Logo

菜单

LarryDpk
发布于 2023-08-10 / 542 阅读
0

Hadoop入门教程

Hadoop入门教程

基础概念

数据分析的类别：

  • 离线分析（Batch Processing）
  • 实时分析（Real Time Processing / Streaming）
  • 机器学习（Machine Learning）

Hadoop核心组件：

  • HDFS（分布式文件存储系统）：解决海量数据存储
  • YARN（集群资源管理和任务调度框架）：解决资源任务调度
  • MapReduce（分布式计算框架）：解决海量数据计算

Google三篇论文：

  • The Google file system
  • MapReduce: Simplified Data Processing on Large Clusters
  • BigTable: A distributed Storage System for Structured Data

Hadoop现状

  • HDFS作为分布式文件存储系统，处在生态圈的底层与核心地位；
  • YARN作为分布式通用的集群资源管理和任务调度平台，支撑各种计算引擎运行，保证了Hadoop地位；
  • MapReduce作为大数据生态圈第一代分布式计算引擎，由于自身设计的模型所生产的弊端，导致企业一线几乎不再直接使用MapReduce进行编程处理，但是很多软件的底层依然在使用MapReduce引擎来处理数据。

Hadoop特性优点

  • Scalability 扩容能力
    Hadoop是在可用的计算机集群间分配数据并完成计算任务的，这些集群可方便灵活的方式扩展到数以千计的节点。

  • Economical 成本低
    Hadoop集群允许通过部署普通廉价的机器组成集群来处理大数据，以至于成本很低。看重的是集群整体能力。

  • Efficiency 效率高
    通过并发数据，Hadoop可以在节点之间动态并行的移动数据，使得速度非常快。

  • reliability 可靠性
    能自动维护数据的多份复制，并且在任务失败后能自动地重新部署（redeploy）计算任务。所以Hadoop的按位存储和处理数据的能力值得人们信赖。

Hadoop版本

Hadoop架构变迁（1.0-2.0变迁）

  • Hadoop 1.0
  1. HDFS（分布式文件存储）
  2. MapReduce（资源管理和分布式数据处理）
  • Hadoop 2.0
  1. HDFS（分布式文件存储）
  2. MapReduce （分布式数据处理）
  3. YARN(集群资源管理、任务调度）

1vs2细节可参考：https://www.hdfstutorial.com/blog/hadoop-1-vs-hadoop-2-differences/

Hadoop架构变迁（3.0新版本）

Hadoop 3.0架构组件和Hadoop 2.0类似，3.0着重于性能优化。

  • 通用方面
    精简内核、类路径隔离、shell脚本重构

  • Hadoop HDFS
    EC纠删码、多NameNode支持

  • Hadoop MapReduce
    任务本地化优化、内存参数自动推断

  • Hadoop YARN
    Timeline Service V2、队列配置

Hadoop集群

Hadoop集群整体概述

  • Hadoop集群包括两个集群 ：HDFS集群、YARN集群
  • 两个集群逻辑上分离、通常物理上在一起
  • 两个集群都是标准的主从架构集群

HDFS集群

  • 主角色：NameNode
  • 从角色：DataNode
  • 主角色辅助角色：SecondaryNameNode

YARN集群

  • 主角色：ResourceManager
  • 从角色：NodeManager

Hadoop安装包目录结构

目录 说明
bin Hadoop最基本的管理脚本和使用脚本的目录，这些脚本是sbin目录下管理脚本的基础实现，用户可以直接使用这些脚本管理和使用Hadoop。
etc Hadoop配置文件所在的目录
include 对外提供的编程库头文件（具体动态库和静态库在lib目录中），这些头文件均是用C++定义的，通第用于C++程序访问HDFS或者编写MapReduce程序。
lib 该目录包含了Hadoop对外提供的编程动态库和静态库，与include目录中的头文件结合使用。
libexec 各个服务对用的shell配置文件所在的目录，可用于配置日志输出、启动参数（比如JVM參数）等基本信息。
sbin Hadoop管理脚本所在的目录，主要包含HDFS和YARN中各类服务的启动/关闭脚本。
share Hadoop各个模块编译后的jar包所在的目录，官方自带示例。

配置文件

所有位置为： etc/hadoop

  • hadoop-env.sh: JDK等
  • core-site.xml: 默认文件系统、本地保存路径、代理等
  • hdfs-site.xml: SNN信息等
  • mapred-site.xml: MR程序运行模式、历史服务地址等
  • yarn-site.xml: 主角色位置等
  • workers: 工作的机器列表

NameNode format

首次启动之前需要format操作，只需要一次。

hdfs namenode -format

启动、停止命令

start-dfs.sh
stop-dfs.sh

start-yarn.sh
stop-yarn.sh

start-all.sh
stop-all.sh

检查进程：jps

查看日志：logs

查看UI：namenode:port/resourcemanager:port

常用命令

贴上一个pdf，有许多常用的命令可参考：

HDFS分布式文件系统

分布式存储系统核心属性

  • 分布式存储：无限扩容
  • 元数据记录：快速定位文件位置
  • 分块存储：文件过大不便处理，分块并行处理提高效率
  • 副本机制：不同机器设置备份，冗余存储，保障数据安全

HDFS简介

HDFS(Hadoop Distributed File System)，意为hadoop分布式文件系统。是Apache Hadoop的核心组件之一，作为大数据生态圈最底层的分布式存储服务而存在。

一主多从的分布式架构：

HDFS设计目标

  • 硬件故障（Hardware Failure）是常态，HDFS可能有成百上千的服务器组成，每一个组件都有可能出现故障。因此故障检测和自动快速恢复是HDFS的核心架构目标。
  • HDFS上的应用主要是以流式读取数据 ( Streaming Data Access )。HDFS被设计成用于批处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据访问的高吞吐量。
  • 典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件 ( Large Data Sets )。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。

HDFS架构图

  • 主从架构
    1. HDFS集群是标准的master/slave主从架构集群；
    2. 一般一个HDFS集群有一个NameNode和一定数目的DataNode组成；
    3. NameNode是主节点，DataNode是从节点；
  • 分块存储
    1. HDFS中的文件在物理上是分块（Block）存储的，默认大小是128M，不足128M则本身就是一块；
    2. 块的大小可以通过配置参数来规定，参数位于hdfs-default.xml中：dfs.blocksize；
    3. 文件的各个block的具体存储管理由DataNode节点承担；
  • 副本机制
    1. 文件所有的block都会有副本，副本系数可以在文件创建的时候指定，也可以在之后通过命令改变；
    2. 副本数由参数dfs.replication控制，默认值是3，也就是会额外再复制2份，连同本身总共3份副本。
  • 元数据记录
    1. 文件自身属性信息：文件名称、权限、修改时间、大小、复制因子、块大小等
    2. 文件块位置映射信息：记录文件块和DataNode之间的映射信息，即哪个块位于哪个节点上
  • 抽象统一的目录树结构（namespace）
    1. 支持传统的层次型文件组织结构；
    2. NameNode负责维护文件系统的namespace名称空间，任何对文件系统名称空间或属性的修改都将被NameNode记录下来；
    3. HDFS提供统一的抽象目录树，客户端通过路径来访问文件，如：hdfs://namenode:port/data/a.txt

主角色：NameNode

  • NameNode是Hadoop分布式文件系统的核心，架构中的主角色。
  • NameNode维护和管理文件系统元数据，包括名称空间目录树结构、文件和块的位置信息、访问权限等信息。
  • 基于此，NameNode成为了访问HDFS的唯一入口。
  • NameNode内部通过内存和磁盘文件两种方式管理元数据。
  • 其中磁盘上的元数据文件包括Fsimage内存元数据镜像文件和edits log (Journal）编辑日志。

职责：

  1. NameNode仅存储HDFS的元数据：文件系统中所有文件的目录树，并跟踪整个集群中的文件，不存储实际数据。
  2. NameNode知道HDFS中任何给定文件的块列表及其位置。使用此信息NameNode知道如何从块中构建文件。
  3. NameNode不持久化存储每个文件中各个块所在的DataNode的位置信息，这些信息会在系统启动时从DataNode重建。
  4. NameNode是Hadoop集群中的单点故障。
  5. NameNode所在机器通常会配置有大量内存 (RAN)。

从角色 DataNode

  • DataNode是Hadoop HDFS中的从角色，负责具体的数据块存储。
  • DataNode的数量决定了HDFS集群的整体数据存储能力。通过和NameNode配合维护着数据块。

职责：

  1. DataNode负责最终数据块block的存储。是集群的从角色，也称为Slave。
  2. DataNode启动时，会将自己注册到NameNode并汇报自己负责持有的块列表。
  3. 当某个DataNode关闭时，不会影响数据的可用性。NameNode将安排由其他DataNode管理的块进行副本复制。
  4. DataNode所在机器通常配置有大量的硬盘空间，因为实际数据存储在DataNode中。

主角色辅助角色： SecondaryNameNode

  • Secondary NameNode充当NameNode的辅助节点，但不能替代NameNode。
  • 主要是帮助主角色进行元数据文件的合并动作。可以通俗的理解为主角色的“秘书”。

文件系统协议

  • HDFS Shell CLI 支持操作多种文件系统 ，包括本地文件系统 (file:///）、分布式文件系统( hdfs://nn:8020 ）等
  • 具体操作的是什么文件系统取决于命令中文件路径URL中的前级协议。
  • 如果没有指定前级，则将会读取环境变量中的fs.defaultFs厲性 ，以该属性值作为默认文件系统。
hadoop fs -ls file:/// #操作本地文件系统
Hadoop fs -ls hdfs://node1:8020/ #操作HDFS分布式文件系统
hadoop fs -ls / #直接根目录，没有指定协议将加载读取fs.defaultFS值

hadoop fs其它类似旧命令：

hadoop dfs
hdfs dfs

HDFS工作流程与机制

写数据完整流程图：

  1. HDFS客户端创建对象实例DistributedFilesystem，该对象中封装了与HDFS文件系统操作的相关方法。
  2. 调用DistributedFileSystem对象的create()方法，通过RPC请求NameNode创建文件。NameNode执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过，NameNode就会为本次请求记下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据。
  3. 客户端通过FSDataOutputStream输出流开始写入数据。
  4. 客户端写入数据时，将数据分成一个个数据包（packet 默认64k），内部组件DataStreamer请求NameNode挑选出适合存储数据副本的一组DataNode地址，默认是3副本存储。 DataStreamer将数据包流式传输到pipeline的第一个DataNode,该DataNode存储数据包并将它发送到pipeline的第二个 DataNode。同样，第二个DataNode存储数据包并且发送给第三个（也是最后一个） DataNode。
  5. 传输的反方向上，会通过ACK机制校验数据包传输是否成功；
  6. 客户端完成数据写入后，在FSDataOutputStream输出流上调用close()方法关闭。
  7. DistributedFileSystem联系NameNode告知其文件写入完成，等待NameNode确认。 因为namenode已经知道文件由哪些块组成（Datastream青求分配数据块），因此仅需等待最小复制块即可成功返回。 最小复制是由参数dfs.namenode.replication.min指定，默认是1.

核心概念 - Pipeline

  • Pipeline，中文翻译为管道。这是HDFS在上传文件写数据过程中采用的一种数据传输方式。
  • 客户端将数据块写入第一个数据节点 ，第一个数据节点保存数据之后再将块复制到第二个数据节点，后者保存后将其复制到第三个数据节点。

为什么datanode之间采用pipeline线性传输，而不是一次给三个datanode拓扑式传输呢？

  • 因为数据以管道的方式，顺序的沿着一个方向传输，这样能够多充分利用每个机器的带宽，避免网络瓶颈和高延迟时的连接，最小化推送所有数据的延时。
  • 在线性推送模式下，每台机器所有的出口宽带都用于以最快的速度传输数据，而不是在多个接受者之间分配宽带。

核心概念 - ACK

  • ACK (Acknowledge character）即是确认宇符，在数据通信中，接收方发给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。
  • 在HDFS pipeline管道传输数据的过程中，传输的反方向会进行ACK校验 ，确保数据传输安全。

核心概念 - 默认3副本存储策略

默认副本存储策略是由BlockPlacementPolicyDefault指定。

  • 第一块副本：优先客户端本地，否则随机；
  • 第二块副本：不同于第一块副本的不同机架；
  • 第三块副本：第二块副本相同机架不同机器。

MapReduce 分布式计算框架

MapReduce设计思想

分而治之

  • MapReduce的思想核心是“先分再合，分而治之〞。
  • 所谓“分而治之〞就是把一个复杂的问题，按照一定的“分解”方法分为等价的规模较小的若干部分，然后逐个解决，分别找出各部分的结果，然后把各部分的结果组成整个问题的最终结果。
  • 这种思想来源于日常生活与工作时的经验。即使是发布过论文实现分布式计算的谷歌也只是实现了这种思想，而不是自己原创。

两个阶段

  • Nap表示第一阶段，负责“拆分〞：即把复杂的任务分解为若干个“简单的子任务”来并行处理。可以进行拆分的前提是这些小任务可以并行计算，彼此间几乎没有依赖关系。
  • Reduce表示第二阶段，负责“合并〞：即对map阶段的结果进行全局汇总。
    这两个阶段合起来正是MapReduce思想的体现。

Hadoop的设计构思

(1) 如何对付大数据处理场景

  • 对相互间不具有计算依赖关系的大数据计算任务 ，实现并行最自然的办法就是采取MapReduce分而治之的策略。
  • 首先map阶段进行拆分 ，把大数据拆分成若千份小数据，多个程序同时并行计算产生中间结果；然后是Reduce聚合阶段，通过程序对并行的结果进行最终的汇总计算，得出最终的结果。
  • 不可拆分的计算任务或相互间有依赖关系的数据无法进行并行计算！

(2) 构建抽象编程模型

NapReduce借鉴了函数式语言中的思想，用Map和Reduce两个西数提供了高层的并行编程抽象模型。

  • map：对一组数据元素进行某种重复式的处理；
  • reduce：对Nap的中间结果进行某种进一步的结果整理。
  • MapReduce中定义了如下的Map和Reduce两个抽象的编程接口，由用户去编程实现：
map: (k1:v1) --> (k2:v2)
reduce: (k2:[v2]) --> (k3:v3)
  • 通过以上两个编程接口，大家可以看出MapReduce处理的数据类型是（key, value)键值对。

(3) 统一架构、隐藏底层细节

  • 如何提供统一的计算框架，如果没有统一封装底层细节，那么程序员则需要考虑诸如数据存储、划分、分发、结果收集、错误恢复等诸多细节；为此，MapReduce设计并提供了统一的计算框架，为程序员隐藏了绝大多数系统层面的处理细节。
  • MapReduce最大的亮点在于通过抽象模型和计算框架把需要做什么（what need to do)与具体怎么做(how to do)分开了，为程序员提供一个抽象和高层的编程接口和框架。
  • 程序员仅需要关心其应用层的具体计算问题，仅需编写少量的处理应用本身计算问题的业务程序代码。
  • 至于如何具体完成这个并行计算任务所相关的诸多系统层细节被隐藏起来，交给计算框架去处理：从分布代码的执行，到大到数千小到单个节点集群的自动调度使用。

MapReduce特点

  • (1) 易于编程
    MapReduce框架提供了用于二次开发的接口；简单地实现一些接口，就可以完成一个分布式程序。任务计算交给计算框架去处理，将分布式程序部署到hadoop集群上运行，集群节点可以扩展到成百上千个等。

  • (2) 良好的扩展性
    当计算机资源不能得到满足的时候，可以通过增加机器来扩展它的计算能力。基于MapReduce的分布式计算得特点可以随节点数目增长保持近似于线性的增长，这个特点是MapReduce处理海量数据的关键，通过将计算节点增至几百或者几千可以很容易地处理数百TB甚至PB级别的离线数据。

  • (3) 高容错性
    Hadoop集群是分布式搭建和部署的，任何单一机器节点宕机了，它可以把上面的计算任务转移到另一个节点上运行，不影响整个作业任务得完成，过程完全是由Hadoop内部完成的。

  • (4) 适合海量数据的离线处理
    可以处理GB、TB和PR级别得数据量

MapReduce局限性

NapReduce虽然有很多的优势，也有相对的局限性，局限性不代表不能做，而是在有些场景下实现的效果比较差，并不适合用NapReduce来处理，主要表现在以下几个方面：

  • 实时计算性能差
    MapReduce主要应用于离线作业 ，无法作到秒级或者是亚秒级得数据响应。
  • 不能进行流式计算
    流式计算特点是数据是源源不断得计算，并日数据是动态的；而MapReduce作为一个离线计算框架，主要是针对静态数据集得，数据是不能动态变化的。

MapReduce实例进程

一个完整的NapReduce程序在分布式运行时有三类：

  • MRAppNaster：负责整个MR程序的过程调度及状态协调
  • MapTask ：负责map阶段的整个数据处理流程
  • ReduceTask ：负责reduce阶段的整个数据处理流程

阶段组成

  • 一个MapReduce编程模型中只能包含—个Nap阶段和一个Reduce阶段，或者只有Nap阶段；
  • 不能有诸如多个map阶段、多个reduce阶段的情景出现；
  • 如果用户的业务逻辑非常复杂，那就只能多个MapReduce程序串行运行。

MapReduce数据类型

  • 整个MapReduce程序中，数据都是以kv键值对的形式流转的；
  • 在实际编程解决各种业务问题中，需要考虑每个阶段的输入输出kv分别是什么；
  • MapReduce内置了很多默认属性，比如排序、分组等，都和数据的k有关，所以说kv的类型数据确定及其重要的。

MapReduce的过程

MapReduce的执行流程

WordCount编程实现思路

  • map阶段的核心：把输入的数据经过切割，全部标记1，因此输出就是<单词，1>。
  • shuffle阶段核心：经过NR程序内部自带默认的排序分组等功能，把key相同的单词会作为一组数据构成新的kv对。
  • Reduce阶段核心：处理shuffle完的一组数据，该组数据就是该单词所有的键值对。对所有的1进行累加求和，就是单词的总次数。

Map阶段

  • 第一阶段：把输入目录下文件按照一定的标准逐个进行逻辑切片，形成切片规划。
    默认Split size = Block size ( 128M），每一个切片由一个MapTask处理。 (getSplits)

  • 第二阶段：对切片中的数据按照一定的规则读取解析返回<key,value>对。
    默认是按行读取数据。key是每一行的起始位置偏移量，value是本行的文本内容。(TextInputFormat)

  • 第三阶段：调用Mapper类中的map方法处理数据。
    每读取解析出来的一个<key,value>，调用一次map方法。

  • 第四阶段：按照一定的规则对Map输出的键值对进行分区partition。默认不分区，因为只有一个ReduceTask。 分区的数量就是ReduceTask运行的数量。

  • 第五阶段：Map输出数据写入内存缓冲区，达到比例溢出到磁盘上。溢出spill的时候根据key进行排序sort。默认根据key字典序排序。

  • 第六阶段：对所有溢出文件进行最终的merge合并，成为一个文件。

Reduce阶段

Reduce阶段执行过程

  • 第一阶段：ReduceTask会主动从MapTask复制拉取属于需要自己处理的数据。
  • 第二阶段：把拉取来数据，全部进行合并merge，即把分散的数据合并成一个大的数据。再对合并后的数据排序。
  • 第三阶段是对排序后的键值对调用reduce方法。键相等的键值对调用一次reduce方法。最后把这些输出的键值对写入到HDFS文件中。

shuffle机制

  • shuffle的本意是洗牌、混洗的意思，把一组有规则的数据尽量打乱成无规则的数据。
  • 而在NapReduce中，Shuffle更像是洗牌的逆过程，指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据，以便reduce端接收处理。
  • 一般把从map产生输出开始到Reduce取得数据作为输入之前的过程称作shuffle。
Map端Shuffle
  • collect阶段：将MapTask的结果收集输出到默认大小为100M的环形缓冲区，保存之前会对key进行分区的计算，默认Hash分区。
  • Spill阶段：当内存中的数据量达到一定的阀值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了combiner，还会将有相同分区号和key的数据进行排序。
  • Merge阶段：把所有溢出的临时文件进行一次合并操作，以确保一个MapTask最终只产生一个中间数据文件。
Reduce端shuffle
  • Copy阶段：ReduceTask启动Fetcher线程到已经完成NapTask的节点上复制一份属于自己的数据。
  • Merge阶段：在ReduceTask远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作。
  • Sort阶段：在对数据进行合并的同时，会进行排序操作，由于MapTask阶段已经对数据进行了局部的排序，ReduceTask只需保证Copy的数据的最终整体有效性即可。
Shuffle机制弊端
  • Shuffle是MapReduce程序的核心与精髓，是MapReduce的灵魂所在。
  • Shuffle也是MapReduce被话病最多的地方所在。MapReduce相比较于Spark、Flink计算引擎慢的原因，跟Shuffle机制有很大的关系。
  • Shuffle中频繁涉及到数据在内存、磁盘之间的多次往复。

Hadoop YARN资源管理、调度平台

YARN简介

  • Apache Hadoop YARN (Yet Another Resource Negotiator ，另一种资源协调者）是一种新的Hadoop资源管理器。
  • YARN是一个通用资源管理系统和调度平台 ，可为上层应用提供统一的资源管理和调度。
  • 它的引入为集群在利用率、资源统—管理和数据共享等方面带来了巨大好处。

YARN功能说明

  • 资源管理系统：集群的硬件资源，和程序运行相关，比如内存、CPU等。
  • 调度平台：多个程序同时申请计算资源如何分配 ，调度的规则（算法）。
  • 通用：不仅仅支持MapReduce程序，理论上支持各种计算程序。YARN不关心你干什么，只关心你要资源，在有的情况下给你，用完之后还我。

YARN概述

  • 可以把Hadoop YARN理解为相当于一个分布式的操作系统平台，而MapReduce等计算程序则相当于运行于操作系统之上的应用程序，YARN为这些程序提供运算所需的资源（内存、CPU等）。
  • Hadoop能有今天这个地位，YARN可以说是功不可没。因为有了YARN，更多计算框架可以接入到HDFS中，而不单单是MapReduce，正是因为YARN的包容，使得其他计算框架能专注于计算性能的提升。
  • HDFS可能不是最优秀的大数据存储系统，但却是应用最广泛的大数据存储系统，YARN功不可没。

YARN架构

  • ResourceManager - （集群物理层面）
  • NodeManager - （集群物理层面）
  • ApplicationMaster ( App Mstr ) - （应用层面）
  • Client
  • Container容器（资源的抽象）

  1. ResourceManager （RM)
  • YARN集群中的主角色，决定系统中所有应用程序之间资源分配的最终权限，即最終仲裁者。
  • 接收用户的作业提交 ，并通过NM分配、管理各个机器上的计算资源。
  1. NodeManager ( NM)
  • YARN中的从角色，一台机器上一个，负责管理本机器上的计算资源。
  • 根据RM命令，启动Container容器、监视容器的资源使用情况。并且向RM主角色汇报资源使用情况。
  1. ApplicationMaster (AM)
  • 用户提交的每个应用程序均包含一个AM。
  • 应用程序内的“老大〞，负责程序内部各阶段的资源申请，监督程序的执行情况。

YARN交互流程

  • MR作业提交 Client --> RM
  • 资源的申请 MrAppNaster --> RM
  • MR作业状态汇报 Container ( Map/Reduce Task ) --> Container ( MrAppNaster）
  • 节点的状态汇报 NM --> RM

整体概述

当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序。

  • 第一个阶段是客户端申请资源启动运行本次程序的ApplicationMaster；
  • 第二个阶段是由ApplicationMaster根据本次程序内部具体情况，为它申请资源，并监控它的整个运行过程，直到运行完成。

MR提交YARN交互流程

  • 第1步、用户通过客户端向YARN中ResourceManager提交应用程序（比如hadoop jar提交MR程序）；
  • 第2步、ResourceManager为该应用程序分配第一个Container（容器），并与对应的NodeManager通信，要求它在这个Container中启动这个应用程序的ApplicationMaster。
  • 第3步、ApplicationNaster启动成功之后，首先向ResourceManager注册并保持通信，这样用户可以直接通过 ResourceManager查看应用程序的运行状态（处理了百分之几）；
  • 第4步、AM为本次程序内部的各个Task任务向RM中请资源，并监控它的运行状态；
  • 第5步、一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager通信，要求它启动任务。
  • 第6步、NodeManager为任务设置好运行环境后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
  • 第7步、各个任务通过某个RPC协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当前运行状态。
  • 第8步、应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。

YARN资源调度器Scheduler

如何理解资源调度

  • 在理想情况下，应用程序提出的请求将立即得到YARN批准。但是实际中，资源是有限的，并且在繁忙的群集上，应用程序通常将需要等待其某些请求得到满足。YARN调度程序的工作是根据一些定义的策略为应用程序分配资源。
  • 在YARN中，负责给应用分配资源的就是Scheduler，它是ResourceManaser的核心组件之一。Scheduler完全专用于调度作业，它无法跟踪应用程序的状态。
  • 一般而言，调度是一个难题，并且没有一个“最佳” 策路，为此，YARN提供了多种调度器和可配置的策略供选择。

调度器策略

  • 三种调度器
    FIRO Scheduler（ 先进先出调度器）、Capacity Scheduler （容量调度器）、Fair Scheduler （公平调度器）。
  • Apache版本YARN默认使用Capacity Scheduler。
  • 如果需要使用其他的调度器，可以在yarn-site.xml中的yarn.resourcemanager.scheduler.class进行配置。
FIFO Scheduler概述
  • FIFO Scheduler是Hadoop 1.x中JobTracker原有的调度器实现，此调度器在YARN中保留了下来。
  • FIFO Scheduler是一个先进先出的思想，即先提交的应用先运行。调度工作不考虑优先级和范国，适用于负载较低的小规模集群。 当使用大型共享集群时，它的效率较低且会导致一些问题。
  • FIFO Scheduler拥有一个控制全局的队列queue，默认queue名称为default，该调度器会获取当前集群上所有的资源信息作用于这个全局的queue。

优势：无需配置、先到先得、易于执行；

坏处：任务的优先级不会变高，因此高优先级的作业需要等待；不适合共享集群；

Capacity Scheduler概述
  • Capacity Scheduler容量调度是Apache Hadoop 3. x默认调度策略。该策略允许多个组织共享整个集群资源，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。
  • capacity可以理解成一个个的资源队列，这个资源队列是用户自己去分配的。队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。
Capacity Scheduler资源队列划分

Capacity Scheduler调度器以队列为单位划分资源。简单通俗点来说，就是一个个队列有独立的资源，队列的结构和资源是可以进行配置的。

Capacity Scheduler特性优势
  1. 层次化的队列设计 (Hierarchical Queues )
    层次化的管理，可以更容易、更台理分配和限制资源的使用。
  2. 容量保证 ( Capacity Guarantees)
    每个队列上都可以设置一个资源的占比，保证每个队列都不会占用整个集群的资源。
  3. 安全(Security）
    每个队列有严格的访问控制。用户只能向自己的队列里面提交任务，而且不能修改或者访问其他队列的任务。
  4. 弹性分配 ( Elasticity )
    空闲的资源可以被分配给任何队列。
    当多个队列出现争用的时候，则会按照权重比例进行平衡。
Fair Scheduler概述
  • Fair Scheduler叫做公平调度，提供了YARN应用程序公平地共享大型集群中资源的另一种方式。使所有应用在平均情况下随着时间的流逝可以获得相等的资源份额。
  • Fair Scheduler设计目标是为所有的应用分配公平的资源（对公平的定义通过参数来设置）。
  • 公平调度可以在多个队列间工作，允许资源共享和抢占。
如何理解公平共享
  1. 有两个用户A和B，每个用户都有自己的队列。
  2. A启动一个作业，由于没有B的需求，它分配了集群所有可用的资源。
  3. 然后B在A的作业仍在运行时启动了一个作业 ，经过一段时间，A，B各自作业都使用了一半的资源。
  4. 现在，如果B用户在其他作业仍在运行时开始第二个作业，它将与B的另一个作业共享其资源，因此B的每个作业将拥有资源的四分之一，而A的继续将拥有一半的资源。结果是资源在用户之间公平地共享。
Fair Scheduler特性优势
  • 分层队列：队列可以按层次结构排列以划分资源，并可以配置权重以按特定比例共享集群。
  • 基于用户或组的队列映射：可以根据提交任务的用户名或组来分配队列。如果任务指定了一个队列,则在该队列中提交任务。
  • 资源抢占：根据应用的配置，抢占和分配资源可以是友好的或是强制的。默认不启用资源抢占。
  • 保证最小配额：可以设置队列最小资源，允许将保证的最小份额分配给队列，保证用户可以启动任务。当队列不能满足最小资源时，可以从其它队列抢占。当队列资源使用不完时，可以给其它队列使用。这对于确保某些用户、组或生产应用始终获得足够的资源。
  • 允许资源共享：即当一个应用运行时，如果其它队列没有任务执行，则可以使用其它队列，当其它队列有应用需要资源时再将占用的队列释放出来。所有的应用都从资源队列中分配资源。
  • 默认不限制每个队列和用户可以同时运行应用的数量。可以配置来限制队列和用户并行执行的应用数量。限制并行执行应用数量不会导致任务提交失败，超出的应用会在队列中等待。
Kafka详解
Google Cloud Plat...