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

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

📎 前提：ファイルフォーマットとシリアライゼーション・データウェアハウス　|　関連：レイクハウスとテーブルフォーマット

要点（BLUF）

• データレイクは、構造化・半構造化・非構造化を問わず、生データをそのまま安く大量に貯める保管庫。土台はオブジェクトストレージ（S3/GCS/Azure Blob）。
• DWHが「スキーマオンライト（入れる前に構造を決める）」なのに対し、レイクは「スキーマオンリード（読むときに構造を解釈する）」。とりあえず置いて後で使える柔軟さが武器。
• 柔軟さの代償は無秩序化（データ沼／data swamp）。パーティション設計・カタログ・命名規約で秩序を保たないと、貯めただけで使えなくなる。

概念 ── 「とりあえず全部置く」湖

DWHは「整ったものだけ」を入れますが、レイクは「生のまま何でも」を受け入れます。JSONログ・画像・CSV・Parquetが同じストレージに同居できる。後から「やっぱりこのログも分析したい」となっても、捨てていなければ使えます。

flowchart TB
    LOG["アプリログ（JSON）"] --> LAKE["データレイク（オブジェクトストレージ）"]
    IMG["画像・音声"] --> LAKE
    CSV["CSV/Parquet"] --> LAKE
    LAKE --> ENG["読むとき構造を解釈（スキーマオンリード）"]

仕組み ── オブジェクトストレージとパーティション

オブジェクトストレージは「キー（パス）→ オブジェクト（ファイル）」のフラットな巨大KVストア。ディレクトリは見かけ上のもので、安価・ほぼ無限・高耐久だが、ファイルシステム的な追記・ロックは弱い。

性能の鍵がパーティション分割。よく絞り込む列（日付など）でフォルダを分けて置くと、クエリが不要なフォルダを丸ごと読み飛ばせます（パーティションプルーニング）。

df.to_parquet(path, partition_cols=["ymd"])               # 日付で分けて書く
one = pd.read_parquet(path, filters=[("ymd","==","2026-06-02")])  # 1日分だけ読む

実行結果（実機）:

生成パーティション: ['ymd=2026-06-01', 'ymd=2026-06-02']
2026-06-02 だけ読込 -> 3 行, 売上合計=3350

ymd=2026-06-01/ と ymd=2026-06-02/ にデータが分かれ、6月2日を指定するとそのフォルダだけI/Oして3行を読みます。テーブルが何年分あっても、1日分のクエリは1日分しか読まない——これがレイクのスケール術です。

設計の勘所 ── DWH と レイクの対比

なぜそうするか ── 安さと柔軟さを別に確保する

なぜDWHと別にレイクを持つのか。「安く貯める」と「速く分析する」を別レイヤーで最適化できるからです。生データを高価なDWHに全部入れると費用がかさむ。安いレイクに全部貯め、分析が必要な部分だけDWH（やレイク上のエンジン）で処理する。ELT（→ ETLとELT）の「まず生をロード」も、安いレイクがあって成立します。ただし「貯めただけ」では沼。次節のレイクハウス（→ レイクハウスとテーブルフォーマット）は、この沼問題に「テーブルの規律」で答えます。

⚠️ よくある落とし穴

• 命名・カタログなしで貯める → 何がどこにあるか分からない沼に。パス規約とカタログ（→ データガバナンスとカタログ）を最初から。
• 小さいファイルを大量生成（small files problem）→ メタデータ負荷で激遅。まとめて書く・コンパクション。
• パーティション列の選択ミス → 絞り込みに使わない列で分けても効かない。逆に細かすぎると小ファイル乱立。
• オブジェクトストレージにOLTP的な頻繁更新を期待 → 追記・更新は不得手。テーブルフォーマットで補う。

対応ラボ

data-engineering-study/labs/05_warehouse_lakehouse.py（PYTHONIOENCODING=utf-8 で実行・パーティション分割と読み飛ばしを確認済み）。

関連

• 貯めるファイルの形式は ファイルフォーマットとシリアライゼーション
• 整った分析基盤の対は データウェアハウス、両者統合は レイクハウスとテーブルフォーマット
• 沼化を防ぐ層構造は メダリオンアーキテクチャ

← 第5章 データウェアハウスとレイクハウス 目次