BigQuery Data Transfer Serviceとは：対応ソースと転送スケジュール設計・自前バッチとの分岐

BigQuery Data Transfer Service（DTS）は、あらかじめ設定されたスケジュールに基づいてBigQueryへのデータ移行を自動化するマネージドサービスです。転送元・転送先・繰り返しスケジュールを「転送構成」として登録すれば、取り込み処理のコードを自分で書かずに定期実行できます。この記事は、対応データソース25種以上を3系統に分けた性格の違い、既定24時間・最小間隔15分という制約から逆算するスケジュール設計、バックフィル180日と更新期間0〜30日を前提にした冪等な再実行、そしてCloud DataflowやDataform、自前バッチとの線引きを実装者の目線で整理したものです。DTSを選ばずに別の手段へ寄せるべき場面も、条件付きで示します。

まとめ：DTSで足りる条件と、自前の取り込み処理へ切り替える境界

DTSが担うのは「変換を伴わない定期取り込み」です。対応ソースの一覧に転送元があり、必要な鮮度が15分以上で、加工はBigQueryに入れたあとのSQLで済むなら、取り込みのコードを自前で書く理由はありません。認証情報の保管、リトライ、実行履歴の保持まで含めてGoogle Cloud側が持ちます。

切り替えの境界は3つに絞れます。第一に、15分より短い間隔が要るとき。定期スケジュールでは組めないため、Cloud Storageへのファイル到着を契機にするイベントドリブン転送か、別の取り込み経路を検討します。第二に、BigQueryへ入れる前の変換が要るとき。マスキングや名寄せを取り込み時点で済ませたいなら、Apache Beamを実行するCloud Dataflowの領分です。第三に、転送元が対応ソースに無いとき。ここだけは自前で書くか、別のSaaSを挟むかの二択になります。

先に押さえる前提は3つ。BigQueryから外部への書き出しには対応しないこと、データセットのロケーションは転送構成より先に決まり後戻りできないこと、バックフィルは1リクエストあたり最大180日で同時実行できないこと。知らずに走り出すと、初期移行の日程とテーブル配置をやり直すことになります。

BigQuery Data Transfer Serviceの転送構成と対応ソース3系統

最初に理解しておく単位が「転送構成」と「転送実行」です。設定の粒度と実行の粒度がずれていると、再実行や障害対応の手順を組み立てられません。

転送構成に保存する設定項目と、転送実行1回あたりが担う処理の範囲

転送構成は、転送元のソース種別、宛先のデータセット、繰り返しスケジュール、そしてソース固有のパラメータをひとまとめにした設定オブジェクトです。作成経路はGoogle Cloudコンソール、bqコマンドラインツール（bq mk --transfer_config）、Data Transfer Service APIの3つで、内容は同じものを指します。APIから転送構成を作る場合の認証方式とサービスアカウントの権限設計は、BigQuery APIの選び方と権限・リトライ設計に整理しました。

• ソース種別と接続情報（対象アカウント、認証、バケットやスキーマの指定）
• 宛先データセットと宛先テーブル名（日付パラメータを含められる）
• 繰り返しスケジュールと更新期間
• ソース固有パラメータ（ファイル形式、書き込み設定、対象テーブルの一覧など）

動く単位は転送実行（transfer run）で、スケジュールが来るたびに1回ぶんが生成されます。実行はBigQueryのロードジョブに落ちるため、処理量や失敗理由はジョブ履歴から追えます。障害切り分けの起点は転送構成ではなく、常に個々の実行です。

Google SaaS・外部ストレージ・DWHという対応ソース3系統の違い

対応ソースは25種以上ありますが、実装上の性格で3系統に分かれます。系統が違えば、スキーマを誰が決めるか、初期移行が要るかが変わります。

Google SaaS系はテーブル定義を自分で作らずに済む代わり、出力されるスキーマの変更に追随する必要があります。外部ストレージ系はファイル形式と書き込み設定を自分で決めるぶん自由度が高く、社内システムからのファイル連携を受ける入口になります。DWH系にはOracle、PostgreSQL、MySQL、Apache Hiveなども並びますが、プレビュー段階のものが混じるため、本番採用の前に対象ソースのステータスを確認してください。なお公式には、Google Cloud外のソースからの転送はSLOの対象外と明記されています。

BigQueryからの書き出しに非対応という前提と代替手段の置き方

DTSはBigQueryへの取り込み専用で、BigQueryからのデータ転送には対応しません。名前からデータの出し入れ両方を想像すると、設計の途中で行き止まりに当たります。外部へ出す経路は別に用意してください。エクスポート文でCloud Storageへ書き出す、bqコマンドで抽出する、Storage Read APIで直接読む、といった手段が対応します。

例外的に、BigQuery同士の複製はデータセットコピーとして同じサービス内に用意されています。本番プロジェクトから分析用プロジェクトへデータセット単位で複製する構成は、これで組めます。BigQueryそのものの仕組みや採用可否の判断はサーバーレスDWHとしてのBigQueryの仕組みと採用判断に整理しているので、取り込み方式より前の段階で迷っている場合はそちらを先に確認してください。

転送スケジュール設計の起点となる最小15分とイベントドリブン転送

スケジュールは「どれくらいの鮮度が要るか」から決めますが、DTSには動かせない下限があります。要件を聞く前にこの数字を持っておくと、実現できない鮮度を約束せずに済みます。

既定24時間・最小15分という間隔制約から決まるバッチ設計の型

定期転送の既定は24時間ごと、設定できる最小間隔は15分です。つまり「1時間ごとに最新化」は素直に組めますが、「5分ごとに反映」は定期スケジュールでは成立しません。要件が翌営業日の朝までに前日ぶんが揃っていればよい水準なら、日次1回で十分です。

紛らわしいのが、同じDTSの基盤上で動くスケジュールされたクエリとの差です。取り込みの最小間隔が15分であるのに対し、スケジュールクエリの最小間隔は5分と案内されています。「変換は5分ごとに回せるが、元データは15分前のもの」という状態が起こりえます。集計結果の鮮度を説明するときは、遅い側である取り込み間隔を基準にしてください。

最小15分を切る要件でイベントドリブン転送へ切り替える判断の条件

15分より短い間隔が要るときの受け皿が、イベントドリブン転送です。Cloud Storageにファイルが置かれた通知を契機に転送を走らせる方式で、時刻ではなく到着で動きます。判断の条件は3つあります。ファイルの到着が不定期であること、到着から反映までの遅延を短くしたいこと、そして1ファイル単位で処理が完結すること。

逆に、締め処理を持つ取り込みには向きません。「その日ぶんが全部そろってから集計する」業務では、到着契機で動かすと未完了の状態で下流が走ります。日次や月次の締めがある取り込みは、時刻で動くスケジュール型に寄せてください。到着契機は締めの概念がない取り込みに限る、と割り切ると運用が単純になります。

スケジュール書式の指定方法と、転送の実行時刻が遅れたときの吸収策

スケジュールはApp Engineのcron.yamlと同じ書式で書きます。every 3 hours のような指定が通り、コンソールでもbqコマンドでも同じ文字列を使います。ここで確認しておきたいのが時刻の解釈です。指定した時刻がUTCで解釈されるのか手元のタイムゾーンなのかは、転送構成の作成画面で確定させてください。日本時間の朝9時のつもりが9時間ずれると、日次の締めと集計の対象日が丸ごと1日ずれます。

元データが遅れて届く事態そのものは、スケジュールの精度では解決できません。吸収するのは更新期間の設定です。毎回の実行で直近数日ぶんを取り直しておけば、当日ぶんが遅れて確定するソースでも数値が後追いで揃います。この設定と書き込み方式の組み合わせには落とし穴があり、次章で扱います。

再実行と冪等性の設計：バックフィル180日制約と更新期間30日

取り込みの設計で最後に効いてくるのが「同じ実行をもう一度流したときに、結果が変わらないか」です。DTSは再実行の手段を持っていますが、制約値を知らずに組むと重複データを生みます。

転送先テーブルの書き込み設定で決まる、重複レコードが生じる条件

転送構成で、宛先テーブルへ追記するか、既存の内容を置き換えるかを選ぶ項目が書き込み設定です。追記を選べば実行のたびに行が積み上がるため、同じファイルや同じ期間を2回読ませた時点で重複します。置き換えを選べば、何度流しても宛先の内容は毎回同じです。冪等性はここで決まります。

実務で戻しやすいのは、宛先を日付単位に分けたうえで置き換えを選ぶ組み合わせです。特定日だけ取り直したいときに、その日のぶんだけを差し替えられます。冪等性そのものの考え方や、パイプライン全体での再実行設計はデータパイプラインの構成要素と冪等性から考える設計判断で製品に依存しない形で整理しています。DTS固有の設定に落とす前に、どこまでを再実行の単位にするかを決めておいてください。

バックフィルの1リクエスト180日・同時実行不可という運用制約

過去にさかのぼって転送を流す機能がバックフィルです。公式ドキュメントには、バックフィルリクエストごとに最大180日間をサポートし、同時のバックフィルリクエストには対応しないと明記されています。この2つは初期移行の日程に直接効きます。

過去2年ぶんを埋めるなら、180日刻みで5回に分割し、前の完了を待って順に流すことになります。直列で走るため、所要時間は「1回ぶんの処理時間×回数」で見積もってください。並列前提で計画すると、移行の山場でスケジュールが崩れます。数年ぶんの初期ロードが要る案件では、初期移行だけを一括ロードで済ませ、DTSには以後の差分だけを担当させる分担も選べます。

更新期間0〜30日の設定と、遅れて届いたデータを取り直すための設計

更新期間は、毎回の実行で直近何日ぶんを取り直すかを決める設定です。refresh_window_days で指定し、取れる値は0から30の範囲と定められています。広告系のように後から数値が確定するソースでは、当日ぶんだけを見ていると最終値と食い違うため、この設定で数日ぶんを毎回上書きします。

ここで起きやすい事故が、追記型の書き込み設定との組み合わせです。更新期間を3日にした状態で追記を選ぶと、同じ日のデータが3回積み上がります。件数が3倍になっても構文エラーにはならないため、下流の集計値がおかしいと気づくまで放置されがちです。更新期間を1日以上にするなら、書き込み設定は置き換え側に固定する。この対応関係を設計時のチェック項目に入れておいてください。

日付のランタイムパラメータで宛先と参照先を分ける再実行の組み立て

宛先テーブル名や転送元のパスには、実行日を埋め込むランタイムパラメータを使えます。run_date や run_time を書式付きで展開し、実行日ごとに別のテーブルやフォルダを指すよう組み立てる書き方です。これを入れておくと、特定日の再実行が「その日の宛先だけを作り直す操作」に閉じます。

分け方は2種類。テーブル名の末尾に日付を付けて物理的に分ける方法と、1つのパーティション分割テーブルの中で日付パーティションを分ける方法です。後段のクエリが期間をまたいで集計するなら、パーティション分割テーブル側を選んでください。テーブルを日付で量産すると、集計のたびにワイルドカードで束ねる書き方が要り、保守が重くなります。

DTSとDataflow・Dataform・自前バッチの役割分担と選定基準

取り込み経路の選定で迷うのは、似た役割のサービスが並んでいるからです。判断の軸を「変換をどこで行うか」に固定すると、線引きが一意に決まります。

変換をどこで行うかで分かれるDTSとDataflowの適用範囲の差

DTSは取り込みだけを担い、転送の途中で任意の変換を挟む仕組みを持ちません。対してCloud DataflowはApache Beamのパイプラインを実行する基盤で、取り込みながらの加工、ストリーミング処理、到着遅延を考慮したウィンドウ処理まで扱えます。

個人情報のマスキングのように、BigQueryへ入れる前に済ませなければならない処理があるなら、その時点でDTS単体では要件を満たしません。Apache Beamの実行基盤としてのCloud Dataflowの仕組みを確認し、運用コストを含めて比較してください。逆に、生データをそのまま置いてから加工してよいなら、Dataflowを持ち出す必要はありません。

取り込み後のSQL変換をDataformへ寄せるときの構成と分担

Dataformは、BigQuery内のSQLワークフローを依存関係つきで管理するサービスです。テーブル間の依存を宣言して順序を解決し、変更をバージョン管理し、データ品質のテストを挟めます。取り込みをDTS、変換をDataformに分けると、それぞれの責任範囲が明確になります。

構成としては、DTSが生データをraw層へ着地させ、Dataformがそこからstaging層、mart層を組み立てる形が扱いやすくなります。線引きはこう覚えてください。BigQueryへ入る前の加工はDataflow、入ったあとの加工はDataform、入れるだけならDTS。この3分割で迷う場面はほぼ無くなります。

自前バッチを書かないと判断する4条件と、書くべき場面の見分け方

次の4条件をすべて満たすなら、取り込み処理を自前で書くのは無駄な投資です。ここは言い切ります。

1. 転送元がDTSの対応ソース一覧にある
2. 必要な鮮度が15分以上、もしくはファイル到着契機で足りる
3. BigQueryへ入れる前の変換が不要で、加工はSQLで後追いできる
4. 再実行の粒度を日付で切れる

この4つが揃った状況で自前実装を選ぶと、認証情報の管理、リトライ、失敗通知、実行履歴の保存、担当者交代後の引き継ぎまで、すべて自分たちの保守対象になります。動くものは作れても、動かし続ける費用は転送構成1つとは比較になりません。

書くべき場面もはっきりしています。対応ソースに無い社内システムから直接引くとき、取り込みの瞬間にマスキングや暗号化が要るとき、そして複数ソースの取得を1つのトランザクションとして扱いたいときです。この3つに当てはまるなら、DTSに寄せようとして構成をねじ曲げるより、素直に実装するほうが安く済みます。

採用可否の判断材料：ロケーション制約・費用の出どころ・見送る場面

採用を決める前に確認する3点を挙げます。どれも後から直すと作り直しになる項目です。

データセットのロケーション指定が転送そのものの可否を左右する場面

DTSはデータセットのロケーション指定を必須としています。そしてデータセットのロケーションは、作成後に変更できません。転送構成を作る前に、宛先データセットをどのロケーションに置くかが確定している必要があります。

詰まりやすいのが外部ストレージからの転送です。Amazon S3のバケットが置かれたリージョンと、宛先データセットのロケーションの対応関係を先に確認してください。既存データセットが米国マルチリージョンにあり、新要件で東京リージョンに置きたいという状況では、転送構成の設定ではなくデータセットの作り直しから始まります。決める順番は、データ所在地の要件、宛先ロケーション、転送構成の作成です。

転送そのものより後段のクエリとストレージに出る費用の見方と抑え方

公式の案内では、転送実行後にBigQueryの標準的なストレージおよびクエリ料金が適用されるとされています。ソースによってはDTS側の課金が別に生じるものがあるため、採用するソースの料金ページで時点を明記して確認してください。ここは改定されうる項目です。

設計で効くのは、転送の頻度より取り込んだ後にどう読まれるかです。日次で洗い替えたテーブルを全期間スキャンする集計が張り付いていれば、費用はクエリ側に出ます。宛先をパーティション分割にして日付で絞る、更新期間を必要な日数だけに絞る。この2点で読み込み量を抑えられます。請求額の内訳と監視の設定はオンデマンドとEditionsの分岐点を含むBigQueryの料金構造で分解しています。

DTSを採用せず別の手段を選ぶべき3つの場面と典型的な失敗の形

見送る判断をすべき場面は3つです。第一に、秒から分の単位で反映したい要件。イベントドリブン転送でも到着契機のぶん短くなるだけで、常時流れ込むデータには向きません。データベースの変更を継続的に取り込むなら、変更データキャプチャに対応した経路を選んでください。第二に、取り込み時点での加工が業務要件になっている場合。第三に、転送元が対応ソースに無い場合。

典型的な失敗の形も挙げておきます。追記型に更新期間を組み合わせて同じ日のデータが多重に入る、宛先データセットのロケーションを決めずに作って作り直しになる、180日制約と同時実行不可を知らずに初期移行の日程を並列前提で引く。この3つは設計の初日に潰せます。

取り込み経路の選定から冪等性の設計、権限とロケーションの決定までを含めて相談先を探しているなら、データ分析基盤構築・MLOps構築支援で受け付けています。既存のバッチをDTSへ寄せられる範囲の切り分けから対応します。

よくある質問

DTSの導入検討でよく挙がる質問を、公式ドキュメントの記載に沿って整理しました。

BigQuery Data Transfer Serviceの利用に追加料金はかかりますか？

公式の案内では、転送が実行された後、BigQueryの標準的なストレージおよびクエリ料金が適用されるとされています。取り込んだデータを保持するストレージ料金と、それを読むクエリ料金は通常どおり発生します。加えて、ソースによってはDTS側の課金が設定されている場合があるため、実際に使うソースの料金ページを確認してください。料金体系は改定されるので、見積もりの時点を明記して社内へ共有してください。

転送を15分より短い間隔で動かせますか？

定期転送のスケジュールとしては設定できません。設定可能な最小間隔は15分で、既定値は24時間ごとです。それより短い頻度が必要な場合は、Cloud Storageへのファイル到着を契機に動くイベントドリブン転送を使います。ただし到着契機は、締め処理を持つ日次集計のような業務には向きません。秒単位に近い反映が要件なら、DTSではなく変更データキャプチャやストリーミング取り込みの経路を検討してください。

転送が失敗したとき、同じデータが二重に入りませんか？

書き込み設定によります。宛先テーブルへ追記する設定なら、同じ期間を再度取り込んだ時点で行が重複します。既存の内容を置き換える設定なら、何度実行しても結果は同じです。再実行を前提にするなら、宛先を日付単位に分けたうえで置き換え側を選んでください。更新期間を1日以上にした構成で追記を選ぶと、指定日数ぶん同じデータが積み上がります。

Amazon S3やAzure Blob Storageからも転送できますか？

どちらも対応ソースに含まれる対象です。Cloud Storageと合わせ、外部クラウドストレージからの取り込みは3種類が用意されています。ただし公式には、Google Cloud外のソースからの転送はSLOの対象外と明記されています。停止が許されない業務の中心に据えるなら、遅延や失敗が起きたときの代替手順を用意しておいてください。宛先データセットのロケーションと、バケットが置かれたリージョンの対応関係も事前確認が要ります。

BigQueryから外部へデータを送る用途にも使えますか？

使えません。DTSはBigQueryへの取り込みを担うサービスで、BigQueryからのデータ転送には対応しないと公式に明記されています。外部へ出す場合は、エクスポート文でCloud Storageへ書き出す、bqコマンドで抽出する、Storage Read APIで読み出すといった別の経路を使ってください。BigQuery同士でデータセットを複製する用途に限っては、データセットコピーが同じサービス内に用意されています。

関連記事

• BigQueryとは：サーバーレスDWHの仕組み・料金・できないことと採用判断：取り込み方式より前に、BigQuery自体を採用するかを判断する記事です。
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順：DTSが担う取り込み層を、基盤全体のどこに位置づけるかを整理しています。
• BigQueryの使い方：コンソールとbqコマンドの初回操作からクエリ実行まで：転送構成を作る前提となる、データセット作成とクエリ実行の手順です。