Hdfs四大机制
一、心跳机制：
hdfs集群中namenode负责管理所有的datanode，namenode如何管理？
怎么获取datanode存活状态的？
通过心跳策略获取的
Datanode在集群运行的过程中会定期的向namenode发送自己的心跳报告，目的报告namenode自己的存活状态
心跳报告的周期：hdfs-default.xml
datanode每隔3s向namenode发送一个心跳报告
如果一个datanode宕机了，namenode通过多长时间可以断定？
Namenode连续10次接收不到datanode的心跳报告的时候，会认为当前的datanode可能宕机
这个时候namenode主动向datanode发送检查(后台守护进程)等待检查的相应结果
Namenode进行datanode的一次检查的时间300000ms=300=5min
Namenode会主动检查两次
如果两次检查都没有相应，这时就断定当前的datanode宕机了
所以namenode断定一个datanode宕机的时间：
10*3+2*5min=10min30s
二、机架策略：
在hdfs（2.0版本重）中对于一个block默认的存储副本个数是3个，这3个副本如何存放？
3个副本存储在3个不同的节点上
事实上在实际生产的时候，节点在机架上，所以我们在存放副本的时候要考虑机架的问题
副本存放策略：
- 第一个副本通常放在客户端所在节点(客户端是集群中的一个节点)
如果客户端不是集群中的一个节点，则第一个副本上传到任意一个节定
- 第二个副本放在和第一个副本不同机架的任意节点上
- 第三个副本放在和第二个副本相同机架的不同节点上---便于写数据
实际生产中：
副本存放有可能跨界点 跨机架 跨机房 跨数据中心--都是为了高可靠性
三、负载均衡：
hdfs集群中的每一个datanode上的存储的数据和自己的硬件占比是相当的
这个时候我们可以认为这个hdfs集群是负载均衡的。
集群的运行过程中，会有可能造成集群中的从节点的负载不均衡
如果集群规模比较小的时候，集群有自动负载均衡的能力，集群的会自己在一段时间之后达到相对的负载均衡。
集群实现负载均衡的过程实际上就是数据块移动的过程(跨节点)
默认集群负载均衡的带宽在我们的配置文件中是1048576(1M/s) 很慢的
这个速度针对集群规模比较小的时候可以的，但是集群规模比较大的时候就不可以了太慢了
集群规模大的时候:手动负载均衡
Start-balancer.sh 这个命令不会立即执行 提升负载均衡的相应时效
Start-balancer.sh -t 10% 参数的意义：datanode中最大的存储容量占比和最小的存储的容量占比不超过10%，此时认为负载均衡
例：节点1 2T 存1T 50%
Hdp02 2T 存1.1T 55%
Hdp03 2T 存0.9T 45%
其中最大占比和最小占比相差10%刚好达到他给的值的范围内，就认为是负载均衡
安全模式：
集群的安全模式是集群的一种自我保护的模式，在集群的安全模式下不允许用户对集群进行部分操作的。
集群什么时候会进入安全模式？
1.集群启动的时候，集群会自己进入安全模式
集群启动过程中做的事情？
首先了解集群启动顺序：
Namenode->datanode->secondarynamenode
启动namenode的时候做的事情：
Namenode主要作用：存储元数据
元数据：抽象目录树+数据和块的映射+数据块和节点映射
一 二 三
硬盘上的存储中的元数据不包括：三
内存中
集群正常启动之后 读取的元数据信息都是内存中的
包括所有的：一二三
集群在启动namenode的时候:
将硬盘中的元数据加载到内存中。
启动datanode:
启动datanode的进程
启动完成向namenode进行发送心跳报告
Datanode在发送心跳报告的时候也会发送块报告，namenode接收到这个块报告信息就会将相应的块id的节点放在元数据的相应位置
启动secondarynamenode：
集群在整个启动过程中处于安全模式的，进行一系列的检查，符合标准的时候，才会离开安全模式：
标准：
- 检查每一个数据块的副本个数，每一个数据块的副本个数至少为1
- 检查合乎标准的数据块占总数据块的比例
集群启动过程中，为什么进入安全模式：
Namenode将硬盘中的元数据加载到内存中
Namenode接受datanode的心跳报告
Namenode接受datanode的块报告
Namenode会进行一系列的检查
基于以上的原因，集群会进入安全模式，上面的事情都完成的情况下，集群会自动退出安全模式。
2.集群在运行过程中，也会进行检查
检查的时候发现不符合要求了，也会自动进入安全模式
3.手动进入安全模式
如果集群出于维护或者是系统升级的时候，也可以手动进入安全模式：
命令：
Hdfs dfsadmin -safemode get:获取安全模式的状态
结果有两种：safe mode is OFF
safe mode is ON
Hdfs dfsadmin -safemode leave:强制离开安全模式
Hdfs dfsadmin -safemode enter:强制进入安全模式
4.在安全模式下，可以执行的操作和不可以执行的操作
可以执行的操作：
ls
get
cat
tail
不可以执行的操作：
put
mkdir
touchz
appendToFIle
rm
总结：所有的查询都是可以进行的，但是增删改是不可以的；只要不修改元数据信息的操作都可以。
安全模式归根结底就是自我保护(自身数据的模式)，在该模式下不允许用户修改任何数据的元数据信息，只能查询元数据。
Hdfs两大核心
文件上传：hdfs写数据
客户端执行文件上传的命令步骤：
1.客户端发送文件上传的请求给namenode
2.namenode会进行一系列的检查
a.文件是否存在
b.父目录是否存在
c.权限问题
3.检查通过，namenode向客户端返回响应
4.客户端开始发送真正的文件上传的请求，请求中包含了一个重要的内容:文件长度(决定分块个数->存储节点个数)
5.namenode就开始进行计算，并向datanode每一个数据端返回数据块存储的节点以及数据块的ID。例：200M/128=2；副本设置为2；然后记录每个副本对应的存储节点
6.客户端准备上传
7.客户端先对数据进行逻辑分块
物理分块：
真实存在的切分，数据被真正的分成了多个块(多个部分)
Hdfs数据的分块存储
逻辑分块：
逻辑上的概念，相当于一个区域、范围的划分；并没有对数据进行真正的切分，只是为物理切块做准备。
8.客户端准备上传第一个数据块
9.客户端开始构建第一个数据块的管道(pipline)
此时客户端开启一个后台进程，等待pipline构建完成的响应
10.客户端开始文件上传
上传时以packet为单位进行数据写入，一个packet大小为64kb，即每次读64kb然后写一次。
写数据过程：
客户端--->第一个副本--->第二个副本--->先写入内存
然后内存--->磁盘
11.第一个数据块上传完成，关闭当前的pipline
12.开始准备上传第二个数据块
步骤同8-9-10
13.所有的数据上传完成，客户端向namenode发送响应，namenode修改元数据信息
文件上传中注意的问题：
1）文件上传过程中的物理切块问题：
边上传边切分的过程
文件切块客户端负责的
2）pipline构建的问题
客户端--->第一个副本--->第二个副本--->第三个副本
Client--->hdp01--->hdp02--->hdp03--->hdp04...
如果在传输过程中发现pipline中的某一个节点有问题，hdp03有问题，尝试重试2次，若2次通信都有问题，则将hdp03剔除出pipline，重新构建pipline
Client--->hdp01--->hdp02--->hdp04
3）上传过程中的最低保障：
每一个数据块至少有一个数据块副本上传成功就认为成功
副本存放策略第一个副本优先放置在客户端所在节点就是为了保证数据上传的成功率
第一个副本放在客户端所在节点就相当于本地复制
将数据从本地的原始路径复制到/home/hdp/data/hadoopdata/data/...
其他副本自己进行异步复制(datanode之间)
文件下载：读hdfs数据
客户端执行文件下载的命令步骤：
1.客户端向namnode发送文件下载的请求
2.namenode也会进行一系列的检查，检查通过则向客户端返回相应的数据对应的块及数据块的存储节点。
3.客户端开始进行第一个数据块的下载
到对应的节点上下载第一个数据块
4.第一个数据块下载完成，开始下载第二个数据块
从datanode上读取并写出到本地文件中，该过程是追加写入第一个数据块的末尾
5.所有的数据块下载完成
文件下载完成，关闭对应的资源
节点分配问题：
文件上传：
几个副本则返回这个数据块的几个存储节点
返回节点的时候有优先级的问题：
1.优先返回客户端所在节点
2.返回同机架节点
3.不同机架的节点
文件下载：
返回节点：客户端所在存储数据块副本节点，返回同机架，不同机架不同节点
文件下载异常：
第一个数据的副本下载失败，则重试，若仍不成功，则换另一个副本的节点继续下载；
同时客户端将这个节点报告给namenode。
注意：
文件下载的时候，每一个数据块读取完成都会进行crc文件校验
Hdfs元数据合并
元数据存储分为两个部分：硬盘（安全）上面一份，内存（效率）中一份
但是如果元数据再写到硬盘过程中断电了怎么办？
此时涉及到一个安全机制：WAL(Write Ahead Log)
即操作预写机制，在操作前先记录操作，如果操作失败，重连之后再恢复数据，即WAL的安全机制功能。
硬盘上存储元数据的文件结构：序列化文件
（1）Edits_00000000000001-0000000000000000000002
元数据的操作日志文件
元数据操作的流水日记
记录的就是元数据的所有操作：仅仅是操作记录
历史日志文件
（2）Edits_inprogress_000000000000000235
正在编辑的日志文件
默认情况下edits文件1h回滚一次
（3）fsimage_00000000000000000000225/Fsimage_00000000000000000000225.md5
元数据内容文件 序列化的文件
这个元数据文件：1.抽象目录树2.数据和数据块的映射
但并不是全部的元数据信息，只是部分的元数据信息
.md5表示加密文件—校验
- seen_txid
合并点文件
下一次需要滚动的日志文件的起始编号
- VERSION
元数据的版本信息文件
集群id：标识整个集群
块池id:标识块的存储的
硬盘上的完整的元数据包括：
Fsimagine文件的最后的编号和eidts文件的编号有一个对应关系
完整的元数据文件:
Fsimage237+
Edits239+
Edits240
Fsimage239+
Edits240
Fsimage文件的产生：
Namenode进行格式化的时候会产生一个初始的fsimage文件
后面的fsimage.new文件是原来fsimage.nold文件+edits文件合并得来的。
(fsimage.old_id+1~fsimage.new_id)
例如：
Fsimage239=Fsimage237+edits238-239
Fsimage和edits文件的合并是谁做的？
Secondarynamenode
元数据合并的过程：checkpoint
元数据合并触发的条件：
- 时间间隔：每个1小时会进行一次元数据合并的工作
- 日志条数间隔：达到100w条日志就进行元数据合并，不管达到1小时
上面的两个条件只要满足任意一个条件就会触发源数据合并
注：内存中的元数据时刻都是最新的最全的元数据
元数据合并的具体步骤：
secondarynamenode定期询问namenode是否需要进行元数据合并------->
Namenode达到元数据合并的条件，就会通知snn------------------------------->
Snn向namenode发送元数据合并的请求------------------------------------------->
Namenode先将正在编辑的日志文件进行回滚，同时生成一个新的正在编辑的日志文件----------------->snn将edits文件和fsimamge文件拉去到自己的本地--------------------->
Snn将edits文件和fsimage文件加载到内存中进行合并，一旦合并完成就会生成一个新 的fsimage文件--------------------------->snn将合并完成的fsimage文件发送给namenode。
Edits文件的作用：
- 记录元数据的操作日志信息
- 帮助进行元数据fsimage文件恢复
合并：fsimage文件通过edits文件的记录的操作修改自己的内容
Hdfs的各个角色：
Namenode：
- 接受客户端的读写请求
- 存储元数据信息
- 接受datanode的心跳报告
- 负载均衡
- 分配数据块的存储节点
....
Datanode:
- 真正处理客户端的读写请求
- 向namenode发送心跳报告
- 向namenode发送块报告
- 真正的数据存储
- 副本之间的相互复制
Secondarynamenode：
- 备份元数据信息
- 帮助namenode进行元数据合并，减轻namenode的压力
客户端：
- 进行数据块的物理切分
- 向namenode发送读写请求
- 向namenode发送读写(读写是否成功)响应报告(之后namenode才好修改元数据)