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 資料表：

• 使用 BigQuery Omni 存取 Amazon S3
• 使用 BigQuery Omni 存取 Blob 儲存體
• Cloud Storage

支援臨時資料表

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

多個來源檔案

只要多個外部資料來源具有相同結構定義，您就能根據這些來源建立 BigLake 資料表。

跨雲端聯結

您可以透過跨雲端聯結，執行涵蓋 BigQuery Omni 地區和 Google Cloud 的查詢。您可以使用 GoogleSQL JOIN 作業，分析 AWS、Azure、公開資料集和其他 Google Cloud 服務等各種儲存解決方案中的資料。跨雲端聯結 可讓您不必先跨來源複製資料，再執行查詢。

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

跨雲端加入所需的權限

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

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

所需權限

如要執行跨雲端聯播，必須具備下列權限：

• bigquery.datasets.create
• bigquery.tables.create

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

跨雲端聯結會建立含有 __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 Omni 區域位於同一位置的 BigQuery 區域，以及 US 和 EU 多區域，才支援跨雲端聯結。在 US 或 EU 多區域執行的跨雲端聯結，只能存取美國或歐盟 BigQuery Omni 區域的資料。
• 如果跨雲端聯結查詢參照 BigQuery Omni 地區的 10 個以上資料集，可能會失敗並顯示 Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region> 錯誤。為避免這個問題，建議您在執行參照超過 1 個資料集的跨雲端聯結時，明確指定位置。請注意，如果您明確指定 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 連接器，透過其他資料處理工具存取 BigLake 資料表中的 Cloud Storage 資料。舉例來說，您可以透過 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 "{}") 標記，插入您的憑證。舉例來說，下列指令會在名為 myproject 的專案中，為名為 mycluster 的叢集啟用憑證傳播工作階段：

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

  注意：使用空白的憑證存取權界線，會移除一層防護機制，避免透過從 Dataproc 叢集竊取的憑證發動攻擊。如果沒有縮減範圍，遭竊憑證的影響範圍會更大。

  或者，您也可以停用個人叢集驗證，並使用 Dataproc 虛擬機器 (VM) 服務帳戶做為使用者群組的 Proxy。

• 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 中建立、更新或刪除檔案，則查詢檔案時，系統不會傳回更新後的資料，直到下次重新整理中繼資料快取為止。這可能會導致非預期的結果。舉例來說，如果您刪除檔案並寫入新檔案，查詢結果可能會排除舊檔案和新檔案，具體情況取決於快取中繼資料上次更新的時間。
  • 如果 BigLake 資料表參照 Amazon S3 或 Blob 儲存空間資料，則不支援搭配快取中繼資料使用客戶管理的加密金鑰 (CMEK)。

安全性模型

管理及使用 BigLake 表格時，通常會涉及下列機構角色：

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

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

注意：資料分析師不應具備下列權限：

• 直接從 Cloud Storage 讀取物件 (請參閱儲存空間物件檢視者 IAM 角色)，讓資料分析師規避資料倉儲管理員設定的存取權控管。

• 將資料表繫結至連線 (例如 BigQuery 連線管理員)。

  否則，資料分析師可以建立沒有任何存取權控管的新資料表，規避資料倉儲管理員設定的控管機制。

中繼資料快取功能可提升效能

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

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

BigQuery 使用 CMETA 做為分散式中繼資料系統，有效處理大型資料表。CMETA 提供資料欄和區塊層級的精細中繼資料，可透過系統資料表存取。這個系統會最佳化資料存取和處理方式，進而提升查詢效能。為進一步提升大型資料表的查詢效能，BigQuery 會維護中繼資料快取。CMETA 重新整理作業會讓這個快取保持在最新狀態。

中繼資料包括檔案名稱、分割資訊，以及來自檔案的實體中繼資料，例如列數。您可以選擇是否在資料表上啟用中繼資料快取功能。如果查詢的檔案數量龐大，且包含 Apache Hive 分區篩選器，中繼資料快取功能就能發揮最大效益。

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

中繼資料快取也會與 Cloud Storage 物件版本管理功能整合。快取填入或重新整理時，會根據當時 Cloud Storage 物件的即時版本擷取中繼資料。因此，即使 Cloud Storage 中出現較新版本，啟用中繼資料快取功能的查詢也會讀取特定快取物件版本對應的資料。如要存取 Cloud Storage 中任何後續更新的物件版本資料，必須重新整理中繼資料快取。

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

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

啟用中繼資料快取功能後，您可以指定可接受的資料表作業中繼資料過時間隔上限。舉例來說，如果您指定 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

Sensitive Data Protection 會掃描 BigLake 表格，找出並分類機密資料。如果偵測到機密資料，Sensitive Data Protection 去識別化轉換可以遮蓋、刪除或隱藏該資料。

費用

BigLake 資料表的下列項目會產生費用：

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

如果您有運算單元預留，查詢外部資料表時不會產生費用。而是會耗用這些查詢的配額。

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

	以量計價	Standard、Enterprise 和 Enterprise Plus 版本
查詢	系統會根據使用者查詢處理的位元組數向您收費。	運算單元會在查詢期間，用於指派給QUERY工作類型的保留項目。
手動重新整理中繼資料快取。	系統會針對重新整理快取所處理的位元組向您收費。	快取重新整理期間會耗用指派給QUERY工作類型的運算單元。
自動重新整理中繼資料快取。	系統會針對重新整理快取所處理的位元組向您收費。	快取重新整理期間會耗用指派給BACKGROUND工作類型的運算單元。 如果沒有可用的 BACKGROUND 預留資源來重新整理中繼資料快取，且您使用的是 Enterprise 或 Enterprise Plus 版本，BigQuery 會自動改用 QUERY 預留資源中的運算單元。

系統也會依據各產品的價格規定，針對 Cloud Storage、Amazon S3 和 Azure Blob Storage 的儲存空間和資料存取權向您收費。

後續步驟

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