谈笑间学会MapReduce-优化Reduce任务核心原理

Reduce任务核心原理

reduce任务的处理阶段

reduce任务处理是包含三个阶段的一个序列。除用户定义的reduce函数的执行是定制的之外，还有其持续时间依赖于每个阶段流经的数据量以及底层Hadoop集群的性能。对每个阶段进行性能分析有助于识别潜在瓶颈以及低速的数据处理。下面给出reduce任务的三个主要阶段

详细分析一下reduce的每一个阶段：

对于Shuffle阶段的性能分析意味着需要测量从map任务向reduce任务传输中间数据所花的时间，以及对其进行合并与排序所花的时间。在Shuffle阶段，Map阶段产生的中间数据被获取。这一阶段的处理时间主要依赖于Hadoop配置参数以及传递给reduce任务的中间数据的量。

在Reduce阶段，每个reduce任务被分配了固定键范围标记的map输出中间数据的一个分区；这样，reduce任务必须从集群中每个map任务的输出获取分区的内容。执行时间就是输入键以及对应的所有值上执行用户提供的reduce函数的时间。要对Reduce阶段进行性能分析，需要测量执行时间，而执行时间又依赖于输入数据的大小。

对Write阶段也就是最后一个阶段，进行性能分析，需要测量把reduce输出写到HDFS所花的时间。

计算reduce任务的吞吐量

在reduce端，造成运行速度降低的原因可能是不良或者未经优化的reduce函数用户代码、硬件问题或者Hadoop框架的不当配置。要确定reduce任务的吞吐量，需要通过Hadoop I/O计算器计算（就像上篇计算map任务的吞吐量一样）。
假设有一个使用N个reduce任务的MapReduce作业，可通过以下公式计算吞吐量（字节/秒）:

吞吐量（N个reduce任务） = sum(每个reduce输入的shuffle字节数) / sum(每个reduce执行秒数)
下图分别显示了reduce任务的吞吐量所需的Hadoop计数器、执行时间。

reduce阶段总的执行时间为三个阶段执行时间的聚合：Shuffle执行时间、Sort时间以及Reduce函数执行时间。Hadoop日志能够给出上述每一步骤的执行时间，如上图所示。

计算Shuffle阶段和Sort阶段的吞吐量同样轻松。Shuffle字节数/Shuffle执行时间（秒）就计算出Shuffle吞吐量。而且，要计算Sort阶段的吞吐量，需要Shuffle字节数除以Sort执行时间（秒），即

Shuffle吞吐量 = Shuffle字节数 / Shuffle时间

Sort吞吐量 = Shuffle字节数 / Sort时间。
如上述公式可得，如果Shuffle时间或者Sort时间为0，会导致上述公式出现零除错误。Shuffle吞吐量和Sort吞吐量与Shuffle和Sort时间成反比。也就是说Shuffle时间、Sort时间越接近0，Shuffle吞吐量和Sort吞吐量就越大，也就是说Shuffle时间、Sort时间最短的时候，吞吐量最大。

改善reduce执行阶段

一旦map任务完成数据处理，在不同时间Shuffle的map输入数需要合并为单个reduce输入文件，并且在提交reduce任务使用之前需要按照键排序。map输出的大小依赖于其输入数据集的大小。在Shuffle阶段和Sort阶段提高性能最简单的手段就是压缩排序和合并的数据量。这一般通过使用combiner、数据压缩和数据过滤来完成。

本地磁盘问题和网络问题是Shuffle阶段、Sort阶段性能问题的常见来源，这是由于MapReduce框架读取本地一些输入，并将其反馈给reduce代码。在reduce阶段内，经常会发现map任务和reduce任务间接传输造成大规模网络流量。Hadoop有几个可供调优的配置参数，可以提高这一阶段的性能。

下图列出了改善reduce阶段客户以调整的常见参数：

通过把mapred.job.reduce.input.buffer.percent 设置为0.8 ，缓冲区可以利用80%，reducer输入数据可以借此保存在内存中。默认值为0.0 标识map输出合并到本地磁盘而非内存。

还有一项建议是在Shuffle阶段最大化内存分配，以存储map输出。因此，可以把，mapred.job.reduce.input.buffer.percent 的值增加到0.9，以使用90%的内存堆而不是70%的默认值。

调优map和reduce参数

正确选择一项作业的任务数量对Hadoop性能有着巨大的影响，但是mapper和reducer的正确量化还不足以使MapReduce作业达到最佳性能。最佳是指在作业执行时的任意时刻集群中的每台机器都有事做，记住Hadoop框架有180多个参数，而其中大多数都不应该保持默认配置。

mapper的个数，理论上限通过  输入文件大小 / 使用块大小计算得到。但是输入文件的处理是由固定数量的CPU核（mapper数 = （物理核数 - 保留核数） x (0.95~1.75)）的机器完成。也就是说，在一个三个节点的集群上-每个节点8个CPU核和256MB内存-要处理10GB文件，mapper的最优数在 37~40。mapper上限为10GB / 0.25GB = 40。mapper最优数计算方法如下：

基于CPU核数的mapper数 = （8个核 - 1个保留核）x 1.75 = 12.25

集群mapper容量 = 12.25 x 3 = 37.5

可以使用各种不同的方法确定mapper和reducer的精确数量。所有这些方法均基于计算与调优，或者仅仅基于实际经验调整。
建议1:

reducer的数量设为集群容量的50~90% ,以便所有reducer在一批完成。这种方法建议reducer数的计算公式：reducer = (0.5~0.95) x 节点数 x reducer槽数
建议2:

reducer槽数和mapper槽数相同，或者至少是mapper数量的三分之二。小规模集群或者开发环境下，这种方法设置reduce数量是最容易的方式，要确定reducer数量的下限（每节点CPU/2）。也可以使用三分之二的mapper方法来决定范围内的reducer的数量。
建议3:

推荐两个基于集群节点数和CPU核数的公式，用来确定mapper和reducer的数量。这些公式可以用作计算上述数量的七点，然后再实际环境下对其进行调优达到最优值。用集群几点计算mapper和reducer的数量，

使用公式：reducer数 = （0.95~1.75）x （节点数 x mapred.reduce.parallel.copies）。

这里，0.95~1.75为CPU超线程因子，而mapred.reduce.parallel.copies为并行运行reducer的最大数目。用CPU核数计算mapper和reduce数量，

使用公式：reduce数 = （0.95~1.75） x (CPU核数目 - 1)。

举个栗子：

（假设我们有一个集群，三个节点，每个节点一个四核CPU，4GB内存，40GB磁盘空间），下图通过不同方法计算汇总

我们对测试集群环境采用了第三和第四中方法的计算结果，结果显示于下表的调优2和调优3列。通过与调优1列对比，我们需要增加块大小（以前的迭代是256MB和128MB），并通过mapred.child.java.opts参数分配更多的内存（-Xmx550m）

小结：

我们了解了Map和Reduce的阶段和过程，块大小对性能的影响，以及通过计算mapper数和reducer数来调优MapReduce配置并提高性能的方法。

 

参考资料：Hadoop MapReduce性能优化