Delta表merge操作报java.lang.NullPointerException及归档失效问题求助

merge操作偶发空指针异常问题 #

根因 #

你使用的Databricks Runtime 7.3对应的Delta Lake 0.7.0存在已知缺陷：DeltaMergeBuilder的异常优化逻辑未做空值校验，当merge操作触发乐观锁冲突、元数据访问延迟等非业务异常时，异常解析步骤会直接抛出空指针，掩盖了原始报错信息。你观察到重试可成功，本质是冲突场景（如Delta表乐观锁抢占、S3最终一致性延迟）在重试时已自动消失。

解决办法 #

• 临时规避：每次执行merge前先刷新Delta表元数据，代码示例：

val deltaTable = DeltaTable.forPath(spark, "你的Delta表路径")
deltaTable.refresh()
// 构造Merge逻辑后执行

• 根本修复：升级Databricks Runtime到10.4 LTS及以上版本，该空指针缺陷在Delta Lake 1.2.0之后的版本已被官方修复。

输入文件遗留未归档问题 #

根因 #

Structured Streaming文件源的内置归档逻辑为尽力而为模式，仅在批次执行全成功、checkpoint完成commit后才会触发文件移动。你遇到的merge失败会导致流作业异常终止，此时checkpoint的offset日志已记录本次读取的文件列表，但归档逻辑未执行；后续重试流作业时，会从checkpoint记录的最新offset开始读取，此前已读取但未归档的文件既不会被重复处理，也不会触发归档，就会永久滞留在输入路径。

解决办法 #

• 优先替换内置归档逻辑：放弃依赖流自带的归档能力，在foreachBatch中merge执行成功后，手动移动当前批次的输入文件到归档路径，获取当前批次文件的代码示例：

def mergeFunction(batchDF: DataFrame, batchId: Long): Unit = {
  // 执行merge操作成功后
  val sourceFiles = batchDF.inputFiles
  // 遍历sourceFiles用dbutils.fs.mv或者Hadoop FileSystem API移动到归档路径
}

• 额外兜底逻辑：每次流作业启动前，先扫描输入路径的历史遗留文件，手动加入本次批次的处理范围，避免遗漏。
• 升级Databricks Runtime到10.4 LTS及以上版本，文件源归档逻辑的可靠性已大幅优化。

配置优化建议 #

• 调整spark.sql.shuffle.partitions从32改为16，适配8Worker节点、24并发作业的资源规模，减少小任务开销，降低冲突概率。
• 新增Delta merge重试配置，让框架自动处理乐观锁冲突：

spark.databricks.delta.merge.retryAttempts = 10
spark.databricks.delta.merge.retryIntervalMs = 1000

• 关闭spark.sql.streaming.schemaInference，给文件源显式指定schema，避免偶发schema推断异常导致作业失败。

内容的提问来源于stack exchange，提问作者Antonio González Borrego