数据倾斜优化思路实践

数据倾斜,顾名思义,就是在计算过程中数据分散度不够,导致某个节点数据过于集中,从而导致任务执行效率大大降低。参照对比下MR的整体流程和ODPS,整体结合理解数据倾斜发生的几个生命周期的节点,如下图:可以分为Map、Reduce、Join三个阶段理解。

Map端长尾

Map端是MR任务的开始,在Map端读取数据的时候,由于读入的数据文件大小分布不均匀,会导致一些Map instance的数据量很大,一些instance很小,造成了Map端长尾现象。一般情况下,Map端长尾现象较少,主要由以下两种原因导致:

Map端读入的文件大小不均匀,且小文件很多,导致当前Map端读取数据不均匀

Map端做聚合操作由于Map instance读取文件某个值较多引起长尾,主要指count(distinct)操作

方案

针对小文件和文件大小不均匀的情况,暂时没有特别好的方法,可以通过合并文件、文件切片大小等参数进行调优,即:set odps.sql.mapper.merge.limit.size = 64,set odps.sql.mapper.split.size = 256

针对第二种情况,采取distribute by rand()来打乱数据,使数据尽可能的分布均匀,如下:通过distribute by rand() 会让Map端分发后的数据重新随机进行一次分发。这种方式虽然平衡了instance处理的数据量,但是带来了Reduce端的资源紧张。具体可以增大Reduce端的instance个数,具体如下:set odps.sql.reducer.insatnce = 100;

select

t1.*

from

(

select

id,

name

from ods.cn_log_app_test01_pre_1d

where dt = ' d t ′ d i s t r i b u t e b y r a n d ( ) ) t 1 l e f t j o i n ( s e l e c t ∗ f r o m o d s . c n l o g a p p t e s t 0 2 p r e 1 d w h e r e d t = ′ {dt}' distribute by rand() )t1 left join ( select * from ods.cn_log_app_test02_pre_1d where dt = ' dt′distributebyrand())t1leftjoin(select∗fromods.cnlogapptest02pre1dwheredt=′{dt}'

) t2

on t1.id = t2.id

Reduce端长尾

Reduce端主要负责的是对Map端输出的K-V形式的数据进行处理,比如常见的聚合操作,即count、sum、avg等,得到最终的聚合结果。Reduce端产生长尾现象的主要原因是key的分布不均匀导致。比如:一些instance处理的数据量很大,可能40min这个reduce task还没结束,有的instance处理的数据量很小,主要场景如下:(从上至下优先级为常见-> 少见)

在Join阶段经常发生的:空值很多,造成这么多的Null值被分发到同一个instance上

在Map端聚合操作的时候出现key值分布不均匀,从而导致Reduce端长尾

多个distinct出现在同一段SQL代码中,数据会被分发多次,不仅会造成数据膨胀,还会把长尾现象放大多倍

动态分区数过多可能造成小文件过多,从而引起Reduce端长尾

第一种场景方案

当存在很多Null值的时候,可以选择把空值数据单独拎出来,然后别的数据去做Join,最后再把空值数据union all上去即可。生产中,有些空值是具备业务含义的,比如:剩余还款字段,用户某个时间点已还清贷款,显然去掉空值数据是肯定不对的,所以需要具体情况具体分析

加随机数,打散,实际用的不多,第一种方式用的更高频

比如数据如下:

concat(name + '_' + random)

乌克兰 -> 乌克兰_1

乌克兰 -> 乌克兰_2

乌克兰 -> 乌克兰_3

最终结果数据 res.split('_')[0]再取回原数据即可

第二种场景方案

查看数据key的分布情况,对一些热点key进行单独计算,然后再union all回来,简单来说,就是两个任务单独处理,例如:select / + skewjoin (a(c0,c1)) /* from T0 a join T1 b on a.c0 = b.c0 and a.c1 = b.c1 and a.c2 = b.c2

第三种场景方案

ODPS对动态分区的处理是引入一个额外的一级reduce task,相同的目标分区交由一个(或者少量几个)reduce instance写入,避免小文件过多

第四种场景方案

遇到该情况,最好的办法就是通过其他方案例如:临时表、现有模型去计算去重的指标,避免使用distinct造成数据膨胀

Join长尾优化

Join是指将相同的数据分发到同一个instance上处理,如果某个key的value量级很大,处理时间很长,即称之为长尾。主要以下几个场景:

大表join小表

空值和热点值在reduce长尾场景中已经说过,见上文

场景一方案

t1表数据量级:9700w+ t2表量级:1000w+

SELECT /+mapjoin(t2) /

t1.*

,t2.f_guaname

,t2.f_guades

,t2.f_own

FROM (

SELECT *

FROM ods.ods_zdf_itf_company_mort

WHERE dt = ' b i z d a t e ′ A N D n v l ( f d e l e t e d , ′ 0 ′ ) = ′ 0 ′ ) t 1 L E F T J O I N ( S E L E C T f g u a n a m e , f g u a d e s , f o w n F R O M o d s . o d s z d f i t f c o m p a n y m o r t g u a W H E R E d t = ′ {bizdate}' AND nvl(f_deleted, '0') = '0' ) t1 LEFT JOIN ( SELECT f_guaname ,f_guades ,f_own FROM ods.ods_zdf_itf_company_mort_gua WHERE dt = ' bizdate′ANDnvl(fdeleted,′0′)=′0′)t1LEFTJOIN(SELECTfguaname,fguades,fownFROMods.odszdfitfcompanymortguaWHEREdt=′{bizdate}'

AND nvl(f_deleted, '0') = '0'

) t2

ON t1.f_morreg_id = t2.f_morreg_id

ODPS高频的长尾参数配置

set odps.sql.groupby.skewindata=true/false

row_number()优化【不常用】

分组过程中可能某个key的数据量太大,会造成倾斜的,那么自己搞个随机列,根据key + random分组,那么这个热点key的数据其实就打散了,那么再求出topN,其实这批次topN就已经是一定条件下的好马了,内层循环已经避免了数据倾斜,外层直接根据key全局分组,相当于这批好马里再挑好马。

select cate_id

,property_id

,value_id

from

(select cate_id

,property_id

,value_id

,row_number() over(partition by cate_id order by property_id asc,value_id asc) as rn

from

(select cate_id

,property_id

,value_id

from

(select cate_id

,property_id

,value_id

,row_number() over(partition by cate_id,sec_part order by property_id asc,value_id asc) as rn

from

(select cate_id

,property_id

,value_id

,ceil(M*rand())%P as sec_part

from one_plat.ads_tb_sycm_cate_xx

where ds = '${bizdate}'

) s

) p

where rn <= N

) part

) a

where rn <= N

常见资源配置参数

设置Map Task每个instance的cpu数,默认在[50-800]之间,一般不会调

set odps.sql.mapper.cpu=100;

设定Map Task每个Instance的Memory大小,单位M,默认1024M

set odps.sql.mapper.memory=1024;

设定一个Map的最大数据输入量

set odps.sql.mapper.split.size=256

[最好不要降低这个阈值,因为每个map task的instance时间是减少了,但是小文件多了,合并时间翻倍,得不偿失]

设定Join Task的Instance数量,默认为-1,在[0,2000]之间调整

set odps.sql.joiner.instances=-1;

场景:每个Join Instance处理的数据量比较大,耗时较长,没有发生长尾,可以考虑增大使用这个参数。

扩大string字符串的大小,这个场景是之前字符串中存储多条json的时候,多的存储几十万条,超出string默认大小,只能修改string大小,需要注意的是要不断调节,有OOM的风险

set odps.sql.cfile2.field.maxsize=16384;

总结

尽量不要通过设置参数的方式进行优化,首先要看能否从业务上或者算法上减少数据和其他方式进行优化

设置参数的话,要首先确定是Map、Reduce、Join哪个阶段的任务时间长,从而设置对应的参数

在没有出现数据倾斜的情况下,如果通过设置Cpu参数(含Memory参数)和设置Instance个数两种方式都能调优的话,最好是先设置Instance个数。因为如果Cpu/Memory参数设置不合理,执行任务的机器满足不了参数的要求,要重新找机器的,这样反而会影响效率

Instance的个数设置,有个简单的方法是二分法。先设置个很大的,如果不能满足要求,那么就继续增大,如果满足了要求,就折半降低参数大小,最终找到一个合适的值

如果面试中问到hivesql的优化,可以侧重数据倾斜做不同场景的优化分析,尽量避免按照网上的优化套路回答,往往效果不佳,毕竟面试官能搜到的答案,大概率不是他想看到的答案,突出有自己的思考且真正的有所应用才是最重要的,不然就会出现自己觉得答的很不错最后却没了结果。

相关推荐
打鱼又晒网5 分钟前
【MySQL】数据库精细化讲解:内置函数知识穿透与深度学习解析
数据库·mysql
佚先森9 分钟前
2024ARM网络验证 支持一键云注入引流弹窗注册机 一键脱壳APP加固搭建程序源码及教程
java·html
大白要努力!10 分钟前
android 使用SQLiteOpenHelper 如何优化数据库的性能
android·数据库·oracle
古月居GYH23 分钟前
在C++上实现反射用法
java·开发语言·c++
tatasix1 小时前
MySQL UPDATE语句执行链路解析
数据库·mysql
南城花随雪。1 小时前
硬盘(HDD)与固态硬盘(SSD)详细解读
数据库
儿时可乖了1 小时前
使用 Java 操作 SQLite 数据库
java·数据库·sqlite
ruleslol1 小时前
java基础概念37:正则表达式2-爬虫
java