Datastream for BigQuery

解決する課題

• 本番のトランザクションデータベースの内容を、分析用に BigQuery へ継続的に複製したいが、自前の同期処理を作りたくない
• 夜間バッチの全件エクスポートでは鮮度が足りず、ほぼリアルタイムに最新データで分析・ダッシュボード更新をしたい
• 分析クエリを本番 DB に直接当てたくない一方で、本番への負荷を抑えて変更だけを取り出したい
• ソース側のスキーマ変更（列の追加など）に、同期を止めずに追従させたい

主要概念と用語

• CDC（変更データキャプチャ）: データベースのトランザクションログ（MySQL の binlog、PostgreSQL の論理レプリケーション、Oracle の REDO ログなど）から、挿入・更新・削除の変更だけを読み取る方式。テーブル全体を都度スキャンせず差分を捕捉する
• ストリーム (Stream): 「どのソース接続から・どの宛先へ・どのテーブルを」複製するかを定義する実行単位。これを開始すると同期が継続的に動く
• 接続プロファイル (Connection Profile): ソース DB や宛先（BigQuery）への接続情報をまとめた再利用可能な設定。ストリームはソース側と宛先側の接続プロファイルを参照する
• バックフィル (Backfill): ストリーム開始時に、既存の全行をまず一括で取り込む初期ロード。以降は CDC による差分のみを流す
• CDC ストリーミングと初期ロードの組み合わせ: バックフィルで過去分を埋め、変更ストリームで以降を追従する二段構えが基本動作
• 最大鮮度 (staleness limit): 宛先 BigQuery に変更を反映するまで許容する遅延の上限。短くすると鮮度が上がり、長くするとマージ処理を束ねてコストを抑えられる
• マージモード / 追記専用モード: ソースの最新状態を BigQuery 側に反映する マージ (UPSERT) と、変更履歴をそのまま積む 追記専用 (append-only) の出力形式

仕様・制限・クォータ

• ソースは MySQL、PostgreSQL、Oracle、SQL Server などのトランザクションデータベースが対象。宛先として BigQuery に直接書き込む構成が Datastream for BigQuery
• 動作にはソース側でトランザクションログを有効化しておく必要がある（MySQL の binlog、PostgreSQL の論理レプリケーションスロットなど）。設定はソース DB の種類ごとに異なる
• BigQuery への反映はほぼリアルタイムだが、最大鮮度の設定により実際の遅延は変わる。厳密なミリ秒同期ではなく、許容遅延を前提にした設計が必要
• 複製できるのはデータの変更であり、ビューやストアドプロシージャ、一部のデータ型などには制限がある。対応データ型や制限は変動するため公式ドキュメントで確認する
• 同時実行ストリーム数やオブジェクト数などにクォータがあり、数値は変動する。大規模な複製では事前に上限を確認する

内部の仕組み

Datastream はサーバーレスの CDC サービスで、ソース DB のトランザクションログを継続的に読み取り、変更イベント（挿入・更新・削除）を順序を保ったまま取り出します。利用者はワーカーやクラスタを管理せず、ストリームを定義して開始するだけで複製が動き続けます。ソースへはエージェントをインストールせず、ログを読む権限を持つアカウントで接続するのが基本です。

ストリームを開始すると、まずバックフィルで対象テーブルの既存行を一括取得し、BigQuery 側に初期状態を作ります。並行して、その時点以降の変更を CDC で捕捉し、初期ロードと差分が重複なくつながるように管理されます。以降はトランザクションログを追い続け、変更を BigQuery に反映します。

BigQuery 側では、ソースの最新状態を表すように変更をマージ (UPSERT) して宛先テーブルを更新するのが既定の動きです。反映の頻度は最大鮮度の設定で制御され、短く設定すれば鮮度が上がり、長く設定すれば変更をまとめて処理することで BigQuery 側のマージ負荷とコストを抑えられます。

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

• 本番 DB の分析複製は、自前の同期バッチを作らず Datastream のストリーム 1 本で「初期ロード＋継続同期」を任せる
• 取り込んだレプリカはそのまま分析の基盤とし、変換は BigQuery の SQL や Dataformで行う。取り込み（複製）と変換を分離して障害の切り分けを容易にする
• 鮮度要件とコストのバランスを最大鮮度で調整する。リアルタイム性が要らないテーブルは鮮度を緩めてマージ回数を減らす
• ソース DB には読み取り専用のレプリカを読ませて本番の負荷影響をさらに抑える構成も検討する
• スキーマ変更（列追加など）に追従させる前提で、下流のクエリやビューを列の増減に強く設計する
• 履歴分析が必要なら追記専用モードで変更履歴を保持し、最新状態が必要ならマージモードを選ぶ

運用・監視

• Cloud Monitoring でストリームのスループットや遅延、未処理イベント量を監視し、遅延が拡大していないかを継続的に確認する
• ストリームの**状態（実行中・一時停止・失敗）**とエラーを確認し、ソース接続やログ設定の問題を早期に検知する
• ログは Cloud Logging に出力されるため、監査やアラートの基盤として利用できる
• スキーマ変更や一時的なソース障害の後は、必要に応じて対象テーブルだけバックフィルを再実行して整合性を取り戻す
• 鮮度や BigQuery 側のマージ負荷が問題になったら、最大鮮度の設定と対象テーブル範囲を見直す

コスト

Datastream の料金は、おおまかに処理した変更データの量に応じて発生します。これに加えて、複製先である **BigQuery のストレージとマージ処理（クエリ/スロット）**のコストが別途かかる点が重要です。鮮度を上げるほどマージが頻繁になり BigQuery 側の処理が増えるため、鮮度とコストはトレードオフの関係にあります。

セキュリティ

• アクセス制御は IAM で行い、ストリームや接続プロファイルの作成・編集・閲覧の権限を役割ごとに最小権限で分離する（AWS の IAM 相当）
• ソース DB へは、ログ読み取りに必要な最小限の権限を持つ専用アカウントで接続し、認証情報を平文でコードに埋め込まない
• ソースへの接続経路は、**プライベート接続（VPC ピアリングなど）**や許可 IP の制限で保護し、公開インターネット経由の直結を避ける
• 宛先の BigQuery データは既定で暗号化され、要件に応じ CMEK（顧客管理鍵, Cloud KMS） を適用できる。データ流出対策として VPC Service Controls を併用する

関連サービス・比較

同じ「BigQuery へ取り込む」手段でも、定型ソースから定期ロードする BigQuery Data Transfer Service と比べると役割の違いが明確になります。Datastream は本番 DB の変更をほぼリアルタイムに複製する CDC、Data Transfer Service は SaaS やストレージからの定期バッチ取り込みです。

ハンズオン / CLI例

# 1) Datastream API を有効化
gcloud services enable datastream.googleapis.com

# 2) ソース（MySQL）への接続プロファイルを作成
gcloud datastream connection-profiles create mysql-source \
  --location=asia-northeast1 \
  --type=mysql \
  --mysql-hostname=10.0.0.5 \
  --mysql-port=3306 \
  --mysql-username=datastream \
  --mysql-password=SECRET \
  --display-name="prod-mysql"

# 3) 宛先（BigQuery）への接続プロファイルを作成
gcloud datastream connection-profiles create bq-dest \
  --location=asia-northeast1 \
  --type=bigquery \
  --display-name="analytics-bq"

# 4) ストリームを作成し、初期バックフィルと CDC を開始
gcloud datastream streams create prod-to-bq \
  --location=asia-northeast1 \
  --source=mysql-source \
  --destination=bq-dest \
  --display-name="prod-to-bq" \
  --backfill-all

# 5) ストリームの状態を確認
gcloud datastream streams describe prod-to-bq \
  --location=asia-northeast1