BigQuery Data Transfer Service

解決する課題

• Google Ads や YouTube などの SaaS データを、定期的に BigQuery へ取り込む処理を自前のスクリプトで回している
• Cloud Storage や Amazon S3 にたまる ファイルを継続的にロードしたいが、cron とスクリプトの運用が煙雑
• 他のデータウェアハウスから BigQuery へ移行・複製したいが、転送パイプラインを一から作りたくない
• ロードジョブのスケジュール管理・失敗時の再実行・通知を、マネージドな仕組みに任せたい

主要概念と用語

• 転送構成 (Transfer Config): 「どのソースから・どの宛先データセットへ・どのスケジュールで」取り込むかを定義する設定単位。これを 1 つ作るとそれ以降は自動で動く
• データソース (Data Source): 転送元のコネクタ。Google Ads、Google アド マネージャー、YouTube、Cloud Storage、Amazon S3、Teradata、Amazon Redshift などが用意されている
• 宛先データセット (Destination Dataset): 転送先となる BigQuery のデータセット。転送構成は宛先データセットと同一またはサポートされたリージョンに置く必要がある
• スケジュール (Schedule): 転送を実行する間隔。日次・週次・時間単位などをカスタムで指定でき、手動の オンデマンド実行もできる
• 転送実行 (Transfer Run): 1 回分の転送ジョブ。実行ごとに成功・失敗のステータスとログが記録される
• バックフィル (Backfill): 過去日付分のデータをまとめて再取得する仕組み。設定変更後や欠損補填に使う
• ランタイムパラメータ: 宛先テーブル名などに run_date のような日付プレースホルダを埋め込み、日付ごとに動的にロード先を切り替える機能

仕様・制限・クォータ

• BigQuery Data Transfer Service は取り込み（EL）に特化したマネージドサービス。変換ロジックを書く場所ではなく、変換は BigQuery 側のクエリや Dataform に委ねる
• 対応ソースは Google の SaaS 群（Google Ads、YouTube、アド マネージャー、Search Ads 360 など）、ファイル系（Cloud Storage、Amazon S3、Azure Blob Storage）、他 DWH（Teradata、Amazon Redshift）などに分かれる
• スケジュールは最短で時間単位程度から指定でき、SaaS ソースはデータの**更新頻度（リフレッシュ枠）**に依存する。具体的な最小間隔やリフレッシュ可能日数は変動するため公式ドキュメントで確認する
• 同時に走る転送数や 1 プロジェクトあたりの転送構成数などにクォータがあり、数値は変動する
• 宛先は BigQuery のみ。BigQuery の外へ書き出す用途には使わない

内部の仕組み

BigQuery Data Transfer Service は、利用者が作成した転送構成をスケジューラが監視し、指定タイミングごとに転送実行を起動するマネージドなオーケストレーション層です。実行されると、各データソース用のコネクタが転送元 API やストレージからデータを取得し、BigQuery のロードジョブとして宛先データセットへ書き込みます。利用者はインフラを意識せず、設定だけで定期ロードが回る構造です。

SaaS ソースの場合、コネクタは対象サービスの API を呼び出して、レポートやログ相当のデータを所定のスキーマで取り込みます。ファイル系ソース（Cloud Storage、Amazon S3 など）の場合は、指定したパスパターンに一致するファイルを検出して BigQuery にロードします。Amazon S3 のようなクラウド外ソースでは、いったん Google 側に取り込んでから BigQuery へ書き込む流れになります。

各転送実行は独立して成功・失敗が判定され、失敗時は自動リトライや手動の再実行ができます。過去分をまとめて取り直したいときはバックフィルを指定し、日付範囲を遡って実行をスケジュールします。宛先テーブル名にランタイムパラメータを使えば、実行日付ごとに別テーブルへ振り分けることも可能です。

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

• SaaS のレポートデータ（Google Ads、YouTube など）を集約したいなら、自前 API 連携を作らず標準コネクタの転送構成で取り込む
• 取り込み（Data Transfer Service）と変換（BigQuery SQL / Dataform）を明確に分離し、生データを保持してから変換結果を別テーブルに作る
• 日次ファイルの取り込みではランタイムパラメータで日付別テーブル/パーティションに振り分け、再実行時の上書きやバックフィルを安全にする
• 失敗を見逃さないよう、**通知（メール / Pub/Sub）**を設定して下流の処理やアラートと連携する
• 大量ファイルの取り込みは、パスパターンとパーティション設計を整えてスキャン量と再処理コストを抑える
• 他 DWH からの移行は、初回のバックフィルで過去分を取り込み、以降は差分転送に切り替える

運用・監視

• 各転送実行の履歴とログで成功・失敗、処理日付、エラー内容を確認し、失敗した実行だけを再実行する
• 失敗や完了の通知をメールまたは Pub/Sub に送り、Cloud Functions などでハンドリングして自動復旧やアラートにつなげる
• ログは Cloud Logging に出力されるため、監査やアラートの基盤として利用できる
• 欠損やスキーマ変更が起きた日付は、バックフィルで範囲を指定して取り直す
• 転送が連鎖して下流のクエリやダッシュボードに影響する場合は、転送完了をトリガーに後続処理を起動する設計にする

コスト

BigQuery Data Transfer Service の料金はソースの種類によって考え方が分かれます。Google の SaaS コネクタ（Google Ads、YouTube など）には転送サービスとしての料金が設定される一方、Cloud Storage からのロードのように BigQuery 標準のロード機能を使うものは、転送自体には追加料金がかからず下流の BigQuery 側で課金される、という整理が基本です。

セキュリティ

• アクセス制御は IAM で行い、転送構成の作成・編集・実行・閲覧の権限を役割ごとに最小権限で分離する（AWS の IAM 相当）
• 転送はサービスアカウントまたは認可されたユーザーの権限で動く。宛先データセットへの書き込み権限を必要な範囲に限定する
• SaaS ソースへの接続は OAuth による認可が前提で、認可情報は転送構成に紐づけて管理する。認証情報を平文でコードに埋め込まない
• Amazon S3 など外部ソースのアクセスキーは安全に管理し、最小権限のキーを使う
• 宛先の BigQuery データは既定で暗号化され、要件に応じ CMEK（顧客管理鍵, Cloud KMS） を適用できる。データ流出対策として VPC Service Controls を併用する

関連サービス・比較

取り込みの選択肢として、汎用的なデータ統合パイプラインを組む Dataflow と比較すると役割の違いが明確になります。Data Transfer Service は定型ソースからの定期ロードに特化し、Dataflow はコードで自由に処理を書くストリーミング/バッチ基盤です。

ハンズオン / CLI例

# 1) BigQuery Data Transfer API を有効化
gcloud services enable bigquerydatatransfer.googleapis.com

# 2) 宛先データセットを用意（未作成の場合）
bq --location=asia-northeast1 mk --dataset my_project:ingest_dataset

# 3) Cloud Storage からの転送構成を作成（日次スケジュール）
#    --params にソース固有の設定（バケットパスや形式）を JSON で渡す
bq mk --transfer_config \
  --project_id=my_project \
  --data_source=google_cloud_storage \
  --target_dataset=ingest_dataset \
  --display_name="gcs-daily-load" \
  --schedule="every 24 hours" \
  --params='{"data_path_template":"gs://my-bucket/data/*.csv","destination_table_name_template":"events","file_format":"CSV"}'

# 4) 既存の転送構成を一覧表示して確認
bq ls --transfer_config --transfer_location=asia-northeast1