大数据技术原理与应用 第三篇 大数据处理与分析 (二) Hadoop再探讨

一、 Hadoop的优化与发展

1.1 Hadoop的局限

对于MapReduce和HDFS【不包含其它组件】：

1、抽象层次低，仍需手工编写代码完成功能

2、表达能力有限，MapReduce抽象的Map和Reduce函数，在降低开发复杂度的同时，也带来了表达能力有限的问题，导致一些任务无法用Map和Reduce函数来完成

3、开发者自行管理作业间的依赖关系。一个作业Job只包含Map和Reduce两个阶段，一个问题需要多个Job协作解决，Job间的依赖关系由开发者自己管理。

4、难以看到程序整体逻辑，用户的处理逻辑 隐藏在代码细节中，没有高层次抽象机制，对代码后期理解和维护带来障碍

5、迭代效率低，对于大型机器学习任务，多需要多轮迭代，用MapReduce实现时，数据和结果都存放在HDFS中，反复读写HDFS效率低

6、资源浪费，Reduce任务需要等待所有Map任务完成后才开始

7、实时性差，仅支持离线批数据处理，无法支持交互式数据处理，实时数据处理

二、 Hadoop2.0

2.1 HDFS HA

解决问题

HDFS 1.0只存在一个名称节点，有单点故障问题，虽然有第二名称节点，但其任务是防止日志文件过大导致的名称节点失败恢复时间过长，周期性获取FsImage和EditLog合并后替换FsImage。但其并不能提供热备份功能，在名称节点故障时，系统不能直接切换到第二名称节点立即对外提供服务，仍需停机维护。

解决方法：

HDFS 2.0采用高可用（High Availability HA）架构。HA集群中一般设置两个名称节点，一个处于活跃状态，一个处于待命状态，处于活跃状态的节点负责处理所有客户端请求，处于待命状态的名称节点作为备用节点，一旦活跃名称节点出现问题，则立即切换到待命名称节点，不会影响对外服务

特点

状态同步： 两个名称节点的实时同步通过一个共享存储系统实现。活跃节点将更新数据写入共享存储系统，待命节点监听该系统，一旦有新的写入就从共享存储系统读取数据加载到自己的内存中，从而保证两个节点状态完全同步

数据节点位置信息更新同时进行：为保证待命名称节点中包含集群中各数据几点的块映射是最新的，需要给每个数据节点配置两个名称节点地址，并把块信息和心跳信息同时发给两个节点

任意时刻仅有一个名称节点提供对外服务：ZooKeeper确保不会有两个名称节点处于活跃状态。

2.2 HDFS 联邦

解决问题

HDFS 1.0单名称节点的设计存在扩展性、系统整体性能和隔离性的问题。

扩展性方面，所有元数据存储在名称节点的内存中，不可以水平拓展，限制了系统数据块、文件和目录的数目。而纵向扩展会带来启动时间长，清理时易出错死机等问题，

系统整体性能方面，整个HDFS的性能受限于单一名称节点的吞吐量

隔离性方面，单个名称节点难以提供不同程序间的隔离性，而HA只是通过热备份解决了单点故障问题

解决方法

HDFS联邦设计了多个相互独立的名称节点，使其可以横向扩展，每个名称节点有自己的命名空间和块管理，不需要彼此协调，且可以无缝兼容单名称节点的部署配置，无需调整。

HDFS联邦中的名称节点提供命名空间和块管理功能。HDFS联邦有多个独立的命名空间，每个命名空间管理属于自己的一组块，属于同一命名空间的块构成一个块池【逻辑概念】，一个块池中的块可以属于不同的数据节点，可见所有名称节点共享底层数据节点存储资源。即使名称节点失效，也不会影响其数据节点进而影响其他名称节点工作。

客户端挂载表方式访问多个命名空间：客户可以访问不同的挂载点来访问不同的子命名空间。通过将各个命名空间挂载到全局挂载表实现全局共享，命名空间挂载到个人的挂载表中就成为应用程序可见的命名空间。

优势

HDFS集群可扩展性：多个名称节点各自分管一部分目录，使得一个集群可以扩展到多个节点，不再由于内存限制集群大小

系统整体性能： 多个名称节点管理不同的数据，且同时对外提供服务，提供了更高的读写效率

良好的隔离性： 用户将不同的业务数据交给不同的名称节点管理，业务间影响小

注意

HDFS联邦不能解决单点故障问题，对于每个名称节点都需要部署一个后备名称节点

2.3 新一代资源调度框架YARN

MapReduce 1.0的缺陷

MapReduce 1.0包括一个JobTracker和若干个TaskTracker，前者负责作业的调度和资源的管理，后者负责执行JobTracker指派的具体任务

存在单点故障：系统只有一个JobTracker，故障时导致系统不可用

JobTracker任务过重：JobTracker既要负责作业的调度和失败恢复，又要负责资源管理分配，内存开销巨大，增大失败风险

容易出现内存溢出：TaskTracker端资源的分配不考虑CPU、内存的实际状况，仅根据MapReduce任务的个数来分配资源，当两个大内存消耗任务分配到同一个TaskTracker时，容易发生内存溢出

资源分配不合理：资源被强制等量分成多个槽（Slot），槽又被划分为Map槽和Reduce槽，分别提供给Map和Reduce任务使用。当Map槽使用完时，Map任务无法使用大量剩余Reduce槽，存在资源浪费。

YARN设计思路

YARN的基本思路是放权，减轻JobTracker的负担，拆分了其原本的资源管理，任务调度和任务监控三大功能，分别交给不同的新组件处理。YARN包括ResourceManager、ApplicationMaster和NodeManager，其中ResourceManager负责资源管理，ApplicationMaster负责任务调度和监控，NodeManager负责执行原TaskTracker的任务。大大降低了JobTracker的负担，提高了系统的稳定性和效率

HDFS 2.0的资源调度功能被单独分离出来形成YARN，这是一个纯粹的资源管理调度框架，而非计算框架，而被剥离了资源调度功能的MapReduce形成了MapReduce 2.0，这是运行YARN上的一个纯粹的计算框架，由YARN外包了资源管理调度服务

YARN三大组件功能

组件	功能	任务
ResourceManager	处理客户端请求 启动/监控ApplicationMaster 监控NodeManager 资源分配与调度	ResourceManager负责整个系统的资源管理和分配，主要包含资源调度器和应用程序管理器 资源调度器负责资源的调度和分配，不负责跟踪监控程序转态等。资源调度器根据ApplicationMaster的资源请求，根据一定条件，将集群中的资源以容器的形式分配给相应的应用程序。 应用程序管理器负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等
ApplicationMaster	为应用程序申请资源并分配给内部任务 任务调度、监控及容错	ResourceManager接收用户提交的作业，按照作业的上下文信息以及从NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一个ApplicationMaster 当用户作业提交时，ApplicationMaster与ResManager协商获取资源，ResManager会以容器的形式为ApplicationMaster分配资源 把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务），实现资源的“二次分配” 与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）; 定时向ResManager发送“心跳”消息，报告资源的使用情况和应用的进度信息;当作业完成时，App Mstr向ResManager注销容器，执行周期完成
NodeManager	单个节点上的资源管理 处理来自ResourceManager的命令 处理来自ApplicationMaster的命令	容器生命周期管理 监控每个容器的资源（CPU、内存等）使用情况 跟踪节点健康状况以“心跳”的方式与ResourceManager保持通信 向ResourceManager汇报作业的资源使用情况和每个容器的运行状态 接收来自ApplicationMaster的启动/停止容器的各种请求

容器的特点：作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁盘等资源，从而限定每个应用程序可使用的资源量。容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”

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

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

集群的部署：在集群部署方面，YARN的各个组件和Hadoop集群其他组件进行统一部署的

YARN的工作流程

（1）用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括 App Mstr程序、启动App Mstr的命令、用户程序等

（2）YARN中的ResManager负责接收和处理来自客户端的请求，为应用程序分配一个容器，并与该容器所在的NodeManager通信，为该程序在容器中启动一个App Mstr

（3）App Mstr被创建后会首先向ResManager注册，可以通过ResManager查看应用程序的运行状态

具体应用程序的执行步骤：

（4）App Mstr采用轮询的方式向ResManager申请资源

（5）ResManager以“容器”的形式向提出申请的App Mstr分配资源，申请成功后App Mstr与容器所在的NodeManage通信，要求它启动任务

（6）App Mstr要求容器启动任务后，为任务设置好运行环境，并将任务命令写到脚本中，在容器中运行该脚本

（7）各个任务向App Mstr汇报自己的状态和进度，让App Mstr随时掌握个任务运行状态

（8）应用程序运行完成后， App Mstr向ResManager的应用程序管理器注销并关闭自己。若失败，则ResManager重启App Mstr，直到任务执行完成

YARN框架的优势

（1）从MapReduce1.0框架发展到YARN框架，客户端并没有发生变化，其大部分调用API及接口都保持兼容，因此，原来针对Hadoop1.0开发的代码不用做大的改动，就可以直接放到Hadoop2.0平台上运行

（2）大大减少了承担中心服务功能ResourceManager的资源消耗，ApplicationMaster来完成需要大量资源消耗的任务调度和监控，多个作业对应多个ApplicationMaster实现了监控分布化

（3）YARN是一个纯粹的资源调度管理框架，在它上面可以运行包括MapReduce在内的不同类型的计算框架，只要编程实现相应的ApplicationMaster

（4）YARN中的资源管理比MapReduce1.0更加高效。以容器为单位，而不是以slot为单位

YARN的发展目标

“一个集群多个框架”：

“一个集群多个框架”即在一个集群上部署一个统一的资源调度管理框架YARN，在YARN之上可以部署其他各种计算框架由YARN为这些计算框架提供统一的资源调度管理服务，并且能够根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩可以实现一个集群上的不同应用负载混搭，有效提高了集群的利用率不同计算框架可以共享底层存储，避免了数据集跨集群移动

Hadoop生态系统中具有代表性的功能组件

组件	功能	应用场景
Pig	提供了类似SQL的Pig Latin语言（包含Filter、GroupBy、Join、OrderBy等操作，同时也支持用户自定义函数） 允许用户通过编写简单的脚本来实现复杂的数据分析，而不需要编写复杂的MapReduce应用程序 Pig会自动把用户编写的脚本转换成MapReduce作业在Hadoop集群上运行，而且具备对生成的MapReduce程序进行自动优化的功能 用户在编写Pig程序的时候，不需要关心程序的运行效率，这就大大减少了用户编程时间 通过配合使用Pig和Hadoop，在处理海量数据时就可以实现事半功倍的效果，比使用Java、C++等语言编写MapReduce程序的难度要小很多，并且用更少的代码量实现了相同的数据处理分析功能	数据查询只面向相关技术人员 即时性的数据处理需求，这样可以通过pig很快写一个脚本开始运行处理，而不需要创建表等相关的事先准备工作
Tez	Tez是Apache开源的支持DAG作业的计算框架， 它直接源于MapReduce框架核心思想是将Map和Reduce两个操作进一步拆分Map被拆分成Input、Processor、Sort、Merge和Output Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等分解后的元操作可以任意灵活组合，产生新的操作 这些操作经过一些控制程序组装后，可形成一个大的DAG作业 通过DAG作业的方式运行MapReduce作业，提供了程序运行的整体处理逻辑，可去除工作流中多余的Map阶段，减少不必要操作，提升数据处理性能 Hortonworks把Tez应用到数据仓库Hive的优化中，使性能提升了约100倍	Tez在解决Hive、Pig延迟大、性能低等问题的思路，是和那些支持实时交互式查询分析的产品（如Impala、Dremel和Drill等）是不同的 在Hadoop2.0生态系统中，MapReduce、Hive、Pig等计算框架，都需要最终以MapReduce任务的形式执行数据分析，因此，Tez框架可以发挥重要的作用 借助于Tez框架实现对MapReduce、Pig和Hive等的性能优化 可以解决现有MR框架在迭代计算（如PageRank计算）和交互式计算方面的问题
Kafka	Kafka是一种高吞吐量的分布式发布订阅消息系统，用户通过Kafka系统可以发布大量的消息，同时也能实时订阅消费消息 Kafka可以同时满足在线实时处理和批量离线处理	在公司的大数据生态系统中，可以把Kafka作为数据交换枢纽，不同类型的分布式系统（关系数据库、NoSQL数据库、流处理系统、批处理系统等），可以统一接入到Kafka，实现和Hadoop各个组件间不同类型数据的实时高效交换