整理 BigQuery 資源

與其他 Google Cloud 服務一樣,BigQuery 資源會依階層架構整理。您可以使用這個階層管理 BigQuery 工作負載的各個層面,例如權限、配額、運算單元保留項目和帳單。

資源階層

BigQuery 會沿用Google Cloud 資源階層,並新增稱為「資料集」的額外分組機制,這些機制專屬於 BigQuery。本節將說明這個階層的元素。

資料集

資料集是邏輯容器,可用來整理及控管 BigQuery 資源的存取權。資料集類似於其他資料庫系統中的結構定義。

您建立的大部分 BigQuery 資源 (包括資料表、檢視區塊、函式和程序) 都會建立在資料集中。連線和工作是例外狀況,因為這些項目與專案相關聯,而非資料集。

資料集有位置。建立資料表時,資料表資料會儲存在資料集的位置。建立生產資料表之前,請先考量位置規定。資料集建立之後,就無法更改位置。

專案

每個資料集都與專案相關聯。如要使用 Google Cloud,您必須建立至少一個專案。專案是建立、啟用及使用所有 Google Cloud 服務的基礎。詳情請參閱「資源階層」。專案可以包含多個資料集,且同一專案中可存在不同位置的資料集。

對 BigQuery 資料執行作業 (例如執行查詢或將資料擷取至資料表) 時,系統會建立工作。作業一律會與專案建立關聯,但不一定要在包含資料的專案中執行。事實上,工作可能會參照多個專案中資料集的資料表。查詢、載入或擷取工作一律會在參照資料表的位置執行。

每項專案都會連結至Cloud 帳單帳戶。系統會向該帳戶收取專案產生的費用。如果您使用以量計價,系統會將查詢費用計入執行查詢的專案。如果您採用以容量為準的計費方式,系統會將運算單元預留項目的費用,計入用於購買運算單元的管理專案。系統會向資料集所屬專案收取儲存空間費用。

資料夾

資料夾是在專案之上更進一步的分組機制。資料夾中的專案和資料夾會自動沿用父項資料夾的存取權政策。資料夾可用來為公司內的不同法人、部門和團隊建立模型。

組織

機構資源代表機構 (例如公司),也是Google Cloud 資源階層的根節點。

您不必擁有機構資源,就能開始使用 BigQuery,但我們建議您建立機構資源。使用機構資源可讓管理員集中控管 BigQuery 資源,而不是由個別使用者控管自己建立的資源。

下圖為資源階層的範例。在這個範例中,機構在資料夾內有一個專案。專案已與帳單帳戶建立關聯,且內含三個資料集。

資源階層

注意事項

選擇如何整理 BigQuery 資源時,請考量下列幾點:

  • 配額。許多 BigQuery 配額都是在專案層級套用。其中有幾個適用於資料集層級。涉及運算資源的專案層級配額 (例如查詢和載入工作),會計入建立工作的專案,而非儲存專案。
  • 帳單。如果貴機構的不同部門要使用不同的 Cloud Billing 帳戶,請為每個團隊建立不同的專案。在機構層級建立 Cloud Billing 帳戶,並將專案與這些帳戶建立關聯。
  • 運算單元預留項目。預留運算單元的範圍為機構資源。購買預留配額容量後,您可以將配額集區指派給機構內的任何專案或資料夾,也可以將配額指派給整個機構資源。專案會繼承上層資料夾或機構的時段預訂。預留運算單元會與管理專案建立關聯,用於管理運算單元。詳情請參閱使用預留項目進行工作負載管理
  • 權限。請考量權限階層對貴機構中需要存取資料的使用者有何影響。舉例來說,如要讓整個團隊存取特定資料,您可以將該資料儲存在單一專案中,簡化存取權管理作業。

    資料表和其他實體會繼承父項資料集的權限。資料集會繼承資源階層 (專案、資料夾、機構) 中父項實體的權限。如要對資源執行作業,使用者必須同時具備資源的相關權限,以及建立 BigQuery 工作的權限。建立工作的權限與該工作使用的專案相關聯。

模式

本節介紹兩種常見的 BigQuery 資源整理模式。

  • 中央資料湖泊、部門資料市集。機構會建立統一儲存空間專案,用來存放原始資料。機構內的各部門會建立自己的資料市集專案,以進行分析。

  • 部門資料湖泊、中央資料倉儲。各部門會建立及管理自己的儲存空間專案,用來存放該部門的原始資料。接著,該機構會建立中央資料倉儲專案,以進行分析。

每種做法各有優缺點。許多機構會結合這兩種模式的元素。

中央資料湖泊、部門資料市集

在這個模式中,您會建立統一的儲存空間專案,用來存放機構的原始資料。資料擷取管道也可以在這個專案中執行。這個統一儲存空間專案會做為貴機構的資料湖泊。

每個部門都有專屬專案,可用於查詢資料、儲存查詢結果及建立檢視區塊。這些部門層級的專案會做為資料市集。這些費用會與部門的帳單帳戶相關聯。

中央資料湖泊模式

這種結構的優點包括:

  • 集中式資料工程團隊可以在單一位置管理擷取管道。
  • 原始資料與部門層級專案隔離。
  • 若是以量計價,執行查詢的部門會支付查詢費用。
  • 採用容量計費時,您可以根據各部門的預估運算需求,為每個部門指派運算單元。
  • 就專案層級配額而言,每個部門都是獨立的。

使用這種結構時,通常會授予下列權限:

  • 中央資料工程團隊獲授儲存專案的 BigQuery 資料編輯者和 BigQuery 工作使用者角色。這些權限可讓他們在儲存專案中擷取及編輯資料。
  • 部門分析師在中央資料湖專案中,獲得特定資料集的 BigQuery 資料檢視者角色。這樣一來,他們就能查詢資料,但無法更新或刪除原始資料。
  • 此外,部門分析師也會獲得部門資料集市專案的 BigQuery 資料編輯者角色和工作使用者角色。因此他們可以在專案中建立及更新資料表,並執行查詢工作,以便轉換及匯總資料,供部門專用。

詳情請參閱「基本角色和權限」。

部門資料湖泊,中央資料倉儲

在這個模式中,每個部門都會建立及管理自己的儲存空間專案,中央資料倉儲專案會儲存原始資料的匯總或轉換結果。

分析師可以查詢及讀取資料倉儲專案中的匯總資料。 資料倉儲專案也會為商業智慧 (BI) 工具提供存取層。

部門資料湖泊模式

這種結構的優點包括:

  • 為每個部門使用不同的專案,可簡化部門層級的資料存取權管理作業。
  • 中央分析團隊有一個專案,可執行分析工作,方便監控查詢。
  • 使用者可透過集中式商業智慧工具存取資料,這些資料與原始資料保持隔離。
  • 您可以將時段指派給資料倉儲專案,處理分析師和外部工具的所有查詢。

使用這種結構時,通常會授予下列權限:

  • 資料工程師在部門的資料市集獲得 BigQuery 資料編輯者和 BigQuery 工作使用者角色。這些角色可讓使用者將資料擷取並轉換至資料市集。
  • 分析師在資料倉儲專案中獲派 BigQuery 資料編輯者和 BigQuery 工作使用者角色。這些角色可讓他們在資料倉儲中建立匯總檢視畫面,並執行查詢工作。
  • 將 BigQuery 連結至 BI 工具的服務帳戶,會獲得特定資料集的 BigQuery 資料檢視者角色,這些資料集可保留資料湖的原始資料,或資料倉儲專案中的轉換資料。

詳情請參閱「基本角色和權限」。

您也可以使用授權檢視畫面授權使用者定義函式 (UDF) 等安全性功能,向特定使用者提供匯總資料,而不授予他們查看資料市集專案中原始資料的權限。

這種專案結構可能會導致資料倉儲專案中出現許多並行查詢。因此,您可能會達到並行查詢限制。如果採用這種結構,建議提高專案的配額上限。此外,也建議您採用以運算資源為基礎的計費方式,購買運算單元集區來執行查詢。