瞭解運算單元

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

雖然所有查詢都會使用運算單元，但您可以選擇以以量計價或以運算資源為基礎的定價模式計費。

根據預設，系統會使用以量計價的模式向您收費。採用這個模式時，系統會根據各項查詢處理的資料量 (以 TiB 為單位) 向您收費。使用隨選型模型的專案必須符合每個專案和每個機構的運算單元限制，並具備暫時性大量傳輸能力。在按需模式中，大多數使用者都認為運算單元容量限制已綽綽有餘。不過，視工作負載而定，使用更多運算單元可能會提升查詢效能。如要查看帳戶使用的運算單元數量，請參閱「BigQuery 監控」一文。

採用容量型模式時，您需要為查詢分配的運算單元容量支付費用。相較於以量計價模式，運算單元計價模式可讓您明確控管總運算單元容量。您可以透過保留明確選擇要使用的運算單元數量。您可以將預留項目中的運算單元數量指定為一律會分配的基準數量，或是指定為自動調度的數量，在需要時才會分配。

使用運算單元來執行查詢

當 BigQuery 執行查詢工作時，會將 SQL 陳述式轉換成執行計畫，並將執行作業拆分成一系列的查詢「階段」，而這些階段是由更精細的執行步驟組合所組成的。BigQuery 會使用高度分散的平行架構來執行這些查詢，而這些階段則會建立許多潛在工作站可能並行執行的工作單元模型。這些階段會透過快速的分散式重組架構來彼此通訊，而我們會在 Google Cloud 部落格中詳細討論這種架構。

BigQuery 查詢的執行作業是動態的，這代表查詢計畫可以在查詢執行期間修改。而在查詢執行期間所引進的階段，通常是用來改善資料在所有查詢工作站之間的分布狀況。此外，當其他查詢完成或開始執行，或是自動配置器在預留時新增運算單元時，可用運算能力的數量可能會變動，進而影響查詢執行作業。

BigQuery 可同時執行多個階段，可使用推測性執行來加快查詢的執行速度，且可以動態的方式重新分割階段，以便獲得最佳的平行處理能力。

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

查詢運算單元。

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

運算單元資源經濟

如果查詢要求的運算單元數量超過可用數量，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 中，您執行需要 100 個運算單元才能執行的查詢 A (一個並行查詢)，而在專案 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 中執行可使用 500 個運算單元的 query_a。

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

在這個範例中，如果 project_b 指派給沒有基準運算單元或自動調度資源的預留項目，query_b 在 query_a 開始執行後就不會有運算單元。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 工作未佔用保留項目中的運算單元時，ML_EXTERNAL 和 QUERY 指派類型同時存在的保留項目中的運算單元，只能供其他查詢工作使用。此外，這些工作也無法使用其他預留項目的閒置運算單元。

以預留為準的平衡機制

透過以保留項目為準的平衡機制，無論每個保留項目中執行的工作專案數量為何，BigQuery 都會優先處理並平均分配閒置的運算單元，以便在同一個管理專案中執行。每個預留項目都會在閒置運算單元集區中獲得類似的可用容量，然後將運算單元平均分配給各專案。這項功能僅支援 Enterprise 或 Enterprise Plus 版本。

下圖顯示在未啟用預留制公平性功能的情況下，空閒時段的分配方式：

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

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

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

下圖顯示啟用預留制公平性功能後，空白時段的分配方式：

閒置的運算單元會在多個預留項目之間共用。

在這個圖表中，閒置的運算單元會平均分配給保留項目，而非專案。

啟用以預留為準的平衡機制後，可用的閒置運算單元會平均分配給各預留項目。

啟用預留制公平性功能後，請查看資源用量，以便管理時段可用性和查詢效能。

請勿將實際工作負載的工作時間限制設得過嚴，以免導致閒置運算單元不足。這類工作應使用基準運算單元或自動調度運算單元。建議您將閒置的執行序用於較低優先順序的工作，因為執行序可隨時先佔。

運算單元用量過多

如果工作保留運算單元太久，可能會獲得不公平的運算單元分配。為避免延遲，BigQuery 允許其他工作借用額外的運算單元，導致運算單元使用量超過指定的運算單元容量。任何超出配額的使用量，都只會歸因於工作獲得的配額超過應有的份額。

系統不會直接向您收取多餘的廣告位上傳費用。相反地，工作會繼續執行，並以公平分配的方式累積分割槽用量，直到所有超出用量都涵蓋在您指派的容量範圍內為止。除了某些詳細執行統計資料外，系統會將多餘的空白處排除在已回報的空白處用量之外。

請注意，系統可能會預先借用部分時段，以減少未來的延遲情形，並提供其他好處，例如減少時段費用的變化情形，以及減少尾端延遲時間。運算單元借用功能僅限於總運算單元容量的一小部分。