标签：
前面展示了 MapReduce 针对 小量 输入的 工作方式，
现在是时候 整体 了解 系统 并 进入 大数据 流 作为 输入了。
为简单起见，我们的例子 到目前为止 都使用 本地 文件系统 中的文件。
然而 ， 为了 分布化，我们需要 把 数据 存储在 分布式文件 系统中， 典型的如 HDFS ，
以允许 Hadoop 把 MapReduce 的 计算 移到 承载 部分 数据的 各台机器。
下面 我们 就来 看看 这是如何 工作的。
数据流
首先是一些 术语 的 说明。
MapReduce 作业（job）是 客户端执行的单位： 它 包括输入数据、 MapReduce 程序 和 配置信息。
Hadoop 通过把 作业分成 若干个小任务 （task）来工作，其 包括 两种 类型的任务： map 任务 和 reduce 任务。
有两种类型的 节点 控制着 作业执行过程： jobtracker 和 多个 tasktracker 。
jobtracker 通过调度任务 在 tasktracker 上 运行，来协调 所有 运行在 系统上的 作业。
Tasktracker 运行任务的 同时， 把 进度 报告传送 到 jobtracker， jobtracker 则 记录着 每项 任务 的 整体 进展情况。
如果 其中一个任务 失败， jobtracker 可以 重新 调度任务 到另外 一个 tasktracker .
Hadoop 把 输入数据 划分成 等长 的 小数据 发送 到 MapReduce , 称为 输入 分片（input split） 或 分片。
Hadoop 为 每个 分片( split ) 创建一个map 任务， 由 它 来 运行 用户 自定义的 map 函数 来 分析 每个 分片 中的 记录。
拥有 许多 分片 就意味着 处理 每个 分片 的 时间 与 处理 整个 输入的 时间 相比 是比较小的。
因此， 如果 我们 并行 处理 每个 分片， 且 分片 是 小块的数据， 那么 处理过程 将 有 一个更好的 负载 平衡，
因为 更快 的 计算机 将 能够 比 一台 速度 较慢 的 机器 在 作业 过程 中 处理完 比例 更多 的 数据 分片。
即使是 相同的 机器， 没有 处理的 或 其他同时运行的 作业 也会 使 负载平衡得以实现，
并且 在 分片变得 更细时， 负载平衡 质量 也会 更佳。
另一方面，如果 分片太小，那么 管理 分片的总时间 和 map 任务 创建的 总时间 将 决定 作业的 执行的 总时间。
对于 大多数 作业， 一个 理想的 分片 大小往往 是 一个 HDFS 块 的 大小， 默认是 64 MB，
虽然 这 可以 根据 集群 进行 调整 （对于 所有 新建 文件） 或 在 新建 每个 文件 时 具体 进行 指定。
map 任务 的 执行 节点 和 输入 数据的 存储 节点 是 同一个 节点，
Hadoop 的 性能 达到最佳。 这就是 所谓的 data locality optimization ( 数据局部 性 优化 )。
现在我们应该 清楚 为什么 最佳 分片 的 大小 与 块 大小 相同： 它是 最大的 可 保证 存储在单个节点上的数据量。
如果 分区 跨越 两个 块， 那么 对于 任何一个 HDFS 节点 而言， 基本 不可能 同时 存储 这 两 数据块，
因此 此 分布的 某部分 必须 通过 网络 传输到节点， 这 与 使用 本地 数据 运行 map 任务 相比， 显然 效率 更低。
map 任务 把 输出 写入 本地 硬盘， 而不是 HDFS。 这是为什么？
因为 map 的 输出 作为 中间 输出： 而 中间输出 则 被 reduce 任务 处理 后 产生 最终的 输出， 一旦 作业 完成， map 的 输出 就可以 删除了。
因此 ， 把 它 及其 副本 存储 在 HDFS 中， 难免 有些 小题 大做。
如果 该 节点 上 运行的 map 任务 在 map 输出 给 reduce 任务 处理 之前 崩溃，
那么 Hadoop 将 在另一个i 节点 上 重新 运行 map 任务 以 再次 创建 map 的 输出。
reduce 任务 --54
标签：
原文地址：http://www.cnblogs.com/duffy/p/5374851.html
