変更要約: 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.1パイプラインの計画と構築
データソースとシンクの定義、変換とオーケストレーションのロジック、バッチとストリーミング（ウィンドウ・遅延データ）の処理、そして適切な処理サービス（Dataflow・Apache Beam・Dataproc・Cloud Data Fusion・BigQuery・Pub/Sub・Spark・Kafka）の選択を理解します。
データ基盤の中核は、データを取り込み・処理するパイプラインです。ソースとシンク、バッチかストリーミングか、そして使うサービスを要件で設計します。
2.1.1ソース・シンクとバッチ/ストリーミング
パイプラインは データソース（取り込み元）と シンク（書き込み先）を定義し、その間の 変換 ロジックを設計します。処理は二系統あります：たまったデータをまとめて処理する バッチと、到着し続けるデータを逐次処理する ストリーミング。ストリーミングでは ウィンドウ（時間で区切る）や 遅延データ（late arriving）の扱いが要です。リアルタイム取り込みには Pub/Sub（メッセージング）を使います。「逐次・リアルタイム＝ストリーミング＋Pub/Sub」「時間で集計＝ウィンドウ」と結びます。
2.1.2処理サービスの選択
処理サービスは特性で選びます：統一モデルでバッチ/ストリーミングをスケーラブルに処理する Dataflow（Apache Beam）、既存の Spark/Hadoop 資産を動かす Dataproc、ビジュアルに低コードで組む Cloud Data Fusion、SQL で大規模変換する BigQuery。メッセージングは Pub/Sub、既存の Kafka 資産も活用できます。「Beam の統一モデルでバッチ/ストリーム＝Dataflow」「既存 Spark/Hadoop＝Dataproc」「SQL 変換＝BigQuery」と結びます。
「要件 → サービス」が頻出。例：「バッチもストリームも統一モデルでスケーラブル」＝Dataflow（Beam）、「既存の Spark/Hadoop を動かす」＝Dataproc、「ビジュアルに低コード」＝Cloud Data Fusion、「SQL で大規模変換」＝BigQuery、「リアルタイム取り込み」＝Pub/Sub、「時間で区切る集計」＝ウィンドウ、「遅延到着データ」＝ウォーターマーク/許容遅延の設計。
混同に注意：
①Dataflow（Beam・統一）と Dataproc（既存 Spark/Hadoop）を取り違えない。
②ストリーミングはウィンドウと遅延データの設計が要。
③Pub/Sub は通常 at-least-once＝重複に冪等で対応。
2.1.3この節のまとめ
- ソース/シンクと変換を定義、バッチ vs ストリーミング（ウィンドウ/遅延データ）を要件で選ぶ
- 処理＝Dataflow(Beam)/Dataproc(Spark・Hadoop)/Cloud Data Fusion(ビジュアル)/BigQuery(SQL)
- リアルタイム取り込みは Pub/Sub（at-least-once は冪等で対応）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. バッチもストリーミングも統一モデルでスケーラブルに処理したい。最適なのはどれですか？
Q2. 既存の Spark / Hadoop ワークロードをマネージドで動かしたい。最適なのはどれですか？
Q3. リアルタイムにイベントを取り込み複数サービスへ配信したい。最適なのはどれですか？
Q4. ストリーミング処理で一定時間ごとに集計したい。使う概念はどれですか？
Q5. ストリーミングで遅れて到着するデータに正しく対処したい。設計すべきものはどれですか？
Q6. Dataflow と Dataproc の使い分けとして正しいものはどれですか？