Halaman ini memberikan panduan dan rekomendasi untuk mengupgrade pipeline streaming Anda. Misalnya, Anda mungkin perlu mengupgrade ke Apache Beam SDK versi yang lebih baru, atau Anda mungkin ingin mengupdate kode pipeline. Opsi yang berbeda disediakan untuk menyesuaikan berbagai skenario.
Sementara pipeline batch berhenti saat tugas selesai, pipeline streaming sering kali berjalan terus-menerus untuk memberikan pemrosesan yang tidak terganggu. Oleh karena itu, saat mengupgrade pipeline streaming, Anda perlu mempertimbangkan hal-hal berikut:
- Anda mungkin perlu meminimalkan atau menghindari gangguan pada pipeline. Dalam beberapa kasus, Anda mungkin dapat mentoleransi gangguan sementara pada pemrosesan saat versi baru pipeline di-deploy. Dalam kasus lain, aplikasi Anda mungkin tidak dapat mentoleransi gangguan apa pun.
- Proses update pipeline perlu menangani perubahan skema dengan cara meminimalkan gangguan pada pemrosesan pesan dan sistem lain yang terpasang. Misalnya, jika skema untuk pesan dalam pipeline pemrosesan peristiwa berubah, perubahan skema mungkin juga diperlukan di sink data downstream.
Anda dapat menggunakan salah satu metode berikut untuk mengupdate pipeline streaming, bergantung pada pipeline dan persyaratan update Anda:
Untuk informasi selengkapnya tentang masalah yang mungkin Anda alami selama update dan cara mencegahnya, lihat 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 update tambahan.
- Upgrade versi Apache Beam SDK yang digunakan pipeline Anda secara rutin.
Melakukan update dalam penerbangan
Anda dapat memperbarui beberapa pipeline streaming yang sedang berlangsung tanpa menghentikan tugas. Skenario ini disebut pembaruan tugas yang sedang berlangsung. Pembaruan tugas saat berjalan hanya tersedia dalam situasi terbatas:
- Tugas harus menggunakan Streaming Engine.
- Tugas harus dalam status berjalan.
- Anda hanya mengubah jumlah pekerja yang digunakan tugas.
Untuk informasi selengkapnya, lihat Menetapkan rentang penskalaan otomatis di halaman Penskalaan Otomatis Horizontal.
Untuk petunjuk yang menjelaskan cara melakukan pembaruan tugas yang sedang berjalan, lihat Memperbarui pipeline yang ada.
Meluncurkan tugas pengganti
Jika tugas yang diperbarui kompatibel dengan tugas yang ada, Anda dapat memperbarui
pipeline menggunakan opsi update. Saat Anda mengganti tugas yang ada, tugas baru akan menjalankan kode pipeline yang diperbarui.
Layanan Dataflow mempertahankan nama tugas, tetapi menjalankan tugas penggantian
dengan ID Tugas yang diperbarui. Proses ini dapat menyebabkan periode nonaktif
saat tugas yang ada berhenti, pemeriksaan kompatibilitas berjalan, dan tugas baru
dimulai. Untuk mengetahui detail selengkapnya, lihat
Efek penggantian 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 saat 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 update pipeline tidak kompatibel dengan tugas saat ini, Anda harus menghentikan dan mengganti pipeline. Jika pipeline Anda tidak dapat mentoleransi periode nonaktif, jalankan pipeline paralel.
Menghentikan dan mengganti pipeline
Jika dapat menghentikan pemrosesan untuk sementara, Anda dapat membatalkan atau menguras pipeline, lalu menggantinya dengan pipeline yang diperbarui. Membatalkan pipeline akan menyebabkan Dataflow segera menghentikan pemrosesan dan menonaktifkan resource secepat mungkin, yang dapat menyebabkan beberapa data yang sedang diproses hilang, yang dikenal sebagai data dalam proses. Untuk menghindari kehilangan data, dalam sebagian besar kasus, pengosongan adalah tindakan yang lebih disukai. Anda juga dapat menggunakan snapshot Dataflow untuk menyimpan status pipeline streaming, yang memungkinkan Anda memulai versi baru tugas Dataflow tanpa kehilangan status. Untuk mengetahui informasi selengkapnya, lihat Menggunakan snapshot Dataflow.
Menguras pipeline akan segera menutup semua jendela dalam proses dan mengaktifkan semua pemicu. Meskipun data dalam pengiriman tidak hilang, pengosongan mungkin menyebabkan jendela memiliki data yang tidak lengkap. Jika hal ini terjadi, jendela dalam proses akan memunculkan hasil sebagian atau tidak lengkap. 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 beberapa 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, tidak terlalu rumit dibandingkan menjalankan pipeline paralel.
Untuk petunjuk yang lebih mendetail, lihat Menguras tugas Dataflow. Setelah Anda menghabiskan tugas saat ini, mulai tugas baru dengan nama tugas yang sama.
Pemrosesan ulang pesan dengan Snapshot dan Penelusuran Pub/Sub
Dalam beberapa situasi, setelah mengganti atau membatalkan pipeline yang habis, Anda mungkin perlu memproses ulang pesan Pub/Sub yang dikirim sebelumnya. Misalnya, Anda mungkin perlu menggunakan logika bisnis yang diperbarui untuk memproses ulang data. Penelusuran Pub/Sub adalah fitur yang memungkinkan Anda memutar ulang pesan dari snapshot Pub/Sub. Anda dapat menggunakan Penelusuran Pub/Sub dengan Dataflow untuk memproses ulang pesan sejak snapshot langganan dibuat.
Selama pengembangan dan pengujian, Anda juga dapat menggunakan Penelusuran Pub/Sub untuk memutar ulang pesan yang diketahui berulang kali guna memverifikasi output dari pipeline Anda. Saat Anda menggunakan Penelusuran Pub/Sub, jangan cari snapshot langganan saat langganan sedang digunakan oleh pipeline. Jika Anda melakukannya, pencarian dapat membatalkan logika watermark Dataflow dan dapat memengaruhi pemrosesan pesan Pub/Sub tepat satu kali.
Alur kerja gcloud CLI yang direkomendasikan untuk menggunakan Penelusuran Pub/Sub dengan pipeline Dataflow di jendela terminal adalah sebagai berikut:
Untuk membuat snapshot langganan, gunakan perintah
gcloud pubsub snapshots create:gcloud pubsub snapshots create SNAPSHOT_NAME --subscription=PIPELINE_SUBSCRIPTION_NAME
Untuk menghabiskan atau membatalkan pipeline, gunakan perintah
gcloud dataflow jobs drainatau perintahgcloud dataflow jobs cancel:gcloud dataflow jobs drain JOB_ID
atau
gcloud dataflow jobs cancel JOB_ID
Untuk mencari snapshot, gunakan perintah
gcloud pubsub subscriptions seek:gcloud pubsub subscriptions seek SNAPSHOT_NAME
Deploy pipeline baru yang menggunakan langganan.
Menjalankan pipeline paralel
Jika Anda perlu menghindari gangguan pada pipeline streaming selama update, jalankan pipeline paralel. Buat tugas streaming baru yang memiliki kode pipeline yang diperbarui, dan jalankan pipeline baru secara paralel dengan pipeline yang ada.
Saat membuat pipeline baru, gunakan strategi periode yang sama dengan yang Anda gunakan untuk pipeline yang ada. Biarkan pipeline yang ada terus berjalan hingga watermarknya melebihi stempel waktu jendela lengkap paling awal yang diproses oleh pipeline yang diperbarui. Kemudian, habiskan atau batalkan pipeline yang ada. Pipeline yang diperbarui akan terus berjalan di tempatnya dan secara efektif mengambilalih pemrosesan dengan sendirinya.
Diagram berikut menggambarkan proses ini.
Dalam diagram, Pipeline B adalah tugas yang diperbarui yang mengambil alih dari Pipeline A. Nilai t adalah stempel waktu jendela lengkap awal yang diproses oleh Pipeline B. Nilai w adalah watermark untuk Pipeline A. Untuk memudahkan, watermark yang sempurna diasumsikan tanpa data terlambat. Waktu pemrosesan dan waktu tunggu diwakili pada sumbu horizontal. Kedua pipeline menggunakan jendela tetap (tumbling) lima menit. Hasil dipicu setelah watermark melewati akhir setiap jendela.
Karena output serentak terjadi selama jangka waktu saat dua pipeline tumpang-tindih, konfigurasikan kedua pipeline untuk menulis hasil ke tujuan yang berbeda. Sistem downstream kemudian dapat menggunakan abstraksi atas dua sink tujuan, seperti tampilan database, untuk mengkueri hasil gabungan. Sistem ini juga dapat menggunakan abstraksi untuk menghapus duplikat hasil dari periode tumpang-tindih.
Contoh berikut menjelaskan pendekatan penggunaan pipeline yang membaca data input dari Pub/Sub, melakukan beberapa pemrosesan, dan menulis hasilnya ke BigQuery.
Dalam status awal, pipeline streaming yang ada (Pipeline A) berjalan dan membaca pesan dari topik Pub/Sub (Topic) menggunakan langganan (Subscription A). Hasilnya ditulis ke tabel BigQuery (Tabel A). Hasil digunakan melalui tampilan BigQuery, yang berfungsi sebagai fasad untuk menyamarkan perubahan tabel yang mendasarinya. Proses ini adalah penerapan metode desain yang disebut pola fasad. Diagram berikut menunjukkan status awal.
Buat langganan baru (Langganan B) untuk pipeline yang diperbarui. Deploy pipeline yang diperbarui (Pipeline B), yang membaca dari topik Pub/Sub (Topic) menggunakan Subscription B dan menulis ke tabel BigQuery terpisah (Table B). Diagram berikut mengilustrasikan alur ini.
Pada tahap ini, Pipeline A dan Pipeline B berjalan secara paralel dan menulis hasil ke tabel terpisah. Anda mencatat waktu t sebagai stempel waktu periode lengkap paling awal yang diproses oleh Pipeline B.
Jika stempel waktu Pipeline A melebihi waktu t, habiskan Pipeline A. Saat Anda menghabiskan pipeline, semua jendela yang terbuka akan ditutup, dan pemrosesan untuk data yang sedang diproses akan selesai. Jika pipeline berisi jendela dan jendela lengkap penting (dengan asumsi tidak ada data yang terlambat), sebelum menghabiskan Pipeline A, biarkan kedua pipeline berjalan hingga Anda menyelesaikan jendela yang tumpang-tindih. Hentikan tugas streaming untuk Pipeline A setelah semua data yang sedang diproses diproses dan ditulis ke Tabel A. Diagram berikut menunjukkan tahap ini.
Pada tahap ini, hanya Pipeline B yang berjalan. Anda dapat membuat kueri dari tampilan BigQuery (Tampilan Fasad), 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, kembali ke Tabel A. Diagram berikut menunjukkan tampilan (Tampilan Fasad) yang membaca dari Tabel A dan Tabel B.
Pada tahap ini, Anda dapat menghapus Langganan A.
Jika masalah terdeteksi dengan deployment pipeline baru, memiliki pipeline paralel dapat menyederhanakan rollback. Dalam contoh ini, Anda mungkin ingin terus menjalankan Pipeline A saat memantau Pipeline B untuk memastikan operasinya sudah benar. Jika terjadi masalah pada Pipeline B, Anda dapat melakukan rollback ke Pipeline A.
Batasan
Pendekatan ini memiliki batasan berikut:
- Menjalankan dua pipeline di input yang sama kemungkinan akan menghasilkan data duplikat di output. Sistem downstream harus mengetahui dan mampu mentoleransi data duplikat.
- Saat membaca dari sumber Pub/Sub, penggunaan langganan yang sama untuk beberapa pipeline tidak direkomendasikan dan dapat menyebabkan masalah kebenaran. Namun, dalam beberapa kasus penggunaan, seperti pipeline ekstrak, transformasi, muat (ETL), menggunakan langganan yang sama di dua pipeline dapat mengurangi duplikasi. Masalah terkait penskalaan otomatis mungkin terjadi dalam skenario ini, tetapi dapat dimitigasi dengan menggunakan fitur update tugas yang sedang berlangsung. Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan penskalaan otomatis untuk pipeline streaming Pub/Sub.
- Saat membaca dari sumber Pub/Sub, penggunaan langganan kedua akan menghasilkan duplikat, tetapi tidak menyebabkan masalah pada akurasi data dan penskalaan otomatis.
Menangani mutasi skema
Sistem penanganan data sering kali perlu mengakomodasi mutasi skema dari waktu ke waktu, terkadang karena perubahan persyaratan bisnis dan terkadang karena alasan teknis. Menerapkan update skema biasanya memerlukan perencanaan dan eksekusi 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 dapat bermutasi dengan cara yang tidak biasa. Misalnya, kolom ditambahkan, dihapus, atau diganti. Skema A berkembang menjadi skema baru. Dalam diskusi berikut, skema baru disebut sebagai Skema B. Dalam hal ini, Pipeline A perlu diperbarui, dan skema tabel output perlu mendukung Skema B.
Untuk tabel output, Anda dapat melakukan beberapa mutasi skema tanpa downtown.
Misalnya, Anda dapat menambahkan kolom baru atau melonggarkan
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 ke dalam 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 di atas tabel utama dan staging, yang memungkinkan konsumen membuat kueri data historis dan terbaru.
Diagram berikut merevisi alur pipeline sebelumnya untuk menyertakan tabel staging (Staging Table A), tabel utama, dan tampilan fasad.
Dalam alur yang direvisi, Pipeline A memproses pesan yang menggunakan Skema A dan menulis output ke Tabel Staging A, yang memiliki skema yang kompatibel. Tabel utama berisi data historis yang ditulis oleh versi pipeline 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 bermutasi 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 menyebabkan jeda pemrosesan, karena tidak ada pipeline yang berjalan selama periode waktu tertentu.
Pipeline yang diperbarui menulis ke tabel staging tambahan (Staging Table B) yang menggunakan Schema B. Anda dapat menggunakan alur kerja terkoordinasi untuk membuat tabel staging baru sebelum mengupdate pipeline. Perbarui tampilan fasad untuk menyertakan hasil dari tabel staging baru, yang mungkin menggunakan langkah alur kerja terkait.
Diagram berikut menunjukkan alur yang diperbarui yang menampilkan Tabel Staging B dengan Skema B dan cara tampilan fasad diperbarui untuk menyertakan konten dari tabel utama dan dari kedua tabel staging.
Sebagai proses terpisah dari update 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 mengupdate pipeline yang ada.