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 のクエリ・ストレージ側で発生する（コストの節を参照）。具体的な上限値やクォータは変動するため、最新の公式ドキュメントで確認すること

内部の仕組み

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

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

実行はワークスペースからの手動トリガーのほか、リリース構成 / ワークフロー構成による定期実行で自動化できます。各実行はログとして記録され、どのアクションが成功・失敗したかを後から追跡できます。

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

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

運用・監視

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

コスト

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

セキュリティ

• Dataform の実行はサービスアカウントを介して BigQuery にアクセスする。このサービスアカウントに対象データセットへの最小権限を付与する（AWS の IAM ロール相当の考え方）
• 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