Tepat satu kali di Dataflow

Dataflow mendukung pemrosesan data yang tepat satu kali. Halaman ini menjelaskan cara Dataflow menerapkan pemrosesan tepat satu kali sekaligus memastikan latensi rendah.

Ringkasan

Pipeline batch selalu menggunakan pemrosesan tepat satu kali. Pipeline streaming menggunakan pemrosesan tepat satu kali secara default, tetapi juga dapat menggunakan pemrosesan setidaknya satu kali.

Pemrosesan tepat satu kali memberikan jaminan tentang hasil pemrosesan data, termasuk hasil dari setiap tahap pipeline. Secara khusus, untuk setiap data yang tiba ke pipeline dari sumber, atau tiba di tahap dari tahap sebelumnya, Dataflow memastikan hal berikut:

  • Data diproses dan tidak hilang.
  • Setiap hasil pemrosesan yang tetap berada dalam pipeline akan ditampilkan paling banyak satu kali.

Dengan kata lain, data diproses setidaknya satu kali, dan hasilnya di-commit tepat satu kali.

Pemrosesan tepat satu kali memastikan hasil akurat, tanpa data duplikat dalam output. Dataflow dioptimalkan untuk meminimalkan latensi sekaligus mempertahankan semantik tepat satu kali. Namun, pemrosesan tepat satu kali tetap dikenai biaya untuk melakukan penghapusan duplikat. Untuk kasus penggunaan yang dapat mentoleransi data duplikat, Anda sering kali dapat mengurangi biaya dan meningkatkan latensi dengan mengaktifkan mode setidaknya satu kali. Untuk mengetahui informasi selengkapnya tentang memilih antara streaming tepat satu kali dan setidaknya satu kali, lihat Menetapkan mode streaming pipeline.

Data terlambat

Pemrosesan tepat satu kali memastikan akurasi pipeline: Jika pipeline memproses data, Dataflow akan memastikan bahwa data tersebut ditampilkan dalam output, dan data tersebut tidak diduplikasi.

Namun, dalam pipeline streaming, pemrosesan tepat satu kali tidak dapat menjamin bahwa hasilnya lengkap, karena data mungkin terlambat tiba. Misalnya, pipeline Anda melakukan agregasi selama jangka waktu tertentu, seperti Count. Dengan pemrosesan tepat satu kali, hasilnya akurat untuk data yang tiba dalam jangka waktu yang tepat, tetapi data yang terlambat mungkin akan dihilangkan.

Umumnya, tidak ada cara untuk menjamin kelengkapan dalam pipeline streaming, karena secara teori data dapat tiba terlambat. Dalam kasus yang membatasi, Anda harus menunggu selamanya untuk menghasilkan hasil. Secara lebih praktis, Apache Beam memungkinkan Anda mengonfigurasi nilai minimum untuk menghilangkan data yang terlambat dan kapan harus mengeluarkan hasil gabungan. Untuk mengetahui informasi selengkapnya, lihat Watermark dan data terlambat dalam dokumentasi Apache Beam.

Efek samping

Efek samping tidak dijamin memiliki semantik tepat satu kali. Yang penting, hal ini mencakup penulisan output ke penyimpanan eksternal, kecuali jika sink juga menerapkan semantik tepat satu kali.

Secara khusus, Dataflow tidak menjamin bahwa setiap data akan melalui setiap transformasi tepat satu kali. Karena percobaan ulang atau kegagalan worker, Dataflow mungkin mengirim data melalui transformasi beberapa kali, atau bahkan secara bersamaan di beberapa worker.

Sebagai bagian dari pemrosesan tepat satu kali, Dataflow menghapus duplikat output. Namun, jika kode dalam transformasi memiliki efek samping, efek tersebut mungkin terjadi beberapa kali. Misalnya, jika transformasi melakukan panggilan layanan jarak jauh, panggilan tersebut mungkin dilakukan beberapa kali untuk data yang sama. Efek samping bahkan dapat menyebabkan kehilangan data dalam beberapa situasi. Misalnya, anggaplah transformasi membaca file untuk menghasilkan output, lalu segera menghapus file tanpa menunggu output di-commit. Jika terjadi error saat meng-commit hasil, Dataflow akan mencoba ulang transformasi, tetapi sekarang transformasi tidak dapat membaca file yang dihapus.

Logging

Output log dari pemrosesan menunjukkan bahwa pemrosesan terjadi, tetapi tidak menunjukkan apakah data di-commit. Oleh karena itu, file log mungkin menunjukkan bahwa data diproses beberapa kali meskipun hasil data yang diproses di-commit ke penyimpanan persisten hanya satu kali. Selain itu, log tidak selalu mencerminkan data yang diproses dan di-commit. Log mungkin dihilangkan karena pembatasan atau hilang karena masalah layanan logging lainnya.

Streaming tepat satu kali

Bagian ini menjelaskan cara Dataflow menerapkan pemrosesan tepat satu kali untuk tugas streaming, termasuk cara Dataflow mengelola kompleksitas seperti pemrosesan non-deterministik, data terlambat, dan kode kustom.

Shuffle streaming Dataflow

Tugas Dataflow streaming berjalan di banyak worker yang berbeda secara paralel dengan menetapkan rentang kerja ke setiap worker. Meskipun tugas dapat berubah dari waktu ke waktu sebagai respons terhadap kegagalan worker, penskalaan otomatis, atau peristiwa lainnya, setelah setiap GroupByKey transformasi , semua data dengan kunci yang sama diproses di worker yang sama. Transformasi GroupByKey sering digunakan oleh transformasi gabungan, seperti Count atau FileIO. Untuk memastikan bahwa data untuk kunci tertentu berakhir di worker yang sama, worker Dataflow mengacak data di antara mereka sendiri dengan menggunakan panggilan prosedur jarak jauh (RPC).

Untuk membantu memastikan bahwa data tidak hilang selama shuffle, Dataflow menggunakan pencadangan upstream. Dengan pencadangan upstream, worker yang mengirim data akan mencoba kembali RPC hingga menerima konfirmasi positif bahwa data telah diterima. Efek samping dari pemrosesan data di-commit ke downstream penyimpanan persisten. Jika worker yang mengirim data tidak tersedia, Dataflow akan terus mencoba ulang RPC, yang memastikan bahwa setiap data dikirimkan setidaknya satu kali.

Karena percobaan ulang ini dapat membuat duplikat, setiap pesan diberi tag dengan ID unik. Setiap penerima menyimpan katalog semua ID yang telah dilihat dan diproses. Saat data diterima, Dataflow akan mencari ID-nya di katalog. Jika ID ditemukan, data telah diterima dan di-commit, dan akan dihilangkan sebagai duplikat. Untuk memastikan ID data stabil, setiap output dari langkah ke langkah di-checkpoint ke penyimpanan. Akibatnya, jika pesan yang sama dikirim beberapa kali karena panggilan RPC berulang, pesan hanya di-commit ke penyimpanan satu kali.

Memastikan latensi rendah

Agar pemrosesan tepat satu kali dapat dilakukan, I/O harus dikurangi, khususnya dengan mencegah I/O pada setiap data. Untuk mencapai tujuan ini, Dataflow menggunakan filter Bloom dan pembersihan sampah memori.

Filter Bloom

Filter Bloom adalah struktur data ringkas yang memungkinkan pemeriksaan keanggotaan set yang cepat. Di Dataflow, setiap worker menyimpan filter Bloom dari setiap ID yang dilihatnya. Saat ID data baru tiba, worker akan mencari ID di filter. Jika filter menampilkan salah (false), data ini bukan duplikat, dan worker tidak mencari ID di penyimpanan stabil.

Dataflow menyimpan kumpulan filter Bloom bergulir yang dikelompokkan berdasarkan waktu. Saat data tiba, Dataflow akan memilih filter yang sesuai untuk diperiksa berdasarkan stempel waktu sistem. Langkah ini mencegah filter Bloom menjadi jenuh saat filter dikumpulkan sampah memorinya, dan juga membatasi jumlah data yang perlu dipindai saat startup.

Pembersihan sampah memori

Untuk menghindari pengisian penyimpanan dengan ID data, Dataflow menggunakan pembersihan sampah memori untuk menghapus data lama. Dataflow menggunakan stempel waktu sistem untuk menghitung watermark pembersihan sampah memori.

Watermark ini didasarkan pada jumlah waktu fisik yang dihabiskan untuk menunggu di tahap tertentu. Oleh karena itu, watermark ini juga memberikan informasi tentang bagian pipeline mana yang lambat. Metadata ini adalah dasar untuk metrik jeda sistem yang ditampilkan di antarmuka pemantauan Dataflow.

Jika data tiba dengan stempel waktu yang lebih lama dari watermark, dan jika ID untuk waktu ini telah dikumpulkan sampah memorinya, data akan diabaikan. Karena watermark rendah yang memicu pembersihan sampah memori tidak akan maju hingga pengiriman data dikonfirmasi, data yang terlambat tiba ini adalah duplikat.

Sumber non-deterministik

Dataflow menggunakan Apache Beam SDK untuk membaca data ke dalam pipeline. Jika pemrosesan gagal, Dataflow mungkin akan mencoba ulang pembacaan dari sumber. Dalam situasi tersebut, Dataflow harus memastikan bahwa setiap data unik yang dihasilkan oleh sumber dicatat tepat satu kali. Untuk sumber deterministik, seperti Pub/Sub Lite atau Kafka, data dibaca berdasarkan offset yang direkam, sehingga mengurangi kebutuhan akan langkah ini.

Karena Dataflow tidak dapat menetapkan ID data secara otomatis, sumber non-deterministik harus memberi tahu Dataflow ID data untuk menghindari duplikasi. Saat sumber memberikan ID unik untuk setiap data, konektor menggunakan shuffle dalam pipeline untuk menghapus duplikat. Data dengan ID yang sama akan difilter. Untuk mengetahui contoh cara Dataflow menerapkan pemrosesan tepat satu kali saat menggunakan Pub/Sub sebagai sumber, lihat bagian Pemrosesan tepat satu kali di halaman Streaming dengan Pub/Sub.

Saat Anda menjalankan DoFn kustom sebagai bagian dari pipeline, Dataflow tidak menjamin bahwa kode ini hanya dijalankan satu kali per data. Untuk membantu menjamin pemrosesan setidaknya satu kali jika terjadi kegagalan worker, Dataflow mungkin menjalankan data tertentu melalui transformasi beberapa kali, atau mungkin menjalankan data yang sama secara bersamaan di beberapa worker. Jika Anda menyertakan kode dalam pipeline yang melakukan hal-hal seperti menghubungi layanan eksternal, tindakan tersebut mungkin dijalankan lebih dari satu kali untuk data tertentu.

Untuk membuat pemrosesan non-deterministik menjadi deterministik secara efektif, gunakan checkpointing. Saat Anda menggunakan checkpointing, setiap output dari transformasi di-checkpoint ke penyimpanan stabil dengan ID uniknya sebelum dikirim ke tahap berikutnya. Percobaan ulang dalam pengiriman shuffle Dataflow menyampaikan output yang telah di-checkpoint. Meskipun kode Anda mungkin berjalan beberapa kali, Dataflow memastikan bahwa output dari hanya satu operasi tersebut yang disimpan. Dataflow menggunakan penyimpanan yang konsisten yang mencegah duplikat ditulis ke penyimpanan stabil.

Pengiriman output tepat satu kali

Apache Beam SDK menyertakan sink bawaan yang dirancang untuk memastikan bahwa sink tersebut tidak menghasilkan duplikat. Jika memungkinkan, gunakan salah satu sink bawaan ini.

Jika Anda perlu menulis sink sendiri, pendekatan terbaik adalah membuat objek fungsi Anda idempoten sehingga dapat dicoba ulang sesering yang diperlukan tanpa menyebabkan efek samping yang tidak diinginkan. Namun, sering kali beberapa komponen transformasi yang menerapkan fungsi sink bersifat non-deterministik dan mungkin berubah jika dicoba ulang.

Misalnya, dalam agregasi berjendela, kumpulan data di jendela mungkin bersifat non-deterministik. Secara khusus, jendela mungkin mencoba memicu dengan elemen e0, e1, e2. Worker mungkin mengalami error sebelum meng-commit pemrosesan jendela, tetapi tidak sebelum elemen tersebut dikirim sebagai efek samping. Saat worker dimulai ulang, jendela akan diaktifkan lagi, dan elemen e3 yang terlambat tiba. Karena elemen ini tiba sebelum jendela di-commit, elemen ini tidak dihitung sebagai data terlambat, sehingga DoFn dipanggil lagi dengan elemen e0, e1, e2, e3. Elemen ini kemudian dikirim ke operasi efek samping. Idempotensi tidak membantu dalam skenario ini, karena kumpulan data logis yang berbeda dikirim setiap kali.

Untuk mengatasi non-determinasi di Dataflow, gunakan transformasi Reshuffle bawaan. Saat Dataflow mengacak data, Dataflow akan menulis data secara tahan lama sehingga elemen yang dihasilkan secara non-deterministik akan stabil jika operasi dicoba ulang setelah shuffle terjadi. Menggunakan transformasi Reshuffle membantu menjamin bahwa hanya satu versi output DoFn yang dapat melewati batas shuffle. Pola berikut memastikan bahwa operasi efek samping selalu menerima data deterministik untuk output:

c.apply(Window.<..>into(FixedWindows.of(Duration.standardMinutes(1))))
 .apply(GroupByKey.<..>.create())
 .apply(new PrepareOutputData())
 .apply(Reshuffle.<..>of())
 .apply(WriteToSideEffect());

Untuk memastikan runner Dataflow mengetahui bahwa elemen harus stabil sebelum menjalankan DoFn, tambahkan RequiresStableInput anotasi ke DoFn.

Pelajari lebih lanjut