Memecahkan masalah hambatan di Dataflow

Bottleneck terjadi saat satu langkah, tahap, atau pekerja memperlambat keseluruhan tugas. Hambatan dapat menyebabkan pekerja menganggur dan peningkatan latensi.

Jika Dataflow mendeteksi bottleneck, grafik tugas akan menampilkan pemberitahuan, dan panel Info Langkah akan mencantumkan jenis bottleneck dan penyebabnya, jika diketahui. Dataflow juga mengekspor informasi deteksi hambatan ke metrik Monitoring, yang menampilkan data sebagai deret waktu. Dengan begitu, Anda dapat melihat hambatan dari waktu ke waktu atau di masa lalu.

Memahami hambatan

Saat menjalankan pipeline streaming, tugas Dataflow terdiri dari serangkaian komponen, seperti pengacakan streaming, thread pemrosesan fungsi yang ditentukan pengguna (DoFn), dan pembuatan titik pemeriksaan status persisten. Untuk memfasilitasi aliran data, Dataflow menggunakan antrean untuk menghubungkan komponen ini. Data dikirim dari upstream ke downstream.

Di banyak pipeline, kapasitas throughput keseluruhan dibatasi oleh satu komponen, sehingga menciptakan hambatan dalam pipeline. Kecepatan data dapat melewati hambatan membatasi seberapa cepat pipeline dapat menerima dan memproses data input.

Misalnya, pertimbangkan pipeline tempat pemrosesan DoFn terjadi di hilir pengacakan streaming. Antrean di antara keduanya akan melakukan buffering data yang diacak, tetapi belum diproses. Jika pemrosesan DoFn tidak dapat menggunakan data secepat yang dihasilkan oleh pengacakan streaming, maka antrean akan bertambah. Hambatan yang berkepanjangan dapat menyebabkan antrean mencapai kapasitasnya. Pada saat itu, pengacakan lebih lanjut akan dijeda, dan backlog akan diteruskan ke upstream. Antrean di hulu juga mengakumulasi backlog, yang pada akhirnya menyebabkan pelambatan yang meluas ke sumber data, yang berarti seluruh pipeline tidak dapat mengimbangi input.

Saat terjadi hambatan, sebagian besar pipeline mungkin tampak tidak responsif, meskipun hanya satu titik di pipeline yang menyebabkan backlog. Perilaku ini dapat menyulitkan proses men-debug hambatan. Tujuan deteksi hambatan adalah mengidentifikasi lokasi dan penyebab yang tepat, sehingga tidak perlu menebak-nebak, agar Anda dapat memperbaiki akar masalahnya.

Dataflow mendeteksi hambatan saat penundaan melebihi nilai minimum lima menit. Jika penundaan tidak melampaui nilai minimum ini, Dataflow tidak mendeteksi hambatan.

Deteksi hambatan tidak selalu mengharuskan Anda bertindak dan bergantung pada kasus penggunaan Anda. Pipeline dapat beroperasi secara normal dengan penundaan sementara lebih dari lima menit. Jika hal ini dapat diterima untuk kasus penggunaan Anda, Anda mungkin tidak perlu menyelesaikan kemacetan yang ditunjukkan.

Jenis hambatan

Saat Dataflow mendeteksi hambatan, antarmuka pemantauan menunjukkan tingkat keparahan masalah. Hambatan dibagi dalam kategori berikut:

Pemrosesan macet dan tidak ada kemajuan
Progres pipeline dihentikan sepenuhnya pada langkah ini.
Pemrosesan sedang berlangsung, tetapi tertinggal.
Pipeline tidak dapat memproses data yang masuk secepat saat data tersebut tiba. Akibatnya, backlog meningkat.
Pemrosesan sedang berlangsung, tetapi backlog tetap stabil
Pipeline sedang berjalan, dan kecepatan pemrosesan sebanding dengan kecepatan input. Pemrosesan cukup cepat sehingga backlog tidak bertambah, tetapi backlog yang terakumulasi juga tidak berkurang secara signifikan.
Pemrosesan sedang berlangsung dan mengejar ketertinggalan dari backlog
Backlog berkurang, tetapi hambatan saat ini mencegah pipeline mengejar ketinggalan lebih cepat. Jika Anda memulai pipeline dengan backlog, status ini mungkin normal dan tidak memerlukan intervensi apa pun. Pantau progres untuk melihat apakah backlog terus berkurang.

Penyebab hambatan

Bagian ini mencantumkan penyebab hambatan yang dapat dideteksi. Gunakan informasi ini untuk menyelesaikan masalah. Dalam beberapa kasus, mungkin ada beberapa penyebab, dan penyebab tersebut mungkin terkait. Misalnya, jika pekerja kurang disediakan, pemakaian vCPU mungkin tinggi. Penggunaan vCPU yang tinggi dapat menyebabkan operasi menjadi lambat, yang pada gilirannya dapat menyebabkan penundaan antrean yang lebih tinggi. Analisis kemungkinan penyebab dapat menampilkan semua ini sebagai penyebab keterbatasan.

Operasi dengan waktu pemrosesan yang lama

Beberapa operasi dalam komputasi ini memiliki waktu pemrosesan yang lama. Hal ini terjadi setiap kali paket input dikirim ke pekerja yang menjalankan DoFn dan waktu yang signifikan telah berlalu tanpa hasil tersedia.

Hal ini paling sering terjadi akibat satu operasi yang berjalan lama dalam kode pengguna. Masalah lain dapat muncul sebagai operasi waktu pemrosesan yang lama. Misalnya, error yang ditampilkan dan dicoba lagi di dalam DoFn, percobaan ulang dalam jangka waktu yang lama, atau error pada harness pekerja karena faktor seperti OOM dapat menyebabkan waktu pemrosesan yang lama ini.

Jika komputasi yang terpengaruh ada dalam kode pengguna, cari cara untuk mengoptimalkan kode atau membatasi waktu eksekusi. Untuk membantu proses debug, log pekerja menampilkan stack trace untuk setiap operasi yang macet selama lebih dari 5 menit.

Key commit terlalu besar

Lihat Pengecualian commit kunci terlalu besar.

Izin sink BigQuery ditolak

Error ini menunjukkan bahwa akun layanan yang menjalankan pipeline tidak memiliki izin yang diperlukan untuk menulis ke resource BigQuery.

Untuk memvalidasi masalah ini menggunakan log pekerja:

  1. Di konsol Google Cloud , buka halaman Detail tugas Dataflow.
  2. Di panel bawah, klik tab Logs, lalu pilih Worker Logs.
  3. Cari pesan error yang menunjukkan bahwa izin atau akses ditolak (misalnya, PERMISSION_DENIED, 403 Forbidden, Access Denied, atau actuallyForbidden).
  4. Periksa pesan log untuk mengidentifikasi set data atau tabel tujuan dan izin tertentu yang tidak ada (seperti bigquery.tables.updateData).

Untuk menyelesaikan masalah ini:

  • Pastikan akun layanan telah diberi peran BigQuery Data Editor (roles/bigquery.dataEditor) pada set data dan tabel tujuan.
  • Jika menulis lintas project, pastikan izin diberikan langsung ke akun layanan di project tujuan yang menghosting set data BigQuery, dan Kontrol Layanan VPC (jika diaktifkan) mengizinkan komunikasi antara kedua project.

Jika langkah-langkah ini tidak menyelesaikan masalah, lihat Peran dan izin bawaan BigQuery untuk mengidentifikasi dan memberikan izin terperinci yang tidak ada yang diperlukan untuk konfigurasi spesifik Anda.

Resource sink BigQuery habis

Error ini menunjukkan bahwa pipeline telah melampaui batas kuota BigQuery. Kemungkinan besar penyebabnya adalah kuota yang tidak mencukupi di project BigQuery tujuan untuk menangani volume data yang sedang ditulis.

Untuk memvalidasi masalah ini menggunakan log pekerja:

  1. Di konsol Google Cloud , buka halaman Detail tugas Dataflow.
  2. Di panel bawah, klik tab Logs, lalu pilih Worker Logs.
  3. Cari pesan error yang menunjukkan bahwa resource atau kuota telah habis atau batas kecepatan terlampaui (misalnya, RESOURCE_EXHAUSTED, 429 Too Many Requests, quotaExceeded, atau rateLimitExceeded).
  4. Periksa pesan log untuk mengonfirmasi operasi dan batas kuota mana yang terlampaui (misalnya, batas throughput atau koneksi AppendRows Storage Write API, atau batas kecepatan penyisipan streaming).

Untuk menyelesaikan masalah ini:

  • Tentukan implementasi sink BigQuery yang digunakan pipeline Anda (misalnya, Storage Write API atau streaming insert).
  • Tinjau penggunaan kuota BigQuery Anda di konsol Google Cloud . Cari secara khusus kuota yang terkait dengan jenis sink Anda, seperti koneksi serentak, throughput, atau baris streaming insert per detik.
  • Jika Anda terus-menerus mendekati atau melampaui batas ini, pertimbangkan untuk meminta penambahan kuota.

Jika langkah-langkah ini tidak mengidentifikasi batas spesifik yang terlampaui, lihat Memecahkan masalah error kuota dan batas untuk menyelidiki lebih lanjut.

Kegagalan RPC sink BigQuery

Error ini menunjukkan bahwa permintaan RPC dari pipeline ke BigQuery gagal. Kemungkinan penyebabnya meliputi masalah jaringan atau layanan sementara, payload permintaan yang tidak valid, ketidakcocokan skema, atau error karena waktu tunggu dan batas waktu terlampaui.

Untuk memvalidasi masalah ini menggunakan log pekerja:

  1. Di konsol Google Cloud , buka halaman Detail tugas Dataflow.
  2. Di panel bawah, klik tab Logs, lalu pilih Worker Logs.
  3. Cari pesan error atau pengecualian yang terkait dengan operasi penulisan BigQuery (misalnya, DEADLINE_EXCEEDED, UNAVAILABLE, INVALID_ARGUMENT, atau error validasi skema).
  4. Periksa pelacakan tumpukan dan pesan error untuk menentukan mode kegagalan spesifik yang ditampilkan oleh BigQuery API.

Untuk menyelesaikan masalah ini:

  • Setelah Anda mengidentifikasi pesan error atau kode status tertentu dalam log pekerja, lihat referensi pesan error BigQuery untuk mendapatkan panduan pemecahan masalah khusus untuk error tersebut.
  • Jika pipeline Anda menggunakan Storage Write API, lihat Penanganan error dalam dokumentasi API BigQuery Storage Write untuk mengetahui informasi tentang penanganan error penulisan dan streaming tertentu.
Waktu pemrosesan yang lama di semua operasi

Operasi dalam komputasi ini secara konsisten membutuhkan waktu yang lama, yang menunjukkan adanya masalah dalam DoFn yang diberikan pengguna.

Penyebab ini berbeda dengan Operasi waktu pemrosesan yang lama; jika penyebab tersebut memengaruhi beberapa operasi, penyebab ini menunjukkan bahwa semua operasi dalam komputasi ini terpengaruh.

Periksa log pekerja untuk mengetahui error, pengecualian, atau stack trace yang menunjukkan thread lambat atau macet. Jika Anda menggunakan Apache Beam SDK untuk Python, dan jika operasi secara inheren berjalan lama berdasarkan desain (misalnya, panggilan API eksternal yang lambat atau I/O latensi tinggi), pertimbangkan untuk menggunakan Async DoFn. Fitur ini dapat meningkatkan throughput dengan mencegah pemrosesan diblokir pada tugas yang berjalan lama ini.

Pembacaan status persisten lambat

Komputasi menghabiskan banyak waktu untuk membaca status persisten sebagai bagian dari eksekusi DoFn. Hal ini mungkin disebabkan oleh status persisten yang terlalu besar atau terlalu banyak pembacaan. Pertimbangkan untuk mengurangi ukuran status yang dipertahankan atau frekuensi pembacaan. Optimalkan pola akses status dengan menggabungkan beberapa operasi pembacaan status atau menggunakan status peta, bukan status nilai jika sesuai. Hal ini juga mungkin merupakan masalah sementara karena lambatnya status persisten yang mendasarinya.

Penulisan status persisten yang lambat

Komputasi menghabiskan banyak waktu untuk menulis status persisten selama penerapan hasil pemrosesan. Hal ini mungkin disebabkan oleh status persisten yang terlalu besar. Pertimbangkan untuk mengurangi ukuran status yang dipertahankan. Mengoptimalkan pola akses status dengan menggabungkan beberapa operasi penulisan status jika sesuai. Hal ini juga mungkin merupakan masalah sementara karena lambatnya status persisten yang mendasarinya.

Commit yang ditolak

Pemrosesan data tidak dapat dilakukan ke status persisten karena tidak valid. Hal ini biasanya disebabkan oleh terlampauinya salah satu batas operasional. Periksa log untuk mengetahui detail selengkapnya, atau hubungi dukungan.

Partisi sumber Apache Kafka tidak mencukupi

Komputasi sumber Apache Kafka memiliki partisi yang tidak memadai. Untuk mengatasi masalah ini, coba langkah-langkah berikut:

  • Tingkatkan jumlah partisi Kafka.
  • Sertakan pendistribusian ulang menggunakan .withRedistribute() saat mengonfigurasi pembacaan Kafka IO untuk memparalelkan data secara lebih efisien. Sertakan .withRedistributeNumKeys(N) dengan N > partitions untuk memberikan batas atas pada jumlah total kunci. Memiliki jumlah kunci yang terbatas memberikan efisiensi melalui penggabungan record.
  • Untuk meminimalkan biaya pengacakan pendistribusian ulang, gunakan .withOffsetDeduplication(). Mode ini meminimalkan jumlah data yang perlu dipertahankan sebagai bagian dari shuffle, sekaligus tetap menyediakan pemrosesan tepat satu kali.

Untuk mengetahui informasi selengkapnya, lihat Paralelisme di halaman Membaca dari Apache Kafka ke Dataflow.

Sumber Apache Kafka dengan Volume Besar Status yang Dipertahankan

Komputasi sumber Apache Kafka mendistribusikan ulang data dalam volume tinggi yang dapat menimbulkan latensi dan biaya yang tinggi. Untuk mengatasi masalah ini, coba langkah-langkah berikut:

  • Jika pemrosesan tepat satu kali diperlukan untuk pipeline, minimalkan biaya pengacakan pendistribusian ulang dengan memanfaatkan mode penghapusan duplikat offset. Mode ini meminimalkan jumlah data yang perlu dipertahankan sebagai bagian dari shuffle, sekaligus tetap menyediakan pemrosesan tepat satu kali.
  • Jika pemrosesan minimal sekali sudah cukup untuk pipeline, konfigurasi izinkan duplikat dapat diaktifkan.

Untuk mengetahui informasi selengkapnya, lihat Membaca dari Apache Kafka ke Dataflow.

Paralelisme sumber tidak memadai

Komputasi sumber memiliki paralelisme yang tidak memadai. Jika memungkinkan, tingkatkan paralelisasi dalam sumber. Jika Anda tidak dapat meningkatkan paralelisme dan tugas menggunakan mode minimal sekali, coba tambahkan transformasi Redistribute ke pipeline.

Tombol cepat atau paralelisme kunci yang tidak memadai

Tugas memiliki tombol cepat atau paralelisme kunci yang tidak memadai.

Untuk setiap kunci sharding, Dataflow memproses pesan secara berurutan. Saat Dataflow memproses batch pesan untuk kunci tertentu, pesan masuk lainnya untuk kunci tersebut akan diantrekan hingga batch saat ini selesai.

Jika Dataflow tidak dapat memproses kunci unik yang cukup secara paralel, hal ini dapat menyebabkan hambatan. Misalnya, data mungkin memiliki terlalu sedikit kunci yang berbeda, atau kunci tertentu mungkin terlalu banyak direpresentasikan dalam data ("kunci panas"). Untuk mengatasi masalah ini, ubah logika pipeline Anda untuk mendistribusikan ulang data. Misalnya, tambahkan sufiks acak ke kunci pengelompokan untuk memecah kunci aktif, dan gabungkan hasil dalam langkah berikutnya. Untuk mengetahui detail selengkapnya, lihat Memecahkan masalah tombol pintas.

vCPU yang kurang disediakan

Tugas tidak memiliki vCPU pekerja yang cukup. Situasi ini terjadi saat tugas sudah diskalakan ke maksimum, pemakaian vCPU tinggi, dan masih ada tumpukan tugas. Anda mungkin harus meningkatkan jumlah maksimum pekerja yang disediakan untuk tugas ini. Misalnya, Anda dapat meningkatkan jumlah ini dengan memperbarui rentang penskalaan otomatis. Atau, cari cara untuk mengurangi penggunaan vCPU dengan mengubah kode atau workload pipeline. Anda dapat menggunakan cloud profiler untuk mencari peluang pengoptimalan.

Penggunaan vCPU tinggi, menunggu peningkatan skala

Tugas memiliki pemakaian vCPU yang tinggi, tetapi masih ada ruang untuk meningkatkan skala. Kondisi ini kemungkinan bersifat sementara hingga peningkatan skala dapat terjadi. Anda dapat memantau penskalaan otomatis untuk melihat keputusan penskalaan otomatis. Jika kondisi ini berlanjut dalam waktu lama atau sering terjadi, Anda mungkin perlu mengubah konfigurasi penskalaan otomatis dengan menetapkan petunjuk pemanfaatan pekerja yang berbeda agar tugas dapat melakukan penskalaan ke atas secara lebih proaktif.

Beban vCPU yang tidak seimbang menyebabkan hambatan pada beberapa worker pencilan

Tugas memiliki vCPU pekerja yang cukup, tetapi beberapa pekerja menunjukkan penggunaan vCPU yang sangat tinggi. Hal ini sering kali disebabkan oleh distribusi tugas yang tidak merata. Kemungkinan penyebabnya meliputi partisi sumber yang dimuat secara tidak merata atau tombol pintas.

Untuk mengatasi masalah ini, coba langkah-langkah berikut:

  • Tentukan penyebab pemuatan yang tidak merata dan coba perbaiki. Misalnya, pastikan partisi sumber didistribusikan secara merata.
  • Jika memperbaiki beban yang tidak merata tidak memungkinkan, pertimbangkan untuk mengubah bentuk VM worker guna meningkatkan vCPU per-worker untuk menurunkan pemakaian puncak. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi vCPU per pekerja, lihat Mengonfigurasi VM pekerja Dataflow.
Masalah saat berkomunikasi dengan pekerja

Dataflow tidak dapat berkomunikasi dengan semua VM pekerja. Periksa status VM pekerja tugas. Kemungkinan penyebabnya meliputi:

  • Ada masalah saat menyediakan VM worker.
  • Kumpulan worker VM dihapus saat tugas sedang berjalan.
  • Masalah jaringan.
Sumber Pub/Sub mengalami error penarikan.

Terjadi error saat menarik dari sumber Pub/Sub. Pastikan topik dan langganan yang diperlukan ada, serta verifikasi kuota dan konfigurasi. Anda juga dapat memeriksa log untuk mengetahui error.

Sumber Pub/Sub memiliki paralelisme yang tidak memadai

Komputasi sumber Pub/Sub memiliki jumlah kunci Pub/Sub yang tidak memadai. Untuk menambah jumlah kunci, tetapkan opsi layanan num_pubsub_keys. Untuk mengetahui informasi selengkapnya, lihat Paralelisme sumber Pub/Sub.

Sumber Pub/Sub di-throttle karena alasan yang tidak diketahui

Komputasi sumber Pub/Sub di-throttle saat membaca dari Pub/Sub, karena alasan yang tidak diketahui. Masalah ini mungkin bersifat sementara. Periksa masalah konfigurasi Pub/Sub, izin IAM yang tidak ada, atau batas kuota. Namun, jika tidak ada area sebelumnya yang menjadi penyebab utama dan masalah berlanjut, hubungi dukungan.

Publikasi sink Pub/Sub lambat atau terhenti

Komputasi sink Pub/Sub lambat atau macet. Masalah ini mungkin disebabkan oleh masalah konfigurasi atau batas kuota.

Waktu antrean kerja yang tinggi

Usia kerja yang memenuhi syarat paling lama tinggi, karena banyaknya kunci dan kecepatan pemrosesan kunci. Dalam situasi ini, setiap operasi mungkin tidak berlangsung terlalu lama, tetapi penundaan antrean secara keseluruhan tinggi.

Dataflow menggunakan satu thread pemrosesan per kunci sharding, dan jumlah thread pemrosesan dibatasi. Penundaan antrean kira-kira sama dengan rasio kunci terhadap thread, dikalikan dengan latensi dalam thread untuk setiap paket pemrosesan untuk kunci:

(key count / total harness threads) * latency per bundle

Coba perbaikan berikut:

  • Menambah jumlah pekerja. Lihat Penskalaan otomatis streaming.
  • Tingkatkan jumlah thread harness pekerja. Tetapkan numberOfWorkerHarnessThreads / number_of_worker_harness_threads opsi pipeline.
  • Kurangi jumlah kunci.
  • Mengurangi latensi operasi.
Masalah sementara dengan backend Streaming Engine

Ada masalah konfigurasi atau operasional dengan backend Streaming Engine. Masalah ini mungkin bersifat sementara. Jika masalah berlanjut, hubungi dukungan.

Penyebab yang tidak dapat ditentukan

Penyebab keterlambatan tidak dapat ditentukan dengan pasti. Masalah ini mungkin bersifat sementara. Jika masalah berlanjut, hubungi dukungan.

Metrik hambatan

Metrik tugas berikut memberikan informasi tentang hambatan:

Langkah berikutnya