我来结合日常项目里的实际经验，给你梳理下这两个算子的用法和分区优化的思路，刚好你提到的点都是调优时的核心问题～

一、先把repartition和coalesce的核心差异说透 #

你之前的理解方向完全没错，我再补充些落地的细节：

• repartition：不管是增加还是减少分区数，都会触发全量Shuffle——简单说就是所有数据会在集群节点间彻底打散、重新分配。好处是分区后的数据分布会非常均衡，但代价也很明显：Shuffle会消耗大量网络IO和磁盘IO，对集群资源是不小的压力，非必要别随便用。
• coalesce：只能用来减少分区数，默认情况下不会触发全量Shuffle，它会尽量把小分区的数据直接合并到已有分区里（如果非要强制Shuffle，可以加参数shuffle=true，但一般场景完全没必要）。优势是轻量、性能开销小，但如果你的数据原本分布不均，合并后可能还是会出现部分分区数据量偏大的情况，这时候就要权衡取舍了。

二、分区数的计算逻辑（给你补个正确的算法） #

你说的用数据大小算分区数是非常靠谱的思路，不过刚才的计算有点小失误：1TB是1024GB=1048576MB，按128MB的块大小算，应该是1048576 / 128 = 8192个分区。

这里给个通用参考规则：Spark官方推荐每个分区的大小在128MB-256MB之间，这个区间能完美平衡Task并行度和调度开销：

• 如果分区太小（比如几十MB），会导致Task数量暴增，集群调度这些Task的开销会远大于Task本身的执行时间，反而拖慢整体进度；
• 如果分区太大（比如超过512MB），单个Task执行时间太长，不仅容易出现OOM（内存溢出），还会因为单个Task卡住拖慢整个Job的进度。

三、实际场景下的选择技巧 #

什么时候用repartition？ #

1. 需要增加分区数的时候：比如数据经过过滤后，剩余数据量还很大，但分区数变得很少，导致并行度不够，这时候可以用repartition提升分区数，让更多Task并行执行；
2. 减少分区但要求数据分布均衡的时候：如果原本的分区数据量差异很大（比如有的分区100MB，有的1GB），用coalesce合并后还是会有大分区，这时候就可以牺牲一点性能用repartition，换数据分布的均衡性；
3. 按业务字段分区的场景：比如后续要频繁按category字段做聚合，用df.repartition("category")把同类别数据放到同一个分区里，能避免后续聚合时的额外Shuffle。

示例代码：

// 调整到指定分区数
val optimizedDf = df.repartition(8192)
// 按业务字段分区
val groupedByCategoryDf = df.repartition("category")

什么时候用coalesce？ #

当你只是单纯想减少分区数，且数据分布本来就比较均衡的时候：比如经过一系列过滤、聚合后，数据量大幅减少，原来的几千个分区现在每个只有几十MB，这时候用coalesce把分区数降到合理范围，能显著降低调度开销，而且几乎没有性能损耗。

示例代码：

// 把分区数从2000降到500
val compactDf = df.coalesce(500)

四、额外的调优小Tips #

• 先看再调：调整分区前，先用df.rdd.getNumPartitions()查看当前分区数，用df.rdd.glom().map(_.size).collect()查看每个分区的数据量，判断是否真的需要调整；
• 避免小文件：如果输入是大量小文件（比如每个几MB），别直接用repartition，建议先通过spark.sql("INSERT INTO ... SELECT ...")合并成大文件再处理，能减少很多不必要的开销；
• 别盲目加分区：不是分区越多越快，并行度超过集群的核心数后，再多的分区只会增加调度成本，反而变慢。

总的来说，核心就是根据数据量、数据分布、后续计算需求来选择算子，把每个分区大小控制在128-256MB的黄金区间，就能兼顾性能和稳定性啦～