3. Delta Lake表作为管道基石

在 Databricks 的批流一体管道里，Delta Lake 不是“一种可选的文件格式”，而是承载正确性、可重放性与性能的存储层。它把对象存储上的 Parquet 文件加上一层事务日志（_delta_log），从而在分布式、多写入者的环境中提供 ACID 语义。理解这层日志如何工作，是理解后续 MERGE、Time Travel、OPTIMIZE 与 VACUUM 行为的前提。

ACID 事务：日志即真相

Delta 表的每一次写入都会在 _delta_log 下生成一个 JSON 提交文件（如 00000000000000000010.json），记录本次新增/删除的文件、schema、分区与统计信息。读取时，引擎先读日志再定位数据文件，因此“表”是日志的逻辑视图，而不是目录里所有 Parquet 的简单集合。这带来三点关键能力：

• 原子性：一次 MERGE 或流式微批要么整体可见，要么完全不可见，不会出现“写了一半”的中间状态。
• 隔离性：默认快照隔离，读操作看到的是某个提交点的稳定视图，不会被并发写入撕裂。
• 冲突检测：并发写同一分区时，Delta 基于日志做乐观并发控制，冲突则抛 ConcurrentAppendException 或 ConcurrentDeleteReadException，由上层重试或串行化。

在流场景中，这意味着 Structured Streaming 的 foreachBatch 或 MERGE 写入具备幂等基础：只要业务键与合并条件设计正确，失败重跑不会产生重复行。批场景中，多任务并行写同一张表时，也应优先按分区或业务键拆分，减少冲突概率。

Time Travel：可回滚、可审计、可复现

由于日志保留了历史提交，Delta 支持按版本号或时间戳查询历史快照：

SELECT * FROM orders VERSION AS OF 12;
SELECT * FROM orders TIMESTAMP AS OF '2025-03-01 08:00:00';

Time Travel 在管道中的实际价值有三类。第一，故障回滚：当某次 MERGE 条件写错导致大面积更新时，可用 RESTORE TABLE orders TO VERSION AS OF 11 快速恢复，而不必从上游重跑全量。第二，审计与对账：对比两个版本的聚合结果，定位是哪一批数据引入了偏差。第三，可复现实验：模型训练或报表复算时固定版本，避免“昨天跑和今天跑结果不同”。需要注意的是，Time Travel 依赖数据文件仍然存在，VACUUM 会物理删除旧文件，因此保留窗口必须与合规、回滚需求匹配。

MERGE：批流共用的 Upsert 核心

MERGE 是 Delta 管道中最常用的写入模式，用于按业务键做“存在则更新、不存在则插入”，并可扩展为条件删除。一个典型的订单宽表合并如下：

MERGE INTO orders AS t
USING staged_orders AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.op = 'DELETE' THEN DELETE
WHEN MATCHED THEN UPDATE SET
  t.status = s.status,
  t.amount = s.amount,
  t.updated_at = s.updated_at
WHEN NOT MATCHED THEN INSERT
  (order_id, status, amount, updated_at)
  VALUES (s.order_id, s.status, s.amount, s.updated_at);

在流场景中，通常把 MERGE 放进 foreachBatch，对每个微批的 DataFrame 执行合并，从而实现“流式 Upsert”。这里有两个实践要点：其一，去重。同一微批内若同一 order_id 出现多次，MERGE 可能报“multiple source rows matched”，应先在 source 侧用 dropDuplicates 或窗口取最新。其二，冲突控制。高并发写入时，可对分区键做 OPTIMIZE 或使用分区裁剪，减少需要重写的文件数，从而降低冲突与写放大。

OPTIMIZE 与 VACUUM：性能与成本的平衡

频繁的小批量 MERGE 会产生大量小文件，读取时元数据开销和任务数急剧上升。OPTIMIZE 通过合并小文件来改善布局：

OPTIMIZE orders ZORDER BY (customer_id);
OPTIMIZE orders WHERE dt = '2025-03-01';

ZORDER 让相关数据在文件内聚簇，配合 Delta 的数据跳过（data skipping）可显著减少扫描量，尤其适合按 customer_id、dt 等高频过滤列。对于流式写入，建议按分区或时间窗口定期触发 OPTIMIZE，而不是每微批都执行。

VACUUM 则负责清理不再被日志引用的旧数据文件，默认保留 7 天：

VACUUM orders RETAIN 168 HOURS;
VACUUM orders DRY RUN;

保留期必须大于最长查询时长与 Time Travel 需求，否则正在运行的长查询可能因文件被删而失败。生产上建议先用 DRY RUN 观察待删文件量，再逐步缩短保留窗口。若关闭安全期（spark.databricks.delta.retentionDurationCheck.enabled=false），需自行承担破坏 Time Travel 的风险。

把四件事串成一条管道

在一个典型的订单管道中，可以这样组织：上游 CDC 或事件流写入 staged_orders；每 1 分钟用 foreachBatch 对 orders 执行 MERGE，完成 Upsert；每小时对最近分区执行 OPTIMIZE ... ZORDER BY (customer_id)；每天凌晨执行 VACUUM orders RETAIN 168 HOURS。当发现某次合并错误时，用 RESTORE TABLE orders TO VERSION AS OF N 回滚，再修正逻辑重跑。这样，ACID 保证正确性，Time Travel 提供安全网，MERGE 承担增量合并，OPTIMIZE 与 VACUUM 控制性能与成本，四者共同构成 Delta 表作为管道基石的完整闭环。