大数据(hadoop-分布式搭建和yarn)

依然范特西╮ 提交于 2019-12-01 00:10:28

分布式搭建步骤

1:克隆一台机器完成后,按以下步骤进行修改(作为源克隆主机)
    1)修改网卡信息,路径/etc/sysconfig/network-scripts
    2)删除70-persistent-net.rules这个文件,路径在:/etc/udev/rules.d
    3)修改hosts文件,设置ip和主机名对映关系
    如:
    127.0.0.1 localhost
       192.168.153.115 hm02
    192.168.153.116 hs0201
    192.168.153.117 hs0202
    4)重启

    5)删除hadoop和jdk的安装包(可选)
    6)删除hadoop2.7.3下面的tmp目录

2:克隆从节点后,修改步骤
    比上面的主节点的步骤,少3,5,6这几步


3:免密登陆设置
    1)重新生成私钥和公钥(主从节点)
    2)将公钥写入authorized_keys这个文件(主节点)
三台机器的免密设置
    3)将2台从节点上面的公钥远程拷贝到主节点
    4)在主节点上面将从节点的公钥合并到authorized_keys这个文件
    5)把这已经合并了三台机器公钥的authorized_keys文件分发到两个从节点上面
     cat id_rsa.pub_from_hs0201 >> authorized_keys
     scp authorized_keys hadoop@hs0202:~/.ssh/authorized_keys

4:hadoop分布式搭建
    hm02是主节点:namenode,resourcemanager
    hs0201和hs0202是从节点:datanode,nodemanager
    1):主从节点配置文件修改:
        (如果配置文件多且修改的内容较多,最好是在一台机器上设置好,再克隆)
     修改文件:
        (1)core-site.xml
            <value>hdfs://hm02:9000</value>
        (2)slaves
            添加从节点信息
            hs0201
            hs0202
        (3)yarn-site.xml
            <property>
                        <name>yarn.resourcemanager.hostname</name>
                        <value>hm02</value>
                </property>
                <property>
                        <name>yarn.nodemanager.aux-services</name>
                        <value>mapreduce_shuffle</value>
                </property>
            
    2)格式化主节点上的hdfs
         ./hdfs namenode -format

    3)启动集群进行测试
         ./sbin/start-all.sh 

    4)自带的mapreduce程序进行测试

 

Hadoop YARN产生背景

YARN产生背景—MapReduce 1.0固有问题

YARN产生背景—资源利用率

YARN产生背景—运维成本与数据共享

运维成本    如果采用“一个框架一个集群”的模式,则可能需要多个管理员管理这些集群,进而增加运维成本,而共享模式通常需要少数管理员即可完成多个框架的统一管理。

数据共享    随着数据量的暴增,跨集群间的数据移动不仅需花费更长的时间,且硬件成本也会大大增加,而共享集群模式可让多种框架共享数据和硬件资源,将大大减小数据移动带来的成本。

YARN产生背景—总结

直接源于MRv1在几个方面的缺陷
   扩展性受限
   单点故障
   难以支持MR之外的计算    

多计算框架各自为战,数据共享困难
   MR:离线计算框架
   Storm:实时计算框架
   Spark:内存计算框架 。

 

YARN基本架构

 

ResourceManager

负责集群资源的统一管理和调度

详细功能
   处理客户端请求
   启动/监控ApplicationMaster
   监控NodeManager
   资源分配与调度

NodeManager

负责单节点资源管理和使用

详细功能
   单个节点上的资源管理和任务管理
   处理来自ResourceManager的命令
   处理来自ApplicationMaster的请求 

ApplicationMaster

每个应用有一个,负责应用程序的管理

详细功能
与RM调度器协商以获取资源;
将得到的任务进一步分配给内部的任务(资源的二次分配);
与NM通信以启动/停止任务;
监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务。

Container

对任务运行环境的抽象

描述一系列信息
   任务运行资源(节点、内存、CPU)
   任务启动命令
   任务运行环境

YARN运行过程剖析

 

YARN容错性

ResourceManager
   存在单点故障;
   正在基于ZooKeeper实现HA    
NodeManager
   失败后,RM将失败任务告诉对应的AM;
   AM决定如何处理失败的任务
ApplicationMaster
   失败后,由RM负责重启;
   AM需处理内部任务的容错问题
   RMAppMaster会保存已经运行完成的Task,重启后无需重新运行。

YARN调度框架

双层调度框架
   RM将资源分配给AM
   AM将资源进一步分配给各个Task
    
基于资源预留的调度策略
   资源不够时,会为Task预留,直到资源充足
   与“ all or nothing”策略不同( Apache Mesos)     

YARN资源调度器

多类型资源调度
    目前支持CPU和内存两种资源    
提供多种资源调度器
   FIFO
   Fair Scheduler
   Capacity Scheduler
多租户资源调度器
   支持资源按比例分配
   支持层级队列划分方式
   支持资源抢占。

YARN资源隔离方案

支持内存和CPU两种资源隔离
   内存是一种“决定生死”的资源
   CPU是一种“影响快慢”的资源

内存隔离
   基于线程监控的方案

CPU隔离
   默认不对CPU资源进行隔离

应用程序种类繁多

YARN设计目标

通用的统一资源管理系统
   同时运行长应用程序和短应用程序

长应用程序
   通常情况下,永不停止运行的程序
   Service、HTTP Server等

短应用程序
   短时间(秒级、分钟级、小时级)内会运行结束的程序
   MR job、Spark Job等

以YARN为核心的生态系统

运行在YARN上的计算框架

     离线计算框架:MapReduce
     DAG计算框架:TEZ
     流式计算框架:Storm
     内存计算框架:Spark 

离线计算框架MapReduce

将计算过程分为两个阶段,Map和Reduce
   Map阶段并行处理输入数据
   Reduce阶段对Map结果进行汇总

Shuffle连接Map和Reduce两个阶段
   Map Task将数据写到本地磁盘
   Reduce Task从每个Map Task上读取一份数据

仅适合离线批处理
   具有很好的容错性和扩展性
   适合简单的批处理任务

缺点明显
   启动开销大、过多使用磁盘导致效率低下等

MapReduce On YARN

 

DAG计算框架Tez

多个作业之间存在数据依赖关系,并形成一个依赖关系有向图(Directed Acyclic Graph ),该图的计算称为“ DAG计算”

Apache Tez:基于YARN的DAG计算框架
   运行在YARN之上,充分利用YARN的资源管理和容错等功能;
   提供了丰富的数据流(dataflow)API;
   动态生成物理数据流关系。

 

Tez On YARN

Tez优化技术

ApplicationMaster缓冲池
   作业提交到AMPoolServer服务上
   预启动若干个ApplicationMaster,形成一个ApplicationMaster缓冲池
预先启动Container
   ApplicationMaster启动时可以预先启动若干个Container
Container重用
   任务运行完成后,ApplicationMaster不会马上注销它使用的Container,
   而是将它重新分配给其他未运行的任务

Tez应用场景

直接编写应用程序
   Tez提供了一套通用编程接口
   适合编写有依赖关系的作业

优化Pig、Hive等引擎
   下一代Hive:Stinger
   好处1:避免查询语句转换成过多的MapReduce作业后产生大量不必要
   的网络和磁盘IO
   好处2:更加智能的任务处理引擎

流式计算框架Storm

流式( Streaming) 计算,是指被处理的数据像流水一样不断流入系统,而系统需要针对每条数据进行实时处理和计算,并永不停止(直到用户显式杀死进程) ;

传统做法: 由消息队列和消息处理者组成的实时处理网络进行实时计算;
   缺乏自动化
   缺乏健壮性
   伸缩性差

Storm出现
 

内存计算框架Spark

     克服MapReduce在迭代式计算和交互式计算方面的不足
     引入RDD( Resilient Distributed Datasets)数据表示模型;
     RDD是一个有容错机制,可以被并行操作的数据集合,能够被缓存到内存或磁盘上

Spark On YARN

Spark生态系统

 

 

 

 

 

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!