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 Google Cloudinternal untuk 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 ke pelanggan.

Pub/Sub menetapkan ID pesan unik ke setiap pesan yang berhasil dipublikasikan ke topik. Secara default, Pub/Sub melakukan pengiriman pesan setidaknya satu kali. Untuk mencapai semantik setidaknya satu kali, 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 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 diproses pada tahap ini.

Karena Pub/Sub mungkin mengirim ulang pesan, pesan duplikat dapat tiba 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 mentoleransi beberapa data duplikat, pertimbangkan untuk menggunakan mode streaming setidaknya satu kali sebagai gantinya. Mode ini dapat menurunkan latensi dan total biaya pipeline Anda secara signifikan. Kelemahannya 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 mengirimkan 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 dihilangkan 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 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 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 a stempel waktu, yang menunjukkan 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 watermark. Jika tidak, secara default, konektor akan menggunakan stempel waktu pesan Pub/Sub.

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 yang tidak terkonfirmasi tertua dalam langganan. API ini memberikan latensi yang lebih rendah daripada yang tersedia di Cloud Monitoring. API ini memungkinkan Dataflow memajukan watermark pipeline dan memancarkan 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.subscriptions.consume
  • pubsub.subscriptions.delete

Selain itu, akun layanan pekerja 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, hal ini akan menunda seluruh watermark untuk maju, sehingga meningkatkan latensi pipeline secara keseluruhan. Jika ada timer atau agregasi jendela dalam pipeline berdasarkan watermark, hal ini juga akan tertunda.

Pub/Sub Seek

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 di pipeline yang sedang berjalan dapat menyebabkan pesan duplikat atau pesan dihilangkan. 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, alur kerja berikut direkomendasikan:

  1. Buat snapshot langganan.
  2. Buat langganan baru untuk topik Pub/Sub. Langganan baru mewarisi snapshot.
  3. Hentikan atau batalkan 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 ke setiap pesan untuk diproses dan menggunakan kunci tersebut untuk mengacak pesan. Untuk tugas Streaming Engine, 1.024 kunci digunakan untuk pengacakan. Untuk tugas non-Streaming Engine, jumlah kunci adalah pangkat 2 terendah yang lebih besar dari (4 * maximum workers).

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

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. 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 kelebihan dan kekurangan yang dijelaskan dalam Paralelisasi dan distribusi.

Anda tidak dapat mengubah jumlah kunci sebagai bagian dari a 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 runner Dataflow.

Backoff eksponensial

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

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

Topik yang dihentikan pengirimannya

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

  • Dataflow mengirimkan konfirmasi negatif karena berbagai alasan internal (misalnya, jika pekerja dimatikan). Akibatnya, pesan mungkin dikirimkan 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 kapan saja setelah tahap pertama, pesan sudah dikonfirmasi dan tidak masuk ke topik yang dihentikan pengirimannya.

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

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 tepat satu kali Pub/Sub 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 panduan 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 pesan tunggal 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 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