Day41_Hadoop优化

（一）MapReduce跑的慢的原因

MapReduce 程序效率的瓶颈在于两点：

计算机性能

       CPU、内存、磁盘健康、网络

I/O 操作优化

    （1）数据倾斜

    （2）map和reduce数设置不合理

    （3）map运行时间太长，导致reduce等待过久

    （4）小文件过多

    （5）spill(溢出)次数过多，溢出数据到磁盘

    （6）merge次数过多，Shuffle溢出时后会有合并，reduce端也会有合并

（二）MapReduce优化方案

    MapReduce优化方法主要从六个方面考虑：数据输入、Map阶段、Reduce阶段、IO传输、数据倾斜问题和常用的调优参数。

1、数据输入

    （1）合并小文件：在执行MR任务前将小文件进行合并，大量的小文件会产生大量的map任务，大量节点资源被占用，从而导致MR整体运行较慢。

    （2）采用CombineTextInputFormat作为输入，解决输入端大量小文件场景。

2、Map阶段

(1)        减少溢写（spill）次数：通过调整io.sort.mb及sort.spill.percent参数值（在mapred-default.xml），增大触发spill的内存上限，减少spill次数，从而减少磁盘IO。

(2)        减少合并（merge）次数：通过调整io.sort.factor参数（在mapred-default.xml），增大merge的文件数目，减少merge的次数，从而缩短MR处理时间。

(3)        在map之后，不影响业务逻辑前提下，先进行combine处理，减少 I/O。

3、Reduce阶段

    （1）合理设置map和reduce数：两个都不能设置太少，也不能设置太多。太少，会导致task等待，延长处理时间；太多，会导致 map、reduce任务间竞争资源，造成处理超时等错误。

    （2）设置map、reduce共存：调整slowstart.completedmaps参数，使map运行到一定程度后，reduce也开始运行，减少reduce的等待时间。

    （3）合理设置reduce端的buffer：默认情况下，map任务处理完的数据会被reduce拉取到内存buffer上，当buffer上的数据达到一个阈值的时候，buffer中的数据就会写入磁盘，然后reduce会从磁盘中获得所有的数据。也就是说，buffer和reduce是没有直接关联的，中间多个一个写磁盘->读磁盘的过程，既然有这个弊端，那么就可以通过参数来配置，使得buffer中的一部分数据可以直接输送到reduce，从而减少IO开销：

mapred.job.reduce.input.buffer.percent //默认为0.0

当值大于0的时候，会保留指定比例的内存读buffer中的数据直接拿给reduce使用。这样一来，设置buffer需要内存，读取数据需要内存，reduce计算也要内存，所以要根据作业的运行情况进行调整。

4、I/O传输

    （1）采用数据压缩的方式，减少网络IO的的时间。使用自带压缩功能，或者安装第三方yasuo编码器，如：Snappy和LZO。

    （2）使用SequenceFile二进制文件

5、数据倾斜问题

   （1）数据倾斜现象

       数据频率倾斜：某一个区域的数据量要远远大于其他区域。

            数据大小倾斜：部分记录的大小远远大于平均值。

   （2）减少数据倾斜的方法

   方法1：抽样和范围分区

       可以通过对原始数据进行抽样得到的结果集来预设分区边界值。

   方法2：自定义分区

       基于输出键的背景知识进行自定义分区。例如，如果map输出键的单词来源于一本书。且其中某几个专业词汇较多。那么就可以自定义分区将这这些专业词汇发送给固定的一部分reduce实例。而将其他的都发送给剩余的reduce实例。

   方法3：Combine

       使用Combine对maptask的输出进行局部汇总，可以大量地减小数据倾斜。在可能的情况下，combine的目的就是聚合并精简数据。

   方法4：采用Map Join，尽量避免Reduce Join。

6、常用调优参数

（1）MR调优参数

    在用户自己的MR应用程序中配置就可以生效（mapred-default.xml）

配置参数	参数说明
mapreduce.map.memory.mb	一个MapTask可使用的资源上限（单位:MB），默认为1024。如果MapTask实际使用的资源量超过该值，则会被强制杀死。
mapreduce.reduce.memory.mb	一个ReduceTask可使用的资源上限（单位:MB），默认1024。如果ReduceTask实际使用的资源量超过该值，则会被强制杀死。
mapreduce.map.cpu.vcores	每个MapTask可使用的最多cpu core数目，默认值: 1
mapreduce.reduce.cpu.vcores	每个ReduceTask可使用的最多cpu core数目，默认值: 1
mapreduce.reduce.shuffle.parallelcopies	每个Reduce去Map中取数据的并行数。默认值是5
mapreduce.reduce.shuffle.merge.percent	Buffer中的数据达到多少比例开始写入磁盘。默认值0.66
mapreduce.reduce.shuffle.input.buffer.percent	Buffer大小占Reduce可用内存的比例。默认值0.7
mapreduce.reduce.input.buffer.percent	指定多少比例的内存用来存放Buffer中的数据，默认值是0.0

（2）Yarn调优参数

在YARN启动之前就配置在服务器的配置文件中才能生效（yarn-default.xml）

配置参数	参数说明
yarn.scheduler.minimum-allocation-mb	给应用程序Container分配的最小内存，默认值：1024
yarn.scheduler.maximum-allocation-mb	给应用程序Container分配的最大内存，默认值：8192
yarn.scheduler.minimum-allocation-vcores	每个Container申请的最小CPU核数，默认值：1
yarn.scheduler.maximum-allocation-vcores	每个Container申请的最大CPU核数，默认值：32
yarn.nodemanager.resource.memory-mb	给Containers分配的最大物理内存，默认值：8192

（3）Shuffle性能优化

    在YARN启动之前就配置好（mapred-default.xml）

配置参数	参数说明
mapreduce.task.io.sort.mb	Shuffle的环形缓冲区大小，默认100m
mapreduce.map.sort.spill.percent	环形缓冲区溢出的阈值，默认80%

（4）容错性调优

    在YARN启动之前就配置好（mapred-default.xml）

配置参数	参数说明
mapreduce.map.maxattempts	每个Map Task最大重试次数，一旦重试次数超过该值，则认为Map Task运行失败，默认值：4。
mapreduce.reduce.maxattempts	每个Reduce Task最大重试次数，一旦重试参数超过该值，则认为Map Task运行失败，默认值：4。
mapreduce.task.timeout	Task超时时间，如果一个Task在一定时间内即不会读取新的数据，也没有输出数据，则认为该Task处于Block状态，可能是卡住了，也许永远会卡住，为了防止因为用户程序永远Block住不退出，则强制设置了一个该超时时间（单位毫秒），默认是600000。如果你的程序对每条输入数据的处理时间过长（比如会访问数据库，通过网络拉取数据等），建议将该参数调大，该参数过小常出现的错误提示是： “AttemptID:attempt_14267829456721_123456_m_000224_0 Timed out after 300 secsContainer killed by the ApplicationMaster.”。

（三）Hadoop对小文件处理方式

当小文件比较多的时候，就会产生很多的索引文件，一方面会大量占用NameNode的内存空间，另一方面就是索引文件过大使得索引速度变慢。

    优化方法：

       上传到HDFS前：使用java的编程语言提前和并小文件

       上传到HDFS时：使用hadoop fs -appendtofile进行文件追加

       上传到HDFS后：使用hdfs的归档机制合并小文件

            使用MapReduce计算后：使用CombinerTextInputFormat合并小文件

（四）HDFS的HA

    HDFS高可用性功能通过提供以下选项来解决上述问题：

    在具有热备用的主动/被动配置中，可以在同一集群中运行两个（或更多，从Hadoop3.0.0起）冗余NameNode。这可以在计算机崩溃的情况下快速故障转移到新的NameNode，或者出于计划维护的目的由管理员发起的正常故障转移。

    在学习Zookeeper时会着重介绍HA的实现。

（五）YARN HA 集群

ResourceManager（RM）负责管理群集中的资源和调度应用程序（如MR、Spark等）。在Hadoop 2.4之前，YARN群集中的ResourceManager存在SPOF（Single Point of Failure，单点故障）。为了解决ResourceManager的单点问题，YARN设计了一套Active/Standby模式的ResourceManager HA（High Availability，高可用）架构。在运行期间有多个ResourceManager同时存在来增加冗余进而消除这个单点故障，并且只能有一个ResourceManager处于Active状态，其他的则处于Standby状态，当Active节点无法正常工作，其余Standby状态的几点则会通过竞争选举产生新的Active节点。

1、高可用 HA 架构

故障转移机制支持自动故障转移和手动故障转移两种方式实现。在生产环境中，自动故障转移应用更为广泛。

第一种：手动故障转移

当没有启用自动故障转移时，管理员必须手动将一个RM转换为活动状态。要从一个RM到另一个RM进行故障转移，需要先把Active状态的RM转换为Standby状态的RM，然后再将Standby状态的RM转换为Active状态的RM。这些操作可用yarn rmadmin 命令来完成。

第二种：自定故障转移

RM可以选择嵌入基于Zookeeper的ActiveStandbyElector（org.apache.hadoop.ha.ActiveStandbyElector类）来实现自动故障转移，以确定哪个RM应该是Active。当Active状态的RM发生故障或无响应时，另一个RM被自动选为Active，然后接管服务。YARN的故障转移不需要像HDFS那样运行单独的ZKFC守护程序，因为ActiveStandbyElector是一个嵌入在RM中充当故障检测器和Leader选举的线程，而不是单独的ZKFC守护进程。

当有多个RM时，Clients和NMs通过读取yarn-site.xml配置找到所有ResourceManager。Clients、AM和NM会轮训所有的ResourceManager并进行连接，直到找着Active状态的RM。如果Active状态的RM也出现故障，它们就会继续查找，直到找着新的Active状态的RM。

2、故障转移原理

YARN这个Active/Standby模式的RM HA架构在运行期间，会有多个RM同时存在，但只能有一个RM处于Active状态，其他的RM则处于Standby状态，当Active节点无法正常提供服务，其余Standby状态的RM则会通过竞争选举产生新的Active节点。以基于ZooKeeper这个自动故障切换为例，切换的步骤如下：

1. 主备切换，RM使用基于ZooKeeper实现的ActiveStandbyElector组件来确定RM的状态是Active或Standby。
2. 创建锁节点，在ZooKeeper上会创建一个叫做ActiveStandbyElectorLock的锁节点，所有的RM在启动的时候，都会去竞争写这个临时的Lock节点，而ZooKeeper能保证只有一个RM创建成功。创建成功的RM就切换为Active状态，并将信息同步存入到ActiveBreadCrumb这个永久节点，那些没有成功的RM则切换为Standby状态。
3. 注册Watcher监听，所有Standby状态的RM都会向/yarn-leader-election/cluster1/ActiveStandbyElectorLock节点注册一个节点变更的Watcher监听，利用临时节点的特性，能够快速感知到Active状态的RM的运行情况。
4. 准备切换，当Active状态的RM出现故障（如宕机或网络中断），其在ZooKeeper上创建的Lock节点随之被删除，这时其它各个Standby状态的RM都会受到ZooKeeper服务端的Watcher事件通知，然后开始竞争写Lock子节点，创建成功的变为Active状态，其他的则是Standby状态。
5. Fencing(隔离)，在分布式环境中，机器经常出现假死的情况（常见的是GC耗时过长、网络中断或CPU负载过高）而导致无法正常对外进行及时响应。如果有一个处于Active状态的RM出现假死，其他的RM刚选举出来新的Active状态的RM，这时假死的RM又恢复正常，还认为自己是Active状态，这就是分布式系统的脑裂现象，即存在多个处于Active状态的RM，可以使用隔离机制来解决此类问题。
6. YARN的Fencing机制是借助ZooKeeper数据节点的ACL权限控制来实现不同RM之间的隔离。这个地方改进的一点是，创建的根ZNode必须携带ZooKeeper的ACL信息，目的是为了独占该节点，以防止其他RM对该ZNode进行更新。借助这个机制假死之后的RM会试图去更新ZooKeeper的相关信息，但发现没有权限去更新节点数据，就把自己切换为Standby状态。

（六）HDFS的联邦机制（HDFS Federation）

    以前的HDFS框架整个集群只允许有一个namenode管理所有的命名空间，为了水平扩展名称服务，HDFS联邦通过增加多个namenode进行联合使用，多个Namenode提高了集群的拓展性。但Namenode之间相互隔离，不需要相互协调，一个Namenode挂掉，并不会影响其他Namenode的运行。Datanode被所有Namenode用作块的通用存储。每个Datanode向集群中的所有Namenode注册。Datanode定期发送心跳信息、块报告到所有namenode,同时执行所有namenode发来的命令。

注：具体使用可参考官网说明

   https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/Federation.html