影响MapReduce性能的几个因素

Hadoop MapReduce性能优化
影响MapReduce输入数据处理时间的因素不少。其中之一是实现map和reduce函数时使用的算法。其余外部因素也可能影响MapReduce性能。根据咱们的经验和观察，可能影响MapReduce的主要因素有如下几个。

• 硬件（或者资源）因素，如CPU时钟、磁盘I/O、网络带宽和内存大小。
• 底层存储系统。
• 输入数据、分拣（shuffle）数据以及输出数据的大小，这与做业的运行时间紧密相关。
• 做业算法（或者程序），如map、reduce、partition、combine和compress。有些算法很难在MapReduce中概念化，或者在MapReduce中效率可能会下降。

运行map任务时，shuffle子任务的中间输出存储在内存缓冲区中，用以减小磁盘I/O。输出的大小可能会超过内存缓冲区而形成溢出，所以须要spill子阶段把数据刷新到本地文件系统。这个子阶段也会影响MapReduce性能，它常常采用多线程技术实现，以便使磁盘I/O利用率最大化并缩减做业的运行时间。

MapReduce编程模型容许用户使用本身的map和reduce函数指定数据转换逻辑。本模型并不限定map函数产生的中间对在交由reduce函数处理前如何被分组。所以，归并排序（merge-sort）算法被用做默认的分类算法。然而，归并排序算法并不是老是最高效的，尤为是对分析型任务（如聚合和等值链接）而言，这类任务并不关心中间键的顺序。

提示.tif对于MapReduce编程模型来讲，分组（grouping）/划分（partitioning）是一个串行的任务。这就意味着在reduce任务能够运行以前，框架须要等待全部map任务完成。

想要深刻学习归并排序算法，请参考http://en.wikipedia.org/wiki/Merge_sort。
MapReduce性能是以map和reduce的运行时间为基础的。这是由于典型环境下集群节点数目和节点插槽数目这类参数是不可修改的。

其余可能对MapReduce性能构成潜在影响的因素具体以下。

• I/O模式：也就是从存储系统获取数据的方式。从底层存储系统读取数据有如下两种模式。
  直接I/O：经过硬件控制器把数据从本地硬盘缓存中直接读到内存，于是不须要进程间通讯成本。

流式I/O：经过特定进程间通讯手段，如TCP/IP和JDBC，从其余正在运行进程（典型状况是存储系统进程）读取数据。

从提升性能的角度看，使用直接I/O比流式I/O更高效。

• 输入数据解析：是指从存储系统获取数据时，从原始数据到键值对的转换过程。数据解析过程的目标是把原始数据按照原来的格式解码，并转换为可供Java等编程语言处理的数据对象。

输入数据能够解码为（Java或者其余语言）对象，这样当对象实例建立后，对象内容能够改变，典型的状况是使用对对象实例的引用（这样的对象叫作可变对象），输入数据也能够解码为一经建立其内容就不可改变的对象（叫作不可变对象）。在上百万条记录的状况下，不可变对象的解码过程会明显比可变对象的解码过程慢，这是由于在前者解码过程当中产生了大量不可变对象。所以，这会致使系统性能的下降。 - 输入数据存储：当MapReduce获取数据并进行进一步处理时，所在的存储系统必须保证高速访问和数据可用性（如HDFS和HBase）。若是选用的不是那些推荐的与MapReduce一块儿使用的存储文件系统，那么输入数据的访问会潜在地影响MapReduce性能。

使用Hadoop框架时，许多因素可能会影响整个系统的性能和做业的运行时间。这些因素多是Hadoop MapReduce引擎的一部分，也多是引擎以外的。

Hadoop配置参数一般会影响并发运行的任务数，并决定做业的运行时间，由于Hadoop集群被创建且做业开始执行后，其余因素就不可改变了。若是Hadoop框架配置不当，可能没法充分利用集群资源，并所以影响MapReduce做业性能。这是由于大量的配置参数控制着Hadoop框架的行为。

一项Hadoop做业常常由许多实现不一样算法的子模块组成，这些子模块要么以串行方式链接，要么以并行方式链接。若是Hadoop框架配置不当，可能会影响内部任务完成的协做方式。全部这类参数（将在第2章讨论）设置的影响都依赖于map和reduce函数的代码、集群资源，固然还有输入数据。

MapReduce做业的性能也可能受Hadoop集群节点数的影响，以及受全部节点中运行map和reduce任务的可用资源的影响。每一个节点的容量决定了一个节点能够执行的mapper和recducer任务的数量。所以，若是节点资源利用不充分或者过分利用，都会直接影响MapReduce任务的性能。