【大数据实战案例】解决由手机号缺失引发的数据倾斜，提速10倍

一、引入

本文总结一个数据倾斜的问题，该问题由 SQL 函数row_number()对手机号分组时引发，做数仓开发的同学在在业务实战过程中，或许会遇到过。

先简单介绍一下什么是数据倾斜和为什么会造成数据倾斜。
数据倾斜是在分布式计算系统中经常遇到的一种现象，特别是在大数据处理和分析领域。它指的是数据在被分割并分配到多个计算节点上进行并行处理时，数据分布不均匀，导致某些节点处理的数据量远远大于其他节点的现象。

在 MapReduce 中，数据倾斜也是比较常见的一个问题，稍不留意可能就会出现数据倾斜的问题。数据倾斜的根本原因大抵只有一个，数据值分布不均，或者叫出现热点值。

这也符合实际业务或实际生活中的情况，比如说令打工人感到痛苦的通勤早晚高峰，一天24小时中，高峰的时间段就是这两个时间段，白天其他时间段则相对稳定，然后在凌晨则是低谷期。表现在数据上，如果按小时来看，就会明显看到一个尖峰和一个低谷，数据分布明显不均匀。
同样的，像微博这种平台，大热的话题会有上亿的阅读和千万的讨论，而小话题，只有零星几人阅读，所以针对话题的数据分布极度不均匀。
这些现实问题映射到了一些大数据的处理上，就容易出现数据倾斜。

二、问题来源

本次的数据倾斜问题，来自使用row_number()函数对有大量空值的手机号字段进行分组，导致 Shuffle 阶段分布不均匀。

以下是一个简化之后的 SQL 结构，大致意思就是使用另外一个表 t1 的手机号，对用户表 t0 中的手机号字段的值进行补充，并对手机号进行标记，以便取最后关联的手机号。t0 是一个大表，有 2000 多万数据，t1 是小表，只有 30 多万数据。

INSERT OVERWRITE TABLE t2 PARTITION(cre_year,cre_month)
select /*+ mapjoin(t1)*/
    t0.user_id
    ,coalesce(t1.mobile,t0.mobile) mobile
    ,if(row_number()over(partition by coalesce(t1.mobile,t0.mobile) order by t1.created_at desc,t0.created_at desc)=1,1,0) "mobile_label"
    ,year(t0.created_at)                AS "cre_year"
    ,lpad(month(t0.created_at),2,'0')   AS "cre_month"
from t0
left join t1 on t1.user_id=t0.user_id;

注：通过/*+ mapjoin(t1)*/指定在 Map 阶段进行 JOIN，避免 Shuffle 和减少 Reduce 阶段，降低网络负载，提高执行效率。

t0 表中的 mobile 字段有 80% 是空的，即使 t1 表进行补充，最多也就补充 1.5%，所以在进行row_number()过程中引发了数据倾斜。

该任务是跑在阿里云的 MaxCompute 上，可以通过 LogView 查看每个作业的具体任务，如下图，就是对应上面 SQL 中的 SELECT 任务，可以看到在 SELECT 中出现了数据倾斜，第一个任务跑了百分之七八十的数据，剩下的数据拆分为几十个任务给其他线程跑，发生了严重的数据倾斜，造成了一个长尾现象：第一个任务跑了 3分钟，其他任务五六秒就跑完了。

2.1 如何定位到是哪一个 SQL 节点出了问题？

在阿里云的 LogView 中的 Job Details 界面，可以看到有很多节点作业（Job），每一个作业对应一个或一类任务（Task）。

如下图，展示了 2 个作业，可以抽象地认为是上面 SQL 的作业图，作业 J18_3_4_8_11_12_15_16_17 把关联的表进行 JOIN 操作，而作业 R19_8 则是对 JOIN 结果进行处理（R19_8 对应的任务就是上文的截图，第一个任务跑了百分之七八十的数据，出现明显的长尾现象）。

双击 R19_18 查看详细的算子，可以看到读取数据之后就进行一个窗口函数计算，然后做数据分流。所以基本确认了，数据倾斜的问题就是在 SELECT 中的row_number()函数上。

三、如何解决该数据倾斜问题

该问题主要是空值太多导致 Shuffle 的时候分配到了同一个任务导致的，那么就手动给空值填充一个随机值即可。使用CONCAT(ROUND(RAND(),8)*100000000)手动给空值补充一个随机值（注意：该填充值并不是唯一的，仅做一种参考），这样便可以规避数据倾斜问题。

if(row_number()over(partition by coalesce(t1.mobile,t0.mobile,CONCAT(ROUND(RAND(),8)*100000000)) order by t1.created_at desc,t0.created_at desc)=1,1,0) "mobile_label"

但是该处理方式会使得标记手机号的数据，即标识为 1 的记录翻了 5 倍，我又想实现原来的效果，即对有手机号记录且为最后一个绑定的用户记录标记为1，方便后续筛选出相关记录，该怎么操作呢？
在if()条件上下功夫，加一个条件coalesce(t1.mobile,t0.mobile) is not null，参考如下。

if(row_number()over(partition by coalesce(t1.mobile,t0.mobile,CONCAT(ROUND(RAND(),8)*100000000))  order by t1.created_at desc,t0.created_at desc)=1 and coalesce(t1.mobile,t0.mobile) is not null,1,0) "mobile_label"

修改完跑一下任务，查看那 LogView，可以看到数据都均匀了，每个任务差不多分配 86 万条数据，174 MB，基本在 16 秒左右跑完。

时间从 3 分钟下降到 16 秒，下降 90%，速度提高了 10 倍。另外，阿里云有一个资源占用指标：CoreMin（核数分钟数），CPU 占用由 47.51 下降到 38.90，降幅 18%；内存从 86.24 降到 66.58，降幅 23%。

四、小结

本文介绍了使用随机数填充字段值，规避数据倾斜的一个实战案例。使用CONCAT(ROUND(RAND(),8)*100000000)作为空值的填充值，保证数据在 Shuffle 阶段不发生倾斜，从而提高执行效率（注意：该填充值并不是唯一的，仅做一种参考）。
实战过程中可能会遇到不同的数据倾斜问题，需要根据实际的情况“对症下药”，另外，阿里云官方提供了一份数据倾斜调优文档，感兴趣的同学可以看看。