排解工作執行緩慢或停滯的問題

本頁說明如何排解 Dataflow 串流和批次工作緩慢或停滯的常見原因。

串流

如果發現下列徵兆，表示 Dataflow 串流工作可能執行緩慢或停滯：

請參閱下列各節的資訊，找出並診斷問題。

找出根本原因

  1. 檢查資料更新間隔和待處理位元組指標。

    • 如果這兩項指標都單調遞增，表示管道卡住且沒有進展。
    • 如果資料新鮮度增加，但積壓位元組數維持正常，表示一或多個工作項目卡在管道中。

    找出這些指標增加的階段，判斷是否有問題的階段，以及該階段執行的作業。

  2. 查看「平行處理圖表」，確認是否有任何階段因平行處理量過多或過少而停滯。請參閱排解平行處理問題。

  3. 檢查工作記錄，確認是否有配額限制、缺貨或 IP 位址耗盡等問題。

  4. 檢查工作站記錄是否有警告和錯誤。

    • 如果工作站記錄檔含有錯誤，請查看堆疊追蹤記錄。調查錯誤是否是由程式碼中的錯誤所致。
    • 尋找 Dataflow 錯誤。請參閱「排解 Dataflow 錯誤」。
    • 找出顯示工作超出限制的錯誤，例如 Pub/Sub 訊息大小上限。
    • 尋找記憶體不足錯誤，這類錯誤可能會導致管道停滯。如果看到記憶體不足錯誤，請按照「排解 Dataflow 記憶體不足錯誤」一文中的步驟操作。
    • 如要找出緩慢或停滯的步驟，請檢查工作站記錄檔中的 Operation ongoing 訊息。查看堆疊追蹤，瞭解步驟耗費時間的位置。詳情請參閱「處理卡住或正在進行的作業」。

  5. 如果作業項目停滯在特定工作站，請重新啟動該工作站 VM。

  6. 如果未使用 Streaming Engine，請檢查 shuffler 記錄是否有警告和錯誤。如果通訊埠 12345 或 12346 顯示 RPC 逾時錯誤，表示工作可能缺少防火牆規則。請參閱「Dataflow 的防火牆規則」。

  7. 檢查快速鍵。

  8. 如果已啟用 Runner v2，請檢查安全防護記錄是否有錯誤。詳情請參閱「排解 Runner v2 問題」。

調查重複失敗情形

在串流工作中，系統會無限期重試某些失敗作業。這些重試作業會導致管道無法繼續執行。如要找出重複失敗的項目，請檢查工作人員記錄檔中的例外狀況。

  • 如果例外狀況與使用者程式碼有關，請偵錯並修正程式碼或資料中的問題。
  • 為避免非預期的故障導致管道停滯，請實作死信佇列。如需實作範例，請參閱 Apache Beam 說明文件中的 BigQuery 模式。
  • 如果例外狀況是記憶體不足 (OOM) 錯誤，請參閱排解 Dataflow 記憶體不足錯誤。
  • 如需其他例外狀況，請參閱「排解 Dataflow 錯誤」。

找出健康狀態不良的工作者

如果處理串流工作的工作站健康狀態不佳，工作可能會執行緩慢或停滯。如要找出健康狀態不良的工作者，請按照下列步驟操作：

找出進度落後項目

進度落後項目是指相較於階段中的其他工作項目，進度較慢的工作項目。如要瞭解如何找出並修正進度落後項目，請參閱排解串流工作中的進度落後項目。

排解平行處理問題

為提高擴充性和效率，Dataflow 會在多個工作站上平行執行管道的階段。Dataflow 中平行處理的最小單位是鍵。每個融合階段的傳入訊息都與一個鍵相關聯。金鑰的定義方式如下：

  • 鍵會由來源的屬性 (例如 Kafka 分區) 隱含定義。
  • 鍵是由管道中的匯總邏輯明確定義，例如 GroupByKey。

在 Dataflow 中，工作站執行緒負責處理鍵的工作 (訊息) 組合。可用於處理工作金鑰的執行緒數量等於 num_of_workers * threads_per_worker。每個工作站的執行緒數量取決於 SDK (Java、Python 或 Go) 和工作類型 (批次或串流)。

如果管道在特定階段的索引鍵不足，就會限制平行處理。該階段可能會成為瓶頸。

如果管道在特定階段使用大量鍵，可能會限制該階段的總處理量，並在上游階段累積待處理工作，因為每個鍵都有一些額外負荷。這類額外負擔可能包括後端與工作人員通訊、對 BigQuery 等接收器發出的外部 RPC，以及其他處理作業。舉例來說，如果處理一個訊息的金鑰需要 100 毫秒，處理該金鑰套件中的 1000 則訊息可能也需要 100 毫秒。

找出平行處理程度偏低的階段

如要判斷管道速度緩慢是否是由於平行處理程度不足所致，請查看 CPU 使用率指標。如果 CPU 使用率偏低，但工作站的 CPU 使用率平均，則工作可能平行處理量不足。如果工作使用 Streaming Engine，請在「工作指標」分頁中查看平行處理指標，瞭解階段的平行處理程度是否偏低。如要解決這個問題，請採取下列行動：

  • 在 Google Cloud 控制台的「工作資訊」頁面，使用「自動調度資源」分頁，查看工作是否無法擴充。如果問題與自動調度資源有關，請參閱「排解 Dataflow 自動調度資源問題」。
  • 使用作業圖表檢查階段中的步驟。如果階段是從來源讀取資料或寫入接收器，請參閱來源或接收器服務的說明文件。請參閱說明文件，確認該服務是否已設定足夠的擴充性。

找出平行處理程度高的階段

如果系統延遲時間較短、資料更新間隔逐漸縮短，且待處理工作數量增加，但工作站 CPU 使用率偏低，表示管道因金鑰數量過多而受到節流。查看平行處理圖表，找出含有大量索引鍵的階段。

如果您未明確指定 withNumBuckets，Reshuffle 等轉換可能會產生數百萬個金鑰。大量索引鍵可能會導致建立許多較小的工作套件，每個套件都需要專屬的工作執行緒來處理。由於可用的工作站執行緒有限，這可能會導致大量待處理的處理鍵，造成資源等待延遲。因此，工作執行緒無法有效運用。

建議您在 Reshuffle 轉換中設定 withNumBuckets 選項，限制鍵的數量。這個值不得超過所有工作站的執行緒總數。管道中的指定目標(threads_per_worker * max_workers)鍵可能不是最佳選擇。有時可以減少鍵的數量並擴大組合，這樣一來，由於使用的工作站較少，Dataflow 處理作業的效率會更高。較少的鍵會建立較大的工作套件，有效運用工作執行緒並提高階段的輸送量。

如果管道中有多個 Reshuffle 步驟，請將執行緒總數除以 Reshuffle 步驟數，計算 withNumBuckets。

檢查熱鍵

如果工作在工作站間的分配不均，且工作站使用率差異很大，管道可能會有熱鍵。熱鍵是指需要處理的元素數量遠多於其他鍵的鍵。

使用下列記錄篩選器檢查快速鍵：

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

將 JOB_ID 替換為工作 ID。

如要解決這個問題，請採取下列一或多項做法：

  • 重新輸入資料。如要輸出新的鍵/值組合，請套用 ParDo 轉換。 詳情請參閱 Apache Beam 說明文件中的 Java ParDo 轉換頁面或 Python ParDo 轉換頁面。
  • 在合併轉換中使用 .withFanout。詳情請參閱 Java SDK 中的 Combine.PerKey 類別，或 Python SDK 中的 with_hot_key_fanout 作業。
  • 如果 Java 管道處理大量不受限的 PCollections，建議您採取下列做法：
    • 使用 Combine.Globally.withFanout，而不要使用 Combine.Globally。
    • 使用 Combine.PerKey.withHotKeyFanout，而不要使用 Count.PerKey。

檢查配額是否不足

請確認來源和接收器有足夠的配額。舉例來說，如果管道從 Pub/Sub 或 BigQuery 讀取輸入，專案的配額可能不足。 Google Cloud 如要進一步瞭解這些服務的配額限制，請參閱 Pub/Sub 配額或 BigQuery 配額。

如果工作產生大量 429 (Rate Limit Exceeded) 錯誤，可能是配額不足。如要檢查是否有錯誤，請嘗試下列步驟：

  1. 前往Google Cloud 控制台。
  2. 在導覽窗格中，按一下「API 和服務」。
  3. 按一下選單中的「媒體庫」。
  4. 使用搜尋方塊搜尋「Pub/Sub」。
  5. 按一下「Cloud Pub/Sub API」。
  6. 點選「管理」。
  7. 在「依回應碼區別的流量」圖表中，尋找 (4xx) 用戶端錯誤代碼。

您也可以使用 Metrics Explorer 檢查配額用量。如果管道使用 BigQuery 來源或接收器，請使用 BigQuery Storage API 指標，排解配額問題。舉例來說，如要建立圖表，顯示 BigQuery 同時連線計數，請按照下列步驟操作：

  1. 在 Google Cloud 控制台中選取「Monitoring」：

    前往「Monitoring」頁面

  2. 在導覽窗格中，選取「指標探索器」。

  3. 在「選取指標」窗格中，針對「指標」，依序篩選「BigQuery 專案」 >「寫入」 >「並行連線計數」。

如需查看 Pub/Sub 指標的操作說明，請參閱「在 Cloud Monitoring 中監控 Pub/Sub」一文的「監控配額使用量」一節。如需查看 BigQuery 指標的操作說明，請參閱「建立資訊主頁、圖表和快訊」一文中的「查看配額用量和限制」。

批次

如果批次工作執行緩慢或停滯，請使用「執行詳細資料」分頁標籤，進一步瞭解工作，並找出造成瓶頸的階段或工作人員。

找出根本原因

  1. 檢查工作是否在啟動工作站時發生問題。詳情請參閱「無法同步處理 Pod」。

    如要確認工作已開始處理資料，請在 job-message 記錄檔中尋找下列記錄檔項目：

    All workers have finished the startup processes and began to receive work requests

  2. 如要比較不同工作的效能，請確保輸入資料量、工作站設定、自動調度資源行為和 Dataflow Shuffle 設定都相同。

  3. 檢查 job-message 記錄，確認是否有配額限制、缺貨問題或 IP 位址耗盡等問題。

  4. 在「執行詳細資料」分頁中，比較階段進度，找出耗時較長的階段。

  5. 找出工作中的任何落後者。詳情請參閱「排解批次作業中落後的問題」。

  6. 檢查處理量、CPU 和記憶體用量指標。

  7. 查看工作站記錄中的警告和錯誤。

    • 如果工作站記錄檔含有錯誤，請查看堆疊追蹤記錄。調查錯誤是否是由程式碼中的錯誤所致。
    • 尋找 Dataflow 錯誤。請參閱「排解 Dataflow 錯誤」。
    • 尋找記憶體不足錯誤，這類錯誤可能會導致管道停滯。如果看到記憶體不足錯誤，請按照「排解 Dataflow 記憶體不足錯誤」一文的步驟操作。
    • 如要找出緩慢或停滯的步驟，請檢查工作站記錄檔中的 Operation ongoing 訊息。查看堆疊追蹤，瞭解步驟耗費時間的位置。詳情請參閱「處理卡住或正在進行的作業」。

  8. 檢查快速鍵。

  9. 如果未使用 Dataflow Shuffle，請檢查 Shuffler 記錄檔，瞭解 Shuffle 作業期間的警告和錯誤。如果通訊埠 12345 或 12346 顯示 RPC 逾時錯誤，表示工作可能缺少防火牆規則。請參閱「Dataflow 的防火牆規則」。

  10. 如果已啟用 Runner v2，請檢查安全帶記錄檔是否有錯誤。詳情請參閱「排解 Runner v2 問題」。

找出進度落後項目

進度落後項目是指相較於階段中的其他工作項目，進度較慢的工作項目。如要瞭解如何找出並修正落後的工作，請參閱排解批次工作中的落後工作。

找出緩慢或停滯的階段

如要找出緩慢或停滯的階段，請使用「Stage progress」(階段進度) 檢視畫面。 長條越長，表示該階段耗時越久。使用這個檢視畫面找出管道中最慢的階段。

找出瓶頸階段後，請按照下列步驟操作：

  • 找出該階段的落後工作者。
  • 如果沒有落後的工作站，請使用「階段資訊」面板找出最慢的步驟。運用這項資訊找出可進行使用者程式碼最佳化的候選項目。
  • 如要找出平行處理瓶頸，請使用 Dataflow 監控指標。

找出延遲的工作人員

如要找出特定階段中進度落後的工作站，請使用「工作站進度」檢視畫面。這個檢視畫面會顯示所有工作站是否都在處理工作，直到階段結束，或是單一工作站是否卡在延遲的工作上。如果發現工作人員速度緩慢，請採取下列步驟：

偵錯工具

如果管道速度緩慢或停滯，可以使用下列工具診斷問題。

  • 如要將事件相互關聯並找出瓶頸，請使用 Cloud Monitoring for Dataflow。
  • 如要監控管道效能，請使用 Cloud Profiler。
  • 有些轉換比其他轉換更適合用於大流量管道。記錄訊息可識別批次或串流管道中停滯的使用者轉換作業。
  • 如要進一步瞭解停滯的工作，請使用 Dataflow 工作指標。下列清單列出實用指標：
    • 「待處理作業位元組」指標 (backlog_bytes) 會測量各階段未處理的輸入位元組數量。使用這個指標找出沒有輸送量的融合步驟。 同樣地，待處理元素指標 (backlog_elements) 會測量階段中未處理的輸入元素數量。
    • 「處理平行處理索引鍵」(processing_parallelism_keys) 指標會測量過去五分鐘內，管道特定階段的平行處理索引鍵數量。您可以透過下列方式使用這項指標進行調查：
      • 將問題範圍縮小至特定階段，並確認快速鍵警告，例如 A hot key ... was detected。
      • 找出平行處理量不足導致的輸送量瓶頸。 這些瓶頸可能會導致管道緩慢或停滯。
    • 系統延遲指標 (system_lag) 和每個階段的系統延遲指標 (per_stage_system_lag) 會測量資料項目處理或等待處理的最長時間。您可以運用這些指標，找出資料來源中效率不彰的階段和瓶頸。

如需 Dataflow 監控網頁介面未列出的其他指標，請參閱「Google Cloud 指標」一文，查看 Dataflow 指標的完整清單。