第2章 
关于MapReduce

2.1 Hadoop集群架构

图 2.1 Hadoop集群架构图

在图2.1中包括分布式数据处理模型MapReduce，分布式文件系统HDFS。

2.1.1 MapReduce模型之Job与Nodes

Ø 
一个job由若干task组成：

l 
若干 map tasks

l 
若干 reduce tasks

Ø 
控制job运行的两类nodes:

l 
1个 jobtracker：协调和控制系统中运行的所有jobs，以及所有在tasktrackers上运行的tasks

l 
若干 tasktrackers：运行task，并向jobtracker发送进度报告（记录了每一个job的运行进度）

l 
如果一个task失败了，jobtracker可以将其重新部署到另一个tasktracker上运行

2.1.2 HDFS之Namenode与Datanode

Ø 
Namenode与Datanode是HDFS中的概念。

Ø 
被存储在HDFS中的数据以block为单位存储，且每一个block被复制多份存储在不同节点，以提供可靠性保证和高速访问。

Ø 
HDFS采用master-slaves的架构：

l 
master管理数据文件的namepace
(如metadata，目录结构，文件到blocks的映射，blocks的位置，访问权限等)

l 
slaves则管理实际的数据blocks

l 
master指导client对数据进行访问

Ø 
在GFS中

l 
master被称作GFS
master

l 
slaves被称作GFS
chunkservers

Ø 
在Hadoop中

l 
master被称作namenode

l 
slaves则被称作datanodes

图 2.2 MapReduce层与HDFS层的对应关系

2.1.3 HDFS架构

图2.3 HDFS架构图

2.2
数据流

图2.4 MapReduce执行过程数据流

2.2.1 Input splits, and records

Ø 
MapReduce的输入（input file）被切分为固定大小的input
splits，简称split

Ø 
Hadoop为每一个split都创建一个map
task，该map task中的map函数会作用于split中的每一个record.

Ø 
一个record就是一个key-value
pair

注意：

input split是对record（即key-value pair）在逻辑上的切分，而HDFS中的block是对输入数据的物理切分。当两者一致时，很高效，但是实际中往往不一致。record可能会跨越block的边界。

2.2.2 Split的大小选择

Ø 
Split不该太大（失去parallel性）

Ø 
也不该太小（额外的开销占比过大）

Ø 
与HDFS中的一个Block的大小相同较为合适（Block默认为64BM）

2.2.3移动计算，而不是移动数据

Ø 
Task在运行时需要数据

Ø 
Job scheduler会在已经有了所需数据的节点上启动对应的task，这样就实现了data
locality

2.2.4 map
与
reduce 的输出

Ø 
Map task的输出将被写入磁盘（Linux文件系统），而不是HDFS文件系统。为什么？

l 
Map的输出是中间临时结果（intermediate key-value pairs），它们作为reduce
tasks的输入

l 
一旦job结束，这些中间临时结果即被丢弃，不再需要

l 
如果存入HDFS，就需要复制多份副本在网络上传输，浪费！

Ø 
Reduce task的输出会被写入到HDFS文件系统中

l 
毕竟，它们的输出是用户最终需要的结果，要妥善保存

2.2.5
只有1个reduce
task的数据流图

图2.5
只有一个Reduce的数据流

参考消息：
Hadoop、HDFS数据流 解析 第二版 - (肖韬 南京大学计算机系)

Hadoop权威指南