外部データとレイクハウス — BigLake・Iceberg・フェデレーション

「ロードしない」という選択肢

第 3 章では、外部のデータを BigQuery のネイティブストレージへロードして使う方法を学びました。ロードには「クエリが速い」「BigQuery のフル機能が使える」という利点がありますが、裏を返せば「コピーを作る」ということです。元データが更新されるたびに再ロードが必要になり、ストレージも二重に持つことになります。

BigQuery には、データを移動させずにその場でクエリするための経路が複数あります。代表的なものが次の 4 つです。

共通点は「BigQuery のネイティブストレージにデータを複製しない」こと。違いは、誰が元データへの権限を持つかとメタデータをキャッシュできるかです。この 2 点が、この章全体を貫く軸になります。

BigLake テーブル — アクセス委任とメタデータキャッシュ

BigLake テーブルは、Cloud Storage・Amazon S3・Azure Blob Storage 上の構造化データを、通常の外部テーブルと同じ CREATE EXTERNAL TABLE 文の延長で扱えるようにする仕組みです。ただし Amazon S3・Azure Blob Storage 上に作る場合は BigQuery Omni の扱いになり、データセット自体を Omni 対応リージョン（aws-us-east-1 など）に作成する必要があります。本書既定の US マルチリージョンのデータセットに作れるのは Cloud Storage の BigLake テーブルだけです（Omni は後述）。公式ドキュメントは通常の外部テーブルとの違いを次のように説明しています。

Access delegation decouples access to the BigLake table from access to the underlying data store.

普通の外部テーブルでは、クエリを投げるユーザー本人が「外部テーブルへの権限」と「Cloud Storage バケットそのものへの権限」の両方を持っている必要があります。BigLake テーブルでは、BigQuery Connection リソースに紐づくサービスアカウントがバケットへのアクセス権限を持ち、ユーザーは BigLake テーブルへの IAM 権限だけを持てば十分になります。バケットの権限管理をデータエンジニアリング側に集約し、分析者には行レベル・列レベルセキュリティを含む BigQuery 側の権限モデルだけを意識させられるのが利点です。

メタデータキャッシュは、ファイル数が多い外部データセットで特に効果を発揮します。クエリのたびに Cloud Storage のファイル一覧を取得し直すのではなく、キャッシュされたメタデータ（ファイル名・パーティション情報・行数など）を使うことでプランニングが速くなります。対応するのはオブジェクトテーブル、Amazon S3 BigLake テーブル、Cloud Storage BigLake テーブルの 3 種類で、素の Cloud Storage 外部テーブルにはこの機能はありません。

Apache Iceberg 対応 — 「外部」と「マネージド」を区別する

Apache Iceberg はオープンなテーブルフォーマットで、複数のクエリエンジン（Spark・Trino・BigQuery など）から同じデータを読み書きできることが最大の価値です。BigQuery の Iceberg 対応は、性質の異なる 2 つの機能に分かれています。名前が紛らわしいので、現行ドキュメントの表記を正として整理します。

• Apache Iceberg external tables（Iceberg 外部テーブル） — Spark や Trino など他のエンジンがすでに書き込んでいる Iceberg データを、読み取り専用で BigQuery から参照する外部テーブル。Iceberg のメタデータファイル（*.metadata.json）を指すか、Lakehouse ランタイムカタログ／AWS Glue Data Catalog 経由で接続する
• Apache Iceberg managed tables（Iceberg マネージドテーブル） — BigQuery がテーブルそのものを管理するフルマネージドテーブル。DML・スキーマ進化・タイムトラベルに対応しつつ、実データは Parquet 形式で自分の Cloud Storage バケットに保存され、Iceberg フォーマットとして他エンジンからも読み取れる。旧称は「BigLake tables for Apache Iceberg in BigQuery」で、2026 年時点のドキュメントではこの旧称から改称されている

Iceberg マネージドテーブルの作成は、通常の CREATE TABLE に table_format = 'ICEBERG' と保存先を指定するだけです。

CREATE TABLE `PROJECT_ID.handson_ch10.iceberg_events`
(
  event_id INT64,
  event_name STRING,
  event_ts TIMESTAMP
)
WITH CONNECTION `PROJECT_ID.us.biglake_conn`
OPTIONS (
  file_format = 'PARQUET',
  table_format = 'ICEBERG',
  storage_uri = 'gs://PROJECT_ID-bq-handson/iceberg/events'
);

一方、Iceberg 外部テーブルは既存の Iceberg メタデータファイルを指すだけです。

CREATE EXTERNAL TABLE `PROJECT_ID.handson_ch10.iceberg_external`
WITH CONNECTION `PROJECT_ID.us.biglake_conn`
OPTIONS (
  format = 'ICEBERG',
  uris = ['gs://other-team-bucket/lake/events/metadata/00003.metadata.json']
);

Iceberg 外部テーブルには注意点があります。参照する metadata.json は手動で最新のものに更新する必要があり、他エンジンが新しいスナップショットを書いても自動追従しません。頻繁に更新されるテーブルを他エンジンと共有するなら、マネージドテーブルか、カタログ経由（AWS Glue Data Catalog・Lakehouse ランタイムカタログ）での接続を検討してください。

オブジェクトテーブル・フェデレーテッドクエリ・Omni・Drive 連携

非構造化データにも SQL で触れる仕組みがあります。オブジェクトテーブルは Cloud Storage 上の画像・PDF・音声などのファイルを、uri・content_type・size といった固定スキーマの読み取り専用テーブルとして見せます。ファイル本体はテーブルに取り込まれず、参照だけが行と対応します。

CREATE EXTERNAL TABLE `PROJECT_ID.handson_ch10.product_images`
WITH CONNECTION `PROJECT_ID.us.biglake_conn`
OPTIONS (
  object_metadata = 'SIMPLE',
  uris = ['gs://PROJECT_ID-bq-handson/images/*']
);

オブジェクトテーブルの真価は、AI.GENERATE_TEXT・ML.ANNOTATE_IMAGE・ML.PROCESS_DOCUMENT といった AI 関数と組み合わせ、画像や文書に対して SQL 一発で推論をかけられる点にあります。この使い方は第 14 章（オブジェクトテーブルと AI 活用）で本格的に扱います。ここでは「非構造化データを SQL の世界に引き込む入口」として位置づけを押さえておいてください。

フェデレーテッドクエリは、AlloyDB・Spanner・Cloud SQL（および 2026-08 時点でプレビューの SAP Datasphere）に対して、その場でクエリを送り結果を一時テーブルとして受け取る仕組みです。EXTERNAL_QUERY 関数を使います。

SELECT *
FROM EXTERNAL_QUERY(
  'PROJECT_ID.us.cloudsql_conn',
  'SELECT order_id, status FROM orders WHERE status != ''CANCELLED'''
);

実行される SQL は接続先データベースの方言（MySQL / PostgreSQL 等）で書き、読み取り専用に限られます。パフォーマンスはネイティブの BigQuery テーブルより劣り、クロスリージョンのクエリには 1 日あたり 1 TB という上限があるため、大量データの定常的な分析には向きません。「トランザクション DB の最新状態と BigQuery 側の分析データを都度突き合わせたい」といった、小〜中規模のルックアップ用途に向いています。

BigQuery Omni は、Amazon S3・Azure Blob Storage に置いたままのデータに対して BigQuery のクエリエンジンを実行する仕組みです。データを Google Cloud 側に移動させず、コンピュートの方をデータの近く（AWS 6 リージョン・Azure 1 リージョンで提供）に配置します。BigQuery の料金モデルがそのまま適用されますが、DML・BigQuery ML・JavaScript UDF は非対応で、クロスクラウドのデータ転送にはエグレス料金がかかります。「マルチクラウドでデータがサイロ化しているが、分析基盤は BigQuery に統一したい」という組織向けの選択肢です。

Google スプレッドシートや Google ドライブ上のファイルも、Cloud Storage と同様に外部テーブルとして参照できます。スプレッドシートを都度エクスポートする運用から抜け出し、業務部門が更新するシートを BigQuery 側からそのまま SQL で読みに行けるのが利点です。ただし更新頻度の高い共同編集シートを分析の主データソースにするのは避け、あくまで補助的なマスタデータの参照に留めるのが安全です。

bq mk --location=US --dataset PROJECT_ID:handson_ch10

CREATE OR REPLACE EXTERNAL TABLE `PROJECT_ID.handson_ch10.states_external`
(
  name STRING,
  post_abbr STRING
)
OPTIONS (
  format = 'CSV',
  uris = ['gs://cloud-samples-data/bigquery/us-states/us-states.csv'],
  skip_leading_rows = 1
);

-- 処理: 数十 KB 程度（実測は dry run / エディタ右上の見積もりで確認）
SELECT name, post_abbr
FROM `PROJECT_ID.handson_ch10.states_external`
WHERE post_abbr IN ('CA', 'TX', 'NY');

bq load --location=US --autodetect --source_format=CSV \
  handson_ch10.states_loaded \
  gs://cloud-samples-data/bigquery/us-states/us-states.csv

bq rm -r -f -d PROJECT_ID:handson_ch10

gcloud storage buckets create gs://PROJECT_ID-bq-handson --location=us

bq mk --connection --location=US \
  --connection_type=CLOUD_RESOURCE \
  biglake_conn

bq show --location=US --connection PROJECT_ID.us.biglake_conn
# 出力の serviceAccountId をメモする

gcloud storage buckets add-iam-policy-binding gs://PROJECT_ID-bq-handson \
  --member="serviceAccount:CONNECTION_SERVICE_ACCOUNT" \
  --role="roles/storage.objectViewer"

echo "name,post_abbr" > /tmp/states.csv
echo "California,CA" >> /tmp/states.csv
gcloud storage cp /tmp/states.csv gs://PROJECT_ID-bq-handson/states/states.csv

CREATE OR REPLACE EXTERNAL TABLE `PROJECT_ID.handson_ch10.states_biglake`
(
  name STRING,
  post_abbr STRING
)
WITH CONNECTION `PROJECT_ID.us.biglake_conn`
OPTIONS (
  format = 'CSV',
  uris = ['gs://PROJECT_ID-bq-handson/states/*.csv'],
  skip_leading_rows = 1,
  max_staleness = INTERVAL 1 HOUR,
  metadata_cache_mode = 'AUTOMATIC'
);

-- 処理: 1 KB 未満（無料枠内）
SELECT * FROM `PROJECT_ID.handson_ch10.states_biglake`;

bq rm -r -f -d PROJECT_ID:handson_ch10
bq rm --connection --location=US PROJECT_ID.us.biglake_conn
gcloud storage rm -r gs://PROJECT_ID-bq-handson

CREATE TABLE `PROJECT_ID.handson_ch10.iceberg_events`
(
  event_id INT64,
  event_name STRING,
  event_ts TIMESTAMP
)
WITH CONNECTION `PROJECT_ID.us.biglake_conn`
OPTIONS (
  file_format = 'PARQUET',
  table_format = 'ICEBERG',
  storage_uri = 'gs://PROJECT_ID-bq-handson/iceberg/events'
);

INSERT INTO `PROJECT_ID.handson_ch10.iceberg_events`
VALUES (1, 'signup', CURRENT_TIMESTAMP()),
       (2, 'purchase', CURRENT_TIMESTAMP());

UPDATE `PROJECT_ID.handson_ch10.iceberg_events`
SET event_name = 'purchase_completed'
WHERE event_id = 2;

SELECT * FROM `PROJECT_ID.handson_ch10.iceberg_events` ORDER BY event_id;

bq rm -r -f -d PROJECT_ID:handson_ch10
bq rm --connection --location=US PROJECT_ID.us.biglake_conn
gcloud storage rm -r gs://PROJECT_ID-bq-handson

つまずきポイント

理解度チェック

まとめと次章へ

• データが動き続けているなら、外部テーブル・BigLake テーブル・フェデレーテッドクエリのいずれかで「その場に置いたまま」問い合わせる選択肢がある
• BigLake テーブルは外部テーブルにアクセス委任とメタデータキャッシュを足したもの。権限管理を BigQuery 側に集約したいときの標準解
• Apache Iceberg 対応は「external tables（読み取り専用）」と「managed tables（BigQuery が書き込みを管理するフルマネージド、旧称 BigLake tables for Apache Iceberg in BigQuery）」の 2 つを区別する
• オブジェクトテーブルは非構造化データを SQL に引き込む入口。AI 関数との組み合わせは第 14 章で扱う
• フェデレーテッドクエリと BigQuery Omni は「読むだけで理解が完結する」機能として、必要になったときに選択肢として思い出せれば十分

• 外部データソースの概要
• BigLake の概要
• Apache Iceberg managed tables
• Apache Iceberg external tables
• オブジェクトテーブルの概要
• フェデレーテッドクエリの概要
• BigQuery Omni の概要
• 外部テーブルのメタデータキャッシュ