Hadoop知识概要

一、HDFS

Hadoop中的分布式文件系统，高容错（数据库blcok备份），可扩展，适合存储大文件，不适合存储小文件，不适合处理低延时的数据（HBase更好），一次写入、多次读写，不支持多用户写入及任意修改文件。

1、原理架构

1）NameNode：主节点，负责管理文件系统的命名空间，将HDFS的元数据存储在NameNode节点的内存中；负责响应客户端对文件的读写请求。
2）DataNode：数据节点，主要负责数据的读写, 存储block以及block元数据到datanode本地磁盘（此处的元数据包括数据块的长度、块数据的校验和、时间戳）；定期向NameNode发送心跳，超过10分钟节点不可用，6小时上报当前DataNode上的块状态。
3）SecondaryNameNode：辅助节点，定期做checkpoint操作，合并NameNode的fsimage及editlog，NameNode就有了最新的fsimage文件和更小的editslog文件，可减少恢复系统的时间，每小时或每分钟editslog含有100万个事务，就创建一个checkpoint检查点。

心跳机制：

集群的心跳机制，让集群中各节点形成一个整体，可以判断DataNode是否在线；知道各DataNode的存储情况；
集群刚开始启动时，99.9%的block没有达到最小副本数1，集群处于安全模式，涉及BlockReport；

首先，NameNode启动时会开一个ipc server；
DataNode每3秒钟向NameNode发送一个心跳，心跳返回结果带有NameNode给该DataNode的命令；
每6小时向NameNode上报当前DataNode上的块状态报告，块状态报告包含了一个该 Datanode上所有数据块的列表；
超过10分钟没有收到某个DataNode 的心跳，则认为该DataNode节点不可用。

负载均衡：

在机器之间磁盘利用率不平衡、DataNode节点出现故障、增添新的DataNode的时候可能造成不均衡；

可以手动触发负载均衡： sbin/start-balancer.sh -t 5% #

磁盘利用率最高的节点若比最少的节点，大于5%，触发均衡

2、SecondaryNameNode

引入原因：

客户端对HDFS的增删重命名等操作，会保存再次namenode的editlog中（相当于binlog）；系统出故障时，可从editlog进行恢复；

editlog日志大小，随时间越来越大，系统重启根据日志恢复的时候，会越来越长；

为解决恢复系统时间长：设置检查点checkpoint，定期将namenode内存中元数据持久化保存到磁盘，形成fsimage文件，恢复系统时不再只依赖editlog日志。（先从fsimage恢复出元数据，再到回放editlog日志检查点之后记录）；

但对editlog日志文件的保存策略未改变，editlog日志依然不断增大；

为解决editlog大，引入部署在另外一节点secondarynamenode，定期做checkpoint操作，合并fsimage及editlog，nameNode就有了最新的fsimage文件和更小的edits文件。

执行过程：

先请求NameNode，不干涉NameNode，让它继续写写edits日志）
再GET请求，读取NameNode当前fsimage及edits；
然后，读取fsimage到内存中，并回放执行edits中的每个操作，创建一个新的fsimage 文件，后缀为.ckpt；
最后PUT请求，将新的fsimage发送到原NameNode，原NameNode用新的fsimage替换旧的fsimage，

创建checkpoint两大条件：

SecondaryNameNode，每隔1小时创建一个检查点；

Secondary NameNode每1分钟检查一次，从上一检查点开始，edits日志文件中是否已包括100万个事务，如果是，也会创建检查点；

NameNode与SecondaryNameNode 的区别与联系？

(1）区别，功能不同

1）NameNode负责管理元数据，以及每一路径（文件）所对应的数据块信息。
2）SecondaryNameNode，主要定期合并NameNode的fsimage及editlog

（2）联系：

1）SecondaryNameNode中保存了一份，和namenode一致的镜像文件（fsimage）和编辑日志（edits）。
2）在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。

3、数据存储

（1）元数据管理

元数据：关于文件或目录的描述信息，如文件所在路径、文件名称、文件类型等等，这些信息称为文件的元数据metadata
命名空间：文件系统中，为了便于管理存储介质上的，给每个目录、目录中的文件、子目录都起了名字，这样形成的层级结构，称之为命名空间；
HDFS元数据：文件目录树、所有的文件（目录）名称、文件属性（生成时间、副本、权限）、每个文件的块列表、每个block块所在的datanode列表；
- 每个文件、目录、block占用大概 150Byte字节的元数据；
- 元数据metadata保存在NameNode内存中，所以HDFS适合存储大文件，不适合存储小文件

HDFS元数据信息以两种形式持久化保存：①编辑日志edits log 、②命名空间镜像文件fsimage

edits log：HDFS编辑日志文件，保存客户端对HDFS的所有更改记录，如增、删、重命名文件（目录），这些操作会修改HDFS目录树；NameNode会在编辑日志edit日志中记录下来；类似mysql的binlog。一旦系统出故障，可从editlog进行恢复

fsimage：HDFS元数据镜像文件，即将namenode内存中的数据落入磁盘生成的文件；保存了文件系统目录树信息以及文件、块、datanode的映射关系

分块存储

数据分块存储和副本的存放，是保证高可靠性和高性能的关键：

向HDFS上传文件，是按照128M为单位，切分成一个个block，分散的存储在集群的不同数据节点datanode上。
如果每个block只有一份的话，当block所在的节点宕机后，此block将无法访问，进而导致文件无法完整读取；
为保证数据的高可用及容错，HDFS设计成每个block共有三份，即三个副本；
实际机房中，会有机架，每个机架上若干服务器

4、写数据流程

请求上传——检查目录——可以上传

查询Datanode信息——分配datanode

建立数据流——根据管道写数据—— 循环写入其他block

1）请求上传：客户端向namenode请求上传文件，namenode检查目标文件是否已存在，父目录是否存在。 namenode返回是否可以上传。

2）分配datanode：客户端请求第一个block，可上传到哪几个datanode上，namenode查询Datanode信息，返回3个datanode节点，如dn1、dn2、dn3。

3）建立数据流管道：客户端请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，dn1、dn2、dn3逐级应答客户端，建立数据流管道pipeline ；

4）根据管道写数据：客户端开始往dn1上传第一个block，以packet为单位，dn1收到一个packet就会传给pipeline中的下一个 dn2，直到最后一个dn3；dn1每传完一个packet，会放入一个应答队列ackQueue等待应答；最后一个datanode成功存储之后，会返回给客户端ackQueue，成功收到ack后，会将packet删除，否则重新发送。

5）循环写入其他block：当一个block传输完成之后，客户端再次请求namenode上传第二个block的服务器。文件最后一个block块数据写完后，会再发送一个空的packet，表示当前block写完了，然后关闭pipeline；

5、读数据流程

1）客户端向namenode请求下载文件，namenode通过查询元数据，找到文件块所在的datanode地址。
2）挑选一台datanode（就近原则，然后随机）服务器，请求读取数据。
3）datanode开始传输数据给客户端（从磁盘里面读取数据放入流，以packet为单位来做校验）。
4）客户端以packet为单位接收，先在本地缓存，然后写入目标文件。

6、小文件治理

NameNode存储着文件系统的元数据，每个文件、目录、块大概有150字节的元数据；小文件数量多会大量占用namenode的内存; 使namenode读取元数据速度变慢, 启动时间延长; 还因为占用内存过大, 导致gc时间增加等.

解决办法:两个角度,

一是，数据源，如每小时抽取一次改为每天抽取一次等方法来积累数据量.
二是，合并方案，HAR文件方案、Sequence Files方案
开启JVM重用：一个Map运行在一个JVM上，开启重用的话，该Map在JVM上运行完毕后，JVM继续运行其他Map，对于大量小文件Job，可以减少45%运行时间

如果小文件无可避免，一般就采用合并的方式解决。可以写一个MR任务读取某个目录下的所有小文件, 并重写为一个大文件.

SequenceFile文件，是一种由header信息，和一条条record记录组成的文件。每个record是键值对形式，小文件名作为当前record的键，小文件的内容作为当前record的值；

Hadoop Archive或者HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问

7、高可用HA

对于HDFS，nameNode存储元数据在内存中，并负责管理文件系统的命名空间和客户端对HDFS的读写请求。只存在一个nameNode，一旦发生“单点故障”，会使整个系统失效。

HDFS2.x采用了HA（High Availability高可用）架构。（HDFS HA可看作为NN和SN的优化）；

主备NameNode：在HA集群中，可设置两个NameNode，只有一个NameNode处于active状态，另一个处于standby状态。其中，active状态的NameNode负责所有的客户端操作，standby状态的NameNode处于从属地位，维护着数据状态，随时准备切换。
数据同步：两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程(共享存储系统)，进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的
NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空
间。standby可以确保在集群出错时，命名空间状态已经完全同步。
块报告：为了确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。
Standby nameNode是Active nameNode的“热备份”，因此Active nameNode的状态信息必须实时同步到StandbynameNode。
对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。为了保证这点，JNs必须
确保同一时刻只有一个NameNode可以向自己写数据。

8、Hadoop联邦

HA高可用解决了单点故障问题，但HA本质上还是单个nameNode工作，在扩展性、整体性能和隔离性方面仍有问题。

扩展性：元数据存储在nameNode内存中，受限于内存上限（每个文件、目录、block占用约150字节）

整体性能：吞吐量受单个NN的影响

隔离性：一个程序可能会影响其他程序的运行，如果一个程序消耗过多资源会导致其他程序无法顺利运行

HDFS联邦，解决扩展性、整体性能、隔离性

扩展性：有多个命名空间；每个命名空间有一个nameNode或一主一备两个nameNode，使得HDFS的命名服务能够水平扩展；

整体性能：多个nameNode分别管理各自命名空间和块，相互独立，不需要彼此协调；

9、文件压缩

1）gzip压缩

优点：压缩率比较高，压缩/解压速度比较快；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便。
缺点：不支持split。
应用场景：当每个文件压缩之后在130M以内的（1个块大小内），都可以考虑用gzip压缩格式。譬如说一天或者一个小时的日志压缩成一个gzip文件，运行mapreduce程序的时候通过多个gzip文件达到并发。hive程序，streaming程序，和java写的mapreduce程序完全和文本处理一样，压缩之后原来的程序不需要做任何修改。

2）snappy压缩

优点：合理的压缩率，高速压缩速度；支持hadoop native库。
缺点：不支持split；压缩率比gzip要低；hadoop本身不支持，需要安装；linux系统下没有对应的命令
应用场景：当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。

3）lzo压缩

优点：合理的压缩率，压缩/解压速度也比较快；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；可以在linux系统下安装lzop命令，使用方便。
缺点：压缩率比gzip要低一些；hadoop本身不支持，需要安装；在应用中对lzo格式的文件需要做一些特殊处理（为了支持split需要建索引，还需要指定inputformat为lzo格式）。
应用场景：一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，lzo优点越明显

4）bzip2压缩

优点：支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux
系统下自带bzip2命令，使用方便。
缺点：压缩/解压速度慢。
应用场景：适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式；
或者输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情
况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持split，而且兼容之前的应用程序
（即应用程序不需要修改）的情况。

压缩率：bzip2 >gzip>lzo>snappy
压缩/解压速度：snappy>lzo>gzip>bzip2
支持split：lzo、bzip2
不支持native：bzip2
hadoop自带：gzip、bzip2
没有linux：snappy
压缩后的处理：只有lzo需要建立索引，其他和文本处理一样

hive数仓用的lzo格式，支持split，还有一个bzip2 也支持split，但是压缩速度太慢

10、文件存储格式

https://cloud.tencent.com/developer/article/2005288

hdfs 文件存储格式分为两大类：行存储和列存储

行存储：

行存储的写入是一次完成，在写入上有很大优势。将一整行存储在一起，是一种连续的存储方式，可以保证写入过程的成功或者失败，保证数据完整性。
查询时如果只需要某列信息，也必须把整行都读入内存当中，在内存中对冗余数据进行过滤。
因为在一行记录中可能存在多种类型的数据，数据解析需要在多种类型之间频繁转换，这个操作消耗CPU，增加了解析的时间

列存储：

列存储由于需要把一行记录拆分成单列保存，写入次数明显比行存储多，实际时间消耗会更大。
列存储会把文件切割成若干列，读取时只需要返回对应列的数据。
由于每一列中的数据类型相同所以可以根据数据类型选择适合的编码和压缩格式

对照表格

1) textfile

textfile为默认格式，加载速度最快，
可以采用Gzip进行压缩，压缩后的文件无法split。
在检索时磁盘开销大，数据解析开销大。

2) SequenceFile

SequenceFile是Hadoop提供的一种二进制文件,以[Key,Value]的形式序列化到文件中。可以把SequenceFile当做是一个容器，把所有的文件打包到SequenceFile类中可以高效的对小文件进行存储和处理。

SequenceFile主要由一个Header后跟多条Record组成。Header主要包含了Keyname和valuename，还包含了一些同步标识，用于快速定位到记录的边界。每条Record以键值对的方式进行存储，内容包括：记录长度、Key长度、Key值和value值，Value的结构取决于该记录是否被压缩。

SequenceFile支持三种记录存储方式：

无压缩, io效率较差. 相比压缩, 不压缩的情况下没有什么优势.
记录级压缩, 对每条记录都压缩. 这种压缩效率比较一般.
块级压缩, 这里的块不同于hdfs中的块的概念. 这种方式会将达到指定块大小的二进制数据压缩为一个块. 相对记录级压缩, 块级压缩拥有更高的压缩效率.

一般来说使用SequenceFile都会使用块级压缩. 但是SequenceFile只支持Java, SequenceFile一般用来作为小文件的容器使用, 防止小文件占用过多的NameNode内存空间来存储其在DataNode位置的元数据。

3) RCFile

在一般的列存储中，会将不同的列分开存储，有时候存在一个表的某些列不在同一个HDFS块上，所以在查询的时候，Hive重组列的过程会浪费很多IO开销。

RCFile是Hive推出的一种专门面向列的数据格式。存储方式为数据按行分块，每块按照列存储的行列混合模式，具有压缩高，列存取快的特点。

需要说明的是，RCFile在map阶段从远端拷贝仍然是拷贝整个数据块，并且拷贝到本地目录后RCFile并不是真正直接跳过不需要的列，而是通过扫描每一个行组的头部信息实现，但是在整个block级别的头部并没有定义每个列从哪个行组起始到哪个行组结束，所以读取全量数据的操作其性能比sequencefile低。

RCFile先将数据按行划分成行组，大小默认是4MB，行组内包括16字节的HDFS同步块信息，主要是为了区分同一个HDFS块上的相邻行组；
元数据的头部信息主要包括该行组内的存储的行数、列的字段信息等等；
在Row Group内部，再将数据按列划分存储。其结构如下：

4) ORCfile

是RCfile的升级版，支持文件切分，将数据划分为默认大小为250MB的stripe(条带),每个stripe包含索引,数据和footer。可以支持复杂的数据结构（比如Map等）

5) Parquet

parquet基于Google的dremel，擅长处理深度嵌套的数据(有点类似于嵌套多层的json格式)，parquet会将嵌套结构整合为平面列存储。

6) Avro

Avro 是 Hadoop 中的一个子项目，也是 Apache 中一个独立的项目，Avro 是一个基于二进制数据传输高性能的中间件。在Hadoop 的其他项目中，例如 HBase 和 Hive 的 Client端与服务端的数据传输也采用了这个工具。

Avro是一个语言无关的数据序列化的系统，它的出现主要是为了解决Writables缺少跨语言移植的缺陷。Avro将模式存储在文件头中，所以每个文件都是自描述的，而且Avro还支持模式演进(schema evolution)，也就是说，读取文件的模式不需要与写入文件的模式严格匹配，当有新需求时，可以在模式中加入新的字段。Avro支持分片,即使是进行Gzip压缩之后

二、MapReduce

MapReduce，是采用一种分而治之的思想，设计出来的分布式离线计算框架，输入输出都是hdfs。由两个阶段组成：Map阶段（切分成一个个小的任务）；Reduce阶段（汇总小任务的结果）

map任务一次读取block的一行数据，将当前所读行的行首相对于当前block开始处的字节偏移量作为key(0)，当前行的内容作为value，以kv对的形式输入map()方法； map()方法内，按需求，执行业务代码； map()方法的输出作为reduce()的输入；输入文件有几个block，就会生成几个map任务；

reduce任务通过网络将各map任务输出结果中，属于自己的数据拉取过来，key相同的键值对作为一组，调用一次reduce()；reduce任务生成一个结果文件，文件写入HDFS；reduce任务的个数，由程序中编程指定：job.setNumReduceTasks(4)。

1、shuffle

shuffle主要指的是map端的输出作为reduce端输入的过程

map端的shuffle

（1）环形内存缓冲：

每个map任务都有一个对应的环形内存缓冲区；map()方法输出kv对时，先写入到环形缓冲区（默认100M），当内容占据80%缓冲区空间后，由一个后台线程将缓冲区中的数据溢出写到一个磁盘文件。

在溢出写的过程中，map任务可以继续向环形缓冲区写入数据；但是若写入速度大于溢出写的速度，最终造成100m占满后，map任务会暂停向环形缓冲区中写数据的过程；只执行溢出写的过程；直到环形缓冲区的数据全部溢出写到磁盘，才恢复向缓冲区写入

（2）后台线程溢写磁盘过程，

1）分区：先对每个溢写的kv对，根据key进行hash分区；分区的个数由reduce任务数决定；可自定义分区，实现Partitioner接口，在getPartition()中实现分区逻辑。
2）排序：每个分区中，每个kv对，根据key在内存中排序，快速排序算法。
3）可选combine聚合：若设置了map端本地聚合combiner，则对每个分区中，排好序的数据做combine预聚合操作；
4）可选压缩：若设置了对map输出压缩的功能，会对溢写数据压缩，一般选择snappy，压缩速度高，压缩率合理。

reduce端的shuffle

（1）拉取：

reduce task会在每个map task运行完成后，通过HTTP获得map task输出中，属于自己的分区数据（许多kv对），如果map输出数据比较小，先保存在reduce的jvm内存中，否则直接写入reduce磁盘。

（2）归并merge:

一旦内存缓冲区达到阈值（默认0.66）或map输出数的阈值（默认1000），则触发归并merge，结果写到本地磁盘。

（3）combine（可选）：
若MR编程指定了combine，在归并过程中会执行combine操作

2、数据倾斜

MR数据倾斜，一般是指map端输出数据中，存在数据频率倾斜的状况，即部分输出键的数据量远远大于其它的输出键，导致map和reduce的任务执行时间大为延长，也会让需要缓存数据集的操作消耗更多的内存资源。

造成原因：

原数据频率不一致，某些key键值对数量远多于其他键的键值对，导致分区时分区不均匀，一些分区中数据多，一些少
原数据大小不同，某些key键值对的大小远远大于平均值。对缓存造成较大的影响，乃至导致OutOfMemoryError异常。

如何减缓数据倾斜：主要是分区不均匀，

1）预聚合：提前在map进行combine，减少传输的数据量

2）自定义分区：根据数据分布情况，自定义散列函数，将key均匀分配到不同Reducer

3）局部聚合加全局聚合。

二次mr，第一次将key随机散列到不同reducer进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀，按原key进行reduce处理，性能稍差。

4）增加Reducer，提升并行度:JobConf.setNumReduceTasks(int)

5）`数据大小倾斜`，调参line.maxlength，限制RecordReader读取最大长度。

3、优化

Map阶段优化

（1）增大环形缓冲区大小。由100m扩大到200m
（2）增大环形缓冲区溢写的比例。由80%扩大到90%
（3）减少对溢写文件的merge次数。（10个文件，一次20个merge）
（4）不影响实际业务的前提下，采用Combiner提前合并，减少 I/O。

Reduce阶段优化

（1）合理设置Map和Reduce数：两个都不能设置太少，也不能设置太多。太少，会导致Task等待，延长处理时间；太多，会导致 Map、Reduce任务间竞争资源，造成处理超时等错误。
（2）设置Map、Reduce共存：调整slowstart.completedmaps参数，使Map运行到一定程度后，Reduce也开始运行，减少Reduce的等待时间。
（3）规避使用Reduce，因为Reduce在用于连接数据集的时候将会产生大量的网络消耗。
（4）增加每个Reduce去Map中拿数据的并行数
（5）集群性能可以的前提下，增大Reduce端存储数据内存的大小。

IO传输

采用数据压缩的方式，减少网络IO的时间。安装Snappy和LZOP压缩编码器。

压缩：

（1）map输入端主要考虑数据量大小和切片，支持切片的有Bzip2、LZO。注意：LZO要想支持切片必须创建索引。
（2）map输出端主要考虑速度，速度快的snappy、LZO。
（3）reduce输出端主要看具体需求，例如作为下一个mr输入需要考虑切片，永久保存考虑压缩率比较大的gzip。

三、Yarn

1、原理架构

YARN(Yet Another Resource Negotiator)是Hadoop2.0资源管理的子项目

1） ResourceManager：全局资源管理器，一个集群只有一个RM，类似老总。负责与ApplicationMaster交互，资源调度、资源分配等；

2）NodeManager：一台机器上的管理者，类似于部门经理。管理着本机上若干小弟Containers的生命周期、监视资源和跟踪节点健康并定时上报给RM；接收并处理来自AM的Container启动/停止等各种请求。

3）ApplicationMaster：应用程序的管理器，类似项目经理，一个应用程序只有一个AM。负责任务开始时找RM要资源，任务完成时向RM注销自己，释放资源；与NM通信以启动/停止任务；接收NM同步的任务进度信息。

ApplicationMaster可以在容器内运行任何类型的任务，不同的 ApplicationMaster
被分布到不同的节点上，因此它们之间不会相互影响。

Container：一台机器上具体提供运算资源，类似员工，将设备上的内存、CPU、磁盘、网络等资源封装在一起的抽象概念——“资源容器”，Container是一个动态资源分配单位，为了限定每个任务使用的资源量。

Client向 ResourceManager 提交的每一个应用程序都必须有一个 ApplicationMaster，它经过 ResourceManager 分配资源后，运行于某一个 Slave 节点的 Container 中，具体做事情的 Task，同样也运行与某一个 Slave 节点的 Container 中。

2、执行过程

Application在Yarn中的执行过程，整个执行过程可以总结为三步：应用程序提交 -> 启动应用的ApplicationMaster实例 -> ApplicationMaster实例管理应用程序的执行

精简版的：

步骤1：客户端程序向 ResourceManager 提交应用，请求一个 RM的ApplicationMaster 实例，并请求传递给RM的scheduler（调度器）；调度器分配container（容器）
步骤2：ResourceManager 找到一个可以运行一个 Container 的 NodeManager，并在这个 Container 中启动 ApplicationMaster 实例；
步骤3：ApplicationMaster 与 ResourceManager 注册进行通信，为内部要执行的任务申请资源，一旦得到资源后，将于 NodeManager 通信，以启动对应的 Task；
步骤4：所有任务运行完成后，ApplicationMaster 向 ResourceManager 注销，整个应用程序运行结束。

2、调度器

在YARN中有三种调度器可以选择：**先进先出FIFO ，容量Capacity ，公平Fair **

3、yarn状态

yarn的web ui上能够看到yarn 应用程序分为如下8个状态:

新建、新建保存、提交、接受、运行、完成、失败、杀掉、

四、zookeeper

ZooKeeper是分布式应用程序的协调服务。主从架构leader、follower或observer

主要通过本身的文件系统和通知机制，维护和监控存储的数据的状态变化，达到基于数据的集群管理，主要用来解决分布式集群中应用系统的一致性问题（指数据在多个副本之间保持一致的特性）。

为了保证事务的顺序一致性，ZK采用递增的事务id号（zxid）来标识事务，所有提议（proposal）都有zxid。

ZooKeeper = 简版文件系统(Znode) +通知机制(Watcher)+原语(基本命令)

1、保证事务的顺序一致性

（1）zookeeper采用了全局递增的事务Id来标识，所有的 proposal（提议）在被提出时候，加上了 zxid。

zxid实际上是一个 64 位的数字，高32 位是 epoch用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增；低32位用来递增计数。

（2）当新产生proposal的时候，会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。

2、ZAB协议

ZAB协议是Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。

当整个zookeeper集群，刚刚启动、 Leader 宕机重启、网络故障导致不存在过半的服务器时。所有服务器，先进入恢复模式，选举新Leader，再进入广播模式，Follower与新 Leader进行数据同步

Zab协议两种模式：恢复模式（选主），广播模式（同步）

先进入恢复模式，选举新Leader

分两种情况：全新集群leader选举、非全新集群leader选举；
集群中过半数Server启动后，才能选举出Leader；
投票信息结构为(sid, zxid)，服务器ID，事务ID；
规则为：zxid大的server胜出；zxid相等，sid大的胜出。

再进入广播模式，Follower与新 Leader进行数据同步

leader构建NewLeader封包，包含leader中最大的zxid值，广播给其它follower；
follower收到后，如果自己的最大zxid小于leader的，则需要与leader状态同步；否则不需要；
leader给需要同步的每个follower创建LearnerHandler线程，负责数据同步请求；
leader主线程等待LearnHandler线程处理结果；
只有多数follower完成同步，leader才开始对外服务，响应写请求、

该协议需要做到以下几点：

（1）集群在半数以下节点宕机的情况下，能正常对外提供服务；

（2）客户端的写请求，全部转交给leader来处理，leader需确保写变更，能实时同步给所有follower及observer；

（3）leader宕机或整个集群重启时，需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交，确保丢弃那些只在leader服务器上被提出的事务，并保证集群能快速恢复到故障前的状态。

3、HDFS HA方案

主要分两部分**：①元数据同步 ②主备切换**

①元数据同步：

在同一个HDFS集群，运行两个互为主备的NameNode节点，在主备切换过程中，新的Active NameNode必须确保与原Active NamNode元数据同步完成，才能对外提供服务。
用JournalNode集群作为共享存储系统，客户端对HDFS做操作，同时会记录到JournalNode集群，存储HDFS新产生的元数据。
当有新数据写入JournalNode集群时，Standby NameNode能监听到此情况，将新数据同步过来。这样，Active NameNode(写入)和Standby NameNode(读取)实现元数据同步。

②主备切换：

每个NameNode节点上各有一个ZKFC进程，ZKFC会监控NameNode的健康状况，当发现Active NameNode异常时，通过Zookeeper集群进行namenode主备选举，完成Active和Standby状态的切换

4、四种类型的数据节点 Znod

（1）PERSISTENT-持久节点

除非手动删除，否则节点一直存在于Zookeeper上

（2）EPHEMERAL-临时节点

临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。

（3）PERSISTENT_SEQUENTIAL-持久顺序节点

基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

（4）EPHEMERAL_SEQUENTIAL-临时顺序节点

基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

5、Server工作状态

服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。

1）LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入 Leader 选举状态。
2）FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
3）LEADING：领导者状态。表明当前服务器角色是Leader。
4）OBSERVING：观察者状态。表明当前服务器角色是Observer。

6、ZK节点宕机如何处理？

Zookeeper本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时，其他节点会继续提供服务。

如果是一个Follower宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数据是有多个副本的，数据并不会丢失；

如果是一个Leader宕机，Zookeeper 会选举出新的 Leader。 ZK 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在 ZK 节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。

所以

3个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)

2个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)

7、集群支持动态添加机器吗？

    Zookeeper在水平扩容这方面不太好。两种方式：

全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。

逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。

3.5版本开始支持动态扩容。

8、Zk的java客户端都有哪些？

java客户端：zk 自带的 zkclient 及 Apache 开源的 Curator。

常用命令：ls get set create delete等

9、ACL访问控制列表

ACL(Access Control List)可以设置某些客户端，对zookeeper服务器上节点的权限，如增删改查等。ZooKeeper 采用 ACL（Access Control Lists）策略来进行权限控制。ZooKeeper 定义了如

CREATE -> 增 -> c
READ -> 查 -> r
WRITE -> 改 -> w
DELETE -> 删 -> d
ADMIN -> 管理 -> a
这5种权限简写为crwda下5种权限。

# 1）增加一个认证用户
# addauth digest 用户名:密码明文
addauth digest kkb:kkb# 2）设置权限
# setAcl /path auth:用户名:密码明文:权限
setAcl /zk_test auth:kkb:kkb:rw# 3）查看ACL设置
getAcl /zk_test