はじめに
「データウェアハウス（DWH）とデータレイク、どっちを使えばいいの？」——この疑問に対する答えとして登場したのがレイクハウス（Data Lakehouse）です。
この記事では、データ基盤の歴史を振り返りながら、レイクハウスとは何か、なぜ注目されているのかを初心者向けに解説します。
対象読者
- データ基盤の全体像をざっくり把握したい方
- DWH・データレイクとの違いを理解したい方
- レイクハウスという言葉を聞いたけど、何がうれしいのかピンときていない方
この記事で得られること
- DWH → データレイク → レイクハウスという進化の流れが分かる
- レイクハウスのアーキテクチャをイメージできる
- 自分のチーム・プロジェクトにレイクハウスが合うかどうか判断する材料が得られる
参考リンク
データ基盤の歴史を振り返る
レイクハウスを理解するには、その前身であるDWHとデータレイクを知っておくと話が早いです。それぞれの特徴と課題を簡単に見ていきましょう。
データウェアハウス（DWH）とは
DWHは、さまざまなソースから集めたデータを構造化（スキーマ定義済み）した状態で格納するデータ基盤です。1990年代から使われてきた歴史の長いアプローチですね。
特徴
- データは格納前にクレンジング・変換される（ETL: Extract, Transform, Load）
- SQLベースの高速なクエリに最適化されている
- BIツール（Tableau、Power BIなど）との相性が良い
課題
- 構造化データしか扱えない（画像、動画、ログなどの非構造化データは苦手）
- ストレージとコンピュートが密結合で、スケールアウトのコストが高い
- スキーマ変更に時間がかかり、柔軟性が低い
データレイクとは
DWHの制約を解消するために2010年代に広まったのがデータレイクです。「まずは生データをそのまま貯めて、必要なときに加工しよう」という考え方ですね。
特徴
- 構造化・半構造化・非構造化データをそのまま格納できる
- クラウドオブジェクトストレージ（S3、GCSなど）を活用し、低コストで大量保存が可能
- 機械学習やデータサイエンスのワークロードに適している
課題
- ガバナンスが弱い（ACIDトランザクション1非対応）
- データ品質の管理が難しく、"データスワンプ"（使い物にならないデータの沼）になりがち
- BIツールから直接クエリすると、パフォーマンスが出にくい
それぞれの課題を整理する
両者の得意・不得意をまとめると、次のようになります。
こう見ると、「両方のいいとこ取りがしたい」と思いますよね。そこで登場するのがレイクハウスです。
レイクハウスとは
レイクハウスは、データレイクのスケーラビリティと柔軟性に、DWHのデータ品質・ガバナンス・高速クエリを組み合わせたアーキテクチャです。
ひとことで言えば「データレイクの上にDWH相当の機能を載せたもの」ですね。
レイクハウスが実現できたのは、以下のような技術の登場がきっかけです。
- オープンテーブルフォーマット（Delta Lake、Apache Iceberg、Apache Hudi）
- メタデータ管理レイヤーの進化
- クラウドオブジェクトストレージの低コスト化・高性能化
これらにより、データレイク上でもACIDトランザクションやスキーマ管理が可能になりました。
レイクハウスのアーキテクチャ
レイクハウスの内部構造を、2つの視点から見てみましょう。
レイヤー構成
レイクハウスは大きく以下のレイヤーで構成されます。
各レイヤーの役割を簡単に説明しますね。
取り込み層（Ingestion）
さまざまなソースからデータを収集します。バッチ処理だけでなく、リアルタイムストリーミング（Kafka、Kinesis など）にも対応します。
ストレージ層（Storage）
クラウドオブジェクトストレージ（S3、ADLS、GCS）にデータを格納します。コンピュートとストレージが分離されている点がポイントで、スケーリングの柔軟性とコスト効率が高いです。
メタデータ層（Metadata）
レイクハウスの要となるレイヤーです。Delta Lake や Apache Iceberg などのオープンテーブルフォーマットがここで活躍します。ACIDトランザクション、スキーマ管理、タイムトラベル（過去時点のデータ参照）などを実現します。
処理層（Processing）
Spark、Flink、Trino などのエンジンがデータの変換・集計を行います。
消費層（Serving）
BIツール、MLモデル、アプリケーションなど、最終的なデータの利用先です。
メダリオンアーキテクチャ（Bronze / Silver / Gold）
レイクハウスでよく採用されるデータ管理パターンが、メダリオンアーキテクチャです。データを3段階に分けて品質を段階的に上げていきます。
| 層 | 役割 | 例 |
|---|---|---|
| Bronze | ソースからの生データをそのまま保存 | JSON ログ、CSV の生ファイル |
| Silver | クレンジング・標準化済みのデータ | 型変換済み、重複排除済みのテーブル |
| Gold | ビジネスロジックを適用した分析用データ | 日次売上サマリー、KPI テーブル |
この段階的なアプローチにより、「まず安全に生データを保存」→「必要に応じて品質を上げて利用」という柔軟な運用ができます。
レイクハウスのメリット
レイクハウスの主なメリットを整理します。
統一アーキテクチャ
DWHとデータレイクを別々に運用する必要がなくなります。データのコピーや移動が減るため、整合性の確保もしやすくなりますね。
コスト効率
クラウドオブジェクトストレージを活用するため、DWH専用ストレージに比べて大幅にコストを抑えられます。コンピュートとストレージの分離により、必要なときだけ処理能力をスケールアウトできます。
ガバナンスとデータ品質
ACIDトランザクション、スキーマの強制、アクセス制御など、DWH並みのガバナンスをデータレイク上で実現できます。
BI と AI/ML の両立
構造化データ向けのBIクエリも、非構造化データを扱うMLワークロードも、同じ基盤上で実行できます。データの二重管理が不要になるのは大きいですね。
オープンフォーマット
Delta Lake、Apache Iceberg などのオープンフォーマットを使うことで、ベンダーロックインを避けられます。複数のクエリエンジンからデータにアクセスできるのも強みです。
DWH・データレイク・レイクハウス比較表
3つのアーキテクチャを一覧で比較してみましょう。
| 観点 | DWH | データレイク | レイクハウス |
|---|---|---|---|
| データ形式 | 構造化のみ | すべて | すべて |
| データ品質 | 高い | 低くなりがち | 高い |
| ACIDトランザクション | ✅ | ❌ | ✅ |
| コスト | 高い | 低い | 低〜中 |
| スケーラビリティ | 中 | 高い | 高い |
| BIクエリ性能 | 高い | 低い | 高い |
| ML/AI対応 | 限定的 | 得意 | 得意 |
| ガバナンス | 強い | 弱い | 強い |
| ベンダーロックイン | 高い傾向 | 低い | 低い（オープン） |
まとめ
この記事では、データ基盤の進化の流れを振り返りながら、レイクハウスの概念・アーキテクチャ・メリット・課題を解説しました。
ポイントをおさらいしましょう。
- レイクハウスは、データレイクの柔軟性・低コストと、DWHの高品質・高速クエリを組み合わせたアーキテクチャ
- Delta Lake や Apache Iceberg などのオープンテーブルフォーマットが技術的な基盤になっている
- メダリオンアーキテクチャ（Bronze / Silver / Gold）でデータ品質を段階的に管理できる
- 万能ではないが、BIとAI/MLの両立が求められるケースでは有力な選択肢
データ基盤の世界は急速に進化しています。レイクハウスに興味を持った方は、まずはDelta LakeやApache Icebergのチュートリアルから触ってみるのがおすすめです。
※2026年3月時点の情報です。各製品の最新情報は公式ドキュメントをご確認ください。
-
ACID とは、Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）の頭文字で、信頼性のあるデータ処理を保証するための4つの特性です。 ↩