Hadoop再探讨

hadoop只有MapReduce和HDFS组件的时候的不足

1)抽象层次低，需要大量的人工编码
2)表达能力有限(不是所有的问题都能转化成MapReduce)
3)开发者自己管理作业(job)之间的依赖关系
4)难以看到程序整体逻辑(只能通过看代码才能理解到其中执行的逻辑)
5)执行迭代操作效率低(每执行一次都需要读写一次磁盘)
6)资源浪费(Map和Reduce分两个阶段运行)
7)实时性差(适合批注理，不支持实时交互)

优化：1>自身核心组件MapReduce和HDFS的改进(hadoop2.0)

2>其他组件的不断加入和更新(pig、spark、kafka和tez等组件)

HDFS HA(high available解决热备份的问题)

HDFS HA是为了解决单点故障问题
HA集群设置两个名称节点，“活跃”和“待命”
两个名称节点的状态同步，可以借助于一个共享存储系统来实现(实现同步Editlog)
一旦活跃名称节点出现故障，就可以理解切换到待命名称节点
Zookeeper确保一个名称节点在对外服务(只能有一个节点对外提供服务)
名称节点维护映射信息，数据节点同时向两个名称节点汇报信息(实现同步FSImage)

HDFS Feferation(解决扩展性、系统的吞吐量(性能)、隔离性)

HDFS Feferation中设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平的扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟(Feferation)的关系，不需要彼此协调。

HDFS Feferation所有的名称节点共享底层的存储资源，数据节点向所有的名称节点汇报
属于同一命名空间的块构成一个“块池”(块池是一个逻辑的概念，最终还是有底层的数据节点来存储数据)

HDFS Feferation的访问

对于Feferation中的多个命名空间，采用客户端挂载表的方式对数据进行数据共享和访问。客户端可以通过访问不同的挂

载点来访问不同的子命名空间。把各个命名空间挂载到全局“挂载表”中，实现数据的全局共享。同样的命名空间挂载到个人的挂载表中，就成为应用程序可见的命名空间。

HDFS Feferation解决的问题

1>HDFS集群扩展性。多个名称节点各自管理一部分的目录，使得一个集群可以扩展到更多的节点，存储的文件数目不再受
单个机器内存限制。

2>性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。
3>良好的隔离性。用户根据需要将不同业务数据交给不同的名称节点管理，这样不同业务之间的影响很小。

PS：HDFS Feferation不能解决单点故障问题，也就是每一个名称节点都存在单点故障的问题，需要为每一个名称节点部署一个

后备的名称节点(每个名称节点都启用一个high available)，以应对某个名称节点挂掉对业务的影响。

YARN

在Hadoop1.0中MapReduce不仅是一个计算框架，还是一个资源管理调度框架。这样就导致JobTacker管的太多，任务多时开销

太多，容易内存溢出。分配资源之考虑MapReduce任务数量，不考虑不同任务间的CPU、内存使用率，资源划分不合理。

解决思路：将JobTacker功能拆分。将MapReduce1.0中资源管理的功能分离出来，单独形成YARN框架。这样，YARN就是一个

纯粹的资源管理调度框架，MapReduce就是一个纯粹的计算框架。

YARN的体系结构

ResourceManager

ResourceManager(RM)是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件，即调度器和应用

程序管理器。

调度器接受来自ApplicationMaster的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器

的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算想数据靠拢”。

容器作为动态资源分配单位，每个容器中都封装一个内存、cpu、磁盘等资源，从而限定每个应用程序可以使用的资源量。

调度器被设计成一个可插拔的组件，YARN不仅自身提供了许多种直接可用的调度器，也允许用户更具自己的需求重新设计

调度器。

应用程序管理器(Application Manager)复制系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启等。

ApplicationMaster

ResourceManager接受用户提交的作业，按照作业的上下文信息以及从NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一个ApplicationMaster。

ApplicationMaster主要功能：

1>当用户提交作业时，ApplicationMaster与ResourceManager协商获取资源，ResourceManager会以容器的形式为ApplicationMaster分配资源。

2>把获得的资源进一步分配给内部的各个任务(map任务和reduce任务)，实现资源的“二次分配”。

3>与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复(即重新申请资源重启任务).

4>定时向ResourceManager发送“心跳”信息，报告资源的使用情况和应用的进度信息。

5>当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。

NodeManager

NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责：

1>容器生命周期的管理
2>监控每个容器的资源(CPU、内存等)使用情况
3>跟踪节点的健康情况
4>以“心跳”的方式和ResourceManager保持通信
5>向ResourceManager汇报作业的资源使用情况和每个容器的运行状态
6>接受来自ApplicationMaster的启动/暂停容器的各种请求

PS：NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务(Map任务或Reduce任务)自身状态的管理，因为这些管理工作是有ApplicationMaster来完成的，ApplicationMaster会通过不断的与NodeManager通信来掌握各个任务的执行状态。

YARN部署

在集群部署的时候，YARN的各个组件是和Hadoop集群中的其他组件进行统一部署的，而不是独立部署的。

YARN的工作流程

1>用户编写客户端应用程序，向YARN提交应用程序，提交的内容有ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

2>YARN中的ResourceManager负责接收和处理来自客户端的请求，为应用程序分配一个容器，在该容器中启动一个ApplicationMaster。

3>ApplicationMaster被创建后会首先向ResourceManager注册
4>ApplicationMaster采用轮询的方式向RrsourceManager申请资源
5>RrsourceManager以容器的形式向申请资源的ApplicationMaster分配资源
6>在容器中启动任务
7>各个任务向ApplicationMaster汇报各自的状态和进度
8>应用程序运行完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己。

YARN的目标

YARN就是为了实现"一个集群多个框架"，即在一个集群框架上部署一个统一的资源调度管理框架YARN，在YARN之上可以部署其他各种计算框架。

由YARN为这些计算框架提供统一的资源调度管理服务，并且能够根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩。

可以实现一个集群上的不同应用负载混搭，有效提高了集群的利用率

不同计算框架可以共享底层存储，避免了数据集跨集群移动

Tez

Tez的核心思想：

核心思想是将Map和Reduce两个操作进一步拆分。

Map被拆分成Input、Processor、Sort、Merge和Output。

Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等。

分解后的元操作可以任意灵活组合，产生新的操作。

这些操作经过一些控制程序组装后，可形成一个大的DAG作业。

通过DAG作业的方式运行MapReduce作业，提供了程序运行的整体处理逻辑，就可以去除工作流当中多余的Map阶段，减少不必要的操作，提升数据处理的性能。

Tez实例分析。

SELECT a.state, COUNT(*),AVERAGE(c.price)
FROM a
JOIN b ON (a.id = b.id)
JOIN c ON (a.itemId = c.itemId)
GROUP BY a.state

Tez的优化主要体现在：去除了连续两个作业之间的"写入HDFS"；去除每个工作流中多余的Map阶段。

在Hadoop2.0生态系统中，MapReduce、Hive、Pig等计算框架，都需要最终以MapReduce任务的形式执行数据分析，因此，Tez框架可以发挥重要的作用。借助Tez框架实现对MapReduce、Pig和Hive等的性能优化。可以解决现有MapReduce框架在迭代计算(如PageRank)和交互式计算方面的问题。