BigLake 外部資料表簡介

本文件將概略說明 BigLake，並假設您熟悉資料庫資料表和 Identity and Access Management (IAM)。如要查詢儲存在支援的資料儲存庫中的資料，您必須先建立 BigLake 資料表，然後使用 GoogleSQL 語法查詢資料表：

• 建立 Cloud Storage BigLake 資料表，然後查詢。
• 建立 Amazon S3 BigLake 資料表，然後查詢。
• 建立 Azure Blob 儲存體 BigLake 資料表，然後查詢。

您也可以將外部資料表升級為 BigLake。詳情請參閱「將外部資料表升級為 BigLake」。

BigLake 資料表可讓您透過存取權委派，查詢外部資料儲存庫中的結構化資料。存取權委派功能可將 BigLake 資料表的存取權，與基礎資料儲存空間的存取權分離開來。系統會使用與服務帳戶相關聯的外部連線連線至資料儲存庫。由於服務帳戶會處理從資料儲存庫擷取資料的作業，因此您只需授予使用者 BigLake 資料表的存取權。這可讓您在資料表層級強制執行精細的安全防護機制，包括資料列層級和資料欄層級的安全防護機制。如果是基於 Cloud Storage 的 BigLake 資料表，您也可以使用動態資料遮罩。如要進一步瞭解如何使用 BigLake 資料表搭配 Amazon S3 或 Blob 儲存體資料，請參閱 BigQuery Omni。

支援的資料儲存庫

您可以將 BigLake 資料表與下列資料儲存庫搭配使用：

• Amazon S3 (使用 BigQuery Omni)
• 使用 BigQuery Omni 的 Blob 儲存體
• Cloud Storage

支援臨時資料表

以 Cloud Storage 為基礎的 BigLake 資料表可以是臨時或永久資料表。以 Amazon S3 或 Blob 儲存空間為基礎的 BigLake 資料表必須是永久性資料表。

多個來源檔案

您可以根據多個外部資料來源建立 BigLake 資料表，前提是這些資料來源必須具有相同的結構定義。

跨雲端聯結

跨雲端彙整功能可讓您執行跨越 Google Cloud 和 BigQuery Omni 地區的查詢。您可以使用 GoogleSQL JOIN 作業分析 AWS、Azure、公開資料集和其他 Google Cloud 服務等多種儲存空間解決方案中的資料。跨雲端彙整功能可讓您在執行查詢前，不必先複製不同來源的資料。

您可以在 SELECT 陳述式的任何位置參照 BigLake 資料表，就像是標準 BigQuery 資料表一樣，包括使用子查詢擷取資料的資料操縱語言 (DML) 和資料定義語言 (DDL) 陳述式。您可以在同一個查詢中使用來自不同雲端的多個 BigLake 資料表和 BigQuery 資料表。所有 BigQuery 資料表都必須位於同一個地區。

跨雲端彙整所需權限

如要取得執行跨雲彙整所需的權限，請要求管理員為您授予執行彙整的專案的 BigQuery 資料編輯者 (roles/bigquery.dataEditor) IAM 角色。如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。

這個預先定義的角色包含執行跨雲端彙整所需的權限。如要查看確切的必要權限，請展開「必要權限」部分：

您或許還可透過自訂角色或其他預先定義的角色取得這些權限。

跨雲彙整會建立含有 __bigquery_xregion_sink_ 前置字首的資料集，並在這些資料集中建立暫時性資料表。因此，如要只授予由跨雲彙整建立的資源存取權，請針對 Table 和 Dataset 資源類型使用 resource.name.startsWith 條件。

如要進一步瞭解 BigQuery 中的 IAM 角色和權限，請參閱「IAM 簡介」。

跨雲端彙整費用

執行跨雲彙整作業時，BigQuery 會將查詢剖析為本機和遠端部分。本機部分會視為 BigQuery 區域中的標準查詢。遠端部分會轉換為 BigQuery Omni 區域中參照 BigLake 資料表的 CREATE TABLE AS SELECT (CTAS) 作業，並在 BigQuery 區域中建立臨時資料表。接著，BigQuery 會使用這個暫時表格執行跨雲彙整，並在八小時後自動刪除表格。

您必須為參照的 BigLake 資料表中的資料支付資料移轉費用。不過，BigQuery 只會轉移查詢中參照的 BigLake 資料表中的資料欄和資料列，而非整個資料表，因此有助於降低這些成本。建議您指定盡可能狹窄的資料欄篩選器，以進一步降低轉移成本。CTAS 工作會顯示在工作記錄中，並顯示轉移位元組數量等資訊。即使主要查詢工作失敗，成功的轉移作業仍會產生費用。詳情請參閱 BigQuery Omni 定價。

請參考以下查詢：

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

這個範例有兩個轉移作業：一個是從員工資料表 (含等級篩選器) 轉移，另一個是從有效員工資料表轉移。在移轉完成後，系統會在 BigQuery 區域中執行彙整作業。如果其中一個轉移作業失敗，另一個成功的轉移作業仍會產生資料移轉費用。

跨雲端彙整限制

• BigQuery 免費方案和 BigQuery 沙箱不支援跨雲聯結。
• 如果查詢包含 JOIN 陳述式，匯總資料可能不會推送至 BigQuery Omni 區域。
• 每個暫時性資料表只會用於單一跨雲查詢，即使重複執行相同查詢，也不會重複使用。
• 每筆轉移作業的轉移大小上限為 60 GB。具體來說，如果您對 BigLake 資料表套用篩選器並載入結果，則結果必須小於 60 GB。如有需要，您可以申請調整配額。掃描的位元組數量沒有限制。
• 跨雲彙整查詢會針對查詢頻率採用內部配額。如果查詢率超過配額，您可能會收到 All our servers are busy processing data transferred between regions 錯誤。在大多數情況下，重新嘗試查詢應可解決問題。請與支援團隊聯絡，提高內部配額，以便支援更高的查詢率。
• 跨雲端聯結功能僅支援同址 BigQuery 區域與相應的 BigQuery Omni 區域，以及 US 和 EU 多地區。在 US 或 EU 多區域中執行的跨雲彙整作業只能分別存取美國或歐盟 BigQuery Omni 區域中的資料。
• 如果跨雲端彙整查詢參照 BigQuery Omni 區域中的資料集，且資料集超過 10 個，可能會發生錯誤 Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>。為避免這個問題，建議您在執行參照超過 10 個資料集的跨雲彙整作業時，明確指定位置。請注意，如果您明確指定 BigQuery 區域，且查詢只包含 BigLake 資料表，則查詢會以跨雲查詢執行，並產生資料移轉費用。
• 您無法使用跨雲端彙整查詢 _FILE_NAME 擬造欄。
• 在 WHERE 子句中參照 BigLake 資料表的資料欄時，您無法使用 INTERVAL 或 RANGE 文字。
• 跨雲彙整工作不會回報從其他雲端處理及轉移的位元組數。這項資訊會顯示在子 CTAS 工作中，這些工作是在跨雲端查詢執行作業的一部分中建立。
• 只有 BigQuery Omni 區域支援參照 BigQuery Omni 資料表或檢視表的已授權檢視表和已授權例行程序。
• 如果跨雲查詢參照 STRUCT 或 JSON 欄，則不會將推送操作套用至任何遠端子查詢。為提升效能，建議您在 BigQuery Omni 區域中建立檢視畫面，篩選 STRUCT 和 JSON 欄，並只將必要欄位做為個別欄傳回。
• 跨雲端彙整不支援彙整。

跨雲端彙整範例

以下查詢會將 BigQuery 區域中的 orders 資料表與 BigQuery Omni 區域中的 lineitem 資料表彙整：

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

這項查詢分為本機和遠端部分。系統會將下列查詢傳送至 BigQuery Omni 區域，以便優先執行。結果是 BigQuery 區域中的臨時表格。您可以在工作記錄中查看這個子項 CTAS 工作及其中繼資料。

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

建立暫存資料表後，JOIN 作業就會完成，並執行下列查詢：

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

以下是另一個跨雲彙整的範例：

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
SELECT c_mktsegment, c_name
FROM aws_dataset.customer
WHERE c_mktsegment = 'FURNITURE'
LIMIT 10;

在這個查詢中，LIMIT 子句並未推送至 BigQuery Omni 區域。FURNITURE 市場區隔中的所有客戶會先轉移至 BigQuery 區域，然後套用 10 個的限制。

連接器

您可以使用 BigQuery 連接器，從其他資料處理工具存取 Cloud Storage 中 BigLake 資料表的資料。舉例來說，您可以透過 Apache Spark、Apache Hive、TensorFlow、Trino 或 Presto 存取 BigLake 資料表中的資料。BigQuery Storage API 會針對所有 BigLake 資料表的資料存取權 (包括透過連接器存取的資料)，強制執行資料列和資料欄層級的管理政策。

舉例來說，下圖說明 BigQuery Storage API 如何讓使用者透過 Apache Spark 等開放原始碼查詢引擎，存取自己有權限存取的資料：

如要進一步瞭解 BigQuery 支援的連接器，請參閱 BigQuery 連接器。

物件儲存空間中的 BigLake 資料表

資料湖泊管理員可透過 BigLake 設定資料表 (而非檔案) 的存取權控管機制，這樣一來，您就能在設定資料湖泊中資料的使用者存取權時，提供更精細的選項。

由於 BigLake 資料表會以這種方式簡化存取控管機制，因此建議您使用 BigLake 資料表建立及維護外部物件儲存空間的連線。

如果不需治理，或需要臨時探索及操作資料，您可以使用外部資料表。

限制

• 所有外部資料表限制都適用於 BigLake 資料表。
• 物件儲存空間中的 BigLake 資料表，適用於 BigQuery 資料表的限制。詳情請參閱「配額」。

• BigLake 不支援 Dataproc 個人叢集驗證的下層憑證。如要使用啟用個人叢集驗證功能的叢集，您必須使用含有 --access-boundary=<(echo -n "{}") 標記的空白憑證存取邊界，插入憑證。舉例來說，下列指令會為名為 mycluster 的叢集，在名為 myproject 的專案中啟用憑證傳播工作階段：

  gcloud dataproc clusters enable-personal-auth-session \
      --region=us \
      --project=myproject \
      --access-boundary=<(echo -n "{}") \
      mycluster
  

• BigLake 資料表為唯讀。您無法使用 DML 陳述式或其他方法修改 BigLake 資料表。

• BigLake 資料表支援下列格式：

  • Avro
  • CSV
  • Delta Lake
  • Iceberg
  • JSON
  • ORC
  • Parquet

• 您無法搭配 Apache Iceberg 唯讀外部資料表使用快取的結構描述資料；BigQuery 已使用 Iceberg 在資訊清單檔案中擷取的結構描述資料。

• BigQuery Storage API 不適用於 AWS 和 Azure 等其他雲端環境。

• 如果您使用快取中繼資料，則適用下列限制：

  • 您只能在使用 Avro、ORC、Parquet、JSON 和 CSV 格式的 BigLake 資料表中使用快取的結構描述資料。
  • 如果您在 Amazon S3 中建立、更新或刪除檔案，則在下次重新整理中繼資料快取之前，查詢檔案不會傳回更新後的資料。這可能會導致非預期的結果。舉例來說，如果您刪除檔案並寫入新檔案，查詢結果可能會排除舊檔案和新檔案，具體取決於快取中繼資料的最後更新時間。
  • 對於參照 Amazon S3 或 Blob Storage 資料的 BigLake 資料表，不支援使用客戶管理的加密金鑰 (CMEK) 搭配快取中繼資料。

安全性模型

管理和使用 BigLake 資料表時，通常會涉及下列組織角色：

• 資料湖泊管理員：這些管理員通常會管理 Cloud Storage 值區和物件的身分與存取權管理 (IAM) 政策。
• 資料倉儲管理員。這些管理員通常會建立、刪除及更新資料表。
• 資料分析師。分析人員通常會讀取資料和執行查詢。

資料湖泊管理員負責建立連結，並與資料倉儲管理員分享連結。資料倉儲管理員則會建立資料表、設定適當的存取權控管機制，並與資料分析師分享資料表。

為提升效能而快取中繼資料

您可以使用快取的中繼資料，改善某些類型的 BigLake 資料表的查詢效能。如果您要處理大量檔案，或是資料已劃分為巢狀區塊，中繼資料快取功能就特別實用。下列 BigLake 資料表類型支援中繼資料快取：

• Amazon S3 BigLake 資料表
• Cloud Storage BigLake 資料表

中繼資料包括檔案名稱、區隔資訊，以及檔案的實體中繼資料，例如資料列計數。您可以選擇是否在資料表上啟用中繼資料快取功能。含有大量檔案和 Apache Hive 分區篩選器的查詢，最能從中繼資料快取作業中受益。

如果您未啟用中繼資料快取功能，資料表上的查詢必須讀取外部資料來源，才能取得物件中繼資料。讀取這類資料會增加查詢延遲時間，從外部資料來源列出數百萬個檔案可能需要幾分鐘的時間。啟用中繼資料快取功能後，查詢作業就能避免列出外部資料來源中的檔案，並且能更快速地分割及刪除檔案。

有兩個屬性可控制這項功能：

• 最大過時時間：指定查詢使用快取中繼資料的時間。
• 「中繼資料快取模式」會指定中繼資料的收集方式。

啟用中繼資料快取功能後，您可以指定中繼資料過時的最大間隔，以便針對資料表執行作業。舉例來說，如果您指定 1 小時的間隔，則如果表格在過去 1 小時內已重新整理，針對該表格的作業會使用快取中繼資料。如果快取的結構描述資料比這還舊，作業會改為從資料儲存庫 (Amazon S3 或 Cloud Storage) 擷取結構描述資料。您可以指定 30 分鐘至 7 天的過時間隔。

為 BigLake 或物件資料表啟用中繼資料快取功能時，BigQuery 會觸發中繼資料產生重建工作。您可以選擇自動或手動重新整理快取：

• 自動重新整理功能會按照系統定義的間隔時間 (通常為 30 到 60 分鐘) 重新整理快取。如果資料儲存庫中的檔案會在隨機間隔下新增、刪除或修改，自動重新整理快取是一個不錯的做法。如果您需要控制重新整理的時間點 (例如在擷取-轉換-載入工作結束時觸發重新整理)，請使用手動重新整理。

• 如要手動重新整理，您可以執行 BQ.REFRESH_EXTERNAL_METADATA_CACHE 系統程序，按照符合需求的排程重新整理中繼資料快取。針對 BigLake 資料表，您可以提供資料表資料目錄的子目錄，選擇性地重新整理中繼資料。這樣一來，您就能避免不必要的中繼資料處理作業。如果資料儲存庫中的檔案會在已知的間隔時間內新增、刪除或修改 (例如管線的輸出內容)，手動重新整理快取是個不錯的做法。

  如果您同時發出多個手動重新整理要求，只有其中一個會成功。

如果未重新整理，中繼資料快取會在 7 天後過期。

手動和自動快取重新整理作業都會以 INTERACTIVE 查詢優先順序執行。

使用 BACKGROUND 保留項目

如果您選擇使用自動重新整理功能，建議您建立預留，然後為執行中繼資料快取重新整理工作的專案，建立使用 BACKGROUND 工作類型的指派。使用 BACKGROUND 保留功能時，重新整理工作會使用專用資源集區，避免重新整理工作與使用者查詢競爭，並避免在沒有足夠資源可供使用時，工作可能會失敗。

雖然使用共用運算單元集區不會產生額外費用，但使用 BACKGROUND 預留功能可分配專用資源集區，提供更穩定的效能，並提高 BigQuery 中重新整理作業的可靠性和整體查詢效率。

設定過時間隔和中繼資料快取模式值前，請先考量兩者之間的互動方式。請見以下範例：

• 如果您手動重新整理資料表的中繼資料快取，並將失效間隔設為 2 天，則必須每 2 天或更短時間執行 BQ.REFRESH_EXTERNAL_METADATA_CACHE 系統程序，才能讓針對資料表的作業使用快取的中繼資料。
• 如果您自動重新整理資料表的中繼資料快取，並將失效間隔設為 30 分鐘，如果中繼資料快取重新整理作業需要的時間超過一般 30 到 60 分鐘的時間範圍，則針對資料表執行的部分作業可能會從資料儲存庫讀取資料。

如要查看中繼資料重新整理工作相關資訊，請查詢 INFORMATION_SCHEMA.JOBS 檢視區塊，如以下範例所示：

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

對於以 Parquet 檔案為基礎的 Cloud Storage BigLake 資料表，系統會在重新整理中繼資料快取時收集資料表統計資料，並用於改善查詢計畫。

詳情請參閱「中繼資料快取」。

如要進一步瞭解如何設定中繼資料快取選項，請參閱「建立 Amazon S3 BigLake 資料表」或「建立 Cloud Storage BigLake 資料表」。

啟用快取功能的資料表，以及具體化檢視畫面

您可以使用 BigLake 元資料快取啟用資料表的具體化檢視表，在查詢儲存在 Cloud Storage 或 Amazon Simple Storage Service (Amazon S3) 中的結構化資料時，提升效能和效率。這些已具體化的檢視畫面會像 BigQuery 管理的儲存空間資料表中的已具體化的檢視畫面一樣運作，包括自動重新整理和智慧調整的優點。

整合

您可以透過多項其他 BigQuery 功能和 gcloud CLI 服務存取 BigLake 資料表，包括下列醒目顯示的服務。

BigQuery sharing (舊稱 Analytics Hub)

BigLake 資料表與共用功能相容。包含 BigLake 資料表的資料集可發布為共用資訊清單。共用訂閱者可以訂閱這些項目，這些項目會在專案中佈建唯讀資料集，稱為連結資料集。訂閱者可以查詢已連結資料集中的所有資料表，包括所有 BigLake 資料表。詳情請參閱「查看及訂閱商家資訊」。

BigQuery ML

您可以使用 BigQuery ML 在 Cloud Storage 中的 BigLake 上訓練及執行模型。

Sensitive Data Protection

機密資料保護會掃描 BigLake 資料表，識別及分類機密資料。如果偵測到機密資料，Sensitive Data Protection 去識別化轉換可遮蔽、刪除或以其他方式隱藏該資料。

費用

費用與 BigLake 資料表的下列層面相關：

• 查詢資料表。
• 重新整理中繼資料快取。

如果您有運算單元預留，查詢外部資料表不會產生費用。而是會為這些查詢使用空格。

下表說明您的定價模式如何影響這些費用的計費方式：

您也必須依據各產品的價格指南，針對 Cloud Storage、Amazon S3 和 Azure Blob 儲存體的儲存空間和資料存取權付費。

後續步驟

• 瞭解如何將外部資料表升級為 BigLake 資料表。
• 瞭解如何建立 Cloud Storage BigLake 資料表。
• 瞭解如何建立 Amazon S3 BigLake 資料表。
• 瞭解如何建立 Blob 儲存體 BigLake 資料表。
• 瞭解如何使用 Dataplex 通用目錄建立資料品質檢查作業。