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 kustomnya sendiri untuk konektor. Implementasi ini memanfaatkan API dan layanan internal Google Clouduntuk menawarkan watermark latensi rendah, akurasi watermark tinggi, dan penghapusan duplikat yang efisien untuk pemrosesan pesan tepat satu kali. Konektor ini 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 mengirimkan pesan secara asinkron kepada pelanggan.

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

Dataflow mengonfirmasi pesan setelah pesan 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 sekumpulan pesan sedang diproses pada tahap ini.

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

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

Menghapus duplikat berdasarkan atribut pesan

Secara default, Dataflow menghapus duplikat berdasarkan ID pesan. Namun, aplikasi mungkin mengirim data yang sama dua kali sebagai dua pesan Pub/Sub yang berbeda. Misalnya, data sumber asli mungkin berisi data duplikat, atau aplikasi mungkin salah memublikasikan pesan yang sama dua kali. Hal ini dapat terjadi karena percobaan ulang, jika konfirmasi dibatalkan 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 mungkin berisi ID transaksi yang 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 akan menerima sebagian data secara nondeterministik, yang dapat menyebabkan pesan duplikat, jeda 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 unik per pipeline.

Stempel waktu dan watermark

Semua pesan Pub/Sub memiliki stempel waktu, yang menunjukkan waktu saat Pub/Sub menerima pesan. Data Anda mungkin juga memiliki stempel waktu peristiwa, yang merupakan 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 menyediakan usia pesan terlama yang belum dikonfirmasi dalam langganan. API ini memberikan latensi yang lebih rendah daripada yang tersedia di Cloud Monitoring. Hal ini memungkinkan Dataflow memajukan watermark pipeline dan memunculkan 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 ada dalam backlog. Pendekatan ini memungkinkan Dataflow memperkirakan backlog waktu peristiwa secara akurat. Akun layanan worker harus memiliki setidaknya izin berikut pada project yang berisi langganan pelacakan:

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

Selain itu, akun layanan 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 watermark, lihat halaman StackOverflow yang membahas cara Dataflow menghitung watermark Pub/Sub.

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

Pub/Sub Seek

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

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

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

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

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

Paralelisme sumber Pub/Sub

Sumber Pub/Sub menetapkan kunci deterministik untuk setiap pesan yang akan diproses dan menggunakan kunci tersebut untuk mengacak pesan.

  • Untuk tugas Streaming Engine, Dataflow menghitung jumlah kunci secara dinamis berdasarkan worker aktif pada waktu tertentu: (number of workers * threads per worker) / 2. Nilai yang dihitung dibatasi pada rentang antara 128 dan 65.536 kunci, lalu dibulatkan ke bawah ke pangkat 2 terdekat (pangkat 2 tertinggi yang lebih kecil dari atau sama dengan nilai yang dihitung).

  • Untuk tugas non-Streaming Engine, jumlah kunci adalah pangkat 2 terendah yang lebih besar dari atau sama dengan (4 * maximum workers).

Untuk mengganti jumlah default kunci shuffle, tetapkan opsi layanan num_pubsub_keys:

Java 

--dataflowServiceOptions=num_pubsub_keys=NUMBER_OF_KEYS

Python 

--dataflow_service_options=num_pubsub_keys=NUMBER_OF_KEYS

Go 

--dataflow_service_options=num_pubsub_keys=NUMBER_OF_KEYS

Ganti NUMBER_OF_KEYS dengan jumlah kunci. Nilai pangkat 2 berikutnya yang lebih besar dari atau sama dengan nilai yang ditentukan akan digunakan.

Misalnya, Anda dapat menetapkan opsi ini dalam situasi berikut:

Jika Anda menetapkan opsi ini, pertimbangkan konsekuensi yang dijelaskan dalam Paralelisasi dan distribusi.

Anda tidak dapat mengubah jumlah kunci sebagai bagian dari update pipeline. Untuk mengubah jumlah kunci untuk tugas pipeline yang ada, Anda harus memulai tugas baru.

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 backoff eksponensial. Namun, backoff eksponensial tidak berfungsi dengan Dataflow. Sebagai gantinya, buat langganan dengan kebijakan percobaan ulang Retry immediately.

Backoff eksponensial dipicu oleh konfirmasi negatif atau saat batas waktu konfirmasi berakhir. Namun, Dataflow tidak mengirimkan konfirmasi negatif saat kode pipeline gagal. Sebagai gantinya, Pub/Sub akan mencoba ulang pemrosesan pesan tanpa batas waktu, sekaligus terus memperpanjang batas waktu konfirmasi untuk pesan tersebut.

Topik yang dihentikan pengirimannya

Jangan gunakan topik yang dihentikan pengirimannya di Pub/Sub dengan Dataflow, karena alasan berikut:

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

  • Dataflow mengonfirmasi pesan setelah paket pesan berhasil diproses oleh tahap gabungan pertama. Jika pipeline memiliki beberapa tahap gabungan dan kegagalan terjadi pada titik mana pun setelah tahap pertama, pesan sudah dikonfirmasi dan tidak masuk ke topik yang dihentikan pengirimannya.

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

Pengiriman tepat satu kali Pub/Sub

Karena Dataflow memiliki mekanismenya sendiri untuk pemrosesan tepat satu kali, sebaiknya jangan gunakan pengiriman tepat satu kali Pub/Sub dengan Dataflow. Mengaktifkan pengiriman Pub/Sub tepat satu kali 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 publikasinya.

Sebaiknya jangan gunakan pengurutan pesan dengan Dataflow, karena alasan berikut:

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

Transformasi satu pesan Pub/Sub

Transformasi pesan tunggal (SMT) memungkinkan Anda memanipulasi, memvalidasi, dan memfilter pesan berdasarkan atribut atau datanya saat pesan tersebut di-streaming melalui sistem. Langganan yang dimasukkan 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 dikirim 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