レイクハウスとテーブルフォーマット｜データエンジニアリング

🎓 レベル：発展　|　重要度：A（必須）

📎 前提：データウェアハウス・データレイクとオブジェクトストレージ　|　関連：メダリオンアーキテクチャ・べき等性と再実行

要点（BLUF）

レイクハウスは、安いデータレイク（オブジェクトストレージ＋Parquet）の上に、DWHの規律（ACIDトランザクション・スキーマ管理・更新）を載せたアーキテクチャ。
それを実現するのがテーブルフォーマット（Delta Lake / Apache Iceberg / Hudi）。Parquetファイル群の上に**メタデータ層（トランザクションログ・マニフェスト）**を置き、「ばらばらのファイル」を「1つのテーブル」として扱えるようにする。
得られるもの：ACID・タイムトラベル（過去断面の参照）・スキーマ進化・効率的なUPSERT/DELETE。この領域は競争が激しく要最新確認。

概念 ── 「レイクの安さ」と「DWHの規律」を両立

これまで、安いが無秩序なレイク（→ データレイクとオブジェクトストレージ）と、整っているが高いDWH（→ データウェアハウス）は別物でした。レイクハウスは「レイクのファイルに、テーブルとしての約束事を後付けする」ことで、両者の良いとこ取りを狙います。

flowchart TB
    OBJ["オブジェクトストレージ（安い・大量）"] --> PARQ["Parquetファイル群（列指向・圧縮）"]
    PARQ --> META["テーブルフォーマットのメタデータ層"]
    META --> TBL["1つのテーブルとして扱える（ACID・更新・履歴）"]
    ENG["クエリエンジン（Spark/DuckDB/Trino等）"] --> TBL

仕組み ── メタデータ層が「表」を作る

素のレイクは「フォルダにParquetが転がっている」状態で、原子的な更新ができません（書き途中が見える、削除が難しい）。テーブルフォーマットはトランザクションログ／マニフェストを持ち、「今このテーブルを構成するのはどのファイル群か」を版（バージョン）で管理します。

ACID：複数ファイルへの書き込みを「全部反映 or 全部なし」に。書き途中の中途半端な状態が見えない。
タイムトラベル：過去のバージョン（昨日の断面）を読める。監査・再現・誤更新の巻き戻しに有用。
スキーマ進化：列の追加・型変更を、古いファイルを壊さずに管理。
UPSERT/DELETE（MERGE）：素のParquetでは難しい行単位の更新・削除を効率化（→ べき等性と再実行の冪等な書き込みが素直に書ける）。

設計の勘所 ── 3レイヤーの対比

レイヤー	役割	例
ストレージ	安く大量に置く	S3 / GCS / Azure Blob
ファイル形式	列指向・圧縮	Parquet / ORC
テーブル形式	ACID・履歴・更新	Delta Lake / Iceberg / Hudi

ポイントは、これらが疎結合なこと。ストレージは安いまま、ファイルは列指向のまま、その上に「表の機能」だけを薄く足す。エンジン（Spark/Trino/DuckDB）はテーブルフォーマット越しに同じデータを読めるので、ベンダーロックインも避けやすい（要最新確認：相互運用の対応状況は流動的）。

なぜそうするか ── 二重持ちをやめる

なぜレイクハウスなのか。従来は「生はレイク、整形済みはDWH」と同じデータを二箇所に持ち、コピー・同期・コストが二重でした。レイクハウスなら1つのストレージに生も整形済みも置き、テーブルフォーマットの規律で品質を担保できる。「安い1つの場所に、DWH並みの信頼性で」——これが二重持ちの解消というレイクハウスの動機です。次節のメダリオン（→ メダリオンアーキテクチャ）は、その1つのレイクハウス内を層で整える設計です。

⚠️ よくある落とし穴

テーブルフォーマットを入れれば沼が自動で片付くと誤解 → 層設計・カタログは依然必要。
小ファイル問題を放置 → タイムトラベルやログでファイルが増え続ける。定期コンパクション／VACUUMで整理。
フォーマット選定を「最新の流行」だけで決める → エンジン対応・運用実績を確認（要最新確認）。
タイムトラベルの保持期間を無限にする → ストレージ肥大。保持ポリシーを設定。

対応ラボ

なし（概念回・本番テーブルフォーマットは外部基盤前提）。層別変換の実演はメダリオンアーキテクチャのラボで確認。