Hadoop数据倾斜问题

数据倾斜

数据倾斜：由于大量具有相同key的（k-v)键值对被partition分配到一个reduce分区里，map /reduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多（有时是百倍或者千倍之多），这条key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完，这违背了并行计算的初衷，首先一个节点要承受着巨大的压力，而其他节点计算完毕后要一直等待这个忙碌的节点,也拖累了整体的计算时间,可以说效率是十分低下的。

数据倾斜的表现：

1. 一个或多个Reduce卡住
2. 各种container报错OOM
3. 读写的数据量极大，至少远远超过其他的Reduce
4. 伴随着数据倾斜，会出现任务被kill

如何解决

解决方案

1. 增加jvm内存 适用于唯一值非常少，极少数值有非常多的记录值，这种情况下,往往只能通过硬件的手段来进行调优，增加jvm内存可以显著的提高运行效率
2. 增加reduce的个数 适用于唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一的情况。这种情况下，很容易造成大量相同key被partition到一个分区，从而一个reduce执行了大量的工作。而增加reduce的个数，使得节点的工作量减小
3. 自定义分区 需要继承partition类，指定分区策略
4. 重新设计key 在map阶段时给key加上一个随机数，有了随机数的key就不会被大量的分配到同一节点，在reduce中再把随机数去掉即可
5. 使用combinner合并 combinner是在map阶段，reduce之前的一个中间阶段，在这个阶段可以选择性的把大量的相同key数据先进行一个合并，可以看做是local reduce，然后再交给reduce来处理。减轻了map端向reduce端发送的数据量(减轻了网络带宽)，也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率)
6. 采用Map-side join 即map端join的方法可以有效避免数据倾斜。Hadoop提供了DistributedCache。这个组件可以将目标文件发送给各个maptask容器。知道（when）什么时候放，什么时候启动，知道放到（where）哪里去。首先把一个要分发的文件交给DistributedCache，DistributedCache在MapReduce运行的时候会自动把文件分发给每一台maptask的工作目录中，在maptask中可以写一段代码从本地读取这个文件加载到内存，就可以从内存get到这个文件的信息了，就可以实现join

//指定需要缓存一个文件到所有的maptask运行节点的工作目录
job.addArchiveToClassPath(archive);//缓存jar包到task运行节点的classpath中
job.addFileToClassPath(file);//缓存普通文件到task运行节点的classpath中
job.addCatheArchive(uri);//缓存压缩包文件到task运行节点的工作目录
job.addCacheFile(uri);//缓存普通文件到task运行节点的工作目录

由于已经利用DistributedCache组件将文件发送到各个maptask容器，所以在map之前需要做一些初始化工作。

@Override
protected void setup(Context context)throws IOException,InterruptedException{
      BufferedReader bufferedreader=new BufferedReader(new InputStreamReader(new FileInutStream("1.txt")));//因为文件已经在本地工作目录，所以这里可以直接使用文件名称
      String line;
      while(StringUtils.isNotEmpty(line=bufferedreader.readLine())){
           String[] fields=line.split("\t");
           map.put(fields[0],fields[1]);//之前定义了HashMap
	}
}
//setup方法是在MapTask处理数据之前调用一次，可以用来做一些初始化工作