Membaca dari Pub/Sub ke Dataflow

Halaman ini menjelaskan praktik terbaik untuk membaca dari Pub/Sub di Dataflow.

Apache Beam menyediakan implementasi referensi konektor I/O Pub/Sub untuk digunakan oleh runner non-Dataflow. Namun, runner Dataflow menggunakan implementasi konektor kustomnya sendiri. Implementasi ini memanfaatkan API dan layanan internal Google Clouduntuk menawarkan tanda air latensi rendah, akurasi tanda air tinggi, dan penghapusan duplikat yang efisien untuk pemrosesan pesan tepat satu kali. Konektor tersedia untuk Java, Python, dan Go.

Pemrosesan tepat satu kali

Pub/Sub memisahkan penayang peristiwa dari konsumen peristiwa. Aplikasi memublikasikan pesan ke topik, dan Pub/Sub secara asinkron mengirimkan pesan ke pelanggan.

Pub/Sub menetapkan ID pesan unik untuk setiap pesan yang berhasil dipublikasikan ke topik. Secara default, Pub/Sub melakukan pengiriman pesan setidaknya satu kali. Untuk mencapai semantik setidaknya sekali, jika Pub/Sub tidak menerima konfirmasi dari pelanggan dalam batas waktu konfirmasi, Pub/Sub akan mencoba lagi pengiriman pesan. Percobaan ulang juga dapat terjadi sebelum batas waktu konfirmasi, atau setelah pesan dikonfirmasi.

Dataflow mengonfirmasi pesan setelah berhasil diproses oleh tahap gabungan pertama dan efek samping dari pemrosesan tersebut telah ditulis ke penyimpanan persisten. Untuk mengurangi jumlah pesan duplikat, Dataflow terus memperpanjang batas waktu konfirmasi saat batch pesan sedang diproses pada tahap ini.

Karena Pub/Sub dapat mengirim ulang pesan, pesan duplikat dapat tiba di pipeline. Jika pipeline Dataflow Anda menggunakan mode streaming tepat satu kali, maka Dataflow akan menghapus duplikat pesan ini untuk mencapai semantik tepat satu kali.

Jika pipeline Anda dapat mentoleransi beberapa data duplikat, pertimbangkan untuk menggunakan mode streaming minimal sekali. Mode ini dapat menurunkan latensi dan total biaya pipeline Anda secara signifikan. Kelemahannya adalah pesan duplikat mungkin diproses dua kali. Untuk informasi selengkapnya, lihat Memilih mode streaming yang akan digunakan.

Menghapus duplikat menurut atribut pesan

Secara default, Dataflow menghapus duplikat berdasarkan ID pesan. Namun, aplikasi dapat mengirimkan data yang sama dua kali sebagai dua pesan Pub/Sub yang berbeda. Misalnya, data sumber asli mungkin berisi duplikat data, atau aplikasi mungkin salah memublikasikan pesan yang sama dua kali. Yang terakhir dapat terjadi karena percobaan ulang, jika konfirmasi dihentikan karena masalah jaringan atau gangguan lainnya. Dalam situasi ini, pesan duplikat memiliki ID pesan yang berbeda.

Bergantung pada skenario Anda, data Anda mungkin berisi kolom unik yang dapat digunakan untuk menghapus duplikat. Misalnya, data dapat berisi ID transaksi unik. Anda dapat mengonfigurasi konektor I/O Pub/Sub untuk menghapus duplikat pesan berdasarkan nilai atribut pesan, bukan menggunakan ID pesan Pub/Sub. Selama penayang menetapkan atribut ini secara konsisten selama percobaan ulang, Dataflow dapat mendeteksi duplikat. Pesan harus dipublikasikan ke Pub/Sub dalam waktu 10 menit satu sama lain untuk penghapusan duplikat.

Untuk mengetahui informasi selengkapnya tentang penggunaan atribut ID, lihat topik referensi SDK berikut:

Langganan

Saat mengonfigurasi pipeline, Anda menentukan topik Pub/Sub atau langganan Pub/Sub untuk dibaca. Jika Anda menentukan langganan, jangan gunakan langganan Pub/Sub yang sama untuk beberapa pipeline. Jika dua pipeline membaca dari satu langganan, setiap pipeline menerima sebagian data secara non-deterministik, yang dapat menyebabkan pesan duplikat, keterlambatan watermark, dan penskalaan otomatis yang tidak efisien. Sebagai gantinya, buat langganan terpisah untuk setiap pipeline.

Jika Anda menentukan topik, konektor akan membuat langganan sementara baru. Langganan ini bersifat unik per pipeline.

Stempel waktu dan watermark

Semua pesan Pub/Sub memiliki stempel waktu, yang mewakili waktu saat Pub/Sub menerima pesan. Data Anda mungkin juga memiliki stempel waktu peristiwa, yaitu waktu saat data dibuat oleh sumber.

Anda dapat mengonfigurasi konektor untuk membaca stempel waktu peristiwa dari atribut pada pesan Pub/Sub. Dalam hal ini, konektor menggunakan stempel waktu peristiwa untuk pemberian watermark. Jika tidak, secara default, stempel waktu pesan Pub/Sub akan digunakan.

Untuk mengetahui informasi selengkapnya tentang penggunaan stempel waktu peristiwa, lihat topik referensi SDK berikut:

Konektor Pub/Sub memiliki akses ke API pribadi Pub/Sub yang memberikan usia pesan tertua yang belum dikonfirmasi dalam langganan. API ini memberikan latensi yang lebih rendah daripada yang tersedia di Cloud Monitoring. Hal ini memungkinkan Dataflow memajukan tanda air pipeline dan mengeluarkan hasil komputasi berjendela dengan latensi rendah.

Jika Anda mengonfigurasi konektor untuk menggunakan stempel waktu peristiwa, Dataflow akan membuat langganan Pub/Sub kedua, yang disebut langganan pelacakan. Dataflow menggunakan langganan pelacakan untuk memeriksa waktu peristiwa pesan yang masih dalam backlog. Pendekatan ini memungkinkan Dataflow memperkirakan backlog waktu peristiwa secara akurat. Akun layanan pekerja harus memiliki setidaknya izin berikut pada project yang berisi langganan pelacakan:

  • pubsub.subscriptions.create
  • pubsub.subscription.consume
  • pubsub.subscription.delete

Selain itu, akun ini memerlukan izin pubsub.topics.attachSubscription pada topik Pub/Sub. Sebaiknya buat peran Identity and Access Management kustom yang hanya berisi izin ini.

Untuk mengetahui informasi selengkapnya tentang tanda air, lihat halaman StackOverflow yang membahas cara Dataflow menghitung tanda air Pub/Sub.

Jika pipeline memiliki beberapa sumber Pub/Sub, dan salah satunya memiliki volume yang sangat rendah atau tidak aktif, hal ini akan menunda seluruh watermark untuk maju, sehingga meningkatkan latensi pipeline secara keseluruhan. Jika ada timer atau agregasi jendela dalam pipeline berdasarkan tanda air, hal ini juga akan tertunda.

Pencarian Pub/Sub

Pub/Sub Seek memungkinkan pengguna memutar ulang pesan yang sebelumnya dikonfirmasi. Anda dapat menggunakan Pub/Sub Seek dengan Dataflow untuk memproses ulang pesan dalam pipeline.

Namun, sebaiknya jangan gunakan Pub/Sub Seek di pipeline yang sedang berjalan. Mencari ke belakang dalam pipeline yang sedang berjalan dapat menyebabkan pesan duplikat atau pesan dihilangkan. Hal ini juga membatalkan logika watermark Dataflow dan berkonflik dengan status pipeline yang menggabungkan data yang diproses.

Untuk memproses ulang pesan menggunakan Pub/Sub Seek, alur kerja berikut direkomendasikan:

  1. Buat snapshot langganan.
  2. Buat langganan baru untuk topik Pub/Sub. Langganan baru mewarisi snapshot.
  3. Menguras atau membatalkan tugas Dataflow saat ini.
  4. Kirim ulang pipeline menggunakan langganan baru.

Untuk mengetahui informasi selengkapnya, lihat Pemrosesan ulang pesan dengan Snapshot dan Pencarian Pub/Sub.

Fitur Pub/Sub yang tidak didukung

Fitur Pub/Sub berikut tidak didukung dalam implementasi konektor I/O Pub/Sub oleh runner Dataflow.

Backoff eksponensial

Saat membuat langganan Pub/Sub, Anda dapat mengonfigurasinya untuk menggunakan kebijakan percobaan ulang dengan penundaan eksponensial. Namun, backoff eksponensial tidak berfungsi dengan Dataflow. Sebagai gantinya, buat langganan dengan kebijakan percobaan ulang Coba lagi segera.

Pencadangan eksponensial dipicu oleh konfirmasi negatif atau saat batas waktu konfirmasi berakhir. Namun, Dataflow tidak mengirimkan konfirmasi negatif saat kode pipeline gagal. Sebagai gantinya, pesan akan diproses ulang tanpa batas waktu, sambil terus memperpanjang batas waktu konfirmasi untuk pesan tersebut.

Topik yang dihentikan pengirimannya

Jangan gunakan topik pesan yang tidak terkirim Pub/Sub dengan Dataflow, karena alasan berikut:

  • Dataflow mengirimkan konfirmasi negatif karena berbagai alasan internal (misalnya, jika pekerja sedang dimatikan). Akibatnya, pesan dapat dikirimkan ke topik yang dihentikan pengirimannya meskipun tidak ada kegagalan dalam kode pipeline.

  • Dataflow mengakui pesan setelah sekumpulan pesan berhasil diproses oleh tahap gabungan pertama. Jika pipeline memiliki beberapa tahap gabungan dan kegagalan terjadi di titik mana pun setelah tahap pertama, pesan sudah dikonfirmasi dan tidak masuk ke topik pesan yang tidak terkirim.

Sebagai gantinya, terapkan pola pesan yang dihentikan pengirimannya secara eksplisit di pipeline, dengan merutekan pesan yang gagal ke tujuan untuk diproses nanti. Beberapa sink I/O memiliki dukungan bawaan untuk antrean pesan yang tidak terkirim. Contoh berikut mengimplementasikan pola pesan yang tidak terkirim:

Pengiriman tepat satu kali Pub/Sub

Karena Dataflow memiliki mekanisme sendiri untuk pemrosesan tepat satu kali, sebaiknya jangan gunakan pengiriman tepat satu kali Pub/Sub dengan Dataflow. Mengaktifkan pengiriman Pub/Sub tepat sekali akan mengurangi performa pipeline, karena membatasi jumlah pesan yang tersedia untuk pemrosesan paralel.

Pengurutan pesan Pub/Sub

Pengurutan pesan adalah fitur di Pub/Sub yang memungkinkan pelanggan menerima pesan sesuai urutan saat pesan tersebut dipublikasikan.

Sebaiknya jangan gunakan pengurutan pesan dengan Dataflow karena alasan berikut:

  • Konektor I/O Pub/Sub mungkin tidak mempertahankan pengurutan pesan.
  • Apache Beam tidak menentukan pedoman ketat terkait urutan pemrosesan elemen. Oleh karena itu, urutan mungkin tidak dipertahankan dalam transformasi hilir.
  • Menggunakan pengurutan pesan Pub/Sub dengan Dataflow dapat meningkatkan latensi dan menurunkan performa.

Transformasi pesan tunggal Pub/Sub

Transformasi pesan tunggal (SMT) memungkinkan Anda memanipulasi, memvalidasi, dan memfilter pesan berdasarkan atribut atau datanya saat pesan tersebut mengalir melalui sistem. Langganan yang masuk ke Dataflow tidak boleh menggunakan SMT yang memfilter pesan karena dapat mengganggu penskalaan otomatis. Hal ini terjadi karena pemfilteran SMT langganan dapat menyebabkan backlog tampak lebih besar daripada yang dikirimkan ke Dataflow hingga pesan yang difilter benar-benar diproses oleh SMT. SMT topik yang memfilter pesan tidak akan menyebabkan masalah pada penskalaan otomatis.

Langkah berikutnya