大数据技术原理与应用——Hadoop 再探讨

大数据技术原理与应用——Hadoop 再探讨

9.1 Hadoop 的优化与发展

Hadoop 的局限和不足

1.抽象层次低。
2.表达能力有限。
3.开发者自己管理作业之间的依赖关系。
4.难以看到程序整体逻辑。
5.执行迭代操作效率低。
6.资源浪费。
7.实时性差。

Hadoop 的改进和提升

主要体现在两个方面：
一方面：Hadoop 自身两大核心组件，MapReduce 和 HDFS 的架构设计改进。
另一方面：Hadoop 生态系统其它组件的不断丰富，包括 Pig、Tez、Spark 和 Kafka 等。
Hadoop 模块的自身改进：从1.0到2.0

组件	Hadoop1.0的问题	Hadoop2.0的改进
HDFS	第一名称节点，存在单点失效问题	设计了HDFS HA，提供名称节点热备机制
HDFS	单一名称节点，无法实现资源隔离	设计了HDFS Federation管理多个命名空间
MapReduce	资源管理效率低	设计了新的资源管理框架YARN

不断完善的 Hadoop 生态系统

组件	功能	解决 Hadoop 中存在的问题
Pig	处理大规模数据的脚本语言，用户只需要编写几条简单的语句，系统会自动转换为MapReduce作业	抽象层次低，需要手工编写大量的代码
Spark	基于内存的分布式并行编程框架，具有较高的实时性，并且较好支持迭代计算	延迟高，而且不适合执行迭代计算
Oozie	工作流和协作服务引擎，协调Hadoop上运行的不同任务	没有提供作业（Job）之间的依赖关系管理机制，需要用户自己处理作业之间依赖关系
Tez	支持DAG作业的计算框架，对作业的操作进行重新分解和组合，形成一个大的DAG作业，减少不必要操作	不同的MapReduce任务之间存在重复操作，降低了效率
Kafka	分布式发布订阅消息，一般作为企业大数据分析平台的数据交换枢纽，不同类型的分布式系统可以统一接入到Kafka，实现和Hadoop各个组件之间的不同类型数据的实时高效交换	Hadoop生态系统中各个组件和其他产品之间缺乏统一的、高效的数据交换中介

9.2 HDFS2.0的新特性

HDFS HA

为了解决单点故障问题，HDFS2.0采用了 HA（High Availability）架构。在一个典型的 HA 集群中，一般设置两个名称节点，其中一个名称节点处于“活跃（Active）”状态，另一个处于“待命（Standby）”状态。处于活跃状态的名称节点负责对外处理所有客户端的请求，而处于待命状态的名称节点则作为备用节点，保存了足够多的系统元数据，当名称节点出现故障时提供快速恢复能力。也就是说，在 HDFS HA 中，处于待命状态的名称节点提供了“热备份”，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点，不会影响到系统的正常对外服务。

HDFS Federation

HDFS1.0中存在的问题
1.单点故障问题
2.不可以水平扩展
3.系统整体性能所限于单个名称节点的吞吐量
4.单个名称节点难以提供不同程序之间的隔离性
5.HDFS HA 是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性

HDFS 联邦的设计

HDFS 联邦中的名称节点提供了命名空间和块管理功能。在 HDFS 联邦中，所有名称节点会共享底层的数据节点存储资源。每个数据节点要向集群中所有的名称节点注册，并周期性地向名称节点发送“心跳”和块信息，报告自己的状态，同时也会处理来自名称节点的指令。

HDFS 联邦的访问方式

对于 HDFS 联邦中的多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问。每个阴影三角形代表一个独立的命名空间，上方空白三角形表示从客户方向去访问下面子命名空间。客户可以访问不同的挂载点来访问不同的子命名空间。这就是 HDFS 联邦中命名空间管理的基本原理，即把各个命名空间挂载到全局“挂载表”（Mount-table）中，实现数据全局共享；同样地，命名空间挂载到个人的挂载表中，就成为应用程序可见的命名空间。

HDFS 联邦相对于 HDFS 1.0的优势
1.HDFS 集群可扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像 HDFS 1.0中那样由于内存的限制制约文件存储数目。
2.性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。
3.良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小。

需要注意的是，HDFS 联邦并不能解决单点故障问题，也就是说，每个名称节点都存在单点故障问题，需要为每个名称节点部署一个后备名称节点，以应对名称节点宕机后对业务产生的影响。

9.3 新一代资源管理调度框架 YARN

MapReduce 1.0的缺陷

1.存在单点故障。
2.JobTracker“大包大揽”导致任务过重。
3.容易出现内存溢出。
4.资源划分不合理。

YARN 设计思路

在 Hadoop 1.0中，其核心子项目 MapReduce 1.0既是一个计算框架，也是一个资源管理调度框架。到了 Hadoop 2.0以后，MapReduce 1.0中的资源管理调度功能被单独分离出来形成了 YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架；而被剥离了资源管理调度功能的 MapReduce 框架就变成了 MapReduce 2.0，它是运行在 YARN 之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由 YARN 为其提供资源管理调度服务。

YARN 体系结构

YARN 各个组件的功能

• ResourceManager：
  1.处理客户端请求
  2.启动/监控 ApplicationMaster
  3.监控 NodeManager
  4.资源分配与调度
• ApplicationMaster：
  1.为应用程序申请资源，并分配给内部任务
  2.任务调度、监控与容错
• NodeManager：
  1.单个节点上的资源管理
  2.处理来自 ResourceManger 的命令
  3.处理来自 ApplicationMaster 的命令

在集群部署方面，YARN 的各个组件和 Hadoop 集群中的其他组件进行统一部署的。YARN 的 ResourceManager 组件和 HDFS 的名称节点（NameNode）部署在一个节点上，YARN 的 ApplicationMaster 及 NodeManager 是和 HDFS 的数据节点（DataNode）部署在一起的。YARN 中的容器代表了 CPU、内存、网络等计算资源，它也是和 HDFS 的数据节点一起的。

YARN 工作流程

1.用户编写客户端应用程序，向 YARN 提交应用程序，提交的内容包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。
2.YARN 中的 ResourceManager 负责接收和处理来自客户端的请求，为应用程序分配一个容器，在该容器中启动一个 ApplicationMaster。
3.ApplicationMaster 被创建后会首先向 ResourceManager 注册，从而使得用户可以通过 ResourceManager 来直接查看应用程序的运行状态，
4.ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请资源。
5.ResourceManager 以“容器”的形式向提出申请的 ApplicationMaster 分配资源，一旦 ApplicationMaster 申请到资源后，就会与该容器所在的 NodeManager 进行通信，要求它启动任务。
6.当 ApplicationMaster 要求容器启动任务时，它会为任务设置好运行环境（包括环境变量、JAR 包、二进制程序等），然后将任务启动命令写到一个脚本中，最后通过在容器中运行该脚本来启动任务。
7.各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，让 ApplicationMaster 可以随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
8.应用程序运行完成后，ApplicationMaster 向 ResourceManager 的应用程序管理器注销并关闭自己。若 ApplicationMaster 因故失败，ResourceManager 中的应用程序管理器会检测到失败的情形，然后将其重新启动，直到所有的任务执行完毕。

YARN 框架与 MapReduce1.0 框架的对比分析

总体而言，YARN 相当于 MapReduce1.0 来说具有以下优势：
（1）大大减少了承担中心服务功能的 ResourceManager 的资源消耗。
（2）MapReduce1.0 既是一个计算框架，又是一个资源管理调度框架，但是只能支持 MapReduce 编程模型。
（3）YARN 中的资源管理比 MapReduce1.0 更加高效。

YARN 的发展目标

YARN 的目标就是实现“一个集群多个框架”，为什么？
一个企业当中同时存在各种不同的业务应用场景，需要采用不同的计算框架
MapReduce 实现离线批处理
使用 Impala 实现实时交互式查询分析
使用 Storm 实现流式数据实时分析
使用 Spark 实现迭代计算

为了避免不同类型应用之间互相干扰，企业就需要把内部的服务器拆分成多个集群，分别安装运行不同的计算框架，即“一个框架一个集群”。

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

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

Pig

通过配合使用 Pig 和 Hadoop，让两者结合起来使用在处理海量数据的时候就可以达到事半功倍的效果，比使用 Java 和 C++ 语言编写 MapReduce 难度要小很多，而且用更少的代码量，实现了相同的数据处理分析。

• 通过 LOAD 语句去文件系统读取数据
• 通过一系列“转换”语句对数据进行处理
• 通过 STORE 语句把处理结果输出到文件当中去或者用 DUMP 语句把处理结果输出到屏幕上面
  
  下面是一个采用 Pig Latin 语言编写的应用程序实例，实现对用户访问网页情况的统计分析
  
  
  Pig 的应用场景
  

Tez

1.Tez 是 Apache 开源的支持 DAG 作业的计算框架，它直接源于 MapReduce 框架
2.核心思想是将 Map 和 Reduce 两个操作进一步拆分


分解后的元操作可以任意灵活组合，产生新的操作
经过一些控制程序组装后，可形成一个大的 DAG 作业
通过 DAG 作业的方式运行 MapReduce 作业，提供程序运行的整体处理逻辑
Hortonworks 把 Tez 应用到数据仓库 Hive 的优化中，使得性能提升了约100倍

Tez 的优化主要体现在
1.去除连续两个作业之间的“写入 HDFS”
2.去除每个工作流中多余的 Map 阶段


（Tez+Hive）与 Impala、Dremel 和 Drill 的区别
Tez 在解决 Hive、Pig 延迟大、性能低等问题的思路，是和那些支持实时交互式查询分析的产品（如 Impala、Dremel 和 Drill 等）是不同的。
比如，针对 Hive 数据仓库进行优化的“Tez+Hive”解决方案，仍采用 MapReduce 计算框架，但是对 DAG 的作业依赖关系进行了裁剪，并将多个小作业合并成一个大作业，这样，不仅计算量减少了，而且写 HDFS 次数也会大大减少。

Spark 和 Kafka

Hadoop 缺陷
1.其 MapReduce 计算模型延迟过高，无法胜任实时，快速计算的需求因而只适用于离线批处理的应用场景。
2.中间结果写入磁盘，每次运行都从磁盘读数据。
3.在前一个任务执行完成之前，其他任务无法开始，难以胜任复杂、多阶段的计算任务。

Kafka
1.一种高吞吐量的分布式发布订阅消息系统，用户通过 Kafka 系统可以发布大量的消息，同时也能实时订阅消费消息。
2.可以同时满足在线实时处理和批量离线处理。

在公司的大数据生态系统中，可以把 Kafka 作为数据交换枢纽，不同类型的分布式系统（关系数据库、NoSQL 数据库、流处理系统、批处理系统等），可以统一接入到 Kafka，实现和 Hadoop 各个组件之间的不同类型数据的实时高效交换。