疑難排解串流工作緩慢或停滯的問題

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

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

• 管道未從來源讀取資料。舉例來說，Pub/Sub 的待處理工作不斷增加。
• 管道不會將資料寫入接收器。
• 資料更新間隔指標正在增加。
• 系統延遲指標正在增加。

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

找出根本原因

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

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

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

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

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

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

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

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

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

7. 檢查熱鍵。

8. 如果已啟用可攜式 Runner，請檢查安全防護措施記錄檔是否有錯誤。詳情請參閱「排解 Portable Runner 的問題」。

調查重複失敗情形

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

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

找出健康狀態不良的 worker

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

• 使用記憶體用量指標檢查記憶體壓力，並在工作站記錄中尋找記憶體不足錯誤。詳情請參閱「疑難排解 Dataflow 記憶體不足錯誤」。
• 如果您使用 Streaming Engine，請使用持續性指標，找出磁碟輸入/輸出作業 (IOPS) 的瓶頸。
• 查看 worker 記錄是否有其他錯誤。詳情請參閱「處理管道記錄」和「排解 Dataflow 錯誤」。

找出進度落後項目

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

排解平行處理問題

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

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

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

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

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

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

如要判斷管道速度緩慢是否是由於平行處理程度不足，請查看 CPU 使用率指標。如果 CPU 使用率偏低，但平均分配給各個工作站，表示工作可能平行處理量不足。如果您的工作使用 Streaming Engine，如要查看某個階段的平行處理程度是否偏低，請在「Job Metrics」(工作指標) 分頁中查看平行處理指標。如要緩解這個問題，請按照下列步驟操作：

• 在 Google Cloud 控制台的「Job info」(工作資訊) 頁面中，使用「Autoscaling」(自動調度資源) 分頁，查看工作是否無法擴充。如果問題出在自動調度資源，請參閱「疑難排解 Dataflow 自動調度資源」。
• 使用工作圖表檢查階段中的步驟。如果階段是從來源讀取資料或寫入接收器，請參閱來源或接收器服務的說明文件。請參閱說明文件，確認該服務是否已設定足夠的擴充性。
  • 如要收集更多資訊，請使用 Dataflow 提供的輸入和輸出指標。
  • 如果您使用 Kafka，請檢查 Kafka 分區數量。詳情請參閱 Apache Kafka 說明文件。
  • 如果您使用 BigQuery 接收器，請啟用自動分片功能，以提升平行處理能力。詳情請參閱「3x Dataflow Throughput with Auto Sharding for BigQuery」。

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

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

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

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

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

檢查熱鍵

如果工作在工作站間的分配不均，且工作站使用率差異很大，管道可能會有熱鍵。熱鍵是指在資料中過度代表的鍵。

查看緩慢步驟的瓶頸狀態，確認管道是否有熱鍵。如果瓶頸原因是「頻繁使用索引鍵或索引鍵平行處理量不足」，您可能使用了熱鍵。如需瓶頸的一般資訊，請參閱「疑難排解瓶頸」。

您可以透過 --hotKeyLoggingEnabled=true 執行管道，藉此列印特定金鑰。

接著使用下列記錄篩選條件檢查快速鍵：

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.logger="org.apache.beam.runners.dataflow.worker.HotKeyLogger"

將 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 指標，請參閱「建立資訊主頁、圖表和快訊」一文中的「查看配額用量和限制」。

偵錯工具

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

• 如要將事件相互關聯並找出瓶頸，請使用 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 指標清單。