本頁說明如何將從 Pub/Sub 讀取資料並寫入 BigQuery 的 Dataflow 管道最佳化。視應用情況而定，下列建議可能有助於提升成效。
管道待辦事項的初步解決方案
如果 Pub/Sub 至 BigQuery 管道的待處理工作不斷增加，且無法處理傳入的訊息，您可以立即採取下列步驟：
- 延長 Pub/Sub 確認期限：針對相關聯的 Pub/Sub 訂閱項目，延長確認期限，使其略長於預期的訊息處理時間上限。這樣可避免系統在訊息處理期間過早重新傳送訊息。
- 擴充工作站：如果未確認的訊息數量和訂閱項目待處理工作快速增加，管道的處理容量可能不足。增加 Dataflow worker 數量，以處理訊息量。
- 啟用指數輪詢：啟用指數輪詢，改善管道處理暫時性問題重試的方式，提高管道的復原能力。
長期程式碼和管道最佳化
為維持效能和穩定性，建議進行下列架構和程式碼變更：
- 減少對 BigQuery 的
getTable呼叫次數：過多的getTable方法呼叫可能會導致速率限制和效能瓶頸。如要減輕這個問題的影響：- 在工作人員記憶體中快取資料表存在資訊，避免重複呼叫相同資料表。
- 批次
getTable呼叫，以每個套裝組合為單位，而非每個個別元素。 - 重構管道程式碼，不必為每則訊息檢查資料表是否存在。
- 使用 BigQuery Storage Write API：對於寫入 BigQuery 的串流管道，請從標準串流插入作業遷移至 Storage Write API。Storage Write API 的效能較佳，配額也大幅提高。
- 針對高基數工作使用標準的 Streaming Java Runner (先前稱為 Runner v1)： 如果工作處理的唯一鍵數量非常龐大 (高基數)，除非需要跨語言轉換，否則 Streaming Java Runner 的效能可能會優於 Portable Runner。
- 最佳化鍵空間：當管道處理數百萬個有效鍵時，效能可能會降低。調整管道的邏輯，在較小且更容易管理的主要空間中執行工作。
資源、配額和設定管理
適當分配及設定資源，對管道健康狀態至關重要：
- 主動管理配額：監控配額，並在擴充事件期間可能達到配額時，要求增加配額。舉例來說，請考量下列縮放事件：
- 如果對
TableService.getTable或tabledata.insertAll方法的呼叫頻率過高，可能會超過每秒查詢次數 (QPS) 上限。如要進一步瞭解限制和如何要求更多配額，請參閱 BigQuery 配額和限制。 - 使用中的 IP 位址和 CPU 的 Compute Engine 配額可能會超過上限。如要進一步瞭解限制，以及如何要求提高配額，請參閱 Compute Engine 配額與限制總覽。
- 如果對
- 最佳化工作人員設定：為避免記憶體不足 (OOM) 錯誤並提升穩定性：