Dataform

解決する課題

• BigQuery の変換 SQL が手書きスクリプトに散らばり、依存関係や実行順序を人手で管理している
• データパイプラインの SQL にバージョン管理・コードレビュー・CI/CDを適用したい
• 中間テーブルの鮮度や整合性を検証したいが、品質チェックの仕組みがない
• ELT（抽出・ロード後に BigQuery 内で変換）を、ETL ツールを別途運用せずSQL 中心で回したい

主要概念と用語

• ELT: データを先にロードしてから、データウェアハウス内部で変換する方式。Dataform は BigQuery に取り込み済みのデータを SQL で変換する「T（変換）」を担当する
• リポジトリ / ワークスペース: 変換コードを格納する Git リポジトリと、開発者が編集・実行する作業領域。GitHub / GitLab などの外部リポジトリと接続できる
• SQLX: 標準 SQL を拡張した Dataform 独自のファイル形式。SELECT 文に加え、出力タイプや依存関係などの設定ブロックを記述する
• アクション / テーブル / ビュー / 増分テーブル: SQLX 1 ファイルが 1 アクションになり、table（毎回再生成）、view（ビュー）、incremental（差分のみ追記する増分テーブル）などの出力タイプを選べる
• 依存グラフ (DAG): アクション間の参照関係から自動構築される有向非巡環グラフ。Dataform はこの順序でアクションを実行する
• ref 関数: 他のテーブルを名前で参照する仕組み。文字列でテーブル名を直書きせず ref を使うことで、依存関係が自動登録され実行順序が解決される
• アサーション (assertion): データ品質テスト。一意性・非 NULL・条件違反などを SQL で表現し、違反行が見つかると失敗扱いになる
• コンパイル / 実行: SQLX を BigQuery が解釈できる SQL に変換するコンパイルと、生成された SQL を BigQuery 上で順に走らせる実行の二段階で動く

仕様・制限・クォータ

• Dataform は BigQuery 専用の変換オーケストレーションサービス。変換そのものの計算は BigQuery 側で実行され、Dataform はコンパイルとスケジューリングを担う
• コード形式は SQLX と JavaScript。JavaScript で繰り返し定義やマクロ的な共通化（インクルード）ができる
• 外部 Git プロバイダー（GitHub、GitLab、Azure DevOps、Bitbucket など）と連携でき、Dataform 内蔵の Git ホスティングも利用できる
• 出力タイプは テーブル / ビュー / 増分テーブル / マテリアライズドビュー などに対応。BigQuery のパーティショニングやクラスタリングも設定ブロックから指定できる
• Dataform 自体の利用に追加料金は基本かからず、コストは BigQuery のクエリ・ストレージ側で発生する（コストの節を参照）。具体的な上限値やクォータは変動するため、最新の公式ドキュメントで確認すること
• 2026年4月29日から厳格な代理実行モードが全体で必須。ワークフロー実行には、明示したカスタムサービスアカウントまたは利用者資格情報を使い、既定のサービスエージェントへ暗黙に委ねない

内部の仕組み

横にスクロール

Dataform はまずリポジトリ内のすべての SQLX / JavaScript を読み取り、コンパイル段階で各アクションを実行可能な BigQuery SQL に展開します。このとき ref 関数の参照を解決し、アクション間の依存関係から有向非巡環グラフ（DAG）を構築します。コンパイルはコードを静的に解析するだけなので、BigQuery のクエリ課金は発生しません。

次に実行段階で、DAG の順序に従って各アクションの SQL を BigQuery に投げます。テーブルは CREATE OR REPLACE TABLE、増分テーブルは既存テーブルへの差分マージ（または追記）に展開され、変換結果が宛先データセットに書き込まれます。アサーションは「違反行を返すクエリ」として実行され、結果が空でなければ失敗とみなされます。

実行はワークスペースからの手動トリガーのほか、リリース構成 / ワークフロー構成による定期実行で自動化できます。リリース構成はコンパイル対象の Git 参照を固定し、ワークフロー構成は実行対象、変数、スケジュールを定めます。前回の定期実行が完了していない場合は次の実行が開始されないため、処理時間が実行間隔を超えないか監視します。

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

• 取り込みは別サービス（Data Transfer Service、Dataflow、外部 ELT ツールなど）に任せ、BigQuery 内の変換だけを Dataform に集約する。これが ELT の基本構成
• テーブル参照は必ず ref 関数で行い、テーブル名のハードコードを避けて依存グラフを正確に保つ
• 大規模・追記中心のテーブルは 増分テーブルにして、毎回のフルスキャン再生成を避けコストと処理時間を抑える
• 重要テーブルにはアサーションを付け、一意キーや非 NULL、件数の妥当性を継続的に検証する
• 開発と本番を別データセット / 別環境に分け、ワークスペース（開発）で検証してからリリース構成（本番）に反映する
• 共通ロジックは JavaScript のインクルードにまとめ、SQL の重複を減らす

運用・監視

• ワークフロー実行ログで各アクションの成否・所要時間を確認し、失敗したアクションと原因を特定する
• 定期実行は リリース構成 + ワークフロー構成で設定し、Cloud Scheduler 連携などでスケジュール化する
• 変換の鮮度はアサーションで担保する。たとえば最新パーティションが存在するか、件数が想定範囲かをテストし、違反時に失敗させて気づけるようにする
• 実行は Cloud Logging に記録されるため、監査やアラート連携の基盤として利用できる
• 失敗時はまずコンパイルエラー（参照ミス・構文）か実行エラー（BigQuery 側のクエリ失敗）かを切り分ける

コスト

Dataform はオーケストレーション層であり、変換の実体は BigQuery のクエリとして走ります。したがって主なコストは BigQuery のクエリ（スキャン量またはスロット）とストレージで発生し、Dataform の利用自体には基本的に追加料金がかからない、という整理が重要です。

セキュリティ

• Dataform の実行は、カスタムサービスアカウントまたは利用者資格情報で BigQuery にアクセスする。実行主体に対象データセットへの最小権限を付与し、代理実行権限も必要な主体だけに限定する
• IAM でリポジトリの編集権限と実行権限を分離し、開発者・運用者の役割に応じて付与する
• 外部 Git プロバイダー接続の認証トークンは Secret Manager に保管し、コードや設定への直書きを避ける
• 変換先データセットは Google 管理鍵で既定暗号化され、要件に応じ CMEK（顧客管理鍵, Cloud KMS） を BigQuery 側に適用できる
• データ流出対策として VPC Service Controls を BigQuery と組み合わせ、境界外への持ち出しを制限する

Well-Architected の観点

• 運用上の優秀性 (operational): SQL 変換を Git でバージョン管理し、コードレビューと CI/CD、依存解決、データ品質テストを標準化できる。手書きスクリプトの属人化を排し、変更を安全に反映できる点が最大の価値
• コスト最適化: 変換ロジックを増分化・ビュー化することで、下流の BigQuery コストを直接コントロールできる
• 信頼性: アサーションで不正データの混入を早期に検知し、依存グラフにより実行順序の取り違えを防ぐ

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) Dataform リポジトリを作成
gcloud dataform repositories create my-repo \
  --region=asia-northeast1

# 2) リポジトリ一覧で確認
gcloud dataform repositories list \
  --region=asia-northeast1

# 3) 開発用ワークスペースを作成（ここで SQLX を編集する）
gcloud dataform workspaces create dev \
  --repository=my-repo \
  --region=asia-northeast1

# 4) ワークスペース一覧を確認
gcloud dataform workspaces list \
  --repository=my-repo \
  --region=asia-northeast1