BigQuery Data Transfer Service の RDBMS コネクタと Datastream・Dataflow の使い分け

BigQuery Data Transfer Service (BQ DTS) に RDBMS コネクタが加わり、BigQuery への定期データ同期で何を選ぶかの判断軸が変わりました。

BQ DTS・Datastream・Dataflow という 3 サービスの転送モデルと、DELETE 追跡・許容遅延・変換ロジックの 3 軸での選び方を順に整理します。

新規パイプラインの方式選定や、既存構成の見直しの判断材料にしてください。

RDBMS コネクタが埋めた空白 ── BQ DTS はどこまで変わったか

BQ DTS は元来、Google Analytics・Salesforce・YouTube Analytics などの SaaS ソースから BigQuery へのスケジュール転送を担うサービスです。RDBMS への対応は長らく外部の ETL ツールや Dataflow に委ねられており、BQ DTS が直接受け持つ範囲ではありませんでした。

2025 年 12 月、Oracle・MySQL・PostgreSQL の 3 コネクタが GA に移行し、SQL Server も同月 Preview として加わりました。2026 年 4 月には Oracle・MySQL・PostgreSQL の 3 つに増分転送が Preview として追加され、SQL Server の増分転送も 2026-04-08 に Preview に加わっています。全件転送だけでなく差分取得も段階的に整備されています。

ネットワーク面では、Private Service Connect のネットワークアタッチメントを使うことでオンプレミスや他クラウド上の RDBMS にも接続できます。VPC ピアリングが不要な構成で、既存ネットワーク設計を変えずに導入できる点は実務上の大きな変化です。

ただし、この増分転送は CDC (Change Data Capture) ではありません。ウォーターマーク列 (TIMESTAMP 型) を基準にしたポーリング方式であり、UPDATE されたレコードを検出できますが、DELETE を追跡する手段はありません。この制約が、後述する方式選択の核心になります。

3 サービスの転送モデル ── 何を、どう、どの速さで動かすか

2026-05-05 時点で、公式に BQ DTS と Datastream を直接比較するガイダンスは確認できていません。本記事では各サービスの公式ドキュメントを突き合わせて整理します。

BQ DTS (RDBMS コネクタ)

更新検出はウォーターマーク列 (TIMESTAMP 型) のポーリングか、スケジュール全件転送のいずれかです。DELETE は追跡できません。最小転送間隔は Oracle が 15 分、デフォルトは 24 時間です。変換ロジックは持たず、BigQuery へのそのままの書き込みが基本です。

Datastream

binlog (MySQL)・redo log (Oracle)・LSN (PostgreSQL・SQL Server) を読み取る CDC 方式です。INSERT・UPDATE・DELETE のすべてを検出でき、秒〜分オーダーの遅延で BigQuery に届きます。初回のバックフィルと CDC の並行実行もサポートしており、スキーマドリフトも自動で検出します。

対応ソースは MySQL・Oracle・PostgreSQL・SQL Server・MongoDB・Salesforce・Spanner と幅広く、BigQuery への直接書き込みが可能です。配信保証は at-least-once です。

書き込みは Merge と Append-only の 2 モードから選びます。デフォルトの Merge モードはソース DB の現在状態を BigQuery にミラーし、主キー必須・BigQuery 内蔵の CDC 機能で背後で UPSERT が走ります。Append-only モードは全変更イベントを INSERT として履歴で残します。どちらを選ぶかで使用感とコストが大きく変わるため、後段で詳しく扱います。

Dataflow (JDBC to BigQuery テンプレート)

提供されている JDBC to BigQuery テンプレートはバッチ専用です。スケジュール実行や Composer との組み合わせで定期バッチとして動かす用途に向きます。Dataflow 単独では CDC を行えません。JDBC to BigQuery テンプレートが SELECT クエリベースの取得であり、binlog や redo log を直接読む構造を持たないためです。CDC が必要であれば、Datastream と組み合わせることで変換ロジックを挿入した CDC パイプラインを構成できます。

下表に 3 サービスの主要差異をまとめます。

転送方式を 3 軸で絞り込む ── DELETE・遅延・変換の問い

「定期同期」「CDC」「変換あり同期」という 3 層の役割分担が明確になったことで、転送要件の 3 軸に沿って方式を選べるようになりました。

軸 1: DELETE 追跡が必要か

DELETE を追跡する必要があるなら、Datastream 一択です。BQ DTS の増分転送も Dataflow 単独も、binlog を読まない設計のため、削除されたレコードを検出する手段がありません。

論理削除 (deleted_at 列を立てる方式) で運用しているのであれば BQ DTS の増分転送でも対応できます。ただしこの場合も、ウォーターマーク列に指定した updated_at 等が deleted_at 更新と同時に更新される設計でなければ、論理削除イベントを取りこぼします。物理削除のあるテーブルを BigQuery で正確に反映するには Datastream が必要です。

軸 2: 許容遅延はどれくらいか

秒〜数分の遅延が求められるなら Datastream です。15 分以上の遅延を許容できるなら BQ DTS が候補になります。バッチ処理として時間単位・日次での同期であれば Dataflow 単独でも賄えます。

軸 3: 変換ロジックの複雑度

型変換・マスキング・集約など複雑な変換が必要な場合は Dataflow を組み合わせます。Datastream が BigQuery に書き込んだ生データを Dataflow で後処理する構成か、Datastream → Pub/Sub → Dataflow のストリーミング構成が一般的です。変換が不要または軽微であれば BQ DTS か Datastream のみで完結します。

以下に判断フローを示します。

DELETE 追跡が必要か？
  YES → Datastream (+ Dataflow は変換次第)
  NO  →
    許容遅延が 15 分未満か？
      YES → Datastream
      NO  →
        変換ロジックが複雑か？
          YES → Dataflow + BQ DTS または Dataflow 単独バッチ
          NO  → BQ DTS RDBMS コネクタ

このフローを通ると、Datastream を使わなくて済むユースケースが具体的に見えてきます。DELETE を追跡しない・15 分以上の遅延を許容できる・変換が軽微という条件が揃えば、BQ DTS RDBMS コネクタで十分です。

東京リージョン基準のコスト試算 ── 「処理 GiB」の読み方が肝

料金はすべて asia-northeast1 (東京) リージョン基準で記載します。USD/JPY 換算は 1 USD = 160 円 (2026-05-05 時点) を使います。

BQ DTS

スロット時間あたり $0.0765 (約 12.2 円) です。公式は 1 時間あたり最大 20 スロット時間を保守的なガイドラインとして示しており、東京リージョンの単価で換算すると 1 時間あたり最大 $1.53 (約 245 円) に相当します。実際の消費量は転送ジョブのデータ量と並列度に依存するため、最初は小規模テーブルで実消費量を計測してから本番設定を決めると安全です。

なお、増分転送は 2026-05-05 時点で Preview 中のため無料です。Preview 終了後に料金体系が変わる可能性があるため、本番採用時は公式の料金ページで GA 後の扱いを確認してください。

Datastream

CDC 処理は $2.568/GiB (約 411 円/GiB、0–2,500 GiB 階層)、バックフィルは最初の 500 GiB が無料でそれ以降 $0.514/GiB (約 82 円/GiB) です。

ここで注意が必要なのが「処理 GiB」の計算方法です。Datastream が課金する GiB は実際のデータサイズではなく、binlog / redo log から読み取った変更イベントのサイズです。更新頻度が高いテーブルや、大きなテキスト列を含むテーブルでは、実データの 2〜5 倍の処理 GiB が計上されることがあります。

月あたりの実データ転送量が 10 GB のテーブルでも、処理 GiB ベースでは 20〜50 GiB 換算になる可能性があります。コスト試算は実データサイズではなく、ログの変更量を基準に見積もることを勧めます。

Dataflow

バッチ実行では vCPU $0.0728/時間 (約 11.6 円)・メモリ $0.0046241/GiB 時間・Shuffle $0.0143/GiB です。

ストリーミング実行では vCPU $0.0897/時間 (約 14.4 円)・Streaming Engine $0.107/カウントとなります。Shuffle は $0.0234/GiB です (いずれも東京リージョン)。

規模別の参考目安を下表に示します。実際の料金は処理量・実行時間・並列度に依存するため、概算として参照してください。

設定前に確認したい仕様 ── ウォーターマーク・ログ保持・at-least-once

BQ DTS と Datastream はそれぞれ、設定前に確認しておくべき仕様上の制約があります。

BQ DTS のウォーターマーク列

増分転送で使えるウォーターマーク列は TIMESTAMP 型のみです。INTEGER 型の連番 ID や DATE 型はウォーターマーク列として指定できません。既存テーブルに TIMESTAMP 型の更新日時列がない場合は、テーブル定義の変更が必要になります。また、先述の通り DELETE は追跡できないため、物理削除を BigQuery に反映する要件には対応できません。

Datastream for BigQuery の write mode 選択 ── Merge と Append-only

Datastream for BigQuery は Merge モードと Append-only モードの 2 つから書き込み方式を選びます。デフォルトは Merge モードで、両者で使用感とクエリパターンが大きく変わります。

Merge モードは、ソース DB の現在状態を BigQuery のテーブルにミラーします。BigQuery 内蔵の CDC 機能と Storage Write API を使い、Datastream が受け取った変更イベントを背後で UPSERT する仕組みです。テーブル作成時に max_staleness オプションが自動設定され、この値の範囲内で更新が反映されます。利用側は SELECT すれば常に最新行を取得できます。主キーが必須で、主キーがないテーブルは Merge モードを選べません。

Append-only モードは、全変更イベント (INSERT・UPDATE-INSERT・UPDATE-DELETE・DELETE) を行として BigQuery に追加していきます。主キー更新は UPDATE-DELETE と UPDATE-INSERT の 2 行で表現され、削除は DELETE 行として残ります。SCD Type 2 や監査ログ用途に向きますが、最新状態を取りたい場合は ROW_NUMBER() や QUALIFY で最新行を絞り込むクエリが必要です。

選択の目安は次の通りです。ソース DB のスナップショット相当を BigQuery で扱いたいなら Merge モード、変更履歴をすべて残したいなら Append-only モードを選びます。Merge モードはストレージとクエリパターンが素直になる一方、max_staleness の値次第で読み取り時の鮮度に揺れが出ます。Append-only モードは行数とストレージが膨らみますが、過去時点の状態を任意に再構成できます。

Datastream の at-least-once 保証と重複排除

Datastream は at-least-once 配信です。ネットワーク障害や再起動のタイミングによっては、同一の変更イベントが複数回 Datastream から BigQuery に渡る可能性があります。

Merge モードを使う場合、この重複は BigQuery 内部の UPSERT で吸収されるため、利用側で重複排除 SQL を組む必要は基本的にありません。Append-only モードを使う場合は、重複イベントが履歴として残る前提で、最新行を取り出す ROW_NUMBER() や QUALIFY のクエリパターンを設計に組み込んでおく必要があります。

また、MySQL であれば binlog、Oracle であれば redo log の保持期間が Datastream の動作に影響します。保持期間が短すぎると、障害復旧時に変更イベントをさかのぼれなくなるため、運用開始前に DBA と保持期間を確認してください。

MySQL では binlog_expire_logs_seconds、Oracle では Supplemental Logging の設定も必要です。これらはソース DB 側の責務であり、Datastream 設定だけでは完結しない点が見落とされがちです。

ネットワークアタッチメントと Private Service Connect

オンプレミスや他クラウド上の RDBMS に接続する場合、Private Service Connect のネットワークアタッチメントを使います。VPC ピアリングとは設定手順が異なるため、初回導入時に公式ドキュメントで手順を確認してください。

SQL Server コネクタの Preview 採用リスク

SQL Server コネクタは 2026-05-05 時点で Preview です。Preview は SLA の対象外であり、料金・仕様・API が変更される可能性があります。本番環境での採用は GA 移行を待つか、リスクを明示した上で意思決定することを勧めます。

転送要件が方式を決める ── 3 軸で整理すると何が見えるか

BQ DTS RDBMS コネクタの登場で、「定期同期」「CDC」「変換あり同期」という 3 層の役割分担が明確になりました。転送要件を DELETE 追跡・許容遅延・変換ロジックの 3 軸で評価することで、各方式を整理して選べるようになっています。

Datastream を入れれば全部解決、と考えていたなら半分正しいといえます。秒〜分の低遅延や DELETE 追跡が必要なユースケースでは Datastream が適切ですが、定期バッチ的な同期で DELETE を追跡しない要件であれば、BQ DTS RDBMS コネクタで構成をシンプルに保てます。Datastream が「必要ではないケース」が明確になったことが、今回の変化の実務的な意味です。

3 軸の問いを先に立てることで、オーバースペックな構成を避けられます。特に Datastream のコスト試算では処理 GiB の実データ比倍率を考慮し、BQ DTS の増分転送 Preview 終了後の料金変更にも注意しながら設計を進めてください。

参考文献

• BigQuery Data Transfer Service の概要
• BigQuery Data Transfer Service — Oracle Transfer
• BigQuery Data Transfer Service — MySQL Transfer
• BigQuery Data Transfer Service — PostgreSQL Transfer
• BigQuery Data Transfer Service — SQL Server Transfer
• BigQuery のリリースノート
• BigQuery の料金
• Datastream の概要
• Datastream for BigQuery
• Datastream — BigQuery 宛先の構成 (write mode)
• Datastream の料金
• Dataflow — JDBC to BigQuery テンプレート
• Dataflow の料金

Author

tgeas

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

profile