第9章 Hadoop再探讨
第9章 Hadoop再探讨
9.1Hadoop的优化与发展
9.1.1Hadoop的局限与不足
Hadoop1.0的核心组件(仅指MapReduce和HDFS,不包括Hadoop生态系统内的Pig、Hive、HBase等其他组件), 主要存在以下不足:
•抽象层次低,需人工编码
•表达能力有限
•开发者自己管理作业(Job)之间的依赖关系
•难以看到程序整体逻辑
•执行迭代操作效率低
•资源浪费(Map和Reduce分两阶段执行)
•实时性差(适合批处理,不支持实时交互式)
9.1.2针对Hadoop的改进与提升
Hadoop的优化与发展主要体现在两个方面:
•一方面是Hadoop自身两大核心组件MapReduce和HDFS的架构设计改进
•另一方面是Hadoop生态系统其它组件的不断丰富,加入 了Pig、Tez、Spark和Kafka等新组件
9.2 HDFS2.0的新特性
9.2.1 HDFS HA
名称节点保存元数据:
(1)在磁盘上:FsImage和EditLog
(2)在内存中:映射信息,即文件包含哪些块,每个块存储在哪个数据节点
**HDFS HA(High Availability)**是为了解决单点故障问题
1.HA集群设置两个名称节点,“活跃(Active)”和“待命(Standby)”
2.两种名称节点的状态同步,可以借助于一个共享存储系统来实现
3.一旦活跃名称节点出现故障,就可以立即切换到待命名称节点
4.Zookeeper确保一个名称节点在对外服务
5.名称节点维护映射信息,数据节点同时向两个名称节点汇报信息
9.2.2 HDFS Federation
1.HDFS1.0中存在的问题
•单点故障问题
•不可以水平扩展(是否可以通过纵向扩展来解决?)
•系统整体性能受限于单个名称节点的吞吐量
•单个名称节点难以提供不同程序之间的隔离性
•HDFS HA是热备份,提供高可用性,但是无法解决可扩展性、系统性能和隔离性
2.HDFS Federation的设计
•在HDFS Federation中,设计了多个相互独立的名称节点,使得HDFS的命名服务能够水平扩展,这些名称节点分别进行各自命名空间和块的管理,相互之间是联盟 (Federation)关系,不需要彼此协调。 并且向后兼容
•HDFS Federation中,所有名称节点会共 享底层的数据节点存储资源,数据节点向所有名称节点汇报
•属于同一个命名空间的块构成一个“块池”
3.HDFS Federation的访问方式
•对于Federation中的多个命名空间,可以采用客户端挂载表(Client Side Mount Table)方式进行数据共享和访问
•客户可以访问不同的挂载点来访问不同的子命名空间
•把各个命名空间挂载到全局“挂载表” (mount-table)中,实现数据全局共享
•同样的命名空间挂载到个人的挂载表中, 就成为应用程序可见的命名空间
4.HDFS Federation相对于HDFS1.0的优势
HDFS Federation设计可解决单名称节点存在的以下几个问题:
(1)HDFS集群扩展性。多个名称节点各自分管一部分目录,使得一个集 群可以扩展到更多节点,不再像HDFS1.0中那样由于内存的限制制约文件存储数目
(2)性能更高效。多个名称节点管理不同的数据,且同时对外提供服务, 将为用户提供更高的读写吞吐率
(3)良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理,这样不同业务之间影响很小
需要注意的,HDFS Federation并不能解决单点故障问题,也就是说,每 个名称节点都存在在单点故障问题,需要为每个名称节点部署一个后备名称节点,以应对名称节点挂掉对业务产生的影响
9.3新一代资源管理调度框架YARN
9.3.1 MapReduce1.0的缺陷
(1)存在单点故障
(2)JobTracker“大包大揽”导致任务过重(任务多时内存开销大,上限4000节点)
(3)容易出现内存溢出(分配资源只考虑MapReduce任务数,不考虑CPU、内存)
(4)资源划分不合理(强制划分为slot ,包括Map slot和Reduce slot,YARN中的资源管理比MapReduce1.0更加高效,以容器为单位,而不是以slot为单位)
9.3.2 YARN体系结构
MapReduce1.0: 计算框架+资源管理调度框架
MapReduce2.0: 计算框架 YARN: 资源调度框架
(1)ResourceManager:
•处理客户端请求
•启动/监控ApplicationMaster
•监控NodeManager
•资源分配与调度
(2)NodeManager: NodeManager是驻留在一个YARN集群中的每个节点上的代理
•单个节点上的资源管理
•处理来自ResourceManger的命令
•处理来自ApplicationMaster的命令
(3)ApplicationMaster:
•为应用程序申请资源, 并分配给内部任务
•任务调度、监控与容错
9.3.3 YARN工作流程
步骤1:用户编写客户端应用程序,向YARN提交应用程序,提交的内容包括 ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等
步骤2:YARN中的ResourceManager负责接收和处理来自客户端的请求,为应用程序分配一个容器,在该容器中启动一个ApplicationMaster
步骤3:ApplicationMaster被创建后会首先向 ResourceManager注册
步骤4:ApplicationMaster采用轮询的方式向 ResourceManager申请资源
步骤5:ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源
步骤6:在容器中启动任务(运行环境、脚本)
步骤7:各个任务向ApplicationMaster汇报自己的状态和进度
步骤8:应用程序运行完成后, ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己
9.4 Hadoop生态系统中具有代表性的功能组件
9.4.1 Pig
•提供了类似SQL的Pig Latin语言(包含Filter、GroupBy、Join、 OrderBy等操作,同时也支持用户自定义函数)
•允许用户通过编写简单的脚本来实现复杂的数据分析,而不需要编写复杂的MapReduce应用程序
•Pig会自动把用户编写的脚本转换成MapReduce作业在Hadoop集群上运行,而且具备对生成的MapReduce程序进行自动优化的功能
•用户在编写Pig程序的时候,不需要关心程序的运行效率,这就大大减少了用户编程时间
•通过配合使用Pig和Hadoop,在处理海量数据时就可以实现事半功倍的效果,比使用Java、C++等语言编写MapReduce程序的难度要小很多,并且用更少的代码量实现了相同的数据处理分析功能
9.4.2 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倍
9.4.3 Spark
Spark是一个开源集群运算框架,最初是由加州大学柏克莱分校AMPLab所开发。相对于Hadoop的MapReduce会在运行完工作后将中介资料存放到磁盘中,Spark使用了存储器内运算技术,能在资料尚未写入硬盘时即在存储器内分析运算。Spark在存储器内运行程序的运算速度能做到比Hadoop MapReduce的运算速度快上100倍,即便是运行程序于硬盘时,Spark也能快上10倍速度。[1]Spark允许用户将资料加载至集群存储器,并多次对其进行查询,非常适合用于机器学习算法。
9.4.4 Kafka
•Kafka是一种高吞吐量的分布式发布订阅消息系统,用户通过Kafka系统可以发布大量的消息,同时也能实时订阅消费消息
•Kafka可以同时满足在线实时处理和批量离线处理 ,在公司的大数据生态系统中,可以把Kafka作为数据交换枢纽,不同类型的分布式系统(关系数据库、 NoSQL数据库、流处理系统、批处理系统等),可以统一接入到Kafka,实现和Hadoop各个组件之间的不同类型数据的实时高效交换