如果某個步驟、階段或工作站導致整體工作速度變慢，就會發生瓶頸。瓶頸可能會導致工作站閒置，並增加延遲時間。
如果 Dataflow 偵測到瓶頸，工作圖表會顯示快訊，而「Step Info」(步驟資訊) 面板會列出瓶頸類型和原因 (如有)。Dataflow 也會將瓶頸偵測資訊匯出至 Monitoring 指標，並以時間序列的形式呈現資料。方便您查看一段時間或過去的瓶頸。
瞭解瓶頸
Dataflow 執行串流管道時，工作會包含一系列元件，例如串流 Shuffle、使用者定義函式 (DoFn) 處理執行緒，以及永久狀態檢查點。為促進資料流動，Dataflow 會使用佇列連結這些元件。資料會從上游推送至下游。
在許多管道中，整體處理量容量會受到單一元件限制，在管道中形成瓶頸。資料通過瓶頸的速率會限制管道接受及處理輸入資料的速度。
舉例來說，假設管道中發生 DoFn 處理作業，而該作業位於串流隨機排序的下游。兩者之間的佇列會緩衝處理隨機排序但未處理的資料。如果 DoFn 處理程序無法像串流隨機排序產生資料一樣快速取用資料，佇列就會變大。如果瓶頸持續存在，佇列可能會達到容量上限。此時，系統會暫停後續隨機播放作業，並將待處理項目向上游傳播。上游佇列也會累積待處理項目，最終導致速度變慢，並延伸至資料來源，也就是說，整個管道無法跟上輸入速度。
發生瓶頸時，管道中可能會有很大一部分顯示為健康狀態不良，即使管道中只有一個點造成積壓。這種行為可能會導致難以偵錯瓶頸。瓶頸偵測的目標是找出確切位置和原因，消除臆測，以便修正根本原因。
如果延遲時間超過五分鐘的門檻，Dataflow 就會偵測到瓶頸。如果延遲時間未超過這個門檻，Dataflow 就不會偵測到瓶頸。
瓶頸偵測功能不一定需要您採取行動，視您的用途而定。如果管道的暫時性延遲時間超過五分鐘，仍可正常運作。如果您的用途可接受這種情況，可能就不需要解決所指出的瓶頸。
瓶頸類型
Dataflow 偵測到瓶頸時，監控介面會指出問題的嚴重程度。瓶頸可分為下列幾類：
- 處理作業停滯且無法繼續進行
- 管道在這個步驟完全停止。
- 處理作業持續進行中，但進度落後。
- 管道無法快速處理傳入資料。因此積壓的工作量也隨之增加。
- 處理作業持續進行中，但有待處理的工作
- 管道正在處理資料，處理速率與輸入速率相當。處理速度夠快，因此待處理工作不會增加，但累積的待處理工作也不會大幅減少。
- 處理作業持續進行中，且即將進行待處理的工作
- 積壓工作量正在減少，但目前的瓶頸阻礙了管道更快趕上進度。如果啟動的管道有待處理事項，這種狀態可能很正常，不需要採取任何行動。監控進度，看看待處理事項是否持續減少。
造成瓶頸的原因
本節列出可偵測到的瓶頸原因。請參考這項資訊解決問題。在某些情況下，可能有多個原因，而且這些原因可能互有關聯。舉例來說，如果工作站資源不足，vCPU 使用率可能會偏高。vCPU 使用率偏高可能會導致作業速度變慢，進而造成佇列延遲時間增加。可能原因分析可能會將所有這些因素顯示為造成瓶頸的原因。
- 作業處理時間過長
這項運算的部分作業處理時間較長。只要輸入套件傳送至執行
DoFn的工作人員，且經過一段時間後仍未提供結果，就會發生這種情況。這通常是使用者程式碼中單一長時間執行的作業所致。 其他問題可能會導致作業處理時間過長。舉例來說，
DoFn內擲回並重試的錯誤、長時間重試，或因 OOM 等因素導致工作站架構當機，都可能造成處理時間過長。如果受影響的運算位於使用者程式碼中，請尋找最佳化程式碼或限制執行時間的方法。為協助偵錯，工作站記錄會顯示任何停滯超過 5 分鐘的作業堆疊追蹤記錄。
- 金鑰提交過大
請參閱「金鑰提交過大例外狀況」。
- BigQuery 接收器權限遭拒
這項錯誤表示執行管道的服務帳戶沒有寫入 BigQuery 資源的必要權限。
如要使用工作人員記錄驗證這個問題，請按照下列步驟操作：
- 在 Google Cloud 控制台中，開啟 Dataflow 的「Job details」(工作詳細資料) 頁面。
- 在底部面板中，按一下「記錄」分頁，然後選取「工作人員記錄」。
- 尋找指出權限或存取權遭拒的錯誤訊息 (例如
PERMISSION_DENIED、403 Forbidden、Access Denied或actuallyForbidden)。 - 檢查記錄訊息，找出目的地資料集或資料表，以及缺少的特定權限 (例如
bigquery.tables.updateData)。
如何解決這個問題：
- 確認服務帳戶已獲授目的地資料集和資料表的「BigQuery 資料編輯者」 (
roles/bigquery.dataEditor) 角色。 - 如要跨專案寫入資料，請確認已在代管 BigQuery 資料集的目的地專案中，直接將權限授予服務帳戶，且 VPC Service Controls (如已啟用) 允許兩個專案之間的通訊。
如果上述步驟無法解決問題，請參閱「BigQuery 預先定義的角色和權限」，找出並授予特定設定所需的任何細部權限。
- BigQuery 接收器資源耗盡
這個錯誤表示管道超出 BigQuery 配額限制。最可能的原因是目的地 BigQuery 專案的配額不足，無法處理寫入的資料量。
如要使用工作人員記錄驗證這個問題，請按照下列步驟操作：
- 在 Google Cloud 控制台中，開啟 Dataflow 的「Job details」(工作詳細資料) 頁面。
- 在底部面板中，按一下「記錄」分頁，然後選取「工作人員記錄」。
- 尋找錯誤訊息，確認資源或配額是否用盡，或是超出速率限制 (例如
RESOURCE_EXHAUSTED、429 Too Many Requests、quotaExceeded或rateLimitExceeded)。 - 檢查記錄訊息，確認超出哪個作業和配額限制 (例如儲存空間寫入 API
AppendRows處理量或連線限制，或是串流資料即時插入速率限制)。
如何解決這個問題：
- 判斷管道使用的 BigQuery 接收器實作方式 (例如 Storage Write API 或串流插入)。
- 在 Google Cloud 控制台中查看 BigQuery 配額用量。請特別注意與接收器類型相關的配額，例如並行連線、處理量或每秒串流資料插入資料列。
- 如果經常接近或超過這些限制，請考慮申請提高配額。
如果這些步驟無法找出超出上限的具體項目，請參閱「排解配額和限制錯誤」一文，進一步調查。
- BigQuery sink RPC 失敗
這項錯誤表示管道傳送至 BigQuery 的 RPC 要求失敗。可能原因包括暫時性網路或服務問題、無效的要求酬載、結構定義不符，或是逾時和超過期限錯誤。
如要使用工作人員記錄驗證這個問題，請按照下列步驟操作：
- 在 Google Cloud 控制台中，開啟 Dataflow 的「Job details」(工作詳細資料) 頁面。
- 在底部面板中，按一下「記錄」分頁，然後選取「工作人員記錄」。
- 找出與 BigQuery 寫入作業相關的錯誤訊息或例外狀況 (例如
DEADLINE_EXCEEDED、UNAVAILABLE、INVALID_ARGUMENT或結構定義驗證錯誤)。 - 檢查堆疊追蹤和錯誤訊息，判斷 BigQuery API 傳回的特定失敗模式。
如何解決這個問題：
- 在工作站記錄檔中找出特定錯誤訊息或狀態碼後，請參閱 BigQuery 錯誤訊息參考資料，取得該錯誤的專屬疑難排解指南。
- 如果管道使用 Storage Write API，請參閱 BigQuery Storage Write API 說明文件中的「錯誤處理」一節，瞭解如何處理特定寫入和串流錯誤。
- 所有作業的處理時間偏長
這項計算作業持續耗費大量時間，表示使用者提供的
DoFn存在問題。這與「作業處理時間過長」不同，後者會影響部分作業，而前者表示這項計算中的所有作業都會受到影響。
檢查 worker 記錄檔中的錯誤、例外狀況或堆疊追蹤記錄，找出緩慢或停滯的執行緒。如果您使用 Python 適用的 Apache Beam SDK，且作業本質上就是設計為長時間執行 (例如外部 API 呼叫速度緩慢或 I/O 延遲時間較長)，請考慮使用 Async DoFn。這項功能可防止處理作業因這些長時間執行的工作而遭到封鎖，進而提升輸送量。
- 永久狀態讀取速度緩慢
運算作業在執行
DoFn時，會花費大量時間讀取持續性狀態。這可能是因為持續性狀態過大，或是讀取次數過多。請考慮減少保存狀態的大小或讀取頻率。視情況合併多個狀態讀取作業，或使用對應狀態而非值狀態，藉此最佳化狀態存取模式。這也可能是暫時性問題，因為基礎持續性狀態緩慢。- 永久狀態寫入速度緩慢
計算作業在提交處理結果時，花費大量時間寫入持續性狀態。這可能是因為持續性狀態過大所致。建議縮減保存狀態的大小。視情況合併多個狀態寫入作業，藉此最佳化狀態存取模式。這也可能是暫時性問題，因為基礎持續性狀態緩慢。
- 已拒絕的修訂版本
資料無效，因此無法將資料處理作業提交至持續性狀態。 這通常是因為超出其中一項作業限制。 詳情請見記錄，或與支援團隊聯絡。
- Apache Kafka 來源分區不足
Apache Kafka 來源運算的分區不足。如要解決這個問題，請嘗試下列做法：
- 增加 Kafka 分區數量。
- 設定 Kafka IO 讀取時，請加入使用
.withRedistribute()重新分配，更有效率地平行處理資料。加入.withRedistributeNumKeys(N)，其中N > partitions可提供金鑰總數上限。鍵數量有限，可透過記錄組合提高效率。 - 如要盡量降低重新分配重組的成本，請使用
.withOffsetDeduplication()。這個模式可盡量減少需要保存的資料量 (做為重組作業的一部分)，同時仍提供「只處理一次」的作業。
詳情請參閱「從 Apache Kafka 讀取資料到 Dataflow」頁面的「平行處理作業」。
- Apache Kafka 來源保留大量狀態
Apache Kafka 來源運算正在重新分配大量資料，這可能會導致延遲和費用偏高。如要解決這個問題，請嘗試下列做法：
- 如果管道需要「僅需處理一次」，請使用偏移簡化模式，盡量降低重組重組的成本。這個模式會盡量減少需要保留的資料量，同時仍提供「只處理一次」的處理方式。
- 如果管道至少處理一次就足夠，則可啟用「允許重複」設定。
詳情請參閱「從 Apache Kafka 讀取資料到 Dataflow」。
- 來源平行處理量不足
來源運算平行處理量不足。請盡可能增加來源中的平行化。如果無法提高平行化程度，且工作使用至少一次模式，請嘗試在管道中新增
Redistribute轉換。- 頻繁使用索引鍵或索引鍵平行處理量不足
作業有頻繁使用的索引鍵，或索引鍵平行處理量不足。
Dataflow 會依序處理每個分片鍵的訊息。當 Dataflow 處理特定鍵的一批訊息時，該鍵的其他傳入訊息會排入佇列，直到目前批次處理完畢為止。
如果 Dataflow 無法平行處理足夠的相異鍵，可能會造成瓶頸。舉例來說，資料可能只有少數幾個不同的鍵，或某些鍵在資料中過度呈現 (「熱鍵」)。如要解決這個問題，請修改管道邏輯，重新分配資料。舉例來說，您可以在分組鍵中加入隨機後置字串，藉此中斷熱鍵，並在後續步驟中匯總結果。詳情請參閱「排解快速鍵問題」。
- vCPU 佈建不足
這項工作沒有足夠的 worker vCPU。如果工作已擴充至上限，vCPU 使用率偏高，且仍有待處理工作，就會發生這種情況。您可能需要提高為這項工作佈建的工作站數量上限。舉例來說，您可以更新自動調度範圍，增加這個數字。或者，您也可以尋找方法，透過變更管道程式碼或工作負載來減少 vCPU 用量。您可以使用 Cloud Profiler 尋找最佳化商機。
- vCPU 使用率偏高，正在等待擴充資源
這項工作的 vCPU 使用率偏高，但仍有擴充空間。在升級完成前，這種情況可能只是暫時性的。您可以監控自動調度資源，查看自動調度資源決策。如果這種情況持續很久或經常發生，您可能需要設定不同的工作人員利用率提示，允許工作更主動地擴充，藉此變更自動調度設定。
- vCPU 負載不平衡，導致某些離群 worker 產生瓶頸
這項工作有足夠的 worker vCPU，但部分 worker 的 vCPU 使用率非常高。這通常是因為工作分配不均所致。可能原因包括來源分割區負載不均，或是熱鍵。
如要解決這個問題，請嘗試下列做法：
- 判斷載入不均的原因，並嘗試修正。舉例來說，請確保來源分區平均分配。
- 如果無法修正負載不均的問題，請考慮變更 worker VM 形狀，增加每個 worker 的 vCPU 數量，以降低尖峰使用率。如要進一步瞭解如何設定每個工作站的 vCPU，請參閱「設定 Dataflow 工作站 VM」。
- 與 worker 通訊時發生問題
Dataflow 無法與所有 worker VM 通訊。檢查工作 VM 的狀態。可能的原因包括：
- 工作者 VM 的佈建作業發生問題。
- 工作執行期間刪除 worker VM 集區。
- 網路問題。
- Pub/Sub 來源發生提取錯誤。
從 Pub/Sub 來源提取資料時發生錯誤。確認必要主題和訂閱項目存在，並驗證配額和設定。您也可以檢查記錄是否有錯誤。
- Pub/Sub 來源平行處理量不足
Pub/Sub 來源運算使用的 Pub/Sub 金鑰數量不足。如要增加金鑰數量，請設定
num_pubsub_keys服務選項。詳情請參閱「Pub/Sub 來源平行處理量」。- Pub/Sub 來源因不明原因受到限制
從 Pub/Sub 讀取資料時，Pub/Sub 來源運算因不明原因受到限制。這個問題可能只是暫時性的。檢查 Pub/Sub 設定問題、缺少 IAM 權限或配額限制。不過，如果上述區域都不是根本原因，且問題持續發生，請與支援團隊聯絡。
- Pub/Sub 接收器發布作業緩慢或停滯
Pub/Sub 接收器運算作業緩慢或停滯。這個問題可能是設定錯誤或配額限制所致。
- 工作佇列時間過長
由於大量金鑰和金鑰處理速度，最舊的合格工作年齡較高。在這種情況下，每項作業可能不會異常耗時，但整體排隊延遲時間很長。
Dataflow 會為每個分片鍵使用單一處理執行緒，且處理執行緒數量有限。排隊延遲時間約等於鍵與執行緒的比率，乘以每個鍵的處理套件在執行緒上的延遲時間：
(key count / total harness threads) * latency per bundle請嘗試下列補救措施：
- Streaming Engine 後端發生暫時性問題
Streaming Engine 後端發生設定或運作問題。這個問題可能只是暫時性的。如果問題仍未解決，請聯絡支援團隊。
- 無法判斷原因
我們無法確定積壓的原因，這個問題可能只是暫時性的。如果問題仍未解決，請聯絡支援團隊。
瓶頸指標
下列工作指標提供有關瓶頸的資訊：
dataflow.googleapis.com/job/is_bottleneck：指出階段是否為效能瓶頸的布林值，以及指定瓶頸類型和可能原因的標籤。dataflow.googleapis.com/job/backlogged_keys： 瓶頸階段備份的金鑰數量。dataflow.googleapis.com/job/recommended_parallelism：建議的平行處理量值，可減輕受影響階段的瓶頸。