06-Hadoop HA
一、Hadoop的HA
1、HA
H(high)A(avilable)： 高可用，意味着必须有容错机制，不能因为集群故障导致不可用！
HDFS： 满足高可用
NN： 一个集群只有一个，负责接受客户端请求！
DN： 一个集群可以启动N个
YARN： 满足高可用
RM： 一个集群只有一个，负责接受客户端请求！
NM： 一个集群可以启动N个
实现hadoop的HA，必须保证在NN和RM故障时，采取容错机制，可以让集群继续使用！
2、防止故障
核心： 避免NN和RM单点故障
以HDFS的HA为例：
① NN启动多个进程，一旦当前正在提供服务的NN故障了，让其他的备用的NN继续顶上
② NN负责接受客户端的请求
在接收客户端的写请求时，NN还负责记录用户上传文件的元数据
保证：正在提供服务的NN，必须和备用的NN之中的元数据必须是一致的！
元数据的同步： ①在active的nn格式化后，将空白的fsimage文件拷贝到所有的nn的机器上
②active的nn在启动后，将edits文件中的内容发送给Journalnode进程，standby状态的nn主动从Journalnode进程拷贝数据，保证元数据的同步
注意： ①Journalnode在设计时，采用paxos协议, Journalnode适合在奇数台机器上启动。在hadoop中，要求至少需要3个Journalnode进程。
②如果开启了hdfs的ha,不能再启动2nn
③ 当启动了多个NN时，是否允许多个NN同时提供服务？
不允许多个NN同时对外提供服务，因为如果多个NN同时对外提供服务，那么在同步元数据时，非常消耗性能，而且容易出错！
在同一时刻，最多只能有一个NN作为主节点，对外提供服务，其余的NN，作为备用节点！
使用active状态来标记主节点，使用standby状态标记备用节点！
3、HDFS HA的搭建步骤
①配置
- fs.defaultFS=hdfs://hadoop101:9000 进行修改
- 在整个集群中需要启动N个NN，配置N个NN运行的主机和开放的端口！
- 配置Journalnode
②启动
- 先启动Journalnode
- 格式化NN，精格式化后的fsimage文件同步到其他的NN
- 启动所有的NN，需要将其中之一转为active状态
4、自动故障转移
借助Zookeeper实现自动的故障转移！
在每个NN所在的机器，启动一个ZKFC进程，这个进程会维护一个zookeeper客户端！
在启动了这个进程后，如果当前机器的NN可用，ZKFC进程会抢先向ZK集群中注册一个临时节点！
哪个ZKFC进程拥有对这个临时节点的所有权，会对节点加锁！在此进程的Session未断开前，占用此节点！
此时，这个ZKFC进程会将当前机器的NN提升为active!
每个ZKFC进程负责和NN进行进行ping通信，一旦发现ping命令回复超时，会认为此NN已经假死，假死后，zkfc会断开
session，放弃对zookeeper上节点的控制权，其他的ZKFC进程负责监听节点，一旦节点不存在，其他的zkfc进行开始
抢占此节点，哪个ZKFC进程抢占成功，就会把它所在机器的NN提升为active，在提升之前，必须保证不能出现脑裂，
因此使用fence机制，将之前的NN进行隔离！
二、压缩
1、压缩的目的
压缩的目的是在MR运行期间，提高MR运行的效率！
压缩可以减少MR运行期间的磁盘IO和网络IO！
2、 压缩的场景
IO密集型，可以多用压缩！
运行密集型，CPU负载过重，少用或不用压缩！
3、在MR中压缩的位置
输入的文件采用压缩格式：
当单个文件压缩之后，如果超过130M，可以考虑使用带切片的压缩格式！
在shuffle阶段使用压缩：
考虑速度！速度快即可！
reduce输出的结果采用压缩：
考虑当前Job的输出是否还会作为下一个Job的输入，再考虑输出的结果每个大小是否会超过130M,
如果超过，还需要作为下一个Job的输入，可以考虑使用带切片的压缩格式！
4、常见的压缩格式
4.1、默认： deflate,bzip2,gzip
4.2、额外安装的： lzo,snappy
4.3、特点：
- bzip2压缩比最高，压缩速度最慢
- snappy压缩速度最快，压缩比凑合
- deflate，gzip折中
4.4、使用便利性：
LZO压缩格式最麻烦！
①额外安装LZO压缩格式
②如果JOB输入目录中的文件为LZO压缩格式，需要为每个文件创建索引，如果不创建索引，那么输入的文件无法切片，整个文件作为1片。还需要使用LZO特定的输入格式，使用LZOInputFormat！
其他的压缩格式，和纯文本文件使用一致的，不需要额外设置！
4.5、可切片的角度：
如果Job的输入采用了以下压缩格式，只有以下格式支持切片！
只有bzip2和lzo可以切片！
4.6、使用场景：
① Bzip2： 对速度没有要求，常作为reduce输出结果的压缩格式！
即便job运行后，输出的结果还需要被另一个Job继续处理，Bzip2格式也可以支持切片！
② Lzo: 作为Job输入文件的压缩格式！
③ Snappy: 作为shuffle阶段的压缩格式！
Mapper 运算结束后，需要向磁盘溢写 500M的数据，没有用压缩之前，写的速度100M/s
采用了Snappy压缩，需要向磁盘溢写 500M的数据，采用了snappy压缩，写的速度100M/s，500M--->300M
Reduce拷贝300M的数据----> 解压缩（速度很快，解压缩消耗的时间可以忽略不计）------>
4.7、压缩的考虑：
① Mapper的输入： 主要考虑每个文件的大小，如果文件过大，需要使用可以切片的压缩格式！
② Reducer的输出： reducer的输出主要考虑，输出之后，是否需要下一个Job继续处理！
单个reducer输出的结果的大小！
如果需要被下个Job继续处理，且单个文件过大，也要使用可以切片的压缩格式！
③shuffle阶段： 速度快即可
三、调度器
1、FIFO调度器
FIFO调度器的特点就是单队列，所有的Job按照客户端提交的先后顺序，先到先服务！
弊端： 如果当前队列中有一个大的Job，非常消耗资源，那么这个Job之后的其他Job都需要付额外的等待时间，造成集群的资源利用率不足！
解决： 采取多队列的配置
2、容量调度器
容量调度器的本质是多个FIFO的队列组成！
Hadoop默认使用就是容量调度器！
特点： 容量
- 每个队列可以配置一定的容量，空闲的资源可以匀给其他队列临时使用
- 可以配置每个job使用的容量的限制，防止一个大的job独占所有资源
- 可以配置每个用户可以使用的容量限制，防止当个用户占用所有资源
优点：
- 配置灵活，及时刷新即可、
- 资源利用率高
- 安全，可以配置每个队列的访问用户限制
3、公平调度器
公平调度器的设置和容量调度器大致相同，也是多条队列，每天队列都可以设置一定的容量。每个Job，用户可以设置容量！
区别： 公平调度器在调度策略上，采用最大最小公平算法，来调度Job，这个算法会保证同一个队列中，所有已经提交，未运行结束的Job，获取到队列中的资源是平等的！
导致在一个队列中，小的Job运行有优势，大的Job可能不能及时获取到必须的所有资源，但是不至于饿死！
四、推测执行
在MR运行期间，MRAppMaster会为最慢的任务启动一个备份任务，备份任务和当前任务先运行完的会采用其结果！
不适用场景：
①数据有倾斜
②特殊场景： 向数据库写记录
推测执行是典型的以空间换时间，因此在集群资源不足时，如果开启了推测执行，反而不能取得效果！
五、Hadoop的优化
1、小文件的优化
① 源头上处理，在上传到集群之前，提前处理小文件
② 小文件已经在HDFS存在，可以使用hadoop archieve进行归档
③ 在运行MR时，可以使用CombineTextInputFormat将多个小文件规划到一个切片中
④ 小文件过多，可以开启JVM重用
2、MR的优化
① 合理设置MapTask和ReduceTask的数量：在合理利用资源的情况下，提高程序并行运行的效率
② 避免数据倾斜
Map端的数据倾斜： 在切片时，注意每片数据尽量均匀。防止有些不可切片的数据！
Reduce端的数据倾斜： 提前对数据进行抽样调查，统计出大致的分布范围，根据分布范围，合理编写Partitioner，让每个分区的数据尽量均衡
③ 优化磁盘IO和网络IO
a)启用combiner
b)启动压缩
c)调大MapTask缓冲区的大小，减少溢写次数
d)调大MapTask中merge阶段一次合并的片段数，减少合并花费的时间
e)调大reduceTask中shuffle线程可以使用的内存，减少溢写次数
d)调大reduceTask中，input.buffer的大小，提前缓存部分数据到buffer中
