data-engineer

データエンジニア

目的

スケーラブルなデータパイプライン、ETL／ELT ワークフロー、データレイク、データウェアハウスを構築するための、データエンジニアリングに関する専門的な機能を提供します。分散データ処理、ストリーム処理、データ品質、最新のデータスタック技術（Airflow、dbt、Spark、Kafka）を専門とし、信頼性とコストの最適化を重視します。

使用する場面

• ソースから利用レイヤーまでのエンドツーエンドのデータパイプラインを設計する
• エラー処理とデータ品質チェックを備えた ETL／ELT ワークフローを実装する
• 最適なストレージとクエリを備えたデータレイクやデータウェアハウスを構築する
• リアルタイムのストリーム処理（Kafka、Flink、Kinesis）を設定する
• データインフラのコストを最適化する（ストレージ階層化、コンピューティング効率）
• データガバナンスとコンプライアンス（GDPR、データリネージ）を実装する
• レガシーデータシステムを最新のデータプラットフォームに移行する

クイックスタート

次の場合にこのスキルを呼び出してください：

• ソースから利用レイヤーまでのエンドツーエンドのデータパイプラインを設計する
• エラー処理とデータ品質チェックを備えた ETL／ELT ワークフローを実装する
• 最適なストレージとクエリを備えたデータレイクやデータウェアハウスを構築する
• リアルタイムのストリーム処理（Kafka、Flink、Kinesis）を設定する
• データインフラのコストを最適化する（ストレージ階層化、コンピューティング効率）
• データガバナンスとコンプライアンス（GDPR、データリネージ）を実装する

次の場合は呼び出さないでください：

• SQL クエリの最適化だけが必要な場合（代わりに database-optimizer を使用）
• 機械学習モデルを開発する場合（ml-engineer または data-scientist を使用）
• 簡単なデータ分析や可視化を行う場合（data-analyst を使用）
• データベース管理タスクを行う場合（database-administrator を使用）
• データ変換を伴わない API 統合を行う場合（backend-developer を使用）

判断フレームワーク

パイプラインアーキテクチャの選定

├─ Batch Processing?
│   ├─ Daily/hourly schedules → Airflow + dbt
│   │   Pros: Mature ecosystem, SQL-based transforms
│   │   Cost: Low-medium
│   │
│   ├─ Large-scale (TB+) → Spark (EMR/Databricks)
│   │   Pros: Distributed processing, handles scale
│   │   Cost: Medium-high (compute-intensive)
│   │
│   └─ Simple transforms → dbt Cloud or Fivetran
│       Pros: Managed, low maintenance
│       Cost: Medium (SaaS pricing)
│
├─ Stream Processing?
│   ├─ Event streaming → Kafka + Flink
│   │   Pros: Low latency, exactly-once semantics
│   │   Cost: High (always-on infrastructure)
│   │
│   ├─ AWS native → Kinesis + Lambda
│   │   Pros: Serverless, auto-scaling
│   │   Cost: Variable (pay per use)
│   │
│   └─ Simple CDC → Debezium + Kafka Connect
│       Pros: Database change capture
│       Cost: Medium
│
└─ Hybrid (Batch + Stream)?
    └─ Lambda Architecture or Kappa Architecture
        Lambda: Separate batch/speed layers
        Kappa: Single stream-first approach

データストレージの選定

ユースケース	テクノロジー	メリット	デメリット
構造化分析	Snowflake/BigQuery	SQL、高速なクエリ	大規模化に伴うコスト
半構造化データ	Delta Lake/Iceberg	ACID、スキーマの進化	複雑さ
生データのストレージ	S3/GCS	低コスト、高耐久性	クエリエンジンがない
リアルタイム	Redis/DynamoDB	低レイテンシー	分析機能が限定的
時系列データ	TimescaleDB/InfluxDB	時系列データに最適化	用途が限定的

ETL と ELT の判断

要素	ETL（先に変換）	ELT（先にロード）
データ量	小規模〜中規模	大規模（TB 以上）
変換	複雑、ロード前	SQL ベース、ウェアハウス内
レイテンシー	高い	低い
コスト	ロード前にコンピューティング	ウェアハウスのコンピューティング
最適な用途	レガシーシステム	最新のクラウド DW

コアパターン

パターン 1：冪等なパーティション上書き

ユースケース： 重複を作成せずにバッチジョブを安全に再実行します。

# PySpark example: Overwrite partition based on execution date
def write_daily_partition(df, target_table, execution_date):
    (df
     .write
     .mode("overwrite")
     .partitionBy("process_date")
     .option("partitionOverwriteMode", "dynamic")
     .format("parquet")
     .saveAsTable(target_table))

パターン 2：緩やかに変化するディメンション タイプ 2（SCD2）

ユースケース： 過去の状態を失わずに変更履歴を追跡します。

-- dbt implementation of SCD2
{{ config(materialized='incremental', unique_key='user_id') }}

SELECT 
    user_id, address, email, status, updated_at,
    LEAD(updated_at, 1, '9999-12-31') OVER (
        PARTITION BY user_id ORDER BY updated_at
    ) as valid_to
FROM {{ source('raw', 'users') }}

パターン 3：ストリーミング向けデッドレターキュー（DLQ）

ユースケース： パイプラインを停止させずに、不正な形式のメッセージを処理します。

パターン 4：データ品質サーキットブレーカー

ユースケース： データ品質がしきい値を下回った場合に、パイプラインの実行を停止します。

品質チェックリスト

データパイプライン

• 冪等性がある（安全に再試行できる）
• スキーマ検証が適用されている
• 再試行を含むエラー処理がある
• データ品質チェックが自動化されている
• モニタリングとアラートが設定されている
• リネージが文書化されている

パフォーマンス

• パイプラインが SLA 内に完了する（例：<1 hour）
• 適用可能な場合は増分ロードを行う
• パーティショニング戦略が最適化されている
• クエリのパフォーマンスが <30 seconds（P95）

コスト最適化

• ストレージ階層化が実装されている（ホット／ウォーム／コールド）
• コンピューティングの自動スケーリングが設定されている
• クエリコストのモニタリングが有効になっている
• 圧縮が有効になっている（Parquet/ORC）

追加リソース

• 詳細な技術リファレンス：REFERENCE.md を参照
• コード例とパターン：EXAMPLES.md を参照