BigQuery

解決する課題

• テラ〜ペタバイト級のデータを事前のクラスタ構築なしに、標準 SQL で素早く分析したい
• 分析ワークロードに合わせてサーバーやインデックスをチューニング・運用する手間から解放されたい
• ストレージと計算リソースを独立にスケールさせ、使った分だけ支払いたい
• BI ツールやレポートからインタラクティブに対話的クエリを投げたい
• ETL を組まず、Cloud Storage 上のファイルにもそのまま SQLを当てたい（フェデレーション/外部テーブル）

主要概念と用語

• データセット (Dataset): テーブルやビューをまとめる入れ物。リージョン（またはマルチリージョン）を持ち、アクセス制御の単位にもなる。AWS でいうスキーマ/データベースに近い
• テーブル / 外部テーブル: 通常テーブルは BigQuery 管理ストレージに保存。外部テーブルは Cloud Storage や他ソース上のデータを移動せずに参照する（AWS の Athena / Redshift Spectrum に相当）
• スロット (Slot): クエリ実行に使う仮想 CPU の計算単位。オンデマンドでは自動割り当て、容量課金では予約したスロット数で並列度が決まる
• オンデマンド課金 / 容量課金 (Editions): 課金モデル。オンデマンドはスキャンしたバイト量で課金、容量課金（Editions）はスロット時間で課金する
• パーティション分割テーブル: 日付や整数範囲などでテーブルを区切り、スキャン範囲を絞る仕組み。コストとパフォーマンスに直結する
• クラスタリング: 指定列でデータを物理的に並べ替え、フィルタや集計のスキャン量をさらに削減する
• マテリアライズドビュー: クエリ結果を事前計算してキャッシュし、増分更新する高速化機能
• BigQuery ML (BQML): SQL だけで機械学習モデルを学習・推論できる機能
• BigQuery Omni: AWS や Azure 上のデータに対し、データを移動せず BigQuery のエンジンでクエリするマルチクラウド機能

仕様・制限・クォータ

• サーバーレスでクラスタのプロビジョニング・パッチ・スケーリングは不要。ストレージと計算が分離されており、片方だけを増減できる
• 標準 GoogleSQL（ANSI 準拠の SQL） をサポート。配列・構造体（ネスト/繰り返し）など半構造化データも扱える
• 読み込みはバッチロード（無料枠あり）とストリーミング挿入 / Storage Write API（低レイテンシ、課金あり）の両方に対応
• クエリには結果サイズや実行時間、同時実行などの上限があり、ストリーミングや DML にもクォータが設定される。具体的な数値は変動するため、上限はドキュメントで都度確認する
• ストレージはアクティブと**長期（一定期間更新のないデータは自動的に割安）**の 2 区分。物理ストレージ課金を選ぶこともできる

内部の仕組み

BigQuery は計算とストレージを分離した分散アーキテクチャです。データは列指向フォーマットでストレージ層（Colossus 分散ファイルシステム上）に保持され、クエリ実行時にはDremel 由来の実行エンジンが多数のスロットへ処理を分散します。中間データのやり取りは高速ネットワークを介したシャッフルで行われ、ツリー状に集約されて結果が返ります。

この分離により、ストレージは安価に保持しつつ、クエリのたびに必要なだけの計算資源を割り当てられます。列指向なので参照する列だけを読み、パーティションとクラスタリングが効くと読み取るデータブロック自体が減り、課金されるスキャン量も小さくなります。結果は短時間キャッシュされ、同一クエリの再実行はキャッシュヒットなら無料かつ即時になります。

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

• パーティション分割 + クラスタリングを基本にし、クエリは必ずパーティション列で絞る。これがコストとレイテンシの最大の決め手
• SELECT * を避け、必要な列だけを指定する（列指向なのでスキャン量が直接減る）
• 大きな前処理結果はマテリアライズドビューやスケジュールクエリで事前集計し、ダッシュボードの応答を高速化
• ETL は Dataflow / Dataform / Datastream、ニアリアルタイム取り込みは Storage Write API を使い分ける
• 探索的・スポット的な利用はオンデマンド、安定して大量に回す本番は**容量課金（Editions のスロット予約 + オートスケール）**でコストを平準化
• データ移動を避けたい場合は外部テーブル / BigLake / Omni を検討

運用・監視

• INFORMATION_SCHEMA ビューでジョブ履歴・スロット使用・スキャン量・コスト要因を SQL で分析できる
• Cloud Monitoring でスロット使用率やクエリのレイテンシ、エラー率を監視。容量課金では予約スロットの飽和を見る
• クエリプラン / 実行詳細で各ステージの処理時間やシャッフル量を確認し、ホットステージやスキューを特定する
• 高コストクエリはドライランでスキャン量を事前確認し、本番投入前にチューニングする
• ジョブのラベル付けや予約への割り当てで、部門・用途別のコスト配賦を行う

コスト

セキュリティ

• IAM でプロジェクト・データセット・テーブル単位の権限を最小化。さらに列レベル・行レベルのアクセス制御で機密データを限定公開できる
• 保存データは Google 管理鍵で既定暗号化。要件に応じて CMEK（顧客管理鍵, Cloud KMS） を適用する
• 外部流出対策に VPC Service Controls でデータ境界を設定し、エクスポートやコピーの抜け道を塞ぐ
• Authorized View（承認済みビュー） やポリシータグ（Data Catalog 連携） で、元テーブルを直接見せずに必要な範囲だけ共有する
• データ共有はコピーを配らず、Analytics Hub や承認済みビューで参照権を渡す設計が安全

Well-Architected の観点

• パフォーマンス効率: サーバーレスで計算が自動分散し、パーティション/クラスタリングと列指向によりスキャンを最小化。マテリアライズドビューや結果キャッシュで応答を短縮できる
• コスト最適化: スキャン量課金とスロット容量課金をワークロード特性で使い分け、上限設定とドライランで予期せぬ高額化を防ぐ。長期ストレージ自動割引も効く

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) データセットを作成（リージョン指定）
bq --location=asia-northeast1 mk --dataset MY_PROJECT:demo

# 2) 日付パーティション + クラスタリングのテーブルを作成
bq mk --table \
  --time_partitioning_field=event_date \
  --time_partitioning_type=DAY \
  --clustering_fields=user_id \
  MY_PROJECT:demo.events \
  event_date:DATE,user_id:STRING,amount:NUMERIC

# 3) Cloud Storage の CSV をバッチロード
bq load --source_format=CSV --skip_leading_rows=1 \
  MY_PROJECT:demo.events \
  gs://MY_BUCKET/events/*.csv

# 4) ドライランでスキャン量を確認（課金前の見積もり）
bq query --use_legacy_sql=false --dry_run \
  'SELECT user_id, SUM(amount) AS total
   FROM `MY_PROJECT.demo.events`
   WHERE event_date = "2026-06-14"
   GROUP BY user_id'

# 5) クエリ実行（パーティション列で絞り込みスキャンを最小化）
bq query --use_legacy_sql=false \
  'SELECT user_id, SUM(amount) AS total
   FROM `MY_PROJECT.demo.events`
   WHERE event_date = "2026-06-14"
   GROUP BY user_id
   ORDER BY total DESC
   LIMIT 10'