G-gen の佐藤です。当記事では、BigQuery から外部ストレージを参照する2つの構成、従来の外部テーブルと BigLake テーブルの違いを検証した結果を紹介します。

はじめに

BigLake とは

BigLake とは、Google Cloud が提供する分析用データベース BigQuery で、アクセス権限の委任を使用して、BigQuery 外部のストレージにあるデータをクエリするための仕組みです。BigLake の仕組みで作成されたテーブルは BigLake テーブルと呼ばれ、外部テーブルの発展系とされています。

参考 : BigLake 外部テーブルの概要

BigLake の概要については、以下の記事も参考にしてください。

参考 : BigQueryを徹底解説！(応用編) - G-gen Tech Blog - BigLake

検証方法

BigLake テーブルの中でもメタデータキャッシュの効果が高いとされる Hive パーティショニング構成を用いて、外部テーブルと BigLake テーブルを1つずつ作成します。

参考 : 外部でパーティションに分割されたデータを使用する

それぞれのテーブルが、「セキュリティ（アクセス制御）」と「パフォーマンス（スキャン量）」においてどのような挙動の差を示すかを検証します。具体的には、以下の3点に着目しました。

観点	概要
列レベルのアクセス制御	データカタログのポリシータグを付与し、アクセス制御が可能か
行レベルのセキュリティ	`CREATE ROW ACCESS POLICY` 文によるフィルタリングが適用できるか
クエリパフォーマンス	メタデータキャッシュによって、スキャン量（処理されたバイト数）がどの程度削減されるか

検証環境の構築

Cloud Storage

検証のため、Cloud Storage バケットを用意します。その中にフォルダ構成を作成して、CSV ファイルを配置します。

当検証では、Hive パーティショニング分割テーブルを作成するために、日付ごとにフォルダを分割しました。各フォルダ内には、1ファイルあたり約70 KB の CSV ファイルを100個、用意しました。

gs://biglake-connect-test/
└ datasets/
    └ hive_partitioned/   
        ├ dt=2026-03-25/  
        │    ├ sample_data_0.csv
        │    ├ sample_data_1.csv
        │    └ ...
        ├ dt=2026-03-26/
        │    ├ sample_data_0.csv
        │    ├ sample_data_1.csv
        │    └ ...
        └ dt=2026-03-27/
              ├ sample_data_0.csv
              ├ sample_data_1.csv
              └ ...

参考 : 外部でパーティションに分割されたデータを使用する

外部テーブルと BigLake テーブル

外部テーブルと BigLake テーブルを作成します。どちらのテーブルも、同じ Cloud Storage パスを参照しています。DDL は以下のとおりです。

従来の外部テーブル

CREATE EXTERNAL TABLE `project_id.dataset_id.external_table`
WITH PARTITION COLUMNS (
  dt DATE,
)
OPTIONS (
  hive_partition_uri_prefix = "gs://biglake-connect-test/",
  uris=['gs://biglake-connect-test/*'],
  format ="CSV"
);

BigLake テーブル

CREATE OR REPLACE EXTERNAL TABLE `project_id.dataset_id.biglake_table`
WITH PARTITION COLUMNS (
  dt DATE,
)
WITH CONNECTION `project_id.asia-northeast1.sample_gcs_connect`
OPTIONS (
  hive_partition_uri_prefix = "gs://biglake-connect-test/",
  uris=['gs://biglake-connect-test/*'],
  max_staleness = INTERVAL 4 HOUR,
  metadata_cache_mode = 'MANUAL',    -- 今回は手動でメタデータを更新する
  format ="CSV"
);

検証1. 列レベルのアクセス制御

概要

BigQuery には特定の列に対してアクセス制限をかける列レベルのアクセス制御機能があります。この機能では、ポリシータグと呼ばれるタグを、テーブルの列に適用することでアクセス制御を実現します。

外部テーブルと BigLake テーブルのそれぞれに対して、スキーマ編集画面からポリシータグを適用できるかを確認します。

外部テーブルの場合

外部テーブルの場合、Google Cloud コンソール画面の BigQuery テーブルのスキーマ編集画面にポリシータグを追加するボタンが表示されず、ポリシータグを設定できないことがわかります。

BigLake テーブルの場合

BigLake テーブルには、同じ画面に Add policy tag ボタンが表示されており、ポリシータグを追加できることがわかります。

検証2. 行レベルのセキュリティ

概要

行レベルのセキュリティは、Google アカウントやグループが、特定の値を持った行にだけアクセスできるように制御する機能です。この機能では、アクセスポリシーという設定を、テーブルに適用することで有効化します。

外部テーブルと BigLake テーブルのそれぞれに対して、アクセスポリシーを定義する SQL が実行できるかを検証します。

外部テーブルの場合

外部テーブルに対してアクセスポリシーを作成する SQL を実行しようとすると、サポートされていない旨の警告が表示されます。

BigLake テーブルの場合

BigLake テーブルの場合は、同様の SQL が問題なく実行できます。

検証3. パフォーマンス比較

概要

BigLake テーブルは、メタデータキャッシュを利用して外部ファイルの情報を事前に把握することで、不要なスキャンを最小限に抑えるプルーニングを効率化します。この仕組みによって具体的にどれほどの差が生じるのか、実測データをもとに確認します。

参考 : パフォーマンス向上のためのメタデータキャッシュ

メタデータキャッシュの更新

以下の SQL を実行して、BigLake テーブルのメタデータキャッシュを手動で更新します。

CALL BQ.REFRESH_EXTERNAL_METADATA_CACHE('project_id.dataset_id.biglake_table');

参考 : BQ.REFRESH_EXTERNAL_METADATA_CACHE

クエリの実行

外部テーブルと BigLake テーブルのそれぞれに対して、日付パーティションを指定してフィルタリングを行う以下のクエリを実行しました。

SELECT
  COUNT(*)
  , dt
FROM
  `project_id.dataset_id.table_name`
WHERE
  dt = '2026-03-26' 
GROUP BY
  dt;

ジョブ詳細の確認

外部テーブルの場合

BigLake テーブルの場合

従来の外部テーブルに対して、BigLake テーブルでは、スロット時間は約58分の1、処理されたバイト数は約98分の1まで減少しました。

日付ごとのフォルダの中には約7 MB の CSV が格納されているため、従来の外部テーブルでもパーティショニングが効果を発揮しており、特定のフォルダ内のファイルのみが読み込まれていることがわかります。しかし BigLake テーブルの場合、追加のメタデータキャッシングにより、必要最小限のファイルのみが読み込まれていることがわかります。