HDFS HA和Yarn HA架构的概念和区别

最近开始学习大数据，学习过程中将一些知识点整理一下，方便自己复习

1.HDFS HA的概念和架构

什么是HA？ HA全称是High Availability，也就是高可用的意思。在企业中往往会使用集群来解决可用性问题，实现高可用。在HDFS的架构中，NameNode是负责客户端请求的响应以及元数据的管理（查询，修改等），所以NameNode就是HDFS集群中的单点故障（SPOF）发生点，一旦运行NameNode的机器挂了，那么整个HDFS就不可用了。 在hadoop 1.x版本中,是没有ha的实现方式的,它只有可以看做是冷备份的Secondary NameNode来起到冷备份的作用的,当NameNode挂掉的时候,我们需要手工启动Secondary NameNode。这样做能够提高一定的可用性，但是切换SNN仍然有一段时间空闲而在此期间整个服务都是不可用的。在hadoop 2.x版本后，提供了NameNode HA With QJM和NameNode HA With NFS两种HA方式，一般QJM方式使用较多这里也对此作出介绍。
首先看一个简单的架构图：

这是一个基本的HA架构。首先对图中的名词和功能作出讲解。

NN（NameNode）和DN（DataNode）是HDFS文件系统的核心组件，在HA架构中，设置了两个NN，他们分别有两种不同的状态：Active（活动的）和Standby（后备的），Active NN负责接收client的rpc请求并处理，写一份自己的editlog，同时也向JN（JournalNode）的共享存储上的写一份editlog。同时也接收来自DN的block report，block location updates 和 heartbeat。这里为JN是什么东西呢？JN即JournalNode,Journal中文意思是日志的意思，顾名思义JournalNodes的作用就是用于Active NN和Standby NN间的数据同步，本身由一组的JN节点组成的集群，它负责收集Active NN的editlog以便Standby NN使用。而Standby NN就是我们的后备NN，它从JN上读取的editlog并执行这些log操作，使自己的NN的元数据和Active NN的元数据是同步的，也就是说Standby是active NN的一个热备。一旦Active挂了自己便上位切换为active状态，并能够立即马上对外提供NN角色的服务。为了能够实现“立即”的效果，它同时也接收DN的block report，block location updates 和 heartbeat。

简而言之
把整个系统看成一个山寨，Active NN就是老大，它接收客户端发来的请求并将数据交给小弟DN，而Standby就是二大王，在老大ActiveNN在位的时候，他是没有权利直接接收客户端的请求的，但是老大Active NN有个习惯就是将自己的行为写一份日记到自己的日记本（JournalNode）中，而老二随时都可已读老大的日记本（读取JournalNodes中的editlog）了解寨中大事。同时小弟们（DN）向老大Active NN汇报时，也向老二汇（Standby）汇报自己的情况。这样老二不仅对寨中情况完全了解（读了老大的editlog），同时也对小弟们的情况（接收来自DN的block report，heartbeat等）这样在老大外出（Active NN挂了）时，老二能够马上上位，无缝切换。

两个NN，到底谁当Active谁当Standby，是由Zookeeper集群选举决定的，ZK就类似于选举委员会，所以ZK集群一般是由多台机器（2n+1）台组成的。在Active NN出问题的时候，立即投票选举其他Sandby的NN来提供服务。

最后是ZKFC组件，它的全称ZooKeeperFailoverController 即 Zookeepr故障转移控制器。它运行在每个NN节点中，作为一个ZK集群的客户端，用来监控NN的健康状态。它向ZK集群定期发送心跳 ，让自己被选举，当自己被ZK选举时，zkfc进程通过rpc调用让NN转换为active状态。

2.Yarn HA概念和架构

YARN是Hadoop 2.0中的资源管理系统,它也提供了一套HA架构，和HDFS的HA架构十分相似。
先上架构图

和NM(NodeManager)是Yarn的核心组件，ResourceManager负责接收客户端的任务请求，接收和监控NodeManager的资源的汇报，负责资源的分配与调度，启动和监控 ApplicationMaster（AM），是集群中单点故障的发生点，RM挂了整个服务也就挂了。借鉴HDFS HA的思想，Yarn的RM也分Active和Standby两种状态。在Active RM机器挂掉后，Standby RM作为备用而提供服务。RM在启动时会通过向ZK的/hadoop-ha目录写一个lock文件，写成功则为Active，否则Standby，Standby RM会一直监控lock文件的是否存在，如果不存在就会尝试去创建，争取为Active RM。Active RM在运行的时候，会将作业信息存储在ZK的/zkrmstore下，并向这个目录写入app信息。当Active RM挂了后，且另外一个Standby RM成为Active RM后，它会从/rmstore中读取相应的作业信息，并重新构建作业信息。然后启动内部服务，开始接收NM的心跳，构建集群资源的信息，并接收客户端的提交作业的请求等。在Yarn HA中，ZKFC自动故障转移作用和HDFS HA中的ZKFC作用类似，监控RM的健康状态，向ZK集群定期发送心跳 ，让自己被选举，当自己被ZK选举时，zkfc进程通过rpc调用让RM转换为active状态。区别在于Yarn HA的ZKFC只作为RM进程的一个线程 ，而非独立的守护进程来启动。

3.HDFS HA和YARN HA架构区别

HDFS HA	Yarn HA	相似点	不同点
NameNode	ResourceManger	都有Active和Standby两种状态，NN会写editlog到JN,而 RM会写app信息到RMstatestore	Standby NN会实时读取JN中的editlog并执行这些log操作，保持与Active NN的元数据同步，能够立即切换状态，客户端感受不到切换，而Standby RM只会在ActiveRM挂了只会才从/rmstore目录读取相应的作业信息，然后重新构建作业的内存信息 ，不能够立即切换状态，系统会中断服务一定时间，客户端能够感受到切换
JournalNode	RMstatestore	都提供一定的存储能力，JournalNode 记录NN的editlog，RMstatestore记录RM的app作业信息	JournalNode 是由一组的JN节点组成的集群，有自己的存储能力而RMstatestore只是将数据存储在ZK的/rmstore下
ZKFC	ZKFC	都提供监控和被选举功能，HDFS HA中ZKFC负责监控NN健康并向ZK集群定期发送心跳 ，让自己被选举；Yarn HA中ZKFC负责监控RM监控并向ZK集群定期发送心跳 ，让自己被选举	在HDFS HA中ZKFC单独作为一个守护进程而在Yarn HA中仅仅只作为RM进程的一个线程

4.其他一些问题

4.1 hdfs dfs -ls 结果是哪个目录

直接执行hdfs dfs -ls不加参数的话会访问当前用户目录
如当前用户名为hadoop001，則会访问路径/user/hadoop001
而执行hdfs dfs -ls /則会访问根目录

4.2.双写的理解

在生产中，往往会对数据进行双写，即数据库中（MySQL，HBase等）写一份数据，缓存（ElasticSearch，Redis）中写一份数据。一般情况数据库中会存储全部数据，而缓存中存储近期数据。这样双写的目的能够提高系统对数据的读取速度，增强并发性能。读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。

4.3.小文件的理解

什么的小文件？
小文件一般是指明显小于Hadoop的block size的文件，HDFS中文件是按Block来存储的，默认一个Block的长度一般是128MB。
危害？
当HDFS中存在大量小文件（长度小于128MB）时，不仅占用大量存储空间，而且也占用大量的Namespace，给Namenode带来了内存压力。
如何避免？
小文件产生前，文件是许多记录（Records）组成的，那么可以通过调用HDFS的sync()方法(和append方法结合使用)，每隔一定时间生成一个大文件。小文件产生后，可用通过一些方法对小文件进行合并。

4.4.主从架构的hbase读写经过master进程吗？

不经过
HBase主从架构有Master和RegionServer进程，但是读写是不经过Master进程的，以下是读写流程
读取流程：
(1) Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
(2) 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。
(3) 通过RegionServer获取需要查找的数据。
写流程：
(1) Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。
(2) 数据被写入Region的MemStore，直到MemStore达到预设阈值。
(3) MemStore中的数据被Flush成一个StoreFile。
(4) 随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
(5) StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
(6) 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上。
可以看出读写操作都是不经过Master进程的。

5.参考博客：

hadoop ha的实现方式原理介绍 https://blog.csdn.net/czz1141979570/article/details/86738013
HDFS高可用（HA）之ZKFC详解 https://blog.csdn.net/u012736748/article/details/79541311
Hadoop解决小文件存储思路 https://blog.csdn.net/LINBE_blazers/article/details/82861981
译[Hadoop]大量小文件问题及解决方案 https://blog.csdn.net/SunnyYoona/article/details/53870077
redis缓存学习笔记、双写一致性 https://blog.csdn.net/weixin_39446980/article/details/90450866
Hbase框架详解和读写流程分析 https://blog.csdn.net/u011833033/article/details/79773421