3. Delta Lake存储层核心机制

Delta Lake 是 Databricks 湖仓架构的存储底座。它并没有发明一种全新的文件格式，而是在 Parquet 数据文件之上叠加了一层事务日志（_delta_log），从而把“一堆文件”升级为“一张可事务、可追溯、可约束的表”。理解 Delta 表，关键不是记住 Parquet 怎么存列，而是理解日志如何描述“当前这张表由哪些文件组成、经历了哪些操作”。

一、Delta 表的物理结构

在 Unity Catalog 或 Hive Metastore 中创建一张 Delta 表后，其底层存储目录通常呈现如下结构：

dbfs:/user/hive/warehouse/sales_delta/
├── _delta_log/
│   ├── 00000000000000000000.json
│   ├── 00000000000000000010.json
│   ├── 00000000000000000020.checkpoint.parquet
│   └── _last_checkpoint
├── part-00000-xxxx.snappy.parquet
├── part-00001-xxxx.snappy.parquet
└── part-00002-xxxx.snappy.parquet

其中 _delta_log 是 Delta 的“大脑”。每提交一次写操作，就生成一个以 20 位零填充数字命名的 JSON 文件，例如 00000000000000000010.json，代表版本 10。JSON 中记录的是动作（Action），常见类型包括：

  • metaData：表的 schema、分区列、配置等元信息；
  • add：新增一个数据文件，包含路径、大小、分区值、统计信息（min/max、nullCount）；
  • remove：逻辑删除一个数据文件（文件本身可能仍在存储中，等待 VACUUM 清理）；
  • commitInfo：记录操作类型、时间戳、用户、引擎版本等审计信息；
  • txn、protocol、cdc 等：用于事务标识、协议版本和变更数据捕获。

当版本累积到一定数量（默认每 10 次提交），Delta 会生成 .checkpoint.parquet 检查点文件，把此前所有 JSON 动作压缩成一份快照，避免读取时从头重放全部日志。_last_checkpoint 则指向最近一次检查点，加速表状态重建。

Delta 表物理结构与事务日志读取路径 Parquet 数据文件 part-00000.snappy.parquet part-00001.snappy.parquet part-00002.snappy.parquet part-00003（已 remove） 列式存储 · 不可变文件 删除仅逻辑标记，物理清理靠 VACUUM _delta_log 事务日志 00000000000000000000.json 00000000000000000010.json 00000000000000000020.json …20.checkpoint.parquet 每 10 次提交生成检查点 _last_checkpoint 指向最新快照 动作：metaData / add / remove / commitInfo 表状态重建 1. 读 _last_checkpoint 定位最近检查点 2. 加载 checkpoint 快照 得到基线文件集合 3. 重放后续 JSON 日志 应用 add / remove 4. 得到当前有效文件列表 即“表的最新快照” 描述 解析

二、ACID 事务如何实现

Delta 的 ACID 依赖乐观并发控制。每次写入时，引擎先读取当前最新版本号 N，基于该快照计算要新增和删除哪些文件，然后尝试以“原子方式”创建版本 N+1 的 JSON 日志文件。由于对象存储通常提供“同名文件创建失败”的语义，谁先成功创建 N+1.json，谁就提交成功；其他并发写入者检测到冲突后，会重新读取最新状态并重试，或在无法调和时抛出 ConcurrentAppendException、ConcurrentDeleteReadException 等异常。

这种设计带来几个直接结果：

  • 原子性：一次提交要么完整写入日志，要么完全不生效，不会出现“写了一半”的表；
  • 一致性：读者永远看到某个完整版本的文件集合，不会读到中间态；
  • 隔离性：默认快照隔离，读操作不阻塞写，写操作之间通过冲突检测协调；
  • 持久性：日志一旦落盘，即使后续进程崩溃，表状态仍可恢复。

三、时间旅行：按版本或时间戳查询

因为每个版本都完整记录了文件增删，Delta 天然支持时间旅行。可以用版本号或时间戳两种方式访问历史数据：

-- 按版本号查询
SELECT * FROM sales_delta VERSION AS OF 10;

-- 按时间戳查询（取该时刻之后最近的版本）
SELECT * FROM sales_delta TIMESTAMP AS OF '2025-01-15 10:00:00';

-- 查看表历史
DESCRIBE HISTORY sales_delta;

-- 将表恢复到某个历史版本
RESTORE TABLE sales_delta TO VERSION AS OF 10;

时间旅行的实际价值在于：误删数据后快速回滚、对比不同版本的数据差异、复现某次实验所用的数据快照。需要注意，历史版本依赖对应的数据文件仍然存在；执行 VACUUM 会物理删除超过保留期（默认 7 天）的旧文件，之后这些版本将无法再访问。

四、Schema 演进与约束

Delta 默认允许在写入时自动演进 schema，但需要显式开启。常见做法是在写入时设置 mergeSchema：

df.write \
  .format("delta") \
  .option("mergeSchema", "true") \
  .mode("append") \
  .saveAsTable("sales_delta")

如果新数据多出一列，Delta 会更新 metaData 动作中的 schema，旧文件在该列上读取为 null。也可以使用 ALTER TABLE ... ADD COLUMNS 显式加列，或用 overwriteSchema 整体替换 schema（风险较高，会改变表结构语义）。

与“允许演进”相对的是约束。Delta 支持 NOT NULL 和 CHECK 约束，用来阻止不合格数据写入：

ALTER TABLE sales_delta
  ALTER COLUMN amount SET NOT NULL;

ALTER TABLE sales_delta
  ADD CONSTRAINT amount_positive CHECK (amount > 0);

当写入数据违反约束时，整个事务失败并报错，不会产生部分写入。约束信息同样记录在事务日志中，因此对所有写入路径（SQL、DataFrame、Structured Streaming）一致生效。

实践建议：对需要长期保留历史、支持审计或频繁回滚的事实表，优先使用 Delta；对只做一次性中间计算的临时数据，可用 Parquet 减少日志开销。VACUUM 的保留期要与时间旅行需求匹配，不要为了省空间把保留期设得过短。

五、在 Databricks 中创建与管理 Delta 表

创建 Delta 表最直接的方式是 CTAS 或显式指定格式：

CREATE TABLE IF NOT EXISTS sales_delta (
  order_id   BIGINT,
  customer   STRING,
  amount     DECIMAL(10,2),
  order_date DATE
)
USING DELTA
PARTITIONED BY (order_date)
LOCATION 'dbfs:/user/hive/warehouse/sales_delta';

日常管理中，DESCRIBE DETAIL sales_delta 可查看表的位置、大小、分区数、当前版本；OPTIMIZE sales_delta 用于合并小文件；ZORDER BY (customer) 可对常用过滤列做数据聚簇，提升查询裁剪效率；VACUUM sales_delta RETAIN 168 HOURS 清理过期文件。把这些操作与事务日志、时间旅行、约束机制结合起来理解，就能在实际开发中既享受 Delta 的可靠性，又控制好存储与查询成本。

← 上一章 📖 返回目录 下一章 →