Cloud Data Fusion

解決する課題

• 複数のデータソースを統合する ETL/ELT を、コードを書かずに GUI で素早く構築したい
• データエンジニア以外（アナリストなど）でも、ドラッグ＆ドロップでパイプラインを組めるようにしたい
• オンプレ DB、SaaS、各種クラウドストレージなど多様なソースへのコネクタをその都度自作したくない
• 取り込んだデータの変換・クレンジング・品質チェックを視覚的に設計し、再利用したい
• パイプラインの系統（リネージ）やメタデータを管理し、データの出所を追跡したい

主要概念と用語

• CDAP: Cloud Data Fusion の基盤となるオープンソースのデータ統合プラットフォーム。Data Fusion はこの CDAP をフルマネージドで提供したもの
• パイプライン (Pipeline): データの取り込みから変換、書き込みまでの一連の流れを表す有向グラフ。バッチ用とリアルタイム用がある
• プラグイン (Plugin): パイプラインを構成する部品。ソース（読み取り元）、トランスフォーム（変換）、シンク（書き込み先）、アナリティクスなどの種類がある
• Wrangler（ラングラー）: データを対話的にプレビューしながら、変換ルール（列の分割・型変換・フィルタなど）を視覚的に組み立てる機能
• Hub: 再利用できるプラグイン、パイプラインのサンプル、ドライバなどを配布・取得するカタログ
• インスタンス (Instance): Data Fusion 環境の単位。Developer / Basic / Enterprise といったエディションがあり、機能や同時実行性が異なる
• 実行環境 (Compute Profile): パイプラインを実際に走らせる計算基盤。既定では一時的な Dataproc クラスタが起動して Spark / MapReduce として実行される

仕様・制限・クォータ

• パイプラインは GUI で設計され、内部的には実行可能なワークフローへ変換される。バッチパイプラインは Spark や MapReduce、リアルタイムは Spark Streaming として実行される
• 実体としての処理は Dataproc 上で動くため、計算リソースは Dataproc クラスタの設定（マシンタイプ、ワーカー数など）に依存する
• インスタンスには複数のエディションがあり、利用できるプラグインや並列実行数、可用性の特性が異なる。本番の高並列用途は上位エディションが前提になる
• プラグインの種類や同時実行パイプライン数には上限があり、プロジェクト/リージョン単位のクォータが設定される。具体的な数値は変動するため公式ドキュメントで確認する
• インスタンスはリージョンに紐づく。マルチリージョンをまたぐ構成は設計時に考慮が必要

内部の仕組み

Cloud Data Fusion は、オープンソースの CDAP をマネージド化したサービスです。利用者が GUI で組んだパイプライン（ソース・トランスフォーム・シンクのグラフ）は、論理的な定義として保存され、実行時に Spark や MapReduce のジョブへ変換されます。

このジョブを実際に走らせるのが Dataproc です。多くの構成ではパイプライン実行のたびに一時的な Dataproc クラスタが起動し、処理が終わると破棄されます。つまり Data Fusion 自体は設計・オーケストレーション層であり、重い計算は Dataproc にオフロードされる二層構造になっています。この分離により、設計者は基盤の詳細を意識せずに視覚的にパイプラインを構築でき、必要なときだけ計算資源が確保されます。

各プラグインは Hub から取得・追加でき、ソースとシンクの組み合わせで多様なデータの流れを表現します。実行結果やメタデータ、データの**リネージ（系統）**はプラットフォーム側で記録され、どのデータがどこから来てどう変換されたかを追跡できます。

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

• GUI で素早く組みたい・非エンジニアも触るケースに向く。逆に細かいコード制御や複雑なロジックが中心なら Dataflow（Apache Beam）の方が適することが多い
• 実行は一時的な Dataproc クラスタで行わせ、処理が終われば破棄してコストを抑える。常時クラスタを立てっぱなしにしない
• 変換ロジックは Wrangler で対話的に作り込み、再利用可能な部品として整理する
• パイプラインをパラメータ化し、開発・本番などの環境差分を引数で吸収して使い回す
• データ品質チェックやエラーレコードの分岐をパイプライン内に組み込み、不正データを別シンクへ退避させる
• 大量・複雑な変換は、実行基盤の Dataproc クラスタを適切にサイジングしてスループットを確保する

運用・監視

• パイプラインの実行状況（成功・失敗、所要時間、処理レコード数）は Data Fusion の実行履歴画面で確認できる
• 実行基盤である Dataproc 側のログ・メトリクスと合わせて見ることで、性能問題の原因（リソース不足、データ偏りなど）を切り分ける
• ログは Cloud Logging、メトリクスは Cloud Monitoring に連携して集約・アラート設定できる
• パイプラインのスケジュール実行やトリガー連携で、定期的なバッチ処理を自動化する
• リネージ機能でデータの出所と変換経路を追跡し、影響範囲調査や監査に活用する

コスト

セキュリティ

• アクセス制御は IAM で行い、パイプラインの設計者・実行者・閲覧者などの役割を最小権限で分離する（AWS の IAM 相当）
• パイプライン実行に使うサービスアカウントに必要な権限のみを付与し、認証情報のハードコードを避ける
• ネットワークは プライベート IP 構成にして、インスタンスや実行基盤を外部公開しないようにできる
• データソースの接続情報などの機密値は Secret として管理し、パイプライン定義に平文で埋め込まない
• 保存データは既定で暗号化され、要件に応じて CMEK（顧客管理鍵, Cloud KMS） を適用できる。境界防御に VPC Service Controls を併用する

Well-Architected の観点

• 運用上の優秀性 (Operational Excellence): GUI による視覚的な設計で属人化を抑え、パイプラインをパラメータ化・再利用して標準化する。リネージとログで運用の可観測性を高める
• 設計層（Data Fusion）と実行層（Dataproc）が分かれているため、役割分担と責任範囲が明確になり、変更やトラブル対応のオペレーションが整理しやすい
• スケジュール実行・トリガーによる自動化で、手作業のバッチ運用を減らせる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) Cloud Data Fusion API を有効化
gcloud services enable datafusion.googleapis.com

# 2) Data Fusion インスタンスを作成（エディションとリージョンを指定）
gcloud data-fusion instances create my-instance \
  --location=asia-northeast1 \
  --edition=basic

# 3) 作成したインスタンスの詳細（GUI への apiEndpoint など）を確認
gcloud data-fusion instances describe my-instance \
  --location=asia-northeast1

# 4) プロジェクト内のインスタンス一覧を表示
gcloud data-fusion instances list --location=asia-northeast1

# 5) 使い終わったインスタンスを削除してコストを抑える
gcloud data-fusion instances delete my-instance \
  --location=asia-northeast1