Delta Lakeとは？初心者向け完全ガイド｜ACID・Time Travel・Z-Order

Delta Lakeは、データレイクに信頼性・パフォーマンス・ガバナンスを付与するオープンソースのストレージレイヤーです。Apache Parquetファイル形式の上にトランザクションログを追加することで、ACIDトランザクション・スキーマエンフォースメント・Time Travel・増分処理といったデータウェアハウス並みの機能をデータレイク上で実現します。Databricks Lakehouse Platformの基盤技術であり、すべてのDatabricks認定試験で出題される最重要テクノロジーです。

この記事では、Delta Lakeの基本概念から実践的な使い方まで、初心者にもわかりやすく完全解説します。ACID特性・Time Travel・スキーマエボリューション・Z-Order・Liquid Clustering・Auto Compaction・Medallion Architectureといった重要トピックを網羅しているので、Databricks試験対策としてもぜひ活用してください。

Delta Lakeとは

Delta Lakeは、Linux Foundation傘下のオープンソースプロジェクトとして開発されたストレージフレームワークです。従来のデータレイク（Parquet/CSV/JSONファイルの集まり）が抱えていた「データの信頼性の低さ」「スキーマの不整合」「同時書き込みの競合」「ファイル管理の煩雑さ」といった課題を、トランザクションログ（_delta_log）の仕組みで根本的に解決します。

Delta Lakeのデータファイル自体はApache Parquet形式です。Delta Lakeが追加するのはトランザクションログ（JSONおよびCheckpointファイル）であり、このログがすべてのデータ変更操作（INSERT/UPDATE/DELETE/MERGE）を追跡することで、ACIDトランザクション・バージョン管理・データの一貫性を保証します。これにより、データレイクとデータウェアハウスの長所を兼ね備えた「Lakehouse」アーキテクチャが実現されます。

ACIDトランザクション

Delta Lakeの最も重要な特徴のひとつが、データレイク上でのACIDトランザクションのサポートです。ACIDとは、Atomicity（原子性）・Consistency（一貫性）・Isolation（分離性）・Durability（永続性）の4つの特性を指し、従来リレーショナルデータベースでのみ保証されていたトランザクション品質をデータレイク上で実現します。

Atomicity（原子性）

トランザクション内のすべての操作が完全に成功するか、まったく適用されないかのいずれかを保証します。たとえば、大量のデータを書き込む途中でジョブが失敗した場合、中途半端な状態のデータが残ることはありません。トランザクションログにコミットが記録されるまで、変更は可視化されません。

Consistency（一貫性）

スキーマエンフォースメントにより、テーブルに書き込むデータが定義済みのスキーマに適合することを保証します。スキーマに合わないデータが書き込まれようとした場合、Delta Lakeは自動的にエラーを発生させ、データの一貫性を維持します。

Isolation（分離性）

複数のユーザーやジョブが同時にテーブルを読み書きしても、互いの操作が干渉しません。Delta Lakeは楽観的同時実行制御（Optimistic Concurrency Control）を採用しており、読み取り操作は書き込み操作をブロックせず、競合する書き込みは自動的に検出・解決されます。

Durability（永続性）

コミットされたトランザクションは永続的に保存され、システム障害が発生しても失われません。データファイル（Parquet）とトランザクションログの両方がクラウドストレージに保存されるため、高い耐久性が保証されます。

Time Travel

Delta LakeのTime Travel機能は、テーブルの過去のバージョンにアクセスできる機能です。すべてのデータ変更操作がトランザクションログに記録されるため、任意の時点のデータを参照・復元できます。データの誤削除からの復旧、監査・コンプライアンス対応、MLモデルの再現性確保など、さまざまなユースケースで活用されます。

バージョン指定でのアクセス

特定のバージョン番号を指定してデータを読み取ることができます。構文は SELECT * FROM table_name VERSION AS OF version_number です。PySparkでは spark.read.format("delta").option("versionAsOf", version_number).load(path) で同等の操作が可能です。

タイムスタンプ指定でのアクセス

特定の日時を指定してデータを読み取ることもできます。構文は SELECT * FROM table_name TIMESTAMP AS OF '2026-03-01' です。指定した日時以前の最新バージョンのデータが返されます。

バージョン履歴の確認

DESCRIBE HISTORY table_name コマンドで、テーブルの変更履歴（バージョン番号・操作内容・タイムスタンプ・ユーザー情報）を確認できます。RESTORE TABLE構文を使えば、テーブル全体を過去のバージョンに復元することも可能です。なお、VACUUMコマンドで古いデータファイルを削除した場合、そのバージョンのTime Travelは利用できなくなるため注意が必要です。

スキーマエンフォースメントとエボリューション

Delta Lakeは、データの品質を保つための2つの重要なスキーマ管理機能を提供します。

スキーマエンフォースメント

テーブルに書き込むデータのスキーマが既存のテーブルスキーマと一致するかを自動的にチェックする機能です。デフォルトで有効になっており、カラム名・データ型・カラム数が一致しないデータの書き込みを拒否します。これにより、「いつの間にかスキーマが変わっていた」というデータレイクの典型的な問題を防止します。

スキーマエボリューション

スキーマの変更を自動的に受け入れる機能です。書き込み時に .option("mergeSchema", "true") を指定するか、SQLで ALTER TABLE table_name ADD COLUMNS を使うことで、新しいカラムの追加やデータ型の変更を安全に行えます。MERGE INTO文では WHEN NOT MATCHED BY SOURCE と組み合わせて柔軟なスキーマ進化が可能です。

パフォーマンス最適化

Delta Lakeは、クエリパフォーマンスを向上させるための複数の最適化機能を提供しています。大量のデータを扱う実運用環境では、これらの機能を適切に活用することが不可欠です。

OPTIMIZE & Z-Order

OPTIMIZE コマンドは、小さなファイル（Small Files Problem）を統合して大きなファイルにまとめる操作（Compaction）です。多数の小さなファイルが蓄積するとメタデータの処理オーバーヘッドが増大し、クエリ性能が劣化します。OPTIMIZE はこの問題を解決します。

Z-ORDER BY column_name は、指定したカラムの値に基づいてデータを空間的に近い位置に配置するコロケーション手法です。頻繁にフィルタ条件に使用するカラム（日付、地域、ユーザーIDなど）を指定することで、データスキッピングの効果が最大化され、クエリ実行時に読み込むファイル数を大幅に削減できます。構文は OPTIMIZE table_name ZORDER BY (col1, col2) です。

Liquid Clustering

Z-Orderの後継として登場した次世代のデータレイアウト最適化機能です。Z-Orderとの違いは、書き込み時に自動的・増分的にクラスタリングが行われる点です。ALTER TABLE table_name CLUSTER BY (col1, col2) で設定すると、以降の書き込みとOPTIMIZE時に自動的にデータが最適配置されます。Z-Orderは全データを再書き込みする必要がありましたが、Liquid Clusteringは変更されたデータのみを効率的に再配置するため、大規模テーブルでのコストとパフォーマンスが大幅に改善されます。

Auto Compaction & Optimized Writes

Auto Compactionは、書き込み操作の後に自動的に小さなファイルを統合する機能です。手動でOPTIMIZEを実行する頻度を減らせます。Optimized Writesは、書き込み時にパーティション内のファイルサイズを最適化し、小さなファイルの発生自体を抑制する機能です。どちらもテーブルプロパティで有効化でき、Databricksでは多くのケースでデフォルト有効となっています。

VACUUM

VACUUM table_name RETAIN 168 HOURS は、指定した保持期間より古い、現在のテーブルバージョンから参照されていないデータファイルを削除するコマンドです。ストレージコストの削減に使いますが、削除されたファイルに対応するバージョンのTime Travelが利用できなくなる点に注意が必要です。デフォルトの保持期間は168時間（7日間）で、これより短い期間を指定するとデータ破損のリスクがあるため警告が表示されます。

Medallion Architecture

Medallion Architecture（メダリオンアーキテクチャ）は、Delta Lakeを用いたデータレイクのデータ品質を段階的に向上させる設計パターンです。Bronze → Silver → Goldの3層構造で、各レイヤーでデータの品質と構造を段階的に高めていきます。

Bronze層（生データ）

ソースシステムからの生データをそのまま取り込むレイヤーです。「まず生データを安全に保存する」ことが目的で、スキーマの変換やデータクレンジングはこのレイヤーでは行いません。Auto Loaderを使ったクラウドストレージからの増分取り込みや、Change Data Capture（CDC）によるデータベースの変更キャプチャが典型的なパターンです。取り込み日時やソース情報のメタデータカラムを付与しておくと、後続の処理やデバッグに役立ちます。

Silver層（クレンジング・標準化）

Bronze層のデータをクレンジング・標準化・正規化するレイヤーです。重複排除、NULL値処理、データ型の統一、結合処理（JOIN）、フィルタリング（不要レコードの除外）などを行い、分析可能な品質のデータに変換します。エンタープライズレベルのデータとして、複数のビジネスユースケースに対応できる汎用的な構造を目指します。

Gold層（ビジネスレベル集計）

Silver層のデータをビジネス要件に合わせて集計・加工するレイヤーです。KPIダッシュボード用の集計テーブル、MLモデルの特徴量テーブル、レポート用のサマリーテーブルなど、特定のユースケースに最適化されたデータセットを作成します。各Gold層テーブルは通常、特定のビジネスチームやアプリケーションに紐づいています。

問題例

Databricks試験でDelta Lakeに関して出題される形式のサンプル問題を2問掲載します。

よくある質問（FAQ）