BigQuery BI Engine

解決する課題

• BI ダッシュボードのクエリが秒単位かかり、フィルタやドリルダウンの操作感が重いのを改善したい
• 同じデータに対する反復的・対話的なクエリを、毎回フルにスキャンせず高速に返したい
• アプリやクエリの書き換えなしで、既存の BigQuery テーブルをそのまま高速化したい
• キャッシュ用の別システム（インメモリ DB など）を構築・運用する手間をかけずに低レイテンシを得たい
• ダッシュボードの同時利用者が増えても応答時間を安定させたい

主要概念と用語

• BI Engine: BigQuery に統合されたインメモリ分析アクセラレータ。よく使うデータをメモリ上の列指向フォーマットで保持し、対象クエリを高速化する
• 予約容量 (Reservation / Capacity): BI Engine がデータ保持に使えるメモリ量。プロジェクトとロケーション単位で確保し、上限まで自動的にデータがキャッシュされる
• インメモリキャッシュ: テーブルの一部または全体を圧縮した列指向データとしてメモリに常駐させる仕組み。スキャン量と I/O を削減する
• アクセラレーション (高速化対象): BI Engine が処理できるクエリ。集計・フィルタなど多くの分析クエリが対象で、対象外の処理は通常の BigQuery エンジンへフォールバックする
• フォールバック: BI Engine で処理しきれない部分を従来の BigQuery 実行エンジンが引き継ぐ動作。結果の正しさは保たれる
• インテリジェントキャッシュ管理: アクセス頻度に応じて、どのデータをメモリに載せ続けるかを自動で判断する仕組み
• マテリアライズドビューとの連携: マテリアライズドビューと組み合わせると、事前集計済みデータをさらにメモリで高速化できる

仕様・制限・クォータ

• SQL やスキーマの変更は不要で、予約容量を設定すると対象クエリへ透過的に適用される
• 高速化の対象になるかはクエリの内容とデータ型に依存し、対象外の演算や非常に大きな結果はフォールバックする
• メモリは有限のため、予約容量を超えるデータはすべてキャッシュされず、ヒットしない部分は通常スキャンになる
• ロケーション（リージョン/マルチリージョン）単位で容量を確保し、確保したメモリ量に応じて課金される
• 対応する関数・データ型・最大容量などの具体的な上限値は変動するため、ドキュメントで都度確認する

内部の仕組み

BI Engine は BigQuery の実行パスに組み込まれたインメモリ層です。対象クエリが来ると、参照テーブルの列データを圧縮した列指向フォーマットでメモリに保持し、ディスクや分散ファイルシステムへのスキャンを避けて結果を組み立てます。これにより、ストレージ I/O とデータ転送が大幅に減り、レイテンシが短縮されます。

どのデータをメモリに載せ続けるかはアクセス頻度に基づいて自動管理され、利用者がキャッシュを明示的に温める必要は基本的にありません。クエリの一部が BI Engine の対応範囲を超える場合は、その部分だけ従来の BigQuery エンジンへフォールバックするため、結果の正確性はそのまま保たれます。マテリアライズドビューと併用すると、事前集計済みの小さな結果をメモリに置けて、さらに応答が速くなります。

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

• ダッシュボードが繰り返し叩くテーブルを BI Engine の対象に据え、ホットデータをメモリに収める設計にする
• 先にパーティション分割・クラスタリングでスキャン量を絞り、その上で BI Engine を重ねると効果が高い
• 重い前処理はマテリアライズドビューで事前集計し、その結果を BI Engine で高速化する
• 予約容量は実データサイズではなく、よくアクセスされる範囲を載せられる量を目安に調整する
• Looker / Looker Studio など反復的なインタラクティブ BIを主対象とし、単発の大規模バッチ分析には期待しない

運用・監視

• INFORMATION_SCHEMA のジョブ関連ビューで、各クエリが BI Engine で高速化されたか、フォールバックしたかを確認できる
• Cloud Monitoring で予約容量の使用率やヒット状況を監視し、容量不足によるフォールバック増加を検知する
• レイテンシが期待ほど下がらないときは、対象外の演算が混ざっていないか実行詳細で確認する
• アクセスパターンの変化に合わせて予約容量を定期的に見直し、過不足を調整する

コスト

セキュリティ

• アクセス制御は BigQuery の IAM にそのまま従う。BI Engine が独自に権限を緩めることはなく、列レベル・行レベルのセキュリティも維持される
• 高速化はあくまで内部のメモリ層で行われ、利用者から見える権限境界は元テーブルと同じ
• 保存データの暗号化や VPC Service Controls などの境界制御も、BigQuery の設定がそのまま適用される
• キャッシュへの格納はサービス内部で完結し、データが外部の別システムへ移動するわけではない

関連サービス・比較

最も関係が深いのは土台となる BigQuery 本体で、BI Engine はその上に乗るインメモリ高速化レイヤーです。事前集計の マテリアライズドビュー とは補完関係にあり、両者を併用すると効果が重なります。

ハンズオン / CLI例

# BI Engine の予約容量を作成・確認する例（bq の予約コマンド）
# ロケーションを指定して予約管理を行う

# 1) 既存の予約状況を確認
bq ls --reservation --location=US --project_id=MY_PROJECT

# 2) BI Engine 用の予約を作成（容量はメモリ量で指定）
bq mk --bi_reservation \
  --location=US \
  --project_id=MY_PROJECT \
  --size=2

# 3) 設定された BI Engine 予約の内容を表示
bq show --bi_reservation \
  --location=US \
  --project_id=MY_PROJECT

# 4) 高速化状況は INFORMATION_SCHEMA で確認
bq query --use_legacy_sql=false \
  'SELECT job_id, bi_engine_statistics.bi_engine_mode AS mode
   FROM `region-us`.INFORMATION_SCHEMA.JOBS
   WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
   ORDER BY creation_time DESC
   LIMIT 20'