Ringkasan streaming perubahan

Bigtable menyediakan pengambilan data perubahan (CDC) dengan fitur aliran perubahan. Aliran perubahan merekam perubahan data ke tabel Bigtable saat perubahan terjadi, sehingga Anda dapat mengalirkan data tersebut untuk diproses atau dianalisis.

Dokumen ini memberikan ringkasan mengenai aliran perubahan data Bigtable. Sebelum membaca dokumen ini, Anda harus sudah memahami Ringkasan Bigtable.

Aliran data perubahan sangat berguna untuk kasus penggunaan CDC termasuk:

Memicu logika aplikasi downstream saat terjadi perubahan yang ditentukan
Mengintegrasikan dengan pipeline analisis data
Mendukung persyaratan audit dan pengarsipan

Pengertian aliran perubahan

Aliran perubahan melacak perubahan pada tingkat tabel yang dibuat oleh pengguna atau aplikasi, biasanya menggunakan salah satu library klien Cloud Bigtable. Perubahan pembersihan sampah memori juga akan direkam.

Semua perubahan yang diterapkan pada tabel yang mendukung aliran perubahan disimpan sebagai catatan perubahan data. Kumpulan data perubahan data mencakup perubahan data yang diterapkan oleh hal berikut:

Penulisan, penghapusan, dan update yang dikirim menggunakan metode Cloud Bigtable API MutateRow, MutateRows, CheckAndMutateRow, dan ReadModifyWriteRow
Penghapusan yang terjadi karena pembersihan sampah memori
Baris dihapus menggunakan metode DropRowRange Admin API

Untuk mengetahui detail tentang jenis perubahan yang dapat Anda kirim ke tabel Bigtable, lihat Bacaan, Penulisan, Penghapusan, dan Ringkasan pengumpulan sampah.

Aliran data perubahan tidak melacak perubahan skema, seperti menambahkan atau mengubah grup kolom, atau topologi replikasi, seperti menambahkan atau menghapus cluster.

Anda mengaktifkan aliran data perubahan di tabel dan menentukan periode retensi data selama 1 hingga 7 hari.

Yang ada dalam kumpulan data perubahan data

Setiap kumpulan data perubahan data berisi semua perubahan untuk baris yang diterapkan secara atomik sebagai bagian dari panggilan RPC tunggal.

Jika nilai ditimpa, nilai yang baru ditulis tersebut akan dicatat dalam record perubahan data. Data perubahan data tidak berisi nilai lama.

Kumpulan data perubahan data menerima stempel waktunya, yang disebut stempel waktu commit,pada saat perubahan diterapkan ke cluster pertama yang menerimanya. Misalnya, pertimbangkan sebuah instance dengan dua cluster. Jika Anda mengirim permintaan tulis ke Tabel 1 di Cluster A, stempel waktu commit catatan perubahan data akan ditetapkan saat operasi tulis diterima oleh Cluster A, dan kumpulan data perubahan data di Cluster B untuk penulisan ini memiliki stempel waktu commit yang sama.

Setiap record perubahan data berisi hal berikut:

Entri - perubahan dilakukan pada baris, termasuk satu atau beberapa hal berikut:
- Tulis
  - Kelompok kolom
  - Penentu kolom
  - Stempel waktu
  - Nilai
- Penghapusan sel
  - Kelompok kolom
  - Penentu kolom
  - Rentang stempel waktu
- Penghapusan grup kolom
  - Kelompok kolom
  - Penghapusan dari baris - Penghapusan dari baris dikonversi menjadi daftar penghapusan dari grup kolom untuk setiap grup kolom yang datanya dimiliki baris.
Kunci baris - ID untuk baris yang diubah
Jenis perubahan - baik yang dimulai oleh pengguna atau pembersihan sampah memori
ID cluster yang menerima perubahan
Stempel waktu commit - waktu sisi server saat perubahan di-commit ke tabel
Pemutus arus - nilai yang memungkinkan aplikasi yang membaca aliran data menggunakan kebijakan resolusi konflik bawaan Bigtable
Token - digunakan oleh aplikasi pengguna untuk melanjutkan streaming jika terganggu
Estimasi watermark rendah - perkiraan waktu sejak partisi data mendeteksi replikasi di semua cluster. Untuk mengetahui detailnya, lihat Partisi dan Watermark.

Guna mengetahui detail tambahan tentang kolom dalam kumpulan data perubahan data, lihat referensi API untuk ReadChangeStream.

Mengubah penyimpanan streaming

Tabel dan aliran perubahannya menggunakan resource level cluster yang sama, termasuk node dan penyimpanan. Akibatnya, penyimpanan data aliran data perubahan adalah bagian dari penyimpanan tabel. Dalam instance yang menggunakan replikasi, salinan data aliran data perubahan disimpan di setiap cluster instance yang berisi tabel perubahan aliran data yang diaktifkan.

Penyimpanan yang digunakan untuk data aliran data perubahan tidak mengurangi total penggunaan penyimpanan Anda (% maks). Akibatnya, Anda tidak perlu menambahkan node untuk menangani peningkatan penyimpanan yang digunakan oleh data aliran data (meskipun Anda mungkin perlu menambahkan node untuk daya komputasi tambahan). Namun, Anda dikenai biaya untuk penyimpanan yang digunakan oleh data aliran perubahan. Untuk mengetahui detailnya, lihat Pertimbangan biaya.

Membaca aliran perubahan

Untuk membaca (streaming) aliran perubahan, Anda harus menggunakan profil aplikasi yang dikonfigurasi untuk perutean cluster tunggal. Untuk mengetahui informasi selengkapnya tentang kebijakan pemilihan rute, lihat Ringkasan profil aplikasi.

Untuk daftar lengkap parameter yang Anda teruskan untuk membaca aliran perubahan, lihat ReadChangeStream.

Metode aliran data perubahan disediakan oleh Cloud Bigtable API (Data API). Sebaiknya gunakan salah satu opsi berikut, bukan memanggil API tanpa menggunakan konektor atau library klien, sehingga Anda tidak perlu melacak dan menangani perubahan partisi akibat pemisahan dan penggabungan.

Template Dataflow

Anda dapat menggunakan template Dataflow yang disediakan oleh Google:

Konektor Bigtable Beam

Anda dapat menggunakan konektor Bigtable Beam untuk membuat pipeline:

Konektor Bigtable Beam

Jika tidak ingin membuat pipeline sendiri, Anda dapat menggunakan contoh kode dari tutorial atau panduan memulai Bigtable sebagai titik awal untuk kode Anda:

Library klien Java

Klien Cloud Bigtable untuk Java

Partisi

Untuk mempertahankan throughput baca yang tinggi dan sesuai dengan tingkat operasi tulis/perubahan yang tinggi, Bigtable membagi aliran perubahan menjadi beberapa partisi yang dapat digunakan untuk membaca aliran perubahan secara paralel. Setiap partisi aliran perubahan dikaitkan dengan tablet. Tablet adalah subbagian tabel yang didistribusikan ulang sesuai kebutuhan untuk membantu menyeimbangkan beban kerja permintaan tabel. Untuk mempelajari lebih lanjut, lihat Load balancing.

Library klien Java memungkinkan Anda meminta perubahan pada setiap partisi dan memberikan informasi yang diperlukan untuk mengelola perubahan partisi akibat pemisahan dan penggabungan.

Watermark

Watermark adalah stempel waktu yang memperkirakan seberapa baru sebuah partisi menerima replikasi di semua cluster. Watermark untuk partisi terus diperbarui saat replikasi terjadi, yang bergerak maju seiring waktu.

Setiap ChangeStreamMutation (data perubahan data) menyertakan kolom estimatedLowWatermark, yang merupakan watermark untuk partisi yang terkait dengan kumpulan data perubahan data. estimatedLowWatermark ini merupakan perkiraan dan tidak menjamin bahwa tidak ada data yang belum masuk di aliran.

Watermark untuk tabel replika

estimatedLowWatermark (watermark rendah) partisi tidak akan bergerak maju jika replikasi tidak sepenuhnya terdeteksi untuk partisi. Watermark rendah lebar-aliran — yang terendah dari semua estimasi watermark rendah pada tingkat partisi — berhenti melanjutkan jika watermark partisi tidak bergerak maju. Watermark yang telah berhenti bergerak akan dianggap terhenti. Saat hal ini terjadi, jika Anda melakukan streaming aliran perubahan dalam pipeline, pipeline akan terhenti.

Banyak faktor yang dapat menyebabkan satu atau beberapa watermark tingkat partisi berhenti selama beberapa waktu, termasuk hal berikut:

Membebani cluster dengan traffic yang menyebabkan replikasi terhenti di satu atau beberapa partisi
Keterlambatan jaringan
Tidak tersedianya cluster

Konektor Bigtable Beam menangani hal ini dengan menyetel stempel waktu output ke nol untuk semua data. Untuk mengetahui informasi selengkapnya, lihat Mengelompokkan data tanpa waktu peristiwa.

Monitoring

Untuk membantu Anda memahami pengaruh pengaktifan aliran data perubahan terhadap pemakaian CPU dan penyimpanan untuk instance yang berisi tabel yang mendukung aliran data perubahan, kami menyediakan dua metrik khusus aliran data perubahan. Anda dapat melihat metrik di halaman Bigtable Monitoring atau dengan menggunakan rangkaian alat Cloud Monitoring.

Byte yang digunakan oleh data aliran data perubahan (change_stream_log_used_bytes)
Pemakaian CPU oleh aliran perubahan ( menggunakan cpu_load_by_app_profile_by_method_by_table)

Untuk mengetahui detail tentang metrik ini, lihat Monitoring.

Pertimbangan biaya

Mengaktifkan aliran perubahan pada tabel akan mengakibatkan peningkatan biaya untuk node dan penyimpanan. Khususnya, Anda dapat dikenai biaya penyimpanan yang lebih besar.

Node

Anda biasanya perlu menambahkan node ke cluster (atau meningkatkan jumlah maksimum node jika Anda menggunakan penskalaan otomatis) untuk menangani traffic tambahan saat mengaktifkan dan memproses kumpulan data perubahan data.

Mengaktifkan aliran data perubahan dapat meningkatkan penggunaan CPU sekitar 10%, bahkan sebelum Anda mulai memprosesnya. Memproses aliran perubahan, seperti membacanya menggunakan pipeline Dataflow, dapat meningkatkan penggunaan CPU sekitar 20 hingga 30%, bergantung pada tingkat aktivitas perubahan dan cara pembacaan data aliran data.

Penyimpanan

Anda dikenai biaya tarif penyimpanan BigQuery standar untuk menyimpan kumpulan data perubahan data tabel Anda. Anda juga dikenai biaya untuk menyimpan tabel yang dibuat untuk melacak metadata aliran data perubahan. Periode retensi data yang Anda tentukan akan langsung memengaruhi biaya penyimpanan.

Sebagai aturan umum, kumpulan data perubahan data selama satu hari – yang hanya mencerminkan mutasi yang terjadi hari itu – memerlukan penyimpanan sekitar 1,5 kali lebih banyak daripada data yang ditulis pada hari itu yang menggunakan disk.

Transfer data jaringan

Jika membaca aliran data perubahan di seluruh wilayah, Anda dapat dikenai biaya untuk traffic tersebut. Lihat bagian Jaringan di Harga Bigtable untuk mengetahui daftar lengkap kecepatan transfer data jaringan.

Biaya pemrosesan

Bergantung pada cara Anda membaca catatan perubahan data, biaya tambahan untuk layanan selain Bigtable berlaku. Misalnya, jika menggunakan Dataflow, Anda membayar untuk byte yang diproses dan mesin pekerja yang memproses tugas. Untuk mengetahui detailnya, lihat Harga Dataflow.

Melepaskan rentang baris

Jika memungkinkan, hindari melepaskan rentang baris dari tabel yang mengaktifkan aliran data perubahan. Jika Anda harus menghapus rentang baris, ingatlah bahwa Bigtable mungkin memerlukan waktu lama untuk menyelesaikan operasi, dan penggunaan CPU akan meningkat selama operasi.