Dokumen ini menjelaskan cara meminimalkan dampak kegagalan tugas untuk pipeline batch besar. Kegagalan beban kerja besar sangat berdampak karena waktu dan uang yang diperlukan untuk memulihkan dan memperbaiki kegagalan ini. Mencoba lagi pipeline ini dari awal saat gagal akan mahal dari segi waktu dan biaya.
Untuk mengurangi kegagalan pipeline batch yang mahal, ikuti panduan di halaman ini. Karena Anda tidak selalu dapat menghindari kegagalan elemen dan kegagalan pipeline sepenuhnya, teknik yang diberikan berfokus pada peningkatan ketahanan, pengurangan biaya kegagalan, dan mempermudah proses men-debug dan memahami 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 perkiraan biaya dan membantu menemukan potensi titik kegagalan.
Perkiraan biaya
Menjalankan eksperimen dapat memberikan perkiraan batas bawah total biaya menjalankan
tugas. Biasanya, penghitungan 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 perkiraan kasar yang baik tentang biaya tugas. Anda juga dapat mencoba berbagai ukuran input untuk mendapatkan perkiraan yang lebih baik tentang skala biaya Anda. Gunakan informasi ini untuk memutuskan apakah akan melanjutkan pipeline yang ada atau merancang ulang pipeline untuk mengurangi biaya.
Menemukan titik kegagalan
Menjalankan eksperimen dapat memunculkan 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) saat beban lebih tinggi atau dengan rekaman yang sangat besar. Anda mungkin perlu menyediakan lebih banyak memori untuk tugas akhir guna menghindari error OOM ini.
- Jika pipeline Anda mengalami penurunan throughput, periksa log pipeline Anda untuk menentukan 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 batas waktu saat memproses elemen. Untuk informasi selengkapnya, lihat bagian Menghentikan sementara rekaman yang mahal dalam dokumen ini.
- Jika pipeline Anda berperforma jauh lebih buruk pada tugas di Dataflow daripada di 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 hambatan karena persaingan untuk mendapatkan 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.
- Uji secara lokal dengan beberapa core secara bersamaan.
- Periksa kode Anda untuk menemukan potensi hambatan saat men-deploy dalam skala besar.
Jika pipeline Anda memiliki rekomendasi Dataflow, ikuti rekomendasi tersebut untuk meningkatkan performa.
Menggunakan antrean pesan yang tidak terkirim 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 kecil input. Secara default, Dataflow mencoba ulang tugas yang gagal ini sebanyak empat kali dalam mode batch dan berkali-kali tanpa batas dalam mode streaming. Dalam mode batch, setelah mencapai batas percobaan ulang, seluruh tugas Anda akan gagal. Dalam mode streaming, aplikasi dapat terhenti tanpa batas.
Dalam banyak tugas, Anda dapat mengecualikan elemen yang gagal ini dari pipeline dan menyelesaikan tugas lainnya menggunakan antrean pesan yang tidak diproses (antrean pesan yang tidak diproses). Antrean pesan yang tidak terkirim meneruskan rekaman yang gagal ke output PCollection 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 pesan yang tidak terkirim.
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 transformasi. Untuk mengetahui informasi selengkapnya, lihat Menggunakan antrean pesan yang tidak terkirim untuk penanganan error.
Untuk menentukan apakah tugas Anda memenuhi kriteria untuk antrean pesan yang tidak terkirim, lihat bagian Batasan dalam dokumen ini.
Batasan antrean pesan yang tidak terkirim
Dalam skenario berikut, antrean pesan yang tidak terkirim mungkin tidak berguna:
- Kegagalan siklus proses pekerja penuh atau
DoFn. Jika pemrosesan gagal untuk seluruh worker atau bundle, antrean pesan yang tidak diproses tidak dapat menangkap kegagalan tersebut. Misalnya, jika pipeline Anda mengalami pengecualian kehabisan memori (OOM), semua tugas aktif di VM akan gagal dan dicoba lagi, tanpa mengirim apa pun ke antrean pesan yang tidak terkirim. - Gabungan atau agregasi lainnya. Jika pipeline Anda melakukan komputasi yang memerlukan semua elemen input untuk ada dan diproses sebagai bagian dari hasil, berhati-hatilah saat menggunakan antrean pesan yang tidak terkirim sebelum langkah ini. Menggunakan antrean pesan yang tidak terkirim akan mengecualikan sebagian data input Anda dari hasil. Menambahkan antrean pesan yang tidak terkirim dapat mengorbankan kebenaran demi toleransi kesalahan.
- Kegagalan di jalur antrean pesan yang dihentikan pengirimannya. Jika elemen gagal
saat dikirim ke sink antrean pesan yang tidak terkirim, 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 Anda selesai sebelum menulis elemen antrean pesan yang tidak terkirim. Konfigurasi ini dapat mengurangi performa dan menunda sinyal error dari pipeline Anda. - Elemen yang sebagian diubah. Jika Anda menyisipkan antrean pesan yang dihentikan pengirimannya di tengah pipeline, antrean pesan yang dihentikan pengirimannya dapat menghasilkan elemen yang sebagian diubah dan tidak memiliki akses ke elemen asli. Akibatnya, Anda tidak dapat membersihkan elemen dan menjalankan kembali pipeline terhadapnya. Sebagai gantinya, Anda mungkin perlu menerapkan logika yang berbeda untuk mengorelasikan output dalam antrean pesan yang tidak terkirim dengan elemen asli, atau Anda mungkin perlu menafsirkan dan memproses elemen yang sebagian diubah. Hal ini juga dapat menyebabkan hasil yang tidak konsisten. Misalnya, jika elemen dikirim ke dua cabang pipeline, dan setiap cabang mengirim elemen yang menyebabkan pengecualian ke antrean pesan yang tidak terkirim, satu elemen input dapat masuk ke salah satu, yang lain, keduanya, atau tidak satu pun dari cabang.
Menghentikan sementara rekaman yang mahal
Pipeline mungkin berhenti merespons saat memproses sebagian kecil elemen yang
lebih mahal atau yang mencapai batasan yang menyebabkan tidak responsif, seperti
kebuntuan. Untuk memitigasi masalah ini, beberapa transformasi memungkinkan Anda menetapkan waktu tunggu dan membuat elemen yang waktunya habis 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 pesan yang tidak terkirim, pipeline Anda dapat terus memproses elemen
yang berfungsi dengan baik dan membuat progres, serta Anda dapat memproses ulang elemen yang mahal
secara terpisah. Konfigurasi ini dapat menimbulkan biaya performa.
Untuk menentukan operasi DoFn mana yang kemungkinan akan memerlukan waktu tunggu, jalankan eksperimen kecil sebelum meluncurkan pipeline lengkap Anda.
Mengaktifkan Penskalaan Otomatis Vertikal
Jika Anda tidak yakin berapa banyak memori yang dibutuhkan tugas Anda atau berpikir 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 pipeline 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.
Menggunakan eksekusi spekulatif untuk menghindari proses yang lambat
Untuk pipeline batch, Anda dapat mengaktifkan eksekusi spekulatif, sebuah fitur untuk meminimalkan dampak tugas yang berjalan lambat atau macet. Tugas yang lambat atau macet ini juga dikenal sebagai straggler. Fitur ini meluncurkan eksekusi tugas yang berlebihan, atau cadangan, yang berjalan terlalu lama. Tugas pertama yang selesai digunakan, dan tugas lainnya dibatalkan, yang dapat meningkatkan waktu penyelesaian keseluruhan pipeline Anda.
Eksekusi spekulatif dapat membantu menyelesaikan pipeline lebih cepat dengan menyediakan jalur eksekusi alternatif untuk item kerja yang mengalami keterlambatan karena mesin pekerja yang lambat atau masalah sementara lainnya seperti bug non-deterministik, pembatasan resource, atau masalah konektivitas.
Batasan dan pertimbangan
Sebelum mengaktifkan eksekusi spekulatif, pertimbangkan hal berikut:
- Pipeline streaming: Eksekusi spekulatif tidak didukung untuk pipeline streaming.
- Potensi perubahan biaya: Dampak biaya fitur ini sulit diperkirakan karena sulit untuk memprediksi tugas yang tertinggal dan penyediaan tugas cadangan. Misalnya, meskipun item kerja cadangan menggunakan resource tambahan, yang berpotensi meningkatkan biaya, penyelesaiannya yang lebih awal justru dapat menghemat resource dan mengurangi biaya. Dalam kedua skenario tersebut, dampak keseluruhan diperkirakan minimal.
- Item kerja yang berjalan lama dan konsisten: Eksekusi spekulatif mungkin tidak membantu secara signifikan item kerja yang berjalan lama dan konsisten seperti tombol pintas, karena masalah mendasar yang menyebabkan kelambatan akan tetap ada.
Untuk mengetahui informasi selengkapnya tentang straggler dalam tugas batch, lihat Memecahkan masalah straggler dalam tugas batch.
Mengaktifkan eksekusi spekulatif
Untuk mengaktifkan eksekusi spekulatif, gunakan opsi layanan Dataflow map_task_backup_mode. Tersedia dua mode:
Java
--dataflowServiceOptions=map_task_backup_mode=ON--dataflowServiceOptions=map_task_backup_mode=CAUTIOUS
Python / Go
--dataflow_service_options=map_task_backup_mode=ON--dataflow_service_options=map_task_backup_mode=CAUTIOUS
Dalam mode ON, tugas cadangan dijadwalkan jika perkiraan waktu proses tugas asli
sekitar 20% lebih lama daripada perkiraan waktu proses tugas baru.
Dalam mode CAUTIOUS, tugas pencadangan dijadwalkan jika perkiraan
waktu proses tugas asli sekitar 70% lebih lama daripada perkiraan waktu proses tugas baru.
Untuk mengonfirmasi bahwa eksekusi spekulatif diaktifkan, periksa pesan log. Cari entri yang menunjukkan bahwa tugas pencadangan telah diluncurkan. Hal ini mengonfirmasi bahwa eksekusi spekulatif dipicu. Untuk melihat log ini, buka panel Job Logs untuk pipeline Anda (Jobs > pilih tugas > bagian Logs > Job logs). Pesan log akan muncul seperti berikut:
Backup issued in step STEP_NAME. ADDITIONAL_INFORMATION.
Solusi untuk pipeline yang rentan gagal
Beberapa pipeline sangat rentan terhadap error. Meskipun lebih baik mengatasi sumber error ini, untuk mengurangi biaya kegagalan, pertimbangkan opsi berikut.
Mewujudkan hasil sementara
Pipeline mungkin memiliki satu atau beberapa transformasi yang sangat mahal yang mendominasi
waktu eksekusi pipeline. Kegagalan pipeline setelah transformasi ini dapat sangat merugikan, karena semua tugas yang telah selesai akan hilang. Untuk menghindari skenario ini, pertimbangkan untuk menulis PCollections perantara yang dihasilkan oleh langkah-langkah mahal ke dalam sink seperti Cloud Storage. Konfigurasi ini mengurangi
biaya kegagalan. Anda perlu mempertimbangkan keunggulan ini dengan biaya
melakukan penulisan tambahan. Anda dapat menggunakan hasil yang diwujudkan ini dengan salah satu cara berikut:
- Pisahkan pipeline asli Anda menjadi dua pipeline: satu yang menulis hasil sementara dan satu yang membacanya.
- Hanya jika pipeline gagal, baca dan ratakan hasil dari sumber asli dan kumpulan perantara yang diwujudkan.
Untuk memastikan bahwa materialisasi ini ditulis sebelum pemrosesan lebih lanjut, tambahkan
langkah tunggu (lihat wait
class)
sebelum langkah pemrosesan berikutnya.