【比較】データレイク・DWH・データレイクハウスの違い¶

概要¶

データ分析基盤の選択肢として頻出する「データレイク」「データウェアハウス（DWH）」「データレイクハウス」。この3つは「どれが優れているか」ではなく、スキーマをいつ適用するか・どんなデータを置くか・トランザクション保証があるかという設計思想の違いで整理できます。

ざっくり言うと、データレイクは構造を決めずに生データを安価なオブジェクトストレージへそのまま貯める「読み出し時スキーマ（schema-on-read）」型、DWHは事前に構造を定義してから取り込み BI/SQL に最適化する「書き込み時スキーマ（schema-on-write）」型、データレイクハウスはレイクの安価なストレージの上に DWH 並みの ACID トランザクションやテーブル管理機能（Delta Lake / Apache Iceberg / Apache Hudi などのオープンテーブルフォーマット）を載せて両者を1基盤に統合したアーキテクチャです。

なお、本記事は「分析基盤のアーキテクチャ」を比べるものです。OLTP の業務 DB と分析用 DWH の役割分担そのものは別テーマなので、その軸はDBとDWHの違いを参照してください（こちらは記録用 DB と分析用 DWH の対比であり、本記事のレイク／レイクハウスとは扱う論点が異なります）。

例えるなら：倉庫の整理ポリシー¶

データレイク … 何でも段ボールのまま放り込める「巨大な倉庫」。安くて何でも入るが、欲しい物を取り出すとき（＝クエリ時）に自分で開けて中身を確認・整理する。
DWH … 入庫時に検品・ラベル付け・棚割りを済ませる「整理された物流センター」。出荷（分析）は速いが、入れる前のルール作りが必要で柔軟性は下がる。
データレイクハウス … 巨大倉庫はそのままに、台帳（メタデータ層）と入出庫管理（トランザクション）を導入して「物流センター並みの正確さ」を後付けした倉庫。

詳細比較¶

比較軸	データレイク (Data Lake)	データウェアハウス (DWH)	データレイクハウス (Lakehouse)
スキーマ適用	読み出し時（schema-on-read）	書き込み時（schema-on-write）	書き込み時の強制も可（スキーマ施行＋進化）
格納データ	構造化・半構造化・非構造化の生データ	主に構造化データ（整形後）	生データ＋整形データを同一基盤に
ストレージ	安価なオブジェクトストレージ（S3 等）	専用に最適化されたストレージ	レイクと同じ安価なオブジェクトストレージ
トランザクション	原則なし（一貫性保証が弱い）	あり（ACID）	あり（テーブルフォーマットが ACID を付与）
主用途	データサイエンス・ML・探索的分析	BI・定型レポート・SQL 分析	BI と ML を同一データで両立
代表技術	S3/ADLS/GCS 上のファイル群	BigQuery / Redshift / Snowflake 等	Delta Lake / Apache Iceberg / Apache Hudi
弱点・注意	統治不足で「データスワンプ」化しやすい	非構造化データ・ML に弱く、生データ複製が必要	比較的新しく運用ノウハウ・エンジン対応に差

補足：Delta Lake / Iceberg / Hudi は「ストレージ製品」ではなく、オブジェクトストレージ上の Parquet などのファイル群に対してトランザクションログ／メタデータ層を被せるオープンテーブルフォーマットです。これがレイクをレイクハウス化する中核技術です。

よくある誤解¶

誤解1：「データレイクハウスはデータレイクの新しい呼び名（リブランディング）にすぎない」 — 違います。レイクは原則トランザクション保証がなく、並行読み書きやスキーマ施行が弱いままです。レイクハウスは Delta Lake などのメタデータ層を介して ACID トランザクション・スキーマ施行・タイムトラベルをレイクストレージ上に付与する点が本質的な差です（Databricks／CIDR 2021 論文の定義）。名前だけの言い換えではありません。
誤解2：「データレイクは“安く貯められる”ので、ガバナンス不要でとりあえず全部入れておけばよい”」 — 安価に貯められるのは事実ですが、スキーマやカタログ・品質管理を怠ると検索も再利用もできない「データスワンプ（沼）」になります。schema-on-read は「後で構造を当てる」前提であって「構造を考えなくてよい」ではありません。
誤解3：「DWH があれば機械学習も全部そこでやればよい」 — DWH は整形済み構造化データと SQL 分析に最適化されており、画像・テキスト等の非構造化データや ML ワークフローには不向きです。従来はレイク＋DWH の二層構成になり、データ複製・鮮度遅延・ガバナンス分断が生じました。レイクハウスはこの二層問題の解消を狙ったものです。
誤解4：「レイクハウスにすれば DWH は常に不要になる」 — 必ずしもそうではありません。レイクハウスは比較的新しく、エンジンや運用ノウハウの成熟度に差があります。低レイテンシな定型 BI が中心で既存資産が DWH に集約されている場合は、DWH 継続のほうが合理的なこともあります。

実務での選び分け¶

「どれが新しいか」ではなく「データの種類・用途・統治体制」で選びます。

多様な生データ（ログ・画像・テキスト）を安く貯め、データサイエンス／ML で探索したい → データレイク（ただしカタログ・品質管理をセットで）。
構造化データに対する定型 BI・ダッシュボード・SQL 分析が中心で、低レイテンシと統治を重視 → DWH。
同じデータで BI と ML を両立し、二層構成のデータ複製・鮮度遅延・ガバナンス分断を解消したい → データレイクハウス（Delta Lake / Iceberg / Hudi を採用）。
判断軸：①スキーマをいつ確定できるか（探索的＝レイク／確定済み＝DWH）②非構造化・ML の比重 ③ACID・並行更新の要否 ④既存資産と運用体制。迷ったら「単一基盤で BI と ML を統合したいか」を起点にする。

ひとことまとめ¶

レイク＝生データを安価ストレージへ schema-on-read で貯める、DWH＝整形済み構造化データを schema-on-write で BI/SQL に最適化、レイクハウス＝レイクストレージ上にテーブルフォーマット（Delta/Iceberg/Hudi）で ACID とテーブル管理を付与し両者を1基盤に統合。優劣ではなく設計思想の違いとして捉えるのが選定の起点です。

出典・参考¶

Databricks Glossary「Data Lakehouse」（レイクの柔軟性・低コスト・スケールと、DWH のデータ管理・ACID トランザクションを組み合わせた新しいオープンなデータ管理アーキテクチャ。Delta Lake 等のメタデータ層がクラウドストレージ上にトランザクション・スキーマ施行・タイムトラベルを実装）: https://www.databricks.com/glossary/data-lakehouse
CIDR 2021 論文「Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics」（二層アーキテクチャの問題＝データ複製・鮮度遅延・ガバナンス分断。低コストオブジェクトストレージ上のメタデータ層が ACID を提供）: https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf
Delta Lake 公式ドキュメント「Welcome to the Delta Lake documentation」（データレイク上にレイクハウスを構築するオープンソース。Parquet とオブジェクトストレージ上で ACID トランザクション・スキーマ施行・タイムトラベルを提供）: https://docs.delta.io/latest/delta-intro.html
Apache Iceberg 公式ドキュメント（巨大な分析データセット向けオープンテーブルフォーマット。直列化可能分離による ACID 的保証・スキーマ進化・タイムトラベルをオブジェクトストレージ上で提供）: https://iceberg.apache.org/docs/latest/
AWS「What is a data lake?」（構造化・非構造化データを規模を問わず原形のまま集中保管。DWH はデータ取得前にスキーマを定義するが、データレイクは取得時にスキーマを定義しない）: https://aws.amazon.com/what-is/data-lake/