みなさんこんにちは、クルトンです！
本日は、Databricks を支える レイクハウスアーキテクチャ について扱います。
データレイクとデータウェアハウスの考え方から始め、Delta Lake がどのように関わっているのかを見ていきます。
📦 データレイクとは？
データレイクは、S3 / ADLS / GCS などの「オブジェクトストレージ」に形式を問わずデータを保存できる仕組みです。
AWS公式（AWS S3 の整合性モデル）：
特徴：
- JSON、CSV、Parquet、画像データなど、構造を問わず保存できる
- スケールしやすく、容量単価が安価
- ETL の前段や生データ保管に向いている
一方で、仕組み上いくつかの課題があります。
データレイクの主な弱点：
- UPDATE / DELETE が苦手
- Parquet などのファイルは “直接書き換える” 仕組みを持たない
- どのファイルがテーブルの一部なのかを自動管理しない
- テーブルとして扱うには外部での管理が必要
柔軟ではありますが、 “テーブルとしての保証が弱い” 点が大きな課題となります。
(そもそもテーブルとしてのデータ保存を目指したものではないですが。)
🏛️ データウェアハウス（DWH）とは？
DWHは構造化データを厳密に管理しながら、高速に集計・分析を行うための仕組みです。
特徴：
- ACID トランザクションの提供
- スキーマが厳格で品質が高い
- BI や業務分析に適した性能
課題：
- JSON やログデータなどの柔軟な取り扱いが苦手
- コストが高くなることがある
- ML やストリーミングの基盤とは距離がある場面も多い
🏔️ レイクハウスとは？
データレイクは柔軟だが信頼性が弱く、
DWH は信頼性が高いが柔軟性に欠けます。
これらの特徴を踏まえ、Databricks が提案するのが
レイクハウスアーキテクチャ です。
レイクハウスは、
- データレイクの柔軟性・スケーラビリティ
- DWH の信頼性・ガバナンス
これらを一つのプラットフォームで実現する構造です。
Azure公式(Data Lakehouseについて)：
引用元URL: https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse/
💎 Delta Lake がレイクハウスの中核となる理由
レイクハウスの中心には Delta Lake があります。
Databricks公式(Delta Lake 概要)：
クラウドストレージは本来“最終上書き勝ち” のような動作をする単純なファイル置き場であり、
- 書き込み途中の障害
- 同時書き込みの競合
- Parquet の直接上書きによる破損
といった問題が起こり得ます。
Delta Lake は、これらの問題を トランザクションログ（_delta_log） によって解決します。
その結果、
- ACID トランザクションの提供
- スキーマ管理
- Time Travel
- バッチ/ストリーミングの統合
がファイルベースで実現されます。
🔐 Delta Lake の ACID トランザクション
Databricks公式(ACIDについて)：
Delta Lakeは次の4性質を保証します。
◼ Atomicity（原子性）
更新は「全部成功」か「全部失敗」。
中途半端な状態が残りません。
◼ Consistency（一貫性）
スキーマや制約を満たすデータだけがコミットされます。
◼ Isolation（分離性）
複数の書き込みが干渉しないように保護されます。
◼ Durability（永続性）
コミットされた内容はストレージ上に確実に残ります。
📁 Delta Lake の仕組み（_delta_log）
Databricks公式：
- https://docs.databricks.com/ja/delta/history/
- https://www.databricks.com/jp/blog/2019/08/21/diving-into-delta-lake-unpacking-the-transaction-log.html
Delta Lake は Parquet を直接上書きせず、“追加型（append-only）” の方式を採用しています。
具体的には、
- 新しい Parquet ファイルを追加し
- _delta_log に “現在のテーブルを構成するファイル” を記録する
という仕組みで整合性を保ちます。
これにより、途中で障害が発生した場合でも「正しい状態に戻す」ことが可能になります。
👥 MVCC とスナップショット
Databricks公式（分離レベルについて）：
Delta Lake は、MVCC（Multi-Version Concurrency Control） に基づいて動作します。
- 読み込み → ある時点のスナップショットを参照
- 書き込み → 新しいバージョンとして追加
これにより、
- 読み手は安定したデータを読み続けられ
- 書き手は安全に更新でき
- 同時実行による破損が防がれます
🕒 Time Travel（過去バージョンの参照）
Databricks公式(タイムトラベル)：
Delta Lake では、過去のバージョンを簡単に参照できます。
SELECT * FROM table VERSION AS OF 5;
SELECT * FROM table TIMESTAMP AS OF "2025-01-01";
誤更新の調査や、再現性ある実験などに役立ちます。
🗂️ メダリオンアーキテクチャ（Bronze / Silver / Gold）
Databricks によるデータ構造設計の考え方として、Medallion Architecture があります。
Databricks公式(メダリオンレイクハウスアーキテクチャ)：
- Bronze：生データ（Raw）
- Silver：整形済みデータ（Cleaned）
- Gold：ビジネス利用の最終形（Aggregated）
段階的に品質を高めていく構造で、レイクハウスの “柔軟さと信頼性” を活かした設計となります。
イメージとしては、以下です。
🔗 今日の内容が後日にどう関係するか
以下の日程で書く予定の内容と関係があります。
- Day7：DLT（データ品質・パイプライン）
- Day8：ストリーミング（スナップショット読み取り）
- Day10：最適化（Z-Order / OPTIMIZE / VACUUM）
- Day19：Inference Table（推論ログ管理）
📚 参考（公式ドキュメント）
-
レイクハウス
https://learn.microsoft.com/ja-jp/azure/databricks/lakehouse/ -
Delta Lake
https://docs.databricks.com/ja/delta/ -
履歴管理（Time Travel / History）
https://docs.databricks.com/ja/delta/history/ -
メダリオンアーキテクチャ
https://docs.databricks.com/ja/lakehouse/medallion/
✨ 終わりに
今日はレイクハウスの全体像と、その中心にある Delta Lake の仕組みを整理しました。
明日は、レイクハウスの基盤となる処理エンジン Apache Spark の基本を見ていきます。
本日はここまで。
それでは、また明日！
Discussion