総合演習：エンドツーエンドのデータパイプラインを設計しよう

アーキテクチャ図:

[データソース]
  PostgreSQL ─→ [CDC: Debezium] ─→ [Kafka] ─┬→ [Flink] → リアルタイム分析
  Webログ ───→ [Fluentd] ────→ [Kafka] ──┤
  外部API ───→ [Airflow Extract] ──→ [S3 Raw] │
                                              │
                                     ↓        │
                               [S3 Data Lake]  │
                                     ↓        ↓
                               [Snowflake / BigQuery]
                                     ↓
                               [dbt Transform]
                                     ↓
                          ┌── staging ── intermediate ── mart ──┐
                          │                                      │
                          ↓                                      ↓
                    [Looker/Metabase]                      [Feast Feature Store]
                    ダッシュボード                          ML特徴量パイプライン

技術選定:

Airflow DAG設計:

DAG: netshop_daily_pipeline (毎日02:00)
├── TaskGroup: extract
│   ├── extract_orders (PostgreSQL → S3)
│   ├── extract_customers (PostgreSQL → S3)
│   ├── extract_products (PostgreSQL → S3)
│   └── extract_weather_api (API → S3)
├── TaskGroup: load
│   ├── load_to_snowflake (S3 → Snowflake raw)
│   └── data_freshness_check
├── TaskGroup: transform
│   ├── dbt_run_staging
│   ├── dbt_run_intermediate
│   └── dbt_run_mart
├── TaskGroup: quality
│   ├── dbt_test
│   ├── great_expectations_validate
│   └── anomaly_detection
└── notify (Success/Failure → Slack)

エラーハンドリング:
  - extract: retries=3, exponential_backoff, fallback to cache
  - load: retries=2, idempotent MERGE
  - transform: retries=1, 品質ゲートで停止判断
  - SLA: 全体4時間以内

dbtモデル構成:

ストリーミングトピック設計:

モニタリング設計:

インシデント対応フロー:

1. アラート検知（Slack #data-alerts）
2. 初動対応（15分以内）
   - 影響範囲の特定（リネージ確認）
   - 暫定対応（リトライ or ロールバック）
3. 原因調査（1時間以内）
   - ログ確認、品質レポート確認
4. 恒久対応
   - 修正・テスト追加・ドキュメント更新
5. 振り返り
   - ポストモーテム実施、再発防止策

導入スケジュール: