Palantir Foundry中为何不建议基于Changelog数据集构建下游数据集？

• 数据一致性无法兜底：changelog是逐次提交的增量变更记录，只存储每次新增、修改、删除的条目，不保留任何时间点的全量数据状态。下游如果直接读取changelog，只要上游某次增量提交出现漏数、重复、字段错误的问题，错误会顺着链路持续传递，后续修复需要从最早的正确时间点开始重放所有changelog，成本极高。而snapshot是对应版本的全量静态快照，数据状态确定，不管之前的增量出过什么问题，只要选定某个校验通过的snapshot版本作为输入，下游输出的结果就是稳定可复现的。
• 事务原子性没有保障：changelog本质是snapshot生成过程中的中间产物，平台不对changelog的读取完整性做事务承诺——读取changelog时有可能刚好撞上上游变更未提交完成的状态，读到半写入的脏数据。而正式发布的snapshot是完全不可变的，平台层面保证读取时要么拿到完整的全量数据，要么直接读取失败，绝对不会出现读取到部分数据的情况。
• 不符合平台治理的链路追溯要求：Foundry的血缘追踪、版本回滚、合规审计、数据质量校验能力，全都是以snapshot版本为锚点设计的。下游如果直接依赖changelog，会直接造成血缘断点：平台没法把读取到的changelog片段对应到正式发布的数据集版本上，后续开展影响面分析、数据回滚、合规举证工作时，根本定位不到输入的具体状态，完全不符合企业级数据治理的基本要求。
• 破坏构建幂等性：changelog是持续追加更新的，如果下游任务运行失败需要重跑，根本没法保证重跑时读到的changelog和第一次运行时读到的内容完全一致——很可能重跑时上游又追加了新的变更，或者旧的changelog片段被清理，导致重跑出来的结果和第一次运行的结果存在差异，数据结果完全不可控。而snapshot一旦生成就不会改动，不管重跑多少次，只要锁定同一个snapshot版本，输入数据完全一致，输出结果也必然一致。

你之前用changelog提升ontology同步效率的场景属于平台特殊适配：ontology同步服务本身内置了偏移量管理、状态持久化、异常回滚的专门逻辑，属于系统级的changelog消费方，自带完整容错机制。普通下游数据集构建任务没有这套专属保障，直接消费changelog就会触发上述所有风险，这也是规范明确要求普通下游必须使用snapshot版本的核心原因。

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