网站后台管理系统页面,常熟网站建设哪家好,建设商务网站的目的,网站建设与管理的试卷福哥答案2020-08-17#xff1a;数据倾斜是大数据领域绕不开的拦路虎#xff0c;当你所需处理的数据量到达了上亿甚至是千亿条的时候#xff0c;数据倾斜将是横在你面前一道巨大的坎。很可能有几周甚至几月都要头疼于数据倾斜导致的各类诡异的问题。数据倾斜是指#xff1a;… 福哥答案2020-08-17数据倾斜是大数据领域绕不开的拦路虎当你所需处理的数据量到达了上亿甚至是千亿条的时候数据倾斜将是横在你面前一道巨大的坎。很可能有几周甚至几月都要头疼于数据倾斜导致的各类诡异的问题。数据倾斜是指mapreduce程序执行时reduce节点大部分执行完毕但是有一个或者几个reduce节点运行很慢导致整个程序的处理时间很长这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多)这条key所在的reduce节点所处理的数据量比其他节点就大很多从而导致某几个节点迟迟运行不完。Hive的执行是分阶段的map处理数据量的差异取决于上一个stage的reduce输出所以如何将数据均匀的分配到各个reduce中就是解决数据倾斜的根本所在。以下是一些常见的数据倾斜情形一、Group by 倾斜group by造成的倾斜相对来说比较容易解决。hive提供两个参数可以解决1.1 hive.map.aggr一个是hive.map.aggr默认值已经为true他的意思是做map aggregation也就是在mapper里面做聚合。这个方法不同于直接写mapreduce的时候可以实现的combiner但是却实现了类似combiner的效果。事实上各种基于mr的框架如pigcascading等等用的都是map aggregation(或者叫partial aggregation)而非combiner的策略也就是在mapper里面直接做聚合操作而不是输出到buffer给combiner做聚合。对于map aggregationhive还会做检查如果aggregation的效果不好那么hive会自动放弃map aggregation。判断效果的依据就是经过一小批数据的处理之后检查聚合后的数据量是否减小到一定的比例默认是0.5由hive.map.aggr.hash.min.reduction这个参数控制。所以如果确认数据里面确实有个别取值倾斜但是大部分值是比较稀疏的这个时候可以把比例强制设为1避免极端情况下map aggr失效。hive.map.aggr还有一些相关参数比如map aggr的内存占用等具体可以参考这篇文章。1.2 hive.groupby.skewindata另一个参数是hive.groupby.skewindata。这个参数的意思是做reduce操作的时候拿到的key并不是所有相同值给同一个reduce而是随机分发然后reduce做聚合做完之后再做一轮MR拿前面聚合过的数据再算结果。所以这个参数其实跟hive.map.aggr做的是类似的事情只是拿到reduce端来做而且要额外启动一轮job所以其实不怎么推荐用效果不明显。1.3 count distinct 改写另外需要注意的是count distinct操作往往需要改写SQL可以按照下面这么做bash/*改写前*/select a, count(distinct b) as c from tbl group by a;/*改写后*/select a, count(*) as c from (select a, b from tbl group by a, b) group by a;二、Join倾斜2.1 skew joinjoin造成的倾斜常见情况是不能做map join的两个表(能做map join的话基本上可以避免倾斜)其中一个是行为表另一个应该是属性表。比如我们有三个表一个用户属性表users一个商品属性表items还有一个用户对商品的操作行为表日志表logs。假设现在需要将行为表关联用户表bashselect * from logs a join users b on a.user_id b.user_id;其中logs表里面会有一个特殊用户user_id 0代表未登录用户假如这种用户占了相当的比例那么个别reduce会收到比其他reduce多得多的数据因为它要接收所有user_id 0的记录进行处理使得其处理效果会非常差其他reduce都跑完很久了它还在运行。hive给出的解决方案叫skew join其原理把这种user_id 0的特殊值先不在reduce端计算掉而是先写入hdfs然后启动一轮map join专门做这个特殊值的计算期望能提高计算这部分值的处理速度。当然你要告诉hive这个join是个skew join即set hive.optimize.skewjoin true;还有要告诉hive如何判断特殊值根据hive.skewjoin.key设置的数量hive可以知道比如默认值是100000那么超过100000条记录的值就是特殊值。总结起来skew join的流程可以用下图描述2.2 特殊值分开处理法不过上述方法还要去考虑阈值之类的情况其实也不够通用。所以针对join倾斜的问题一般都是通过改写sql解决。对于上面这个问题我们已经知道user_id 0是一个特殊key那么可以把特殊值隔离开来单独做join这样特殊值肯定会转化成map join非特殊值就是没有倾斜的普通join了bashselect *from ( select * from logs where user_id 0 ) ajoin ( select * from users where user_id 0 ) bon a.user_id b.user_idunion allselect * from logs a join users b on a.user_id 0 and a.user_id b.user_id;2.3 随机数分配法上面这种个别key倾斜的情况只是一种倾斜情况。最常见的倾斜是因为数据分布本身就具有长尾性质比如我们将日志表和商品表关联bashselect * from logs a join items b on a.item_id b.item_id;这个时候分配到热门商品的reducer就会很慢因为热门商品的行为日志肯定是最多的而且我们也很难像上面处理特殊user那样去处理item。这个时候就会用到加随机数的方法也就是在join的时候增加一个随机数随机数的取值范围n相当于将item给分散到n个reducerbashselect a.*, b.*from ( select *, cast(rand() * 10 as int) as r_id from logs ) ajoin ( select *, r_id from items lateral view explode(range_list(1, 10)) rl as r_id ) bon a.item_id b.item_id and a.r_id b.r_id上面的写法里对行为表的每条记录生成一个1-10的随机整数对于item属性表每个item生成10条记录随机key分别也是1-10这样就能保证行为表关联上属性表。其中range_list(1,10)代表用udf实现的一个返回1-10整数序列的方法。这个做法是一个解决join倾斜比较根本性的通用思路就是如何用随机数将key进行分散。当然可以根据具体的业务场景做实现上的简化或变化。2.4 业务设计除了上面两类情况还有一类情况是因为业务设计导致的问题也就是说即使行为日志里面join key的数据分布本身并不明显倾斜但是业务设计导致其倾斜。比如对于商品item_id的编码除了本身的id序列还人为的把item的类型也作为编码放在最后两位这样如果类型1(电子产品)的编码是00类型2(家居产品)的编码是01并且类型1是主要商品类将会造成以00为结尾的商品整体倾斜。这时如果reduce的数量恰好是100的整数倍会造成partitioner把00结尾的item_id都hash到同一个reducer引爆问题。这种特殊情况可以简单的设置合适的reduce值来解决但是这种坑对于不了解业务的情况下就会比较隐蔽。三、典型的业务场景3.1 空值产生的数据倾斜场景如日志中常会有信息丢失的问题比如日志中的 user_id如果取其中的 user_id 和 用户表中的user_id 关联会碰到数据倾斜的问题。解决方法1user_id为空的不参与关联bashselect *from log ajoin users bon a.user_id is not null and a.user_id b.user_idunion allselect * from log a where a.user_id is null;解决方法2 赋与空值分新的key值bashselect *from log aleft outer join users bon case when a.user_id is null then concat(‘hive’, rand()) else a.user_id end b.user_id;结论方法2比方法1效率更好不但io少了而且作业数也少了。解决方法1中 log读取两次jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。3.2 不同数据类型关联产生数据倾斜场景用户表中user_id字段为intlog表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时默认的Hash操作会按int型的id来进行分配这样会导致所有string类型id的记录都分配到一个Reducer中。解决方法把数字类型转换成字符串类型bashselect *from users aleft outer join logs bon a.usr_id cast(b.user_id as string)3.3 小表不小不大怎么用 map join 解决倾斜问题使用 map join 解决小表(记录数少)关联大表的数据倾斜问题这个方法使用的频率非常高但如果小表很大大到map join会出现bug或异常这时就需要特别的处理。以下例子:bashselect * from log a left outer join users b on a.user_id b.user_id;users 表有 600w 的记录把 users 分发到所有的 map 上也是个不小的开销而且 map join 不支持这么大的小表。如果用普通的 join又会碰到数据倾斜的问题。bashselect /*mapjoin(x)*/ *from log aleft outer join ( select /*mapjoin(c)*/ d.* from ( select distinct user_id from log ) c join users d on c.user_id d.user_id ) x on a.user_id b.user_id;假如log里user_id有上百万个这就又回到原来map join问题。所幸每日的会员uv不会太多有交易的会员不会太多有点击的会员不会太多有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。四、总结使map的输出数据更均匀的分布到reduce中去是我们的最终目标。由于Hash算法的局限性按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤1)采样log表哪些user_id比较倾斜得到一个结果表tmp1。由于对计算框架来说所有的数据过来他都是不知道数据分布情况的所以采样是并不可少的。2)数据的分布符合社会学统计规则贫富不均。倾斜的key不会太多就像一个社会的富人不多奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。3)map读入users和log假如记录来自log,则检查user_id是否在tmp2里如果是输出到本地文件a,否则生成的key,value对假如记录来自member,生成的key,value对进入reduce阶段。4)最终把a文件把Stage3 reduce阶段输出的文件合并起写到hdfs。如果确认业务需要这样倾斜的逻辑考虑以下的优化方案1)对于join在判断小表不大于1G的情况下使用map join2)对于group by或distinct设定 hive.groupby.skewindatatrue3)尽量使用上述的SQL语句调节进行优化五、参考文献[数据分析系列(3)数据倾斜](https://blog.csdn.net/anshuai_aw1/article/details/84033160)***[评论](https://user.qzone.qq.com/3182319461/blog/1597618770)
