Hadoop面试题
1.基础
1.1 Hadoop是什么
定义:hadoop是一个分布式系统基础架构,主要是为了解决海量数据存储和海量数据分析计算问题。
1.2 Hadoop的特点
- 高可靠性:多副本机制
- 高扩展性:可以方便扩展任务节点
- 高效性:并行分布式处理
- 高容错性:自动将失败的任务重新分配
1.3 Hadoop生态圈
- zookeeper:一个开源的分布式应用程序协调服务,基于zk可以使用同步服务,配置维护,命名服务
- Flume:一个高可用、高可靠、分布式的海量日志采集、聚合和传输的系统
- Hive:基于Hadoop的一个数据仓库工具,可以将结构化的数据映射为一张数据库表,并提供简单的sql查询功能,可以将sql语句转换为MR任务运行
- Hbase:一个分布式、面向列的开源数据库,利用HDFS作为其存储系统
- Sqoop:将一个关型数据库中的数据导入到HDFS中,也可以将HDFS中的数据导入到关型数据库中
1.4 Hadoop核心组件
-
HDFS:具有高可靠性、高吞吐量的分布式文件系统,用于数据存储
- 使用场景:适合一次写入,多次读出的场景
-
MapReduce:处理业务逻辑运算,分布式运算程序的编程框架
- 计算过程分为两个阶段
- Map:并行处理输入数据
- Reduce:对Map结果进行汇总
-
Yarn:负责作业调度与集群资源管理
- Yarn是一个资源调度平台,负责为运算程序提供服务器运算资源,相当于一个分布式的操作系统平台,MR等运算程序相当于操作系统只是的应用程序
-
Common:辅助工具,为其它模块提供基础设施
- 提供工具包,配置文件和日志操作等
1.5 Hadoop1.x 2.x 3.x
-
Hadoop 1.x:MR同时负责处理业务逻辑运算和资源的调度
-
Hadoop 2.x/3.x:增加了Yarn负责资源的调度,MR负责运算
1.6 Hadoop工作进程
HDFS
-
NameNode:Master,hadoop的管理者
- 管理hdfs的名称空间
- 配置副本策略
- 管理数据块映射信息
- 处理客户端读写请求
-
DataNode:Slave,NN负责管理,DN执行实际的操作
- 存储数据块
- 执行数据块的读/写操作
-
Secondary Namenode:提供周期检查点和清理任务,帮助NN合并editslog,减少NN启动时间
- 辅助NN,分担工作,定期合并Fsimage和Edits,并推送给NN
- 紧急情况下,辅助恢复NN
Yarn
-
ResourcManager (JobTracker):负责集群中所有资源的统一管理和分配
- 与客户端交互、处理来自客户端的请求
- 启动和管理ApplicationMaster,并在它运行失败时重新启动它
- 管理NM,接受来着各个节点NM的资源汇报信息,并想NM下达管理指令
- 资源管理与调度,接受来自ApplicationMaster的资源申请请求,并为之分配资源
-
NodeManager (TaskTracker):单个节点的资源管理者
- 从ApplicationMaster上接受有关的Container的命令并执行(比如启动、停止Container)
- 向RM汇报各个Container运行状态和节点健康状况,并领取有关Container的命令(清理Container)
- NM管理的是Container而不是任务,一个Container中可能运行着各种任务,但是对NM而言是透明的,他只负责Container的相关操作
-
ApplicationMaster:应用程序内的“老大”
- 复制程序内部各阶段的资源申请,监督程序的执行情况
高可用
-
DFSZKFailoverController
- 高可用时它负责监控NameNode的状态,并及时的把状态信息写入Zookeeper
-
JournalNode
- 高可用情况下存放NameNode的editlog文件
1.7 Hadoop块大小&分块原因
Hadoop 2.7.2版本及之前默认64MB,Hadoop 2.7.3版本及之后默认128M
块大小的设置对hadoop的影响?
-
块设置太小
- 会增加寻址的时间,而且NN需要大量的内存来存储元数据
-
块设置太大
- 从磁盘传输数据的时间会明显大于寻址时间,导致程序在处理这块数据时,会非常的慢
- map任务一次只处理一个块中的数据,快过大会导致运行速度变慢
HDFS块的大小设置主要取决于磁盘传输速率
为什么要分块存储?
- 简化系统的设计和存储管理,块的大小是固定的
- 块更适合数据备份
- 减少磁盘寻道时间
1.8 Hadoop常见的压缩算法
-
bzip2
- 优点:支持split,具有很高的压缩率,高于gzip
- 缺点:不支持native,速度比较慢
- 应用场景:适合对速度要求不高,但需要较高的压缩率的时候
-
gzip
- 优点:压缩率比较高,速度比较快
- 缺点:不支持split
- 应用场景:当每个文件压缩之后为一个块的大小,都可以考虑使用gzip压缩格式
-
lzo
- 优点:压缩/解压速度也比较快,合理的压缩率;支持split,是hadoop中最流行的压缩格式
- 缺点:压缩率低于gzip,hadoop本身不支持,需要安装
-
应用场景:一个很大的文本文件,压缩之后还大于200M以上的可以考虑,而且单个文件越大,lzo优点
越明显
-
snappy
- 优点:高速压缩速度和合理的压缩率
- 缺点:不支持split;压缩率比gzip要低;hadoop本身不支持,需要安装;
- 应用场景:(提高MR速度)当Mapreduce作业的Map输出的数据比较大的时候,作为Map到Reduce的中间数据的压缩格式;或者作为一个Mapreduce作业的输出和另外一个Mapreduce作业的输入
lzo,snappy需要操作系统安装native库才可以支持
1.9 Hadoop序列化
为了传输和存储
序列化:将内存中的对象,转换成字节序列
反序列化:将字节序列转换成内存中的对象
Hadoop开发了自己的序列化机制
- java序列化太笨重(附带很多额外的信息,继承体系),不利于网络中的高效传输
1.10 Hadoop小文件处理
小文件的size远小于block size的大小,hadoop适合处理少量的大文件,而不是大量的小文件。
小文件导致的问题
- 一个小文件会占用NN 150byte的内存,数据很多会增加了NN的内存负担,制约了集群的扩展
- 访问速度慢,寻址时间会大于传输时间
- 一个小文件会有一个task,导致task运行时间中启动和释放task时间占比重
自带解决方案
-
SequenceFile:由一系列的二进制key/value组成
-
以key为小文件名,value为文件内容,将大批小文件合并成一个大文件
-
不能使用append方法,适合一次性写入大量小文件的场景
-
-
MapFile:MapFile是排序后的SequenceFile,MapFile由两部分组成,分别是index和data
-
index作为文件的数据索引,主要记录了每个Record的key值,以及该Record在文件中的偏移位置
-
在MapFile被访问的时候,索引文件会被加载到内存,通过索引映射关系可迅速定位到指定Record所在文件位置
-
有序是由用户保证的
-
1.11 Hadoop2.x升级3.x
-
最低要求Java版本从7升级到了8
-
支持HDFS中的纠删码
- 纠删码是一种持久存储数据的方法,可节省大量空间。
-
Shell脚本重写
-
MR任务本地优化
-
支持两个以上的NN
- 高可用模式在,standby NN的数量多了
-
默认端口更改
- NN端口:9870、9820(8020)、9871
- SNN端口:9869、9868
- DN端口:9867、9866、9865、9864
- KMS端口:9600
-
支持Microsoft Azure数据湖和阿里云存储系统文件连接器
-
数据内节点平衡器
- 多个磁盘之间的平衡填充,新增的磁盘也可以
-
基于HDFS路由器的联合
-
Yarn资源模型通用化
2.HDFS
2.1 HDFS文件读写流程
写入数据过程
四个步骤:申请上传、确定上传位置、建立通信管道、传输数据
-
请求上传:客户端通过
Distributed FileSystem
模块向NN请求上传文件,NN检查目标文件是否已经存在、父目录是否存在 - 上传应答:NN返回是否可以上传
- 请求block位置:客户端请求第一个block上传到那几个DN服务器上
- 位置应答:NN返回3个DN节点
- 请求管道传输:客户端通过FSDataOutputStream模块请求DN1上传数据,DN1收到请求会继续调用DN2,然后DN2调用DN3,建立起通信管道传输
- 传输应答:三个节点逐级应答客户端
- 数据传输:客户端向DN1上传第一个block(先从磁盘缓存到本地内存),以packet为单位,DN1收到后会往下传输,DN1每传一个packet就会放入一个应答队列等待应答
- 当第一个block传输完成后,客户端再次请求第二个block的位置,重复执行以上步骤,直至传输完毕。
读取数据过程
分批次读取数据
2.2 HDFS组成架构
-
Client
- 文件切分,文件上传到HDFS时,会先将文件切分为一个一个的Block
- 管理和访问HDFS
-
NameNode
负责管理整个集群以及维护集群的元数据信息
- 管理HDFS名称空间
- 管理数据块的映射信息
- 配置副本策略
- 处理客户端读写请求
-
DataNode
- 存储数据
- 执行读写请求
-
Secondary NameNode
- 辅助NN,分担工作量
- 定期合并Fsimage和Edits,并推送给NN
2.3 HDFS优缺点
HDFS是一个文件系统,用于存储文件,通过目录树来定位文件。其次,它是分布式的,由很多服务器联合起来实现其功能,集群中的服务器有各自的角色。
优点
- 高容错性:多副本机制
- 适合处理大数据:支持PB级别数据,也支持处理百万文件规模数据
- 经济性:可构建在廉价机器上
缺点
- 不适合低时延数据访问
- 无法高效的对大量小文件进行存储
- 不支持并发写入、文件随机修改:仅支持数据追加
2.4 HDFS容错机制
故障检测机制
-
DataNode失效:心跳机制
- 每个DataNode以固定的周期向NN发送心跳信号,通过这种方式告诉NN在正常工作。在一定的时间内NN没有收到DN心跳,就认为DN宕机
-
网络故障:ACK应答机制
- HDFS提供了ACK机制,在发送端发送数据后,如果没有收到ACK,并且多次重试之后,则认为网络故障
-
数据损坏(脏数据):校验码机制
- 在传输数据的时候,同时会发送总和校验码,当数据存储到硬盘时,总和校验码也会被存储
- 所有的DN都会定期向NN发送数据块的存储情况
- 在发送数据块报告时,会先检查总和检验码是否正确,如果数据存在错误就不发送该数据块的信息
2.5 HDFS存储机制
-
NameNode:Master,hadoop的管理者
- 管理hdfs的名称空间
- 配置副本策略
- 管理数据块映射信息
- 处理客户端读写请求
-
DataNode:Slave,NN负责管理,DN执行实际的操作
- 存储数据块
- 执行数据块的读/写操作
-
Secondary Namenode:提供周期检查点和清理任务,帮助NN合并editslog,减少NN启动时间
- 辅助NN,分担工作,定期合并Fsimage和Edits,并推送给NN
- 紧急情况下,辅助恢复NN
-
Edit Log:修改日志
- 当client进行写操作时,此写操作记录会放入修改日志中。
-
Fsimage:命名空间镜像
- 是内存中的元数据在硬盘上的checkpoint
- 当NN失效的时候,最新的checkpoint元数据信息就会从fsimage加载到内存中,然后重新执行修改日志中的操作
-
checkpoint过程
- 生成新的日志文件:SNN通知NN生成新的日志文件,以后日志文件写入新的日志文件
- 获取旧的日志文件和fsimage:SNN通过http get从NN获得fsimage文件以及旧的日志文件
- 生成新的fsimage:SNN将fsimage文件加载到内存中,并执行日志文件中的操作,然后生成新的fsimage
- 传回新的fsimage:SNN将新的fsimage文件用http post传回到NN
- 新的fsimage和日志文件替代旧的:NN可以将旧的fsimage文件以及旧的日志文件,换为新的fsimage文件和新的日志文件,然后更新fstime文件,写入此次checkpoint的时间
2.6 HDFS常见数据格式
-
行式存储
- Sequence File
- Map File
- Avro Data Files
-
优点:
- 行存储的写入一次性完成,写入效率高,并且能够保证数据的完整性
-
缺点:
- 数据读取过程中会产生冗余数据,读取数量大的数据可能会影响数据的处理效率
-
列式存储
- Parquet
- RC Files
- ORC Files
-
优点:
- 读取过程中,不会产生冗余数据
-
缺点:
- 写入效率和保证数据完整性上不如行存储
2.7 HDFS高可用实现原理
HDFS高可用(HA)方案是为了解决NN单点故障的问题产生的
HDFS的HA,指的是在一个集群中存在多个NameNode,分别运行在独立的物理节点上。在任何时间点,只有一个NameNode是处于Active状态,其它的是处于Standby状态。 Active NameNode(简写为Active NN)负责所有的客户端的操作,而Standby NameNode(简写为Standby NN)用来同步Active NameNode的状态信息,以提供快速的故障恢复能力。
为了保证Active NN与Standby NN节点状态同步,即元数据保持一致。除了DataNode需要向这些NameNode发送block位置信息外,还构建了一组独立的守护进程”JournalNodes”(简写为JNs),用来同步Edits信息。当Active NN执行任何有关命名空间的修改,(定期写入,所以可能会丢失)它需要持久化到一半以上的JNs上。而Standby NN负责观察JNs的变化,读取从Active NN发送过来的Edits信息,并更新自己内部的命名空间。一旦Active NN遇到错误,Standby NN需要保证从JNs中读出了全部的Edits,然后切换成Active状态,如果有多个Standby NN,还会涉及到选主的操作,选择一个切换为Active 状态。
这里的元数据包含两块,一个是静态的,一个是动态的
静态的是fsimage和edits,其实fsimage是由edits文件合并生成的,所以只需要保证edits文件内容的一致性。这个就是需要保证多个NameNode中edits文件内容的事务性同步。这块的工作是由JournalNodes集群进行同步的
动态数据是指block和DataNode节点的信息,这个如何保证呢? 当DataNode启动的时候,上报数据信息的时候需要向每个NameNode都上报一份。 这样就可以保证多个NameNode的元数据信息都一样了,当一个NameNode down掉以后,立刻从Standby NN中选择一个进行接管,没有影响,因为每个NameNode 的元数据时刻都是同步的。
使用zookeeper集群自动切换的原理
当多个NameNode 启动的时候会向zookeeper中注册一个临时节点,当NameNode挂掉的时候,这个临时节点也就消失了,这属于zookeeper的特性,这个时候,zookeeper就会有一个watcher监视器监视到,就知道这个节点down掉了,然后会选择一个节点转为Active,把down掉的节点转为Standby
2.8 HDFS数据一致性
- 心跳机制
- 安全模式
- 回滚机制
- 安全校验
- 回收站
3.MapReduce
3.1 MR是什么
MR是一个分布式运算程序的编程框架,核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序。
3.2 MR优缺点
优点
- 易于编程
- 良好的扩展性
- 高容错性
- 适合PB级以上海量数据的离线处理
缺点
- 不擅长实时计算
- 不擅长流式计算
- 不擅长DAG计算
3.3 MR架构
MR也采用主从架构。包含四个组成部分。
- client
-
JobTracker:复制资源监控和作业调度
- 监控所有TaskTracker和job的监控状况
-
TaskTracker
- 会周期性地通过Heartbeat将本节点上资源的使用情况和任务进度汇报给JobTracker
-
Task
- Map task
- Reduce task
3.4 MR运行原理
Client提交作业流程
-
提交作业
-
Client提交Job
- Clien编写好Job后,调用Job实例的Submit()提交作业
- 从RM获取新的作业ID(Application ID)
-
Job提交到RM
- Client检查作业的输出说明,计算输入分片,并将作业资源复制到HDFS上
- 调用RM的submitApplication()方法提交作业
-
Client提交Job
-
作业初始化
-
给作业分配ApplicationMaster
- 当RM收到调用它的submitApplication()消息后,便将请求传递给scheduler调度器
- scheduler分配一个Container,然后RM在该NM的管理下在Container中启动ApplicationMaster
-
ApplicationMaster初始化作业
- MR作业的ApplicationMaster是一个Java应用程序,主类是MRAppMaster。对作业进行初始化:通过创建多个薄记对象以保持作业进度的跟踪,因为它将接受来自任务的进度和完成报告
- ApplicationMaster从HDFS获取在Client计算的输入分片(map、reduce任务数)
-
给作业分配ApplicationMaster
-
任务分配
- ApplicationMaster为该作业中的所有map任务和reduce任务向RM请求Container
-
任务执行
- 一旦RM的scheduler为任务分配了Container,ApplicationMaster就通过与NM通信来启动Container
- 该任务由主类为YardChild的Java应用程序执行。在它运行任务之前,首先将任务需要的资源本地化
- 最后运行map任务和reduce任务
-
进度和状态的更新
- 在YARN下运行,任务每 3s通过 umbilical 接口向 ApplicationMaster 汇报进度和状态(包括计数器),作为作业的汇聚试图(aggregate view)
-
作业完成
- )程序运行完毕后,MR 会向 RM 申请注销自己
MapReduce执行流程
Map
-
对文件进行逻辑切片,每一个切片由一个MapTask处理
-
按行读取数据,按照一定规则解析返回键值对key是每一行的起始位置偏移量,value是本行的内容
-
调用Mapper类中的map方法处理数据输出键值对
对每一个解析key-value键值对调用一次map方法
-
按照一定规则对map输出的键值对进行分区(Hash求余),默认不分区,因为只有一个reduceTask
-
将map输出数据写入内存缓冲区
-
shuffle的sort、spill和merge阶段
Reduce
- shuffle的copy和merge阶段
- 对排序后的键值对调用reduce方法,键值相等的键值对调用一次reduce方法。最后输出reduce结果到HDFS文件中
3.5 MR中的Combine
Combine阶段是当Map阶段所有数据处理完成后,MapTask对所有临时文件进行一次合并,以确保最终只会生成一个数据文件。让每个MapTask最终只生成一个数据文件,可避免同时打开大量文件和同时读取小文件产生的随机带来的开销。
Combiner能够应用的前提是不能影响最终的业务逻辑,且Combiner的数据k-v应该跟reducer的输入k-v类型要对应起来
- 程序中有两个阶段可能会执行combine操作:
- map输出数据根据分区排序完成后,在写入文件之前会执行一次combine操作(前提是作业中设置了这个操作)
- 如果map输出比较大,溢出文件个数大于3(此值可以通过属性
min.num.spills.for.combine
配置)时,在merge的过程(多个spill文件合并为一个大文件)中还会执行combine操作
- 只有满足以下条件才可以:
- reduce的输入输出类型都一样,因为combine本质上就是reduce操作
- 计算逻辑上,combine操作后不会影响计算结果,像求和就不会影响
3.6 MR shuffle过程
定义:shuffle像是洗牌的逆过程,将map端的无规则数据按指定规则“打乱”成具有一定规则的数据,以便reduce端接收处理
Map端shuffle
一个mapTask只会产生一个文件
-
Collect阶段:将MapTask的结果收集到默认大小为100M的环形缓冲区,保存之前对key进行分区的计算,默认Hash分区(分区数量为reduce task的数量)
- 环形缓冲区:会存储一个四元组包括:k-v键值对的k和v的起始位置、分区号和value的长度,还会存储k-v键值对本身,四元组往起点的后面存储扩展,键值对往起点的前面扩展,互不干涉
-
Spill阶段:当内存中的数量达到一定的阈值(默认80%)时,将数据写入到本地磁盘,将数据写入磁盘之前需要对数据进行一次排序(sort)的操作
- sort:按照分区好和key两个关键之升序排序,只移动索引四元组数据,排序结果会将一个分区放在一起,分区内key升序(快排)
- spill文件分为两个,一个索引文件一个数据文件,索引文件存放的是三元组(分区的起始位置,原始数据长度,压缩之后数据长度)
- spiil和map任务是并行的,环形缓冲区的起始位置会变动的,spill之后起始位置会变为剩余空间的中间位
- 注意可能存在combine操作
-
Merge阶段:将所有溢出的临时文件进行一次合并操作,合并之后会再次排序,以确保一个MapTask最终只产生一个中间数据文件。(多路归并排序->最小堆K路归并排序)
Reducer端shuffle
- Copy阶段:ReduceTask启动Fetcher线程到MapTask节点上复制一份属于自己的数据
- Merge阶段:在ReduceTask远程复制数据的同时,会在后台开两个线程对内存到本地的数据文件进行合并
- Sort阶段:在对数据进行合并的同时,会进行合并排序操作
3.7 MR shuffle过程的必要性
- Map是映射,复制数据的过滤分发,Reduce是规约,负责数据的计算归并。
- Reduce需要通过shuffle来获取数据
3.8 MR环形缓冲区
- 使用环形缓冲区,便于写入缓冲区和写出缓冲区同时进行
- 为了防止阻塞,所以环形缓冲区不会等缓冲区满了再spill
- 每个Map任务不断地将键值对输出到在内存中构造的一个环形数据结构中,使用环形数据结构是为了更有效地使用内存空间,在内存中放置尽可能多的数据。
- 避免产生Full GC
3.9 MR shuffle为什么要排序
shuffle排序,按照字典顺序来排序,目的是将相同的key提前放到一起。
- 是为了降低内存的使用量:reudce阶段需要分组,将相同的key放在一起进行合并
- sort是用的外部排序,可以对任意数据量进行分组
- 减轻reduce端排序的压力
3.10 map side join原理
Map Join简单来说就是在Map阶段将小表读入内存,顺序扫描大表完成Join。减少昂贵的shuffle操作以及reduce操作
- 通过MapReduce Local Task,将小表读入内存,生成HashTableFiles上传至Distributed Cache中,这里会对HashTableFiles进行压缩。
- MapReduce Job在Map阶段,每个Mapper从Distributed Cache读取HashTableFiles到内存中,顺序扫描大表,在Map阶段直接进行Join,对于大表中的每一条记录key/value,在hash table中查找是否有相同的key的记录,如果有,则连接后输出即可。
3.11 map reduce join原理
reduce side join是一种最简单的join方式,其主要思想如下:
在map阶段,map函数同时读取两个文件File1和File2,为了区分两种来源的key/value数据对,对每条数据打一个标签(tag),比如:tag=0表示来自文件File1,tag=2表示来自文件File2。即:map阶段的主要任务是对不同文件中的数据打标签。在reduce阶段,reduce函数获取key相同的来自File1和File2文件的value list,然后对于同一个key,对File1和File2中的数据进行join(笛卡尔乘积)。即:reduce阶段进行实际的连接操作。
然后对于同一个key,对File1和File2中的数据进行join(笛卡尔乘积)。即:reduce阶段进行实际的连接操作。
3.12 MR的Task数量
MapTask
block块:是HDFS当中存储数据的单位,是物理划分单位
切片split:是MapReduce当中每个MapTask处理数据量的单位,逻辑划分
切片大小默认是block块的大小,计算公式如下
Math.max(minSize, Math.min(maxSize, blockSize));
mapreduce.input.fileinputformat.split.minsize=1 // 默认值为1
mapreduce.input.fileinputformat.split.maxsize= Long.MAXValue
// blockSize为128M
为了提高并行度,可以修改maxsize和minsize的值
ReduceTask
数量默认为1,job.setNumReduceTasks(int n)
可以直接设置数量
3.13 MR数据倾斜
数据倾斜:数据的key的分化严重不均,造成一部分数据很多,一部分数据很少的局面
解决方案
-
业务和数据方面解决
- 有损的方法:找到异常数据
- 无损的方法:对分布不均匀的数据,进行单独计算,首先对key做一层hash,把数据打散,提高并行度,然后汇集数据
- 数据预处理
-
Hadoop平台的解决方法
- 针对join产生的数据倾斜
- 大表和小表join产生的数据倾斜:使用map side join
- 大表和大表join产生的数据倾斜:将异常值赋值随机值,分散key
- group by造成的数据倾斜
- 开启map端聚合操作,相当于combiner
- count(distinct)或者其他参数不当造成的数据倾斜(没懂)
- reduce个数太少
- 使用sum group by替代
- 针对join产生的数据倾斜
3.14 MR分布式缓存
DistributedCache是Hadoop为MapReduce框架提供的一种分布式缓存机制,它会将需要缓存的文件分发到各个执行任务的子节点的机器中,各个节点可以自行读取本地文件系统上的数据进行处理。
用于Map Side Join
4.Yarn
4.1 YARN架构
YARN是一个资源调度平台,负责为运算程序提供服务器运算资源,相当于一个分布式的操作系统平台,而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。
-
ResourceManager(RM)
- 处理客户端请求
- 监控NodeManger
- 启动或监控ApplicationMaster
- 资源的分配与调度
-
NodeManager(NM)
- 管理单个节点上的资源
- 处理来自RM的命令
- 处理来自AMstr的命令
-
ApplicationMaster(AM)
- 为应用程序申请资源并分配个内部的任务
- 任务的监督与容错
-
Container
- Container是YARN中的资源抽象,封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等
4.2 YARN工作流程
- MR程序提交到客户端节点
- YarnRunner向RM申请一个Application
- RM将该应用程序的资源路径以及Application ID返回给YarnRunner
- 客户端将程序运行所需资源提交到HDFS上
- 程序资源提交完毕后,向RM申请运行mrAppMaster
- RM将用户的请求初始化成一个Task
- 其中一个NM领取到Task任务,并创建Container,然后产生mrAppMaster
- Container从HDFS上拷贝资源到本地
- mrAppMaster向RM申请运行MapTask资源
- RM将运行的MapTask任务分配给另外两个NM,这两个NM领取任务并创建容器
- MR向两个接到到任务的NM发送程序启动脚本,这两个NM分别启动MapTask
- mrAppMaster等待所有的MapTask运行完毕后,向RM申请容器,运行Reduce Task
- ReduceTask向MapTask获取相应分区的数据
- 程序运行完毕后,MR向RM申请注销自己
4.3 YARN调度器
-
FIFO:单队列,根据作业的先后顺序,先来先服务
-
Capacity:多队列的FIFO,默认调度策略
- 多队列
- 容量保证:每个队列设置资源最低保证和资源使用上限
- 灵活性:如果一个队列中的资源有剩余,可以暂时共享给其他队列,可随时归还资源
- 多租户:支持多用户共享集群和多应用程序同时运行
-
Fair
- 公平调度可以在多个队列间工作,允许资源共享和抢占
- 多队列的公平共享策略