瞭解運算單元

BigQuery 運算單元是 BigQuery 用來執行 SQL 查詢或其他工作類型的虛擬運算單元。執行查詢時，BigQuery 會自動判斷查詢使用的運算單元數量。使用的運算單元數量取決於處理的資料量、查詢的複雜程度，以及可用的運算單元數量。一般來說，運算單元越多，就能執行更多並行查詢，複雜查詢的執行速度也會更快。

所有查詢都會使用運算單元，但您可以選擇兩種計費方式：以量計價模式或以運算資源為準的計價模式。

根據預設，系統會按照以量計價模式收費。採用這個模式時，系統會根據各項查詢處理作業的資料量 (以 TiB 為單位) 向您收費。使用隨選模式的專案須遵守專案和機構的運算單元限制，並具備暫時的爆量功能。對於採用隨選模式的大多數使用者來說，運算單元容量上限已綽綽有餘。不過，視工作負載而定，使用更多運算單元可能會提升查詢效能。如要檢查帳戶的運算單元配額，請參閱BigQuery 監控。

採用容量計費模式時，您會支付查詢作業在一段時間內分配到的運算單元容量費用。這個模式可讓您明確控管運算單元總容量，以量計價模式則無法。您可透過保留項目明確選擇要使用的運算單元數量。您可以將預留項目的運算單元數量指定為一律會分配的基準數量，或是視需要分配的自動調度數量。

使用運算單元來執行查詢

當 BigQuery 執行查詢工作時，會將 SQL 陳述式轉換成執行計畫，計畫中會把執行作業拆分成一系列的查詢「階段」，而這些階段是由更精細的執行「步驟」組合所組成的。BigQuery 會使用高度分散的平行架構來執行這些查詢，而這些階段則會建立許多潛在工作站可能並行執行的工作單元模型。各階段之間會透過快速的分散式重組架構傳遞資料，如需更多詳細資訊，請參閱Trusted Cloud by S3NS 這篇網誌文章。

BigQuery 查詢的執行作業是動態的，這代表查詢計畫可以在查詢執行期間修改。而在查詢執行期間所引進的階段，通常是用來改善資料在所有查詢工作站之間的分布狀況。此外，隨著其他查詢完成或開始執行，或是自動調度器將運算單元新增至預留項目，可用容量的變化也可能影響查詢執行作業。

BigQuery 可同時執行多個階段，並使用推測性執行來加快查詢速度，還可動態重新分割階段，以達到最佳平行化效果。

BigQuery 運算單元會在查詢的每個段執行個別的工作單位。舉例來說，如果 BigQuery 確定某個階段的最佳平行處理係數是 10，就會要求 10 個運算單元來處理這個階段。

查詢運算單元。

階段和步驟的查詢執行圖表

運算單元資源經濟

如果查詢要求的運算單元數量高於可用數量，BigQuery 就會將個別的工作單元加入佇列，並等待運算單元變成可用。隨著查詢作業取得進展及運算單元釋出時，這些佇列中的作業單元會以動態方式開始執行。

BigQuery 可以針對特定的查詢階段，要求任何數量的運算單元。而 BigQuery 要求的運算單元數量，與您購買的運算能力無關，它只代表 BigQuery 針對該階段所選擇的最佳平行處理係數而已。BigQuery 會把工作單位加入佇列，並在有運算單元可用時執行這些工作單位。

當查詢要求的運算單元數量高於您購買的數量時，我們不會針對額外的運算單元向您收費，也不會按照額外的隨選費率向您收費。BigQuery 就只是把個別的工作單位加入佇列而已。

例如，假設使用者要求系統 將文字從英文翻譯成法文

  1. 某個查詢階段要求 2,000 個運算單元，但可用的運算單元只有 1,000 個。
  2. BigQuery 會用掉所有 1,000 個運算單元，並讓剩下的 1,000 個運算單元加入佇列。
  3. 之後，如果有 100 個運算單元完成工作，它們就會以動態的方式，從佇列中的 1,000 個工作單元裡挑出 100 個工作單元。此時佇列中還有 900 個工作單位。
  4. 之後，如果有 500 個運算單元完成工作，它們就會以動態的方式，從佇列中的 900 個工作單元裡挑出 500 個工作單元。此時佇列中還有 400 個工作單位。

運算單元的使用時間排程。

當需求超出供給時，BigQuery 運算單元會加入佇列

BigQuery 中的公平排程

BigQuery 會使用稱為「公平排程」的演算法，在單一保留項目中分配運算單元容量。

BigQuery 排程器會強制將運算單元平均分配給保留項目中執行查詢的專案，然後再分配給指定專案中的工作。排程器會提供最終的公平性。在短時間內，某些工作可能會分配到不成比例的運算單元數量，但排程器最終仍會修正這個問題。排程器的目標是找出平衡點，避免過於嚴格的作業 (清空執行中的工作會浪費運算單元時間) 和過於寬鬆的作業 (長時間執行作業的工作會佔用不成比例的運算單元時間)。

公平調度機制可確保每個查詢隨時都能存取所有可用的運算單元，並在每個查詢的運算能力需求改變時，動態地將運算能力自動重新分配給所有執行中的查詢。在下列情況下，每當有查詢執行完畢，以及新的查詢送交執行時：

  • 每當您提交新的查詢時，系統會自動把運算能力重新分配給所有執行中的查詢。隨著每個查詢可用的運算能力越來越多，個別的工作單元就能順利地、暫停、繼續執行，以及加入佇列。
  • 每當有查詢執行完畢時，系統會立刻自動將該查詢占用的運算能力提供給所有其他的查詢使用。
  • 每次有查詢因為自己動態 DAG 的改變，導致運算能力的需求變更時，BigQuery 都會自動重新評估該查詢與所有其他查詢的運算能力可用性，並在必要時重新分配及暫停使用運算單元。

多個查詢的使用時間排程。

BigQuery 中的公平排程

視查詢的複雜程度和大小而定，查詢要求的運算單元數量，可能會低於或高於自己有權限使用的所有運算單元數量。BigQuery 會在公平排程的原則下，以動態的方式確保所有運算單元隨時都會受到充分的運用。

如果重要工作持續需要比排程器分配的運算單元數量更多，請考慮建立額外的保留項目，並分配所需數量的運算單元，然後將工作指派給該保留項目。

以公平調度為例，假設您有下列預訂設定：

  • 預留項目「A」有 1,000 個基準運算單元，且未啟用自動調度資源
  • 指派給預留項目的專案 A 和專案 B

情境 1：在專案 A 中，您執行需要大量運算單元的查詢 A (一個並行查詢)，並在專案 B 中執行 20 個並行查詢。雖然共有 21 個查詢使用預留項目 A，但運算單元分配情形如下：

  • 專案 A 收到 500 個運算單元，查詢 A 則以 500 個運算單元執行。
  • 專案 B 收到 500 個運算單元，由 20 個查詢共用。

情境 2：在專案 A 中，您執行查詢 A (一項並行查詢)，需要 100 個運算單元才能執行；在專案 B 中，您執行 20 項並行查詢。由於查詢 A 不需要 50% 的預留項目，因此運算單元分配如下：

  • 專案 A 收到 100 個運算單元，查詢 A 則以 100 個運算單元執行。
  • 專案 B 獲得 900 個運算單元，由 20 個查詢共用。

反之，請參考下列預訂設定：

  • 預留項目 B，有 1,000 個基準運算單元，且未啟用自動調度資源。
  • 10 個專案，全都指派給預留項目 B。

假設這 10 個專案執行的查詢有足夠的運算單元需求，則每個專案會獲得總預留運算單元的 1/10 (或 100 個運算單元)，與每個專案執行的查詢數量無關。

配額和限制

運算單元配額和限制可為 BigQuery 提供安全防護。不同定價模式使用的時段配額類型不同，如下所示：

  • 以量計價模式：您須遵守專案和機構的運算單元上限，並具備暫時的爆量功能。視工作負載而定，使用更多運算單元可提升查詢效能。

  • 以容量為準的價格模式：預留項目配額和限制會定義您在某個位置的所有預留項目中，可分配的運算單元數量上限。您只需支付預留項目和承諾的費用，不必支付配額費用。如要瞭解如何提高運算單元配額，請參閱「申請提高配額」一文。

如要查看您使用的運算單元數量，請參閱 BigQuery 監控。

閒置的運算單元

在任何時間，部分運算單元可能處於閒置狀態。這些實用資源包括：

  • 未分配給任何預留項目基準的運算單元使用承諾。
  • 已分配給預留項目基準，但未使用的運算單元。

使用以量計價模式時，不適用閒置運算單元。

根據預設，在保留項目中執行的查詢會自動使用同一個管理專案中其他保留項目的閒置運算單元。BigQuery 會在需要時，立即將運算單元分配給已指派的預留項目。系統會快速搶占其他預留項目使用的閒置運算單元。您可能會在短時間內看到運算單元總消耗量超過所有預留項目指定的上限，但系統不會針對這類額外運算單元用量收費。

舉例來說，假設您有下列預訂設定：

  • project_a 指派給 reservation_a，後者有 500 個基準運算單元，且未啟用自動調度資源。
  • project_b 指派給 reservation_b，後者有 100 個基準運算單元，且未啟用自動調度資源。
  • 兩個預留項目都位於同一個管理專案中，且沒有其他專案指派給這些預留項目。

您在 project_b 中執行 query_b。如果 project_a 中沒有執行任何查詢，query_b 就能使用 reservation_a 的 500 個閒置運算單元。query_b 仍在執行時，最多可能會使用 600 個位置：100 個基準位置加上 500 個閒置位置。

假設 query_b 正在執行，而您在 project_a 中執行 query_a，該查詢可使用 500 個運算單元。

  • 由於您已為 project_a保留 500 個基準運算單元，query_a 會立即啟動並分配到 500 個運算單元。
  • 分配給 query_b 的運算單元數量會迅速減少至 100 個基準運算單元。
  • project_b 中執行的其他查詢會共用這 100 個運算單元。 如果後續查詢沒有足夠的運算單元可供啟動，就會加入佇列，直到執行中的查詢完成，運算單元變成可用為止。

在這個範例中，如果 project_b 已指派給沒有基準運算單元或自動調度資源的預留項目，則 query_a 開始執行後，query_b 就沒有運算單元。BigQuery 會暫停 query_b，直到有閒置運算單元可用或查詢逾時為止。project_b 中的其他查詢會排隊，直到有閒置運算單元可用為止。

如要確保預訂只使用已佈建的時段，請將 ignore_idle_slots 設為 true。不過，ignore_idle_slots 設為 true 的預留項目可以與其他預留項目共用閒置運算單元。

不同版本的預留項目無法共用閒置運算單元。您只能分享基準運算單元或承諾運算單元。自動調度資源的運算單元 可能暫時可用，但無法做為其他預留項目的閒置運算單元共用，因為這些運算單元可能會縮減。

只要 ignore_idle_slots 設為 False，保留項目就可以將運算單元數量設為 0，並存取未使用的運算單元。如果只使用default預訂功能，建議關閉ignore_idle_slots。接著，您可以將專案或資料夾指派給該預留項目，這樣專案或資料夾就只會使用閒置運算單元。

但類型為 ML_EXTERNAL 的指派作業是例外情況，因為 BigQuery ML 外部模型建立作業使用的運算單元不具先占特性。如果保留項目同時有 ML_EXTERNAL 和 QUERY 指派類型，只有在 ML_EXTERNAL 工作未佔用運算單元時，其他查詢工作才能使用這些運算單元。此外，這些工作無法使用其他預留項目的閒置運算單元。

以預留項目為準的公平性

採用以保留項目為準的公平分配機制後，BigQuery 會優先處理同一管理員專案中所有保留項目的工作，並平均分配閒置運算單元，每個預留項目都會在閒置運算單元集區中獲得類似的可用容量配額，然後系統會將運算單元平均分配給專案。這項功能僅適用於 Enterprise 或 Enterprise Plus 版本。

下圖顯示未啟用以預訂為準的公平性時，閒置時段的分配情形：

閒置運算單元會跨專案共用。

在這個圖表中，閒置運算單元會平均分配給各個專案。

如果未啟用以預留項目為準的公平性，系統會將可用的閒置運算單元平均分配給預留項目中的專案。

下圖顯示啟用以預訂為準的公平性後，閒置時段的分配情形：

閒置運算單元會分配給各個預留項目。

在這張圖表中，閒置運算單元會平均分配給各個預訂項目，而非專案。

啟用以預留項目為準的公平性後，系統會將可用的閒置運算單元平均分配給各個預留項目。

啟用以預留項目為準的公平性後，請查看資源用量，以便管理可用的時段和查詢效能。

對於時間要求嚴格的實際工作環境工作負載，請避免只依賴閒置運算單元，這類工作應使用基準或自動調度運算單元。建議您將閒置的空位用於優先順序較低的作業，因為空位隨時可能遭到搶占。

運算單元用量超出上限

如果工作佔用運算單元的時間過長，可能會獲得不公平的運算單元分配量。為避免延遲，BigQuery 允許其他工作借用額外運算單元，因此總運算單元用量可能會超過您指定的運算單元容量。只有獲得超過公平分配額度的工作，才會耗用多餘的配額。

系統不會直接向您收取超出配額的費用。工作會繼續執行，並根據公平分配原則累積使用配額，直到您分配的容量足以支付所有超額用量為止。系統會從回報的 Slot 用量中排除多餘的 Slot，但某些詳細的執行統計資料除外。

請注意，系統可能會預先借用部分時段，以減少日後的延遲情況，並提供其他好處，例如降低時段費用變異性和減少尾端延遲。運算單元借用功能僅限於總運算單元容量的一小部分。