BigQuery 多租戶工作負載的最佳做法
本文針對多租戶資料平台和企業資料超市中使用的常見模式，提供相關技術和最佳做法。
商業企業、軟體即服務 (SaaS) 供應商和政府機構通常必須跨越地理和行政區域，安全地託管內部和第三方資料。BigQuery 是一項強大的工具，可持續滿足多租用戶平台的需求，包括跨不同業務單位的數十億位元組資料和數十萬個資料使用者。本文件適用於在 BigQuery 上部署多租戶平台的機構，以及想瞭解可用的存取權控管和效能管理功能的機構。
多租戶平台建構人員通常需要平衡以下考量事項：
- 資料隔離：實施強大控管機制，防止資料在租用戶之間外洩。
- 一致的效能：設定並分配 BigQuery 保留空間，以便在多租戶之間維持一致的效能。
- 資源管理：規劃配額和限制的影響。
- 地理分布：將資料放在指定的地理位置。如有法規遵循相關疑慮，請參閱 Google Cloud的法規遵循服務。
- 稽核和安全性：保護租用戶資料，避免遭到不當存取和外洩。
- 費用管理：確保每個租用戶的 BigQuery 費用一致。
- 作業複雜度：盡量減少系統變化量，以便託管新租戶。
使用共用租戶基礎架構的 SaaS 供應商
代管第三方資料的 SaaS 供應商需要確保整個客戶機群的可靠性和隔離性。這些客戶可能多達數萬人，且客戶資料可能會透過共用服務基礎架構存取。部分 SaaS 供應商也會維護經過淨化的中央資料儲存庫，針對整個租戶陣容進行分析。
每個租用戶都有資料集的設計有助於降低組織在擴展至數千個租用戶時，可能遇到的下列疑慮：
- 管理作業複雜度：每位客戶的新專案和雲端資源總數
- 端對端延遲：資料儲存庫對於租用戶和跨客戶分析解決方案的最新程度
- 效能預期值：確保租戶效能維持在可接受的範圍內
為每個租用戶設定資料集
在專門用於儲存客戶資料的專案中，每位客戶的資料都會以 BigQuery 資料集區隔開。在主機組織中，您可以使用第二個專案，針對合併的客戶資料部署數據分析和機器學習。接著，您可以設定資料處理引擎 Dataflow，將傳入資料以雙寫方式寫入內部和租用戶專屬的資料表。Dataflow 設定會使用已寫入的資料表，而非已授權的檢視畫面。使用已完全寫入的資料表可統一處理地理分布情形，並有助於避免在租戶數量增加時達到授權檢視限制。
與以叢集為基礎的倉儲相比，BigQuery 將儲存空間和運算資源分隔開來，可讓您設定較少專案來處理服務層級和資料隔離等問題。如果您不需要為用戶群設定額外的專屬雲端資源，建議您為每個用戶群設定預設專屬資料集。下圖為根據此建議設計的範例專案設定：
圖 1. 隨著租用戶數量增加，固定數量的專案會處理資料和處理需求。
圖 1 中的專案設定包含下列專案：
- 資料管道專案：接收、處理及發布租戶資料的核心基礎架構元件，都會封裝到單一專案中。
- 合併租用戶資料專案：核心資料專案，可為每位客戶維護資料集。租用戶資料應透過運算層專案存取。
- 內部開發專案：代表數據分析團隊用於評估租用戶資料及建構新功能的自管資源。
- 使用者應用程式專案：專案內含專門用於與使用者互動的資源。建議您使用租用戶範圍的服務帳戶存取租用戶資料集，並使用穩健安全的建構管道來部署應用程式。
- 保留項目運算層級專案：將租用戶查詢活動對應至 BigQuery 保留項目的專案。
分享預留項目
這種方法的預留作業會依據 BigQuery 保留項目內建的公平排程演算法。每個運算層級保留項目都會指派給單一專案。租用戶查詢會使用公平調度時段，這些時段可供每個運算層級專案使用，而任何層級的未使用時段都會自動在其他層級重複使用。如果租用戶有特定的時間要求，您可以使用專門提供確切運算單元數量的專案-保留項目組合。
設定 VPC Service Controls 範圍
在這種設定中，我們建議使用 VPC Service Controls 範圍，以免租用戶資料集意外洩漏到貴機構 Google Cloud 之外，並防止未經授權的資料在機構內進行彙整。
範圍
在這種設定中，建議您建立下列服務範圍：
- 資料管道：資料管道專案的範圍應強制執行所有不需要接收租用戶資料的服務。
- 租用戶資料：租用戶資料集專案和租用戶 BigQuery 運算專案的範圍。強制執行所有服務，防止機構外部人士存取。
- 內部應用程式：強制執行所有服務，並使用存取層級授予部門團隊資源存取權。
- 外部應用程式：圍繞軟體式服務 (SaaS) 應用程式的範圍。強制停用所有應用程式不必啟用的服務。
重疊範圍
在這種設定中，建議您建立下列外圍橋接：
- 資料管道和租用戶資料：允許管道將資料寫入租用戶資料集。
- 資料管道和內部應用程式：允許管道將資料寫入跨客戶資料集。
- 外部應用程式和租用戶資料：允許面向外部的應用程式查詢租用戶資料。
- 外部應用程式和內部應用程式：允許外部應用程式使用內部應用程式開發及部署的模型處理資料。
提供專屬租戶基礎架構的 SaaS 供應商
在更複雜的情況下，SaaS 供應商可能會為每個租用戶部署專屬的運算基礎架構。在這種情況下，專屬基礎架構會負責處理 BigQuery 內租戶資料的要求。
專屬租戶基礎架構設計可解決下列常見問題，這些問題會在為每個租戶部署基礎架構時一併使用 BigQuery：
- 帳單責任：追蹤與每位已加入的租用戶相關聯的基礎架構成本。
- 端對端延遲：資料儲存庫對於租用戶和跨客戶分析解決方案的最新程度。
- 效能預期值：確保租戶效能維持在可接受的範圍內。
將資料集與專用資源放置在同一位置
部署專屬租用戶基礎架構時，建議您為租用戶專屬專案建立父資料夾。接著，在專案中將租用戶的 BigQuery 資料集與代表租用戶存取該資料的專屬資源並排放置。為了將租用戶資料的端對端延遲時間降至最低，Dataflow 管道會直接將資料插入租用戶資料集。
這項設計會處理上游資料處理和發布作業，類似於前述的共用基礎架構設計。不過，租用戶資料和存取租用戶資料的應用程式會依租用戶專屬專案進行分類 (並可選擇以租用戶專屬資料夾分類)，以簡化帳單和資源管理作業。下圖為根據此建議設計的範例專案設定：
圖 2：資料管道專案會處理來自多個其他專案的單一租用戶資料。
圖 2 中的專案設定包含下列專案：
- 資料管道專案：接收、處理及發布租戶資料的核心基礎架構元件，都會封裝到單一專案中。
- 專屬租用戶專案：專案包含專屬於單一租用戶的所有雲端資源，包括 BigQuery 資料集。建議您使用身分與存取權管理 (IAM)，大幅限制哪些帳戶和服務帳戶可以存取客戶資料集。
- 內部數據分析專案：代表數據分析團隊用來評估租戶資料及建構新功能的自行管理資源。
- 外部網路專案：處理及將租用戶要求路由至專屬後端的專案。
分享預留項目
這種方法中的預留項目會依賴 BigQuery 預留項目內建的公平排程演算法。在這種設定中，系統會將運算層級保留作業指派給使用該層級的每個用戶群專案。如果租戶有特定的時間要求，您可以建立專屬的預留項目，為租戶專案提供確切的運算單元數量。
使用 IAM 控管機制並停用金鑰建立功能
在這種情況下，VPC Service Controls 範圍可能不適合使用。專案相關限制會防止機構在與租用戶專案互動的專案周圍使用安全範圍邊界。建議您改用嚴格的 IAM 控管機制，並停用金鑰建立功能，以防範不必要的外部存取。
有中央權限的資料市集
資料倉儲是常見的設計主題，核心分析資料會儲存在中央存放區，子集則會沿著業務部門共用。資料倉儲通常有數十或數百個租戶，代表要考慮的業務範圍。
BigQuery 中的資料倉儲設計可滿足下列需求：
- 安全的資料協作：透過技術控管機制共用資料，盡量減少團隊間的不適當存取行為。
- 集中式資料管理：確保用於重要業務報表的核心資料資產經過標準化和驗證。
- 業務單位成本歸因：追蹤及調整各業務單位的運算用量。
使用由中央管理的存放區
在這個設計中，核心資料會在集中管理的存放區中擷取。授權檢視畫面、授權使用者定義函式 (UDF) 和欄政策經常會一起使用，以便與業務單位分享資料，同時避免意外散發機密資料。
租用戶專案中的團隊可以根據帳戶權限存取集中管理的資料集。團隊會使用分配給專屬專案的空格，建立報表和衍生資料集。核心資料團隊會使用授權檢視表，維持資料超市資產存取權的完整擁有權。在這種情況下，我們建議您避免在核心資料專案呈現的物件上方建立多層檢視畫面。下圖為根據此建議設計的專案設定範例：
圖 3：核心資料專案會維護一個集中式資料市集，供整個機構存取。
圖 3 中的專案設定包含下列專案：
- 核心資料專案：管理核心資料和資料倉儲檢視畫面存取權的治理範圍。您可以維護這個專案內資料集中的已授權檢視畫面，並根據群組成員資格，將已授權的檢視畫面授予分析團隊。
- 擷取、轉換及載入 (ETL) 基礎架構：將上游資料來源轉換為核心資料的基礎架構。視管理區隔需求而定，您可以選擇將 ETL 基礎架構部署為專屬專案，或做為核心資料專案的一部分。
- Analytics 團隊專案：資料超市的使用者會使用這些專案，並透過自身的佈建基礎架構存取權，處理資料超市中的資料。數據分析團隊專案應可建立衍生資料集供本機使用。
使用兩層預留設計
使用資料倉儲時，建議您採用兩層設計。在雙層設計中，您可以為機構資源指派具有少量運算單元的預留項目，以涵蓋一般用途。如果團隊有更高的需求，請在專案或資料夾層級指派保留項目。
設定 VPC Service Controls 範圍
在這種設定中，建議您使用 VPC Service Controls 邊界，以免 BigQuery 資料集意外洩漏至Google Cloud 機構外。
範圍
在這種設定中，建議您建立下列服務範圍：
- 核心資料：用來保護資料倉儲和資料超市資料集的邊界。
- 資料管道：ETL 基礎架構專案的邊界。如果資料管道需要在貴 Google Cloud機構以外提出要求，建議您將此範圍與核心資料範圍分開。
- Analytics：用於建構及部署貴機構內部數據分析資產的邊界。這個邊界應具備比核心資料邊界更寬鬆的存取權政策。
重疊範圍
在這種設定中，建議您建立下列周界橋接：
- 資料管道和核心資料：允許資料管道寫入核心資料專案。
- 核心資料和分析：允許分析專案中的使用者查詢已授權的檢視畫面。
複製多地區設定的資料集
由於 BigQuery 不允許跨區查詢，因此如果資料倉儲必須跨多個區域存在，就無法使用透過已授權檢視區隔資料的策略。您可以改用 BigQuery 資料移轉服務，將相關資料集複製到其他區域。在這種情況下，您會在資料目錄中為資料所在的每個額外區域建立資料欄政策。下圖為多地區設定：
圖 4：多地區設定會使用 BigQuery 資料移轉服務，在各個地區複製資料集。
圖 4 中的專案設定包含下列專案。
- 核心資料專案：管理核心資料和資料倉儲檢視畫面存取權的治理範圍。資料會複製並保留至地區性資料集，以便為全球團隊提供服務。
- ETL 基礎架構：處理上游資料來源並轉換為核心資料的基礎架構。視管理區隔需求而定，您可以選擇將 ETL 基礎架構部署為專屬專案，或做為核心資料專案的一部分。
- 數據分析團隊專案：資料超市的使用者會使用這些專案，並使用自身的已佈建基礎架構，處理資料超市區域資料集內的資料。Analytics 團隊專案應可建立衍生資料集供本機使用。
BigQuery 資料移轉服務是額外的排程元件，但有部分限制。內建服務排程器的間隔時間最短為 15 分鐘，且必須從來源資料集複製所有資料表。您無法嵌入其他指令碼，在 BigQuery 資料移轉服務排程器中建立特定區域的資料子集。
如果貴機構需要更多彈性，可以使用下列選項：
- Cloud Composer 工作：您可以排定 Cloud Composer 工作，以便發出 ETL 工作，在透過 用戶端 API 觸發 BigQuery 資料移轉服務之前，先建立區域子集。如果貴機構可以接受較高的延遲時間，建議您使用這個選項。
- ETL 基礎架構：Dataflow 等 ETL 基礎架構可將區域子集以雙寫方式寫入目標區域。如果貴機構需要在各地區之間縮短資料延遲時間，建議您採用這個選項。
具有分散權限的資料市集
如需依系統擁有者、業務線或地理區域劃分管理權限，請使用分散式權限。
與標準資料倉儲相比，分散式資料倉儲有下列不同疑慮：
- 安全的資料協作：透過技術控管機制共用資料，盡量減少團隊間的不適當存取行為。
- 資料可探索性：團隊必須能夠探索資料集並要求存取權。
- 資料來源：如果沒有中央策展團隊，各團隊就必須信任 Analytics 產品中資料的來源。
委派核心資料管理
這種設計與傳統資料倉儲方法不同，因為分散式權限會將核心資料管理決策委派給機構的子元件子群組。使用分散式權限時，您可以使用 Cloud Key Management Service (Cloud KMS)、資料欄政策、VPC Service Controls 和保留項目，對安全性和 BigQuery 容量進行集中控管。因此，您可以避免自助倉儲常見的資料散布問題。下圖顯示採用去中心化權限的架構：
圖 5. 核心管理專案有助於確保一致的安全性，同時讓各個團隊維護各自的資料作業。
圖 5 中的專案設定包含下列專案：
- 核心治理專案：負責跨機構管理問題的專案。在這個專案中，您會建立 Cloud KMS 金鑰環和資料目錄資料欄政策等安全資源。這個專案會充當 BigQuery 預留項目管理專案，讓機構內的所有人都能共用運算單元。
- 機構單位資料專案：指的是整個機構內自管理資料超市擁有者。核心管理專案會管理機構單位資料專案的受限範圍。
- Analytics 團隊專案：資料超市使用者使用的專案。這些專案會使用自身的已佈建基礎架構和時段，存取及處理資料超市中的資料。
使用兩層預留設計
建議您讓分散式資料倉儲使用與標準資料倉儲相同的兩層設計。在這個設定中，您會為機構資源指派預留空間，其中包含少量時段，以涵蓋一般用途。如果團隊有更高的需求，請在專案或資料夾層級指派保留項目。
使用資料目錄
資料目錄可提供全機構探索、中繼資料標記和資料欄政策設定功能。Dataplex 的探索功能會自動為機構中的所有新 BigQuery 資料表建立中繼資料項目。Dataplex 的功能也能協助資料治理管理員快速找出新的資料資產，並套用適當的控管措施。
設定 VPC Service Controls 範圍
在這種設定中，建議您使用 VPC Service Controls 邊界，以免 BigQuery 資料集意外洩漏至Google Cloud 機構外。
範圍
在這種設定中，建議您建立下列服務範圍：
- 核心資料：用來保護資料倉儲和資料超市資料集的邊界。這個範圍應包含所有機構單位專案和資料管理專案。
- Analytics：用於建構及部署機構內部分析資產的範圍。這個邊界預期會比與其連結的核心資料邊界，擁有更寬鬆的存取權政策。
重疊範圍
在這種設定中，建議您建立下列周邊橋接：
- 核心資料和數據分析：允許數據分析專案中的使用者查詢已授權的檢視畫面。
多機構資料共用
資料集設計時，必須特別考量多機構共用問題。這項資料共用設計適用於希望與擁有自家 Google 機構的其他實體安全共用資料集的機構。
多機構資料共用功能可解決資料提供者面臨的下列疑慮：
- 共用機密資訊：只有指定的對象才能存取共用資料。
- 防範不當存取：只有您想讓他人存取的資源才能供外部存取。
- 運算分離：外部使用者會因他們發起的查詢而產生費用。
保護內部專案不受共用資料專案影響
多機構資料共用設計著重於保護機構內部專案，避免受到共用資料專案中的活動影響。共用資料集專案可做為緩衝區，禁止存取機密的內部資料處理作業，同時提供外部資料共用功能。
從外部專案啟動的查詢會使用叫用專案的運算資源。如果所有查詢的資料集都位於同一個 Google Cloud區域，這些查詢就能彙整不同機構的資料。下圖說明在多機構專案設定中，資料集的共用方式：
圖 6：外部機構在共用專案中查詢多個資料集的資料。
圖 6 中的專案設定包含下列專案：
- 機構內部專案：含有機密內部資料的專案。內部專案可以將經過清理的資料複製到共用資料專案的資料集中，藉此對外共用資料。內部專案應擁有負責更新共用資料的服務帳戶。
- 共用資料專案：包含從內部專案複製的經過淨化的資訊的專案。使用外部使用者群組管理外部使用者的存取權。在這種情況下，您可以透過管理功能管理群組會員資格，並將檢視者權限授予外部帳戶，讓他們能夠透過這些群組存取資料集。
設定 VPC Service Controls 範圍
在這種設定中，我們建議使用 VPC Service Controls 範圍來分享資料，並防止 BigQuery 資料集意外曝露在內部專案之外。
範圍
在這種設定中，建議您建立下列服務範圍：
- 內部資料：用於保護核心資料資產的範圍。VPC Service Controls 會強制執行 BigQuery 的存取權。
- 外部共用資料：可代管可與外部機構共用的資料集。這個範圍會停用 BigQuery 存取權的強制執行機制。
重疊範圍
在這種設定中，建議您建立下列周界橋接：
- 內部至外部資料：範圍橋接可讓受到更嚴密保護的內部資料專案將資料傳送至外部資料共用專案。
多租戶系統的其他注意事項
本節將深入探討特殊情況，您可以將這些情況與前述最佳做法一併考量。
Google Cloud 資源限制和配額
- 服務帳戶的軟性配額上限為每個專案 100 個服務帳戶。您可以透過控制台，為維護租戶服務帳戶的專案申請配額。 Google Cloud
- BigQuery 並行作業的預設並行作業數為每個發出查詢的專案 100 個查詢 (儲存資料集的專案沒有此限制)。如要提高這個軟性配額，請與業務代表聯絡。
- 機構內的服務範圍內，VPC Service Controls 的專案數量上限為 10,000 個。如果每個租戶的專案設計規模較大，建議改用每個租戶的資料集設計。
- 每個機構的 VPC Service Controls 範圍 (包括重疊範圍) 上限為 100 個。
使用授權檢視表或具體化子集資料表
如要管理資料夾存取大型事實表的子集，您可以使用資料夾專屬的授權檢視表，或建立資料夾專屬的子集表格。下表比較了這些方法：
| 功能 | 授權檢視表 | 子集資料表 |
|---|---|---|
| 支援的租戶數量 | 每個資料集的授權資源上限為 2500 個。 | 已授權的資源包括已授權的檢視表、已授權的資料集和已授權的函式。專案中資料集的數量或資料集中的資料表沒有限制。 |
| 分區和分群 |
已授權的檢視表必須共用基礎資料表的通用分區和叢集配置。 為提升租戶區隔的成效，建議您根據租戶 ID 將父表彙整為叢集。 |
您可以根據租用戶的需求，將子集資料表分區並建立叢集。 |
| 區域規劃 | 已授權的檢視畫面不得跨區域，且必須位於基礎資料表的 Google Cloud 區域。區域化會影響地理位置偏遠的租戶。 | 子集資料表可位於最適合租用者的區域。可能需要支付額外費用。 |
| 資料欄政策強制執行 | 套用至基礎資料表的資料欄政策會套用至所有已授權的檢視畫面，不論這些檢視畫面的權限為何。 | 每個子集資料表都必須套用資料欄政策，政策才會生效。 |
| 資料存取記錄 | 資料存取記錄會反映在基本資料表的記錄中。 | 系統會分別記錄對每個子集資料表的存取情況。 |
| 轉換彈性 | 授權檢視畫面可讓您立即重新設計租用戶存取的物件。 | 如要變更子集資料表，就必須進行複雜的結構定義變更。 |
控管機密資料
為防止未經授權存取資料，BigQuery 除了標準 IAM 權限外，還提供其他幾項額外功能。
用戶端提供的加密金鑰
用戶端資料加密功能適用於以下情況：代管機構代表租用戶儲存及處理資料，但無法存取部分資料內容。舉例來說，主辦機構可能無法存取個人或裝置資料，因為這些資料屬於機密資料。
我們建議資料傳送者使用開放原始碼 Tink 程式庫中的 AEAD 加密金鑰，加密機密資料。Tink 程式庫 AEAD 加密金鑰與 BigQuery AEAD 函式相容。接著，承租人可以透過以下方式解密資料：在已授權的 UDF 中存取金鑰素材，或是將金鑰素材做為查詢參數傳遞至 BigQuery，因為在後者中，主機組織無法記錄金鑰。
資料欄存取權政策
在多租戶資料倉儲中，經常會使用資料欄政策，防止敏感內容在合作團隊之間意外外洩。在資料倉儲情境中，授權檢視表是團隊間共用資料的首選機制。授權檢視畫面無法授予受保護欄的存取權。
如果您將政策設為強制執行存取控管機制，則可防止未獲授予精細讀取者角色的使用者存取政策。即使未強制執行政策，這項政策也會記錄所有使用者存取分類資料欄的情況。
Sensitive Data Protection
Sensitive Data Protection 提供 API 和掃描公用程式，協助您找出並減輕 BigQuery 或 Cloud Storage 資料集中儲存的機密內容。在多租戶情境中，組織經常使用 DLP API (屬於機密資料保護服務) 來識別機密資料，並視需要在儲存前將其轉為符記。
運算單元預留項目管理
在多租戶系統中，預留管理功能可協助控管成本，並確保每個租戶都能享有保證的效能。
如要管理預留項目，建議您建立單一預留項目管理專案。在同一個管理專案中購買的運算單元承諾，可供來自該管理專案的所有預留項目共用。使用時段承諾的專案一次只能指派給一個保留項目。所有來自專案的查詢都會根據可用資源共用運算單元。
為確保符合租用戶服務等級目標 (SLO)，您可以透過 Cloud Logging 和 BigQuery 資訊結構定義監控預留。如果機構因分析師活動或優先工作而出現繁忙期，可以使用彈性時段分配額外容量。
以租用戶運算層級做為預留項目
擁有數十到數千個租戶的 SaaS 供應商，通常會將有限數量的 BigQuery 保留項目設定為共用資源。
如果您是擁有共用租戶基礎架構的 SaaS 供應商，建議您將每個保留項目專用於單一專案，並將租戶分組，以便共用該專案的 BigQuery 運算資源。這項設計可減少管理成千上萬個額外專案和預留項目的行政負擔，同時讓貴機構分配足以滿足預留項目預期效能需求的最低時段容量。
如果ELT 資料處理作業的及時性是首要考量，建議您分配預留容量來處理這項作業。如要避免使用可用於臨時工作負載的額外運算單元，請將預留項目設為忽略閒置運算單元。
以下範例說明如何將預留容量設為租用戶運算層級：
- 資料處理：2000 個時段，忽略閒置狀態。這項預留空間已設定為符合資料處理 SLO。
- 內部專案：1000 個時段，允許閒置。這項預留作業會套用至用於內部分析的專案。如果有空缺的資料處理或運算層級，系統會重複使用這些空缺。
- 低運算等級：2000 個時段，忽略閒置時段。這項保留作業會套用至資源不足的租戶。與高層級不同，這個預留項目會忽略閒置的運算單元。
- 高運算等級：3000 個空閒時可用的投放位置。這項預留作業會套用至資源較多的租用戶。為了加快查詢速度，系統會自動套用其他預留項目的閒置運算單元。
如果租用戶使用的是專屬基礎架構，建議您將指定的資料夾或專案指派給適當的共用預訂。
每個團隊的預訂數量
在資料倉儲環境中與團隊合作時，建議您為需要額外運算能力的每個團隊建立預訂。然後將該保留項目指派給包含團隊專案的父項資料夾。該團隊的所有新專案都會使用公平排程時段，並從相同的資源分配中取得資源。
以下範例說明如何為每個團隊設定預訂：
- 機構層級保留空間：500 個時段，允許閒置。這項預留項目會指派給頂層機構，並為所有未使用設有專屬預留項目的 BigQuery 使用者提供運算單元
- 資料處理：1000 個時段，忽略閒置狀態。這項預留作業已設定為符合最低資料處理 SLO。
- 核心資料管理：500 個時段，允許閒置。這項預留項目會套用至用於內部管理的專案。如果這些空格是從資料處理或運算層中剩餘，就會重複使用。
- Analytics 處理保留項目：500 個運算單元，允許閒置。這是專門提供給資料分析團隊的預留項目。
多地區代管服務規定
多區域代管服務通常是為了減少消費者的資料延遲，或是為了符合法規要求。
Google Cloud 中的專案視為全球專案，可在任何區域中配置資源。BigQuery 會將資料集、資料欄政策和運算單元承諾視為區域性資源。時段只能存取本機區域的資料集，而資料欄政策只能套用至本機資料集內的資料表。如要使用容量定價，您必須在每個含有資料集的區域中購買運算單元。
如需遵循法規規定的相關指南，請洽詢業務代表。
後續步驟
- 瞭解 IAM 最佳做法。