Hadoop2.0探讨

2023-10-10 23:29
文章标签 探讨 hadoop2.0

本文主要是介绍Hadoop2.0探讨，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

      • 8. Hadoop 再探讨
        • 8.1 Hadoop的优化与发展
        • 8.2 HDFS 的FA和Federation(Hadoop2.0新特性)
          • 8.2.1 HDFS HA
          • 8.2.2 HDFS Federation
        • 8.3 YARN
          • 8.3.1 MapReduce1.0的缺陷
          • 8.3.2 Yarn设计思路
          • 8.3.3 Yarn体系结构
          • 8.3.4 Yarn工作流程
          • 8.3.5 Yarn框架和MapReduce1.0框架对比分析
          • 8.3.6 Yarn框架的发展目标
        • 8.4 Hadoop生态系统中具有代表性的组件
          • 8.4.1 Pig
          • 8.4.2 Tez
          • 8.4.3 Spark和Kafka

8. Hadoop 再探讨

8.1 Hadoop的优化与发展

  • Hadoop1.0的局限和不足

    • 抽象层次低，需人工编码：编写一个非常简单的代码都需要人工编写MapReduce代码，进行编译打包运行
    • 表达能力有限：现实中的一些问题不是使用Map和Reduce就能完成的
    • 开发者需要自己管理作业（Job）之间的依赖关系：多个MapReduce任务之间的前后关系需要人工管理
    • 难以看到程序整体逻辑
    • 执行迭代操作效率低：每次迭代都需要将结果先写入到HDFS中，下一个MapReduce任务再从HDFS中读取数据
    • 资源浪费：整个任务执行过程中Map任务结束之后才能进行Reduce任务，导致Reduce一直处于空闲状态

  • Hadoop2.0的优化与发展

    • Hadoop自身两大核心组件，MapReduce和HDFS的架构设计改进
    • Hadoop生态系统其他组件的不断丰富，包括Pig、Tez、Spark和Kafka等

  • Hadoop1.0到Hadoop2.0对比

    image-20231010171751385

  • 不断完善的Hadoop生态系统

    image-20231010171906733

8.2 HDFS 的FA和Federation(Hadoop2.0新特性)
8.2.1 HDFS HA

  • 整体结构

    • 名称节点发生故障，则立即切换到待命节点
    • 共享存储系统保证（活跃）名称节点和（待命）名称节点的中保存信息的同步
    • 共享存储系统将活跃节点的Editlog不断的同步到待命节点

    image-20231010172530715

8.2.2 HDFS Federation

  • HDFS1.0中存在的问题

    • 单点故障问题：通过HA解决
    • 不可以水平扩展 ：纵向扩展如加内存可能导致启动时间过长
    • 系统整体性能受限于单个名称节点的吞吐量：一秒钟可以接入多少外部节点还是由外部节点决定的
    • 单个名称节点难以提供不同程序之间的隔离性：一个程序消耗的资源非常大，可能导致另外的程序无法运行
    • HDFS HA是热备份，提供高可用性、但是无法解决可扩展性、系统性能和隔离性

  • HDFS Federation架构

    • 提供多个名称节点，由用户设置，名称节点之间彼此独立

    • Federation提供了向后的兼容性：单名称节点的应用程序可以无缝迁移到多名称节点

    • 所有的名称节点共享底层的数据节点

      image-20231010173845797

    • 通过用户挂载不同的命名空间，使用不同的名称节点，用户可以看到一个全局命名空间挂载表，用户可以看到每个子命名空间

      image-20231010174336426

  • HDFS Federation设计可解决单名称节点存在的问题

    • 集群扩展性问题：多个名称节点，每个名称节点可以独立的管理一个目录，让一个集群可以扩展到更多空间去
    • 性能更高效：多个名称节点各自管理数据，而且可以同时提供对外服务
    • 良好的隔离性：不同数据分给不同的名称节点去管理，有效的对应用程序进行隔离
8.3 YARN
8.3.1 MapReduce1.0的缺陷

  • 缺陷

    • 存在单点故障：只有一个JobTracker负责整个作业的管理调度

      image-20231010175118821

    • JobTracker"大包大揽"导致任务过重：资源管理调度分析、任务管理分配、任务监控以及失败的恢复

    • 容易出现内存溢出：只考虑MapReduce的任务数量，不考虑单个MapReduce任务消耗的资源，多个耗内存的任务一起执行，可能会导致内存溢出

    • 资源划分不合理：将资源等分为slot，Map的slot和Reduce的slot隔离，Map在运行时，Reduce的slot资源浪费

8.3.2 Yarn设计思路

  • 将JobTracker三大功能拆分

    image-20231010175713803

  • MapReduce1.0和Hadoop2.0

    • MapReduce1.0既是一个计算框架，也是一个资源调度框架
    • Hadoop2.0将MapReduce1.0中的资源管理调度功能单独分离出来，形成了YARN,使得Yarn成为了纯粹的资源管理调度框架
    • 而被剥离了资源管理调度功能的MapReduce框架就变成了MapReduce2.0，它是运行在Yarn上的纯粹计算框架，不再负责资源调度管理任务，而是由Yarn提供资源管理调度服务
8.3.3 Yarn体系结构

  • Yarn体系结构

    image-20231010192632194

  • Yarn各个组成部分作用

    • ResourceManager
      • 处理客户端请求
      • 启动/监控 ApplicaionMaster
      • 监控NodeManager
      • 资源分配与调度
    • ApplicationMaster
      • 为应用程序申请资源，并分配给内部任务
      • 任务调度、监控与容错（失败恢复）
      • 运行MapReduce所需要的资源(cpu)等由applicationMaster向ResourceManager申请
    • NodeManager
      • 是单个节点上的资源管理
      • 处理来自ResourceManager的命令
      • 处理来自ApplicationMaster的命令

  • ResourceManager作用、

    • ResourceManager包括了Scheduler（调度器）和Applications Manager(应用程序管理器)

      image-20231010193608662

    • 将内存资源以容器的形式分配，而不是以slot的形式分配

      image-20231010193904297

  • ApplicationMaster

    image-20231010194140334

    • ApplicationMaster的主要功能

      • 当用户作业提交时，ApplicationMater与ResourceManager协商获取资源，ResourceManager会以容器的形式给ApplicationMaster分配资源
      • 把获得的资源进一步分配给内部的各个任务（Map任务和Reduce任务），实现资源的“二次分配”
      • 与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）
      • 定时向ResourceManager发送“心跳”信息，报告资源的使用情况和应用的进度信息
      • 当作业完成时，ApplicationMaster向ResourceMnager注销容器，执行周期完成

    • NodeManager:驻留在一个Yarn集群中的每一个节点的代理

      • 容器生命周期管理：容器具体运行Map任务或者Reduce任务，还可以支持其他的计算框架
      • 监控每个容器资源（CPU、内存等）使用情况
      • 跟踪节点健康状态
      • 以“心跳”的方式与ResourceManager保持通信
      • 向ResourceManager汇报作业的资源使用情况和每个容器的运行状态
      • 接受ApplicationMaster的启动/停止容器的各种请求

    • NodeManager的主要说明

      image-20231010195605400

  • YARN和Hadoop平台其他组件的统一部署

    image-20231010195755992

8.3.4 Yarn工作流程

  • Yarn提交作业之后的全流程执行过程

    • 用户编写客户端应用程序，向Yarn提交应用程序，提交内容包括：Applications Master程序、启动Applications Master命令、以及用户程序

      image-20231010200030626

    • ResourceManager负责接受和处理来自客户端请求

      image-20231010200221109

    • ApplicationMaster被创建会首先向ResourceManager注册：为了ResourceManager能够实时监控ApplicationMaster

      image-20231010200411906

    • ApplicationMaster向ResourceManager申请资源

      image-20231010200535296

    • ResourceManager以“容器”的形式向ApplicaionMaster分配资源

      image-20231010200655616

    • 资源二次分配，在容器中将资源分配给Map任务和Reduce任务

      image-20231010200830634

    • 各个任务向ApplicationMaster汇报自己的状态和进度

      image-20231010201042955

  • 应用承租运行完成，注销关闭ApplicationMaster

    image-20231010201141438

8.3.5 Yarn框架和MapReduce1.0框架对比分析

  • 大部分API以及接口是兼容的

    image-20231010201238686

  • Yarn相对于MapReduce1.0的优势

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

  • 目标：在一个Yarn上运行多个计算框架

    image-20231010202132949

  • 为什么要实现“一个集群多个框架”？

    image-20231010202251106

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

      • 但是这样导致集群资源利用率低
      • 数据无法共享
      • 维护代价高

    • Yarn的实现优势

      image-20231010202736590

    • Yarn上部署各种计算框架

      image-20231010202840148

8.4 Hadoop生态系统中具有代表性的组件
8.4.1 Pig

  • Pig简要介绍

    image-20231010203117223

    image-20231010203149723

  • Pig提供的相关操作

    • 过滤，分组，连接，排序等

  • Pig的优势

    image-20231010203307471

  • Pig能做什么？

    • 加载数据，表达转换数据，存储最终结果

      image-20231010203419592

    • 企业将数据收集通过Pig进行数据加工：对收集过来的数据进行抽取、转换、加载，之后再放入数据仓库（Hive）

      image-20231010203607711

    • Pig Latin的应用程序实例

    image-20231010203830006

    • 将执行代码转换为流程图，使用MapReduce解决

      image-20231010203913989

  • Pig的应用场景

    image-20231010204557530

  • Pig的主要用户

    image-20231010204629960

8.4.2 Tez

  • Tez框架简要介绍

    image-20231010204721729

  • Tez将Map和Reduce拆分成更细粒度的字任务

    image-20231010204854402

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

  • HiveQL在MapReduce和Tez中的执行情况对比

    • 在MapReduce中三次写入HDFS的行为降低性能

    image-20231010205334881

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

  • Tez可应用于多个框架

    image-20231010205739565

  • Tez在Hadoop生态系统中的作用

    image-20231010205809967

  • Tez+Hive与Impala、Dremel、Drill区别

    image-20231010205959262

8.4.3 Spark和Kafka

  • Hadoop缺陷

    image-20231010210054034

  • Spark的优势

    image-20231010210147242

  • Kafka

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

  • Kafka作用

    image-20231010210349285

image-20231010210529435

这篇关于Hadoop2.0探讨的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/183845。

相关文章

如何与PM探讨项目

如何与PM探讨项目

我曾在2020年撰写过一篇名为对产品经理的一些思考的文章，紧接着在2021年，我又写了一篇对如何分析项目的思考。在这两篇文章中，我提出了一个核心观点：“船长需要把控所有事情，但最核心的是：需要知道目标是什么，船需要航行到哪里。”这个观点至今我依然坚持。 然而，船长的角色并不一定非得是产品经理，也可以是研发人员，甚至可以是我们大家一起扮演。因为这涉及到一个前提，那就是产品经理真的知道目标是什么吗？
阅读更多...
【AI应用探讨】—多模态应用场景

【AI应用探讨】—多模态应用场景

目录 1. 自动驾驶技术 多模态传感器融合 技术突破 2. 智能家居领域 多模态交互方式 应用实例 3. 智能客服领域 智能问答与情感分析 提升服务效率 4. 跨模态生成与理解 文字生成图像/视频 图像/视频生成文本 5. 未来发展趋势 多模态解析与生成 价值对齐与伦理考虑 1. 自动驾驶技术 多模态传感器融合 自动驾驶汽车通过融合摄像头、雷达、激光雷达
阅读更多...
用sentinel作Redis集群，总结下自己遇到的坑，以及探讨下改如何设置哨兵模式

用sentinel作Redis集群，总结下自己遇到的坑，以及探讨下改如何设置哨兵模式

先写总结 1.sentinel 的配置文件要配置master的密码：sentinel auth-pass mymaster phFUND_linux_redis。 2.为了主从能自由切换请给主从都配置好密码，而且要设置相同的密码（完成切换后，因为从没有配置masterauth，导致重启后连接不上主）: masterauth "phFUND_linux_redis" requirepass
阅读更多...
网页卷去的距离与偏移量的问题探讨

网页卷去的距离与偏移量的问题探讨

网页卷去的距离与偏移量 方便直观下面有一张图： scrollLeft:设置或获取位于给定对象左边界与窗口中目前可见内容的最左端之间的距离 ，即左边灰色的内容。 scrollTop:设置或获取位于对象最顶端与窗口中可见内容的最顶端之间的距离 ，即上边灰色的内容。 offsetLeft:获取指定对象相对于版面或由 offsetParent 属性指定的父坐标的计算左侧位置 。
阅读更多...
数据资产与企业绩效的紧密关联：深入解析数据资产如何直接影响企业绩效，并探讨如何通过策略性利用数据，优化运营，进而提升企业的整体业绩与竞争力

数据资产与企业绩效的紧密关联：深入解析数据资产如何直接影响企业绩效，并探讨如何通过策略性利用数据，优化运营，进而提升企业的整体业绩与竞争力

目录 一、引言 二、数据资产与企业绩效的紧密关联 （一）数据资产的定义与价值 （二）数据资产对企业绩效的影响 三、策略性利用数据资产优化运营 （一）建立数据驱动的企业文化 （二）构建完善的数据治理体系 （三）采用先进的数据分析技术 （四）实现数据资产的跨部门共享 四、案例分析与启示 （一）案例分析 （二）启示 五、结论 一、引言 在数字化浪潮席卷全球的今天，数
阅读更多...
【AI应用探讨】— 通义千问模型应用场景

【AI应用探讨】— 通义千问模型应用场景

目录 一、文字创作 二、文本处理 三、编程辅助 四、翻译服务 五、对话模拟 六、数据可视化 七、电商行业应用 八、教育行业应用 九、开发者与科研工作者应用 一、文字创作 故事、公文、邮件撰写：通义千问能够基于用户的指令和需求，生成符合要求的文本内容，如创作故事、撰写公文或邮件等。剧本、诗歌创作：其强大的文本生成能力也为文艺创作者提供了便利，如辅助创作剧本、诗歌等。
阅读更多...
如何配置Hadoop2.0HDFS的HA以及联邦使用QJM

如何配置Hadoop2.0HDFS的HA以及联邦使用QJM

配置过程详述       大家从官网下载的apache hadoop2.2.0的代码是32位操作系统下编译的，不能使用64位的jdk。我下面部署的hadoop代码是自己的64位机器上重新编译过的。服务器都是64位的，本配置尽量模拟真实环境。大家可以以32位的操作系统做练习，这是没关系的。关于基本环境的详细配置，大家可以观看我的视频，或者浏览吴超沉思录的相关文章。     在这里我们选
阅读更多...
Hadoop2.0的HDFS的改进

Hadoop2.0的HDFS的改进

http://dongxicheng.org/mapreduce/hdfs-federation-introduction/ HDFS Federation是Hadoop最新发布版本Hadoop-0.23.0中为解决HDFS单点故障而提出的namenode水平扩展方案。该方案允许HDFS创建多个namespace以提高集群的扩展性和隔离性。本篇文章主要介绍了HDFS Federation的设计
阅读更多...
探讨Nodejs中的作用域问题。

探讨Nodejs中的作用域问题。

在JS中有全局作用域和函数作用域，而在Nodejs中也自己的作用域，分为全局作用域（global）和模块作用域。 　　js作用域： 　　以前学js的时候我们的全局对象是window，如： var a = 10;console.log(window.a); 　　我们定义的全局变量默认是给window添加一个属性或者方法。 function fn(){var num = 22;
阅读更多...
Django与Flask的区别：从开发者视角的深度探讨

Django与Flask的区别：从开发者视角的深度探讨

Django与Flask的区别：从开发者视角的深度探讨 在现代Web开发中，Python的两大热门框架Django和Flask，常常引起开发者的热烈讨论。作为一个在Python生态系统中进行Web开发的技术员，选择适合的框架至关重要。今天，我将从技术特性、使用场景和开发者体验三个方面深入探讨Django和Flask的区别，帮助你在项目中做出更明智的选择。 一、技术特性 1.1 Django：
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2