BigLake

解決する課題

• Cloud Storage や他クラウド上のファイルを移動せず、BigQuery と同じ SQL で分析したい
• データレイク（オブジェクト上のファイル）とデータウェアハウス（管理テーブル）でバラバラだったアクセス制御を一元化したい
• 素の外部テーブルでは難しい行レベル・列レベルのきめ細かなセキュリティを、レイク上のデータにも適用したい
• 利用者にストレージの直接権限を配らず、テーブル経由でだけデータへアクセスさせたい（権限の委任）
• Parquet や Iceberg などのオープンフォーマットを、BigQuery 以外のエンジンとも共有しながら統制したい

主要概念と用語

• BigLake テーブル: Cloud Storage などの外部データを参照する強化版の外部テーブル。素の外部テーブルと異なり、行/列レベルセキュリティや接続による権限委任を適用できる
• 接続 (Connection): BigLake テーブルがストレージへアクセスする際に使うサービスアカウントの委任先。利用者ではなくこの接続の権限でファイルを読むため、利用者にバケット権限を渡さずに済む
• メタストア (BigLake metastore / BigQuery metastore): テーブルのスキーマやメタデータを管理する仕組み。Spark など外部エンジンとメタデータを共有するために使う
• オブジェクトテーブル (Object table): 画像や音声などの非構造化ファイルを行として扱える特殊なテーブル。SQL や ML から非構造化データを参照できる
• オープンテーブルフォーマット: Apache Iceberg など、複数エンジンから読み書きできるテーブル形式。BigLake はこれらを統制下に置きつつ分析できる
• 行レベル / 列レベルセキュリティ: 行はフィルタ条件、列はポリシータグ（Dataplex 連携）で参照範囲を絞る、レイク上のデータにも効くきめ細かな制御

仕様・制限・クォータ

• 参照できるソースは主に Cloud Storage。BigQuery Omni 経由で AWS S3 / Azure Blob Storage 上のデータも対象にできる
• 対応フォーマットは Parquet / ORC / Avro / CSV / JSON などに加え、Apache Iceberg などのオープンテーブルフォーマット
• BigLake テーブルは読み取り（クエリ）が中心。素の外部テーブルにキャッシュやメタデータ最適化を加え、スキャン性能を高められる
• アクセスは接続のサービスアカウントに委任されるため、利用者へバケットの直接権限を付与しない設計が前提
• 接続数・テーブル数・メタデータ更新頻度などに上限があり、具体的な数値は変動するため最新のドキュメントで都度確認する

内部の仕組み

BigLake は、BigQuery の分散クエリエンジンが Cloud Storage 上のファイルを直接読む外部テーブルの仕組みを土台にしています。素の外部テーブルとの最大の違いは、ストレージへのアクセスを接続（サービスアカウント）に委任する点です。利用者は BigLake テーブルへの権限さえあればよく、裏側でファイルを読むのは接続のアイデンティティになります。この間接化によって、テーブル定義の上に行/列レベルのアクセス制御を重ねられます。

さらに、テーブルのメタデータ（スキャン対象ファイルの一覧や統計）を最適化・キャッシュすることで、ファイルへの問い合わせ回数を減らし、素の外部テーブルより安定したスキャン性能を引き出します。メタストアを介して Spark などの外部エンジンと同じメタデータを共有すれば、1 つのデータを複数エンジンから一貫した定義で扱えます。

設計パターン / ベストプラクティス

• 利用者にはバケットの直接権限を渡さず、接続のサービスアカウントに最小権限を与え、テーブル経由でだけアクセスさせる
• 機密データを含むレイクには行/列レベルセキュリティを設定し、管理テーブルと同じ統制ポリシーで運用する
• 列の機密度は Dataplex のポリシータグで分類し、タグに基づいて列アクセスを制御する
• 複数エンジン（BigQuery と Spark など）で同じデータを使うなら、メタストアでメタデータを共有し定義の二重管理を避ける
• 他クラウドにあるデータは、コピーせず BigQuery Omni + BigLake で「その場でクエリ」し、転送コストとガバナンスの分散を抑える
• 非構造化ファイルの分析・ML 連携が必要ならオブジェクトテーブルを併用する

運用・監視

• クエリ実行や接続のアクセスは Cloud Audit Logs に記録され、誰がどのテーブル経由でデータを読んだかを追跡できる
• INFORMATION_SCHEMA や BigQuery のジョブ履歴でスキャン量・実行時間を確認し、外部テーブル特有の遅さがないか点検する
• 接続のサービスアカウントに付与したストレージ権限が過大でないかを定期的に棚卸しする
• メタデータが古いとスキャン対象がずれるため、ファイル追加時のメタデータ更新（リフレッシュ）運用を決めておく
• 列アクセスを支えるポリシータグの割り当て状況を Dataplex 側で監視する

コスト

セキュリティ

• ストレージアクセスを接続のサービスアカウントに委任し、利用者にはバケットの直接権限を渡さない（権限の集約・最小化）
• レイク上のデータにも行レベル・列レベルのアクセス制御を適用し、管理テーブルと同水準の統制を実現する
• 列の機密度は Dataplex のポリシータグで分類し、分類に応じて参照可否を制御する
• 保存データは Cloud Storage 側の暗号化（CMEK 対応）に従い、鍵管理は Cloud KMS で統制する
• VPC Service Controls でデータ境界を設定し、エクスポートやコピーによる流出経路を塞ぐ

関連サービス・比較

BigLake はレイク上のデータを統制して分析する役割で、データ資産の発見・分類カタログを担う Dataplex としばしば一緒に使われます。両者は競合ではなく補完関係です。

ハンズオン / CLI例

# 1) Cloud Storage へアクセスするための接続を作成
bq mk --connection \
  --location=asia-northeast1 \
  --connection_type=CLOUD_RESOURCE \
  my_biglake_conn

# 2) 接続のサービスアカウントを確認（このアカウントにバケット権限を委任する）
bq show --connection asia-northeast1.my_biglake_conn

# 3) 表示されたサービスアカウントにバケットの閲覧権限を付与
gcloud storage buckets add-iam-policy-binding gs://MY_BUCKET \
  --member="serviceAccount:CONNECTION_SA@PROJECT.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# 4) 接続を使って Parquet ファイル群を参照する BigLake テーブルを定義
bq mk --table \
  --external_table_definition=@PARQUET=gs://MY_BUCKET/events/*.parquet@asia-northeast1.my_biglake_conn \
  MY_PROJECT:demo.events_biglake

# 5) 通常の SQL でクエリ（利用者はバケット権限なしでテーブル経由で読める）
bq query --use_legacy_sql=false \
  'SELECT user_id, COUNT(*) AS cnt
   FROM `MY_PROJECT.demo.events_biglake`
   GROUP BY user_id
   ORDER BY cnt DESC
   LIMIT 10'