Hadoop-Yarn和Hadoop企业优化

Yarn

Hadoop1.x和Hadoop2.x架构区别

在Hadoop1.x时代，Hadoop中的MapReduce同时处理业务逻辑运算和资源的调度，耦合性较大。

在Hadoop2.x时代，增加了Yarn。Yarn只负责资源的调度，MapReduce只负责运算

Yarn概述

Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。

Yarn基本架构

YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等组件构成。

Yarn工作机制

名词解释

1. 资源：在 YARN 的语境下，资源特指计算资源，包括 CPU 和内存。计算机的每个进程都会占用一定的 CPU 和内存，任务需要先向 RM 申请到资源后才能获准在 NM 上启动自己的进程。

2. 队列：YARN 将整个集群的资源划分为队列，每个用户的任务必须提交到指定队列。同时限制每个队列的大小，防止某个用户的任务占用整个集群，影响了其他用户的使用。

3. Vcore & Mem：逻辑 CPU 和逻辑内存，每个 NM 会向 RM 汇报自己有多少 vcore 和内存可用，具体数值由集群管理员配置。比如一台48核，128G内存的机器，可以配置40vcore，120G内存，意为可以对外提供这么多资源。具体数值可能根据实际情况有所调整。每个 NM 的逻辑资源加起来，就是整个集群的总资源量。

4. MinResources & MaxResources：为了使每个队列都能得到一定的资源，同时又不浪费集群的空闲资源，队列的资源设置都是“弹性”的。每个队列都有 min 和 max 两个资源值，min 表示只要需求能达到，集群一定会提供这么多资源；如果资源需求超过了 min 值而同时集群仍有空闲资源，则仍然可以满足；但又限制了资源不能无限申请以免影响其他任务，资源的分配不会超过 max 值。

5. Container：任务申请到资源后在 NM 上启动的进程统称 Container。比如在 MapReduce 中可以是 Mapper 或 Reducer，在 Spark 中可以是 Driver 或 Executor。

• 工作机制简化版
  1. 用户使用客户端向 RM 提交一个任务job，同时指定提交到哪个队列和需要多少资源。用户可以通过每个计算引擎的对应参数设置，如果没有特别指定，则使用默认设置。

1. RM 在收到任务提交的请求后，先根据资源和队列是否满足要求选择一个 NM，通知它启动一个特殊的 container，称为 ApplicationMaster（AM），后续流程由它发起。

2. AM 向 RM 注册后根据自己任务的需要，向 RM 申请 container，包括数量、所需资源量、所在位置等因素。

3. 如果队列有足够资源，RM 会将 container 分配给有足够剩余资源的 NM，由 AM 通知 NM 启动 container。

4. container 启动后执行具体的任务，处理分给自己的数据。NM 除了负责启动 container，还负责监控它的资源使用状况以及是否失败退出等工作，如果 container 实际使用的内存超过申请时指定的内存，会将其杀死，保证其他 container 能正常运行。

5. 各个 container 向 AM 汇报自己的进度，都完成后，AM 向 RM 注销任务并退出，RM 通知 NM 杀死对应的 container，任务结束。

container设置多少资源合适？

如果 container 内存设置得过低，而实际使用的内存较多，则可能会被 YARN 在运行过程中杀死，无法正常运行。而如果 container 内部线程并发数较多而 vcore 设置的较少，则可能会被分配到一个 load 已经比较高的机器上，导致运行缓慢。所以需要预估单个 container 处理的数据量对应的内存，同时 vcore 数设置的不应该比并发线程数低。

• Yarn复杂运行机制
  - - 工作机制详解
  • Mr程序提交到客户端所在的节点。
  • Yarnrunner向Resourcemanager申请一个Application。
  • rm将该应用程序的资源路径返回给yarnrunner。
  • 该程序将运行所需资源提交到HDFS上。
  • 程序资源提交完毕后，申请运行mrAppMaster。
  • RM将用户的请求初始化成一个task。
  • 其中一个NodeManager领取到task任务。
  • 该NodeManager创建容器Container，并产生MRAppmaster。
  • Container从HDFS上拷贝资源到本地。
  • MRAppmaster向RM 申请运行maptask资源。
  • RM将运行maptask任务分配给另外两个NodeManager，另两个NodeManager分别领取任务并创建容器。
  • MR向两个接收到任务的NodeManager发送程序启动脚本，这两个NodeManager分别启动maptask，maptask对数据分区排序。
  • MrAppMaster等待所有maptask运行完毕后，向RM申请容器，运行reduce task。
  • reduce task向maptask获取相应分区的数据。
  • 程序运行完毕后，MR会向RM申请注销自己。

作业提交过程

作业提交全过程详解

• 作业提交

  第0步：client调用job.waitForCompletion方法，向整个集群提交MapReduce作业。

  第1步：client向RM申请一个作业id。

  第2步：RM给client返回该job资源的提交路径和作业id。

  第3步：client提交jar包、切片信息和配置文件到指定的资源提交路径。

  第4步：client提交完资源后，向RM申请运行MrAppMaster。

• 作业初始化

  第5步：当RM收到client的请求后，将该job添加到容量调度器中。

  第6步：某一个空闲的NM领取到该job。

  第7步：该NM创建Container，并产生MRAppmaster。

  第8步：下载client提交的资源到本地。

• 任务分配

  第9步：MrAppMaster向RM申请运行多个maptask任务资源。

  第10步：RM将运行maptask任务分配给另外两个NodeManager，另两个NodeManager分别领取任务并创建容器。

• 任务运行

  第11步：MR向两个接收到任务的NodeManager发送程序启动脚本，这两个NodeManager分别启动maptask，maptask对数据分区排序。

  第12步：MrAppMaster等待所有maptask运行完毕后，向RM申请容器，运行reduce task。

  第13步：reduce task向maptask获取相应分区的数据。

  第14步：程序运行完毕后，MR会向RM申请注销自己。

• 进度和状态更新

  YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。

• 作业完成

  除了向应用管理器请求作业进度外, 客户端每5分钟都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后, 应用管理器和container会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

资源调度器

​ 目前，Hadoop作业调度器主要有三种：FIFO、Capacity Scheduler和Fair Scheduler。目前默认的资源调度器是Capacity Scheduler。

​ 具体设置详见：yarn-default.xml文件

<property>
    <description>The class to use as the resource scheduler.</description>
    <name>yarn.resourcemanager.scheduler.class</name>
    <value>
 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
    </value>
</property>

先进先出调度器（FIFO）- 优点:调度算法简单，JobTracker（job提交任务后发送得地方）工作负担轻。

缺点:忽略了不同作业的需求差异。例如如果类似对海量数据进行统计分析的作业长期占据计算资源，那么在其后提交的交互型作业有可能迟迟得不到处理，从而影响到用户的体验。

• 容量调度器（Capacity Scheduler）===>Yahoo开发
  - - 多队列支持，每个队列采用FIFO

  • 为了防止同一个用户的作业独占队列中的资源，该调度器会对同一个用户提交多的作业所占资源量进行限定
  • 首先，计算每个队列中正在运行的任务数与其应该分得的计算资源之间的比值，选择一个该比值最小的队列
  • 其次，根据作业的优先级和提交时间顺序，同时考虑用户资源量限制和内存限制对队列内任务排序
  • 三个队列同时按照任务的先后顺序依次执行，比如，job1，job21和job31分别排在队列最前面，是最先运行，也是同时运行

  该调度默认情况下不支持优先级，但是可以在配置文件中开启此选项，如果支持优先级，调度算法就是带有优先级的FIFO。

  不支持优先级抢占，一旦一个作业开始执行，在执行完之前它的资源不会被高优先级作业所抢占。

  对队列中同一用户提交的作业能够获得的资源百分比进行了限制以使同属于一用户的作业不能出现独占资源的情况。

• 公平调度器（Fair Scheduler）===>Facebook开发
  - 1.支持多队列多用户，每个队列中的资源量可以配置，同一个队列中的作业公平共享队列中所有资源

  2.比如有三个队列A，B，C.每个队列中的job按照优先级分配资源，优先级越高分配的资源越多，但是每个job都分配到资源以确保公平。在资源有限的情况下，每个job理想情况下，获得的计算资源与实际获得的计算资源存在一种差距，这个差距叫做缺额。同一个队列，job的资源缺额越大，越先获得的资源优先执行，作业是按照缺额的高低来先后执行的，而且可以看到上图有多个作业同时运行

任务的推测执行

推测执行(Speculative Execution)是指在集群环境下运行MapReduce，可能是程序Bug，负载不均或者其他的一些问题，导致在一个JOB下的多个TASK速度不一致，比如有的任务已经完成，但是有些任务可能只跑了10%，根据木桶原理，这些任务将成为整个JOB的短板，如果集群启动了推测执行，这时为了最大限度的提高短板，Hadoop会为该task启动备份任务，让speculative task与原始task同时处理一份数据，哪个先运行完，则将谁的结果作为最终结果，并且在运行完成后Kill掉另外一个任务。

• 作业完成时间取决于最慢的任务完成时间

  一个作业由若干个Map任务和Reduce任务构成。因硬件老化、软件Bug等，某些任务可能运行非常慢。

  典型案例：系统中有99%的Map任务都完成了，只有少数几个Map老是进度很慢，完不成，怎么办？

• 推测执行机制：

  发现拖后腿的任务，比如某个任务运行速度远慢于任务平均速度。为拖后腿任务启动一个备份任务，同时运行。谁先运行完，则采用谁的结果。

• 执行推测任务的前提条件

  • 每个task只能有一个备份任务；
  • 当前job已完成的task必须不小于0.05（5%）
  • 开启推测执行参数设置，mapred-site.xml文件中默认是打开的。

 <property>
  <name>mapreduce.map.speculative</name>
<value>true</value>
  <description>If true, then multiple instances of some map tasks                may be executed in parallel.</description>
</property>

<property>
  <name>mapreduce.reduce.speculative</name>
  <value>true</value>
  <description>If true, then multiple instances of some reduce tasks 
               may be executed in parallel.</description>
</property>

不能启用推测执行机制情况

• 任务间存在严重的负载倾斜；
• 特殊任务，比如任务向数据库中写数据。

Hadoop企业优化

MapReduce 跑的慢的原因

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

• 计算机性能
  • CPU、内存、磁盘健康、网络
• I/O 操作优化
  • 数据倾斜
  • map和reduce数设置不合理
  • map运行时间太长，导致reduce等待过久
  • 小文件过多
  • 大量的不可分块的超大文件
  • spill次数过多
  • merge次数过多等。

MapReduce优化方法

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

• 数据输入

  • 合并小文件：在执行mr任务前将小文件进行合并，大量的小文件会产生大量的map任务，增大map任务装载次数，而任务的装载比较耗时，从而导致mr运行较慢。
  • 采用CombineTextInputFormat来作为输入，解决输入端大量小文件场景。

• Map阶段

  • 减少溢写（spill）次数：通过调整io.sort.mb及sort.spill.percent参数值，增大触发spill的内存上限，减少spill次数，从而减少磁盘IO。
  • 减少合并（merge）次数：通过调整io.sort.factor参数，增大merge的文件数目，减少merge的次数，从而缩短mr处理时间。
  • 在map之后，不影响业务逻辑前提下，先进行combine处理，减少 I/O。

• Reduce阶段

  • 合理设置map和reduce数：两个都不能设置太少，也不能设置太多。太少，会导致task等待，延长处理时间；太多，会导致 map、reduce任务间竞争资源，造成处理超时等错误。
  • 设置map、reduce共存：调整slowstart.completedmaps参数，使map运行到一定程度后，reduce也开始运行，减少reduce的等待时间。
  • 规避使用reduce：因为reduce在用于连接数据集的时候将会产生大量的网络消耗。
  • 合理设置reduce端的buffer：默认情况下，数据达到一个阈值的时候，buffer中的数据就会写入磁盘，然后reduce会从磁盘中获得所有的数据。也就是说，buffer和reduce是没有直接关联的，中间多个一个写磁盘->读磁盘的过程，既然有这个弊端，那么就可以通过参数来配置，使得buffer中的一部分数据可以直接输送到reduce，从而减少IO开销：mapred.job.reduce.input.buffer.percent，默认为0.0。当值大于0的时候，会保留指定比例的内存读buffer中的数据直接拿给reduce使用。这样一来，设置buffer需要内存，读取数据需要内存，reduce计算也要内存，所以要根据作业的运行情况进行调整。

• IO传输

  • 采用数据压缩的方式，减少网络IO的的时间。安装使用Snappy和LZO压缩编码器。
  • 使用SequenceFile二进制文件。

• 数据倾斜问题

  • 数据倾斜现象

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

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

  • 如何收集倾斜数据

  在reduce方法中加入记录map输出键的详细情况的功能。

HDFS小文件优化方法

• HDFS小文件弊端

  HDFS上每个文件都要在namenode上建立一个索引，这个索引的大小约为150byte，这样当小文件比较多的时候，就会产生很多的索引文件，一方面会大量占用namenode的内存空间，另一方面就是索引文件过大是的索引速度变慢。

• 解决方案

  • Hadoop Archive:

    是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样就减少了namenode的内存使用。

  • Sequence file：

    sequence file由一系列的二进制key/value组成，如果key为文件名，value为文件内容，则可以将大批小文件合并成一个大文件。

  • CombineFileInputFormat：

    CombineFileInputFormat是一种新的inputformat，用于将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置。

  • 开启JVM重用

    对于大量小文件Job，可以开启JVM重用会减少45%运行时间。

    JVM重用理解：一个map运行一个jvm，重用的话，在一个map在jvm上运行完毕后，jvm继续运行其他map。

    具体设置：mapreduce.job.jvm.numtasks值在10-20之间。