BigQuery データ基盤の鮮度と加工品質を両立するアーキテクチャパターン

本記事では、BigQuery を中心としたデータ基盤で、鮮度と加工パイプラインの複雑度を両立するアーキテクチャパターンを整理します。 2026 年現在、取り込みレイヤーには Datastream・Pub/Sub BigQuery Subscription・Storage Write API といった選択肢があり、加工レイヤーにはマテリアライズドビュー・Continuous Queries・Dataform・Cloud Composer が並立しています。各サービスの組み合わせ方と、最新サービスへの代替が有効かどうかの判断基準を順に整理します。 各パターンの選択基準と設計上の境界を把握することで、技術選定会議で根拠のある判断材料を持ちましょう。

BigQuery データ基盤の設計地図 ── 取り込みと加工を分けて考える理由

データ基盤の設計を「BigQuery に何を使って書くか」という問いだけで考えると、設計が一枚岩になりやすいです。

取り込みサービスに変換ロジックを押し込んだり、加工処理のレイテンシ要件を取り込みパイプラインに持ち込んだりすると、ひとつの変更が全体に波及する構造になってしまいます。

これを防ぐ出発点は、取り込みレイヤーの責務を「データを届けること」に限定し、変換は独立した加工レイヤーに委ねる境界を引くことです。この境界がパターン選択の判断軸になります。

鮮度要件と加工の重さを 2 軸で整理すると、適切なサービス構成が見えてきます。

なお、既存パイプラインで Pub/Sub Lite を使っている場合は注意が必要です。Pub/Sub Lite は 2026 年 3 月 18 日にサービス終了しているため、本記事のすべての取り込みパターンは標準の Pub/Sub を前提にしています。

取り込みレイヤーの責務は「データを最短で BigQuery に届けること」です。この段階で複雑な変換を行おうとすると、パイプラインの障害がデータ到着そのものに影響します。

加工レイヤーは取り込みが完了したデータを対象に、独立したサイクルで変換・集計を行う役割です。

既存記事「BigQuery Data Transfer Service と Datastream・Dataflow の使い分け」では RDBMS ソースの選択軸を扱っています。本記事はその上位レイヤーにあたる「鮮度 × 加工の全体アーキテクチャ設計」として、合わせて参照するとアーキテクチャ全体が見渡せます。

取り込みレイヤーの選択 ── ソース形態と鮮度要件で決まる 4 パターン

Datastream → BigQuery 直接 CDC

Datastream は CDC (Change Data Capture) サービスです。RDBMS やクラウドサービスからの変更を BigQuery Storage Write API 経由で直接 BigQuery に書き込みます。

対応ソースは MySQL・Oracle・PostgreSQL・SQL Server・AlloyDB に加え、MongoDB・Salesforce・Spanner にも対応しています (2026 年 5 月時点)。

変更追跡モードは 2 種類あります。UPDATE と DELETE を追跡する Merge モードと、変更行を追記し続ける Append-only モードです。

スキーマドリフト (列追加・テーブル追加) は自動追従しますが、列削除・データ型変更・TRUNCATE は対象外です。

取り込みレイヤーとしての Datastream の強みは、アプリケーション側にコードを追加せずにログベースの CDC を実現できる点です。既存の RDBMS をソースにしたい場合に、アプリ側の変更なしで BigQuery への連携を始められます。

一方、Storage Write API でアプリから直接書き込む構成と比較すると、アプリ側にコード追加が可能であれば直書きの方が低コスト・低レイテンシです。

Datastream が必要になるのは「RDBMS など、コードを追加できない既存ソースからの CDC が必要な場合」と考えると整理しやすいです。

料金面の注意点として、Datastream の課金単位は「内部表現バイト数」です。実データの 2〜5 倍になることがあるため、転送量の見積もりには余裕を持たせる必要があります。

また BigQuery 側で CDC 処理コストが別途発生します。

東京リージョン (asia-northeast1) の単価は CDC 0〜2,500 GiB/月が $2.316/GiB で、段階的に逓減します (出典: Datastream 料金、確認日: 2026-05-09)。

Pub/Sub → BigQuery Subscription と Single Message Transforms

Pub/Sub の BigQuery subscription は、受信したメッセージを BigQuery テーブルに直接書き込むエクスポートサブスクリプションです。Dataflow のようなクラスタを別途用意せずに、Pub/Sub からの書き込みを完結できます。

2025 年 6 月 10 日に Single Message Transforms (SMT) の JavaScript UDF が GA になりました。

1 サブスクリプションあたり最大 5 つの SMT を連結でき、フォーマット変換・キャスト・フィールド追加・フィルタリング・PII マスク・Vertex AI 推論を組み合わせられます (出典: Pub/Sub SMT ブログ、2025-06-10)。

SMT でできないことの境界を明確にしておくことが重要です。複数メッセージにまたがる集計・ウィンドウ処理・JOIN・ステートフル処理は SMT の対象外です。 このような処理が必要になった時点で、Dataflow への移行を検討する判断基準になります。

逆に、現在 Pub/Sub + Dataflow で処理しているパイプラインのうち、変換が単一メッセージ内に収まる部分は SMT で置き換えを検討できます。Dataflow クラスタを廃止できれば運用コストとスロット予約コストの削減につながります。

Storage Write API でアプリから直書き

Storage Write API は、アプリケーションから BigQuery にデータを直接書き込む低レイテンシ API です。

旧来の tabledata.insertAll API (Streaming Insert API) からの公式推奨移行先で、スループットは旧 API の約 3 倍です (出典: BigQuery Storage Write API ドキュメント)。

ストリームの種別として 4 種類あります。

• Default stream: 常時利用可能。At-least-once。書き込み直後にクエリ可能
• Committed type: オフセット付きで exactly-once。書き込み直後にクエリ可能
• Pending type: コミットまでバッファリング。アトミックなバッチ書き込みの代替
• Buffered type: Apache Beam 連携向け。行レベルコミット

月最初の 2 TiB は無料で、以降は $0.03/GiB (東京リージョン) です (出典: BigQuery 料金、確認日: 2026-05-09)。中間サービスを持たない分、Pub/Sub を挟む構成に比べてコストと遅延が最小になります。ただし再送・リトライはアプリ側の責務になるため、アプリの設計で配信保証を担う必要があります。

連携クエリ ── データを動かさないという選択

Federated Query は BigQuery から外部データベースにクエリを送信し、結果を一時テーブルとして受け取る仕組みです。Spanner・Cloud SQL (MySQL/PostgreSQL)・AlloyDB に対応しており、データのコピーを行わずに OLTP の最新データを BigQuery から参照できます。

「データを動かさずにリアルタイムの最新値を参照したい」「ETL パイプラインを作りたくない」という場面に向いています。

一方で、都度ライブクエリを発行するため外部データベースへの負荷が増加し、結果サイズが大きい場合は転送オーバーヘッドが顕著になります。大規模な分析用途では Datastream で BigQuery にコピーした方が高スループット・低レイテンシです。

Datastream CDC との境界として整理すると、「コピーしたくない / 鮮度要件が極めて高い / OLTP と直結したい」場合は Federated Query、「大規模分析・バッファリング・DELETE 追跡」が必要な場合は Datastream という判断になります。

加工レイヤーの選択 ── BigQuery 内でどう変換・集計するか

マテリアライズドビューと増分処理

マテリアライズドビュー (MV) は、クエリ結果を事前計算してキャッシュします。ベーステーブルの変更後おおむね 5〜30 分でリフレッシュされ (ベストエフォート)、変更分のみを読み込む増分更新で動作します (出典: BigQuery MV ドキュメント)。

ニアリアルタイムほどの鮮度は不要で、クエリコストを抑えながら集計結果を高速に返したいという場面のコスト最適解です。追加のサービスが不要で BigQuery 内で完結するため、運用シンプルさにも優れています。

制約として、MV 上に別の MV を作成することはできません。DML も非対応で、SQL 定義を変更するには再作成が必要です。外部テーブル・論理ビュー・スナップショットをベースにした MV も作成できないため、取り込みレイヤーの出力先が標準テーブルであることが前提になります。

Continuous Queries ── SQL でリアルタイム加工する新しい選択肢

Continuous Queries は 2025 年 4 月に GA になったサービスです。BigQuery に到着したデータを SQL で連続処理し、別の BigQuery テーブルや Pub/Sub・Bigtable・Spanner にリアルタイムで出力します (出典: Continuous Queries ドキュメント)。

入力源は BigQuery テーブルへの追記ストリームです。Datastream や Pub/Sub・Storage Write API で BigQuery テーブルに到着したデータが対象になります。外部ストリームを直接入力にするわけではなく、「取り込み完了後の SQL 連続処理」という位置付けで動作します。

GA になった Stateless 操作では、JSON 処理・変換関数・AI.GENERATE を使った AI 推論などが使えます。複数ストリームの JOIN・集計・ウィンドウを扱う Stateful 操作は現時点で Preview です。

加工レイヤーの設計で Continuous Queries が持つ意味は大きいです。従来は「取り込み後のリアルタイム変換は Dataflow」という構図でしたが、SQL だけで完結する Stateless 変換であれば Continuous Queries が担える範囲が広がっています。

既存の Dataflow パイプラインのうち、stateless な変換 (フィルタ・フォーマット変換・列追加・AI 推論によるエンリッチメント) を担う部分から段階的に移行できます。Dataflow を完全には外せなくても、加工 DAG の一部を Continuous Queries に切り出すだけで Beam 依存を減らせます。

ただし利用には Enterprise または Enterprise Plus エディションの CONTINUOUS 予約が必須です。東京リージョンの Enterprise スロット予約は $0.0765/slot-hour で、スロット予約コストを別途計上する必要があります。また PIVOT / UNPIVOT / SELECT DISTINCT / UDF には非対応です。

Dataform / Cloud Composer ── 複雑な変換 DAG の制御

複数テーブルにまたがる変換 SQL の依存関係管理・テスト・バージョン管理が必要な場合、Dataform が加工レイヤーの担い手になります。既存記事「Dataform ── Scheduled Queries の次に選ぶ理由」に詳細を書いています。

取り込みと加工を分離する設計思想において、Dataform の役割を明確にしておくことが重要です。Dataform は BigQuery にすでに届いたデータを対象に動作します。取り込みパイプラインの完了をトリガーに、次の変換 DAG を実行するという依存関係を持つ構成で機能します。

例えば Datastream が BigQuery への書き込みを完了したタイミングで Cloud Logging から Pub/Sub に通知を発行し、それを Workflows 経由で Dataform のリリース実行に接続する構成が一例です。取り込みが変わっても加工 DAG の SQL は変わらない、という分離が実現できます。

外部サービスとの連携や複雑なワークフロー制御が必要な場合は Cloud Composer が選択肢になります。Cloud Composer は豊富な Operator を持ち、BigQuery 以外のシステムも含めたマルチシステム依存のワークフローを制御できます。

Pub/Sub → Dataflow → BigQuery が依然として残るケース

SMT と Continuous Queries の登場で、Dataflow に頼らず取り込み・加工を完結できるケースが増えています。それでも Dataflow が不可欠な領域があります。

Dataflow を外せない条件を整理すると以下のとおりです。

• 複数ストリームのリアルタイム JOIN (ステートフル処理)
• ウィンドウ集計 (タンブリング・スライディング・セッション)
• Exactly-once が必須な金融・決済処理
• 重いエンリッチメント (外部 API 呼び出し・複雑な変換ロジック)
• 大量シャッフルが必要な変換

Dataflow のストリーミング処理 (Streaming Engine) の東京リージョン単価は vCPU が $0.0897/vCPU-hour、メモリが $0.0046241/GiB-hour、Shuffle が $0.0234/GiB です。これは米国 (us-central1) の vCPU $0.056/hour と比較して約 30% 高くなります (出典: Dataflow 料金、確認日: 2026-05-09)。

Exactly-once や複数ストリームの JOIN が同時に必要な場合、Continuous Queries の Stateful GA を待つか Dataflow を継続利用するかの判断になります。

構成を選ぶときに踏み外しやすい 3 つの境界

境界 1: 取り込みレイヤーで変換しすぎる罠

Datastream や Pub/Sub BigQuery Subscription に重い変換ロジックを押し込もうとすると、設計が崩れます。Datastream は CDC の配信に特化したサービスであり、変換ロジックは持ちません。SMT も単一メッセージ内の変換に限定されます。

「取り込みレイヤーではデータを届けることだけに集中し、変換は加工レイヤーに委ねる」という設計境界を守ることで、それぞれのサービスの保守・改修サイクルが独立します。取り込みサービスを変更しても加工 SQL は変わらない、という分離が運用上の安定性につながります。

境界 2: Continuous Queries の予約コストと機能制限の見落とし

Continuous Queries の料金設計は「スロット予約 × 稼働時間」です。オンデマンド課金のような「クエリ実行分だけ払う」モデルではありません。Enterprise 予約のスロット数 × 稼働時間で固定コストが発生するため、処理量が少ない時間帯でも予約コストは発生します。

また Stateful 操作が Preview である点も設計判断に影響します。本番ワークロードで複数ストリームの JOIN やウィンドウ集計が必要な場合、現時点では Dataflow を選ぶ方が安全です。Stateful の GA 後に移行を計画に加えておくことで、将来の設計変更コストを下げられます。

PIVOT / UNPIVOT / SELECT DISTINCT / UDF が非対応である点も、SQL の設計段階で確認が必要です。

境界 3: Datastream の課金単位と BigQuery CDC の追加コスト

Datastream の課金が「内部表現バイト数」に基づくことは、見積もり段階で見落としやすいポイントです。実際のデータサイズの 2〜5 倍になりうるため、月の転送量を過小評価すると請求が想定を大きく上回ります。

加えて、Datastream → BigQuery の構成では BigQuery 側で CDC 処理コストが別途発生します。Datastream の料金だけを見て試算すると、実際のコストより低く見積もることになります。両者の合算で試算する必要があります。

パターン別コスト構造 ── 東京リージョンで試算すると見えてくること

主要パターンの課金構造を横断比較します (1 USD = 160 円換算、確認日: 2026-05-09)。

東京リージョンは米国 (us-central1) と比較して Dataflow が約 30% 高く、Pub/Sub・BQ Subscription は全リージョン共通価格です。Storage Write API も東京 $0.03/GiB に対し米国 $0.025/GiB と差があります。

コスト面で取り込みレイヤーと加工レイヤーを分離する意義は、それぞれの最適化が独立して行えることです。

Datastream のコストが高くなった場合でも、加工レイヤーの Dataform には影響しません。逆に Continuous Queries のスロット予約コストを最適化しても、取り込みパイプラインの見直しは不要です。

出典:

• Datastream 料金
• Pub/Sub 料金
• BigQuery 料金
• Dataflow 料金

まとめ ── 取り込みと加工を分離することで何が変わるか

取り込みと加工をレイヤーで分離する設計は、それぞれの保守・改修サイクルを独立させます。取り込みサービスを入れ替えても加工 SQL は変わらず、加工 DAG を最適化しても取り込みパイプラインは触らずに済みます。

この分離が、長期運用での変更コストを下げる最も確実な設計判断です。鮮度と複雑な加工を両立させたい場面では、取り込みは最新サービスで最短化し、加工は独立したパイプラインに委ねる、という二段構えで考えるのが基本になります。

設計選択の判断順序として、次の流れで整理できます。

1. ソース形態を確認する: RDBMS / アプリ直書き / ストリームイベント / 外部参照のいずれか
2. 取り込みレイヤーを選ぶ: Datastream (RDBMS CDC) / Storage Write API (アプリ直書き) / Pub/Sub + BQ Subscription (イベント) / Federated Query (外部参照)
3. 加工要件に応じて加工レイヤーを選ぶ: マテリアライズドビュー (5〜30 分) / Continuous Queries stateless (リアルタイム・軽量変換) / Dataform (複雑 SQL・依存管理) / Dataflow (JOIN・ウィンドウ・Exactly-once)

今後の変化として、Continuous Queries の Stateful 操作が GA になると、加工レイヤーの選択肢が一段階広がります。複数ストリームの JOIN やウィンドウ集計を SQL だけで実装できる範囲が拡大し、Dataflow が必要なケースが絞られていく可能性があります。

関連記事:

• BigQuery Data Transfer Service と Datastream・Dataflow の使い分け ── RDBMS ソースの選択軸
• Dataform ── Scheduled Queries の次に選ぶ理由 ── 加工レイヤーとしての Dataform 詳細

参考文献

• Datastream for BigQuery
• Datastream ソース一覧
• Pub/Sub BigQuery サブスクリプション
• Pub/Sub Single Message Transforms
• BigQuery Storage Write API
• BigQuery 連携クエリ
• BigQuery マテリアライズドビュー
• BigQuery Continuous Queries
• Dataflow 概要
• BigQuery ワークロードオーケストレーション

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile