← データエンジニアリング 一覧

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：データエンジニアリングとは・役割・バッチ処理とストリーム処理　|　関連：ETLとELT・データウェアハウス

要点（BLUF）

• 「現代データスタック（modern data stack）」は、クラウドDWH／レイクハウスを中心に、収集・変換・提供のツールを疎結合に組み合わせた構成。各段を専用ツールが担い、SQLとオブジェクトストレージで繋がる。
• 流れは 収集（Fivetran等）→ 保存（Snowflake/BigQuery/Databricks）→ 変換（dbt）→ 提供（BI・ML）。安価なストレージを背景に、変換を後ろ倒しにするELTが主流になった。
• 全体を縦に貫くのが オーケストレーション（Airflow等） と カタログ／ガバナンス。ツール名より「どの段の課題か」で地図を読むのがコツ。

概念 ── 一枚の地図で捉える

個々のツールは入れ替わりが激しい（要最新確認の領域）ですが、段の構造は安定しています。まず段で地図を持ち、ツールは「その段の選択肢」として後から差し替え可能にしておくのが賢い学び方です。

flowchart LR
    SRC["ソース（業務DB・SaaS・ログ・API）"] --> ING["収集・取り込み"]
    ING --> STO["保存（クラウドDWH／レイクハウス）"]
    STO --> TRF["変換（SQL・dbt）"]
    TRF --> SRV["提供（BI・ML・分析）"]
    ORC["オーケストレーション（依存・スケジュール）"] -.制御.-> ING
    ORC -.制御.-> TRF
    CAT["カタログ・ガバナンス（メタデータ・リネージ）"] -.横断.-> STO
    classDef u fill:#eef,stroke:#557
    class SRC,ING,STO,TRF,SRV u

段ごとのツール地図（代表例・要最新確認）

設計の勘所 ── なぜ「現代」スタックなのか

かつては高価なオンプレDWHの容量を節約するため、ロード前に変換するETLが主流でした。クラウドでストレージが激安・計算が弾力的になった結果、「まず生のままロードし、DWHの計算力で後から変換する」ELTが合理的になりました（→ ETLとELT）。

この転換が現代データスタックの背骨です。生データをそのまま保存しておけば、後から要件が変わっても変換をやり直すだけで済み、源に取りに戻る必要がありません。dbtが「SQLによる変換のコード化」で広く使われるのも、この“DWHの中で変換する”流れの帰結です。

なぜそうするか ── 疎結合と差し替え可能性

なぜ一体型でなく、段ごとに別ツールを繋ぐのか。各段を独立に最適化・交換できるからです。収集をAirbyteからFivetranに替えても、保存と変換はそのまま。SQLとオブジェクトストレージという共通インターフェースで繋がっているので、ベンダーロックインを避けつつ各段でベストを選べます。これは ER図とスキーマ設計 の「疎結合」やソフトウェア工学のモジュール化と同じ発想です。

⚠️ よくある落とし穴

• ツール名を覚えることを学習だと思う → ツールは2年で入れ替わる。段の役割と境界を覚える。
• 「全部入りプラットフォーム」を過信する → 便利だが、特定段で要件に合わないとき逃げ場がない。境界の見える疎結合が安全。
• ELTだからと生データを無検証で貯め込む → “沼（data swamp）”化する。取り込み時の最低限の契約・品質（→ データ品質とテスト）とカタログ（→ データガバナンスとカタログ）が要る。

対応ラボ

なし（地図回）。次章から各段を動くSQL・変換で具体化していく。

関連

• ELT/ETLの「変換をどこでやるか」の本質は ETLとELT
• 保存の中心、クラウドDWHは データウェアハウス、生データの湖は データレイクとオブジェクトストレージ
• 全段を制御するオーケストレーションは ワークフローオーケストレーション

← 第1章 データエンジニアリングの全体像 目次