hdfs的四大机制和两大核心

HDFS的四大机制：

1.心跳机制
在hdfs的整个运行过程中，需要datanode定时向namenode发送心跳报告，namenode可以通过心跳报告确定datanode是可以正常工作的
发送心跳报告的作用：
1）报告自己的存活情况
2）报告自己的块的信息
心跳报告周期 ： 3s 不能太长，也不能太短
可以通过hdfs-deault.xml来进行设置

<property>
   <name>dfs.heartbeat.interval</name>
   <value>3</value>
   <description>Determines datanode heartbeat interval in seconds.</description>
</property>

问题：
每隔3s datanode会向namenode发送一个心跳报告，namenode如何判断一个datanode宕机了？
首先，在连续10次心跳报告接受不到 （就是连续30秒接受不到datanode的心跳） 认为datanode可能宕机了（不能判定宕机）
namenode会主动的向datanode发送检查：
30000ms=300s=5min

<property>
   <name>dfs.namenode.heartbeat.recheck-interval</name>
   <value>300000</value>
   <description>
     This time decides the interval to check for expired datanodes.
     With this value and dfs.heartbeat.interval, the interval of
     deciding the datanode is stale or not is also calculated.
     The unit of this configuration is millisecond.
   </description>
</property>

默认情况下 检查2次 10min 断定datanode宕机了
判断datanode宕机的时间为：
103s+25min=630s

2.安全模式
集群启动顺序：
namenode----->datanode----->secondarynamenode
集群启动的过程中namenode做的事情：
1）将硬盘中的元数据加载到内存中
2）接受datanode的心跳报告 1）判断datanode的存活率 2）加载块的存储节点信息
这个过程中namenode处于安全模式的 集群也是处于安全模式的—集群的一个自我保护的模式
集群处于安全模式的时候不对外提供服务的 不对外提供写服务 对外提供读的服务
集群启动过程中自动离开安全模式的依据：
1）datanode节点的启动的个数：默认0

<property>
  <name>dfs.namenode.safemode.min.datanodes</name>
  <value>0</value>
  <description>
Specifies the number of datanodes that must be considered alive
before the name node exits safemode.
Values less than or equal to 0 mean not to take the number of live
datanodes into account when deciding whether to remain in safe mode
during startup.
Values greater than the number of datanodes in the cluster
will make safe mode permanent.
  </description>
</property>

默认情况下 集群中的datanode节点启动0个也可以离开安全模式
2）数据块（排除副本）的汇报情况
集群处于安全模式的时候 每一个数据块的副本最小保证个数 默认1个

<property>
  <name>dfs.namenode.replication.min</name>
  <value>1</value>
  <description>Minimal block replication.
  </description>
</property>

所有数据块的存活率（不考虑副本的）
假设集群中 10000个数据块 至少0.999*10000=9990个数据块正常的才能离开安全模式
如果数据块少于这个数 这个时候集群一直处于安全模式

<property>
  <name>dfs.namenode.safemode.threshold-pct</name>
  <value>0.999f</value>
  <description>
Specifies the percentage of blocks that should satisfy
the minimal replication requirement defined by dfs.namenode.replication.min.
Values less than or equal to 0 mean not to wait for any particular
percentage of blocks before exiting safemode.
Values greater than 1 will make safe mode permanent.
  </description>
</property>

手动进入和离开安全模式的命令：
hdfs dfsadmin -safemode enter/leave/get/wait
enter 进入安全模式
leave 离开安全模式
get 获取安全模式的状态
wait 等待离开安全模式

集群处于安全模式 哪些事情可以做？哪些事情不可以做？
1）读操作 不可修改元数据的操作
hadoop fs -ls / 可以
hadoop fs -cat / 可以
hadoop fs -tail / 可以
hadoop fs -get / /
不修改元数据的操作都可以进行
2）写的操作 修改元数据信息
hadoop fs -mkdir /
hadoop fs -put / /
hadoop fs -rm -r -f /
需要修改元数据的操作 都不可以进行的

3、机架策略
默认2个机架的时候 3个副本的情况下
机架：存放服务器的
1）第一个副本存放在客户端所在节点（客户端是集群中的某一个节点）
如果客户端不是集群中的某一个节点 任意存储
2）第二个副本存储在与第一个副本不同机架的任意节点上
3）第三个副本存储在与第二个副本相同机架的不同节点上

4、负载均衡
hdfs来说 负载均衡指的是每一个datanode节点上存储的数据和他的硬件匹配 实际上说的是占有率相当的
集群如果没有处于负载均衡的时候 集群会自动进行负载均衡的
进行负载均衡的过程 说白了就是数据块的移动的过程 肯定跨节点 跨机架 需要网络传输
下面的参数 集群自动进行负载均衡的带宽 很慢 默认1M/s

<property>
  <name>dfs.datanode.balance.bandwidthPerSec</name>
  <value>1048576</value>
  <description>
Specifies the maximum amount of bandwidth that each datanode
can utilize for the balancing purpose in term of
the number of bytes per second.
  </description>
</property>

集群规模的比较小的情况下 20个节点以下 自动进行负载均衡就可以了
集群的规模比较大的时候：1000个节点
自动进行负载均衡 太慢了
这个手动进行负载均衡
1）修改负载均衡的带宽 加大

<property>
  <name>dfs.datanode.balance.bandwidthPerSec</name>
  <value>104857600000</value>
  <description>
Specifies the maximum amount of bandwidth that each datanode
can utilize for the balancing purpose in term of
the number of bytes per second.
  </description>
</property>

2）告诉集群及时进行负载均衡
start-balancer.sh -t 10%
不存在绝对的负载均衡
-t 10% 最大的节点的占有百分比 和最小节点占有的百分比差值 不能超过10% 指定的是负载均衡的评价标准
这个命令 提交的时候不会立即执行 类似于java中的垃圾回收
集群空闲的时候进行负载均衡 提升集群负载均衡的效率的

2、HDFS的两大核心

1、文件上传 就是写数据的过程
1）流程

1. 客户端向namenode发送文件上传的请求

2. namenode进行一系列的检查 权限 父目录 文件是否已经存在

3. namenode检查通过 会向客户端响应

4. 客户端会向namenode发送文件上传的真正的请求 这个请求中包含、文件的长度、文件的大小

5. namenode会根据客户端发送的请求中的文件的长度 计算数据块的个数，并获取集群中的副本的配置信息
   给客户端返回当前数据每一个数据块

   需要存放的节点 hadoop.wmv 204m blk01:[hadoop01,hadoop03,hadoop04]
   blk02:[hadoop01,hadoop02,hadoop04]

6. 客户端开始准备文件上传

7. 客户端进行逻辑切块 仅仅是一个偏移量的范围划分

8. 客户端开始准备上传第一个数据块 开启一个后台的阻塞进程 这个进程作用：等待数据块上传完成一个报告

9. 构建第一个数据块的pipline

10. 开始进行数据块上传

11. 第一个数据块上传成功 关闭当前的pipline

12. 开始上传第二个数据块 重复9,10,11

13. 所有的数据块上传成功 客户端给namenode反馈namenode开始修改元数据信息

2）流程图解

3）文件上传的问题：
1.构建pipline的过程中 blk01:client----datanode01----datanode03—datanode04
pipline中的某一个节点宕机了 假设datanode03宕机了
datanode01会立即重试一次 还失败 将这个节点剔除pipline 重新构建pipline
blk01:client-----datanode01-----datanode04
至少保证整个pipline中有一个存活的节点就可以
2.进行整个文件的上传的过程中 只需要保证至少一个副本上传成功就认为整个数据块上传成功
其他副本集群中自行异步复制
3.进行文件上传的过程中 优先第一个副本的节点 是客户端所在的节点
原因：保证副本最大程度的可以成功上传一个
相当于本地的复制的工作 不需要网络传输

2、元数据合并
元数据的目录结构：
1）edits * 历史日志文件 一个小时滚动一次
2）edits_inprogress 正在编辑的日志文件
3）fsimage 元数据的镜像文件
4）seen_txid 合并点
fsimage_0000000000000000043 9:04
fsimage_0000000000000000078 10:04 最新合并的元数据文件
fsimage_0000000000000000078====fsimage_0000000000000000043+edits文件合并
合并完成之后 fsimage文件的命名：fsimage_0000000000000000078 以最后一个edits文件的id进行命名的
命名完成之后 存在namenode的元数据中 为了避免元数据丢失
原来的镜像文件fsimage_0000000000000000043不会立即删除 下一个镜像文件合并完成的时候
前前一个镜像文件才会被删除。

元数据合并的过程：
1）snn会向namenode发送元数据是否合并的检查 1min检查一次
2）namenode需要元数据合并 会向snn进行响应
3）snn向namenode发送元数据合并的 请求
4）namenode将正在编辑的元数据的日志文件进行回滚 变成一个历史日志文件，同时会生成一个新的正在编辑的日志文件
5）snn将fsimage文件和edits文件拉取到snn的本地
6）snn将上面的文件加载到内存中进行合并 根据edits的操作日志修改fsimage文件
7）合并完成，将合并完成的文件发送给namenode，重命名，生成最新的fsiamge文件 本地也会保存一个
流程图：