Mengupgrade pipeline streaming

Halaman ini memberikan panduan dan rekomendasi untuk mengupgrade pipeline streaming Anda. Misalnya, Anda mungkin perlu mengupgrade ke versi Apache Beam SDK yang lebih baru, atau memperbarui kode pipeline. Berbagai opsi disediakan untuk menyesuaikan dengan skenario yang berbeda.

Sementara pipeline batch berhenti saat tugas selesai, pipeline streaming sering berjalan secara terus-menerus untuk memberikan pemrosesan tanpa gangguan. Oleh karena itu, saat mengupgrade pipeline streaming, Anda perlu memperhitungkan pertimbangan berikut:

• Anda mungkin perlu meminimalkan atau menghindari gangguan pada pipeline. Dalam beberapa kasus, Anda mungkin dapat menoleransi gangguan sementara pada pemrosesan saat versi baru pipeline di-deploy. Pada kasus lain, aplikasi Anda mungkin tidak dapat menoleransi gangguan apa pun.
• Proses pembaruan pipeline perlu menangani perubahan skema dengan cara yang meminimalkan gangguan pada pemrosesan pesan dan pada sistem lainnya yang terpasang. Misalnya, jika skema untuk pesan dalam pipeline pemrosesan peristiwa berubah, perubahan skema mungkin juga diperlukan dalam sink data downstream.

Anda dapat menggunakan salah satu metode berikut untuk mengupdate pipeline streaming, bergantung pada pipeline dan persyaratan update:

• Melakukan pembaruan selama penerbangan
• Meluncurkan tugas pengganti
• Menjalankan pipeline paralel

Untuk mengetahui informasi selengkapnya tentang masalah yang mungkin Anda alami selama update dan cara mencegahnya, baca Memvalidasi tugas pengganti dan Pemeriksaan kompatibilitas tugas.

Praktik terbaik

• Upgrade versi Apache Beam SDK secara terpisah dari perubahan kode pipeline.
• Uji pipeline Anda setelah setiap perubahan sebelum melakukan pembaruan tambahan.
• Upgrade versi Apache Beam SDK yang digunakan pipeline Anda secara rutin.

Lakukan pembaruan selama penerbangan

Anda dapat memperbarui beberapa pipeline streaming yang sedang berlangsung tanpa menghentikan tugas. Skenario ini disebut {i>in-flight update<i} (pembaruan tugas yang sedang berlangsung). Info terbaru tugas yang sedang berlangsung hanya tersedia dalam situasi terbatas:

• Tugas harus menggunakan Streaming Engine.
• Tugas harus dalam status berjalan.
• Anda hanya mengubah jumlah pekerja yang digunakan tugas tersebut.

Untuk informasi selengkapnya, lihat Menetapkan rentang penskalaan otomatis di halaman Penskalaan Otomatis Horizontal.

Untuk mengetahui petunjuk yang menjelaskan cara menjalankan update tugas yang sedang berlangsung, lihat Mengupdate pipeline yang ada.

Meluncurkan tugas pengganti

Jika tugas yang diperbarui kompatibel dengan tugas yang sudah ada, Anda dapat memperbarui pipeline menggunakan opsi update. Saat Anda mengganti tugas yang ada, tugas baru akan menjalankan kode pipeline yang telah diperbarui. Layanan Dataflow mempertahankan nama tugas, tetapi menjalankan tugas pengganti dengan ID Tugas yang telah diperbarui. Proses ini dapat menyebabkan periode nonaktif saat tugas yang ada berhenti, pemeriksaan kompatibilitas berjalan, dan tugas baru dimulai. Untuk detail selengkapnya, lihat Efek dari mengganti tugas.

Dataflow melakukan pemeriksaan kompatibilitas untuk memastikan bahwa kode pipeline yang diperbarui dapat di-deploy dengan aman ke pipeline yang sedang berjalan. Perubahan kode tertentu menyebabkan pemeriksaan kompatibilitas gagal, seperti ketika input samping ditambahkan ke atau dihapus dari langkah yang ada. Jika pemeriksaan kompatibilitas gagal, Anda tidak dapat melakukan update tugas di tempat.

Untuk petunjuk yang menjelaskan cara meluncurkan tugas pengganti, lihat Meluncurkan tugas pengganti.

Jika pembaruan pipeline tidak kompatibel dengan tugas saat ini, Anda harus menghentikan dan mengganti pipeline. Jika pipeline Anda tidak dapat menoleransi periode nonaktif, jalankan pipeline paralel.

Menghentikan dan mengganti pipeline

Jika dapat menghentikan pemrosesan untuk sementara, Anda dapat membatalkan atau mengosongkan pipeline, lalu menggantinya dengan pipeline yang diperbarui. Jika pipeline dibatalkan, Dataflow akan segera menghentikan pemrosesan dan menonaktifkan resource secepat mungkin, sehingga dapat menyebabkan hilangnya data yang sedang diproses, yang dikenal sebagai data yang sedang diproses. Untuk menghindari kehilangan data, dalam sebagian besar kasus, pengosongan data adalah tindakan yang lebih disukai.

Mengosongkan pipeline akan langsung menutup semua jendela dalam proses dan mengaktifkan semua pemicu. Meskipun data yang sedang berlangsung tidak hilang, pengosongan dapat menyebabkan jendela memiliki data yang tidak lengkap. Jika hal ini terjadi, jendela dalam proses akan memberikan hasil yang tidak lengkap atau sebagian. Untuk informasi selengkapnya, lihat Efek menghabiskan tugas. Setelah tugas yang ada selesai, luncurkan tugas streaming baru yang berisi kode pipeline yang diperbarui, yang memungkinkan pemrosesan dilanjutkan.

Dengan metode ini, Anda akan mengalami periode nonaktif antara saat tugas streaming yang ada berhenti dan saat pipeline pengganti siap melanjutkan pemrosesan data. Namun, membatalkan atau menghabiskan pipeline yang ada, lalu meluncurkan tugas baru dengan pipeline yang diperbarui tidaklah sulit dibandingkan menjalankan pipeline paralel.

Untuk petunjuk yang lebih detail, lihat Mengosongkan tugas Dataflow. Setelah menghabiskan tugas saat ini, mulai tugas baru dengan nama pekerjaan yang sama.

Pemrosesan ulang pesan dengan Snapshot Pub/Sub dan Seek

Dalam beberapa situasi, setelah mengganti atau membatalkan pipeline yang terkuras, Anda mungkin perlu memproses ulang pesan Pub/Sub yang dikirim sebelumnya. Misalnya, Anda mungkin perlu menggunakan logika bisnis yang diperbarui untuk memproses ulang data. Pub/Sub Seek adalah fitur yang memungkinkan Anda memutar ulang pesan dari snapshot Pub/Sub. Anda dapat menggunakan Pub/Sub Seek dengan Dataflow untuk memproses ulang pesan sejak snapshot langganan dibuat.

Selama pengembangan dan pengujian, Anda juga dapat menggunakan Pub/Sub Seek untuk memutar ulang pesan yang diketahui secara berulang untuk memverifikasi output dari pipeline Anda. Saat Anda menggunakan Pub/Sub Seek, jangan mencari ringkasan langganan saat langganan digunakan oleh pipeline. Jika Anda melakukannya, pencarian tersebut dapat membatalkan logika watermark Dataflow dan dapat memengaruhi pemrosesan pesan Pub/Sub tepat satu kali.

Alur kerja gcloud CLI yang direkomendasikan untuk menggunakan Pub/Sub Seek dengan pipeline Dataflow di jendela terminal adalah sebagai berikut:

1. Untuk membuat snapshot langganan, gunakan perintah gcloud pubsub snapshots create:

   gcloud pubsub snapshots create SNAPSHOT_NAME --subscription=PIPELINE_SUBSCRIPTION_NAME
   

2. Latih atau batalkan pipeline, gunakan perintah gcloud dataflow jobs drain atau perintah gcloud dataflow jobs cancel:

   gcloud dataflow jobs drain JOB_ID
   

   atau

   gcloud dataflow jobs cancel JOB_ID
   

3. Untuk mencari snapshot, gunakan perintah gcloud pubsub subscriptions seek:

   gcloud pubsub subscriptions seek SNAPSHOT_NAME
   

4. Deploy pipeline baru yang memakai langganan.

Menjalankan pipeline paralel

Jika Anda perlu menghindari gangguan pada pipeline streaming selama update, jalankan pipeline paralel. Membuat tugas streaming baru yang memiliki kode pipeline yang diperbarui, dan menjalankan pipeline baru secara paralel dengan pipeline yang ada.

Saat Anda membuat pipeline baru, gunakan strategi windowing yang sama dengan yang Anda gunakan untuk pipeline yang ada. Biarkan pipeline yang ada terus berjalan hingga watermark-nya melebihi stempel waktu periode lengkap paling awal yang diproses oleh pipeline yang diperbarui. Kemudian, menguras atau membatalkan pipeline yang ada. Pipeline yang diupdate akan terus berjalan di tempatnya dan secara efektif mengambil alih pemrosesan sendiri.

Diagram berikut mengilustrasikan proses ini.

Dalam diagram, Pipeline B adalah tugas yang diperbarui dan mengambil alih dari Pipeline A. Nilai t adalah stempel waktu periode lengkap paling awal yang diproses oleh Pipeline B. Nilai w adalah watermark untuk Pipeline A. Agar lebih praktis, watermark yang sempurna mengasumsikan tanpa adanya data yang terlambat. Pemrosesan dan waktu produksi ditampilkan pada sumbu horizontal. Kedua pipeline menggunakan periode tetap (jatuh) selama lima menit. Hasil dipicu setelah watermark melewati akhir setiap jendela.

Karena output serentak terjadi selama periode waktu saat kedua pipeline tumpang-tindih, konfigurasikan kedua pipeline untuk menulis hasil ke tujuan yang berbeda. Sistem downstream dapat menggunakan abstraksi pada dua sink tujuan, seperti tampilan database, untuk membuat kueri hasil gabungan. Sistem ini juga dapat menggunakan abstraksi untuk menghapus duplikat hasil dari periode yang tumpang-tindih.

Contoh berikut menjelaskan pendekatan penggunaan pipeline yang membaca data input dari Pub/Sub, melakukan beberapa pemrosesan, dan menulis hasilnya ke BigQuery.

1. Dalam status awal, pipeline streaming yang ada (Pipeline A) menjalankan dan membaca pesan dari topik Pub/Sub (Topik) menggunakan langganan (Langganan A). Hasilnya ditulis ke tabel BigQuery (Tabel A). Hasilnya digunakan melalui tampilan BigQuery, yang berfungsi sebagai fasad untuk menyamarkan perubahan tabel yang mendasarinya. Proses ini adalah penerapan metode desain yang disebut pola {i>façade<i}. Diagram berikut menunjukkan status awal.

   

2. Buat langganan baru (Langganan B) untuk pipeline yang diperbarui. Deploy pipeline yang telah diperbarui (Pipeline B), yang membaca dari topik Pub/Sub (Topik) menggunakan Langganan B dan menulis ke tabel BigQuery terpisah (Tabel B). Diagram berikut menggambarkan alur ini.

   

   Pada tahap ini, Pipeline A dan Pipeline B berjalan secara paralel dan menulis hasilnya ke tabel terpisah. Anda mencatat waktu t sebagai stempel waktu periode lengkap paling awal yang diproses oleh Pipeline B.

3. Jika watermark Pipeline A melebihi waktu t, kosongkan Pipeline A. Saat Anda menghabiskan pipeline, semua jendela yang terbuka akan tertutup, dan pemrosesan untuk data yang sedang berjalan akan selesai. Jika jendela lengkap bersifat penting (dengan asumsi tidak ada data yang terlambat), sebelum menghabiskan Pipeline A, biarkan kedua pipeline berjalan hingga Anda memiliki jendela yang tumpang-tindih sepenuhnya. Hentikan tugas streaming untuk Pipeline A setelah semua data yang beroperasi diproses dan ditulis ke Tabel A. Diagram berikut menunjukkan tahap ini.

   

4. Pada tahap ini, hanya Pipeline B yang berjalan. Anda dapat membuat kueri dari tampilan BigQuery (Façade View), yang berfungsi sebagai fasad untuk Tabel A dan Tabel B. Untuk baris yang memiliki stempel waktu yang sama di kedua tabel, konfigurasikan tampilan untuk menampilkan baris dari Tabel B, atau jika baris tidak ada di Tabel B, kembalikan ke Tabel A. Diagram berikut menunjukkan pembacaan (Façade View) dari Tabel A dan Tabel B.

   

   Pada tahap ini, Anda dapat menghapus Langganan A.

Saat masalah terdeteksi pada deployment pipeline baru, memiliki pipeline paralel dapat menyederhanakan rollback. Dalam contoh ini, Anda mungkin ingin Pipeline A tetap berjalan sambil memantau Pipeline B untuk operasi yang benar. Jika terjadi masalah pada Pipeline B, Anda dapat melakukan roll back ke Pipeline A.

Menangani mutasi skema

Sistem penanganan data sering kali perlu mengakomodasi mutasi skema dari waktu ke waktu, terkadang karena perubahan persyaratan bisnis dan waktu lainnya karena alasan teknis. Penerapan pembaruan skema biasanya memerlukan perencanaan dan pelaksanaan yang cermat untuk menghindari gangguan pada sistem informasi bisnis.

Pertimbangkan pipeline yang membaca pesan yang berisi payload JSON dari topik Pub/Sub. Pipeline mengonversi setiap pesan menjadi instance TableRow, lalu menulis baris ke tabel BigQuery. Skema tabel output mirip dengan pesan yang diproses oleh pipeline. Dalam diagram berikut, skema disebut sebagai Skema A.

Seiring waktu, skema pesan mungkin berubah dengan cara yang tidak umum. Misalnya, kolom ditambahkan, dihapus, atau diganti. Skema A berkembang menjadi skema baru. Dalam diskusi selanjutnya, skema baru disebut sebagai Skema B. Dalam hal ini, Pipeline A perlu diupdate, dan skema tabel output harus mendukung Skema B.

Untuk tabel output, Anda dapat melakukan beberapa mutasi skema tanpa pusat kota. Misalnya, Anda dapat menambahkan kolom baru atau menyesuaikan mode kolom, seperti mengubah REQUIRED menjadi NULLABLE, tanpa periode nonaktif. Mutasi ini biasanya tidak memengaruhi kueri yang ada. Namun, mutasi skema yang mengubah atau menghapus kolom skema yang ada akan merusak kueri atau menyebabkan gangguan lainnya. Pendekatan berikut mengakomodasi perubahan tanpa memerlukan periode nonaktif.

Pisahkan data yang ditulis oleh pipeline ke dalam tabel utama dan menjadi satu atau beberapa tabel staging. Tabel utama menyimpan data historis yang ditulis oleh pipeline. Tabel staging menyimpan output pipeline terbaru. Anda dapat menentukan tampilan fasad BigQuery terhadap tabel utama dan staging, yang memungkinkan konsumen mengkueri data historis dan terbaru.

Diagram berikut merevisi alur pipeline sebelumnya untuk menyertakan tabel staging (Tabel Staging A), tabel utama, dan tampilan fasad.

Pada alur yang direvisi, Pipeline A memproses pesan yang menggunakan Skema A dan menulis output ke Tabel Staging A, yang memiliki skema kompatibel. Tabel utama berisi data historis yang ditulis oleh pipeline versi sebelumnya, serta hasil yang digabungkan secara berkala dari tabel staging. Konsumen dapat membuat kueri data terbaru, termasuk data historis dan real-time, dengan menggunakan tampilan fasad.

Saat skema pesan berubah dari Skema A menjadi Skema B, Anda dapat memperbarui kode pipeline agar kompatibel dengan pesan yang menggunakan Skema B. Pipeline yang ada perlu diperbarui dengan implementasi baru. Dengan menjalankan pipeline paralel, Anda dapat memastikan bahwa pemrosesan data streaming berlanjut tanpa gangguan. Menghentikan dan mengganti pipeline akan mengakibatkan jeda pemrosesan, karena tidak ada pipeline yang berjalan selama periode waktu tertentu.

Pipeline yang telah diperbarui menulis ke tabel staging tambahan (Tabel Staging B) yang menggunakan Skema B. Anda dapat menggunakan alur kerja terorkestrasi untuk membuat tabel staging baru sebelum memperbarui pipeline. Perbarui tampilan fasad untuk menyertakan hasil dari tabel staging baru, yang kemungkinan menggunakan langkah alur kerja terkait.

Diagram berikut menunjukkan alur terbaru yang menunjukkan Tabel Staging B dengan Skema B dan cara tampilan fasad diperbarui untuk menyertakan konten dari tabel utama dan dari kedua tabel staging.

Sebagai proses yang terpisah dari pembaruan pipeline, Anda dapat menggabungkan tabel staging ke dalam tabel utama, baik secara berkala maupun sesuai kebutuhan. Diagram berikut menunjukkan cara Tabel Staging A digabungkan ke dalam tabel utama.

Langkah selanjutnya

• Temukan langkah-langkah mendetail untuk memperbarui pipeline yang ada.