Streaming dengan Pub/Sub

Halaman ini memberikan ringkasan konseptual tentang integrasi Dataflow dengan Pub/Sub. Ringkasan ini menjelaskan beberapa pengoptimalan yang tersedia dalam penerapan konektor I/O Pub/Sub oleh runner Dataflow. Pub/Sub adalah sistem penyerapan dan pengiriman peristiwa yang skalabel dan tahan lama. Dataflow melengkapi model pengiriman Pub/Sub yang skalabel dan setidaknya satu kali dengan penghapusan duplikat pesan, pemrosesan tepat satu kali, dan pembuatan watermark data dari peristiwa yang diberi stempel waktu. Untuk menggunakan Dataflow, tulis pipeline Anda menggunakan Apache Beam SDK, lalu jalankan kode pipeline di layanan Dataflow.

Sebelum memulai, pelajari konsep dasar Apache Beam dan pipeline streaming. Baca referensi berikut untuk informasi lebih lanjut:

Membangun pipeline streaming dengan Pub/Sub

Untuk mendapatkan manfaat integrasi Dataflow dengan Pub/Sub, Anda dapat membangun pipeline streaming dengan salah satu cara berikut:

Fitur integrasi Pub/Sub dan Dataflow

Apache Beam menyediakan implementasi sumber I/O referensi (PubsubIO) untuk Pub/Sub (Java, Python, dan Go). Implementasi sumber I/O ini digunakan oleh runner non-Dataflow, seperti runner Apache Spark, runner Apache Flink, dan runner langsung.

Runner Dataflow menggunakan implementasi pribadi yang berbeda dari PubsubIO (untuk Java, Python, dan Go). Implementasi ini memanfaatkan API dan layanan internal Google Cloud untuk menawarkan tiga keunggulan utama: watermark latensi rendah, akurasi watermark yang tinggi (dan kelengkapan data), dan penghapusan duplikat yang efisien (pemrosesan pesan tepat satu kali).

Konektor I/O Apache Beam memungkinkan Anda berinteraksi dengan Dataflow menggunakan sumber dan sink yang dikontrol. Implementasi runner Dataflow untuk PubsubIO otomatis mengonfirmasi pesan setelah pesan berhasil diproses oleh tahap penggabungan pertama dan efek samping dari pemrosesan tersebut akan ditulis ke penyimpanan persisten. Lihat dokumentasi fusi untuk detail selengkapnya. Oleh karena itu, pesan hanya dikonfirmasi jika Dataflow dapat menjamin bahwa tidak ada data yang hilang jika beberapa komponen mengalami error atau koneksi terputus.

Watermark latensi rendah

Dataflow memiliki akses ke API pribadi Pub/Sub yang memberikan usia pesan terlama yang tidak dikonfirmasi dalam langganan, dengan latensi lebih rendah daripada yang tersedia di Cloud Monitoring. Sebagai perbandingan, metrik backlog Pub/Sub yang tersedia di Cloud Monitoring biasanya tertunda selama dua hingga tiga menit, tetapi metrik hanya tertunda sekitar sepuluh detik untuk Dataflow. Hal ini memungkinkan Dataflow mempercepat watermark pipeline dan memunculkan hasil komputasi berjendela.

Akurasi watermark yang tinggi

Masalah penting lainnya yang diselesaikan secara native oleh integrasi Dataflow dengan Pub/Sub adalah perlunya watermark yang kuat untuk periode yang ditentukan dalam waktu peristiwa. Waktu peristiwa adalah stempel waktu yang ditentukan oleh aplikasi penayang sebagai atribut pesan Pub/Sub, bukan kolom publish_time yang ditetapkan pada pesan oleh layanan Pub/Sub itu sendiri. Karena Pub/Sub menghitung statistik backlog hanya sesuai dengan stempel waktu yang ditetapkan layanan (atau waktu pemrosesan), estimasi watermark waktu peristiwa memerlukan mekanisme terpisah.

Untuk mengatasi masalah ini, jika pengguna memilih untuk menggunakan stempel waktu peristiwa kustom, layanan Dataflow akan membuat langganan pelacakan kedua. Langganan pelacakan ini digunakan untuk memeriksa waktu peristiwa pesan di backlog langganan dasar, dan memperkirakan backlog waktu peristiwa. Lihat halaman StackOverflow yang membahas cara Dataflow menghitung watermark Pub/Sub untuk mengetahui informasi lebih lanjut.

Penghapusan duplikat yang efisien

Penghapusan duplikat pesan diperlukan untuk pemrosesan pesan tepat satu kali, dan Anda dapat menggunakan model pemrograman Apache Beam untuk mencapai pemrosesan streaming pesan Pub/Sub tepat satu kali. Dataflow menghapus duplikat pesan sehubungan dengan ID pesan Pub/Sub. Akibatnya, semua logika pemrosesan dapat mengasumsikan bahwa pesan tersebut sudah unik sehubungan dengan ID pesan Pub/Sub. Mekanisme agregasi inkremental yang efisien untuk mencapai hal ini diabstraksi dalam PubsubIO API.

Jika PubsubIO dikonfigurasi untuk menggunakan atribut pesan Pub/Sub untuk penghapusan duplikat, bukan ID pesan, Dataflow akan menghapus duplikat pesan yang dipublikasikan ke Pub/Sub dalam waktu 10 menit satu sama lain.

Fitur Pub/Sub yang tidak didukung

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

Topik yang dihentikan pengirimannya dan kebijakan percobaan ulang penundaan backoff eksponensial

Topik Pub/Sub yang dihentikan pengirimannya dan kebijakan percobaan ulang penundaan backoff eksponensial tidak sepenuhnya didukung oleh Dataflow. Sebagai gantinya, terapkan pola ini secara eksplisit dalam pipeline. Dua contoh pola yang dihentikan pengirimannya disediakan di aplikasi retail dan template Pub/Sub to BigQuery.

Ada dua alasan mengapa kebijakan percobaan ulang penundaan backoff eksponensial dan topik yang dihentikan pengirimannya tidak berfungsi dengan Dataflow.

Pertama, Dataflow tidak pesan NACK (yaitu, mengirim konfirmasi negatif) ke Pub/Sub jika kode pipeline gagal. Sebagai gantinya, Dataflow akan mencoba kembali pemrosesan pesan tanpa batas waktu, sambil terus memperpanjang batas waktu konfirmasi untuk pesan tersebut. Namun, backend Dataflow mungkin memiliki pesan NACK karena berbagai alasan internal, sehingga pesan dapat dikirim ke topik yang dihentikan pengirimannya meskipun tidak ada kegagalan dalam kode pipeline.

Kedua, Dataflow mungkin mengonfirmasi pesan sebelum pipeline memproses data sepenuhnya. Secara khusus, Dataflow mengonfirmasi pesan setelah pesan berhasil diproses pada tahap pertama gabungan dan efek samping dari pemrosesan tersebut telah ditulis ke penyimpanan persisten. Jika pipeline memiliki beberapa tahap gabungan dan kegagalan terjadi pada titik mana pun setelah tahap pertama, pesan telah dikonfirmasi.

Pengiriman Pub/Sub tepat satu kali

Karena Dataflow memiliki pemrosesan tepat satu kali, penggunaan Pub/Sub tepat satu kali dengan Dataflow tidak direkomendasikan. Mengaktifkan pengiriman Pub/Sub tepat satu kali akan menurunkan performa pipeline karena membatasi pesan yang tersedia untuk pemrosesan paralel.

Pengurutan pesan Pub/Sub

Saat pengurutan pesan Pub/Sub diaktifkan, Dataflow mungkin mengurutkan ulang pesan. Pipeline berjalan, tetapi tidak ada jaminan bahwa pesan akan tiba sesuai urutan penerimaannya. Namun, saat menggunakan Pub/Sub dengan Dataflow, mengaktifkan pengurutan pesan dapat meningkatkan latensi dan menurunkan performa.

Langkah selanjutnya