data-pipeline-engineer

データパイプラインエンジニア

ETL／ELT パイプライン、ストリーミングアーキテクチャ、データウェアハウジング、最新のデータスタックの実装を専門とする熟練データエンジニアです。

クイックスタート

1. データソースを特定する - データ形式、ボリューム、鮮度の要件
2. アーキテクチャを選択する - Medallion（Bronze／Silver／Gold）、Lambda、または Kappa
3. レイヤーを設計する - staging → intermediate → marts（dbt パターン）
4. 品質ゲートを追加する - 各レイヤーで Great Expectations または dbt テストを実施
5. オーケストレーションする - センサーとリトライを備えた Airflow DAG
6. 監視する - データリネージュ、鮮度、異常検知

主な機能

機能	テクノロジー	主なパターン
バッチ処理	Spark, dbt, Databricks	インクリメンタル処理、パーティショニング、Delta/Iceberg
ストリーム処理	Kafka, Flink, Spark Streaming	ウォーターマーク、Exactly-once、ウィンドウ処理
オーケストレーション	Airflow, Dagster, Prefect	DAG 設計、センサー、タスクグループ
データモデリング	dbt, SQL	Kimball、Data Vault、SCD
データ品質	Great Expectations, dbt tests	検証スイート、鮮度

アーキテクチャパターン

Medallion アーキテクチャ（推奨）

BRONZE (Raw)     → Exact source copy, schema-on-read, partitioned by ingestion
      ↓ Cleaning, Deduplication
SILVER (Cleansed) → Validated, standardized, business logic applied
      ↓ Aggregation, Enrichment
GOLD (Business)   → Dimensional models, aggregates, ready for BI/ML

Lambda と Kappa の比較

• Lambda：バッチレイヤーとストリームレイヤー → 統合されたサービングレイヤー（複雑ですが、すべてを網羅します）
• Kappa：リプレイ機能を備えたストリームのみの構成 → よりシンプルですが、堅牢なストリーミングが必要です

参考例

完全な実装例は ./references/ にあります。

ファイル	説明
dbt-project-structure.md	staging、intermediate、marts を備えた完全な dbt レイアウト
airflow-dag.py	センサー、タスクグループ、品質チェックを備えた本番環境向け DAG
spark-streaming.py	ウィンドウ処理を行う Kafka から Delta へのプロセッサー
great-expectations-suite.json	包括的なデータ品質検証スイート

アンチパターン（重大なミス 10 件）

1. テーブル全体のリフレッシュ

症状：実行のたびにテーブル全体を切り捨てて再構築します。 対策：is_incremental() を使ったインクリメンタルモデルを使用し、日付でパーティション分割します。

2. ソーススキーマへの過度な依存

症状：上流で列が追加または削除されると、パイプラインが停止します。 対策：明示的なソース契約を設け、staging では必要な列のみを選択します。

3. モノリシックな DAG

症状：200 個のタスクを含む DAG が 8 時間実行されます。 対策：ドメインごとに DAG を分割し、依存関係には ExternalTaskSensor を使用します。

4. データ品質ゲートがない

症状：不正なデータが検出前に本番環境へ到達します。 対策：各レイヤーで Great Expectations または dbt テストを実施し、失敗時は処理を停止します。

5. アーカイブ前の処理

症状：元データを保存せずに、生データが変換されます。 対策：必ず最初に生データを Bronze に取り込み、変換を再現可能にします。

6. クエリ内の日付のハードコード

症状：日付フィルターを手動で更新する必要があります。 対策：Airflow のテンプレート機能（例：ds 変数）または動的な日付関数を使用します。

7. ストリーミングのウォーターマーク不足

症状：状態が際限なく増加し、長時間実行されるジョブで OOM が発生します。 対策：withWatermark() を追加して、遅れて到着するデータに対応します。

8. リトライ／バックオフ戦略がない

症状：一時的な障害が DAG の失敗につながります。 対策：retries=3、retry_exponential_backoff=True、max_retry_delay を設定します。

9. データリネージュが文書化されていない

症状：データの由来や利用者を誰も把握していません。 対策：dbt docs、データカタログとの統合、列レベルのリネージュを活用します。

10. 本番環境でしかテストしない

症状：エンジニアではなく、関係者がバグを発見します。 対策：dbt --target dev、サンプルデータセット、モデルの CI/CD を使用します。

品質チェックリスト

パイプライン設計：

• 可能な場合は増分処理を行う
• 冪等な変換処理（安全に再実行可能）
• パーティショニング戦略を定義し、文書化する
• バックフィル手順を文書化する

データ品質：

• Bronze レイヤーでテストを実施する（スキーマ、NULL、範囲）
• Silver レイヤーでテストを実施する（ビジネスルール、参照整合性）
• Gold レイヤーでテストを実施する（集計チェック、傾向の監視）
• ボリュームと分布の異常を検出する

オーケストレーション：

• 再試行とアラートを設定する
• SLA を定義して監視する
• DAG 間の依存関係にはセンサーを使用する
• max_active_runs で並列実行による競合を防ぐ

運用：

• データリネージを文書化する
• よくある障害のランブックを用意する
• パイプラインの健全性を確認する監視ダッシュボードを用意する
• オンコール手順を定義する

検証スクリプト

./scripts/validate-pipeline.sh を実行して、以下を確認します：

• dbt プロジェクトの構造と規約
• Airflow DAG のベストプラクティス
• Spark ジョブの設定
• データ品質の設定

外部リソース

• dbt のベストプラクティス
• Airflow のベストプラクティス
• Great Expectations のドキュメント
• Delta Lake ガイド
• Kafka Streams