目次 › 第1章 › 1-2

第1章 Databricks Intelligence Platform / 想定学習時間:30〜40分 / 最終確認:2026年8月

1-2. Delta Lakeの基礎(ACIDトランザクション・タイムトラベル・スキーマ強制)

1. Delta Lake の実体:Parquet+トランザクションログ

Delta Lake は、クラウドオブジェクトストレージ上のデータレイクに DWH 並みの信頼性を与えるオープンなストレージフォーマットです。その実体は驚くほどシンプルで、次の2つの要素でできています。

テーブルへの書き込みは「新しい Parquet ファイルを追加し、その事実を _delta_log にコミットとして記録する」という形で行われます。読み取り側は必ずログを起点に「現在有効なファイル一覧」を解決するため、書き込み途中の中途半端な状態が読み手に見えることはありません。この仕組みがオープンな標準として公開されているため、Databricks 以外のエンジンからも同じテーブルを読み書きできます。

2. ACID トランザクション:同時読み書きの安全性

トランザクションログがあることで、Delta Lake は ACID 特性を保証します。

実務的に重要なのは、「ETL ジョブがテーブルへ書き込んでいる最中でも、BI ユーザーは直前のコミット時点の一貫したスナップショットを安全に読める」という点です。素の Parquet ファイル群を直接置き換える運用では、この保証がありませんでした。

3. タイムトラベル:過去のバージョンを読む・戻す

すべての変更がログにバージョン付きで残るため、Delta Lake では過去の任意時点のテーブルを読み出す(タイムトラベル)ことができます。

-- バージョン番号で過去の状態を読む
SELECT * FROM main.sales.orders VERSION AS OF 12;

-- タイムスタンプで過去の状態を読む
SELECT * FROM main.sales.orders TIMESTAMP AS OF '2026-08-01T00:00:00';

-- 変更履歴(いつ・誰が・どんな操作をしたか)を確認する
DESCRIBE HISTORY main.sales.orders;

-- 誤った更新をなかったことにして、テーブルを過去バージョンに戻す
RESTORE TABLE main.sales.orders TO VERSION AS OF 12;

• VERSION AS OF / TIMESTAMP AS OF — 過去のスナップショットを読み取る(テーブル自体は変わらない)。誤更新前後の比較や再現性のある分析に使う
• DESCRIBE HISTORY — バージョンごとの操作・実行者・タイムスタンプの一覧。監査証跡として機能する
• RESTORE TABLE — テーブルの現在の状態を過去バージョンの内容に戻す(この操作自体も新しいコミットとして記録される)

4. スキーマ強制とスキーマ進化

Delta Lake はテーブルのスキーマをログに保持し、書き込み時に検証します。

• スキーマ強制(schema enforcement):既定の動作。書き込もうとするデータの列や型がテーブル定義と一致しない場合、書き込みは拒否(エラー)されます。不正データの混入を水際で防ぐ、一貫性(C)の要です。
• スキーマ進化(schema evolution):意図的にスキーマを変えたい場合は、明示的なオプションで許可します。代表が mergeSchema で、新しい列をテーブル定義に追加しながら書き込めます。

# PySpark:ソースに新列 coupon_code が増えたケース
df = spark.read.table("main.staging.new_orders")

# 既定ではスキーマ不一致でエラーになる(スキーマ強制)
# df.write.mode("append").saveAsTable("main.sales.orders")
# => AnalysisException: A schema mismatch detected ...

# 意図的な変更なら mergeSchema で列追加を許可して書き込む(スキーマ進化)
(df.write
   .mode("append")
   .option("mergeSchema", "true")
   .saveAsTable("main.sales.orders"))

5. DML と保守:MERGE / OPTIMIZE / VACUUM

Delta Lake のテーブルには、DWH と同様の DML(UPDATE / DELETE / MERGE)がそのまま使えます。特に MERGE INTO は「あれば更新、なければ挿入(upsert)」を1文で表現でき、増分取り込みの中心的な構文です。

-- テーブル作成(Unity Catalog 配下では既定で Delta 形式)
CREATE TABLE main.sales.orders (
  order_id BIGINT,
  customer_id BIGINT,
  amount DOUBLE,
  updated_at TIMESTAMP
);

-- upsert:order_id が一致すれば更新、なければ挿入
MERGE INTO main.sales.orders AS t
USING main.staging.new_orders AS s
ON t.order_id = s.order_id
WHEN MATCHED THEN
  UPDATE SET t.amount = s.amount, t.updated_at = s.updated_at
WHEN NOT MATCHED THEN
  INSERT (order_id, customer_id, amount, updated_at)
  VALUES (s.order_id, s.customer_id, s.amount, s.updated_at);

また、運用が続くと小さなファイルが増えて読み取り性能が落ちるため、保守コマンドを併用します。

ここまでの仕組みを、書き込みから読み取りまでの流れとして図にまとめます。

練習問題