データエンジニアリング基礎——データパイプライン、ETL、データレイクの仕組み

読了時間: 約14分 ｜ 文字数: 約5,000字

「データは新しい石油」と言われて久しい。しかし、石油は採掘しただけでは使えず、精製・輸送・貯蔵のインフラが必要だ。データも同様で、生データを集めただけでは価値を生み出さない。それを価値ある形に加工し、必要な場所に届ける仕組み——これがデータエンジニアリングである。本稿では、データサイエンティストや ML エンジニアとの協業に必要なデータエンジニアリングの基礎を解説する。

データエンジニアリングとは

データエンジニアリング: データの収集・保存・処理・提供を担うエンジニアリング領域。データ分析や機械学習の「下流」を支えるインフラ。

データエンジニアリングの役割：
生データ → [収集] → [保存] → [処理] → [提供] → 分析/ML

データサイエンスの役割：
提供されたデータ → [分析] → [モデリング] → [洞察] → ビジネス価値

データエンジニアの主なタスク

データパイプラインの基本構成

データパイプラインは、データが生産されてから消費されるまでの流れを定義する。

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   ソース    │ ──→ │  変換処理   │ ──→ │   宛先      │
│  (Source)   │     │ (Transform) │     │ (Sink)      │
└─────────────┘     └─────────────┘     └─────────────┘

ソース（データ発生源）

変換処理（Transform）

データを分析・利用可能な形に変換する。

主な変換タイプ:

• クリーニング: 欠損値処理、異常値除去、フォーマット統一
• 結合: 複数ソースのデータを結合（JOIN）
• 集計: 合計、平均、カウントなどの集計
• 特徴量エンジニアリング: ML 用の特徴量を作成

宛先（Sink）

処理済みデータの格納先・提供先。

ETL vs ELT——データ処理のパラダイム

ETL（Extract, Transform, Load）

伝統的なアプローチ。データを変換してからロードする。

抽出 (Extract) → 変換 (Transform) → 読込 (Load)
      ↓                ↓               ↓
   ソースから      中間サーバー      DWH に
   取得            で変換            格納

メリット:

• DWH にロードする前にデータをクリーンアップできる
• 機密データのマスキングを適用可能
• 従来型の RDBMS と相性が良い

デメリット:

• 変換処理に時間がかかる
• 変換ロジックの変更にコスト
• 生データが残らない（変換後しか保存されない）

ELT（Extract, Load, Transform）

現代的なアプローチ。データを変換せずにロードし、後から変換する。

抽出 (Extract) → 読込 (Load) → 変換 (Transform)
      ↓              ↓                ↓
   ソースから    DWH に生データ   DWH 内で
   取得          で格納           SQL 変換

メリット:

• 生データが常に利用可能
• DWH の計算リソースを活用（スケール容易）
• 変換ロジックの変更が容易（SQL のみ）

デメリット:

• DWH の性能に依存
• 生データがそのまま保存される（ガバナンス課題）

どちらを使うべきか

2026 年現在、クラウドネイティブな環境ではELT がデファクトスタンダードだ。

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

データを「どのように保存するか」の選択だ。

データレイク（Data Lake）

あらゆる形式の生データを格納するリポジトリ。

データレイクの典型的な階層構造：

s3://data-lake/
├── raw/          # 生データ（変更不可）
├── staged/       # 一次加工済み
├── curated/      # 品質保証済み
└── sandbox/      # 実験用

データウェアハウス（DWH）

分析用に構造化されたデータを格納するリポジトリ。

データレイクハウス（Data Lakehouse）

両者の利点を組み合わせた新しいアーキテクチャ。

データレイクハウス = データレイク（安価・柔軟）+ DWH（高速・構造化）

代表製品：
- Databricks Lakehouse
- Delta Lake
- Apache Iceberg

メリット:

• 生データと構造化データを一元管理
• ACID トランザクションをサポート
• ML と BI を同一プラットフォームで

バッチ処理 vs ストリーミング処理

データ処理の「タイミング」の選択だ。

バッチ処理

一定期間のデータをまとめて処理。

# 典型的なバッチパイプライン例
毎日 2:00 に前日分のデータを処理：
1. 2:00 - データ抽出開始
2. 2:30 - 変換処理
3. 3:00 - DWH にロード
4. 4:00 - 集計完了
5. 9:00 - 朝礼でダッシュボード確認

ストリーミング処理

データをリアルタイムで継続的に処理。

# 典型的なストリーミングパイプライン例
クレジットカード不正検知：
1. カード利用発生
2. 100ms 以内にストリーム処理
3. 不正スコアを計算
4. 閾値超ならアラート + 取引ブロック
5. 全体で 500ms 以内

ラムダアーキテクチャ

バッチとストリーミングを組み合わせた設計パターン。

                  ┌──────────────┐
                  │   クエリ     │
                  │   レイヤー   │
                  └──────┬───────┘
                         │
            ┌────────────┴────────────┐
            ↓                         ↓
    ┌───────────────┐         ┌───────────────┐
    │  バッチ       │         │  スピード     │
    │  レイヤー     │         │  レイヤー     │
    │  (正確性)     │         │  (低遅延)     │
    └───────┬───────┘         └───────┬───────┘
            │                         │
            └────────────┬────────────┘
                         ↓
                  ┌──────────────┐
                  │   データ     │
                  │   レイヤー   │
                  └──────────────┘

バッチレイヤー: 正確だが遅い（真実の源泉） スピードレイヤー: 速いが近似値（リアルタイム性） クエリレイヤー: 両方を統合して回答

複雑なので、最近は「Kappa アーキテクチャ」（ストリーミング統一）も注目されている。

データパイプラインの設計原則

1. 冪等性（Idempotency）

同じ操作を何度実行しても同じ結果になること。

# 冪等でない処理
def load_data(data):
    db.insert(data)  # 2 回実行すると重複！

# 冪等な処理
def load_data_idempotent(data):
    db.upsert(data, key="id")  # 2 回実行しても同じ結果

なぜ重要か: パイプラインは失敗して再実行されることがある。その際、データが重複したり欠落したりしないようにする。

2. データ品質の自動検証

パイプライン内に品質チェックを組み込む。

# Great Expectations の例
expectations:
  - expect_column_values_to_not_be_null:
      column: user_id
  - expect_column_values_to_be_unique:
      column: order_id
  - expect_column_values_to_be_between:
      column: amount
      min_value: 0
      max_value: 1000000

検証失敗時はアラートを送り、パイプラインを停止する。

3. データラインージ（系譜）の追跡

データの出所と変遷を追跡可能にする。

order_summary.amount
  ← orders テーブル（PostgreSQL）
    ← 受注システム（2025-09-15 02:00 取得）
  ← exchange_rate テーブル
    ← 外部 API（為替レート）

問題発生時に「どのデータが影響を受けるか」を特定できる。

4. 監視とアラート

パイプラインの健全性を可視化する。

ツール選定の指針

オーケストレーション

変換（Transformation）

データ統合

So What?——実務への応用

• ELT から始める: クラウド DWH 環境なら、まず ELT パターンで始める
• 生データを必ず保存: 変換前の raw データは必ず保存（再処理可能に）
• 冪等性を担保: 再実行しても安全な設計に
• 監視を最初から: データ鮮度とデータ量の監視は必須
• ツールより設計: 優れた設計 × 単純なツール > 酷い設計 × 優れたツール
• データ契約を結ぶ: 上流・下流チームとデータ仕様を文書化

データエンジニアリングは「縁の下の力持ち」だが、データ駆動組織の成否を握る。堅牢なパイプラインが、信頼できる分析と意思決定を支える。

参考リンク

• Fundamentals of Data Engineering (O’Reilly) — データエンジニアリングの包括的な教科書
• dbt Documentation — 変換レイヤーの定番ツール
• Great Expectations — データ品質検証フレームワーク
• Data Engineering Zoomcamp — 無料のデータエンジニアリング講座