Hadoop初识、架构探讨

Hadoop简介：

Hadoop官网：http://hadoop.apache.org/

Hadoop是Apache软件基金会旗下的一个开源分布式计算平台，为用户提供了系统底层细节透明的分布式基础架构

Hadoop 底层用Java语言、跨平台性，可以部署在廉价的计算机集群中。

Hadoop在分布式环境下提供了海量数据的处理能力

几乎所有主流厂商都围绕Hadoop提供开发工具、开源软件、商业化工具和技术服务，如谷歌、雅虎、微软、思科、淘宝等，都支持Hadoop。

Hadoop核心：

Hadoop组成：

• 分布式文件系统 HDFS（Hadoop Distributed File System）            |   存储系统
• 分布式计算 MapReduce                                                                    |   并行运算框架

Hadoop的特性：

Hadoop是一个能够对大量数据进行分布式处理的软件框架，并且是以一种可靠、高效、可伸缩的方式进行处理的，它具有以下几个方面的特性：

• 高可靠性
• 高效性
• 高可扩展性
• 高容错性
• 成本低
• 运行在Linux平台上
• 持多种编程语言

Hadoop 生态系统架构

Hadoop的项目结构不断丰富发展，已经形成一个丰富的Hadoop生态系统。

Hadoop1 生态系统架构

Hadoop2 生态系统架构 

• HDFS:构建于廉价计算机集群之上的分布式文件系统，低成本、高可靠性、高吞吐量
• MapReduce:分布式编程模型和软件框架，用于在集群上编写对海量数据处理的并行化程序
• Common:整体架构提供基础支撑性功能，主要包括了文件系统、RPC和数据串行化库
• Hive:数据仓库工具，将结构化数据文件映射为库表，并提供强大的类SQL查询功能
• Hbase:分布式的、面向列的数据库，是一个适合于非结构化海量数据存储的数据库
• Pig:适合海量数据分析的脚本语言工具，包括了一个数据分析语言和支持的运行环境
• Sqoop:在Hadoop与传统数据库间进行数据交换的工具，支持两者之间的数据导入和导出
• Zookeeper:维护Hadoop集群的配置和命名信息，并提供分布式锁同步功能和群组管理功能
• Ambari:安装、管理和监控Hadoop集群的Web界面工具。目前已支持大部分组件的管理,就 Ambari 的作用来说，就是创建、管理、监视 Hadoop 的集群

Hadoop的生态圈

 Hadoop生态系统详解：

• HDFS：分布式文件系统
• MapReduce：分布式并行编程模型
• YARN：资源管理和调度器
• Tez：运行在YARN之上的下一代Hadoop查询处理框架，它会将很多的mr任务分析优化后构建一个有向无环图，保证最高的工作效率
• Hive：Hadoop上的数据仓库
• Hbase：Hadoop上的非关系型的分布式数据库
• Pig：一个基于Hadoop的大规模数据分析平台，提供类似SQL的查询语言Pig Latin
• Sqoop：用于在Hadoop与传统数据库之间进行数据传递
• Oozie ['u:zɪ]：Hadoop上的工作流管理系统
• Zookeeper：提供分布式协调一致性服务
• Storm：流计算框架
• Flume：一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统
• Ambari：Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控
• Kafka：一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据
• Spark：类似于Hadoop MapReduce的通用并行框架

Hadoop项目结构

组件	功能
HDFS	分布式文件系统
MapReduce	分布式并行编程模型
YARN	资源管理和调度器
Tez	运行在YARN之上的下一代Hadoop查询处理框架，它会将很多的mr任务分析优化后构建一个有向无环图，保证最高的工作效率
Hive	Hadoop上的数据仓库
HBase	Hadoop上的非关系型的分布式数据库
Pig	一个基于Hadoop的大规模数据分析平台，提供类似SQL的查询语言Pig Latin
Sqoop	用于在Hadoop与传统数据库之间进行数据传递
Oozie	Hadoop上的工作流管理系统
Zookeeper	提供分布式协调一致性服务
Storm	流计算框架
Flume	一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统
Ambari	Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控
Kafka	一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据
Spark	类似于Hadoop MapReduce的通用并行框架

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Hadoop2新特性详解：HDFS HA和HDFS Federation

HDFS HA

Hadoop1组件及功能：

名称节点保存元数据：

• 在磁盘上：FsImage和EditLog
• 在内存中：映射信息，即文件包含哪些块，每个块存储在哪个数据节点

HDFS 1.0存在单点故障问题，第二名称节点（SecondaryNameNode）无法解决单点故障问题

• SecondaryNameNode会定期和NameNode通信
• 从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下
• 执行EditLog和FsImage文件合并
• 将新的FsImage文件发送到NameNode节点上
• NameNode使用新的FsImage和EditLog（缩小了）

第二名称节点用途：

• 不是热备份
• 主要是防止日志文件EditLog过大，导致名称节点失败恢复时消耗过多时间
• 附带起到冷备份功能

HDFS HA（High Availability）是为了解决单点故障问题：

• HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”
• 两种名称节点的状态同步，可以借助于一个共享存储系统来实现
• 一旦活跃名称节点出现故障，就可以立即切换到待命名称节点
• Zookeeper确保一个名称节点在对外服务
• 名称节点维护映射信息，数据节点同时向两个名称节点汇报信息

HDFS Federation

1.HDFS1.0中存在的问题

• ​​​​​​​单点故障问题
• 不可以水平扩展（是否可以通过纵向扩展来解决？）
• 系统整体性能受限于单个名称节点的吞吐量
• 单个名称节点难以提供不同程序之间的隔离性
• HDFS HA是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性

2.HDFS Federation的设计

HDFS Federation架构

• 在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调。并且向后兼容
• HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报
• 属于同一个命名空间的块构成一个“块池”

​​​​​​​3. HDFS Federation的访问方式

每个阴影三角形代表一个独立的命名空间
名称节点1维护的命名空间
名称节点2维护的命名空间
客户端挂载表方式访问多个命名空间

• 对于Federation中的多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问
• 客户可以访问不同的挂载点来访问不同的子命名空间
• 把各个命名空间挂载到全局“挂载表”（mount-table）中，实现数据全局共享
• 同样的命名空间挂载到个人的挂载表中，就成为应用程序可见的命名空间

4.HDFS Federation相对于HDFS1.0的优势

HDFS Federation设计可解决单名称节点存在的以下几个问题：

（1）HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目

（2）性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率

（3）良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小

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

Yarn—资源管理调度框架

MapReduce1.0的缺陷：

MapReduce1.0体系结构

• （1）存在单点故障
• （2）JobTracker“大包大揽”导致任务过重（任务多时内存开销大，上限4000节点）
• （3）容易出现内存溢出（分配资源只考虑MapReduce任务数，不考虑CPU、内存）
• （4）资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot）

Yarn设计思路：

• MapReduce1.0既是一个计算框架，也是一个资源管理调度框架
• 到了Hadoop2.0以后，MapReduce1.0中的资源管理调度功能，被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架
• 被剥离了资源管理调度功能的MapReduce 框架就变成了MapReduce2.0，它是运行在YARN之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由YARN为其提供资源管理调度服务

Yarn体系结构：

ResourceManager

• 处理客户端请求
• 启动/监控ApplicationMaster
• 监控NodeManager
• 资源分配与调度
• ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件，即调度器（Scheduler）和应用程序管理器（Applications Manager）
• 调度器接收来自ApplicationMaster的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”
• 容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量
• 调度器被设计成是一个可插拔的组件，YARN不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器
• 应用程序管理器（Applications Manager）负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等

NodeManager

• 单个节点上的资源管理
• 处理来自ResourceManger的命令
• 处理来自ApplicationMaster的命令

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

• 容器生命周期管理
• 监控每个容器的资源（CPU、内存等）使用情况
• 跟踪节点健康状况
• 以“心跳”的方式与ResourceManager保持通信
• 向ResourceManager汇报作业的资源使用情况和每个容器的运行状态
• 接收来自ApplicationMaster的启动/停止容器的各种请求

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

ApplicationMaster

• 为应用程序申请资源，并分配给内部任务
• 任务调度、监控与容错

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

ApplicationMaster的主要功能是：

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

（2）把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务），实现资源的“二次分配”；

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

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

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

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

Yarn工作流程：

步骤1：用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等

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

步骤3：ApplicationMaster被创建后会首先向ResourceManager注册

步骤4：ApplicationMaster采用轮询的方式向ResourceManager申请资源

步骤5：ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源

步骤6：在容器中启动任务（运行环境、脚本）

步骤7：各个任务向ApplicationMaster汇报自己的状态和进度

步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己

Yarn框架与MapReduce1.0框架的对比分析：

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

总体而言，YARN相对于MapReduce1.0来说具有以下优势：

• 大大减少了承担中心服务功能的ResourceManager的资源消耗
• ApplicationMaster来完成需要大量资源消耗的任务调度和监控
• 多个作业对应多个ApplicationMaster，实现了监控分布化
• MapReduce1.0既是一个计算框架，又是一个资源管理调度框架，但是，只能支持MapReduce编程模型。而YARN则是一个纯粹的资源调度管理框架，在它上面可以运行包括MapReduce在内的不同类型的计算框架，只要编程实现相应的ApplicationMaster
• YARN中的资源管理比MapReduce1.0更加高效
• 以容器为单位，而不是以slot为单位

一个企业当中同时存在各种不同的业务应用场景，需要采用不同的计算框架：

• MapReduce实现离线批处理
• 使用Impala实现实时交互式查询分析
• 使用Storm实现流式数据实时分析
• 使用Spark实现迭代计算

这些产品通常来自不同的开发团队，具有各自的资源调度管理机制。

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

导致问题：

• 集群资源利用率低
• 数据无法共享
• 维护代价高

​​​​​​​YARN的目标就是实现“一个集群多个框架”。​​​​​​​