Dokumen ini menjelaskan cara meminimalkan dampak kegagalan tugas untuk pipeline batch besar. Kegagalan beban kerja yang besar sangat berdampak karena waktu dan uang yang diperlukan untuk memulihkan dan memperbaiki kegagalan ini. Mencoba kembali pipeline ini dari awal saat gagal akan menghabiskan banyak waktu dan uang.
Untuk mengurangi kegagalan pipeline batch yang mahal, ikuti panduan di halaman ini. Karena Anda tidak selalu dapat sepenuhnya menghindari elemen yang gagal dan kegagalan pipeline, teknik yang diberikan berfokus pada peningkatan ketahanan, pengurangan biaya kegagalan, dan mempermudah proses debug dan pemahaman kegagalan saat terjadi.
Untuk praktik terbaik pipeline yang umum, lihat Praktik terbaik pipeline Dataflow.
Menjalankan eksperimen kecil untuk tugas besar
Sebelum menjalankan tugas batch besar, jalankan satu atau beberapa tugas yang lebih kecil pada subset set data. Teknik ini dapat memberikan perkiraan biaya dan membantu menemukan titik potensi kegagalan.
Perkiraan biaya
Menjalankan eksperimen dapat memberikan estimasi nilai minimum dari total biaya untuk menjalankan tugas. Biasanya, penghitungan untuk biaya tugas adalah cost of test job*size(full dataset)/size(test dataset). Bergantung pada pipeline, biaya dapat diskalakan secara superlinear atau, lebih jarang, secara sublinear. Namun, langkah ini sering kali memberikan perkiraan kasar yang baik tentang biaya pekerjaan. Anda juga dapat mencoba berbagai ukuran input untuk mendapatkan estimasi yang lebih baik tentang skala biaya Anda. Gunakan informasi ini untuk memutuskan apakah akan melanjutkan dengan pipeline yang ada atau merancang ulang pipeline Anda untuk mengurangi biaya.
Menemukan titik kegagalan
Menjalankan eksperimen dapat mengekspos bug, potensi titik kegagalan, atau potensi masalah konfigurasi dan efisiensi. Anda juga dapat memeriksa metrik pipeline lainnya, seperti metrik berikut:
- Jika pipeline Anda menggunakan hampir semua memori yang tersedia, pipeline tersebut mungkin mengalami pengecualian kehabisan memori (OOM) dengan beban yang lebih tinggi atau dengan data yang sangat besar. Anda mungkin perlu menyediakan lebih banyak memori untuk tugas akhir guna menghindari error OOM ini.
- Jika pengalaman pipeline Anda mengalami penurunan throughput, periksa log pipeline Anda untuk mengetahui alasannya. Anda mungkin menemukan elemen yang macet atau bagian set data dengan performa yang sangat buruk. Anda dapat memproses titik data ini secara terpisah, atau Anda dapat menerapkan waktu tunggu saat memproses elemen. Untuk informasi selengkapnya, lihat bagian Waktu tunggu data mahal dalam dokumen ini.
- Jika pipeline Anda berperforma jauh lebih buruk pada tugas di Dataflow daripada secara lokal, periksa logika pipeline Anda untuk mengetahui alasannya. Misalnya, jika Anda mendapatkan throughput yang sama dengan delapan core di Dataflow seperti Anda dengan satu inti secara lokal, tugas mungkin terhambat akibat pertentangan resource. Jika Anda mendapati bahwa performa Anda lebih buruk dari yang diharapkan, pertimbangkan satu atau beberapa opsi berikut:
- Jalankan lebih banyak eksperimen dengan konfigurasi mesin atau software yang berbeda.
- Menguji secara lokal dengan beberapa core secara bersamaan.
- Periksa kode Anda untuk menemukan potensi bottleneck saat men-deploy dalam skala besar.
Jika pipeline Anda memiliki rekomendasi Dataflow, ikuti rekomendasi tersebut untuk meningkatkan performa.
Menggunakan antrean dead letter untuk menangani data buruk yang tidak terduga
Pipeline sering kali berhasil pada sebagian besar elemen input, tetapi gagal pada sebagian kecil input. Anda mungkin tidak mengalami masalah ini saat menjalankan eksperimen kecil, karena eksperimen ini hanya menguji subkumpulan input. Secara default, Dataflow mencoba kembali tugas yang gagal ini empat kali dalam mode batch dan jumlah yang tidak terbatas dalam mode streaming. Dalam mode batch, setelah mencapai batas percobaan ulang, seluruh tugas Anda akan gagal. Dalam mode streaming, streaming dapat terhenti tanpa batas waktu.
Di banyak tugas, Anda dapat mengecualikan elemen gagal ini dari pipeline dan menyelesaikan tugas lainnya dengan menggunakan antrean yang telah dihentikan pengirimannya (antrean pesan yang belum diproses). Antrean yang dihentikan pengiriman akan meneruskan kumpulan data yang gagal ke PCollection output terpisah, yang dapat Anda kelola secara terpisah dari output utama. Konfigurasi ini memungkinkan Anda mendesain kebijakan untuk kumpulan data ini. Misalnya, Anda dapat menulisnya ke Pub/Sub secara manual, memeriksa dan membersihkannya, lalu memproses ulang data.
Banyak transformasi Apache Beam menyertakan dukungan bawaan untuk antrean yang dihentikan pengirimannya. Di Java, Anda dapat mengaksesnya dengan objek ErrorHandler. Di Python, Anda dapat mengaksesnya menggunakan metode with_exception_handling. Beberapa transformasi memiliki cara khusus untuk menentukan antrean yang dihentikan pengirimannya, yang dapat Anda baca di dokumentasi untuk transformasi tersebut. Untuk informasi selengkapnya, lihat Menggunakan antrean huruf mati untuk penanganan error.
Untuk menentukan apakah tugas Anda memenuhi kriteria antrean yang dihentikan pengirimannya, lihat bagian Batasan dalam dokumen ini.
Batasan antrean yang dihentikan pengirimannya
Dalam skenario berikut, antrean pesan tidak terkirim mungkin tidak membantu:
- Pekerja penuh atau
DoFnkegagalan siklus proses. Jika pemrosesan gagal untuk seluruh pekerja atau paket, antrean yang dihentikan pengirimannya tidak akan dapat menangkap kegagalan. Misalnya, jika pipeline Anda mengalami pengecualian kehabisan memori (OOM), semua tugas aktif di VM akan gagal dan dicoba ulang, tanpa mengirim apa pun ke antrean surat tidak terkirim. - Menggabungkan atau agregasi lainnya. Jika pipeline Anda melakukan komputasi yang mengharuskan semua elemen input ada dan diproses sebagai bagian dari hasilnya, berhati-hatilah saat menggunakan antrean pesan tidak terkirim sebelum langkah ini. Penggunaan antrean huruf mati akan mengecualikan bagian data input Anda dari hasil. Menambahkan antrean yang dihentikan pengiriman dapat menukar ketepatan dengan toleransi kesalahan.
- Kegagalan di jalur antrean yang dihentikan pengirimannya. Jika elemen gagal saat dikirim ke sink antrean pesan yang mati, seluruh pipeline dapat gagal. Untuk menghindari kegagalan ini, buat logika antrean pesan tidak terkirim Anda sedasar mungkin. Anda dapat menambahkan langkah tunggu (lihat
wait class) untuk memastikan input utama selesai sebelum menulis elemen antrean surat mati. Konfigurasi ini dapat mengurangi performa dan menunda sinyal error dari pipeline Anda. - Elemen yang ditransformasi sebagian. Jika Anda memasukkan bagian antrean yang dihentikan pengirimannya di sepanjang pipeline, antrean yang dihentikan pengirimannya mungkin menghasilkan elemen yang diubah sebagian dan tidak memiliki akses ke elemen asli. Akibatnya, Anda tidak dapat membersihkan elemen dan menjalankan ulang pipeline terhadap elemen tersebut. Sebagai gantinya, Anda mungkin perlu menerapkan logika yang berbeda untuk mengaitkan output dalam antrean dead-letter ke elemen asli, atau Anda mungkin perlu menafsirkan dan memproses elemen yang ditransformasi sebagian. Hal ini juga mungkin mengakibatkan hasil yang tidak konsisten. Misalnya, jika elemen dikirim ke dua cabang pipeline, dan setiap cabang mengirim elemen penyebab pengecualian ke antrean surat tidak terkirim, satu elemen input mungkin akan dikirim ke salah satu, kedua, atau tidak satu pun cabang.
Waktu tunggu data yang mahal
Pipeline mungkin berhenti merespons saat memproses sebagian kecil elemen yang lebih mahal atau yang mencapai batasan yang menyebabkan tidak responsif, seperti deadlock. Untuk mengurangi masalah ini, beberapa transformasi memungkinkan Anda menetapkan waktu tunggu dan membuat elemen yang habis waktu tunggu gagal di DoFn kode pengguna yang mengalami masalah ini. Misalnya, Anda dapat menggunakan metode with_exception_handling Python. Saat Anda menggunakan waktu tunggu dengan antrean yang dihentikan pengirimannya, pipeline Anda dapat terus memproses elemen yang responsif dan membuat progres, serta Anda dapat memproses ulang elemen yang mahal secara terpisah. Konfigurasi ini dapat menimbulkan biaya performa.
Untuk menentukan operasi DoFn yang cenderung memerlukan waktu tunggu, jalankan eksperimen kecil sebelum meluncurkan pipeline lengkap Anda.
Aktifkan Penskalaan Otomatis Vertikal
Jika Anda tidak yakin berapa banyak memori yang dibutuhkan tugas atau merasa tugas Anda berisiko kehabisan memori, aktifkan Penskalaan Otomatis Vertikal. Fitur ini membantu menghindari kegagalan OOM saat pipeline berjalan dalam skala yang lebih besar atau saat menemukan elemen yang sangat besar.
Karena Penskalaan Otomatis Vertikal dapat meningkatkan biaya tugas Anda dan tidak mencegah semua kegagalan kehabisan memori, Anda tetap perlu mengatasi masalah konsumsi memori yang berlebihan. Penskalaan Otomatis Vertikal juga memerlukan Dataflow Prime, yang memiliki batasan tambahan dan model penagihan yang berbeda.
Solusi untuk pipeline yang rentan kegagalan
Beberapa pipeline sangat rentan terhadap error. Meskipun lebih baik untuk mengatasi sumber error ini, pertimbangkan opsi berikut untuk mengurangi biaya kegagalan.
Mewujudkan hasil menengah
Pipeline mungkin memiliki satu atau beberapa transformasi yang sangat mahal yang mendominasi waktu eksekusi pipeline. Kegagalan pipeline setelah transformasi ini dapat sangat berbahaya, karena semua pekerjaan yang telah selesai akan hilang. Untuk menghindari skenario ini, sebaiknya tulis PCollections perantara yang dihasilkan oleh langkah-langkah yang mahal ke sink seperti Cloud Storage. Konfigurasi ini mengurangi biaya kegagalan. Anda perlu mempertimbangkan keuntungan ini dengan biaya untuk melakukan operasi tulis tambahan. Anda dapat menggunakan hasil yang diwujudkan ini dengan salah satu cara berikut:
- Pisahkan pipeline asli Anda menjadi dua pipeline: satu yang menulis hasil perantara dan satu lagi yang membacanya.
- Hanya jika terjadi kegagalan pipeline, baca dan ratakan hasil dari sumber asli dan koleksi perantara terwujud Anda.
Untuk memastikan bahwa materialisasi ini ditulis sebelum pemrosesan lebih lanjut, tambahkan langkah tunggu (lihat wait class) sebelum langkah pemrosesan berikutnya.