本文已参与「新人创作礼」活动，一起开启掘金创作之路。
1、NN和2NN工作机制
一个正常HDFS集群，读取和写入，尤其是读取是十分频繁的，读取则必然需要访问NN，读取元数据（存储数据的数据，比如索引信息），也就是说，在运行的集群中，元数据的读取是十分频繁的，而且时效性比较高，于是，元数据在运行中需要放在内存中（速度比较快）。
将所有元数据放在内存中，又会造成一旦机器断电，所有的元数据就消失不见了。
所以又需要将易丢失的数据放在磁盘上（持久化过程），一个64GB的NN，即使内存全部用来存储，也只能存放458129844个块，假如一块是128MB，也就是存放54PB的数据，与目前的数据量相比，54PB显然是不够的，实际上有27PB已经是很好的情况了，那么如何存储上忆PB的数据？首先想到的是将NN的内存扩大到128GB或256GB，第二是将扩大每个块的存储空间，第三个是HDFS的集群设计问题。
总之，NN的内存可能为256GB，这么大量的数据，在持久化过程中是十分困难的，需要的时间是很长的（6-20分钟），单纯的将易丢失的数据放在磁盘上就需要6分钟，并且在工作过程中NN是不接受读写请求的。
那么，如果NN只持久化操作，将存储元数据的操作写入磁盘中，这个操作称为编辑日志（edits.log），编辑日志中记录了操作人员的每一次操作，那么写的操作压力就变得小了许多，随之而来又会产生新的问题，一是随着操作的增加，日志文件会变得越来越大（几十TB），元数据却没有增加；二是，如果NN重启，需要将整个编辑日志从头到尾地读一遍，造成NN运行的时间越长，重启的时间就会越长。
NN在持久化时，只想写编辑日志（edits.log）出去，但是在启动时，又偏向于完整的内存镜像（fsimage），这时就产生了新的需求，于是2NN应运而生，2NN负责每隔一段时间（距离上一次CheckPoint【合并edits和fsimage】一小时或者edits记录的操作数达到100W次【可以自定义】），将edits.log合并成fsimage，在合并的过程中NN并不会下线，2NN在后台默默的工作，合并完成之后，将合并好的文件（fsimage.chkpoint）通过TCP发送给NN，这就是2NN的作用。
NN将edits.log发送给2NN时，NN仍然在继续工作，会产生新的edits.log，这也是2NN不能做NN热备的原因，2NN缺少一份最新的文件信息，有一套配置基本相同的服务器，但是它并不能做热备，所以很不划算，HA将2NN进行改进，可以做NN的热备。
NN中的文件
2NN中的文件
可以看出2NN与NN的区别只缺少了一个正在编辑的日志文件
Hadoop启动过程
Fsimage和Edits解析
****Edits是一个过程，并且将这个过程体现了出来，fsimage记录了一个时刻的状态。
查看fsimage文件
hdfs oiv -p XML -i 查看fsimage文件的文件名 -o 输出到哪里
hdfs oiv -p XML -i fsimage_0000000000000001153 -o /opt/module/hadoop-3.1.3/fsimage.xml
sz fsimage.xml
sz edits.xml
fsimage内部信息
edits内部信息
集群安全模式
安全模式是集群的一个自我保护状态，每次启动时会进入一次安全模式，当集群出现资源不足的情况会进入安全模式，进入安全模式时，集群不接受任何写请求，所有的读请求会被延迟。
fsimage只记录了文件在哪些块上，但是没有记录这些块在哪些dn上，而集群在运转时需要知道块在哪些dn上，在集群启动时，会加载fsimage，但是加载完fsimage，它并不知道系统中块数据的位置，在加载fsimage之后，它会等待dn主动向nn报告自己的块，从而把块列表的形式汇总起来来实现高效运行文件系统，这个过程是在安全模式下进行的。
块的位置信息是dn自己维护，为什么不是nn维护？
****为了运行速度，nn将元数据存放在内存中，问题就是关机元数据就消失了。如果其亲自维护，对于系统没有什么用，NameNode不知道它所维护的数据块的位置是否正确，因为nn不知道关机后是否发生了系统的更新（块位置信息是一个动态的信息），所以交给DataNode维护数据块的位置信息，当每次开机时，DN向NN定期汇报最新的数据块位置信息，而第一次汇报就是在集群刚刚启动的时候。
在满足最小副本条件（整个文件系统中99.9%的块满足最小副本级别【dfs.replication.min=1】）时，nn会在30S之后退出安全模式。
2、DataNode工作机制
****dn除了存储数据块以外，每个块内还存储了每个块的元信息，包括数据、数据长度、校验和、时间戳。当dn启动时，会主动向nn注册，之后nn会向dn发送注册成功的信息。以后周期性（1小时）上报dn持有的所有块信息，第一次是在系统安全模式时汇报。此外，每3秒钟会确定对方是否还在正常工作，称为心跳，心跳返回结果带有nn给dn的命令，超过3秒钟没有收到dn的心跳，不会立刻判定该节点不可用，超过10分钟 + 30秒没有收到dn的心跳，就会认为该节点不可用。在此期间进行操作，系统会报异常。
超时TimeOut计算公式：
TimeOut = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval
默认5分钟 默认30s
什么是校验
**** 检验数据在网络上传送过程中有没有错误，如奇偶校验，CRC循环冗余校验（32位），MD5校验（128位），sha1校验（160位）等，随着位数的上升，校验的准确度越高，同时所需要的资源的不断上升的。
集群的扩展
修改主机名
sudo hostnamectl --static set-hostname hadoop104
在101向104部署环境jdk hadoop
sudo rsync -av /opt/module/ hadoop104:/opt/
进入hadoop目录，删除hadoop文件夹下的data目录
rm -rf data logs edits.xml fsimage.xml
分发环境变量
sudo rsync -av /etc/profile.d hadoop104:/etc
检查以上步骤是否成功
hadoop version
java -version
直接在新扩展的机器上启动datanode
hdfs --daemon start datanode
启动nodemanager
yarn --daemon start nodemanager
群起需要配置主机上的works文件，再配置免密即可
cd /opt/module/hadoop-3.1.3/etc/hadoop/
vim workers
黑名单白名单
黑名单中的节点可以和主机进行连接，但不能访问datanode。
不在白名单中的主机不能够和主机进行连接。
在101上创建blacklist whitelist两个文件
cd /opt/module/hadoop-3.1.3/etc/hadoop/
vim blacklist(什么都不写)
vim whitelist 添加 hadoop101 hadoop102 hadoop103 hadoop104
在NameNode的hdfs-site.xml配置文件中添加两条配置信息
vim hdfs-site.xml
<property>
<name>dfs.hosts.exclude</name>
<value>/opt/module/hadoop3.1.3/etc/hadoop/blacklist</value>
</property>
<property>
<name>dfs.hosts</name>
<value>/opt/module/hadoop-3.1.3/etc/hadoop/whitelist</value>
</property>
重启hdfs集群
stop-dfs.sh
start-dfs.sh
使用黑名单和白名单管理节点
退役节点一定要用黑名单，不会出现丢失数据的情况，在退役时，其会将存储在自己节点上的数据备份到其他节点上，这个过程称为Decommissioning（正在退役中），当数据备份完成，节点状态变为Decommissioned（已退役）
退役101节点，编辑blacklist，加入hadoop101节点
刷新节点
hdfs dfsadmin -refreshNodes
当节点状态变为Decommissioned时，可以关闭此节点，经过10分钟后，节点状态变为Decommissioned & dead
hdfs -daemon stop datanode
在白名单中删除某一节点（不推荐），会造成数据的丢失，可以先进行以上步骤，当数据备份完成，再在白名单中删除此节点。
datanode多目录配置
<property>
<name>dfs.datanode.data.dir</name>
<value>file://${hadoop.data.dir}/data,file://${hadoop.data.dir}/data1</value>
</property>
DataNode可以配置成多个目录，每个目录存储的数据不一样。
