repartition和coalesce，终于分清了两者的区别和适用场景。repartition会重新洗牌数据，可以任意增加或减少分区数，适合数据分布不均、需要彻底重新分区的场景，但因为有 Shuffle，性能开销稍大；coalesce不会洗牌数据，只能减少分区数（强行增加分区数无效），直接合并现有分区，性能更高，适合任务后期数据量大幅减少、只需精简分区的场景。实操时用之前的用户数据测试，把初始 10 个分区用repartition(5)和coalesce(5)分别处理，查看执行计划发现，前者有 Shuffle 步骤，后者没有，运行时间也差了近一倍。还学会了根据数据量和集群核心数合理设置分区数，一般按 “核心数 ×2~3” 来定，既不会因分区太少导致任务并行度低，也不会因分区太多增加调度开销。
接着重点解决数据倾斜问题，这是之前跑大数据量任务时遇到的痛点 —— 部分 Task 运行时间特别长，其余 Task 很快完成，导致整个任务卡在最后几步。查资料结合实操，搞懂了数据倾斜的核心原因：某几个 Key 的数据量远大于其他 Key，导致对应分区的任务压力过大。今天试了两种新手易上手的解决方法，效果都很明显：一是随机前缀法，给倾斜 Key 加随机前缀（如 0-9），让原本集中的 Key 分散到不同分区，计算完成后再去掉前缀合并结果，适合聚合类任务；二是过滤倾斜 Key，如果部分倾斜 Key 是无效数据（如空值、异常值），直接用filter过滤，能快速解决问题。实操时针对薪资统计中 “未知城市” 这个倾斜 Key，先加随机前缀做聚合，再合并，原本卡了 5 分钟的任务，调优后 1 分钟就完成了，效果立竿见影。还结合之前学的窗口函数做了调优实操，发现窗口函数的partitionBy字段如果选得不好，也会导致数据倾斜。比如按 “性别” 分区，男女数据量相差悬殊，后续排名任务就会卡顿，换成按 “城市 + 性别” 联合分区后，数据分布均匀，任务执行效率大幅提升。
