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 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 estimasi biaya dan membantu menemukan potensi titik kegagalan.
Perkiraan biaya
Menjalankan eksperimen dapat memberikan perkiraan minimum 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, sublinear. Namun, langkah ini sering kali memberikan estimasi 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 pipeline yang ada atau mendesain ulang pipeline 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 throughput pipeline Anda mengalami penurunan, periksa log pipeline untuk mengetahui penyebabnya. 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 Menonaktifkan data yang mahal karena waktu tunggu habis 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 yang Anda dapatkan dengan satu core secara lokal, tugas mungkin mengalami bottleneck pada pertentangan untuk 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 berhasil pada sebagian besar elemen input, tetapi gagal pada sebagian kecil input. Anda mungkin tidak menemukan masalah ini saat menjalankan eksperimen kecil, karena eksperimen ini hanya menguji sebagian input. Secara default, Dataflow akan mencoba ulang tugas yang gagal ini empat kali dalam mode batch dan tanpa batas dalam mode streaming. Dalam mode batch, setelah mencapai batas percobaan ulang, seluruh tugas Anda akan gagal. Dalam mode streaming, proses ini dapat terhenti tanpa batas waktu.
Dalam banyak tugas, Anda dapat mengecualikan elemen yang gagal ini dari pipeline dan menyelesaikan tugas lainnya menggunakan antrean dead-letter (antrean pesan yang tidak diproses). Antrean surat tidak terkirim meneruskan data yang gagal ke PCollection output terpisah, yang dapat Anda kelola secara terpisah dari output utama. Konfigurasi ini memungkinkan Anda mendesain kebijakan untuk 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 surat mati. 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 pesan yang tidak terkirim, yang dapat Anda baca dalam dokumentasi untuk transformasi tersebut. Untuk informasi selengkapnya, lihat Menggunakan antrean surat mati untuk penanganan error.
Untuk menentukan apakah tugas Anda memenuhi kriteria untuk antrean surat tidak terkirim, lihat bagian Batasan dalam dokumen ini.
Batasan antrean surat tidak terkirim
Dalam skenario berikut, antrean pesan yang tidak terkirim mungkin tidak membantu:
- Kegagalan siklus proses pekerja penuh atau
DoFn. Jika pemrosesan gagal untuk seluruh pekerja atau paket, antrean surat mati tidak dapat mendeteksi kegagalan tersebut. 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 mati. - 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 surat mati sebelum langkah ini. Penggunaan antrean pesan yang tidak terkirim akan mengecualikan sebagian data input Anda dari hasil. Menambahkan antrean dead-letter dapat mengorbankan akurasi untuk fault tolerance.
- Kegagalan pada jalur antrean pesan yang dihentikan pengirimannya. Jika elemen gagal saat dikirim ke sink antrean pesan mati, seluruh pipeline dapat gagal. Untuk menghindari kegagalan ini, buat logika antrean pesan yang tidak terkirim sesederhana 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 menyisipkan antrean dead letter di bagian pipeline, antrean dead letter mungkin menghasilkan elemen yang ditransformasi 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 surat tidak terkirim ke elemen asli, atau Anda mungkin perlu menafsirkan dan memproses elemen yang diubah sebagian. Hal ini juga dapat menyebabkan 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 untuk 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 dead letter, pipeline dapat terus memproses elemen yang sehat dan membuat progres, dan 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.
Mengaktifkan Penskalaan Otomatis Vertikal
Jika Anda tidak yakin berapa banyak memori yang diperlukan tugas Anda atau merasa bahwa 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 terhadap 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, pertimbangkan untuk menulis 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 pada kegagalan pipeline, baca dan ratakan hasil dari sumber asli dan koleksi perantara yang diwujudkan.
Untuk memastikan bahwa materialisasi ini ditulis sebelum pemrosesan lebih lanjut, tambahkan langkah tunggu (lihat wait class) sebelum langkah pemrosesan berikutnya.