一提到RDD分区重置很多Spark开发者第一反应是“这有什么好讲的coalesce减少分区、repartition增加分区呗”。但在实际项目中围绕这两个算子踩过的坑比想象中多得多——有人发现coalesce缩完分区数据更歪了有人用repartition扩分区结果写出几千个碎文件还有人搞不清为什么同一个操作有时候奇快有时候慢到怀疑集群挂了。我打算把这两个算子的源码逻辑、窄依赖与宽依赖的本质、真实场景中的选型判断一次性说清楚顺便分享几个自己调优过程中总结的土办法。这篇内容适合正在做Spark离线任务优化、被数据倾斜或小文件问题折磨过、同时也想搞清楚底层原理的人。看完你能明白什么时候该用coalesce、什么时候必须repartition以及目标分区数到底该怎么拍脑袋才是比较靠谱的拍法。1. 为什么分区数会“出事”并行度、小文件与数据倾斜的连锁反应1.1 分区数如何决定Spark任务的执行效率Spark的并行能力来源于分区。一个RDD分区对应一个任务任务最终被分配到Executor上执行一个Executor核心同一时间只能跑一个任务。分区数量太少核心空闲资源白给分区数量太多每个分区数据量又太小任务调度、结果序列化、网络传输的固定开销被放大执行效率反而下降。这个道理等价于工作分配一个100人的工作量如果只有5个人干活那就是5个人累死如果分成2000个微型任务发给2000个人那大部分时间都浪费在排队领活儿和交活儿上。分区数反映到真实作业里就是“任务在跑多久”和“任务调度占比有多高”之间的一种平衡。更麻烦的是分区数量不是恒定不变的。读HDFS文件时分区数通常跟文件块数量挂钩经过groupByKey、join这类宽依赖算子之后分区数又由Shuffle阶段的分区器决定调用filter过滤掉大量数据后虽然分区数不变但很多分区几乎变成了空壳。这些变化叠加起来常常让最终阶段的RDD分区分布变得很不理想。1.2 三个最典型的分区重置需求我梳理一下日常开发中最常遇到的分区调整场景读入大量小文件场景上游产生了几百上千个小文件Spark默认按照文件块拆分区导致分区数巨大且单个分区数据量极小。这时候需要减少分区数降低调度成本。filter过滤后分区空转场景原始数据1亿条过滤后只剩100万条但分区数依然是1000。大量任务跑了个寂寞读取的数据几乎为空。这时候更适合把分区合并。数据倾斜场景某个key的数据量远超其他key无论分区总数有多少数据总是堆在同一个分区里。这时候不是单纯减少分区能解决的很多时候需要反方向——扩大分区把倾斜的数据“摊开”。发现没有前两个场景的核心诉求是“减”第三个场景的核心诉求往往是“增”。这两个方向虽然都叫分区调整但底层的操作语义完全不同对应的算子自然也不同。1.3 先分清你是要“减”还是要“增”我见过不少初学者拿到coalesce当万能药不管什么情况都先coalesce(100)一下。方向没搞对的时候不仅性能没有提升还可能把原本尚可的数据分布弄得更糟糕。这里先记住一个粗印象默认情况下coalesce只做分区合并不做全局重新洗牌比较适合“减”repartition强制走Shuffle流程可以把分区数量任意增大或减小同时重新分配数据比较适合“增”和“重新均匀化”。至于什么时候选哪个得看具体依赖类型和数据分布第二部分细讲。2. 剖析coalesce与repartition的实现差异源码、依赖类型与shuffle语义2.1 repartition本质上就是coalesce加shuffle这是很多教程里反复提及的一句话与其人云亦云不如自己看一眼源码。RDD类中repartition的实现非常简单def repartition(numPartitions: Int)(implicit ord: Ordering[T] null): RDD[T] withScope { coalesce(numPartitions, shuffle true) }也就是说repartition压根没有自己单独的实现逻辑它就是把coalesce的shuffle参数从默认的false改成了true。搞清楚这点之后很多说法就能对上了为什么repartition既可以增加又可以减少分区因为Shuffle本身就是一次全局的数据打散和重新分配你想切成几份就切成几份。为什么repartition性能开销更大因为它多了一遍完整的Shuffle。因此从语义上讲coalesce(num, shuffle true)和repartition(num)完全等价日常开发中没人会绕圈子写前者但这层关系能帮你理解后面所有行为差异的根基。2.2 coalesce的窄依赖到底做了什么当coalesce(partitionNum, shuffle false)时Spark构建的是一个窄依赖。它的核心思路是尽量在本地合并分区不跨节点移动数据。具体实现上新分区会尽量复用原来位于同一Worker节点上的多个旧分区把它们合并成一个新的逻辑分区。因为数据不需要跨节点搬移所以没有网络IO没有磁盘Shuffle读写执行成本极低。但这个本地合并策略有一个天然缺陷它只是把分区“凑”到一起并没有对数据做全局重新分配。如果原始各分区的数据量已经很不均匀那么合并之后的分区承接的数据量天然也不均匀。极端情况下可能某个新分区里塞了几百GB的数据另一个新分区却几乎是空的。所以coalesce快是真快但它的快是建立在“接受原始数据分布”的前提上的。假如你本来的数据分布就已经歪了用它合并分区只是把好几摊歪的并成一摊更歪的问题丝毫没有解决。2.3 repartition的宽依赖代价在哪里打开repartition的Shuffle流程发生的事就复杂多了。Spark先对RDD中每个元素做一次哈希计算决定它应该落到一个新的分区里然后把数据通过网络传输到对应节点在落地的过程中还可能触发磁盘写读。这一步在DAG中会引入一个宽依赖相当于插入了一个Stage边界。Stage边界意味着上游Stage要等全部任务结束把结果写到Shuffle文件里下游Stage才能启动并拉取数据。这个“全部等一个”的机制天然比窄依赖慢加上网络、磁盘IO整体耗时比coalesce(shufflefalse)高出一个量级。但多付出这么多代价换来的是数据分布的重新均匀化。同样一批数据落在10000个分区里经过repartition(100)之后每个分区理论上承接的数据量就均衡多了。也正是这个特性让它成为解决数据倾斜的基础手段之一。2.4 分区器变化一个容易被漏掉的细节用coalesce做缩减分区时还有一个不太起眼但偶尔会造成性能隐患的细节如果原来的RDD带有HashPartitioner经过coalesce(shuffle false)合并之后分区器信息会丢失变为None。为什么这很重要因为后续如果这个RDD要跟另一个RDD做joinSpark会检查两边的分区器。如果两边的分区器一致且分区数相同Spark可以避免一次Shuffle如果分区器信息丢了或者不一致那就要重新走一遍Shuffle性能直接掉档。如果你确定coalesce之后紧跟着一个需要分区器支撑的操作要么显式调用partitionBy重新指定分区器要么干脆改用repartition让它在Shuffle过程中重建HashPartitioner别让分区器信息在不知不觉中失效。3. 选型指南什么样的场景该用什么算子3.1 缩减分区filter后合并小分区、降低写文件数量缩减分区的核心场景就是数据量变小、分区数偏多。比如读取了一份日志文件经过繁杂的过滤规则后1亿条变成200万条但分区数仍然是1000。此时每个分区只有2000条数据任务密集且每任务执行时间极短调度开销占比反而高。这时候用coalesce把分区数压到100左右是一个性价比很高的操作。再比如最后要写parquet或文本文件落盘如果分区数默认1000就可能输出1000个小文件。小文件是分布式存储和后续查询的噩梦——NameNode压力大、读取速度慢、Spark再读这些文件又会产生大量任务。用coalesce在写之前把分区数推开文件数量会成比例减少效果立竿见影。这里有个细节coalesce合并分区采用的是窄依赖如果原始RDD的每个分区已经相对均衡那么合并后的分区也大体均衡而且整个过程不涉及网络传输速度非常快。所以我判断“该不该用coalesce”前提条件永远是——原始分区之间的数据量差异不大。3.2 扩大分区增加并行度、缓解数据倾斜跟缩减相反当集群资源明明有几百个核心但RDD只有几十个分区大量核心空转这是典型的并行度不足。此时用repartition把分区数扩大到几百能让任务立刻铺开充分利用集群。数据倾斜的场景则更微妙。比如groupByKey之后某个热门key聚集了大量数据那个分区的大小远超其他分区。此时你再怎么扩分区也没有用——关键是让这个聚集了很多数据的key分摊到多个分区中。直接的手段是给key加盐把原始key拆成“key 随机后缀”让原本挤在一个分区里的大key被打散到多个新分区计算完成后再去掉盐。这是repartition配合加盐操作解决倾斜的经典组合拳。需要强调的是在倾斜场景下不要用coalesce(shufflefalse)它只是把分区合并不会改变数据到分区的分配方式大key还是挤在一起白费功夫。3.3 coalesce与repartition对比表对比维度coalescerepartition默认是否Shuffle关闭开启能否增加分区数仅当shuffletrue时可以能否减少分区数可以可以数据是否跨节点移动默认不移动一定跨节点移动数据均衡性继承原始分布可能不均Shuffle后相对更均衡是否有Stage边界默认无有性能开销低几乎无网络IO高有Shuffle读写开销典型场景过滤后合并、减少小文件提高并行度、解决倾斜这张表基本能回答90%的选型问题数据均匀、只需要合并选coalesce数据不均匀、需要重新分配或扩分区选repartition。4. 实测复盘三个真实棘手的Shuffle与分区问题排错4.1 coalesce无法解决倾斜问题的深刻教训有一次我处理一个用户行为日志聚合任务某个头部用户产生的数据量占整体的30%groupByKey之后这个key所在分区的执行时间比其他分区高出十几倍。当时我第一反应是“分区太多导致调度慢”于是把1000个分区coalesce成64个结果跑完发现头部key依然在那一个分区里任务时间一点没降。复盘下来问题很清晰coalesce的本质是本地合并不重新分配倾斜的key压根不会因为合并分区就自动换地方。后来我改成先用加盐逻辑把大key拆开再用repartition(500)重新均匀分配任务耗时才从2小时压到20多分钟。这件事让我养成一个习惯任何一次coalesce之前先看一眼RDD每个分区的数据量到底均不均匀可以通过glom().map(_.length).collect()快速检查分区内容的条数分布再决定合并策略。这是排查倾斜类问题的最快入口。4.2 repartition扩大分区后反而产生海量小文件另一个案例是我曾经为了让下游并发读取更快把一个大RDD从200个分区repartition到5000个然后直接写Parquet。写入倒是顺利但HDFS上多出了5000个小文件。下游用Hive和Spark读这批数据时启动都变慢了实测比原来更糟。问题出在我只考虑了写入端的并行度没考虑文件数量的副作用。对于大多数存储格式写入时的分区数几乎等于输出文件数量分区越多碎文件越多。后来调整策略计算阶段可以临时repartition到较高分区数来充分利用并行度但写入前通过coalesce把分区压回一个合理范围比如目标文件数量控制在几十个以内整体耗时和下游读取性能都更优。这个案例也提醒我repartition不是用越多越好并行度跟输出文件数要分开评估不能拿着一个参数从头用到尾。4.3 spark.sql.shuffle.partitions与手动repartition的冲突还有一个容易混淆的坑来自Spark SQL。SQL任务的Shuffle并行度默认由spark.sql.shuffle.partitions控制默认值200。但RDD API里的repartition跟这个参数完全不相关。如果你在一条数据链路上混用了Spark SQL和RDD算子可能出现两层分区不一致的情况SQL阶段按200个分区写入Shuffle文件后面RDD阶段又repartition(1000)再来一次全量Shuffle执行效率大打折扣。建议是要么统一切到SQL层面通过调整spark.sql.shuffle.partitions来控制全局Shuffle并行度要么坚定地走RDD手动repartition路线不要两层混用更不要对一个结果反复repartition。每多一次Shuffle都是对整个作业执行时间的实打实加码。5. 分区数到底设置为多少我实践中的调整策略5.1 从数据量、Executor资源出发估算目标分区数目标分区数没有绝对公式我一般是两条腿走路。先看数据量与性能参考线。单个分区数据量太大GC压力和序列化时间会上升单个分区太小调度占比又变高。我习惯对标HDFS块大小期望每个分区承载的数据量在64MB到128MB左右。所以如果有10GB数据目标分区数大约就是10GB/128MB向上取整80到160之间。再看集群资源。假设Executor总核心数是100那么有效并行度上限就是100把分区数设成100的整数倍通常没有意义。一般情况下目标分区数控制在总核心数的2到4倍就能获得较好的资源利用率。最终取值建议综合两者取大。5.2 辅助手段partitionBy、预聚合与组合Shuffle有时候repartition并不是唯一手段。对于带Key的PairRDD后续要频繁按Key访问或重复Join与其每次repartition不如直接partitionBy并指定HashPartitioner。这样一次Shuffle建立的“分区键”元数据可以被后续多个操作复用避免反复全量洗牌。处理大表Join时也可以在reduceByKey或aggregateByKey阶段做预聚合把每个分区内的重复Key先合并掉再执行repartition。预聚合会明显减少需要跨节点传输的数据量。你要明白Shuffle的瓶颈通常不在分区数上而在需要搬运的数据量上。数据量减半分区再多也不会慢到哪里去。5.3 最后分享一个调参复查技巧我给任务调分区参数时有一套固定动作第一次跑完打开Spark UI看Stage耗时柱状图重点关注有没有某几个Task明显比其他Task耗时更长。如果有说明分区内数据量不均衡或者某个分区的数据经过了特别重的计算。根据这个观察再去调整分区数和分区方式而不是盲目加核心或加并行度。还有个小习惯是对反复执行的生产任务我会在关键RDD上打日志记录分区数和总条数配合getNumPartitions做基准数据监控。一旦上游数据量大幅变化就能快速判断现有分区参数还合不合理而不是等问题爆发了再排查。这样做之后分区相关的性能问题基本都能在早期发现并处理掉比事后分析Stack Trace舒服得多。分区调整这件事看似只是调一个数字背后却牵连着Shuffle设计、数据分布、任务调度乃至下游存储布局。而coalesce和repartition的选择本质上是你对“代价”和“收益”的一次权衡——是想用低开销接受现状还是愿意多付一次Shuffle的代价把分布彻底捋直。我在项目中反复验证下来最稳妥的做法永远不是记下某个固定答案而是理解每条数据链路的分区演变过程再针对当前瓶颈决定走哪条路。希望这篇内容能帮你把这两个算子的边界彻底想透下次再遇到分区问题少走几步弯路。