Spark专题-第三部分：性能监控与实战优化（2）-分区优化

这一篇不同于之前理论层面的讲解，会直接引入前段时间在工作中发现的问题，并配上思路和解决办法

问题回顾

事情的起因是一个批处理作业，在9月24号当天疯狂报错，原本凌晨就该结束的作业愣是拖到晚上

日志探查

那很自然会想到查看日志，找找报错的原因，这里就会通过之前提到的spark ui查看，也很自然的就能找到图中所提示的报错信息

复制代码

Failure Reason: Job aborted due to stage failure
Task 1 in stage 46.0 failed 4 times
Reason: Couldn't form a bad node; couldn't: ASI, Y15450404805, 1654378, Q0_00043
compute-node-ZR1002T7.mm-sgps.com
Error code: I4E

这种类型的报错通常属于网络通信 或资源管理类问题
网络通信错误节点间连接超时防火墙/安全组限制 DNS解析失败网络分区 executor与driver失联端口被阻止主机名无法解析集群节点隔离

python 复制代码

resource_issues = [
    "内存不足导致GC overhead",
    "磁盘空间耗尽",
    "CPU资源竞争激烈", 
    "网络带宽瓶颈",
    "容器资源限制触发"
]

但如果是网络原因，不会只有这一个作业异常，于是我们便初步怀疑是资源不足导致的，而这些猜想需要继续通过spark ui找证据。

因为作业是通过提交spark sql的方式提交，所以我们当时想知道是哪段sql导致的报错，于是便去查看了SQL/DataFrame菜单，找到失败的语句

一路顺着数据流程往下找，发现了两个可疑的地方

14个亿的数据量，却只安排了2个partition处理，累死也算不出来
到sort算子部分就停止了
那此时的问题可能就出现在，用很少的分区去对极大的数据量进行排序，导致资源不足，出现报错

sql验证

当从日志里找出这些蛛丝马迹后，就该看看实际执行的sql能否和这些猜想对应上

sql 复制代码

where day between today(-2) and today(-1)
cluster by  day

从执行的sql里，我们发现了这样一句，每天会更新最近2天的数据，所以day值只会有2个，而cluster by day 这句就是罪魁祸首了，将14亿的数据按2个day分组，调用sort算子，导致资源不足作业失败

性能优化

定位问题后，一切就好解决了，直接将最后一句改成

sql 复制代码

DISTRIBUTE BY day, ceil(rand() * 100)

虽然还是2个day，但通过ceil(rand() * 100) 起到稀释加盐的作用，将数据打散，优化后再查看日志就会发现这里的分区数已经变大，作业也就顺利执行完成