使用 Dataflow 深入分析

您可以運用 Dataflow Insights 最佳化工作效能。 本主題將示範如何使用 gcloud 或 REST API 與 Dataflow Insights 互動。您也可以在 Dataflow 控制台中查看 Insights。如要進一步瞭解如何在主控台中查看洞察資料，請參閱「建議」。

總覽

Dataflow 深入分析結果會提供深入分析，協助您提升工作效能、降低成本及排解錯誤。Dataflow 深入分析是 Recommender 服務的一部分，可透過 google.dataflow.diagnostics.Insight 類型取得。

使用 Dataflow Insights 時，請注意部分建議可能與您的用途無關。

事前準備

您必須先完成下列步驟，才能開始使用 Dataflow Insights。

  1. 啟用 Recommender API。

  2. 設定驗證方法。

    Select the tab for how you plan to use the samples on this page:

    gcloud

    In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

    REST

    如要在本機開發環境中使用本頁的 REST API 範例，請使用您提供給 gcloud CLI 的憑證。

      安裝 Google Cloud CLI。 安裝完成後，執行下列指令初始化 Google Cloud CLI： 

      gcloud init

      如果您使用外部識別資訊提供者 (IdP)，請先 使用聯合身分登入 gcloud CLI。

    詳情請參閱 Google Cloud 驗證說明文件中的「Authenticate for using REST」。

  3. 確認帳戶具備下列權限：

    • recommender.dataflowDiagnosticsInsights.get
    • recommender.dataflowDiagnosticsInsights.list
    • recommender.dataflowDiagnosticsInsights.update

    您可以個別授予這些權限，也可以授予下列其中一個角色：

    • roles/recommender.dataflowDiagnosticsViewer
    • roles/recommender.dataflowDiagnosticsAdmin
    • roles/dataflow.viewer
    • roles/dataflow.developer
    • roles/dataflow.admin

    4. 要求提供 Dataflow 深入分析結果

    您可以列出 Dataflow 洞察，如下所示。如要瞭解其他類型的洞察資料互動，請參閱建議工具 API 的洞察資料指南。

    列出 Dataflow 深入分析結果

    如要列出專案在特定區域的所有 Dataflow 洞察，請使用下列其中一種方法：

    gcloud

    您可以使用 gcloud recommender insights list 指令，查看專案在指定區域的所有 Dataflow 洞察。

    執行指令前，請先替換下列值：

    • PROJECT_ID：要列出洞察資料的專案 ID。
    • REGION：Dataflow 工作執行的區域。例如：us-west1。
    gcloud recommender insights list --insight-type=google.dataflow.diagnostics.Insight \
  --project=PROJECT_ID \
  --location=REGION

    輸出內容會列出指定區域中專案的所有 Dataflow 洞察。

    REST

    您可以使用 Recommender API 的 insights.list 方法，列出指定區域中專案的所有 Dataflow 洞察。

    使用任何要求資料之前，請先替換以下項目：

    • PROJECT_ID：要列出洞察資料的專案 ID。
    • REGION：Dataflow 工作執行的區域。例如：us-west1。

    HTTP 方法和網址：

    GET https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights

    如要使用 curl (Linux、macOS 或 Cloud Shell) 傳送要求，請執行下列指令：

    curl -X GET \
  -H "Authorization: Bearer "$(gcloud auth print-access-token) \
  "https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights"

    取得單一 Dataflow 深入分析

    如要進一步瞭解單一洞察，包括洞察的說明、狀態和相關聯的任何建議，請使用下列其中一種方法：

    gcloud

    使用 gcloud recommender insights describe 指令和洞察 ID，查看單一洞察的相關資訊。執行指令前，請先替換下列值：

    • INSIGHT_ID：要查看的洞察 ID。
    • PROJECT_ID：要列出洞察資料的專案 ID。
    • REGION：Dataflow 工作執行的區域。例如：us-west1。
    gcloud recommender insights describe INSIGHT_ID \
  --insight-type=google.dataflow.diagnostics.Insight \
  --project=PROJECT_ID \
  --location=REGION

    輸出畫面會顯示詳細洞察資料。

    REST

    Recommender API 的 insights.get 方法會取得單一洞察資料。使用任何要求資料之前，請先替換以下項目：

    • PROJECT_ID：要列出洞察資料的專案 ID。
    • REGION：Dataflow 工作執行的區域。例如：us-west1。
    • INSIGHT_ID：要查看的洞察 ID。

    HTTP 方法和網址：

    GET https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights/INSIGHT_ID

    如要使用 curl (Linux、macOS 或 Cloud Shell) 傳送要求，請執行下列指令：

    curl -X GET \
  -H "Authorization: Bearer "$(gcloud auth print-access-token) \
  "https://recommender.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/insightTypes/google.dataflow.diagnostics.Insight/insights/INSIGHT_ID"

    解讀 Dataflow 深入分析結果

    取得洞察後，您可以查看內容，瞭解洞察所強調的資源用量模式。除了標準深入分析屬性外，Dataflow Insights 還提供下列子類型：

    • AUTOSCALING_NOT_ENABLED： 自動調度資源可能已啟用。這項工作的 CPU 使用率偏高，使用的 worker 數量也達到所設上限。啟用自動調度資源功能可以改善效能。
    • HIGH_FAN_OUT：您可在一個或多個轉換項目之後插入融合中斷點，以增加平行處理。
    • MAX_NUM_WORKERS： 自動調度資源： 可以提高 worker 的數量上限。這項工作採用自動調度資源設定，CPU 使用率偏高，使用的 worker 數量也達到所設上限。增加工作站數量上限或許能提高效能。
    • WORKER_OUT_OF_MEMORY：部分工作站因記憶體不足而無法正常運作，這可能會導致工作速度變慢或失敗。
    • PREBUILD_NOT_UTILIZED：使用工作站映像檔預先建構工作流程，縮短工作站啟動時間並提升自動調整規模的可靠性。
    • ACTIVE_KEYS (預覽)： 有效金鑰總數少於核心總數，擴充不會有幫助。
    • LONG_WORK_ITEM：融合階段的作業處理時間過長，表示作業執行緩慢或停滯。

    如要進一步瞭解如何解決 Dataflow Insights 發現的問題，請參閱「洞察」一文。

    Dataflow Insights 也提供特殊的 content 欄位，其中包含子欄位，內有洞察資料的額外資訊和中繼資料。視用途而定，下列 content 子欄位可能很有用：

    • jobName：Dataflow 工作名稱。
    • description：以英文說明洞察資料。
    • title：洞察資料的英文標題。

    深入分析

    偵測到高擴散傳遞

    如果 Dataflow 偵測到工作有一或多個轉換作業的扇出率偏高，就會顯示下列訊息：

    High fan-out detected

    如果 ParDo 的輸出/輸入元素計數比率偏高，且與後續的 ParDo 融合，就會顯示這則訊息。在這種情況下，第二個 ParDo 會與第一個 ParDo 依序執行，這會強制將特定輸入的所有輸出元素放到同一個工作站，進而減少平行處理，並降低效能。

    如何解決這個問題：

    • 插入 GroupByKey，並在第一個 ParDo 之後取消分組。Dataflow 服務絕不會融合匯總中的多個 ParDo 作業。詳情請參閱「融合最佳化」。
    • 將中繼 PCollection 做為側邊輸入傳送至另一個 ParDo。Dataflow 服務一律會將側邊輸入具體化。
    • 插入「重新洗牌」步驟。重新洗牌可防止融合、檢查點資料，並重新設定時間區間策略，確保不會捨棄任何資料。即使 Apache Beam 文件中已將 Reshuffle 標示為已淘汰，Dataflow 仍支援這項功能 (請注意，重新隨機分配資料可能會增加管道的執行成本)。

    自動調度資源：可提高工作站的數量上限

    如果 Dataflow 偵測到工作使用的工作站數量已達上限 maxNumWorkers (或 max_num_workers)，且工作可能會使用更多工作站 (如果上限提高)，系統會顯示下列訊息：

    maximum number of workers could be increased

    舉例來說，如果批次或串流工作設為 50 個工作站，且所有工作站的平均 CPU 使用率都超過 80%，系統就會提供這項建議。maxNumWorkers如果所有 50 個工作站都以高於 50% 的平均 CPU 使用率運作，且工作預估處理時間超過 2 分鐘，系統也會針對 maxNumWorkers 設為 50 的串流工作提供這項建議。

    一般來說，增加 maxNumWorkers 會提高管道輸送量。 批次管道完成作業的時間可能較短，串流管道則可處理更大的資料尖峰，並每秒處理更多元素。不過，這可能會增加成本。詳情請參閱工作人員資源定價。如要瞭解自動調度演算法的運作方式和設定方法，請參閱自動調度指南。

    如何解決這個問題：

    • 增加或移除 maxNumWorkers 管道選項。 如果沒有這個選項，Dataflow 會使用「自動調度資源指南」中列出的預設值。
    • 如果管道效能足夠，則不必採取任何行動。
      • 如果是批次管道，請確認總執行時間符合您的需求。
      • 如果是串流管道，請查看工作頁面「Job Metrics」(工作指標) 分頁中的「Data freshness」(資料更新間隔) 圖表。 確認圖表中的值不會持續增加，且在可接受的範圍內。

    自動調度資源：設定工作站的初始數量可提高工作效能

    如果 Dataflow 偵測到工作在超過 50% 的執行時間內使用特定數量的工作站，建議您將工作站的初始數量設為建議值，這樣就能縮短批次工作的執行時間，或在更新串流工作時防止待處理工作量增加，進而提升工作效能。

    工作站發生 OutOfMemory 錯誤而無法正常運作

    如果 Dataflow 偵測到工作站因記憶體不足錯誤而無法執行工作，系統會顯示下列訊息：

    Some workers are out of memory

    這項工作的部分 worker 因記憶體不足而失敗。雖然工作可能還是會完成，但這些錯誤也可能導致工作無法順利完成，或降低效能。

    請嘗試下列建議：

    未使用預先建構的工作流程

    如果 Dataflow 偵測到管道未使用工作站映像檔預先建構工作流程，就會顯示下列訊息：

    pre-build workflow not utilized

    如果未使用工作站映像檔預先建構工作流程，管線會在執行階段重複安裝依附元件。這項設定會延長工作站啟動時間，導致工作輸送量降低，並造成自動調度資源行為不可靠。

    如要解決這個問題，請在啟動管道時使用工作站映像檔預先建構工作流程。詳情請參閱「預先建構 Python 依附元件」。

    如果已使用自訂的預先建構容器，請新增「--sdk_location=container」選項，並移除下列選項，避免不必要的安裝作業：

    • '--setup_file'
    • '--requirements_file'
    • '--extra_package(s)'

    使用中的車鑰數量偏低

    如果 Dataflow 偵測到工作落後，是因為有效鍵的數量少於核心總數，且擴充作業無法解決問題，就會顯示下列訊息：

    Active keys can be increased

    Dataflow 會使用工作站在工作中執行使用者程式碼。每個執行緒都會對應至一個負責處理一組資料的索引鍵，且基於正確性考量，索引鍵一次只能在單一核心上執行。

    有時部分核心會過度運作，其他核心則處於閒置狀態。如要解決這個問題，請增加金鑰數量，這也會增加有效執行緒數量。

    增加金鑰的可能解決方案： - 使用更具體的金鑰類型，即可增加金鑰數量。舉例來說，如果金鑰類型為 IP address，可用的金鑰就會比較少。不過，如果將金鑰類型變更為 IP + [user identifier]，可用的金鑰會變多，平行處理能力也會隨之提升。 - 如果管道會將資料寫入 BigQuery，且接收器可能成為瓶頸，請參閱這篇文章。 - 如為其他來源/接收器，請檢查是否具有 numShards 參數並增加該參數。一般來說，一個分片會對應到一個鍵。- 如需執行模式的一般指南，請參閱這篇文章。 - Fanout 可用於取得單一輸入金鑰，並在其中加入雜湊，以產生多個輸出金鑰。參考資料

    階段耗費過多時間來處理工作

    如果 Dataflow 偵測到工作經常需要很長時間才能完成處理，就會顯示下列訊息：

    Stage spending too long on work

    Dataflow 會將工作傳送至元素組合中的融合階段，以供處理，且只要階段處理完所有元素及其輸出內容，系統就會將每個組合視為完成。串流管道經過最佳化，適合能在一分鐘內完全處理完畢的工作套件，因此處理時間過長可能會導致管道效能問題。

    使用者轉換作業停滯或緩慢可能會導致這個問題。您可以透過 Cloud Logging 和「診斷」分頁中發出的警告，找出這些轉換作業，並留意「作業進行中」或「處理作業停滯」等關鍵字詞。如要診斷這個問題是否是由使用者轉換所造成，請使用 Cloud Profiler 檢查使用者轉換的效能。然後追蹤導致速度變慢的程式碼，以及發生頻率。詳情請參閱「排解常見的 Dataflow 錯誤」。

    如果調查結果顯示處理時間過長並非使用者轉換所致，建議您聯絡 Cloud 支援團隊，並說明調查步驟。

    工作停滯在工作項目

    如果 Dataflow 偵測到某個鍵停滯，是因為單一工作項目重複失敗並重試，系統會顯示下列訊息：

    Job is stuck due to failed and retried work item

    在 Dataflow 中，管道中的所有訊息都會以特定鍵處理。處理郵件時發生錯誤，系統會重新嘗試處理該郵件。如果訊息重試兩到三次，是可以接受的。不過，如果錯誤一再發生 (例如連續發生十次)，通常表示管道程式碼有基本問題。如果系統重試特定金鑰上的訊息，同一金鑰下的其他訊息就無法繼續處理。如果訊息傳送失敗 10 次以上，問題可能不會自行解決。訊息傳送失敗可能會導致管道問題，例如：

    • 延遲顯示浮水印
    • 累積待處理事項
    • 防止排空作業完成

    如要偵錯這個問題，請調查建議回報的階段，並查看記錄檔，找出有問題的程式碼。接著，使用新的管道程式碼更新工作，即可解決工作停滯的問題。

    未啟用 Streaming Engine

    如果 Dataflow 偵測到串流工作未啟用 Streaming Engine，就會顯示以下訊息：

    This job isn't using Streaming Engine. It might benefit from having Streaming Engine enabled.

    使用 Streaming Engine 有多種潛在優點，包括更完善的水平自動調度資源功能、更優異的支援服務，以及減少工作人員 VM 的 CPU、記憶體和永久磁碟儲存空間資源用量。Streaming Engine 也支援以資源為準的計費方式。