生ログと画像は安価なオブジェクトストレージへ置き、集計用データはDWHへコピーし、機械学習用にまた別の形式へ書き出す。用途が増えるほど同じデータの複製と変換が増え、どれが最新で正しいか分からなくなる。この違和感に対して提案された設計概念がデータレイクハウスです。
結論から言えば、レイクハウスはデータレイクの柔軟で拡張しやすいストレージ上に、DWHで重視されてきたトランザクション、スキーマ管理、履歴、性能、ガバナンスを持ち込むアーキテクチャです。特定製品一つの名前ではありません。また、Bronze・Silver・Goldへ分けるメダリオンアーキテクチャは代表的な実装パターンですが、三層に分ければ自動的にレイクハウスになるわけでもありません。
最初に結論
データレイクハウスとは、オブジェクトストレージ上の多様なデータを中心に置きながら、ACIDトランザクション、スキーマの強制・変更、タイムトラベル、カタログ、SQL性能などを加え、BIとAI・機械学習を一つの基盤で扱いやすくするアーキテクチャです。メダリオンは、未加工に近いBronze、品質を整えるSilver、用途別のGoldへ段階的にデータを改善する設計パターンです。
この記事のポイント
- ・レイクハウスはストレージ形式、カタログ、コンピュート、ガバナンスを組み合わせたアーキテクチャであり、単なるデータレイクの別名ではない
- ・オープンテーブル形式がオブジェクトストレージ上のファイルへトランザクションログとメタデータを与える
- ・メダリオンのBronze・Silver・Goldは品質段階であり、必ず物理環境を三つに分ける規格ではない
- ・既存DWHで要件を満たす小規模用途では、移行の複雑さが便益を上回る場合がある
対象：データ保存先や分析基盤の再設計を検討し、レイクハウスやメダリオンという用語を実務に置き換えたい企画・データ担当者
データレイクとDWHの間にあった溝
データレイクは、構造化・半構造化・非構造化データをオブジェクトストレージへ広く保存できます。元データを残し、複数のコンピュートエンジンから使える柔軟さがあります。一方、ファイルが増えるだけでは、同時更新、スキーマ変更、重複、細かなアクセス制御、SQL性能を利用者ごとに解決することになります。整備されていないデータレイクでは、必要なデータを見つけても信用できません。
データウェアハウスは、構造を管理したデータを安定してSQL分析することに強みがあります。現在のクラウドDWHは半構造化データや機械学習にも対応しており、『DWHは構造化データだけ』と単純化はできません。それでも、ストレージとエンジンの選択、オープン形式、原本データ、複数ワークロードの共有を重視すると、レイクハウスというアーキテクチャが比較対象になります。
2021年のCIDR論文は、低コストで直接アクセス可能なデータレイクのストレージと、DWHの管理・性能機能を統合する新しいオープンアーキテクチャとしてレイクハウスを整理しました。現在は各クラウド事業者やベンダーが異なる実装を提供しているため、名称より構成要素を比較します。
DWH・データレイク・レイクハウスを比較する
境界は製品の進化で重なっています。次の表は固定的な製品分類ではなく、設計の出発点です。実際にはクラウドDWHが外部テーブルを読み、データレイク基盤がSQLウェアハウスを提供するため、要件ごとに確認してください。
| 観点 | DWH中心 | データレイク中心 | レイクハウス |
|---|---|---|---|
| 主な保存 | 管理されたテーブルストレージ | オブジェクトストレージ上のファイル | オブジェクトストレージ＋テーブル形式・カタログ |
| 主な用途 | BI、定型・アドホックSQL | 原本保存、データサイエンス、加工 | BI、AI、MLを共通データで扱う |
| トランザクション | 製品が管理 | 素のファイルでは利用者側で考慮 | テーブル形式がACID等を管理 |
| スキーマ | 事前管理が中心 | 柔軟だが混乱しやすい | スキーマの強制と変更を両立させる |
| エンジン | 提供製品のエンジンが中心 | 複数エンジンを選びやすい | 共有形式を複数エンジンで読む構成も可能 |
| 注意点 | 複製とベンダーロックインを確認 | 品質・ガバナンスを別途構築 | 構成部品と運用責任が増える |
オープンテーブル形式がファイルをテーブルとして管理する
オブジェクトストレージ上にParquetファイルを置くだけでは、複数のジョブが同時に読み書きしたときの一貫性や、どのファイルが現在のテーブルを構成するかを安全に管理しにくくなります。Delta LakeやApache Icebergなどのテーブル形式は、データファイルに加えてトランザクションログやメタデータを持ち、スナップショット単位でテーブルの状態を管理します。
これにより、処理途中の不完全な状態を見せないACIDトランザクション、過去スナップショットを読むタイムトラベル、列追加などのスキーマ変更、パーティション構成の管理が可能になります。ただし、形式が機能を定義しても、すべてのエンジンが同じ機能を同じ挙動で扱えるとは限りません。書き込み、MERGE、削除、権限、カタログ連携を、実際に利用する組み合わせで検証します。
| 機能 | 解決したい問題 | 確認すること |
|---|---|---|
| ACIDトランザクション | 途中状態や競合更新を避ける | 同時書き込みと失敗時ロールバック |
| スキーマ強制 | 想定外の列・型を混ぜない | 拒否、隔離、通知の動作 |
| スキーマ変更 | 安全に列を追加・変更する | 互換性と下流への影響 |
| タイムトラベル | 過去状態の再現と監査 | 保持期間とストレージ費用 |
| メタデータ管理 | 大量ファイルをテーブルとして読む | カタログとエンジン間の互換性 |
メダリオンアーキテクチャのBronze・Silver・Gold
メダリオンアーキテクチャは、データを品質と用途の段階で分けるパターンです。名称はDatabricksの公式文書で広く使われ、Microsoft Fabricも推奨パターンとして説明しています。ただし、業界共通の必須規格ではありません。未加工、検証済み、用途別など別名でも、責務の境界が明確なら同じ考え方を実装できます。
| 層 | 主な役割 | 行う処理 | 利用者 |
|---|---|---|---|
| Bronze | ソースに近い原本を保持 | 取り込み時刻・出典を付けて追記 | データエンジニア、再処理 |
| Silver | 品質と共通構造を整える | 型、重複、欠損、標準化、結合 | 分析者、データサイエンティスト |
| Gold | 業務用途へ最適化する | 指標、集計、データマート、特徴量 | BI、業務部門、AIアプリ |
EC注文データを三層で処理する例
注文API、店舗CSV、決済SaaSからデータを集める例を考えます。Bronzeでは、受け取ったJSONやCSVをソース別に保存し、ingested_at、ファイル名、バッチIDを付けます。元の誤りを勝手に修正せず、後から同じ処理をやり直せるようにします。
Silverでは、注文IDと顧客IDの型をそろえ、タイムゾーンと通貨を標準化し、再送された注文を重複排除します。取消・返品を別の状態として扱い、データコントラクトに反するレコードは隔離します。Goldでは、『確定売上』『顧客別LTV』『商品別日次売上』など、利用者が共通定義で使うテーブルを作ります。
- 1. Bronzeへ追記する：ソースの内容とメタデータを保持し、同じバッチを重複取り込みしないキーを用意します。
- 2. Silverで共通化する：型、時刻、通貨、主キー、状態を検証し、不正レコードは理由とともに隔離します。
- 3. Goldで意味を固定する：売上定義、粒度、更新SLO、責任者を定め、BIとAIが同じ意味を再利用できるようにします。
- 4. 各層を観測する：到着量、鮮度、品質ルール、データリネージを記録し、どの層で減少・変形したか追えるようにします。
Delta LakeかApache Icebergかは要件から選ぶ
テーブル形式の選択では、機能一覧だけでなく、現在利用中のクラウド、カタログ、主要エンジン、運用スキル、既存データとの相性を見ます。Delta LakeはDatabricksのエコシステムで深く統合され、Apache Icebergは公開仕様として複数エンジン・カタログから利用されています。ほかにもApache Hudiなどの選択肢があります。
『オープン』という言葉だけで可搬性を保証されたと考えないでください。仕様が公開されていても、ベンダー固有の最適化、カタログ、権限、ストリーミング、保守手順へ依存する場合があります。代表的な読み取り・書き込み・MERGE・スキーマ変更・タイムトラベルを複数エンジンで試し、移行時に失う機能を記録します。
- 主要な読み取り・書き込みエンジンが正式対応しているか
- カタログ、ID管理、行・列権限を一貫して管理できるか
- 小さなファイル整理、ファイル統合、スナップショット期限切れを誰が運用するか
- 障害時のロールバックと別環境への復旧を検証できるか
- 固有機能を外した場合にも重要ワークロードが動くか
レイクハウスが不要な場合もある
データ量と種類が限られ、利用者の中心がSQLによるBIで、現在のDWHが費用・性能・ガバナンス要件を満たすなら、アーキテクチャを移す理由は弱いでしょう。オブジェクトストレージ、テーブル形式、カタログ、複数コンピュートの組み合わせは自由度と同時に、互換性検証と保守の責任を増やします。
また、レイクハウスを採用しても、意味の重複、責任者不在、低品質データは解決しません。BronzeからGoldへコピーしただけで、利用価値が生まれるわけではありません。移行前に、減らしたいデータ複製、統合したいワークロード、必要なオープン性、性能・費用の基準を明文化し、現在構成との比較を行います。
| 状況 | 判断の方向 |
|---|---|
| BI中心で既存DWHが要件を満たす | 継続利用と部分改善を優先 |
| 大量のファイル・AI/ML・BIで同じデータを使う | レイクハウスのPoCに価値がある |
| エンジンをまたぐオープン形式が重要 | 互換性を実機検証して選ぶ |
| 責任者・品質・指標定義が未整備 | アーキテクチャ移行前後でガバナンスを並行整備 |
導入前に答える6つの質問
新しい基盤を先に作らず、代表ワークロード一つを端から端まで動かします。既存DWH案とレイクハウス案で、取り込み、変換、BIクエリ、AI/ML利用、権限、障害復旧を比較します。通常時のクエリ速度だけでなく、スキーマ変更、遅延、再処理の作業も試すことが大切です。
- どのデータ複製と運用負担を減らしたいか
- BI、ストリーミング、AI/MLのどのワークロードを同じデータへ載せるか
- 必要な更新頻度、同時実行、クエリ性能はどの程度か
- テーブル形式、カタログ、エンジンの責任分担を誰が持つか
- 機密区分、行・列権限、監査を各アクセス経路で守れるか
- 既存構成から移す費用に対し、どの指標が改善すれば採用するか
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics — CIDR 2021（最終確認：2026-08-07）：レイクハウスの問題設定、構成要素、DWH・データレイクとの関係を参照。
- What is a data lakehouse? — Databricks（最終確認：2026-08-07）：レイクハウスの基本概念と、データウェアハウス・AI/MLワークロードの統合を参照。
- What is the medallion lakehouse architecture? — Databricks（最終確認：2026-08-07）：Bronze、Silver、Goldの品質段階と役割を参照。
- Implement medallion lakehouse architecture in Microsoft Fabric — Microsoft Learn（最終確認：2026-08-07）：メダリオンパターンの実装選択、層の分離、データ形式に関する説明を参照。
- Apache Iceberg Documentation — Apache Iceberg（最終確認：2026-08-07）：スキーマ変更、隠れたパーティション分割、タイムトラベル、直列化可能な分離レベルなどを参照。
よくある質問
データレイクハウスとクラウドDWHはどちらが優れていますか？
一律には決まりません。現在のクラウドDWHも多様なデータやAI機能に対応しています。オブジェクトストレージ上のオープン形式、複数エンジン、BIとMLのデータ共有が重要ならレイクハウスを比較し、BI中心で既存要件を満たすならDWH継続が合理的です。
Bronze・Silver・Goldの三層は必須ですか？
必須規格ではありません。原本、共通品質、用途別データの責務を分ける代表パターンです。規模に応じて層を統合したり別名にしたりできますが、再処理可能性と利用者向け品質の境界は明確にします。
Delta LakeとApache Icebergはどちらを選ぶべきですか？
利用するクラウド、カタログ、コンピュートエンジン、書き込みパターン、ガバナンス、チームのスキルで選びます。機能表だけで決めず、読み取り・書き込み・MERGE・スキーマ変更・復旧を代表ワークロードで実行し、固有機能と移行可能性を確認してください。
まとめと次の一歩
レイクハウスの判断軸は流行語ではなく、複製削減、複数エンジンの利用、BIとAI・MLのデータ共有が運用複雑性を上回るかです。メダリオンの三層は品質責任を分ける手段にすぎません。