データ分析やAI活用を考える際、よく登場する「データレイク」「データウェアハウス（DWH）」「レイクハウス」。それぞれの概念の違いを理解することは、プラットフォーム選定や設計において非常に重要です。
本記事では、Databricksが提唱する「レイクハウス」の強みと、他モデルとの違いを初心者向けにわかりやすく解説します。
🔍 用語解説
| 用語 | 意味 | 補足 |
|---|---|---|
| データレイク（data lake） | 生データを大量に保存する倉庫 | 加工前の全データを保存できる |
| データウェアハウス（data warehouse） | 整形されたデータを保存・分析する倉庫 | KPIやBI分析向け |
| データマート（data mart） | 業務特化型のミニデータベース | 定型レポートやアプリで使う |
| レイクハウス（lakehouse） | レイクとDWHのいいとこ取り | Databricksが提唱・実装 |
| スキーマオンリード（schema-on-read） | データ読み取り時に構造を定義 | 柔軟だが精度には注意 |
| スキーマオンライト（schema-on-write） | データ保存時に構造を定義 | 扱いやすく、精度が高い |
各モデルの概要
データレイク（Data Lake）
- 構造化／非構造化データの全てをそのまま保存
- 安価・柔軟・スキーマレス（オンリード）
- 機械学習や探索的分析に適するが、データ整合性や品質管理には課題
データウェアハウス（Data Warehouse）
- 整形済み構造化データの保存・分析に最適
- 高性能・スキーマオンライト
- BIツールとの連携が得意
データマート（Data Mart）
- 特定用途向けの軽量・高速なデータベース
- 定型レポートやアプリ向けに最適化
レイクハウス（Lakehouse）
- データレイクの柔軟性 × DWHの信頼性を融合
- ACIDトランザクション、スキーマ進化、オープンフォーマットをサポート
Lakehouseとは？
Databricksが提唱する「レイクハウス」は、従来のレイクやDWHの弱点を補う次世代の統合データアーキテクチャです。
- Delta Lake：トランザクション & スキーマ管理
- Unity Catalog：アクセス制御・ガバナンス
- Databricks SQL：BI/SQL分析
モデル比較表
| 項目 | データレイク | データウェアハウス | データレイクハウス |
|---|---|---|---|
| データ形式 | 全形式対応 | 構造化中心 | 全形式対応 |
| スキーマ方式 | オンリード | オンライト | ハイブリッド |
| コスト | 安価 | 中〜高 | 中程度 |
| パフォーマンス | 低〜中 | 高 | 高 |
| 柔軟性 | 高 | 低 | 高 |
| 管理・ガバナンス | 弱 | 強 | 非常に強い |
代表ユースケース
| モデル | ユースケース例 |
|---|---|
| データレイク | IoTログ蓄積／音声・画像保存／ML前処理 |
| データウェアハウス | 売上集計／経営指標のKPI分析／BIレポート |
| レイクハウス | リアルタイム分析＋BI連携／ML×BI統合／全社横断データ基盤 |
✅ まとめ
レイクハウスは、「あらゆるデータを一箇所で、信頼性高く、柔軟に活用したい」という現代のニーズに応える最強アーキテクチャです。
Databricksを使えば、Delta Lake × Unity Catalog × Databricks SQL により、これをノーインフラで簡単に構築できます。