瞭解運算單元

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

以量計價和以容量為準的計價方式

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

根據預設，系統會採用隨選模式計費。採用這種模式時，系統會根據每項查詢處理的資料量 (以 TiB 為單位) 收費。使用隨選模式的專案會受到專案和機構的每個機構代碼配額限制，並具有暫時的爆量功能。大多數隨選模式使用者都認為配額容量十分充足。不過，視工作負載而定，存取更多配額可能會提升查詢效能。如要查看帳戶的配額用量，請參閱「監控健康狀態、資源用量和作業」。

以容量為準的模式會根據查詢分配的運算單元容量計費。這個模式可讓您明確控管總時段容量。 您可透過預留項目明確選擇要使用的運算單元數量。 您可以將預留項目的運算單元數量指定為一律會分配的基準量，也可以指定為視需要分配的自動調度量。自動調度資源運算單元的預留項目會調度容量，以因應工作負載需求。BigQuery 會隨著工作負載變化分配運算單元。您可以根據使用預留項目的工作負載效能或重要性，設定預留項目中的運算單元數量。

使用運算單元執行查詢

BigQuery 執行查詢工作時，會將 SQL 陳述式轉換成執行計畫，其中包含一系列的查詢「階段」。階段則是由一組執行步驟組成。BigQuery 使用分散式平行架構執行查詢。階段會模擬可平行執行的工作單元。階段之間會透過分散式重組架構傳遞資料，如要瞭解詳情，請參閱這篇Google Cloud 網誌文章。

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 運算單元資源需求量偏高時，系統會優先分配容量，以管理資源爭用情形。這項優先順序機制可確保容量模式等級較高的客戶較不受影響。系統會依下列順序優先分配容量：

  1. Enterprise Plus 和 Enterprise 版的基準和承諾容量。
  2. Enterprise Plus 自動調整容量。
  3. Enterprise 版自動調度容量。
  4. 標準版和隨選容量。

如果某個地區發生爭用情形，系統會優先將資源分配給較高階的版本，因此標準版和隨選容量要求較有可能發生存取延遲。

BigQuery 中的公平排程

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

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

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

  • 每當您提交新的查詢時，系統會自動把運算能力重新分配給所有執行中的查詢。隨著每個查詢可用的運算能力越來越多，個別的工作單元就能順利地、暫停、繼續執行，以及加入佇列。
  • 每當有查詢執行完畢時，系統會立刻自動將該查詢占用的運算能力提供給所有其他的查詢使用。
  • 每次有查詢因為自己動態 DAG 的改變，導致運算能力的需求變更時，BigQuery 都會自動重新評估該查詢與所有其他查詢的運算能力可用性，並在必要時重新分配及暫停使用運算單元。
在多個查詢之間公平排定 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 會在需要時，立即將閒置運算單元分配給已指派的預留項目。如果原始預留項目需要，系統會快速搶占其他預留項目使用的閒置運算單元。由於這項搶占作業並非即時進行，閒置運算單元可能會在短時間內不平均地分配給各個預留項目，但 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。不過，設為 true 的預留項目可以與其他預留項目共用閒置運算單元。ignore_idle_slots

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

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

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

以預留項目為基礎的公平性機制

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

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

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

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

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

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

閒置運算單元會分配給其他預留項目。

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

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

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

請避免僅依賴閒置運算單元處理時間要求嚴格的正式版工作負載，這類工作必須使用基準或自動調度運算單元。建議您將閒置運算單元用於優先順序較低的工作，因為系統隨時可能搶占這些運算單元。

運算單元自動調度資源

下一節將討論自動調度資源的時段，以及這類時段如何與預訂項目搭配運作。

使用自動調度資源預留項目

您不必先購買運算單元承諾，即可建立自動調整規模的預留項目。運算單元承諾使用可為持續使用的運算單元提供折扣費率，但使用自動調度資源預留時，這類承諾使用並非必要。如要建立自動調度預留項目，請為預留項目指派運算單元數量上限 (預留項目大小上限)。如要找出自動調度資源運算單元數量上限，請從預留項目大小上限中，扣除分配給預留項目的任何基準運算單元 (視需要)。

建立自動調度資源預留項目時，請注意下列事項：

  • BigQuery 會近乎即時地調度預留項目，直到達到執行工作所需的運算單元數量，或是達到預留項目可用的運算單元數量上限為止。運算單元數量一律會自動調度為 50 的倍數。
  • 系統會根據實際用量調高容量，並將用量進位至最接近的 50 個時段增量。
  • 自動調整的運算單元會按照相關聯版本的容量運算定價計費。系統會根據擴充的運算單元數量收費，而非實際使用的運算單元數量。即使導致 BigQuery 擴充的工作失敗，仍須支付這筆費用。因此，請勿使用工作資訊結構定義來比對帳單。請改為參閱「使用資訊結構定義監控自動調度」。
  • 雖然配額一律會以 50 的倍數擴充，但單一步驟中可能會擴充超過 50 個配額。舉例來說，如果工作負載需要額外 450 個運算單元，BigQuery 可以嘗試一次擴充 450 個運算單元，以滿足容量需求。
  • 當與預留項目相關聯的工作不再需要容量時，BigQuery 會縮減規模。根據預設，容量的計費單位為秒，且有 1 分鐘的最低使用費用。您可以選擇在預訂層級啟用 BigQuery 彈性調度，並依秒計費，且沒有最短時間限制。

自動調度的容量至少會保留 60 秒。這段 60 秒的期間稱為縮減視窗。容量出現任何新尖峰時，系統會重設縮減視窗，並將整個容量層級視為新的授權。不過，如果自上次增加容量以來已超過 60 秒，且需求量較低，系統就會減少容量，但不會重設縮減時間範圍，因此可連續減少容量，不會造成延遲。

舉例來說，如果初始工作負載容量擴充至 100 個時段，系統會保留尖峰容量至少 60 秒。如果工作負載在縮減期間擴充至 200 個時段的新尖峰容量，系統會開始新的 60 秒縮減期間。如果工作負載在這段期間沒有達到新的尖峰容量，系統會在 60 秒結束時開始縮減工作負載。

請參考以下詳細範例：12:00:00 時，初始容量會擴充至 100 個配額，且用量會持續一秒。系統會從 12:00:00 開始，至少保留 60 秒的尖峰用量。60 秒過後 (12:01:01)，如果新用量為 50 個配額，BigQuery 會縮減至 50 個配額。如果 12:01:02 時新用量為 0 個配額，BigQuery 會再次立即縮減至 0 個配額。縮減時間視窗結束後，BigQuery 可以連續多次縮減，不需要新的縮減時間視窗。

BigQuery 彈性調度

BigQuery 彈性調度資源可免除標準自動調度資源的一分鐘最短時間限制，並以秒為單位調整運算單元容量。這項功能不會改變 50 個位置的縮放增量。

為快速因應預訂需求，BigQuery 彈性調度功能會以短時間增量為單位，在預訂項目之間分配閒置運算單元，因此分配到的閒置運算單元數量會略多於或少於預訂項目的確切公平分配量。

如需如何啟用這項功能的操作說明，請參閱「更新預訂」。

如要瞭解如何使用自動調度資源功能，請參閱「管理工作負載預留項目」。

使用預留項目搭配基準和自動調度資源運算單元

除了指定預留項目大小上限，您也可以選擇性指定每個預留項目的基準運算單元數量。基準是指一律會分配給預留項目的運算單元最小數量，而且必定會產生這個數量的運算單元費用。只有在所有基準運算單元 (和閒置運算單元，如有) 都用完後，系統才會新增自動調度資源運算單元。您可以將一個預留項目的閒置基準運算單元，分享給其他需要容量的預留項目。

每隔幾分鐘，您就可以增加預訂的基準運算單元數量。如要減少基準運算單元，如果最近變更了基準運算單元容量，且基準運算單元超過已承諾的運算單元，則每小時只能減少一次。否則，每隔幾分鐘即可減少基準運算單元。

基線和自動調度資源運算單元會根據您最近的工作負載提供容量。如果您預期會出現與近期工作負載差異極大的大型工作負載，建議您在活動前增加基線容量，而不是依賴自動調度資源運算單元來涵蓋工作負載容量。如果增加基線容量時發生問題，請等待 15 分鐘後重試要求。

如果預留項目沒有基準運算單元，或未設定從其他預留項目借用閒置運算單元，BigQuery 就會嘗試擴充。否則，必須先充分運用基準運算單元，才能進行擴充。

預留項目會依據下列優先順序使用及新增運算單元：

  1. 基準運算單元。
  2. 閒置運算單元共用功能 (如果已啟用)。預留項目只能共用其他預留項目的閒置基準或已承諾運算單元，且這些預留項目必須以相同版本和區域建立。
  3. 自動調度運算單元。

在下列範例中，運算單元會從指定的基準量開始擴充。etl 和 dashboard 預留項目的基準大小分別為 700 和 300 個運算單元。

不含承諾的自動調整資源範例。

在這個範例中，etl 預留項目可擴充至 1300 個運算單元 (700 個基準運算單元加上 600 個自動調度運算單元)。如果 dashboard 預留項目未使用中，且沒有任何工作在 dashboard 預留項目中執行，etl 預留項目就能使用 dashboard 預留項目的 300 個運算單元，最多可達 1,600 個運算單元。

dashboard 預留項目可擴充至 1100 個運算單元 (300 個基準運算單元加上 800 個自動調度運算單元)。如果 etl 預留項目完全閒置，dashboard 預留項目最多可擴充至 1800 個運算單元 (300 個基準運算單元加上 800 個自動調度運算單元，以及 etl 預留項目中的 700 個閒置運算單元)。

如果 etl 預留項目需要超過 700 個一律可用的基準運算單元，系統會依序嘗試使用下列方法新增運算單元：

  1. 700 個基準運算單元。
  2. 閒置運算單元會與 dashboard 預留項目中的 300 個基準運算單元共用。只有以相同版本建立的預留項目，才能共用預留項目的閒置基準運算單元。
  3. 將運算單元擴充 600 個，達到預留項目大小上限。

使用運算單元承諾使用合約

以下範例顯示如何使用容量承諾自動調整資源配置。

自動調度預留項目，並搭配容量承諾使用。

與預留項目基準類似，運算單元承諾使用合約可讓您分配固定數量的運算單元，供所有預留項目使用。與基準時段不同，承諾時段在約期內無法縮短。運算單元承諾使用合約為選用功能，但如果長期需要基準運算單元，可藉此節省費用。運算單元承諾使用合約可用於支付預留項目的基準運算單元費用。任何未使用的運算單元容量，都會以閒置運算單元的形式，在其他預留項目之間共用。運算單元承諾使用合約不適用於自動調度資源運算單元。為確保您能以折扣費率使用已承諾的運算單元，請確認您承諾的運算單元數量足以涵蓋基準運算單元。

在這個範例中，您需要為容量承諾運算單元支付預先定義的費率。自動調度資源功能啟動後，預留項目會進入擴充狀態，您需要為自動調度資源運算單元支付自動調度資源費率。自動調度資源費率的計費依據是擴充的運算單元數量，而非使用的運算單元數量。

以下範例顯示預訂內容，其中基準時段數超過已承諾時段數。

基準運算單元數量超過承諾使用的運算單元數量。

在這個範例中，兩個預留項目共有 1,000 個基準運算單元，etl 預留項目有 500 個，dashboard 預留項目也有 500 個。不過，承諾方案只涵蓋 800 個運算單元。在這種情況下，多出的運算單元會以隨用隨付 (PAYG) 費率計費。

可用的運算單元數量上限

如要計算預留項目可使用的運算單元數量上限，請將基準運算單元數量、自動調度運算單元數量上限，以及以相同版本建立且未納入基準運算單元的承諾運算單元數量加總。以下範例的設定如下：

自動調度預留項目，並搭配容量承諾使用。

  • 每年 1000 個運算單元的容量承諾。這些運算單元會指派為 etl 預留項目和 dashboard 預留項目的基準運算單元。
  • 指派給 etl 預留項目的 700 個基準運算單元。
  • 指派給 dashboard 預留項目的 300 個基準運算單元。
  • 將「etl」預訂的運算單元自動調度上限設為 600。
  • dashboard 預留項目的自動調度運算單元為 800 個。

以 etl 預留項目為例，運算單元數量上限等於 etl 基準運算單元 (700) 加上 dashboard 基準運算單元 (300，如果所有運算單元都處於閒置狀態) 加上自動調度運算單元數量上限 (600)。因此，在這個範例中，etl 預留項目可使用的運算單元數量上限為 1600。這個數字超過容量承諾中的數量。

在下列範例中，年約方案的運算單元數超過指派的基準運算單元數。

如何計算預留項目的可用運算單元最大數量。

在這個範例中，我們有：

  • 承諾每年使用 1600 個運算單元。
  • 預留項目大小上限為 1500 個運算單元 (包括 500 個自動調度運算單元)。
  • 指派給 etl 預留項目的 1000 個基準運算單元。

預留項目可用的運算單元數量上限，等於基準運算單元數量 (1000)，加上未專用於基準運算單元的任何承諾閒置運算單元 (1600 個年度運算單元 - 1000 個基準運算單元 = 600)，再加上自動調度運算單元數量 (500)。因此，這個預留項目的運算單元數量上限為 2100。自動調度運算單元是超出容量承諾的額外運算單元。

自動調度資源最佳做法

  • 首次使用自動配置器時，請根據過去和預期的效能，將自動調度資源運算單元數量設為有意義的數字。建立預留項目後，請主動監控失敗率、效能和帳單，並視需要調整自動調度資源運算單元數量。

  • 自動調度器至少要 1 分鐘後才會縮減資源，因此請務必設定自動調度資源的上限，以平衡效能和成本。如果自動調度資源的上限過高，且工作可以在幾秒內使用所有資源完成工作，您仍須支付整分鐘的資源上限費用。如果將資源上限調低一半，預留資源就會減少，工作在這段時間內可以使用更多 slot_seconds，減少浪費。如需判斷資源需求量的協助，請參閱「監控工作效能」。如要判斷資源需求量，也可以參閱「查看版本資源建議」。

  • 運算單元用量有時可能會超過基準運算單元加上調度運算單元的總和。如果運算單元用量超過基準運算單元加上縮放運算單元，您就不必支付相關費用。

  • 自動配置器最適合用於大量長時間執行的工作負載，例如含有多個並行查詢的工作負載。請避免一次傳送一個查詢，因為每個查詢都會擴充預留量，且擴充狀態至少會維持 1 分鐘。如果您持續傳送查詢，導致工作負載維持不變，設定基準並購買使用承諾，就能以折扣價取得固定容量。

  • BigQuery 自動調度資源取決於運算能力可用性。BigQuery 會根據過往用量，盡量滿足客戶的容量需求。如要確保容量，您可以視需要設定運算單元基準，也就是保留項目中保證的運算單元數量。使用基準時，系統會立即提供配額，無論您是否使用，都必須支付費用。如要確保容量可因應大型非自然需求 (例如高流量的節慶假日)，請提前數週與 BigQuery 團隊聯絡。

  • 系統一律會收取基準運算單元費用。如果容量承諾到期，您可能需要手動調整預留項目中的基準運算單元數量，以免產生不必要的費用。舉例來說，假設您有 100 個運算單元的 1 年期承諾，以及 100 個基準運算單元的預訂。承諾期限到期，且沒有續約方案。使用承諾到期後，您需要以即付即用費率支付 100 個基準運算單元的費用。

監控自動調度資源

如要瞭解如何監控自動調度資源的時段用量和工作效能，請參閱「監控自動調度資源」。

超出配額的運算單元用量

如果工作佔用運算單元的時間過長，可能會獲得不公平的運算單元配額。為避免延遲，BigQuery 允許其他工作借用額外的運算單元，導致運算單元總用量在一段時間內超過您指定的運算單元容量。任何超額的運算單元用量只會歸因於獲得不公平配額的工作。

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

請注意，系統可能會預先借用部分時段，以減少日後延遲，並提供其他好處，例如降低時段成本變異性和減少尾端延遲。借用時段的數量不得超過總時段容量的一小部分。