データ分析基盤 — BigQuery・Pub/Sub・Dataflow

データが流れる道 — 分析基盤の全体像

第 8 章から第 10 章まではデータを「置く・捌く」プロダクトを見てきました。本章はそのデータを「分析する」側、つまりデータ分析基盤です。Google Cloud の分析基盤は、収集（Pub/Sub）→ 処理（Dataflow）→ 保存・分析（BigQuery）→ 可視化（Looker Studio など）という 4 段のパイプラインが基本形で、公式ドキュメントでも ETL / BI の代表構成としてこの並びが示されています。まず全体の地図を頭に入れましょう。

BigQuery — サーバーレスデータウェアハウス

アーキテクチャ: ストレージとコンピュートの分離

BigQuery はフルマネージド・サーバーレスのデータウェアハウスです。インスタンスのプロビジョニングもスケール操作も不要で、SQL（GoogleSQL）を投げるとその場で必要な計算資源が割り当てられます。設計の核心はストレージ層とコンピュート層の分離です。データは列指向フォーマットで専用ストレージに保存され、クエリ実行時だけスロット（クエリ実行の計算単位。仮想 CPU）が割り当てられて、両層をペタビット級の内部ネットワークが結びます。読み書きと分析が同じリソースを取り合う従来型 DB のボトルネックがなく、ストレージとコンピュートを独立にスケール・課金できるのがポイントです。

データはプロジェクト → データセット → テーブル / ビューの階層で管理します。データセットにはロケーション（asia-northeast1 や US マルチリージョンなど）があり、作成後は変更できません。操作はコンソール・bq CLI・REST API・各言語のクライアントライブラリ・ODBC / JDBC ドライバから行えます。取り込みは Avro / Parquet / CSV / JSON などのバッチ読み込み（課金対象外の無料オペレーション）と、Storage Write API によるストリーミング挿入の 2 系統が基本です。分析側の拡張として、SQL だけで機械学習モデルを作る BigQuery ML、外部データを扱う BigLake・外部テーブル・フェデレーテッドクエリも用意されています。

パーティショニングとクラスタリング — スキャン量を設計する

BigQuery のオンデマンド課金は「クエリがスキャンしたバイト数」で決まるため、スキャン量を減らす設計 = 性能とコストの設計です。道具は 2 つあります。

パーティショニングはテーブルを区画（パーティション）に物理分割し、フィルタに合致する区画だけをスキャンさせる仕組みです（プルーニング）。種類は 3 つ — ① DATE / TIMESTAMP / DATETIME 列による時間単位パーティショニング（粒度は時間 / 日 / 月 / 年。日次が既定で最もよく使う）、② 取り込み時刻で自動分割する取り込み時間パーティショニング（疑似列 _PARTITIONTIME で参照）、③ 整数列の範囲で分割する整数範囲パーティショニングです。

クラスタリングは指定した列（最大 4 列。指定順に効く）の値でストレージブロックをソート・同居配置し、フィルタや集計に関係するブロックだけを読ませる仕組みです。高カーディナリティ（値の種類が多い）列に強く、追加データの再クラスタリングはバックグラウンドで自動・無料で行われます。両者は併用でき、「日付でパーティション → 区画内をユーザー ID でクラスタリング」が定番です。

料金モデルとコスト制御

クエリ（コンピュート）の課金は 2 モデルから選びます（2026-08 時点）。

• オンデマンド（TiB 単価）: スキャンしたバイト数に課金。us マルチリージョンで $6.25/TiB、東京（asia-northeast1）で $7.59375/TiB。毎月最初の 1 TiB は無料です。小〜中規模や不定期の分析はまずこちら
• 容量ベース（スロット時間単価）: エディション（Standard / Enterprise / Enterprise Plus）でスロットを確保し、スロット時間に課金。オートスケーリングに対応し、1 年 / 3 年のコミットメントで割引。大量・定常的なワークロードで月額を予測可能にしたい場合はこちら

ストレージは月あたり最初の 10 GiB が無料で、90 日間変更のないテーブルは自動的に約 50% 割引の長期保存料金になります。バッチ読み込み・テーブル削除などは無料オペレーションです。学習用にはBigQuery サンドボックスもあり、クレジットカードなし・無料枠（ストレージ 10 GiB / クエリ月 1 TiB）だけで試せます（テーブルは 60 日で自動失効。ストリーミングや DML は使えません）。

コスト暴走を防ぐ道具は覚える価値があります。実行前にスキャン量を確認する bq query --dry_run、上限を超えるクエリを実行前に拒否する --maximum_bytes_billed、プロジェクト / ユーザー単位で 1 日のスキャン量を制限するカスタムクォータ、そして中身を眺めるだけなら課金されないプレビュー（bq head）です。

Pub/Sub — 非同期メッセージング

トピックとサブスクリプション

Pub/Sub は非同期・スケーラブルなメッセージングサービスです。メッセージを送るパブリッシャーはトピックに publish し、受け取るサブスクライバーはサブスクリプション経由でメッセージを受信します。送信側は受信側が誰か・生きているかを知る必要がなく、コンポーネントの疎結合化とトラフィックスパイクの吸収がこのサービスの存在意義です。1 つのトピックに複数のサブスクリプションを付ければ、同じメッセージを複数システムがそれぞれのペースで処理できます。配信レイテンシは典型的には 100 ミリ秒程度で、リアルタイム分析・イベント駆動アーキテクチャ（第 7 章の Eventarc / Cloud Run functions）・IoT テレメトリの受け口として使われます。

配信保証は既定で at-least-once（少なくとも 1 回）、順序保証なしです。つまり同じメッセージが 2 回届くことがある前提で、受信処理は冪等に作ります。サブスクリプションの受信方式は次から選びます。

確認応答・再配信・デッドレター

受信したメッセージは処理完了後に確認応答（ack）を返します。ack が ack 期限（既定 10 秒、10〜600 秒で設定可能）内に返らなければ、Pub/Sub はそのメッセージを再配信します。未 ack のメッセージはメッセージ保持期間（既定 7 日、10 分〜31 日）の間残り続けます。またサブスクリプション自体にも有効期限があり、既定ではサブスクライバーの活動が 31 日間ないと自動削除されます（無期限にも設定可能）。

処理が恒久的に失敗するメッセージ（不正なフォーマットなど）を放置すると再配信が無限に続くため、デッドレタートピックを設定します。配信試行回数が max-delivery-attempts（5〜100 回、既定 5 回）を超えたメッセージは別トピックへ隔離され、後から調査・再処理できます。設定時は Pub/Sub のサービスアカウント（service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com）に、デッドレタートピックへの roles/pubsub.publisher と元サブスクリプションへの roles/pubsub.subscriber を付与する必要があります。

順序指定と exactly-once

既定の Pub/Sub は順序を保証しませんが、メッセージに順序指定キー（ordering key）を付け、サブスクリプションで --enable-message-ordering を有効にすると、同一キー・同一リージョンで publish されたメッセージは publish 順に配信されます。代償として順序指定キーごとのスループットは 1 MBps に制限され、途中のメッセージが再配信されると後続も連鎖して再配信されます。また pull 型サブスクリプションでは exactly-once 配信（同一リージョン内での再配信抑止）も有効化できます。「順序も重複排除も Pub/Sub 任せ」にはせず、まず受信側の冪等化で吸収し、本当に必要な箇所だけに絞るのが設計の定石です。ローカル開発にはエミュレータもあります（第 10 章参照）。

Dataflow と処理エンジンの選び分け

Dataflow — Apache Beam のマネージドランナー

Dataflow は、オープンソースの Apache Beam SDK（Java / Python / Go）で書いたパイプラインを実行するフルマネージドのデータ処理サービスです。最大の特徴はバッチとストリーミングを同じプログラミングモデルで書けること。ワーカー VM の割り当て・並列分散・完了後の破棄は Dataflow が自動で行い、負荷に応じた水平オートスケーリングと動的な作業再配分、Dataflow Prime による垂直オートスケーリングも備えます。レコード処理は既定で exactly-once（コストを優先するなら at-least-once モードも選択可）。Pub/Sub の at-least-once 配信と組み合わせても、集計結果に重複を持ち込まない変換層を作れるのが、図 11-1 のパイプラインで Dataflow が真ん中に座る理由です。

コードを書かずに使う道もあります。Google 提供テンプレートには「Pub/Sub から BigQuery へ」のような定番 ETL が用意されており、パラメータを与えるだけでジョブを起動できます。ノートブック（JupyterLab）での対話的開発もサポートされています。

Managed Service for Apache Spark と Cloud Composer（Managed Service for Apache Airflow）

Google Cloud Managed Service for Apache Spark（旧称 Dataproc。試験や既存資料では旧称で登場することがあります）は、Apache Spark / Hadoop エコシステムをマネージドで動かすサービスです。クラスタは 90 秒以内で起動でき、課金は秒単位（最低 1 分）。「ジョブのたびにクラスタを作り、終わったら消す」エフェメラルクラスタ運用でアイドルコストをなくせます。クラスタ管理すら不要な Managed Service for Apache Spark serverless（旧称 Serverless for Apache Spark / Dataproc Serverless）というデプロイ方式もあります。オンプレの Spark / Hadoop 資産を書き換えずに移行したいときの受け皿です。

Cloud Composer（2026-08 時点、公式ドキュメントの表記は Managed Service for Apache Airflow への移行中で、両名称が併存しています）は Apache Airflow のマネージド版で、役割がまったく異なります。Composer は処理エンジンではなくオーケストレーターです。Python で書いた DAG（タスクの依存関係グラフ）に従って、「BigQuery のロード → Dataflow ジョブ → 完了通知」のような複数サービスをまたぐワークフローをスケジュール・監視します。ハイブリッド / マルチクラウドのパイプラインもつなげます。

ハンズオン

第 1 章で作った学習用プロジェクトと Cloud Shell を使います（ローカルの gcloud + bq でも同じです）。BigQuery と Pub/Sub はどちらも使った分だけの課金で、以下のハンズオンは無料枠にほぼ収まる分量に抑えています。

# 実行前にスキャン量を確認（課金なし）
bq query --dry_run --use_legacy_sql=false \
'SELECT start_station_name, COUNT(*) AS num_trips
FROM `bigquery-public-data.new_york.citibike_trips`
GROUP BY start_station_name
ORDER BY num_trips DESC
LIMIT 10'

# 問題なければ本実行
bq query --use_legacy_sql=false \
'SELECT start_station_name, COUNT(*) AS num_trips
FROM `bigquery-public-data.new_york.citibike_trips`
GROUP BY start_station_name
ORDER BY num_trips DESC
LIMIT 10'

bq mk --location=asia-northeast1 -d pca_analytics

bq query --use_legacy_sql=false \
'CREATE TABLE pca_analytics.access_logs
PARTITION BY DATE(event_time)
CLUSTER BY user_id AS
SELECT
  TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL n MINUTE) AS event_time,
  CONCAT("user-", CAST(MOD(n, 50) AS STRING)) AS user_id,
  MOD(n, 5) AS response_class
FROM UNNEST(GENERATE_ARRAY(0, 99999)) AS n'

# 全期間スキャン
bq query --dry_run --use_legacy_sql=false \
'SELECT COUNT(user_id) FROM pca_analytics.access_logs'

# 当日パーティションのみ（バイト数が激減する）
bq query --dry_run --use_legacy_sql=false \
'SELECT COUNT(user_id) FROM pca_analytics.access_logs
WHERE DATE(event_time) = CURRENT_DATE()'

# 課金上限ガード: 上限 100 KB を超えるためエラーになり実行されない
bq query --maximum_bytes_billed=100000 --use_legacy_sql=false \
'SELECT COUNT(user_id) FROM pca_analytics.access_logs'

bq rm -r -f pca_analytics
bq ls   # 一覧から消えたことを確認

gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq

gcloud pubsub subscriptions create orders-sub --topic=orders \
  --dead-letter-topic=orders-dlq --max-delivery-attempts=5
gcloud pubsub subscriptions create orders-dlq-sub --topic=orders-dlq

PROJECT_NUMBER=$(gcloud projects describe \
  $(gcloud config get-value project) --format="value(projectNumber)")

gcloud pubsub topics add-iam-policy-binding orders-dlq \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" \
  --role="roles/pubsub.publisher"

gcloud pubsub subscriptions add-iam-policy-binding orders-sub \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" \
  --role="roles/pubsub.subscriber"

gcloud pubsub topics publish orders --message='{"order_id": 1001, "item": "coffee"}'
gcloud pubsub topics publish orders --message='{"order_id": 1002, "item": "tea"}'

# 受信と同時に ack（メッセージは消える）
gcloud pubsub subscriptions pull orders-sub --auto-ack --limit=5

# ack せずに受信 → 10 秒ほど待って再度 pull すると同じメッセージが再配信される
gcloud pubsub topics publish orders --message='{"order_id": 1003, "item": "cocoa"}'
gcloud pubsub subscriptions pull orders-sub --limit=5
gcloud pubsub subscriptions pull orders-sub --limit=5

gcloud pubsub subscriptions delete orders-sub
gcloud pubsub subscriptions delete orders-dlq-sub
gcloud pubsub topics delete orders
gcloud pubsub topics delete orders-dlq

bq mk --location=asia-northeast1 -d pca_stream
bq mk --table pca_stream.raw_events data:STRING

PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" \
  --format="value(projectNumber)")

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataEditor"

gcloud pubsub topics create sensor-events

gcloud pubsub subscriptions create sensor-to-bq \
  --topic=sensor-events \
  --bigquery-table="${PROJECT_ID}.pca_stream.raw_events"

gcloud pubsub topics publish sensor-events --message='{"device": "d-01", "temp": 21.5}'
gcloud pubsub topics publish sensor-events --message='{"device": "d-02", "temp": 23.0}'

# 数秒待ってから
bq query --use_legacy_sql=false 'SELECT data FROM pca_stream.raw_events'

gcloud pubsub subscriptions delete sensor-to-bq
gcloud pubsub topics delete sensor-events
bq rm -r -f pca_stream

gcloud projects remove-iam-policy-binding "${PROJECT_ID}" \
  --member="serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataEditor"

つまずきポイント

理解度チェック

まとめと次章へ

• 分析基盤の基本形は収集（Pub/Sub）→ 処理（Dataflow）→ 保存・分析（BigQuery）→ 可視化。変換不要なら BigQuery サブスクリプションで直行できる
• BigQuery はストレージとコンピュート（スロット）の分離が核。スキャン量の設計 = パーティショニング + クラスタリングがそのまま性能とコストを決める
• 料金はオンデマンド（TiB 単価・月 1 TiB 無料）と容量ベース（スロット時間・エディション）。dry run・maximum_bytes_billed・カスタムクォータで暴走を防ぐ
• Pub/Sub は at-least-once が既定。ack 期限（既定 10 秒）・保持 7 日・デッドレター（既定 5 回、要 IAM 設定）・順序指定キーの数字と条件を正確に
• エンジン選びは「SQL で完結 → BigQuery ELT」「既存 Spark / Hadoop → Managed Spark（旧称 Dataproc）」「新規開発 → Dataflow」、指揮は Cloud Composer（Managed Service for Apache Airflow）

ストレージとデータを巡る第 III 部はここまでです。次の第 12 章からは第 IV 部「接続とセキュリティ」に入り、オンプレミスとクラウドをつなぐハイブリッド接続と、組織スケールの VPC 設計パターンを扱います。

参考リンク（公式ドキュメント）:

• BigQuery overview / Introduction to partitioned tables / Introduction to clustered tables
• Estimate and control costs / Enable the BigQuery sandbox
• What is Pub/Sub? / Subscription properties / Configure dead letter topics / Create BigQuery subscriptions
• Dataflow overview / Managed Service for Apache Spark on clusters overview / Cloud Composer（Managed Airflow）overview