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, pelaksana Dataflow menggunakan implementasi konektor kustomnya sendiri. Implementasi ini memanfaatkan API dan layanan internal Google Cloud 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 akan mengirimkan pesan secara asinkron 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, Pub/Sub akan mencoba mengirim ulang jika tidak menerima konfirmasi dari pelanggan dalam batas waktu konfirmasi. Percobaan ulang dapat menyebabkan pesan dikirim lebih dari sekali. Misalnya, pengiriman ulang dapat terjadi jika pelanggan mengonfirmasi setelah batas waktu, atau jika konfirmasi hilang karena masalah jaringan sementara.
Jika Anda menjalankan pipeline Dataflow menggunakan mode streaming tepat satu kali, Dataflow akan menghapus duplikat pesan untuk mencapai semantik tepat satu kali. Jika pipeline Anda dapat mentoleransi beberapa data duplikat, sebaiknya gunakan mode streaming setidaknya sekali. Mode ini dapat secara signifikan menurunkan latensi dan total biaya pipeline Anda. Komprominya adalah beberapa pesan mungkin diproses dua kali. Untuk mengetahui informasi selengkapnya, lihat Memilih mode streaming yang akan digunakan.
Menghapus duplikat menurut 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 terakhir dapat terjadi karena percobaan ulang, jika konfirmasi dihapus 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 dari satu sama lain untuk penghapusan duplikat.
Untuk informasi selengkapnya tentang penggunaan atribut ID, lihat topik referensi SDK berikut:
withIdAttribute
(Java)ReadFromPubSub
(Python)ReadOptions
(Go)
Langganan
Saat mengonfigurasi pipeline, Anda menentukan topik Pub/Sub atau langganan Pub/Sub yang akan 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 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 dihasilkan 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, stempel waktu pesan Pub/Sub akan digunakan.
Untuk informasi selengkapnya tentang penggunaan stempel waktu peristiwa, lihat topik referensi SDK berikut:
withTimestampAttribute
(Java)ReadFromPubSub
(Python)ReadOptions
(Go)
Konektor Pub/Sub memiliki akses ke API pribadi Pub/Sub yang memberikan usia pesan terlama yang tidak terkonfirmasi dalam langganan. API ini memberikan latensi yang lebih rendah daripada yang tersedia di Pemantauan Cloud. Hal ini memungkinkan Dataflow untuk memajukan stempel waktu pipeline dan menghasilkan hasil komputasi berbingkai dengan latensi rendah.
Jika Anda mengonfigurasi konektor untuk menggunakan stempel waktu peristiwa, Dataflow akan membuat langganan Pub/Sub kedua. Fungsi ini menggunakan langganan ini untuk memeriksa waktu peristiwa pesan yang masih berada dalam daftar tunggu. Pendekatan ini memungkinkan Dataflow memperkirakan backlog waktu peristiwa secara akurat. Untuk mengetahui informasi selengkapnya, lihat halaman StackOverflow yang membahas cara Dataflow menghitung watermark Pub/Sub.
Penelusuran Pub/Sub
Penelusuran Pub/Sub memungkinkan pengguna memutar ulang pesan yang sebelumnya diakui. Anda dapat menggunakan Penelusuran Pub/Sub dengan Dataflow untuk memproses ulang pesan dalam pipeline.
Namun, sebaiknya jangan gunakan Penelusuran Pub/Sub dalam pipeline yang sedang berjalan. Mencari mundur di 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 Penelusuran Pub/Sub, alur kerja berikut direkomendasikan:
- Buat snapshot langganan.
- Buat langganan baru untuk topik Pub/Sub. Langganan baru akan mewarisi snapshot.
- Menguras atau membatalkan tugas Dataflow saat ini.
- Kirim ulang pipeline menggunakan langganan baru.
Untuk mengetahui informasi selengkapnya, lihat Pemrosesan ulang pesan dengan Snapshot dan Penelusuran 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 backoff eksponensial. Namun, backoff eksponensial tidak berfungsi dengan Dataflow.
Backoff eksponensial dipicu oleh konfirmasi negatif atau saat batas waktu konfirmasi berakhir. Namun, Dataflow tidak mengirim respons negatif saat kode pipeline gagal. Sebagai gantinya, pesan akan dicoba lagi tanpa batas waktu, sekaligus terus memperpanjang batas waktu konfirmasi untuk pesan tersebut.
Topik yang dihentikan pengirimannya
Jangan gunakan topik dead-letter Pub/Sub dengan Dataflow, karena alasan berikut:
Dataflow mengirimkan konfirmasi negatif karena berbagai alasan internal (misalnya, jika pekerja dimatikan). Akibatnya, pesan mungkin dikirim ke topik yang dihentikan pengirimannya meskipun tidak ada kegagalan yang terjadi dalam kode pipeline.
Dataflow mungkin mengonfirmasi pesan sebelum pipeline memproses data sepenuhnya. Secara khusus, Dataflow mengonfirmasi pesan setelah berhasil diproses oleh tahap gabungan pertama dan efek samping pemrosesan tersebut telah ditulis ke penyimpanan persisten. Jika pipeline memiliki beberapa tahap gabungan dan kegagalan terjadi kapan saja setelah tahap pertama, pesan sudah dikonfirmasi dan tidak akan masuk ke topik dead-letter.
Sebagai gantinya, terapkan pola dead-letter secara eksplisit di pipeline. Beberapa sink I/O memiliki dukungan bawaan untuk antrean surat mati. 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 tepat sekali 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 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.
Langkah selanjutnya
- Stream Processing dengan Pub/Sub dan Dataflow: Qwik Start (lab mandiri)
- Streaming dari Pub/Sub ke BigQuery
- Melakukan streaming pesan dari Pub/Sub menggunakan Dataflow
- Pipeline streaming
- Tepat satu kali di Dataflow
- Setelah Lambda: Pemrosesan tepat satu kali di Dataflow Bagian 1 dan Bagian 3: Sumber dan Penampung (blog)