Delta Table合并更新操作的日志与数据文件管理问询

核心原理回顾 #

Delta Lake 采用写时复制（Copy-On-Write） 机制处理更新操作，不会直接修改原有数据文件，而是生成包含最新有效数据的新文件，再通过事务日志标记旧文件为失效。

你的场景具体分析 #

Run-1 状态（初始写入） #

• 日志文件：000000.json，包含一条add操作，记录file_1.parquet的路径、记录数等元数据
• 数据文件：file_1.parquet，存储2条初始记录

Run-2 执行Merge-Update后的变化 #

数据文件变化

不会修改file_1.parquet，而是生成1个新的数据文件（比如file_2.parquet），这个文件包含：

• Run-1中未被更新的1条原始记录
• 被更新后的那条记录
• 新插入的1条记录

注：如果原数据文件较大，Delta可能会拆分重写涉及更新的部分文件，但你的场景中原文件只有2条记录，会直接合并所有有效记录生成单个新文件，不会分开为新记录和更新记录生成独立文件。

日志文件变化

只会生成1个新的日志文件000001.json（不会生成000002.json），文件内包含两类事务操作：

1. remove操作：标记file_1.parquet为逻辑删除，记录该文件的路径、版本等信息，后续查询会忽略这个文件
2. add操作：记录新生成的file_2.parquet的路径、记录数、统计信息等元数据，Delta会以此文件作为当前有效数据的来源

Delta Lake通过日志中的add/remove操作序列，维护数据的版本历史，查询时会合并所有未被标记为remove的add操作对应的文件，返回最新的有效数据。

关于提问论坛的说明 #

这个问题适合在Stack Overflow提问，可添加delta-lake、databricks标签；也可以在Databricks官方社区提问，但Stack Overflow是全球通用的技术问答平台，更容易获得广泛的技术解答。

内容的提问来源于stack exchange，提问作者user16798185