瞭解運算單元
BigQuery 運算單元是 BigQuery 用來執行 SQL 查詢、Python 程式碼或其他虛擬運算單元的工作類型。執行查詢時，BigQuery 會自動判斷查詢使用的運算單元數量。使用的運算單元數量取決於處理的資料量、查詢的複雜程度，以及可用的運算單元數量。一般來說，運算單元越多，就能執行更多並行查詢，複雜查詢的執行速度也會更快。
所有查詢都會使用運算單元，但您可以選擇兩種計費方式：以量計價模式或以運算資源為準的計價模式。
根據預設，系統會採用以量計價模式收費。採用這個模式時，系統會根據各項查詢處理作業的資料量 (以 TiB 為單位) 向您收費。使用隨選模式的專案須遵守專案和機構的運算單元限制，並具備暫時爆量功能。對於採用隨選模式的大多數使用者來說，運算單元容量上限已綽綽有餘。不過，視工作負載而定，使用更多運算單元可能會提升查詢效能。如要查看帳戶使用的運算單元數量，請參閱「監控健康狀態、資源使用率和工作」。
以容量為基礎的模式會根據您在一段時間內為查詢分配的運算單元容量計費。這個模式可讓您明確控管總時段容量。您可透過保留項目明確選擇要使用的運算單元數量。您可以將預留項目的運算單元數量指定為一律會分配的基準量，或是視需要分配的自動調度量。自動調度運算單元預留項目會調度容量，以因應工作負載需求。BigQuery 會在工作負載變更時分配運算單元。自動調度運算單元的保留項目僅適用於 BigQuery 版本。您可以根據使用預留項目的工作負載效能或重要性，設定預留項目中的運算單元數量。
使用運算單元來執行查詢
BigQuery 執行查詢工作時，會將 SQL 陳述式轉換成執行計畫，其中包含一系列的查詢「階段」。階段則是由一組執行步驟組成。BigQuery 使用分散式平行架構執行查詢。階段會模擬可平行執行的工作單元。階段之間會透過分散式重組架構傳遞資料，如要瞭解詳情，請參閱這篇Google Cloud 網誌文章。
BigQuery 查詢的執行作業是動態的。查詢處理期間，您可以修改查詢方案。隨著階段的加入，工作分配可針對資料分配進行最佳化。此外，查詢執行作業的運算能力可能會隨著其他查詢開始或完成，或是自動調度器將運算單元新增至預留項目而變更。
BigQuery 可同時執行好幾個階段，可使用推測性執行來加快查詢的執行速度，且可將階段以動態的方式重新分割，以便獲得最佳的平行處理能力。
運算單元資源經濟
如果查詢要求的運算單元數量高於可用數量，BigQuery 就會將個別的工作單元加入佇列，並等待運算單元變成可用。隨著查詢作業取得進展及運算單元釋出時，這些佇列中的作業單元會以動態方式開始執行。
BigQuery 可以針對特定的查詢階段，要求任何數量的運算單元。而 BigQuery 要求的運算單元數量，與您購買的運算能力無關，它只代表 BigQuery 針對該階段所選擇的最佳平行處理係數而已。BigQuery 會把工作單位加入佇列，並在有運算單元可用時執行這些工作單位。
當查詢要求的運算單元數量高於您購買的數量時，我們不會針對額外的運算單元向您收費，也不會按照額外的隨選費率向您收費。BigQuery 就只是把個別的工作單位加入佇列而已。
例如，假設使用者要求系統 將文字從英文翻譯成法文
- 某個查詢階段要求 2,000 個運算單元，但可用的運算單元只有 1,000 個。
- BigQuery 會用掉所有 1,000 個運算單元，並讓剩下的 1,000 個運算單元加入佇列。
- 之後，如果有 100 個運算單元完成工作，它們就會以動態的方式，從佇列中的 1,000 個工作單元裡挑出 100 個工作單元。此時佇列中還有 900 個工作單位。
- 之後，如果有 500 個運算單元完成工作，它們就會以動態的方式，從佇列中的 900 個工作單元裡挑出 500 個工作單元。此時佇列中還有 400 個工作單位。
如果工作負載需要的運算單元超出預訂方案的可用量，工作執行時間可能會增加，因為工作會等待運算單元可用。這就是所謂的「運算單元爭用」。如果工作負載需求遠大於預訂可用的時段，時段爭用情況可能會增加。
BigQuery 中的公平排程
BigQuery 會使用稱為「公平排程」的演算法，在單一保留項目中分配運算單元容量。
BigQuery 排程器會強制將運算單元平均分配給保留項目中執行查詢的專案，然後再分配給指定專案中的工作。排程器會提供最終的公平性。在短時間內，某些工作可能會分配到不成比例的運算單元數量，但排程器最終仍會修正這個問題。排程器的目標是找出平衡點，避免過於嚴格的作業 (清空執行中的工作會浪費運算單元時間) 和過於寬鬆的作業 (長時間執行作業的工作會佔用不成比例的運算單元時間)。
公平排程可確保每個查詢隨時都能存取所有可用的運算單元，並在每個查詢的運算能力需求改變時，動態地將運算能力自動重新分配給所有執行中的查詢。在下列情況下，每當有查詢執行完畢，以及新的查詢送交執行時：
- 每當您提交新的查詢時，系統會自動把運算能力重新分配給所有執行中的查詢。隨著每個查詢可用的運算能力越來越多，個別的工作單元就能順利地、暫停、繼續執行，以及加入佇列。
- 每當有查詢執行完畢時，系統會立刻自動將該查詢占用的運算能力提供給所有其他的查詢使用。
- 每次有查詢因為自己動態 DAG 的改變，導致運算能力的需求變更時，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。不過，設為 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 允許其他工作借用額外的運算單元，因此總運算單元用量可能會超過您指定的運算單元容量。只有獲得超過公平分配額度的工作，才會計入任何超出額度的使用量。
系統不會直接向您收取超出配額的費用。工作會繼續執行，並以公平的比例累積使用配額，直到您分配的容量足以涵蓋所有超額用量為止。系統會從回報的時段用量中排除多餘時段，但特定詳細執行統計資料除外。
請注意，系統可能會預先借用部分時段，以減少日後延遲，並提供其他好處，例如降低時段成本變異性和尾端延遲。運算單元借用量不得超過運算單元總容量的一小部分。