Spark 同一份 DataFrame 执行两次 Action，结果一定相同吗？
本文目录
面试怎么回答
我会从输入版本、计算确定性和物化边界排查。DataFrame通常保存计划，两次Action可能重新执行，源端变化与外部非确定逻辑会影响结果，但具体读取行为要看数据源实现，不能断言每次都自动刷新。需要可复现时，应固定快照或不可变输入并物化校验结果；缓存主要用于复用计算，不能当作多源一致事务。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官追问：“你先count校验，再把同一个DataFrame写出去，为什么校验数量和最终结果对不上？”如果只回答Spark是惰性计算，还差一步：两次执行到底依赖了什么输入？
DataFrame不是天然冻结的结果集；重复计算是否一致，取决于输入快照、表达式确定性和执行边界，缓存不能替代完整的数据版本协议。
同一个变量，不代表同一份已计算结果
DataFrame描述的是数据和计算计划，很多转换要等Action触发才执行。如果没有合适的物化边界，多次Action可能重复执行部分或全部计算。
但不能由此推出“每次Action都会重新发现最新文件”。文件列表、元数据缓存、表格式快照、JDBC读取方式以及计划构建时机，都可能影响实际行为。不同数据源要结合实现和执行计划判断。
因此真正要回答的是：这份计划绑定了哪一个输入版本，哪些内容会在执行时重新获取，失败重试又会读取什么。
输入变化与表达式变化，是两条线
一条线是源数据。比如多个JDBC分区分别建立连接，如果没有额外的一致性安排，它们未必处在同一个数据库快照中；单次Action本身就可能面对跨分区时间差。
另一条线是计算逻辑。自定义函数访问实时规则接口、依赖进程本地状态或自行生成随机值，都可能让相同输入产生不同输出。不能只盯数据文件是否变化。
内置表达式在一个查询或不同查询中的语义也不完全相同，需要按具体函数分析。不要把所有随机或时间函数笼统说成“每行每次都变”，更不要仅凭变量名相同断言结果固定。
cache解决复用，不自动提供源端事务
缓存可以减少重复计算，但声明缓存通常不意味着所有数据已经立刻读完。要考虑首次物化是否完整、哪些分区已缓存，以及块丢失后是否会按血缘重新计算。
若上游不是不可变输入，重新计算能否得到同一版本需要另外保证。把缓存当成稳定快照，会遗漏失败恢复时的边界。
需要可复现的发布批次时，更清晰的做法是固定输入清单或表快照，记录规则版本，将待发布结果写入有明确完成标识的隔离位置，再校验这份结果。只有校验通过的同一版本才能进入正式发布。
检查点或其他持久化机制是否适合，也要按存储可靠性和恢复语义评估；它们不是任意多个外部数据源之间的事务协调器。
一个典型场景：校验和写出读到了不同规则
比如一个假设任务在函数内部查询当前分群规则。第一次count时接口返回旧规则，稍后write触发新计算时，规则已经升级。
最初团队怀疑分区丢失，检查输入文件总数与任务重试日志，却发现两次作业都成功。旧验收只证明源文件到齐，没有保存规则版本，因此无法解释为什么过滤结果发生变化。
修正时把规则预先固定成带版本的输入，让同一发布批次使用同一份规则，同时校验写入隔离区后的实际记录数和关键字段。版本切换发生在新批次，不在一批计算的中途。
如果还有实时源表参与关联，也要明确它的读取边界。只冻结一张规则表，并不等于其他来源都自动冻结。
验收要与发布指向同一个对象
“先数一下，再重新算一遍写出去”最多是两个动作都成功，不一定证明所数的就是所写的。更稳妥的验证应指向同一个物化结果版本，并校验行数、主键、关键聚合和异常样本。
输入版本、代码版本、规则版本与输出批次应能互相追溯。这样出现差异时，才能区分是源数据变化、计算逻辑变化，还是发布过程拿错了版本。
面试里讲到这里，比直接建议加cache更有说服力：你不是只减少了一次计算，而是明确了哪个结果接受验收，以及验收之后它还能不能悄悄变化。
资料与适用边界
机制以所链接版本为准；业务示例用于说明判断方法，不代表作者真实项目或已验证的生产性能。