Hadoop-HDFS(HDFS-HA)
HDFS(Hadoop Distributed File System) 分布式文件系统，HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用.由NameNode，若干DataNode，以及Secondary NameNode组成。
HDFS组成架构
HDFS文件块大小：
HDFS客户端Shell操作
常用命令实操（0）启动Hadoop集群（方便后续的测试）[atguigu@hadoop102 hadoop-2.7.2]$ sbin/start-dfs.sh[atguigu@hadoop103 hadoop-2.7.2]$ sbin/start-yarn.sh（1）-help：输出这个命令参数[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -help rm（2）-ls: 显示目录信息[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -ls /（3）-mkdir：在HDFS上创建目录[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -mkdir -p /sanguo/shuguo（4）-moveFromLocal：从本地剪切粘贴到HDFS[atguigu@hadoop102 hadoop-2.7.2]$ touch kongming.txt[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -moveFromLocal ./kongming.txt /sanguo/shuguo（5）-appendToFile：追加一个文件到已经存在的文件末尾[atguigu@hadoop102 hadoop-2.7.2]$ touch liubei.txt[atguigu@hadoop102 hadoop-2.7.2]$ vi liubei.txt输入san gu mao lu[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -appendToFile liubei.txt /sanguo/shuguo/kongming.txt（6）-cat：显示文件内容[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -cat /sanguo/shuguo/kongming.txt（7）-chgrp 、-chmod、-chown：Linux文件系统中的用法一样，修改文件所属权限[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -chmod 666 /sanguo/shuguo/kongming.txt[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -chown atguigu:atguigu /sanguo/shuguo/kongming.txt（8）-copyFromLocal：从本地文件系统中拷贝文件到HDFS路径去[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -copyFromLocal README.txt /（9）-copyToLocal：从HDFS拷贝到本地[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -copyToLocal /sanguo/shuguo/kongming.txt ./（10）-cp ：从HDFS的一个路径拷贝到HDFS的另一个路径[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -cp /sanguo/shuguo/kongming.txt /zhuge.txt（11）-mv：在HDFS目录中移动文件[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -mv /zhuge.txt /sanguo/shuguo/（12）-get：等同于copyToLocal，就是从HDFS下载文件到本地[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -get /sanguo/shuguo/kongming.txt ./（13）-getmerge：合并下载多个文件，比如HDFS的目录 /user/atguigu/test下有多个文件:log.1, log.2,log.3,...[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -getmerge /user/atguigu/test/* ./zaiyiqi.txt（14）-put：等同于copyFromLocal[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -put ./zaiyiqi.txt /user/atguigu/test/（15）-tail：显示一个文件的末尾[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -tail /sanguo/shuguo/kongming.txt（16）-rm：删除文件或文件夹[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -rm /user/atguigu/test/jinlian2.txt（17）-rmdir：删除空目录[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -mkdir /test[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -rmdir /test（18）-du统计文件夹的大小信息[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -du -s -h /user/atguigu/test2.7 K /user/atguigu/test[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -du -h /user/atguigu/test1.3 K /user/atguigu/test/README.txt15 /user/atguigu/test/jinlian.txt1.4 K /user/atguigu/test/zaiyiqi.txt（19）-setrep：设置HDFS中文件的副本数量[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -setrep 10 /sanguo/shuguo/kongming.txt
图3-3 HDFS副本数量这里设置的副本数只是记录在NameNode的元数据中，是否真的会有这么多副本，还得看DataNode的数量。因为目前只有3台设备，最多也就3个副本，只有节点数的增加到10台时，副本数才能达到10。
HDFS读写流程
HDFS写流程（上传文件）
1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
2）NameNode返回是否可以上传。
3）客户端请求第一个 Block上传到哪几个DataNode服务器上。
4）NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
6）dn1、dn2、dn3逐级应答客户端。
7）客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
8）当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）。
在HDFS写数据的过程中，NameNode会选择距离待上传数据最近距离的DataNode接收数据。那么这个最近距离怎么计算呢？
节点距离：两个节点到达最近的共同祖先的距离总和。
DN1是最近的，DN2和DN3是根据第一个节点DN1选出来的；
第二次的DN4、DN5、DN6可能跟第一次传输的DN一样，也可能不一样取决于内部集群的状况；两次返回的DN都是独立的。
N1与N2之间的距离为2；（找线条数）
假设N1、N2、N3三台机器，从N1上传数据，则最短的节点就是它本身0；
后两个的选择是根据机架感知来选：
HDFS读数据流程（下载）
1）客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。
2）挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。
3）DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。
4）客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。
NameNode和SecondaryNameNode
NN和2NN工作机制
思考NameNode存储在哪里？
如果将NameNode节点元数据存于磁盘中，因为需要经常进行随机访问，且还响应客户端的请求，效率低下。因此，要将元数据防于内存中，但是如果断电，内存中的数据就会丢失，集群无法工作了。因此在磁盘中备份元数据的FsImage。
但是这样会带来新的问题就是，在更新内存中的数据同时，还要同时更新FsImage，这样效率低下，因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。
但是如果长时间添加数据到Edits中，导致文件过大，如果某天断电，那么回复元数据时间很长，因此，需要定期合并FsImage和Edits文件，但是这个操作由NameNode节点完成，效率低下。因此引入新节点SecondaryNameNode，专门用于FsImage和Rdits定期合并。
NN和2NN工作机制如图所示：
Fsimage：NameNode内存中元数据序列化后形成的文件。包含HDFS文件系统的所有目录和文件inode的序列化信息；是HDFS文件系统元数据的永久性检查点；
Edits：记录客户端更新--增删改元数据信息的每一步操作。
NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。
1. 第一阶段：NameNode启动
（1）第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求。
（3）NameNode记录操作日志，更新滚动日志。
（4）NameNode在内存中对元数据进行增删改。
2. 第二阶段：Secondary NameNode工作
（1）Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
（2）Secondary NameNode请求执行CheckPoint。
（3）NameNode滚动正在写的Edits日志。
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint。
（7）拷贝fsimage.chkpoint到NameNode。
（8）NameNode将fsimage.chkpoint重新命名成fsimage。
NN和2NN工作的详解：
Fsimage：NameNode内存中元数据序列化后形成的文件。Edits：记录客户端更新元数据信息的每一步操作（可通过Edits运算出元数据）。NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询元数据的操作不会被记录在Edits中，因为查询操作不会更改元数据信息），如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息。然后，NameNode会在内存中执行元数据的增删改的操作。由于Edits中记录的操作会越来越多，Edits文件会越来越大，导致NameNode在启动加载Edits时会很慢，所以需要对Edits和Fsimage进行合并（所谓合并，就是将Edits和Fsimage加载到内存中，照着Edits中的操作一步步执行，最终形成新的Fsimage）。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。SecondaryNameNode首先会询问NameNode是否需要CheckPoint（触发CheckPoint需要满足两个条件中的任意一个，定时时间到和Edits中数据写满了）。直接带回NameNode是否检查结果。SecondaryNameNode执行CheckPoint操作，首先会让NameNode滚动Edits并生成一个空的edits.inprogress，滚动Edits的目的是给Edits打个标记，以后所有新的操作都写入edits.inprogress，其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地，然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint，然后将fsimage.chkpoint拷贝给NameNode，重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。
Fsimage和Edits解析
查看FsImage文件
[gll@hadoop101 current]$ ll总用量 7256-rw-rw-r--. 1 gll gll 1048576 1月 17 17:10 edits_0000000000000000001-0000000000000000001-rw-rw-r--. 1 gll gll 42 1月 18 11:08 edits_0000000000000000002-0000000000000000003-rw-rw-r--. 1 gll gll 1048576 1月 18 17:12 edits_0000000000000000004-0000000000000000020-rw-rw-r--. 1 gll gll 1048576 1月 18 18:27 edits_0000000000000000021-0000000000000000021-rw-rw-r--. 1 gll gll 42 1月 18 18:29 edits_0000000000000000022-0000000000000000023-rw-rw-r--. 1 gll gll 3869 1月 18 19:29 edits_0000000000000000024-0000000000000000074-rw-rw-r--. 1 gll gll 922 1月 18 20:29 edits_0000000000000000075-0000000000000000090-rw-rw-r--. 1 gll gll 1048576 1月 18 20:37 edits_0000000000000000091-0000000000000000107-rw-rw-r--. 1 gll gll 42 1月 19 11:28 edits_0000000000000000108-0000000000000000109-rw-rw-r--. 1 gll gll 42 1月 19 12:28 edits_0000000000000000110-0000000000000000111-rw-rw-r--. 1 gll gll 42 1月 19 13:28 edits_0000000000000000112-0000000000000000113-rw-rw-r--. 1 gll gll 1276 1月 19 14:28 edits_0000000000000000114-0000000000000000127-rw-rw-r--. 1 gll gll 42 1月 19 15:28 edits_0000000000000000128-0000000000000000129-rw-rw-r--. 1 gll gll 42 1月 19 16:28 edits_0000000000000000130-0000000000000000131-rw-rw-r--. 1 gll gll 1048576 1月 19 16:28 edits_0000000000000000132-0000000000000000132-rw-rw-r--. 1 gll gll 1048576 1月 19 20:45 edits_0000000000000000133-0000000000000000133-rw-rw-r--. 1 gll gll 14290 1月 20 12:24 edits_0000000000000000134-0000000000000000254-rw-rw-r--. 1 gll gll 42 1月 20 13:24 edits_0000000000000000255-0000000000000000256-rw-rw-r--. 1 gll gll 42 1月 20 14:24 edits_0000000000000000257-0000000000000000258-rw-rw-r--. 1 gll gll 1048576 1月 20 14:24 edits_inprogress_0000000000000000259-rw-rw-r--. 1 gll gll 2465 1月 20 13:24 fsimage_0000000000000000256-rw-rw-r--. 1 gll gll 62 1月 20 13:24 fsimage_0000000000000000256.md5-rw-rw-r--. 1 gll gll 2465 1月 20 14:24 fsimage_0000000000000000258-rw-rw-r--. 1 gll gll 62 1月 20 14:24 fsimage_0000000000000000258.md5-rw-rw-r--. 1 gll gll 4 1月 20 14:24 seen_txid-rw-rw-r--. 1 gll gll 206 1月 20 11:36 VERSION[gll@hadoop101 current]$ [gll@hadoop101 current]$ cat seen_txid //文件保存的是一个数字，就是最后一个edit_数字[gll@hadoop101 current]$ hdfs oiv -p XML -i fsimage_0000000000000000258 -o /opt/module/hadoop-2.7.2/fsimage.xml[gll@hadoop101 current]$ sz /opt/module/hadoop-2.7.2/fsimage.xml
CheckPoint时间设置
1）通常情况下，SecondaryNameNode每隔一小时执行一次。
2）一分钟检查一次操作次数；
3 ）当操作次数达到1百万时，SecondaryNameNode执行一次。
NameNode故障处理
方法一：将SecondaryNameNode中数据拷贝到NameNode存储数据的目录：但是这样处理，2nn的数据有部分没有合并，会不全，数据丢失。
1. kill -9 NameNode进程2. 删除NameNode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）[atguigu@hadoop102 hadoop-2.7.2]$ rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*3. 拷贝SecondaryNameNode中数据到原NameNode存储数据目录[atguigu@hadoop102 dfs]$ scp -r atguigu@hadoop104:/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/* ./name/4. 重新启动NameNode[atguigu@hadoop102 hadoop-2.7.2]$ sbin/hadoop-daemon.sh start namenode
方法二：使用-importCheckpoint选项启动NameNode守护进程，从而将SecondaryNameNode中数据拷贝到NameNode目录中。
1.修改hdfs-site.xml中的<property> <name>dfs.namenode.checkpoint.period</name> <value>120</value></property><property> <name>dfs.namenode.name.dir</name> <value>/opt/module/hadoop-2.7.2/data/tmp/dfs/name</value></property>2. kill -9 NameNode进程3. 删除NameNode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）[atguigu@hadoop102 hadoop-2.7.2]$ rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*4. 如果SecondaryNameNode不和NameNode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到NameNode存储数据的平级目录，并删除in_use.lock文件[atguigu@hadoop102 dfs]$ scp -r atguigu@hadoop104:/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary ./[atguigu@hadoop102 namesecondary]$ rm -rf in_use.lock[atguigu@hadoop102 dfs]$ pwd/opt/module/hadoop-2.7.2/data/tmp/dfs[atguigu@hadoop102 dfs]$ lsdata name namesecondary5. 导入检查点数据（等待一会ctrl+c结束掉）[atguigu@hadoop102 hadoop-2.7.2]$ bin/hdfs namenode -importCheckpoint6. 启动NameNode[atguigu@hadoop102 hadoop-2.7.2]$ sbin/hadoop-daemon.sh start namenode
集群安全模式
集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。（1）bin/hdfs dfsadmin -safemode get （功能描述：查看安全模式状态）（2）bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）（3）bin/hdfs dfsadmin -safemode leave （功能描述：离开安全模式状态）（4）bin/hdfs dfsadmin -safemode wait （功能描述：等待安全模式状态）
DataNode工作机制
1）一个数据块在DataNode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。
2）DataNode启动后向NameNode注册，通过后，周期性（1小时）的向NameNode上报所有的块信息。
3）心跳是每3秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用。
4）集群运行中可以安全加入和退出一些机器。
DataNode数据完整性
1）当DataNode读取Block的时候，它会计算CheckSum。
2）如果计算后的CheckSum，与Block创建时值不一样，说明Block已经损坏。
3）Client读取其他DataNode上的Block。
4）DataNode在其文件创建后周期验证CheckSum，如图3-16所示。
DataNode掉线时限参数设置
服役新数据节点
随着公司业务的增长，数据量越来越大，原有的数据节点的容量已经不能满足存储数据的需求，需要在原有集群基础上动态添加新的数据节点
1. 环境准备
（1）在hadoop104主机上再克隆一台hadoop105主机
（2）修改IP地址和主机名称
（3）删除原来HDFS文件系统留存的文件（/opt/module/hadoop-2.7.2/data和log）
（4）source一下配置文件
[atguigu@hadoop105 hadoop-2.7.2]$ source /etc/profile
2. 服役新节点具体步骤
（1）直接启动DataNode，即可关联到集群
[atguigu@hadoop105 hadoop-2.7.2]$ sbin/hadoop-daemon.sh start datanode
[atguigu@hadoop105 hadoop-2.7.2]$ sbin/yarn-daemon.sh start nodemanager
（2）在hadoop105上上传文件
[atguigu@hadoop105 hadoop-2.7.2]$ hadoop fs -put /opt/module/hadoop-2.7.2/LICENSE.txt /
（3）如果数据不均衡，可以用命令实现集群的再平衡
[atguigu@hadoop102 sbin]$ ./start-balancer.sh
starting balancer, logging to /opt/module/hadoop-2.7.2/logs/hadoop-atguigu-balancer-hadoop102.out
退役旧数据节点
添加白名单
添加到白名单的主机节点，都允许访问NameNode，不在白名单的主机节点，都会被退出。
配置白名单的具体步骤如下：
（1）在NameNode的/opt/module/hadoop-2.7.2/etc/hadoop目录下创建dfs.hosts文件 [atguigu@hadoop102 hadoop]$ pwd /opt/module/hadoop-2.7.2/etc/hadoop [atguigu@hadoop102 hadoop]$ touch dfs.hosts [atguigu@hadoop102 hadoop]$ vi dfs.hosts 添加如下主机名称（不添加hadoop105） hadoop102 hadoop103 hadoop104（2）在NameNode的hdfs-site.xml配置文件中增加dfs.hosts属性 <property> <name>dfs.hosts</name> <value>/opt/module/hadoop-2.7.2/etc/hadoop/dfs.hosts</value> </property>（3）配置文件分发 [atguigu@hadoop102 hadoop]$ xsync hdfs-site.xml（4）刷新NameNode [atguigu@hadoop102 hadoop-2.7.2]$ hdfs dfsadmin -refreshNodes Refresh nodes successful（5）更新ResourceManager节点 [atguigu@hadoop102 hadoop-2.7.2]$ yarn rmadmin -refreshNodes 17/06/24 14:17:11 INFO client.RMProxy: Connecting to ResourceManager at hadoop103/192.168.1.103:8033
黑名单退役
在黑名单上面的主机都会被强制退出
1.在NameNode的/opt/module/hadoop-2.7.2/etc/hadoop目录下创建dfs.hosts.exclude文件
[atguigu@hadoop102 hadoop]$ pwd/opt/module/hadoop-2.7.2/etc/hadoop[atguigu@hadoop102 hadoop]$ touch dfs.hosts.exclude[atguigu@hadoop102 hadoop]$ vi dfs.hosts.exclude添加如下主机名称（要退役的节点）hadoop105
2．在NameNode的hdfs-site.xml配置文件中增加dfs.hosts.exclude属性
<property><name>dfs.hosts.exclude</name> <value>/opt/module/hadoop-2.7.2/etc/hadoop/dfs.hosts.exclude</value></property>
3．刷新NameNode、刷新ResourceManager
[atguigu@hadoop102 hadoop-2.7.2]$ hdfs dfsadmin -refreshNodesRefresh nodes successful[atguigu@hadoop102 hadoop-2.7.2]$ yarn rmadmin -refreshNodes17/06/24 14:55:56 INFO client.RMProxy: Connecting to ResourceManager at hadoop103/192.168.1.103:8033
4. 检查Web浏览器，退役节点的状态为decommission in progress（退役中），说明数据节点正在复制块到其他节点，如图3-17所示
5.等待退役节点状态为decommissioned（所有块已经复制完成），停止该节点及节点资源管理器。注意：如果副本数是3，服役的节点小于等于3，是不能退役成功的，需要修改副本数后才能退役，如图3-18所示
[atguigu@hadoop105 hadoop-2.7.2]$ sbin/hadoop-daemon.sh stop datanodestopping datanode[atguigu@hadoop105 hadoop-2.7.2]$ sbin/yarn-daemon.sh stop nodemanagerstopping nodemanager
6. 如果数据不均衡，可以用命令实现集群的再平衡
[atguigu@hadoop102 hadoop-2.7.2]$ sbin/start-balancer.sh starting balancer, logging to /opt/module/hadoop-2.7.2/logs/hadoop-atguigu-balancer-hadoop102.outTime Stamp Iteration# Bytes Already Moved Bytes Left To Move Bytes Being Moved
注意：不允许白名单和黑名单中同时出现同一个主机名称。
DataNode多级目录配置
1. DataNode也可以配置成多个目录，每个目录存储的数据不一样。即：数据不是副本
2．具体配置如下
hdfs-site.xml<property> <name>dfs.datanode.data.dir</name><value>file:///${hadoop.tmp.dir}/dfs/data1,file:///${hadoop.tmp.dir}/dfs/data2</value></property>
HDFS2.x新特性
集群间数据拷贝
1．scp实现两个远程主机之间的文件复制 scp -r hello.txt root@hadoop103:/user/atguigu/hello.txt // 推 push scp -r root@hadoop103:/user/atguigu/hello.txt hello.txt // 拉 pull scp -r root@hadoop103:/user/atguigu/hello.txt root@hadoop104:/user/atguigu //是通过本地主机中转实现两个远程主机的文件复制；如果在两个远程主机之间ssh没有配置的情况下可以使用该方式。2．采用distcp命令实现两个Hadoop集群之间的递归数据复制[atguigu@hadoop102 hadoop-2.7.2]$ bin/hadoop distcphdfs://haoop102:9000/user/atguigu/hello.txt hdfs://hadoop103:9000/user/atguigu/hello.txt
小文件存档
案例实操
（1）需要启动YARN进程[atguigu@hadoop102 hadoop-2.7.2]$ start-yarn.sh（2）归档文件把/user/atguigu/input目录里面的所有文件归档成一个叫input.har的归档文件，并把归档后文件存储到/user/atguigu/output路径下。[atguigu@hadoop102 hadoop-2.7.2]$ bin/hadoop archive -archiveName input.har –p /user/atguigu/input /user/atguigu/output（3）查看归档[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -lsr /user/atguigu/output/input.har[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -lsr har:///user/atguigu/output/input.har（4）解归档文件[atguigu@hadoop102 hadoop-2.7.2]$ hadoop fs -cp har:/// user/atguigu/output/input.har/* /user/atguigu
HDFS HA高可用
HA概述
1）所谓HA(High Available),即高可用（7*24小时中段服务）
2）实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。
3）Hadoop2.0之前，在HDFS集群中NameNode存在单点故障（SPOF）。
4) NameNode主要在以下两个方面影响HDFS集群
- NameNode机器发生意外，如宕机，集群将无法使用，直到管理员重启
- NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用
HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。
HDFS-HA工作机制
通过双NameNode消除单点故障
HDFS-HA工作要点
1. 元数据管理方式需要改变
内存中各自保存一份元数据；
Edits日志只有Active状态的NameNode节点可以做写操作；
两个NameNode都可以读取Edits；
共享的Edits放在一个共享存储中管理（qjournal和NFS两个主流实现）；
2. 需要一个状态管理功能模块
实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生。
3. 必须保证两个NameNode之间能够ssh无密码登录
4. 隔离（Fence），即同一时刻仅仅有一个NameNode对外提供服务
HDFS-HA自动故障转移机制
故障转移增加了zookeeper和ZKFS进程
Zookeeper：维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务
HA依赖zookeeper的一下功能：
1）故障检测：集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。
2）现役NameNode选择：ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。
ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：
1）健康监测：ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。
2）ZooKeeper会话管理：当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对短暂节点的支持，如果会话终止，锁节点将自动删除。
3）基于ZooKeeper的选择：如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地NameNode为Active。故障转移进程与前面描述的手动故障转移相似，首先如果必要保护之前的现役NameNode，然后本地NameNode转换为Active状态。
ZKFC:是zookeeper的客户端，让它联系zookeeper，HA是hadoop2.0才有的，namenode在1.0时就有了，但是为了保持NameNode的健壮性，未把ZKFC加入NameNode中，但是两个进程是相互绑定的，有ZKFC监视NameNode，
将状态汇报给zookeeper。
主Namenode处理所有的操作请求（读写），而Standby只是作为slave，维护尽可能同步的状态，使得故障时能够快速切换到Standby。为了使Standby Namenode与Active Namenode数据保持同步，两个Namenode都与一组Journal Node进行通信。当主Namenode进行任务的namespace操作时，都会确保持久会修改日志到Journal Node节点中的大部分。Standby Namenode持续监控这些edit，当监测到变化时，将这些修改应用到自己的namespace
当进行故障转移时，Standby在成为Active Namenode之前，会确保自己已经读取了Journal Node中的所有edit日志，从而保持数据状态与故障发生前一致。
脑裂现象（split brain）: 当两台Namenode都认为自己的Active Namenode时，会同时尝试写入数据（不会再去检测和同步数据）：zookeeper会根据自身通知机制，确认主机，防止脑裂。
如果一台出现了假死，当前NameNode监控的ZKFX检测到假死，会通知从机的ZKFC，从而杀死假死的NameNode的进程，激活从机为Active，同时通知zookeeper服务端将从机注册为Active。
现在合并fsimage是由standby来完成的，没有secondaryNameNode；
Journal Nodes为了防止脑裂，只让一个Namenode写入数据，内部通过维护epoch数来控制，从而安全地进行故障转移，有两种方式共享edits log：
- 使用NFS共享edit log（存储在NAS/SAN）
如图所示，NFS作为主备Namenode的共享存储。这种方案可能会出现脑裂（split-brain），即两个节点都认为自己是主Namenode并尝试向edit log写入数据，这可能会导致数据损坏。通过配置fencin脚本来解决这个问题，fencing脚本用于：
将之前的Namenode关机
禁止之前的Namenode继续访问共享的edit log文件
使用这种方案，管理员就可以手工触发Namenode切换，然后进行升级维护。但这种方式存在以下问题：
- 只能手动进行故障转移，每次故障都要求管理员采取措施切换。
- NAS/SAN设置部署复杂，容易出错，且NAS本身是单点故障。
- Fencing 很复杂，经常会配置错误。
- 无法解决意外（unplanned）事故，如硬件或者软件故障。
因此需要另一种方式来处理这些问题：
- 自动故障转移（引入ZooKeeper达到自动化）
- 移除对外界软件硬件的依赖（NAS/SAN）
- 同时解决意外事故及日常维护导致的不可用
- 使用QJM共享edit log：Quorum-based 存储 + ZooKeeper
QJM（Quorum Journal Manager）是Hadoop专门为Namenode共享存储开发的组件。其集群运行一组Journal Node，每个Journal 节点暴露一个简单的RPC接口，允许Namenode读取和写入数据，数据存放在Journal节点的本地磁盘。当Namenode写入edit log时，它向集群的所有Journal Node发送写入请求，当多数节点回复确认成功写入之后，edit log就认为是成功写入。例如有3个Journal Node，Namenode如果收到来自2个节点的确认消息，则认为写入成功。
而在故障自动转移的处理上，引入了监控Namenode状态的ZookeeperFailController（ZKFC）。ZKFC一般运行在Namenode的宿主机器上，与Zookeeper集群协作完成故障的自动转移。整个集群架构图如下：
Namenode使用QJM 客户端提供的RPC接口与Namenode进行交互。写入edit log时采用基于仲裁的方式，即数据必须写入JournalNode集群的大部分节点。
在Journal Node节点上（服务端）
服务端Journal运行轻量级的守护进程，暴露RPC接口供客户端调用。实际的edit log数据保存在Journal Node本地磁盘，该路径在配置中使用dfs.journalnode.edits.dir属性指定。
Journal Node通过epoch数来解决脑裂的问题，称为JournalNode fencing。具体工作原理如下：
1）当Namenode变成Active状态时，被分配一个整型的epoch数，这个epoch数是独一无二的，并且比之前所有Namenode持有的epoch number都高。
2）当Namenode向Journal Node发送消息的时候，同时也带上了epoch。当Journal Node收到消息时，将收到的epoch数与存储在本地的promised epoch比较，如果收到的epoch比自己的大，则使用收到的epoch更新自己本地的epoch数。如果收到的比本地的epoch小，则拒绝请求。
3）edit log必须写入大部分节点才算成功，也就是其epoch要比大多数节点的epoch高。
这种方式解决了NFS方式的3个问题：
不需要额外的硬件，使用原有的物理机
Fencing通过epoch数来控制，避免出错。
自动故障转移：Zookeeper处理该问题。
HDFS-HA故障转移参考：https://blog.csdn.net/qq_36933797/article/details/78826713
HDFS-HA集群配置
环境准备
1. 修改IP
2. 修改主机名及主机名和IP地址的映射
3. 关闭防火墙
4. ssh免密登录
5. 安装JDK，配置环境变量等
规划集群
|
hadoop102 |
hadoop103 |
hadoop104 |
|
NameNode |
NameNode |
|
|
JournalNode |
JournalNode |
JournalNode |
|
DataNode |
DataNode |
DataNode |
|
ZK |
ZK |
ZK |
|
ResourceManager |
||
|
NodeManager |
NodeManager |
NodeManager |
配置HDFS-HA集群
在opt目录下创建一个ha文件夹mkdir ha将/opt/app/下的 hadoop-2.7.2拷贝到/opt/ha目录下cp -r hadoop-2.7.2/ /opt/ha/配置hadoop-env.shexport JAVA_HOME=/opt/module/jdk1.8.0_144
配置core-site.xml
<configuration><!-- 把两个NameNode）的地址组装成一个集群mycluster --> <property> <name>fs.defaultFS</name> <value>hdfs://mycluster</value> </property> <!-- 指定hadoop运行时产生文件的存储目录 --> <property> <name>hadoop.tmp.dir</name> <value>/opt/ha/hadoop-2.7.2/data/tmp</value> </property></configuration>
配置hdfs-site.xml
<configuration> <!-- 完全分布式集群名称 --> <property> <name>dfs.nameservices</name> <value>mycluster</value> </property> <!-- 集群中NameNode节点都有哪些 --> <property> <name>dfs.ha.namenodes.mycluster</name> <value>nn1,nn2</value> </property> <!-- nn1的RPC通信地址 --> <property> <name>dfs.namenode.rpc-address.mycluster.nn1</name> <value>hadoop102:9000</value> </property> <!-- nn2的RPC通信地址 --> <property> <name>dfs.namenode.rpc-address.mycluster.nn2</name> <value>hadoop103:9000</value> </property> <!-- nn1的http通信地址 --> <property> <name>dfs.namenode.http-address.mycluster.nn1</name> <value>hadoop102:50070</value> </property> <!-- nn2的http通信地址 --> <property> <name>dfs.namenode.http-address.mycluster.nn2</name> <value>hadoop103:50070</value> </property> <!-- 指定NameNode元数据在JournalNode上的存放位置 --> <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://hadoop102:8485;hadoop103:8485;hadoop104:8485/mycluster</value> </property> <!-- 配置隔离机制，即同一时刻只能有一台服务器对外响应 --> <property> <name>dfs.ha.fencing.methods</name> <value>sshfence</value> </property> <!-- 使用隔离机制时需要ssh无秘钥登录--> <property> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/home/atguigu/.ssh/id_rsa</value> </property> <!-- 声明journalnode服务器存储目录--> <property> <name>dfs.journalnode.edits.dir</name> <value>/opt/ha/hadoop-2.7.2/data/jn</value> </property> <!-- 关闭权限检查--> <property> <name>dfs.permissions.enable</name> <value>false</value> </property> <!-- 访问代理类：client，mycluster，active配置失败自动切换实现方式--> <property> <name>dfs.client.failover.proxy.provider.mycluster</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property></configuration>
拷贝配置好的hadoop环境到其他节点
启动HDFS-HA集群
1. 在各个JournalNode节点上，输入以下命令启动journalnode服务 sbin/hadoop-daemon.sh start journalnode2. 在[nn1]上，对其进行格式化，并启动 bin/hdfs namenode -format sbin/hadoop-daemon.sh start namenode3. 在[nn2]上，同步nn1的元数据信息 bin/hdfs namenode -bootstrapStandby4. 启动[nn2] sbin/hadoop-daemon.sh start namenode5. 在[nn1]上，启动所有datanode sbin/hadoop-daemons.sh start datanode6. 将[nn1]切换为Active bin/hdfs haadmin -transitionToActive nn17. 查看是否Active bin/hdfs haadmin -getServiceState nn1
配置HDFS-HA自动故障转移
1. 具体配置
（1）在hdfs-site.xml中增加
<property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value></property>
（2）在core-site.xml文件中增加
<property> <name>ha.zookeeper.quorum</name> <value>hadoop102:2181,hadoop103:2181,hadoop104:2181</value></property>
2. 启动
（1）关闭所有HDFS服务： sbin/stop-dfs.sh（2）启动Zookeeper集群： bin/zkServer.sh start（3）初始化HA在Zookeeper中状态： bin/hdfs zkfc -formatZK（4）启动HDFS服务： sbin/start-dfs.sh
3.验证
（1）将Active NameNode进程kill kill -9 namenode的进程id（2）将Active NameNode机器断开网络 service network stop
YARN-HA配置
YARN-HA工作机制，如图3-23所示：
具体配置
（1）yarn-site.xml
<configuration> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <!--启用resourcemanager ha--> <property> <name>yarn.resourcemanager.ha.enabled</name> <value>true</value> </property> <!--声明两台resourcemanager的地址--> <property> <name>yarn.resourcemanager.cluster-id</name> <value>cluster-yarn1</value> </property> <property> <name>yarn.resourcemanager.ha.rm-ids</name> <value>rm1,rm2</value> </property> <property> <name>yarn.resourcemanager.hostname.rm1</name> <value>hadoop102</value> </property> <property> <name>yarn.resourcemanager.hostname.rm2</name> <value>hadoop103</value> </property> <!--指定zookeeper集群的地址--> <property> <name>yarn.resourcemanager.zk-address</name> <value>hadoop102:2181,hadoop103:2181,hadoop104:2181</value> </property> <!--启用自动恢复--> <property> <name>yarn.resourcemanager.recovery.enabled</name> <value>true</value> </property> <!--指定resourcemanager的状态信息存储在zookeeper集群--> <property> <name>yarn.resourcemanager.store.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value></property></configuration>
启动hdfs
（1）在各个JournalNode节点上，输入以下命令启动journalnode服务：sbin/hadoop-daemon.sh start journalnode（2）在[nn1]上，对其进行格式化，并启动：bin/hdfs namenode -formatsbin/hadoop-daemon.sh start namenode（3）在[nn2]上，同步nn1的元数据信息：bin/hdfs namenode -bootstrapStandby（4）启动[nn2]：sbin/hadoop-daemon.sh start namenode（5）启动所有DataNodesbin/hadoop-daemons.sh start datanode（6）将[nn1]切换为Activebin/hdfs haadmin -transitionToActive nn1
启动YARN
（1）在hadoop102中执行：sbin/start-yarn.sh（2）在hadoop103中执行：sbin/yarn-daemon.sh start resourcemanager（3）查看服务状态，如图3-24所示bin/yarn rmadmin -getServiceState rm1