senior-data-engineer

シニアデータエンジニア

スケーラブルで信頼性の高いデータシステムを構築するための、本番環境向けデータエンジニアリングスキルです。

目次

1. トリガーフレーズ
2. クイックスタート
3. ワークフロー
4. アーキテクチャ決定フレームワーク
5. 技術スタック
6. リファレンスドキュメント
7. トラブルシューティング

---

トリガーフレーズ

次のような語句があった場合に、このスキルを有効にします。

パイプライン設計：

• 「…のデータパイプラインを設計して」
• 「ETL／ELT プロセスを構築して」
• 「…からデータを取り込むにはどうすればよいですか？」
• 「…からのデータ抽出を設定して」

アーキテクチャ：

• 「バッチとストリーミングのどちらを使うべきですか？」
• 「Lambda と Kappa のアーキテクチャ」
• 「遅れて到着するデータをどう処理するか」
• 「データレイクハウスを設計して」

データモデリング：

• 「ディメンショナルモデルを作成して」
• 「スタースキーマとスノーフレークスキーマ」
• 「緩やかに変化するディメンションを実装して」
• 「データボルトを設計して」

データ品質：

• 「…にデータ検証を追加して」
• 「データ品質チェックを設定して」
• 「データの鮮度を監視して」
• 「データコントラクトを実装して」

パフォーマンス：

• 「この Spark ジョブを最適化して」
• 「クエリの実行が遅い」
• 「パイプラインの実行時間を短縮して」
• 「Airflow DAG をチューニングして」

---

クイックスタート

コアツール

# Generate pipeline orchestration config
python scripts/pipeline_orchestrator.py generate \
  --type airflow \
  --source postgres \
  --destination snowflake \
  --schedule "0 5 * * *"

# Validate data quality
python scripts/data_quality_validator.py validate \
  --input data/sales.parquet \
  --schema schemas/sales.json \
  --checks freshness,completeness,uniqueness

# Optimize ETL performance
python scripts/etl_performance_optimizer.py analyze \
  --query queries/daily_aggregation.sql \
  --engine spark \
  --recommend

---

ワークフロー

→ 詳細は references/workflows.md を参照してください。

アーキテクチャ決定フレームワーク

このフレームワークを使って、データパイプラインに最適なアプローチを選択します。

バッチとストリーミング

基準	バッチ	ストリーミング
レイテンシ要件	数時間から数日	数秒から数分
データ量	大規模な履歴データセット	継続的なイベントストリーム
処理の複雑さ	複雑な変換、ML	単純な集計、フィルタリング
コストへの配慮	より費用対効果が高い	インフラコストが高い
エラー処理	再処理が容易	綿密な設計が必要

判断ツリー：

Is real-time insight required?
├── Yes → Use streaming
│   └── Is exactly-once semantics needed?
│       ├── Yes → Kafka + Flink/Spark Structured Streaming
│       └── No → Kafka + consumer groups
└── No → Use batch
    └── Is data volume > 1TB daily?
        ├── Yes → Spark/Databricks
        └── No → dbt + warehouse compute

Lambda と Kappa のアーキテクチャ

項目	Lambda	Kappa
複雑さ	2 つのコードベース（バッチ＋ストリーム）	単一のコードベース
保守	高い（バッチ／ストリームのロジックを同期）	低い
再処理	ネイティブのバッチレイヤー	ソースから再生
ユースケース	ML のトレーニング＋リアルタイム配信	イベント駆動のみ

Lambda を選ぶ場合：

• 履歴データを使って ML モデルをトレーニングする必要がある
• 複雑なバッチ変換をストリーミングで実現できない
• 既存のバッチインフラがある

Kappa を選ぶ場合：

• イベントソーシングアーキテクチャ
• すべての処理をストリーム操作として表現できる
• レガシーシステムなしで新たに始める

データウェアハウスとデータレイクハウス

特徴	ウェアハウス（Snowflake／BigQuery）	レイクハウス（Delta／Iceberg）
最適な用途	BI、SQL 分析	ML、非構造化データ
ストレージコスト	高い（独自形式）	低い（オープン形式）
柔軟性	書き込み時のスキーマ適用	読み取り時のスキーマ適用
パフォーマンス	SQL に最適	良好、改善中
エコシステム	成熟した BI ツール	拡大中の ML ツール

---

技術スタック

カテゴリ	技術
言語	Python、SQL、Scala
オーケストレーション	Airflow、Prefect、Dagster
変換	dbt、Spark、Flink
ストリーミング	Kafka、Kinesis、Pub/Sub
ストレージ	S3、GCS、Delta Lake、Iceberg
ウェアハウス	Snowflake、BigQuery、Redshift、Databricks
品質	Great Expectations、dbt tests、Monte Carlo
監視	Prometheus、Grafana、Datadog

---

リファレンスドキュメント

1. データパイプラインアーキテクチャ

以下については references/data_pipeline_architecture.md を参照してください。

• Lambda と Kappa のアーキテクチャパターン
• Spark と Airflow によるバッチ処理
• Kafka と Flink によるストリーム処理
• Exactly-once セマンティクスの実装
• エラー処理とデッドレターキュー

2. データモデリングのパターン

以下については、references/data_modeling_patterns.md を参照してください。

• ディメンショナルモデリング（スター／スノーフレーク）
• 緩やかに変化するディメンション（SCD タイプ 1～6）
• データボルトモデリング
• dbt のベストプラクティス
• パーティショニングとクラスタリング

3. DataOps のベストプラクティス

以下については、references/dataops_best_practices.md を参照してください。

• データテストフレームワーク
• データコントラクトとスキーマ検証
• データパイプラインの CI/CD
• オブザーバビリティとリネージ
• インシデント対応

---

トラブルシューティング

→ 詳細については references/troubleshooting.md を参照してください