Hadoop（27）hadoop的企业级调优

hadoop的企业级调优

HDFS参数调优hdfs-site.xml

(1) 设置参数dfs.namenode.handler.count

dfs.namenode.handler.count=20 * log2(Cluster Size)
//该参数用来调整namenode处理客户端的线程数，根据20 * log2(Cluster Size)这个公式来估计即可，Cluster Size是集群的NameNode节点个数

比如集群规模为8台时，此参数设置为60=20*log2(8)

NameNode有一个工作线程池，用来处理不同DataNode的并发心跳以及客户端并发的元数据操作。对于大集群或者有大量客户端的集群来说，通常需要增大参数dfs.namenode.handler.count的默认值10。设置该值的一般原则是将其设置为集群大小的自然对数乘以20，即20logN，N为集群大小。

（2）编辑日志存储路径dfs.namenode.edits.dir设置与镜像文件存储路径dfs.namenode.name.dir尽量分开，达到最低写入延迟。

（3）元数据信息fsimage多目录冗余存储配置

YARN参数调优yarn-site.xml

根据实际调整每个节点和单个任务申请内存值

（1）yarn.nodemanager.resource.memory-mb

表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。

（2）yarn.scheduler.maximum-allocation-mb

单个任务可申请的最多物理内存量，默认是8192（MB）。

Hadoop宕机

（1）如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）

（2）如果写入文件过量造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。高峰期的时候用Kafka进行缓存，高峰期过去数据同步会自动跟上。

mapreduce运行慢的主要原因

1、计算机性能出现瓶颈：

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

2、I/O操作需要优化：

• 数据倾斜
• Map和Reduce数目设置不合理
• map运行时间太长、导致reduce等待太久
• 小文件过多
• 大量的不可分块的超大文件
• Spill溢写次数过多
• Merge次数过多等

mapreduce的优化方法

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

数据输入阶段

• 合并小文件
• 采用CombineTextInputFormat作为输入类，解决输入端大量小文件场景

MapTask运行阶段

• 减少溢写Spill次数:

  通过调整io.sort.mb参数来增大环形缓冲区大小，通过调整sort.spill.percent参数增大达到溢写条件的百分比。

• 减少合并Merge次数:

  通过调整io.sort.factor参数，增大Merge的文件数目，从而减少合并次数。

• 在Map之后，不影响业务逻辑的前提下，优先考虑进行规约Combine处理，减少I/O的使用

ReduceTask运行阶段

• 合理设置Maptask和reducetask个数，不能太少不能太多。

  太少会导致task等待，延长处理时间

  太多会导致Maptask与reducetask间竞争资源，造成处理超时等错误

• 设置Maptask、Reducetask的共存时间：

  我们知道，在Maptask任务完成5%后，集群就开始启动reducetask，那么我们把5%调为更小的值的话，reducetask就启动得更快，可以提早把reducetask要使用地资源通过网络拉取过来，maptask和reducetask的共存时间就更长了。

• 能不用Reducetask就不使用Reducetask

  因为reduce连接数据集的时候会产生大量的网络消耗。

• 合理设置Reduce端的Buffer

  在reducetask的copy阶段，ReduceTask从各个MapTask上远程拷贝一片数据，并针对某一片数据，如果其大小超过一定阈值，则写到磁盘（hdfs文件系统）上，否则直接放到内存Buffer中。如果数据写到了磁盘上，我们reduce是直接从磁盘读数据来运行任务的，效率较低。

  那么我们可以设置mapreduce.reduce.input.buffer.percent参数来指定Buffer中的一定比例的数据可以直接给reduce任务使用。但是要合理设置，以免占用过多内存资源。

  

IO传输阶段

• 压缩数据，减少数据量
• 使用SequenceFile二进制文件

数据倾斜问题

• 数据频率倾斜：某个区域数据量远远大于其它区域
• 数据大小倾斜：部分记录的大小远远大于平均值

解决方法：

方法1：抽样和范围分区，原理示意图如下：

方法2：自定义分区

方法3：进行规约Combine

方法4：采用map join，避免使用reduce join

抽样和范围分区的原理示意图如下：

常用的调优参数

资源相关参数

以下参数是在用户自己的Mapreduce应用程序中配置就可以生效（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

以下参数应该在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

Shuffle性能优化的关键参数

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

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

容错相关参数(MapReduce性能优化)

配置参数	参数说明
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.”。