hadoop之 mapreduce data flow

注：随笔 取自于 hadoop权威指南第四版

Hadoop 会讲MapReduce输入的数据切分红大小相等的数据块（fixed-size 固定大小，我认为翻译成相等大小比较合适），或者称之为分片。Hadoop会未每个分片建立一个map 任务，并由该任务来运行用户自定义的map函数。

一个输入数据能够切分红许多切片，咱们可使用map并行处理这些切片，缩短整个任务处理过程的时间。固然分片并非切分的越小越好，越多的分片就须要花费越多的时间去管理分片以及 增长构建map的时间。然而对于大多数的做业来讲，比较合理的方式是 分片的大小是等于 block size。

若是在存有数据集的节点上运行map任务，hadoop将会得到更好的性能，由于这无需使用集群的带宽资源。这被称为data locality optimization。可是，有时候会有这么一种状况，当前map任务的输入数据存储的三个HDFS节点上都有其余map任务在运行，此时，做业调度会在三个备份中的某个数据寻求同个机架中空闲的机器运行该map任务。固然若是未寻找到合适的机器，会使用其余机架中的机器运行该map任务，不过这种状况发生的几率比较小。下图展现了这三种可能性。

It should now be clear why the optimal split size is the same as the block size: it is the largest size of input that can be guaranteed to be stored on a single node.
分片的大小不超过block size，能够确保输入的数据存储在单个节点上。若是分片跨越两个数据块，在一个HDFS节点上，几乎不可能同时存储这两个block，那么部分输入数据须要经过网络进行传输。与使用本地数据相比，这种方法明显不够明智。

Map 函数产生的中间文件不会写入HDFS，而是写在了本地。缘由是map输出的是中间结果，须要通过reduce的处理后才能产生最终结果。看成业完成时，map输出的结果能够删除。所以，若是将中间结果存储在HDFS并备份，overkill（过分，或者叫小题大作）。若是该节点运行的map任务在将结果传输到reduce以前失败，hadoop会自动在其余节点重现运行map任务，并产生中间结果。

reduce任务并不具有本地化优点。单个的reduce任务的输入一般来自于全部mapper的输出。在http://www.cnblogs.com/re-myself/p/5518283.html 例子中，只有一个reduce任务，其输入是全部map任务的输出。通过排序的map输出需经过网络传输发送到运行reduce任务的节点，并在reduce函数中进行合并、运算。reduce的输出结果存储在HDFS中。reduce输出时，第一个replica 会存储在本地节点，其余replica会存储在其余的机架节点中。所以，reduce输出确定会占用网络带宽，可是和正常的写入消耗是同样的。
下图是一个reduce任务的 MapReduce 数据流

reduce任务的数量并不是由输入数据决定，须要独立指定。
the map tasks partition their output, each creating one partition for each reduce task
若是有多个reducers，map会将其输出进行分区，每个reduce任务都会建立一个分区。每一个分区都会有许多个键（还有其对应的值），可是每一个键值对记录都在同一个分区中（There can be many keys (and their associated values)in each partition, but the records for any given key are all in a single partition）。分区由用户定义partition函数控制。默认的partitioner是经过hash函数分区。

上图未多个reduce任务的数据流图

mapreduce能够没有reduce。数据处理能够彻底并行，不须要shuffle。在这种状况下，惟一的非本节点的传输是map任务将结果写入HDFS。（In this case, the only off-node data transfer is when the map tasks write to HDFS）