Delta Lakeとは：Databricksの中核を支えるテーブルフォーマット

レイクハウスの概念を最初に技術として成立させたのが、Delta Lakeです。Databricksが2019年に発表し、いまではLinux Foundationが運営するOSSとして、Databricks以外でも広く使われている。Sparkでの実行性能の高さ、トランザクションログの堅牢さ、運用ノウハウの蓄積で、いまも「最も成熟したテーブルフォーマット」と評価される。

2024年にDelta UniFormというIceberg/Hudi互換機能が登場し、「Deltaで書いて他のフォーマットからも読む」ハイブリッド構成が現実的になりました。実装の中身と運用設計を順に押さえます。

Delta Lakeの基本構造

Deltaのテーブルは「データファイル（Parquet）」と「トランザクションログ（_delta_log）」で構成されます。トランザクションログが、テーブルのすべての変更履歴を持ちます。

トランザクションログは追記専用（append-only）で、コミットされるたびに新しい番号のJSONファイルが追加されます。10コミットごとなどに、過去をまとめたcheckpointが作られ、起動時の読み込みを高速化します。

Delta特有の機能

ACIDトランザクション

-- 複数のINSERT/UPDATE/DELETEを1トランザクションで実行
MERGE INTO orders AS t
USING new_orders AS s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET t.amount = s.amount
WHEN NOT MATCHED THEN INSERT *;

同時書き込みでも整合性が保たれ、失敗時にはロールバックされる。複数のジョブが並行して書き込んでも、トランザクションログが排他制御を行う。

タイムトラベル

-- バージョン指定で過去状態を読む
SELECT * FROM orders VERSION AS OF 42;

-- タイムスタンプで過去時点を読む
SELECT * FROM orders TIMESTAMP AS OF '2026-06-01';

事故が起きた前の状態に戻す、ABテストの一貫性のあるスナップショットを取る、といった運用が標準でできる。

スキーマ進化

-- 新しいカラムを安全に追加
ALTER TABLE orders ADD COLUMN discount_amount DECIMAL(10,2);

-- 書き込み時にスキーマ自動進化を許可
df.write.option("mergeSchema", "true").format("delta").mode("append").save(...)

過去データは新カラムがNULLとして扱われ、整合性を保ったまま進化できる。

Delta UniForm：Iceberg互換読み取り

2024年に登場したDelta UniFormは、「Deltaで書きつつ、Iceberg形式のメタデータも自動生成する」機能です。これにより、Snowflake・BigQuery・TrinoといったIcebergリーダーからも、同じテーブルが読めるようになります。

-- UniFormを有効化したDeltaテーブル
CREATE TABLE orders (
  order_id BIGINT,
  customer_id BIGINT,
  ordered_at TIMESTAMP
)
USING DELTA
TBLPROPERTIES (
  'delta.universalFormat.enabledFormats' = 'iceberg'
);

この機能により、Databricks中心の組織が他のクエリエンジンとも併用しやすくなった。「DatabricksをデフォルトにしつつIceberg互換性も持つ」ハイブリッド戦略の現実解だ。Icebergの詳細はApache Iceberg とはを参照してほしい。

Databricks以外での利用

Delta LakeはOSSなので、Databricks以外でも使えます。主な使い方を挙げます。

「Databricksに依存しないけどDelta Lakeで作りたい」という需要も実は多く、OSS Sparkでの利用は広がっている。Databricks固有の話はDatabricksとはを参照してほしい。

運用上のハマりどころ

• VACUUMによる古いファイルの削除：タイムトラベルのために古いファイルが残り続ける。`VACUUM`で定期的に削除する。デフォルトは7日保持。
• OPTIMIZE（compaction）の頻度：小さなファイルが溜まる前に`OPTIMIZE`を定期実行する。書き込み頻度に応じて調整。
• Z-Orderの選び方：高頻度クエリで使うカラムでZ-Orderを切ると性能が上がる。全カラムでやると逆効果。
• トランザクションログの肥大化：checkpointが正しく作られないと、起動が遅くなる。`delta.checkpointInterval`を見直す。

向く・向かない場面

• 向く：Databricks中心の運用、Sparkでの大規模処理、運用ノウハウの豊富さを重視、機械学習基盤との一体運用、UniFormで他エンジンとも併用したい
• 向かない：完全にベンダー中立を求める（→Iceberg）、極めて更新の多いCDC（→Hudi）、小規模で単一エンジンの簡易要件（テーブルフォーマット自体が不要）

まとめ

• Delta LakeはDatabricks発の、最も成熟したテーブルフォーマット。
• トランザクションログ（_delta_log）で堅牢なACIDを実現。
• タイムトラベル・スキーマ進化・MERGE・Z-Orderなど運用機能が豊富。
• Delta UniFormでIceberg互換読み取りが可能になり、エコシステムが広がった。
• Databricks中心ならまず第一選択。OSS Sparkでも広く使われる。

全体像はレイクハウステーブルフォーマット比較、隣接の選択肢はApache Iceberg とは・Apache Hudi とはにあります。Delta Lakeの導入や設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. DatabricksでないとDelta Lakeは使えませんか？

A. OSSなので使える。OSS Sparkで`delta-spark`パッケージを入れれば、KubernetesやEMR、EKS上のSparkクラスタでも動く。ただし、Databricksの最新機能（Photonエンジンによる高速化、Liquid Clustering、専用UI等）は使えない。OSS Sparkでの利用は機能の世代が1〜2バージョン遅れる点も考慮しよう。

Q. Delta UniFormを有効にすると、どのくらいオーバーヘッドがありますか？

A. 書き込み時にIcebergのメタデータも生成するため、若干の追加コストがある。データ自体は重複生成されず、メタデータだけが追加されるので、ストレージへの影響は小さい。クエリ性能には影響しない。「Iceberg互換性が要らないテーブル」は有効化しなくてよく、必要なテーブルだけ選択的に有効化できる。

Q. VACUUMを実行すると、タイムトラベルは効かなくなりますか？

A. VACUUMは「保持期間より古いファイル」を削除する。デフォルトは7日なので、7日より前へのタイムトラベルはできなくなる。長期保持が必要なら、`delta.deletedFileRetentionDuration`と`delta.logRetentionDuration`を伸ばそう。タイムトラベルとストレージコストはトレードオフなので、業務要件で期間を決める。

Q. Snowflake/BigQueryからDeltaを書き込めますか？

A. 原則として読み取りのみ対応だ。書き込みはDatabricksまたはOSS Spark/Trino/Flink経由が標準。「Snowflakeで書きたい・他からも読みたい」要件なら、Snowflake Native Iceberg Tablesが現実解になる。「どこから書き込み、どこから読むか」のシナリオで、Delta vs Icebergを選択しよう。