Hadoop性能优化概述-数据膨胀&数据倾斜

MapReduce执行过程

基本概念

mapreduce是一种适合大数据处理的编程模型，程序的本质就是并发，核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序，并发运行在一个 hadoop 集群上。顾名思义，其主体就是由两个阶段组成，map阶段与reduce阶段。map和reduce的过程是由用户自定义实现的，但需要符合mapreduce的协议框架。
我们常说的Hadoop有四大组件构成：

1. HDFS：分布式存储系统。
2. MapReduce：分布式计算系统。
3. YARN： hadoop的资源调度系统。
4. Common： 以上三大组件的底层支撑组件，主要提供基础工具包和 RPC 框架等。
   

处理流程

1. 数据输入

(1) split:
分片。在执行map前需要将数据切分成大小尽可能相等的数据块，输入到多个map task(job)中进行处理，以便于同时(并行)进行。
输入分片存储的并非数据本身，而是一个分片长度和一个记录数据的位置的数组，输入分片往往和hdfs的block关系很密切，假如我们设定hdfs的块的大小是64mb，如果我们输入有三个文件，大小分别是3mb、65mb和127mb，那么mapreduce会把3mb文件分为一个输入分片（input split），65mb则是两个输入分片（input split）而127mb也是两个输入分片（input split），换句话说我们如果在map计算前做输入分片调整，例如合并小文件，那么就会有5个map任务将执行，而且每个map执行的数据大小不均，这个也是mapreduce优化计算的一个关键点。
当然，我们也可以用set参数的方式去改变hdfs上限，这个慎用。

2. map过程

(1) 多个map task并发工作:
每个map task在读入各自的数据后，进行并行计算处理，最终输出给 Reduce。
在最终输出数据时候，会为每一条输出数据(k,v对)指定一个key值，其这条数据用于判定发送给哪一个reduce task。因此，key值与reduce task是多对一的关系，相同的key的数据会被送到同一个reduce task中。
上述过程如下:
(2) sort
map输出结果由于key值不同，会针对key进行快速排序。
(3) spill
磁盘溢写过程。在内存有限的情况下会将map的结果写入磁盘，并且combine那些key值相同的数据。spill与combine交替进行。（注意这里是在hash的基础上）
(4) merge
多次spill产生溢出的数据会被merge在一起。

3. shuffle过程

map输出到reduce输入的过程称为shuffle阶段(洗牌)。这个阶段会根据分区策略将同一分区的数据分配到同一reduce中。
map的输出是k,v对，先进行combine将相同的key合并在一起。
通过hash(key)mod(reduce数目) 计算出partition的ID，上述的key就被分配给这个partition；一个partition中可以有多个key，但是同一个key只存在于一个partition中；一个partition对应一个reduce。有的partition负载可能很重，有的则很轻，需要通过一定的协调机制平衡负载（比如根据自己的需求重写partition函数）。

将map的输出作为reduce的输入的过程就是shuffle了，这个是mapreduce优化的重点地方。这里我不讲怎么优化shuffle阶段，讲讲shuffle阶段的原理，因为大部分的书籍里都没讲清楚shuffle阶段。Shuffle一开始就是map阶段做输出操作，一般mapreduce计算的都是海量数据，map输出时候不可能把所有文件都放到内存操作，因此map写入磁盘的过程十分的复杂，更何况map输出时候要对结果进行排序，内存开销是很大的，map在做输出时候会在内存里开启一个环形内存缓冲区，这个缓冲区专门用来输出的，默认大小是100mb，并且在配置文件里为这个缓冲区设定了一个阀值，默认是0.80（这个大小和阀值都是可以在配置文件里进行配置的），同时map还会为输出操作启动一个守护线程，如果缓冲区的内存达到了阀值的80%时候，这个守护线程就会把内容写到磁盘上，这个过程叫spill，另外的20%内存可以继续写入要写进磁盘的数据，写入磁盘和写入内存操作是互不干扰的，如果缓存区被撑满了，那么map就会阻塞写入内存的操作，让写入磁盘操作完成后再继续执行写入内存操作，前面我讲到写入磁盘前会有个排序操作，这个是在写入磁盘操作时候进行，不是在写入内存时候进行的，如果我们定义了combiner函数，那么排序前还会执行combiner操作。每次spill操作也就是写入磁盘操作时候就会写一个溢出文件，也就是说在做map输出有几次spill就会产生多少个溢出文件，等map输出全部做完后，map会合并这些输出文件。这个过程里还会有一个Partitioner操作，对于这个操作很多人都很迷糊，其实Partitioner操作和map阶段的输入分片（Input split）很像，一个Partitioner对应一个reduce作业，如果我们mapreduce操作只有一个reduce操作，那么Partitioner就只有一个，如果我们有多个reduce操作，那么Partitioner对应的就会有多个，Partitioner因此就是reduce的输入分片，这个程序员可以编程控制，主要是根据实际key和value的值，根据实际业务类型或者为了更好的reduce负载均衡要求进行，这是提高reduce效率的一个关键所在。到了reduce阶段就是合并map输出文件了，Partitioner会找到对应的map输出文件，然后进行复制操作，复制操作时reduce会开启几个复制线程，这些线程默认个数是5个，程序员也可以在配置文件更改复制线程的个数，这个复制过程和map写入磁盘过程类似，也有阀值和内存大小，阀值一样可以在配置文件里配置，而内存大小是直接使用reduce的tasktracker的内存大小，复制时候reduce还会进行排序操作和合并文件操作，这些操作完了就会进行reduce计算了。

4. reduce阶段

在部分map任务执行完后（不用等到所有map任务结束）JobTracker开始分配reduce任务到TaskTracker。taskTracker启动单独的JVM运行这个reduce任务。注意这里不是真正执行reduce函数，而只是分配，等到所有map任务都结束后，jobtracker才会通知tasktracker开始执行reduce的任务。

！补充一个小点，这里有些任务只会生成map任务产生0个reduce任务，这种情况数据量极大比如where查询。 其实如果你的hsql最后生成好多mapreduce任务你的进程自然会很快，这是一个很好的标志。如上述提到的问题你可以加个distributed by。

数据倾斜

数据倾斜的原因

什么叫数据倾斜？倾斜主要发生在Reduce阶段，而很少发生在 Map阶段，我们上述讲到了map阶段会均匀拆分数据到不同块，而这个过程如果倾斜往往是因为hdfs的内存不够问题，很少见。
而Reduce阶段的数据倾斜几乎都是因为数据研发工程师没有考虑到某种key值数据量偏多的情况而导致的。像我们上述降到，会把相同的key放在一个partition传送到reduce， 那比如reduce_1的数据量远远大于reduce_2的时候，就会出现倾斜。卡在这里。

先来看一下常见的数据倾斜语句：

！原理就是上述谈到的那些，分配资源不均，我记得好像分配reduce资源的时候是按照不同分桶组合的平均值来分的，所以倾斜才会导致整体处理能力不足。

！还有一个方法，我们在看mapreduce task 和拆分的instance时候，某个instance 的计算耗时明显大于平均的3倍，那么铁定就倾斜了。

数据倾斜的优化办法

开启参数

-- map端的Combiner,默认为ture
set hive.map.aggr=true；
-- 开启负载均衡
set hive.groupby.skewindata=true （默认为false）

类似groupby的倾斜，可以直接开启参数。但是前提是上述的方法可以诊断出确实有倾斜，不然乱开会导致整体运算很慢。
此外还可以set mapjoin.memory , set jvm memory， set split size等，这些都可以在网上查到。

数据仓库设计层面

举个例子，类似双11，618大促活动，某些商品维度属性的数据本身就会保障，那么在设计表的时候就可以除了日期分区多增加几个属性分区。

join倾斜优化

1. 热点值散列处理

(??) a
join
(??) b on 
case when coalesce(a.device_id,'') in ('','-') then concat('xx',rand()-1) else a.device_id = b.device_id

2. mapjoin
小表join大表，key都集中在小表。
将小表table_a，别名为ta的表放到map端的内存中
如果想将多个表放到Map端内存中，只需在mapjoin()中写多个表名称即可，用逗号分隔，如将a表和c表放到Map端内存中，则 /* +mapjoin(a,c) */

select
/*+ mapjoin(ta)*/
tt_id,
pp_good
from
table_a ta
left join table_b tb on ta.tt_id = tb.tt_id;

另外一点~ mapjoin 可以做不等式的join哟~😄

还有一种sort_merge_bucket join 也可以，没有用过就不讲了。感兴趣可以查查。

3. 把筛选条件尽量写在on上
这个事儿我之前不知道，后来听大佬讲过，不要把筛选条件写在外层，尽量写在On上就会快很多，这个算是优化提速，不一定是倾斜。

group by倾斜优化

上线的set hive.groupby.skewindata=true其实可以解决一部分。

还有一种方法，其实就是拆分多层去进行聚合union all在一起，不要一股脑直接按照key1 key2 key3去聚合。这里就不多说了。

multi distinct倾斜优化

倾斜案例：

select
city,
count(distinct uid) as uid_cnt,
count(distinct device_id) as device_cnt,
count(distinct ip) as ip_cnt
from
table_content
where
dt_par = '???'
group by
city

我们发现一连串count(disitnct) 会导致倾斜，加入某一列空值很多。。。
所以我们一般尽量不要count(distinct) ，我们有两种方法替代：
(1) 双层or多层group by

先聚合多个维度，再在外层聚合最终结果。

(2) with as …group by

with tmp as (
SELECT  city
        ,uid
        ,device_id
        ,ip
FROM    table_content
WHERE   dt_par = '???'
GROUP BY city
         ,uid
         ,device_id
         ,ip
)

SELECT  city， count(uid) AS uid_cnt
        ,count(device_id) AS device_cnt
        ,count(ip) AS ip_cnt
FROM    tmp
GROUP BY city
;

数据膨胀

数据膨胀举个例子，比如两表连接之后，数据量远超两表只和，可能是笛卡尔积导致，因为一个主键对应多条记录。
当然还可能是，写错连接条件。（没写会触发严格模式，尽量不要取消严格模式参数non-district）
在分析一个上层指标时，连接了N张表，越垒越大，这种情况就是时候构建中间层，构建数据Cube，先行聚合，在聚合的基础上再聚合,这样既可以复用中间钻取的数据表，减少了数据量，又加速了关联查询。