BigQuery Migration Service

解決する課題

Teradata・Amazon Redshift・Snowflake・Oracle といった既存データウェアハウス（DWH）から BigQuery へ乗り換えたい場面で使います。DWH 移行は単なるデータコピーでは終わらず、独自方言の SQL、大量のテーブル、依存するレポートやパイプラインの書き換えが伴い、手作業では工数と見積もりの不確実性が大きくなります。

• 既存DWHのSQL方言を BigQuery の GoogleSQL に書き換える作業が膨大 → 自動変換で工数を圧縮したい
• 移行対象の規模・コスト・互換性が読めず計画が立たない → 事前アセスメントで可視化したい
• 大量テーブルのデータ移行を手作業で管理したくない → マネージドな転送に任せたい
• 移行は一度で終わらず、**段階的に並走（並行運用）**しながら切り替えたい

主要概念と用語

• 移行アセスメント（Migration assessment）: 既存DWHのメタデータやクエリログを読み取り、移行対象の規模・複雑さ・推定コスト・互換性をレポート化する事前評価。結果は BigQuery 上のテーブルとダッシュボードで確認できる
• バッチSQLトランスレーター（Batch SQL translator）: 大量のSQLファイルをまとめて GoogleSQL へ一括変換する仕組み。Cloud Storage 上の入力を読み、変換結果と差分・警告を出力する
• インタラクティブSQLトランスレーター（Interactive SQL translator）: クエリ単位でその場で変換結果を確認できる対話型の変換。少量の検証や手直しに向く
• 対応ソース方言（Source dialect）: Teradata、Amazon Redshift、Snowflake、Oracle、Apache Hive、Presto/Trino、SQL Server など、変換元として扱える既存DWH／クエリエンジンの方言
• データ移行（Data migration）: 既存DWHの実データを BigQuery へ転送する工程。テーブルのスキーマとデータを移し替える
• GoogleSQL: BigQuery の標準SQL方言。変換のゴールとなるターゲット言語
• メタデータ／クエリログ: アセスメントと変換の精度を高めるための入力。テーブル定義や実際に流れたクエリ履歴を抽出して与える

仕様・制限・クォータ

• 変換元として扱える方言は複数のDWH／クエリエンジンに対応するが、対応方言の一覧やカバー範囲は更新されるため、移行前に公式ドキュメントで確認する
• すべてのSQLが自動変換されるわけではない。独自関数・ストアドプロシージャ・固有構文など、変換できない部分は警告として出力され、手動対応が必要になる
• バッチ変換の入力は Cloud Storage に置き、出力も Cloud Storage へ書き出す構成が基本
• アセスメントの精度は、与えるメタデータとクエリログの網羅性に依存する。ログが少ないと推定の確度も下がる
• 同時実行できる変換ジョブ数などにはプロジェクト単位のクォータがあり、必要に応じて引き上げを申請する
• データ移行そのものは、対象によって BigQuery Data Transfer Service など別機能と組み合わせて行う場合がある

内部の仕組み

• アセスメント: 既存DWHから抽出したメタデータとクエリログを取り込み、移行対象の規模・複雑さ・互換性・推定コストを集計して、BigQuery 上のレポートとして可視化します。これにより移行の優先順位とリスクを把握できます
• SQL変換: 入力SQLを解析し、ソース方言の構文・関数を GoogleSQL の等価表現へマッピングして出力します。バッチは大量ファイルを一括処理、インタラクティブはクエリ単位で即時に変換します
• 変換の補助情報: メタデータ（テーブル定義など）を併せて与えると、型やオブジェクト参照の解決精度が上がり、より正確な変換になります
• データ移行との連携: スキーマとデータの転送は、変換とは別工程として実施し、必要に応じて転送機能と組み合わせます。SQL変換・データ移行・並行運用を段階的に進める設計です

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

• まずアセスメントを実施して移行規模・複雑なクエリ・推定コストを把握し、移行ウェーブ（段階）を計画する
• 大量SQLはバッチ変換でまとめて処理し、警告が出た少数の難所だけインタラクティブ変換や手作業で仕上げる
• 変換後のクエリは**実データで結果突合（既存DWHと BigQuery の出力比較）**を行い、論理的な等価性を検証する
• 移行は一括ではなく、重要度の低いワークロードから段階移行し、並行運用で安全に切り替える
• 入力には実際のクエリログを与え、使われていないクエリや低頻度クエリを後回しにして優先度を最適化する
• 移行後は BigQuery のパーティション分割・クラスタリングを設計し、旧DWHの物理設計をそのまま持ち込まない

運用・監視

• 変換ジョブとアセスメントのステータス・警告件数・失敗を確認し、警告の多いクエリ群を優先的に手直しする
• Cloud Logging で変換・転送ジョブのログを追い、失敗時は入力SQLや権限・Cloud Storage アクセスを点検する
• アセスメントレポートをダッシュボードで定期確認し、移行ウェーブの進捗（変換済み・検証済みの割合）を追跡する
• データ移行後は、行数・集計値の突合チェックをジョブ化し、移行の正確性を継続的に確認する

コスト

BigQuery Migration Service の評価・SQL変換といった移行支援機能は、追加費用なしで提供される範囲があります。一方で、移行に伴って次のコストが発生する点に注意します。

• 移行先 BigQuery の費用（ストレージ、クエリ実行のオンデマンドまたは容量課金）は通常どおり課金される
• 変換入力・出力を置く Cloud Storage の保管・操作料が発生する
• データ移行に伴う**ネットワーク（エグレス等）**の通信料が、移行データ量に応じて発生し得る
• 検証のために流す結果突合クエリの実行コストも見込んでおく

正確な料金は変動するため、移行データ量とクエリ量をもとに公式の料金ページで見積もるのが確実です。アセスメントの推定コストは、移行後の BigQuery 運用費を概算する手がかりになります。

セキュリティ

• 変換入力・出力に使う Cloud Storage バケットは適切な IAM で限定し、誰でも読めない構成にする
• 既存DWHから抽出するメタデータやクエリログに機微情報が含まれ得るため、抽出物の保管場所とアクセス権を管理する
• 移行作業者には BigQuery と Cloud Storage の必要最小権限だけを付与し、移行完了後は権限を整理する
• 移行先 BigQuery は保存時暗号化がデフォルトで有効で、必要に応じて CMEK（Cloud KMS） も利用できる
• 変換結果のSQLをレビューする際、ハードコードされた接続情報や資格情報が紛れ込まないか点検する

関連サービス・比較

BigQuery への移行では、SQL変換・アセスメントを担う BigQuery Migration Service と、定期的・継続的なデータ取り込みを担う BigQuery Data Transfer Service を役割で使い分けます。

ハンズオン / CLI例

# 移行ワークフロー（バッチSQL変換タスク）を作成する例。
# 入力SQLと出力先の Cloud Storage パス、変換元の方言を指定する。
bq mk --transfer_config \
  --project_id=my-project \
  --data_source=dwh_migration \
  --display_name="teradata-sql-translation" \
  --params='{
    "source_dialect": "teradata",
    "target_dialect": "bigquery",
    "input_path": "gs://my-bucket/migration/input/",
    "output_path": "gs://my-bucket/migration/output/"
  }'

# 作成済みの移行／転送設定を一覧で確認する
bq ls --transfer_config --transfer_location=us --project_id=my-project

# 入力SQLを Cloud Storage にアップロードしておく（変換前の準備）
gsutil cp ./legacy_queries/*.sql gs://my-bucket/migration/input/

# 変換結果（出力）を手元に取得してレビューする
gsutil cp -r gs://my-bucket/migration/output/ ./translated_queries/