Spark累加器与局部变量的差异疑问及代码异常排查

首先，你的观察其实是Spark本地模式下的特殊场景导致的，咱们一步步拆解你的疑问：

1. 为什么累加器和普通counter值完全相同？ #

你配置了master("local[3]")，这是Spark的本地运行模式。在这种模式下，Spark的Executor和Driver是运行在同一个JVM进程里的；再加上你的输入数据量极小（只有9个空行+几行文本），Spark会直接把所有任务放在Driver所在的线程中执行，没有真正将任务分发到独立的Executor节点。

对于普通变量counter来说，正常集群模式下每个Executor都会拿到变量的副本，更新的只是本地副本的值，Driver端的原始变量不会被同步修改；但在本地单进程场景下，所有操作共享同一内存空间，counter +=1的修改直接作用在Driver的变量上，所以最终和累加器的统计结果一致。

如果换成真正的集群模式（比如YARN、Standalone），你会发现counter的值还是初始的0，只有累加器能正确统计到9个空行。

2. 为什么能在转换函数中读取累加器的value？ #

Spark文档强调的是不建议在转换操作中读取累加器的值，且读取结果不可靠，而非完全不能读取。

在转换函数（比如这里的flatMap）里，每个Task都会持有累加器的本地副本。你读取到的cntAccum.value其实是当前Task内累加的局部值，不是Driver端的全局最终值。如果Task因为失败触发重试，这个局部值还会被重复累加，导致最终Driver端的累加器值可能超过实际数量。

你的本地场景下因为Task数量少且没有重试，所以读取到的局部值刚好和全局值一致，但这是特殊情况，生产集群中这种读取行为会导致统计数据不准确。

3. 你的核心理解需要修正的点 #

• 正确规则：累加器的更新应该放在行动操作（Action）中，或者在转换操作中仅用于累加，绝对不要读取其值；只有Driver端在行动操作完成后读取的value，才是可靠的全局统计结果。
• 普通变量在集群模式下，Executor的修改永远不会同步回Driver，只有累加器能保证将各个节点的更新聚合到Driver端。

验证建议 #

你可以做两个测试来验证上述结论：

• 把运行模式改成集群模式（比如提交到YARN集群），运行后会发现counter的值保持0，只有累加器能得到正确的9。
• 扩大输入文件的大小，让Spark启动多个Task，手动触发Task重试（比如杀掉某个Executor进程），你会发现转换函数里读取的cntAccum.value是局部的，且最终累加器的值可能因为重试出现重复计数。

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