WEB問題集
ある小売企業は、過去 5 年分・約 3 TB の販売明細を BigQuery に保管し、店舗別・日次の売上推移を BI ツールで可視化しています。マネージャは「直近 7 日間の移動平均と前年同曜日比を同一画面で比較したい」と要望しています。レポートは毎朝 8 時に約 200 名が同時参照し、低レイテンシかつスキャンコストの抑制が求められます。最も適切な BigQuery の実装方針はどれですか？
正解：C
正解の根拠
Materialized View は集計結果を事前計算して保持し、ベーステーブル更新時に増分でメンテナンスされるため、移動平均や前年同曜日比のような繰り返し参照される集計をスキャンコストを抑えつつ低レイテンシで提供できます。BigQuery のクエリオプティマイザはベーステーブルへのクエリを自動的に Materialized View に書き換えるため、BI ツール側の改修も不要であり、200 名同時参照のシナリオに適しています。
サービス比較
| 項目 | Materialized View | バッチ集計テーブル |
|---|---|---|
| 更新 | 自動増分 | 手動スケジュール |
| クエリ書換 | 自動 | 不可 |
| 整合性 | 常に最新 | バッチ遅延 |
不正解の理由
- A: バッチ集計はジョブ遅延や更新漏れが発生し、クエリ書換も手動で BI 側改修が必要です。
- B: BI キャッシュ依存ではキャッシュミス時にフルスキャンが走り、コストとレイテンシが悪化します。
- D: 大量同時参照にオンデマンドのみでは BI Engine の高速化を受けられず、レイテンシ要件を満たせません。
マーケティング部門は、約 80 億行の購買履歴を BigQuery で分析し、顧客の生涯価値 (LTV) を予測したいと考えています。データサイエンスチームは存在せず、SQL に習熟したアナリストのみで運用する必要があります。モデルの再学習は月 1 回、推論は毎日バッチで実行できれば十分です。最も運用負荷が低い設計はどれですか？
正解：C
正解の根拠
BigQuery ML は CREATE MODEL 文と ML.PREDICT 関数によって、SQL のみで回帰や分類モデルの学習と推論を完結できます。データサイエンスチームを持たない組織でも、既存のアナリスト人材だけで LTV 予測のような回帰タスクを構築・運用できる点が大きな利点です。データを BigQuery 外に移動させないためデータ移動コストもかからず、スケジュールクエリで月次再学習と日次推論を自動化できます。
サービス比較
| 項目 | BigQuery ML | Vertex AI Workbench |
|---|---|---|
| 学習言語 | SQL | Python |
| 必要スキル | SQL アナリスト | データサイエンティスト |
| データ移動 | 不要 | 必要に応じ抽出 |
不正解の理由
- A: Vertex AI Workbench は柔軟ですが Python と ML 知識が前提で、運用負荷が高すぎます。
- B: Dataproc Spark MLlib はクラスタ運用が必要で、SQL アナリストのみの体制では維持困難です。
- D: Cloud Functions の 1 行推論はスループットが低く 80 億行のバッチに非現実的です。
金融機関のアナリストは、口座取引テーブルから「各口座の直近 5 回の取引のうち最大金額」を SQL で算出する必要があります。テーブルは口座 ID と取引日時で並んでおり、約 50 億行が格納されています。BigQuery で最もシンプルかつ効率的にこのロジックを実装する方法はどれですか？
正解：C
正解の根拠
BigQuery 標準 SQL の WINDOW 関数は、PARTITION BY と ORDER BY、ROWS フレーム指定により、各口座の現在行から直近 5 行 (現行 + 直近 4 件後ろ) のスライディング集計を 1 パスで計算できます。サブクエリやスクリプトループに比べてシャッフル回数を最小化でき、50 億行規模でも効率的に動作します。クエリも宣言的で保守性に優れます。
サービス比較
| 項目 | WINDOW フレーム | ROW_NUMBER + CTE |
|---|---|---|
| パス回数 | 1 回 | 2 回以上 |
| シャッフル | 少 | 多 |
| 可読性 | 高 | 中 |
不正解の理由
- A: ROW_NUMBER 経由は CTE と再集計が必要で、シャッフルが追加されコストが増えます。
- B: ARRAY_AGG + UNNEST は中間配列を生成しメモリ消費が大きく、50 億行では非効率です。
- D: スクリプトループはクエリ数が爆発し、BigQuery の並列実行モデルに反します。
ある企業の経営層は、Looker でモデル化された KPI を社内全体に配布するダッシュボードを構築したいと考えています。データガバナンスチームは、すべての KPI ロジックを Looker 上で一元管理し、Looker Studio 上のレポートでも同じ計算式を利用させたいと要望しています。最も適切な構成はどれですか？
正解：C
正解の根拠
Looker の LookML には Explore、ディメンション、メジャーといったセマンティックモデルを記述でき、KPI の計算ロジックを一元管理できます。Looker Studio には Looker コネクタが提供されており、同じ LookML の Explore を Looker Studio のデータソースとして利用することで、ロジックを二重実装せずにダッシュボードを構築できます。これによりガバナンスと一貫性が両立します。
サービス比較
| 項目 | LookML + Looker コネクタ | BigQuery ビュー |
|---|---|---|
| ロジック管理 | セマンティック層で集中管理 | SQL 層のみ |
| 権限制御 | Looker のアクセスフィルタ | BigQuery IAM のみ |
| ガバナンス | 強 | 弱 |
不正解の理由
- A: レポート毎の計算フィールドはロジックが分散し、ガバナンス要件に反します。
- B: ビューは SQL 単位の再利用に留まり、Looker のメジャー定義や行レベルセキュリティを共通化できません。
- D: Sheets 経由はデータ量や鮮度に制約があり、企業全体の KPI 配布基盤には不向きです。
あるグローバル企業は AWS S3 にイベントログを蓄積していますが、分析チームは BigQuery の SQL で AWS データを直接クエリしたいと考えています。データを GCS にコピーする運用コストや遅延は避けたいです。最適なアプローチはどれですか？
正解：D
正解の根拠
BigQuery Omni は AWS や Azure のオブジェクトストレージを BigQuery の SQL から直接クエリできるマルチクラウド分析機能です。データを GCS にコピーする必要がなく、データレジデンシー要件のあるシナリオでも S3 を移動させずに分析でき、ETL 遅延と運用コストを大幅に削減できます。アナリストは慣れ親しんだ BigQuery のインターフェースで作業を継続できます。
サービス比較
| 項目 | BigQuery Omni | Storage Transfer Service |
|---|---|---|
| データ移動 | 不要 | 必要 |
| 遅延 | クエリ時 | 転送頻度依存 |
| 運用 | 低 | 転送ジョブ管理 |
不正解の理由
- A: 日次コピーは鮮度が低下し、データ重複保管のコストも発生します。
- C: Dataflow も結局データ移動を伴い、レジデンシー要件があると採用しづらいです。
- B: Cloud Run + AWS CLI はスケールしにくく、運用負荷が高く本格分析基盤には不適です。