join left 大数据_离线和实时大数据开发实战笔记

----------第四章：hive原理实践----------

1.mapreduce执行原理详解：

1.输入分片 2.map阶段 3.combiner(不影响结果可以用) 4. shuffle阶段 (分map 和reduce两个阶段) 5.reduce

2：order by 和 sort by 不一样。 order by 是全局排序，只有一个reduce任务。而sort by 是本机排序。

3.join 大表放后面：因为reduce任务时将join序列的 除了最后一个表所有记录缓存，再通过最后一个表将结果序列化到文件系统。

4.left semi join 是 in/exists 子查询的更高效的实现;

SELECT A.A,B.A FROM A WHERE A.A IN (SELECT B.A FROM B)等效于 select a.a ,b.a from a left semi join b on a.a=b.a

5.理解 几种基本的hive sql语句的对应的执行原理。

----------第五章：hive优化实践----------

6.优化点：(1)小文件合并成大文件 (2)避免select (3)避免selct count(distinct )

7.与join无关的数据倾斜：

group by 列分布不均引起的数据倾斜.数据量多的一种列对应的 reduce任务数据量就很大，导致倾斜

设置2个参数。设置之后会生成2个mrjob。第一个mr job会把map结果集均匀随机分布到reduce任务。第二个mr job再根据预处理的结果集按照 group by

字段分布到reduce任务中

set hive.map.aggr=true

set hive.groupby.skewindata=true

8.和join相关的数据倾斜

join导致的倾斜主题思想是：由于join列的分发导致有些值的数据分布特别大，所以关键是将join列的值分散掉，让其均匀分布。

(1)大表关联小表--使用mapjoin提示：比如有一个很大的事实表里有供应商，供应商有对应的供应商评级表。计算每天各等级的供应商的个数。而供应商的评级会符合28定律导致数据倾斜。()

select /+mapjoin(b)/ a.seller_star,count(seller_id) from ..... 这样 优化点：在map阶段进行join 而不是像在reduce阶段按照join列进行分发后在每个reduce任务节点进行join不分发也就不会有倾斜

(2)空值导致倾斜

将空值随机取数，这样为空的user_id就会将订单随机分配到不同的任务中

select a.user_id ,a.order_id,b.user_id from a left join b on

case when a.user_id is null then concat('hive',rand) else a.user_id =b.user_id

(3)大表关联大表

问题场景：A表汇总事实表：buyer_id,sell_id,pay_cnt_90d B表 sell_id s_level 卖家等级表，该表也很大。几千万的数据量。所以不能直接majoin

处理方法：

(1)过滤行：将近90天没有成交的卖家过滤

(2)倍数B表 再取模：这样就不会只按照sell_id 分发，而是sell_id和数字一起分发，不会数据倾斜

select buyer_id,sell_id,pay_cnt_90d ,b.s_level from a left join (select /mapjoin(membtes)*/ sell_id,s_level ,member from b join membtes ) b on a.sell_id=b.sell_id and mod(a.pay_cnt_90d,10)+1=b.member;

(3) 专用方案：看不太懂。。代码看起来关联不起来。。

(4)建一个买家多的卖家列表。符合该表的用mapjoin ,其他正常使用join。然后两部分 再union all (书本中逻辑没问题，但是代码有些问题)