変更要約: Professional Data Engineer 第2章を新規作成（ドメイン2「取り込みと処理」: パイプライン計画と構築＝ソース/シンク・変換・バッチ/ストリーミング/ウィンドウ/遅延データ・Dataflow/Beam/Dataproc/Spark/Hadoop/Cloud Data Fusion/BigQuery/Pub/Sub/Kafka、デプロイと運用化＝Cloud Composer(DAG)/Workflows・クレンジング/AI エンリッチメント・CI/CD）。
2.2パイプラインのデプロイと運用化
ジョブの自動化とオーケストレーション（Cloud Composer・Workflows）、データクレンジングとAIによるデータエンリッチメント、新しいデータソースとの統合、そして CI/CD によるパイプラインの継続的デリバリーを理解します。
設計したパイプラインを、自動で・繰り返し・安全に動かすのが運用化です。オーケストレーションと CI/CD でデータ基盤を運用に乗せます。
2.2.1自動化とオーケストレーション
複数ステップのジョブは、依存関係を DAG で表現する Cloud Composer（マネージド Airflow）でオーケストレーションします。サービス間の軽量な連携は Workflows を使います。クレンジングで品質を整え、必要に応じて AI によるデータエンリッチメント（分類・抽出・要約など）で価値を付加します。新しいデータソースは、スキーマやフォーマットを取り込みロジックに統合します。「依存のある複数ステップ＝Cloud Composer（DAG）」「軽量な連携＝Workflows」と結びます。
2.2.2CI/CD による継続的デリバリー
パイプラインのコード（変換ロジック・DAG・IaC）は CI/CD（Cloud Build など）で検証・デプロイします。これにより、変更がレビュー・テストされ、環境（開発→本番）へ一貫して反映されます。手作業のデプロイはドリフトやミスを生むため避けます。「パイプラインの変更を安全に反映＝CI/CD」を押さえます。
「要件 → 手段」が頻出。例：「依存のあるジョブを DAG でスケジュール」＝Cloud Composer、「サービス間の軽量連携」＝Workflows、「変換やデータをコードとして安全にデプロイ」＝CI/CD（Cloud Build）、「データに分類/抽出を付加」＝AI データエンリッチメント。
混同に注意：
①Cloud Composer（依存のある重いオーケストレーション）と Workflows（軽量連携）を取り違えない。
②手作業デプロイはドリフトの原因＝CI/CD で一貫させる。
③単純な定期実行は BigQuery のスケジュールクエリでも足りる。
2.2.3この節のまとめ
- 依存のある複数ステップは Cloud Composer（DAG）、軽量連携は Workflows
- クレンジングと AI データエンリッチメントで品質・価値を付加
- パイプライン変更は CI/CD（Cloud Build）で検証・一貫デプロイ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 依存のある複数ステップのデータパイプラインを DAG でスケジュール・オーケストレーションしたい。最適なのはどれですか？
Q2. サービス間の軽量なステップ連携（シンプルなワークフロー）を行いたい。最適なのはどれですか？
Q3. パイプラインの変換ロジックや DAG をレビュー・テストして一貫してデプロイしたい。最適な方法はどれですか？
Q4. Cloud Composer と Workflows の使い分けとして正しいものはどれですか？
Q5. 手作業でのパイプラインデプロイの主な問題はどれですか？
Q6. データに分類・抽出・要約などの価値を付加したい。最も適切な考え方はどれですか？