Spark reduceByKey 为什么常比 groupByKey 快？所有聚合都能替换吗？
面试怎么回答
如果最终只要每个键的和或计数，我会优先考虑reduceByKey等可合并聚合，它能先在分区内合并，再交换中间结果，减少传输。groupByKey需要保留分组值，适合确实要处理全部明细的情况。替换前必须确认合并函数满足结合与交换要求；平均数要合并总和与数量，不能平均局部平均值，而且局部聚合不代表消除了热点键。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
同样按用户统计访问次数，一份Spark作业先groupByKey再数长度，另一份直接reduceByKey相加。结果看起来一样，为什么前者可能传输和缓存更多数据？
需要可合并结果时，先在分区内缩小数据再跨网络聚合；是否能替换，取决于运算规律和必须保留的信息。
差异先发生在网络传输之前
groupByKey把同一键的值组织到一个分组中。如果每条访问都变成用户ID与数字一，即使最后只想数次数，仍在表达“我要这个用户的所有值”。
reduceByKey则可以把一个分区里同一用户的多个一先加起来，再把局部计数发送到后续聚合。重复键多时，中间记录数量可能大幅减少。
这里讨论Spark 4.0.1的RDD接口，不应把这些名称机械映射为所有SQL计划。DataFrame聚合是否有局部聚合阶段，应通过实际执行计划和运行指标确认。
先明确结果要保留多少信息
计数只需要一个累加值，求和也可以压缩成部分和。若要求输出全部事件明细，一个总和无法还原原记录，就不能直接替换。
下面的简化PySpark逻辑表达的是按键累加计数：
counts = events.map(lambda e: (e.user_id, 1)) \
.reduceByKey(lambda a, b: a + b)平均值不能写成两个数相加再除二并反复合并。假设一个分区一条100，另一个分区九条20，局部平均分别为100和20，简单再平均得到60，全体记录平均却是28。
正确的中间值可以是总和与数量二元组，合并时两项分别相加，最后除法。也可以选适合不同输入输出类型的聚合接口，但选哪个接口不应掩盖中间状态是否充分。
合并顺序不受你随意指定
分布式计算会按不同分区、不同阶段组合数据，因此reduceByKey的函数要满足相应的结合与交换要求。减法、直接取“先来的那个”，不能未经分析就放进去。
如果业务需要最新记录，可以按明确的版本次序选较大者，并处理版本相同的冲突；不能把执行时先后到达当成业务先后。
浮点相加受数值精度影响，改变合并次序可能出现微小尾差。对金额等要求精确的场景，应选合适的数值表示和舍入边界，而不是把数学上的结合律当作机器精度的绝对保证。
一个典型场景：网络下降了，结果却偏了
假设一个平均耗时任务从分组后遍历改为局部平均再合并，运行更快，但结果偏向低流量分区。最初怀疑采样误差，原始记录数量却完全一致。
根因是把局部均值当成等权值合并，丢掉每个分区的样本数量。旧测试让每个分区数据量相近，因此没有暴露权重错误。
修正为合并总耗时和有效样本数，再用不均匀分区验证：一条记录的分区与大量记录的分区同时出现，最终结果应与直接按明细计算一致。
额外加入空输入、无效耗时、单热点键和大数值样本，避免优化只在理想分布下正确。
本地合并不等于没有代价
当几乎每条记录的键都不同，本地无法压缩多少重复信息，聚合状态本身仍消耗内存。键非常多时也可能发生溢写，不能承诺所有数据都会更快。
单个热点键虽然可能从大量原始值缩小为各分区的中间值，但最终仍需要合并。若中间值是不断变长的列表，所谓“局部聚合”可能并没有真正缩小数据体积。
评估优化应同时看输入分布、Shuffle记录数和字节数、溢写、长尾任务及最终结果。只有正确性与实际成本都得到验证，才能把一个API替换称为优化。