Delta Lake In-Commit Timestamps 协议详解让 TIMESTAMP AS OF 时间旅行摆脱文件系统时间戳的不可靠性【免费下载链接】deltaAn open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs项目地址: https://gitcode.com/GitHub_Trending/del/delta导读本文围绕 Delta Lake 的inCommitTimestampsWriter 表特性In-Commit Timestamps下文简称 ICT展开完整解读其协议设计、启用条件、写入端与读取端规则并结合当前仓库 protocol_rfcs/accepted/in-commit-timestamps.md 与 Spark 侧实现源码讲清楚commit 元数据内嵌单调递增时间戳是如何让TIMESTAMP AS OF时间旅行在文件系统操作篡改 commit 文件修改时间时依然可靠。读完本文你将掌握 ICT 的三个核心表属性、启用/停用操作、启用信息追踪语义以及读取端与时间旅行必须遵守的分段规则。一、问题背景为什么需要 In-Commit Timestamps在传统 Delta 协议中一个 commit 的提交时间取自 Delta 日志文件_delta_log/下的00000000000000000000.json等在文件系统上的修改时间file modification time。这一设计依赖一个隐含假设commit 文件的修改时间能够真实反映提交发生的时间。但在真实生产环境中这个假设并不总是成立将 Delta 表从对象存储 A 复制/迁移到对象存储 B如跨 S3 bucket 同步、跨云迁移时目标文件的时间戳可能会被重置为复制操作的执行时间使用 HDFS、本地文件系统时touch类操作或文件系统元数据重建可能批量改写文件修改时间备份恢复、冷热分层归档再取回等流程也可能破坏原有时间戳。一旦 commit 文件的修改时间失真基于时间戳的TIMESTAMP AS OF时间旅行就会产生错误结果要么选错快照版本要么因为时间戳前后颠倒而无法解析。In-Commit Timestamps 特性的核心思路非常直接把提交时间从文件系统元数据中解放出来作为inCommitTimestamp字段直接写进 commit 的元数据commitInfoaction中并由协议强制保证该时间戳单调递增。这样即使文件系统时间戳被篡改提交时间的语义依然稳定、可依赖。二、协议变更总览ICT 在 Delta 协议中的位置该特性是一份已接受的协议 RFC位于 protocol_rfcs/accepted/in-commit-timestamps.md对 Delta 协议文档PROTOCOL.md做了三处修改Commit Provenance Information 小节修订commitInfoaction 的约束新增启用 ICT 时写入端必须附带inCommitTimestamp字段的要求Reader Requirements for AddCDCFile 小节修订_commit_timestamp列的取值来源规则新增 In-Commit Timestamps 小节完整定义启用条件、写入端要求与读取端建议。2.1 Commit Provenance InformationcommitInfo 的契约变化commitInfoaction 承载一个提交的高层操作来源信息谁执行、执行了什么操作实现方本可以自由写入任意合法的 JSON 对象字面量。协议在此处追加了一条限制除非某些表特性例如 In-Commit Timestamps对数据提出额外要求实现方可自由存储任意合法 JSON 对象作为commitInfoaction。即当 ICT 启用后写入端必须在每一次 commit 中都附带一个commitInfoaction且该 action 必须包含inCommitTimestamp字段。在 Spark 侧的CommitInfo实现中该字段被建模为Option[Long]并配套getCommitTimestamp访问器——当 ICT 启用但字段缺失时会直接抛出missingCommitTimestamp异常见 actions.scala从实现上保证了启用即必须写入这一协议约束。2.2 启用条件三个缺一不可的前提协议明确规定启用 ICT 需要同时满足条件说明表协议版本表必须处于Writer Version 7表特性注册特性名inCommitTimestamps必须存在于表protocol的writerFeatures中表属性表属性delta.enableInCommitTimestamps必须设置为true在 Spark 实现中InCommitTimestampTableFeature是一个Writer Feature且属于由元数据自动启用FeatureAutomaticallyEnabledByMetadata类型只要元数据中的delta.enableInCommitTimestampstrue协议便会自动把该特性加入writerFeatures并在建表或修改属性时自动升级 Writer 版本见 TableFeature.scala。这意味着对普通用户而言只需设置一个表属性即可完成启用协议升级是自动的。三、写入端要求Writer Requirements当 ICT 启用后协议对每一次 commit 施加了 5 条硬性要求必须写commitInfoaction每一次提交都必须包含commitInfocommitInfo必须是 commit 中的第一个 action它必须排在add、remove、metaData、protocol等其他 action 之前inCommitTimestamp字段类型为long毫秒精度Unix epoch 起算表示该 commit 被认为成功提交的时刻其取值是以下两者中的较大者写入端尝试提交时的时刻毫秒上一个 commit 的inCommitTimestamp加 1 毫秒。这一取较大值的规则正是单调递增的保证来源启用信息追踪如果表中存在特性未启用时期的历史 commit必须在表属性中记录启用时的位置信息详见下一节启用 commit 的时间戳要求启用该特性那一次 commit 的inCommitTimestamp必须大于其紧邻前一个 commit 的文件修改时间从而保证新旧时间基准平滑衔接。3.1 源码印证写入路径如何生成时间戳在 Spark 实现中上述规则体现在OptimisticTransaction的提交路径上。commit 开始尝试时写入端记录commitAttemptStartTimeMillis取系统当前时间并调用generateInCommitTimestampForFirstCommitAttempt生成首轮尝试的inCommitTimestamp见 OptimisticTransaction.scala。冲突重试场景下并发写导致事务被拒绝后重新尝试时间戳会进一步与已获胜 commit 的inCommitTimestamp比较确保最终写盘的数值严格大于历史上所有已提交版本——这正是协议第 3 条取较大者语义的工程化落地。四、启用信息追踪两张历史分界表属性ICT 允许在表生命中途才启用因此协议必须解决一个关键问题如何区分有inCommitTimestamp的 commit和没有该字段的老 commit答案是一对配套表属性表属性类型语义delta.inCommitTimestampEnablementVersionLong启用 ICT 时表的版本号delta.inCommitTimestampEnablementTimestampLong与启用那次 commit 的inCommitTimestamp相同二者的配套关系是启用 commit 的版本 该 commit 的inCommitTimestamp。注意协议约定启用 commit 的inCommitTimestamp必须大于紧邻前一个 commit 的文件修改时间正是为了让分界线两侧的时间基准不会出现倒挂。4.1 源码印证启用信息如何写进元数据Spark 侧的工具类 InCommitTimestampUtils.scala 完整实现了这套逻辑didCurrentTransactionEnableICT通过对比当前事务的元数据与前一版本元数据判断本次提交是否新启用了 ICT利用前一版本中delta.enableInCommitTimestamps是否为 truegetUpdatedMetadataWithICTEnablementInfo若本次提交新启用 ICT 且提交版本不为 0版本 0 时日志中还没有无 ICT 的 commit无需记录分界信息则将inCommitTimestampEnablementVersion与inCommitTimestampEnablementTimestamp写入表元数据的configuration特别地针对REPLACE/CLONE这类会重建元数据的命令实现还提供了保留既有启用信息的修复逻辑避免启用信息被意外丢弃由spark.conf中的spark.databricks.delta.inCommitTimestamp.retainEnablementInfoFix.enabled控制见 DeltaSQLConf.scalagetValidatedICTEnablementInfo读取并校验两条启用信息要求二者同时存在或同时不存在否则抛出IllegalStateException。三个相关表属性在 DeltaConfig.scala 中统一定义delta.enableInCommitTimestamps默认false、delta.inCommitTimestampEnablementVersion默认无、delta.inCommitTimestampEnablementTimestamp默认无。五、读取端要求与规则Reader Requirements协议给读取端提供的不是强制要求而是建议Recommendations但其规则相当精确核心目标是为每个 commit 确定唯一的、正确的提交时间戳。5.1 确定单个 commit 的时间戳对于启用了 ICT 的表读取端应使用inCommitTimestamp作为 commit 时间戳用于时间旅行和DESCRIBE HISTORY查看表历史等操作。若表中存在启用前的历史 commit则借助两条启用信息按版本分界版本 delta.inCommitTimestampEnablementVersion的 commit使用commitInfoaction 中的inCommitTimestamp字段版本 delta.inCommitTimestampEnablementVersion的 commit回退到文件修改时间。5.2 执行 TIMESTAMP AS OF 时间旅行时的查询范围当读取端需要按时间 X 获取表状态时协议进一步规定候选版本的裁剪规则若timestamp Xdelta.inCommitTimestampEnablementTimestamp只考虑版本 delta.inCommitTimestampEnablementVersion的表版本否则只考虑版本 delta.inCommitTimestampEnablementVersion的表版本。这条规则避免了跨分界线的无效搜索ICT 启用时间戳大于启用前的所有文件修改时间因此在分界点之后任何早于分界时间的 commit 都不可能包含在 ICT 区间内。5.3 源码印证历史与时间旅行的双路径实现Spark 的 DeltaHistoryManager.scala 严格按协议实现了getHistory的双段合并逻辑当 ICT 启用时先取出启用版本ictEarliest将历史拆成[start, ictEarliest-1]用文件修改时间与[ictEarliest, end]用inCommitTimestamp两段分别读取再合并成倒序结果。时间旅行侧的getActiveCommitAtTimeDeltaHistoryManager.scala则对应 5.2 的二分规则先比较请求时间与启用时间戳决定走ICT 区间搜索getActiveCommitAtTimeFromICTRange还是非 ICT 区间搜索getCommitFromNonICTRange并配合parallelSearch在大区间上并行查找兼顾正确性与性能。5.4 CDC 读取器的配套变更协议还对 Change Data Feed 的读取器做了同步修订。_commit_timestamp列的取值来源从Delta 日志文件的修改时间变更为取决于是否启用 In-Commit Timestamps启用时取自该版本 Delta 日志中commitInfoaction 的inCommitTimestamp字段否则取自 Delta 日志文件的修改时间。_commit_version列仍从 Delta 日志文件名推导Long类型。也就是说CDC 消费端拿到的时间戳语义与主读取路径完全一致。六、实操在表上启用 / 停用 ICT以下操作均基于当前仓库 Spark 模块的实际行为验证用例见 DeltaProtocolVersionSuite.scala。6.1 建表时启用CREATE TABLE delta./path/to/table (id bigint) USING delta TBLPROPERTIES (delta.enableInCommitTimestamps true)建表后protocol中的writerFeatures会自动包含inCommitTimestamp由元数据自动启用特性保证且automaticallyUpdateProtocolOfExistingTables trueWriter 版本会自动提升到 7。6.2 对已有表启用ALTER TABLE delta./path/to/table SET TBLPROPERTIES ( delta.enableInCommitTimestamps true )此时协议会为表记录启用信息下一个 commit 的版本写入delta.inCommitTimestampEnablementVersion该 commit 的inCommitTimestamp写入delta.inCommitTimestampEnablementTimestamp且该值会被强制大于其前一版本 commit 的文件修改时间。6.3 停用与特性移除根据特性实现TableFeature.scala停用只需将表属性置为falseALTER TABLE delta./path/to/table SET TBLPROPERTIES ( delta.enableInCommitTimestamps false )若需彻底从writerFeatures中移除该特性可执行ALTER TABLE ... DROP FEATURE inCommitTimestamp。测试用例drop InCommitTimestamp系列验证了移除特性后enableInCommitTimestamps与两条启用信息属性会被一并清理且清理行为遵循启用属性与启用版本/时间戳属性独立存在的边界条件。6.4 注意事项若在表已包含无 ICT 历史 commit 时才启用两条启用信息属性必须成对出现读取端遇到只出现其一的情况会视为损坏状态并抛异常ICT 只改变commit 时间戳的获取来源不改变时间旅行本身如VERSION AS OF按版本查询的语义对历史 commit 的DESCRIBE HISTORY、CDC 消费等场景时间戳来源会按 5.1 / 5.4 的规则自动切换无需用户感知。七、总结可靠时间旅行的协议基石In-Commit Timestamps 用一份写入 commit 元数据的单调递增时间戳化解了文件系统时间戳不可靠这一长期痛点对写入端要求每个 commit 附带commitInfo且必须包含inCommitTimestamp通过取当前时间与前值 1ms 的较大者保证全局单调对读取端借助delta.inCommitTimestampEnablementVersion/delta.inCommitTimestampEnablementTimestamp划定新旧时间基准的分界线统一了DESCRIBE HISTORY、TIMESTAMP AS OF与 CDC 的时间语义对生态作为 Writer 特性它在协议层面Writer Version 7可被所有遵循规范的引擎共同遵守为跨引擎的 Lakehouse 架构提供一致的时间旅行体验。如果你正在维护跨存储复制的 Delta 表或曾为时间旅行结果随文件复制而漂移所困扰delta.enableInCommitTimestamps true就是协议层给出的标准答案。深入理解本文涉及的 协议 RFC 与 写入端实现即可在任何实现 Delta 协议的引擎上正确落地该特性。【免费下载链接】deltaAn open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs项目地址: https://gitcode.com/GitHub_Trending/del/delta创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Delta Lake In-Commit Timestamps 协议详解：让 TIMESTAMP AS OF 时间旅行摆脱文件系统时间戳的不可靠性
Delta Lake In-Commit Timestamps 协议详解让 TIMESTAMP AS OF 时间旅行摆脱文件系统时间戳的不可靠性【免费下载链接】deltaAn open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs项目地址: https://gitcode.com/GitHub_Trending/del/delta导读本文围绕 Delta Lake 的inCommitTimestampsWriter 表特性In-Commit Timestamps下文简称 ICT展开完整解读其协议设计、启用条件、写入端与读取端规则并结合当前仓库 protocol_rfcs/accepted/in-commit-timestamps.md 与 Spark 侧实现源码讲清楚commit 元数据内嵌单调递增时间戳是如何让TIMESTAMP AS OF时间旅行在文件系统操作篡改 commit 文件修改时间时依然可靠。读完本文你将掌握 ICT 的三个核心表属性、启用/停用操作、启用信息追踪语义以及读取端与时间旅行必须遵守的分段规则。一、问题背景为什么需要 In-Commit Timestamps在传统 Delta 协议中一个 commit 的提交时间取自 Delta 日志文件_delta_log/下的00000000000000000000.json等在文件系统上的修改时间file modification time。这一设计依赖一个隐含假设commit 文件的修改时间能够真实反映提交发生的时间。但在真实生产环境中这个假设并不总是成立将 Delta 表从对象存储 A 复制/迁移到对象存储 B如跨 S3 bucket 同步、跨云迁移时目标文件的时间戳可能会被重置为复制操作的执行时间使用 HDFS、本地文件系统时touch类操作或文件系统元数据重建可能批量改写文件修改时间备份恢复、冷热分层归档再取回等流程也可能破坏原有时间戳。一旦 commit 文件的修改时间失真基于时间戳的TIMESTAMP AS OF时间旅行就会产生错误结果要么选错快照版本要么因为时间戳前后颠倒而无法解析。In-Commit Timestamps 特性的核心思路非常直接把提交时间从文件系统元数据中解放出来作为inCommitTimestamp字段直接写进 commit 的元数据commitInfoaction中并由协议强制保证该时间戳单调递增。这样即使文件系统时间戳被篡改提交时间的语义依然稳定、可依赖。二、协议变更总览ICT 在 Delta 协议中的位置该特性是一份已接受的协议 RFC位于 protocol_rfcs/accepted/in-commit-timestamps.md对 Delta 协议文档PROTOCOL.md做了三处修改Commit Provenance Information 小节修订commitInfoaction 的约束新增启用 ICT 时写入端必须附带inCommitTimestamp字段的要求Reader Requirements for AddCDCFile 小节修订_commit_timestamp列的取值来源规则新增 In-Commit Timestamps 小节完整定义启用条件、写入端要求与读取端建议。2.1 Commit Provenance InformationcommitInfo 的契约变化commitInfoaction 承载一个提交的高层操作来源信息谁执行、执行了什么操作实现方本可以自由写入任意合法的 JSON 对象字面量。协议在此处追加了一条限制除非某些表特性例如 In-Commit Timestamps对数据提出额外要求实现方可自由存储任意合法 JSON 对象作为commitInfoaction。即当 ICT 启用后写入端必须在每一次 commit 中都附带一个commitInfoaction且该 action 必须包含inCommitTimestamp字段。在 Spark 侧的CommitInfo实现中该字段被建模为Option[Long]并配套getCommitTimestamp访问器——当 ICT 启用但字段缺失时会直接抛出missingCommitTimestamp异常见 actions.scala从实现上保证了启用即必须写入这一协议约束。2.2 启用条件三个缺一不可的前提协议明确规定启用 ICT 需要同时满足条件说明表协议版本表必须处于Writer Version 7表特性注册特性名inCommitTimestamps必须存在于表protocol的writerFeatures中表属性表属性delta.enableInCommitTimestamps必须设置为true在 Spark 实现中InCommitTimestampTableFeature是一个Writer Feature且属于由元数据自动启用FeatureAutomaticallyEnabledByMetadata类型只要元数据中的delta.enableInCommitTimestampstrue协议便会自动把该特性加入writerFeatures并在建表或修改属性时自动升级 Writer 版本见 TableFeature.scala。这意味着对普通用户而言只需设置一个表属性即可完成启用协议升级是自动的。三、写入端要求Writer Requirements当 ICT 启用后协议对每一次 commit 施加了 5 条硬性要求必须写commitInfoaction每一次提交都必须包含commitInfocommitInfo必须是 commit 中的第一个 action它必须排在add、remove、metaData、protocol等其他 action 之前inCommitTimestamp字段类型为long毫秒精度Unix epoch 起算表示该 commit 被认为成功提交的时刻其取值是以下两者中的较大者写入端尝试提交时的时刻毫秒上一个 commit 的inCommitTimestamp加 1 毫秒。这一取较大值的规则正是单调递增的保证来源启用信息追踪如果表中存在特性未启用时期的历史 commit必须在表属性中记录启用时的位置信息详见下一节启用 commit 的时间戳要求启用该特性那一次 commit 的inCommitTimestamp必须大于其紧邻前一个 commit 的文件修改时间从而保证新旧时间基准平滑衔接。3.1 源码印证写入路径如何生成时间戳在 Spark 实现中上述规则体现在OptimisticTransaction的提交路径上。commit 开始尝试时写入端记录commitAttemptStartTimeMillis取系统当前时间并调用generateInCommitTimestampForFirstCommitAttempt生成首轮尝试的inCommitTimestamp见 OptimisticTransaction.scala。冲突重试场景下并发写导致事务被拒绝后重新尝试时间戳会进一步与已获胜 commit 的inCommitTimestamp比较确保最终写盘的数值严格大于历史上所有已提交版本——这正是协议第 3 条取较大者语义的工程化落地。四、启用信息追踪两张历史分界表属性ICT 允许在表生命中途才启用因此协议必须解决一个关键问题如何区分有inCommitTimestamp的 commit和没有该字段的老 commit答案是一对配套表属性表属性类型语义delta.inCommitTimestampEnablementVersionLong启用 ICT 时表的版本号delta.inCommitTimestampEnablementTimestampLong与启用那次 commit 的inCommitTimestamp相同二者的配套关系是启用 commit 的版本 该 commit 的inCommitTimestamp。注意协议约定启用 commit 的inCommitTimestamp必须大于紧邻前一个 commit 的文件修改时间正是为了让分界线两侧的时间基准不会出现倒挂。4.1 源码印证启用信息如何写进元数据Spark 侧的工具类 InCommitTimestampUtils.scala 完整实现了这套逻辑didCurrentTransactionEnableICT通过对比当前事务的元数据与前一版本元数据判断本次提交是否新启用了 ICT利用前一版本中delta.enableInCommitTimestamps是否为 truegetUpdatedMetadataWithICTEnablementInfo若本次提交新启用 ICT 且提交版本不为 0版本 0 时日志中还没有无 ICT 的 commit无需记录分界信息则将inCommitTimestampEnablementVersion与inCommitTimestampEnablementTimestamp写入表元数据的configuration特别地针对REPLACE/CLONE这类会重建元数据的命令实现还提供了保留既有启用信息的修复逻辑避免启用信息被意外丢弃由spark.conf中的spark.databricks.delta.inCommitTimestamp.retainEnablementInfoFix.enabled控制见 DeltaSQLConf.scalagetValidatedICTEnablementInfo读取并校验两条启用信息要求二者同时存在或同时不存在否则抛出IllegalStateException。三个相关表属性在 DeltaConfig.scala 中统一定义delta.enableInCommitTimestamps默认false、delta.inCommitTimestampEnablementVersion默认无、delta.inCommitTimestampEnablementTimestamp默认无。五、读取端要求与规则Reader Requirements协议给读取端提供的不是强制要求而是建议Recommendations但其规则相当精确核心目标是为每个 commit 确定唯一的、正确的提交时间戳。5.1 确定单个 commit 的时间戳对于启用了 ICT 的表读取端应使用inCommitTimestamp作为 commit 时间戳用于时间旅行和DESCRIBE HISTORY查看表历史等操作。若表中存在启用前的历史 commit则借助两条启用信息按版本分界版本 delta.inCommitTimestampEnablementVersion的 commit使用commitInfoaction 中的inCommitTimestamp字段版本 delta.inCommitTimestampEnablementVersion的 commit回退到文件修改时间。5.2 执行 TIMESTAMP AS OF 时间旅行时的查询范围当读取端需要按时间 X 获取表状态时协议进一步规定候选版本的裁剪规则若timestamp Xdelta.inCommitTimestampEnablementTimestamp只考虑版本 delta.inCommitTimestampEnablementVersion的表版本否则只考虑版本 delta.inCommitTimestampEnablementVersion的表版本。这条规则避免了跨分界线的无效搜索ICT 启用时间戳大于启用前的所有文件修改时间因此在分界点之后任何早于分界时间的 commit 都不可能包含在 ICT 区间内。5.3 源码印证历史与时间旅行的双路径实现Spark 的 DeltaHistoryManager.scala 严格按协议实现了getHistory的双段合并逻辑当 ICT 启用时先取出启用版本ictEarliest将历史拆成[start, ictEarliest-1]用文件修改时间与[ictEarliest, end]用inCommitTimestamp两段分别读取再合并成倒序结果。时间旅行侧的getActiveCommitAtTimeDeltaHistoryManager.scala则对应 5.2 的二分规则先比较请求时间与启用时间戳决定走ICT 区间搜索getActiveCommitAtTimeFromICTRange还是非 ICT 区间搜索getCommitFromNonICTRange并配合parallelSearch在大区间上并行查找兼顾正确性与性能。5.4 CDC 读取器的配套变更协议还对 Change Data Feed 的读取器做了同步修订。_commit_timestamp列的取值来源从Delta 日志文件的修改时间变更为取决于是否启用 In-Commit Timestamps启用时取自该版本 Delta 日志中commitInfoaction 的inCommitTimestamp字段否则取自 Delta 日志文件的修改时间。_commit_version列仍从 Delta 日志文件名推导Long类型。也就是说CDC 消费端拿到的时间戳语义与主读取路径完全一致。六、实操在表上启用 / 停用 ICT以下操作均基于当前仓库 Spark 模块的实际行为验证用例见 DeltaProtocolVersionSuite.scala。6.1 建表时启用CREATE TABLE delta./path/to/table (id bigint) USING delta TBLPROPERTIES (delta.enableInCommitTimestamps true)建表后protocol中的writerFeatures会自动包含inCommitTimestamp由元数据自动启用特性保证且automaticallyUpdateProtocolOfExistingTables trueWriter 版本会自动提升到 7。6.2 对已有表启用ALTER TABLE delta./path/to/table SET TBLPROPERTIES ( delta.enableInCommitTimestamps true )此时协议会为表记录启用信息下一个 commit 的版本写入delta.inCommitTimestampEnablementVersion该 commit 的inCommitTimestamp写入delta.inCommitTimestampEnablementTimestamp且该值会被强制大于其前一版本 commit 的文件修改时间。6.3 停用与特性移除根据特性实现TableFeature.scala停用只需将表属性置为falseALTER TABLE delta./path/to/table SET TBLPROPERTIES ( delta.enableInCommitTimestamps false )若需彻底从writerFeatures中移除该特性可执行ALTER TABLE ... DROP FEATURE inCommitTimestamp。测试用例drop InCommitTimestamp系列验证了移除特性后enableInCommitTimestamps与两条启用信息属性会被一并清理且清理行为遵循启用属性与启用版本/时间戳属性独立存在的边界条件。6.4 注意事项若在表已包含无 ICT 历史 commit 时才启用两条启用信息属性必须成对出现读取端遇到只出现其一的情况会视为损坏状态并抛异常ICT 只改变commit 时间戳的获取来源不改变时间旅行本身如VERSION AS OF按版本查询的语义对历史 commit 的DESCRIBE HISTORY、CDC 消费等场景时间戳来源会按 5.1 / 5.4 的规则自动切换无需用户感知。七、总结可靠时间旅行的协议基石In-Commit Timestamps 用一份写入 commit 元数据的单调递增时间戳化解了文件系统时间戳不可靠这一长期痛点对写入端要求每个 commit 附带commitInfo且必须包含inCommitTimestamp通过取当前时间与前值 1ms 的较大者保证全局单调对读取端借助delta.inCommitTimestampEnablementVersion/delta.inCommitTimestampEnablementTimestamp划定新旧时间基准的分界线统一了DESCRIBE HISTORY、TIMESTAMP AS OF与 CDC 的时间语义对生态作为 Writer 特性它在协议层面Writer Version 7可被所有遵循规范的引擎共同遵守为跨引擎的 Lakehouse 架构提供一致的时间旅行体验。如果你正在维护跨存储复制的 Delta 表或曾为时间旅行结果随文件复制而漂移所困扰delta.enableInCommitTimestamps true就是协议层给出的标准答案。深入理解本文涉及的 协议 RFC 与 写入端实现即可在任何实现 Delta 协议的引擎上正确落地该特性。【免费下载链接】deltaAn open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs项目地址: https://gitcode.com/GitHub_Trending/del/delta创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考