本頁面說明如何解決 Dataflow 自動調度資源功能的問題,並提供如何管理自動調度資源的資訊。
工作未向上或向下擴充
本節說明可能導致 worker 無法向上或向下擴充的情境。
串流工作未向上擴充
串流管道有待處理工作,但 worker 未擴充。
如果待處理工作持續時間不到幾分鐘,或平行處理受限,就會發生這個問題。
有時待處理工作量偏高,但平行處理程度偏低。在這種情況下,Dataflow 不會擴充,因為工作無法分配給更多 worker,因此增加 worker 數量也無法加快處理速度。詳情請參閱「串流自動調度資源」。
批次和串流工作不會向上擴充
批次或串流工作正常執行,但需要更多 worker 時,工作不會擴充。
這個問題可能是下列其中一個原因所致:
- 無法存取暫存檔。如果工作使用 Cloud Storage bucket,該 bucket 可能設有生命週期設定,會刪除 bucket 中的物件。刪除的物件包括暫存資料夾和檔案。如要確認檔案是否已刪除,請查看 bucket 的生命週期設定。如果暫存資料夾或檔案在工作啟動後遭到刪除,建立新 worker 所需的套件可能就不存在。如要解決這個問題,請在 bucket 中重新建立資料夾和檔案。
- 防火牆規則會阻止 worker 在必要的 TCP 通訊埠上傳送及接收流量。防火牆規則可能會導致 worker 無法啟動。Dataflow worker 必須能夠在 TCP 通訊埠 12345 和 12346 上傳送及接收流量。如需更多資訊 (包括解決這個問題的步驟),請參閱「Dataflow 的防火牆規則」。
- 自訂來源具有會傳回 NULL 值的
getProgress()方法。使用自訂來源時,待處理工作指標會依據自訂來源getProgress()方法的傳回值,開始收集資料。getProgress()的預設實作會傳回 NULL 值。如要解決這個問題,請確認自訂來源會覆寫預設的getProgress()方法,傳回非空值。 - 由垂直自動調度資源觸發的更新會暫時停用水平自動調度資源。詳情請參閱「對自動水平調度資源的影響」。
- 如果您在 Python 管道中使用
map作業,但工作未擴充,可能需要在管道程式碼中加入Reshuffle轉換。詳情請參閱 Apache Beam 說明文件中的「Reshuffle」。
串流工作不會縮減
如果串流工作的待處理工作量和 CPU 使用率偏低,worker 就不會縮減。這個問題可能由多種原因造成。
如果工作未使用 Streaming Engine,Dataflow 會平衡 worker 之間的永久磁碟數量。因此,每個 worker 必須有相同數量的永久磁碟。舉例來說,如果有 100 個磁碟和 100 個 worker,每個 worker 會分配到一個磁碟。縮減資源時,工作可以有 50 個 worker,每個 worker 有兩個永久磁碟。直到工作可有 25 個 worker,且每個 worker 有四個永久磁碟,才會再次縮減。此外,工作站數量下限是
maxNumWorkers的值除以 15。詳情請參閱「串流自動調度資源管道的資源調度範圍」。如果工作使用 Streaming Engine,縮減目標會以 75% 的目標 CPU 使用率為依據。如果無法達到這個 CPU 使用率,系統就會停用縮減功能。
待處理工作時間預估值必須至少有兩分鐘低於十秒,worker 才會縮減。待處理時間波動可能會導致縮減功能停用。此外,低處理量可能會導致預估時間不準確。
Apache Beam SDK 2.60.0 以上版本支援
PeriodicImpulse。如果管道使用PeriodicImpulse搭配 Apache Beam SDK 2.59.0 以下版本,Dataflow worker 不會按照預期縮減。
停止擴充
批次或串流工作開始向上擴充,但即使仍有待處理工作,worker 仍停止向上擴充。
達到配額限制時,就會發生這個問題。
- Compute Engine 配額:Dataflow 工作受限於專案的 Compute Engine 配額。如果有多個工作正在執行,專案可能已達到 Compute Engine 配額上限。在這種情況下,Dataflow 無法增加 worker 數量。
- CPU 配額:Dataflow 工作也受專案的 CPU 配額限制。如果 worker 類型使用多個 CPU,專案可能已達到 CPU 配額上限。
- 外部 IP 位址配額:如果工作使用外部 IP 位址與資源通訊,則外部 IP 位址數量必須與 worker 數量相同。當 worker 數量增加時,外部 IP 位址數量也會增加。達到 IP 位址限制時,worker 就會停止擴充。
此外,如果您選擇的區域沒有資源,即使區域或專案中還有剩餘配額,也無法建立該類型的資源。舉例來說,您可能仍有配額可在 us-central1 建立外部 IP 位址,但該區域可能沒有可用的 IP 位址。詳情請參閱「配額和資源可用性」。
如要解決這個問題,請要求提高配額,或在其他區域執行工作。
worker 使用率提示不會產生任何影響
您設定了工作站使用率提示,但自動調度資源行為並未改變。
如要瞭解這個問題,請前往「Worker CPU utilization」(工作站 CPU 使用率) 圖表,檢查是否正在使用工作站使用率提示。如果正在使用提示,圖表會顯示 CPU utilization hint (actively used by autoscaler)。否則,系統會顯示 CPU utilization hint (not actively used by autoscaler)。
使用率提示只是影響自動調度資源的其中一個因素。下表列出自動配置器可能不會主動使用提示的部分原因:
| 觀察到的資源調度行為 | 原因 | 要查看的指標 |
|---|---|---|
| 沒有變更 |
|
|
| 向上擴充 |
|
|
| 縮減 |
|
詳情請參閱「串流自動調度資源經驗法則」。
排解自動調度資源排程問題
如果您在建立、更新或執行自動調度資源排程時遇到問題,請參閱下列常見情境和疑難排解步驟。
無法設定或更新自動調度資源時間表
如果嘗試建立或更新自動調度資源排程失敗,請確認排程設定符合下列限制:
- 排程限制:單一工作最多可有 10 個自動調度資源排程。如果工作已有 10 個排程,您必須先移除現有排程,才能新增排程。
- 最短時間長度:排程時間長度至少須為 5 分鐘 (300 秒)。
- 參數限制:
- CPU 使用率目標必須介於 [0.1, 0.9] 之間。
- worker 數量上限必須大於或等於 worker 數量下限 (
max_workers≥min_workers)。
- 工作啟動時的 Crontab 格式限制:使用
--experiments=autoscaling_schedule=...管道選項在工作啟動時指定的 Crontab 運算式不得包含半形逗號 (例如1,15 * * * *或* * * * MON,WED,FRI)。半形逗號會保留用於分隔管道選項。如果排程需要逗號,請在不設定排程的情況下啟動工作,並在啟動後使用執行中更新進行設定,或指定多個獨立排程。
時間表未生效或套用其他時間表
如果自動調度資源排程未在預期時間範圍內生效,或套用了其他排程的設定,請檢查下列事項:
- 一次只能啟用一個排程:如果兩個以上的排程時間範圍重疊,Dataflow 會根據排程優先順序決定要套用哪個排程:
- 系統會套用優先順序值較高 (
priority) 的時間表。 - 如果多個有效排程具有相同的優先順序值,系統會套用最近更新或修改的排程。
- 有效時間表結束後,Dataflow 會套用其他仍有效的時間表,或將自動調度資源行為還原為工作的預設設定。
- 系統會套用優先順序值較高 (
- 時區不一致:確認排程指定的時區符合預期區域和日光節約時間規則。根據預設,系統會以
UTC解讀時間表的開始時間。 - 在控制台驗證有效排程:在 Google Cloud 控制台,前往 Dataflow 工作詳細資料頁面的「Autoscaling」(自動調度資源) 分頁,查看有效排程。您也可以執行
gcloud dataflow jobs describe指令或查詢 REST API,檢查設定的排程及其參數。
管道未擴充至排定的 worker 數量
如果排程啟用時,worker 數量上限較高或使用率提示較低,但管道未擴充至預期的 worker 數量,請檢查下列因素:
- 資源和配額限制: Google Cloud 專案和區域必須有足夠的資源配額,才能向上擴充。以下情況可能會導致無法分配 worker:
- Compute Engine 執行個體配額:專案可能已達到該區域的執行個體上限。
- CPU 配額:如果 worker 使用多個 CPU (例如
n1-standard-4),請確保專案有足夠的 CPU 配額。 - IP 位址配額:每個 worker VM 都需要 IP 位址。如果虛擬私有雲網路或區域中的 IP 位址配額用盡,就無法佈建新的 worker。
- 資源可用性:如果區域或可用區暫時資源耗盡,即使配額充足,Dataflow 也可能無法建立新的 worker 執行個體。詳情請參閱「擴充停止」。
延遲時間層級敏感度:如果有效排程設定的延遲時間層級為
medium_latency或high_latency,Dataflow 會刻意等待更多待處理工作累積,再觸發擴充事件:low_latency(預設):待處理時間超過 15 秒時,系統會向上擴充。medium_latency:待處理工作超過 180 秒 (3 分鐘) 時,會向上擴充。high_latency:待處理工作超過 600 秒 (10 分鐘) 時,系統會向上擴充。
如果工作在排定的可預約時間範圍內似乎延遲或延遲擴充,請確認使用中的排程是否設定了較高的延遲等級。
以索引鍵為準的平行處理限制:Dataflow 的擴充程度,無法超過該階段可用的不重複處理索引鍵數量。如果資料串流包含的專屬索引鍵很少,新增 worker 無法提高處理量,Dataflow 會限制 worker 數量,避免資源閒置。
worker 集區穩定性:如果 worker 執行個體發生當機或記憶體不足 (OOM) 錯誤,Dataflow 會暫時停止自動調度資源大小調整要求,直到 worker 集區穩定為止。
自動調度資源指標有缺漏
自動調度資源指標有短暫的臨時缺口。
如果重新啟動後端工作,就可能發生這個問題。這些指標中的缺口並不代表自動調度資源或串流工作的健康狀態有問題。
CPU 分配不均
工作自動調度資源時,各 worker 的 CPU 使用率分布不均。部分 worker 的 CPU 使用率、系統延遲或資料更新間隔高於其他 worker。
如果資料含有熱鍵,就可能發生這個問題。熱鍵是指含有足夠元素,會對管道效能造成負面影響的鍵。每個鍵都必須由單一 worker 處理,因此工作無法分配給多個 worker。
詳情請參閱熱鍵錯誤指南。
要求讀取狀態的工作項目在後端已失效
在串流管道中,worker VM 執行個體與 Streaming Engine 工作通訊時,發生下列錯誤:
The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.
自動調度資源期間,worker VM 執行個體會與多個 Streaming Engine 工作通訊,且每項工作會為多個 worker VM 執行個體提供服務。項目鍵用於分配工作。每項工作和 worker VM 執行個體都有一組鍵範圍,這些範圍的分布可能會動態變更。舉例來說,在自動調度資源期間,調整工作大小可能會導致金鑰範圍分布變更。金鑰範圍變更時,可能會發生這項錯誤。這項錯誤是預期中的情況,除非您發現這些訊息與管道效能不佳有關,否則可以忽略。
Streaming Engine 資源不足
如果 Streaming Engine 無法分配您要求的最低 worker 數量,則會傳回下列錯誤:
Streaming Engine does not currently have enough resources available to fulfill
the request.
如要解決這個問題,請嘗試設定較低的工作站數量下限。請參閱「設定自動調度資源範圍」。
串流自動調度資源管道的調度範圍
本節詳細說明串流自動調度資源管道的調度範圍。
Java
對於不使用 Streaming Engine 的串流自動調度資源工作,Dataflow 服務會為每個 worker 分配 1 到 15 個 Persistent Disk。這項分配方式代表串流自動調度資源管道使用的 worker 數量下限為 N/15,其中 N 是 --maxNumWorkers 的值。
針對使用 Streaming Engine 的串流自動調度資源工作,工作站數量下限為 1。
Dataflow 會平衡 worker 之間的 Persistent Disk 數量。舉例來說,如果管道在穩定狀態下需要三或四個 worker,您可以設定 --maxNumWorkers=15。管道會自動在 1 到 15 個 worker 之間調度資源,使用 1、3、5 或 15 個 worker,分別對應每個 worker 15、5、3 或 1 個永久磁碟。
--maxNumWorkers 的上限是 1000。
Python
對於不使用 Streaming Engine 的串流自動調度資源工作,Dataflow 服務會為每個 worker 分配 1 到 15 個 Persistent Disk。這項分配方式代表串流自動調度資源管道使用的 worker 數量下限為 N/15,其中 N 是 --max_num_workers 的值。
針對使用 Streaming Engine 的串流自動調度資源工作,工作站數量下限為 1。
Dataflow 會平衡 worker 之間的 Persistent Disk 數量。舉例來說,如果管道在穩定狀態下需要三或四個 worker,您可以設定 --max_num_workers=15。管道會自動在 1 到 15 個 worker 之間調度資源,使用 1、2、3、4、5、8 或 15 個 worker,分別對應每個 worker 15、8、5、4、3、2 或 1 個永久磁碟。
--max_num_workers 的上限是 1000。
Go
對於不使用 Streaming Engine 的串流自動調度資源工作,Dataflow 服務會為每個 worker 分配 1 到 15 個 Persistent Disk。這項分配方式代表串流自動調度資源管道使用的 worker 數量下限為 N/15,其中 N 是 --max_num_workers 的值。
針對使用 Streaming Engine 的串流自動調度資源工作,工作站數量下限為 1。
Dataflow 會平衡 worker 之間的 Persistent Disk 數量。舉例來說,如果管道在穩定狀態下需要三或四個 worker,您可以設定 --max_num_workers=15。管道會自動在 1 到 15 個 worker 之間調度資源,使用 1、2、3、4、5、8 或 15 個 worker,分別對應每個 worker 15、8、5、4、3、2 或 1 個永久磁碟。
--max_num_workers 的上限是 1000。
串流自動調度資源可能使用的 worker 數量上限
Java
Dataflow 的運作範圍受限於專案的 Compute Engine 執行個體數量配額或 maxNumWorkers,以較低者為準。
Python
Dataflow 的運作範圍受限於專案的 Compute Engine 執行個體數量配額或 max_num_workers,以較低者為準。
Go
Dataflow 的運作範圍受限於專案的 Compute Engine 執行個體數量配額或 max_num_workers,以較低者為準。
限制自動調度資源,減少對帳單的影響
如果不希望自動調度資源功能增加帳單費用,可以限制串流工作可使用的 worker 數量上限。
Java
您可以指定 --maxNumWorkers,限制用來處理工作的資源調度範圍。
Python
您可以指定 --max_num_workers,限制用來處理工作的資源調度範圍。
Go
您可以指定 --max_num_workers,限制用來處理工作的資源調度範圍。
變更資源調度範圍
如要瞭解如何變更串流管道的資源調度範圍,請參閱「設定自動調度資源範圍」。
關閉串流管道的自動調度資源功能
如要停用串流管道的自動調度資源功能,請按照下列步驟操作。
Java
請設定 --autoscalingAlgorithm=NONE。詳情請參閱「停用自動水平調度資源」。
Python
請設定 --autoscaling_algorithm=NONE。詳情請參閱「停用自動水平調度資源」。
Go
請設定 --autoscaling_algorithm=NONE。詳情請參閱「停用自動水平調度資源」。
使用固定數量的 worker
對於不使用 Streaming Engine 的串流工作,預設行為是使用固定數量的 worker。如要搭配這些管道使用串流自動調度資源功能,您必須明確選擇加入,因為這項功能預設為關閉。