笔记 Hadoop

今天有缘看到董西成写的《Hadoop技术内幕：深入解析MapReduce架构设计与实现原理》，翻了翻觉得是很有趣的而且把hadoop讲得很清晰书，就花了一下午的时间大致拜读了一下（仅浏览了感兴趣的部分，没有深入细节）。现把觉得有趣的部分记录如下。

JobControl

把各个job配置好后，放入JobControl中，JobControl会根据它们之间的依赖关系，分别进行调度。

工作流引擎

　　除了JobControl外，还可以使用Oozie和Azkaban来进行工作流控制。相较于前者而言，Oozie和Azkaban可以使用图形化界面观看工作流的处理进度，另外还有其他更丰富的功能。

JobTracker

（Master）

是一个后台服务程序，启动后会一直监听并接收来自各个TaskTacker发送的心跳信息。心跳信息中包含节点资源的使用情况和任务运行情况。

作业控制：JobTracker在其内部以“三层多叉树”的方式描述和跟踪每个作业的运行状态。

当任何一个Task Attemp运行成功后，其上层对应的TaskInProgress会标注该任务运行成功；而当所有的TaskInProgress运行成功后，JobInProgress会标注整个作业运行成功。

JobTracker如何查找和定位各种对象？

为了查找和定位各种对象，JobTracker将相关信息封装成各种对象后，以key/value的形式保存到Map结构中。（在JDK中，Map以红黑树来实现）

1、作业ID查找对应的JobInProgress对象

2、查找每个TaskTracker上运行的task

JobTracker的各种 操作（如监控、更新），实际上就是修改这些Map关系。

不过JobTracker存在单点故障（因为是Master/Slave结构）。如果已保存的任务或节点状态丢失，则所有正在运行的作业将会失败。

TaskTracker

（slave）

①运行于各个节点上的服务

②是JobTracker与Task之间的沟通桥梁，在两者间使用RPC进行通信。

对JobTracker和TaskTracker而言，前者为server，后者为client。

对TaskTracker和Task而言，前者为server，后者为client。

③执行两个功能：汇报心跳和执行命令

Hadoop对快排的优化

（1）轴枢选择

Hadoo将序列的首尾和中间元素的中位数作为轴枢，以避免出现极端不对称子序列的情况。（极端不对称子序列会导致快排算法的退化）

（2）子序列的划分

使用两个索引 i 和 j 分别从左右两端对序列进行扫描，并让索引i扫描到大于等于轴枢的元素停止，j扫描到小于等于轴枢的元素停止，然后交互两个元素（交换时索引不动），重复这个过程知道i和j相遇。

（3）对相同元素的优化

在每次划分子序列时，将与枢轴相同的元素集中存放在中间位置，让它们不再参与后续的递归处理，即将序列划分为三部分：小于轴枢、等于轴枢、大于轴枢。（这也是由于hadoop排序中会出现大量相等值的原因，这样做可以通过减少递归排序的数量从而提高算法的效率）

（4）减少递归次数

当子序列中元素数目小于13时，直接使用插入排序算法，不再使用递归。

第一代MapReduce框架的局限性

①扩展性差

JobTracker兼具资源管理和作业控制两个功能，因此成为系统性能扩展的最大瓶颈。

②单点故障

master/salve结构的通病

③资源利用率低

因为使用slot为资源分配模型，但slot粒度大，而且MapSlot和ReduceSlot不能share，因而会出现一种slot资源紧张而另一种空闲的尴尬状况。

④无法支持多种计算框架

几种比较vogue的框架有：

MapReduce：支持离线处理，可以被搜索引擎公司用于建立网页索引。

Storm：支持在线处理，tweeter使用的框架

Spark：迭代式计算框架，可以用于自然语言处理、数据挖掘，如PageRank计算、分类、聚类。对性能要求高的DM，可以使用MPI。

S4：流式处理框架，Yahoo。

而第一代的Hadoop只能支持MapReduce这一种计算框架。

互联网公司希望可以将这些框架统一用到自己的集群资源上，因此诞生了资源管理与调度平台，典型的代表有：

YARN（Apache），现可以运行MapReduce和Storm（今天才在InfoQ上看到的新闻）

Corona（Facebook）

Mesos（Berkeley）

转载于:https://www.cnblogs.com/elaron/p/3146429.html