『データパイプライン』はデータエンジニアの中核業務
各システムからデータを集約し、分析・ML に使える形に整える DataPipeline は現代のデータ基盤の心臓部です。本記事では編集部の視点で、構築の実務を公開情報をもとに整理します。dbt 実践 もご参考に。
ELT vs ETL
(1) ETL：抽出→変換→ロード(伝統的)。(2) ELT：抽出→ロード→変換(現代的)。(3) クラウド DWHの登場で ELT 優勢。(4) 変換は SQL/dbtで。(5) 判断軸：データ量・コスト・要件。
主要なワークフローエンジン
(1) Apache Airflow：OSS・実績豊富。(2) Dagster：データアセット中心の設計。(3) Prefect：Python ネイティブ。(4) Mage：UI 重視。(5) Argo Workflows：k8s ベース。判断軸は規模・開発体験・運用負荷。
パイプラインの設計原則
(1) 冪等性：再実行で同じ結果。(2) 分割実行：日付/IDで分散。(3) 失敗時の再開：チェックポイント。(4) 監視：実行時間・成功率。(5) テスト：データ品質チェック。冪等性設計 もご参考に。
データ品質の確保
(1) スキーマ検証：型・必須項目。(2) ビジネスルール：金額範囲等。(3) 異常検知：行数の急変。(4) Great Expectations / dbt tests。(5) SLA：データ更新時刻保証。
運用のベストプラクティス
(1) DAG の小さく：失敗影響範囲限定。(2) 依存性管理：DAG 間の関係明示。(3) 監視ダッシュ。(4) コスト最適化：DWH スロット管理。(5) ドキュメント：data catalog。Snowflake/BigQuery 比較 もご参考に。
失敗しがちなパターン
(1) 巨大 DAG 一つ：失敗時の影響大。(2) SQL 直書き：再利用不能。(3) テスト不在：データ汚染。(4) 監視なし：障害気付かず。(5) ドキュメント不在：データ意味不明。対策は、(1)分割、(2)dbt、(3)Great Expectations、(4)Datadog/Slack 通知、(5)data catalog、です。