変更要約: Associate Data Practitioner 第3章を新規作成（ドメイン3「パイプライン」: パイプラインの設計＝Dataproc/Dataflow/Cloud Data Fusion/Cloud Composer/Dataform/ELT・ETL、スケジュール・自動化・監視＝スケジュールクエリ/Cloud Scheduler/Workflows/Dataproc Workflow Templates/Pub/Sub→BigQuery/Eventarc/Dataflow ジョブ UI/Cloud Logging・Monitoring）。
3.1データパイプラインの設計
ビジネス要件に応じたデータ変換ツール（Dataproc・Dataflow・Cloud Data Fusion・Cloud Composer・Dataform）の選択、ELT と ETL のユースケースの評価、そして基本的な変換パイプラインを実装するために必要なプロダクトの組み合わせを理解します。
データを定期的・自動的に流して変換する仕組みが データパイプライン です。要件（既存資産・スキル・規模・リアルタイム性）に応じて、適したツールを選びます。
3.1.1変換ツールの選択
| ツール | 向いている用途 |
|---|---|
| Dataflow | バッチ/ストリーミングのスケーラブルな処理（Apache Beam） |
| Dataproc | 既存の Spark/Hadoop ジョブ |
| Cloud Data Fusion | ビジュアルに ETL/ELT を構築（コード少なめ） |
| Dataform | BigQuery 内の SQL ベースの変換（ELT） |
| Cloud Composer | 複数ステップのオーケストレーション（Airflow） |
Dataflow は Apache Beam ベースでバッチ/ストリーミングをスケーラブルに処理します。既存の Spark/Hadoop 資産があれば Dataproc、ビジュアルに低コードで組むなら Cloud Data Fusion、BigQuery 内で SQL ベースの変換（ELT） を管理するなら Dataform が向きます。複数ステップの依存関係をオーケストレーションするのが Cloud Composer（Airflow ベース）です。「Spark/Hadoop＝Dataproc」「SQL の ELT 管理＝Dataform」「ワークフローの統制＝Cloud Composer」と結びます。
「要件 → ツール」が頻出。例：「スケーラブルなバッチ/ストリーミング」＝Dataflow、「既存 Spark/Hadoop を移す」＝Dataproc、「ビジュアルに低コードで ETL」＝Cloud Data Fusion、「BigQuery 内の SQL 変換（ELT）を管理」＝Dataform、「複数ステップの依存をオーケストレーション」＝Cloud Composer。
混同に注意：
①Dataflow（Beam・スケーラブル処理）とDataproc（Spark/Hadoop）の違い。
②Cloud Composer（Airflow・オーケストレーション）は変換そのものよりワークフロー統制。
③Dataform は BigQuery の SQL ELT 管理。
3.1.2この節のまとめ
- Dataflow（Beam・バッチ/ストリーミング）/Dataproc（Spark/Hadoop）/Cloud Data Fusion（ビジュアル）/Dataform（SQL ELT）
- Cloud Composer（Airflow）で複数ステップをオーケストレーション
- 要件（既存資産・スキル・規模）でツールを選ぶ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 既存の Spark / Hadoop のジョブをそのまま Google Cloud で動かしたい。最適なのはどれですか？
Q2. スケーラブルにバッチとストリーミングのデータ変換を行いたい（Apache Beam ベース）。最適なのはどれですか？
Q3. BigQuery 内の SQL ベースの変換（ELT）をバージョン管理しながら実装したい。最適なのはどれですか？
Q4. 複数ステップの依存関係を持つデータワークフローをオーケストレーションしたい。最適なのはどれですか？
Q5. コードをあまり書かず、ビジュアルに ETL/ELT パイプラインを構築したい。最適なのはどれですか？
Q6. Cloud Composer の主な役割として最も適切なものはどれですか？