取得查詢效能洞察資料

查詢的執行圖是 BigQuery 執行查詢所需步驟的視覺化呈現。本文將說明如何使用查詢執行圖來診斷查詢效能問題，以及如何查看查詢效能洞察。

BigQuery 提供強大的查詢效能，但它也是一個複雜的分散式系統，其中包含許多可能影響查詢速度的內部和外部因素。SQL 的宣告性質也可以隱藏查詢執行的複雜性。也就是說，如果查詢執行速度不如預期，或比先前執行的速度慢，要瞭解發生的情況可能會相當困難。

查詢執行圖表提供動態圖形介面，可用於檢查查詢計畫和查詢效能詳細資料。您可以查看任何執行中或已完成查詢的查詢執行圖。

您也可以使用查詢執行圖，取得查詢的成效深入分析資料。效能深入分析會提供最佳效能建議，協助您提高查詢效能。由於查詢效能是多面向的，效能深入分析可能只會顯示查詢效能的局部資訊，而非整體情況。

所需權限

如要使用查詢執行圖表，您必須具備下列權限：

• bigquery.jobs.get
• bigquery.jobs.listAll

您可以透過下列 BigQuery 預先定義的 Identity and Access Management (IAM) 角色取得這些權限：

• roles/bigquery.admin
• roles/bigquery.resourceAdmin
• roles/bigquery.resourceEditor
• roles/bigquery.resourceViewer

執行圖結構

查詢執行圖會在主控台中以圖形方式顯示查詢計畫。每個方塊都代表查詢計畫中的階段，例如：

• 輸入：從資料表讀取資料或選取特定欄
• 彙整：根據 JOIN 條件合併兩個資料表的資料
• 匯總：執行 SUM 等計算
• 排序：排序結果

階段由步驟組成，用來說明階段中每個 worker 執行的個別作業。您可以按一下階段來開啟並查看其步驟。階段也包含相對和絕對時間資訊。階段名稱會概述各階段執行的步驟。舉例來說，名稱中含有「join」的階段表示該階段的主要步驟為 JOIN 作業。結尾有 + 的階段名稱表示會執行其他重要步驟。舉例來說，名稱中含有 JOIN+ 的階段表示該階段會執行彙整作業和其他重要步驟。

連接各階段的線條代表各階段之間交換的中介資料。在執行階段時，BigQuery 會將中繼資料儲存在洗牌記憶體中。邊緣上的數字代表階段之間交換的資料列預估數量。洗牌記憶體配額與分配給帳戶的運算單元數量相關。如果超出重組配額，重組記憶體可能會溢出至磁碟，導致查詢效能大幅降低。

查看查詢成效洞察

主控台

如要查看查詢成效洞察，請按照下列步驟操作：

1. 在 Google Cloud 控制台開啟「BigQuery」頁面。

   前往「BigQuery」頁面

2. 在「編輯器」中，按一下「個人記錄」或「專案記錄」。

3. 在工作清單中找出你感興趣的查詢工作。按一下 「動作」，然後選擇「在編輯器中開啟查詢」。

4. 選取「執行圖」分頁，即可以圖表形式查看查詢的各個階段：

   

   如要判斷查詢階段是否有效能深入分析資料，請查看顯示的圖示。有 資訊圖示的階段會顯示效能洞察資料。有 勾選圖示的階段則不會。

5. 按一下階段即可開啟階段詳細資料窗格，查看下列資訊：

   • 階段的查詢計畫資訊。
   • 在階段中執行的步驟。
   • 任何適用的成效洞察資料。

   

6. 選用：如果您要檢查正在執行的查詢，請按一下 「Sync」來更新執行圖表，以便反映查詢的目前狀態。

   

7. 選用：如要依階段持續時間在圖表中醒目顯示前幾個階段，請按一下「醒目顯示持續時間最長的階段」。

   

8. 選用：如要依圖表中使用的時段時間醒目顯示前幾個階段，請按一下「醒目顯示處理時間最長的階段」。

   

9. 選用：如要在圖表中加入重組重新分配階段，請按一下「顯示重組重新分配階段」。

   

   使用這個選項，即可顯示在預設執行圖中隱藏的重新分割和合併階段。

   在查詢執行期間引進的重新分割和合併階段，用於改善處理查詢的 worker 之間的資料分布狀況。由於這些階段與查詢文字無關，因此會隱藏這些階段，以簡化顯示的查詢計畫。

對於任何有效能回歸問題的查詢，系統也會在查詢的「工作資訊」分頁中顯示效能深入分析資料：

SQL

1. 前往 Google Cloud 控制台的「BigQuery」頁面。

   前往 BigQuery

2. 在查詢編輯器中輸入以下陳述式：

   SELECT
     `bigquery-public-data`.persistent_udfs.job_url(
       project_id || ':us.' || job_id) AS job_url,
     query_info.performance_insights
   FROM
     `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
   WHERE
     DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history
     AND job_type = 'QUERY'
     AND state = 'DONE'
     AND error_result IS NULL
     AND statement_type != 'SCRIPT'
     AND EXISTS ( -- Only include queries which had performance insights
       SELECT 1
       FROM UNNEST(
         query_info.performance_insights.stage_performance_standalone_insights
       )
       WHERE slot_contention OR insufficient_shuffle_quota
       UNION ALL
       SELECT 1
       FROM UNNEST(
         query_info.performance_insights.stage_performance_change_insights
       )
       WHERE input_data_change.records_read_diff_percentage IS NOT NULL
     );

3. 按一下 「Run」。

如要進一步瞭解如何執行查詢，請參閱「執行互動式查詢」一文。

API

您可以呼叫 jobs.list API 方法，並檢查傳回的 JobStatistics2 資訊，以非圖形格式取得查詢效能深入分析資料。

解讀查詢效能洞察資料

請參閱本節，進一步瞭解效能洞察資料的含義，以及如何解決相關問題。

成效洞察資訊適用於兩類目標對象：

• 分析師：您會在專案中執行查詢。您想瞭解為何先前執行的查詢速度變慢，並想知道如何提升查詢效能。您具備「必要權限」一節所述的權限。

• Data Lake 或資料倉儲管理員：管理貴機構的 BigQuery 資源和預留作業。您具備與 BigQuery 管理員角色相關的權限。

以下各節會根據您擔任的角色，提供如何處理收到的成效洞察資料的相關指引。

運算單元爭用情況

執行查詢時，BigQuery 會嘗試將查詢所需的工作拆分為工作。工作是指單一資料切片，可輸入至階段並從中輸出。單一時段會接收工作，並執行該階段的資料切片。理想情況下，BigQuery 分區會並行執行這些工作，以便達到高效能。如果查詢有許多工作準備開始執行，但 BigQuery 無法取得足夠的可用運算單元來執行這些工作，就會發生運算單元爭用情形。

分析師的處理方式

請按照「減少查詢處理的資料」一文中的指示，減少查詢中處理的資料量。

管理員應採取的行動

您可以採取下列行動，增加運算單元可用性或減少運算單元使用量：

• 如果您採用 BigQuery 的以量計價方案，查詢會使用共用運算單元集區。建議您改為購買保留空間，以便改用以容量為準的分析價格。保留項目可讓您為貴機構的查詢預留專屬運算單元。

• 如果您使用 BigQuery 保留項目，請確認保留項目中指派給執行查詢的專案有足夠的運算單元。在下列情況下，預留空間可能會不足：

  • 其他工作正在使用保留運算單元。您可以使用管理員資源圖表，瞭解貴機構如何使用預留空間。
  • 預留空間的運算單元數量不足，無法快速執行查詢。您可以使用時段估算器，預估需要多少預留空間，才能有效處理查詢工作。

  如要解決這個問題，請嘗試下列任一解決方案：

  • 在該預留項目中新增更多運算單元 (基準運算單元或預留項目運算單元數量上限)。
  • 建立額外的預留項目，並指派給執行查詢的專案。
  • 將耗用大量資源的查詢分散在保留期間或不同保留期間。

• 請確認您要查詢的資料表已叢集。叢集功能有助於確保 BigQuery 能快速讀取含有相關資料的資料欄。

• 請確認您要查詢的資料表已分區。對於未分割的資料表，BigQuery 會讀取整個資料表。分區資料表有助於確保您只查詢感興趣的資料表子集。

重組配額不足

在執行查詢之前，BigQuery 會將查詢邏輯分割為階段。BigQuery 運算單元會執行各個階段的工作。當運算單元完成階段工作執行作業時，會將中繼結果儲存在 shuffle 中。查詢中的後續階段會讀取 Shuffle 中的資料，以便繼續執行查詢。如果需要寫入重組的資料量超過重組容量，就會發生重組配額不足的情況。

分析師的處理方式

與插槽爭用情況類似，減少查詢處理的資料量可能會降低 shuffle 使用量。如要這麼做，請按照「減少查詢中處理的資料」一文中的指示操作。

SQL 中的某些作業通常會更廣泛地使用 shuffle，尤其是 JOIN 作業和 GROUP BY 子句。盡可能減少這些作業中的資料量，或許可以降低隨機播放的用量。

管理員應採取的行動

請採取下列行動，減少隨機播放配額爭用情形：

• 與運算單元爭用情況類似，如果您使用 BigQuery 的以量計價，查詢會使用共用運算單元集區。建議您改為購買保留空間，以便改用以容量為準的分析價格。預留項目可為專案查詢提供專屬運算單元和重組容量。

• 如果您使用 BigQuery 預留項目，運算單元會提供專屬的隨機播放容量。如果您的保留項目執行的查詢大量使用隨機排序功能，可能會導致其他同時執行的查詢無法取得足夠的隨機排序容量。您可以查詢 INFORMATION_SCHEMA.JOBS_TIMELINE 檢視畫面中的 period_shuffle_ram_usage_ratio 欄，找出哪些工作大量使用隨機播放功能。

  如要解決這個問題，請嘗試下列一或多個解決方案：

  • 為該預訂項目新增更多運算單元。
  • 建立額外的預留項目，並指派給執行查詢的專案。
  • 將重組量高的查詢分散到保留期間或不同保留項目。

資料輸入規模調整

這項成效深入分析結果表示，查詢讀取的特定輸入資料表資料量，至少比上次執行查詢時多 50%。您可以使用資料表變更記錄，查看查詢中使用的任何資料表最近是否已增加。

分析師的處理方式

請按照「減少查詢處理的資料」一文中的指示，減少查詢中處理的資料量。

高基數彙整

如果查詢包含彙整，且彙整兩端的索引鍵不重複，輸出資料表的大小可能會比輸入資料表的大小大得多。這項洞察資料指出輸出列與輸入列的比率偏高，並提供這些列數量的相關資訊。

分析師的處理方式

請檢查彙整條件，確認輸出資料表的大小是否符合預期。避免使用交叉彙整。如果您必須使用交叉彙整，請嘗試使用 GROUP BY 子句預先匯總結果，或使用窗型函式。詳情請參閱「使用 JOIN 前減少資料」。

分區偏差

預先發布版

這項功能受《服務專屬條款》中「一般服務條款」一節的「正式發布前產品條款」規範。 正式發布前功能是依「原樣」提供，支援服務可能受限。 詳情請參閱推出階段說明。

如要提供意見回饋或針對這項功能尋求支援，請傳送電子郵件至 [e-mail]。

資料分布不均可能導致查詢執行速度變慢。執行查詢時，BigQuery 會將資料分割成小型分區。您無法在不同時段之間共用分區。因此，如果資料分布不均，部分分區會變得非常大，導致處理過大分區的運算單元異常終止。

偏差會發生在 JOIN 階段。執行 JOIN 作業時，BigQuery 會將 JOIN 作業左側和右側的資料分割為分區。如果某個區隔過大，系統會透過重新分割階段重新平衡資料。如果偏差過大，且 BigQuery 無法進一步重新平衡，則會在「JOIN」階段新增區隔偏差洞察資料。這個程序稱為重新分區階段。如果 BigQuery 偵測到無法再細分的大型分區，就會在 JOIN 階段新增分區偏差洞察資料。

分析師的處理方式

為避免分割區偏移，請盡早篩選資料。

解讀查詢階段資訊

除了使用查詢效能深入分析，您也可以在查看查詢階段詳細資料時，參考下列指南，協助判斷查詢是否有問題：

• 如果某個或多個階段的 Wait ms 值與先前執行查詢時的值相比偏高：
  • 確認您是否有足夠的插槽可用於工作負載。如果沒有，請在執行需要大量資源的查詢時進行負載平衡，以免這些查詢彼此競爭。
  • 如果「等待 ms」值高於單一階段，請查看前一個階段，看看是否有瓶頸。例如，查詢中涉及的資料表資料或結構定義發生重大變更，可能會影響查詢效能。
• 如果某個階段的亂數輸出位元組值相較於先前執行的查詢或先前階段的值偏高，請評估該階段處理的步驟，看看是否有任何步驟會產生意外大量的資料。這類錯誤的常見原因是步驟處理的 INNER JOIN 在兩個彙整項目中含有重複的鍵。這可能會傳回意外大量的資料。
• 您可以使用執行圖表，依據時間長度和處理方式查看前幾個階段。請考量這些資料產生的資料量，以及是否與查詢中參照的資料表大小相符。如果不是，請檢查這些階段中的步驟，看看是否有任何步驟可能產生意外的暫時性資料量。

後續步驟

• 請參閱查詢最佳化規範，瞭解如何改善查詢效能。