Hadoop HDFS
一、概述
1.HDFS 是用于进行分布式存储的组件
2.根据Google的论文设计实现的
HDFS 特点：
(1)好处
1.能够存储超大文件 - 切块block
2.快速的应对和检测故障 - NameNode和DataNode之间的心跳检测
3.保证数据的高可用 - 副本备份
4.简易的一致性模型 - 一次写入多次读取，在Hadoop2.0开始，允许追加
5.能够利用低廉的设备来进行横向扩展
存储：纵向 - 在数量不变的前提下提供性能 性能和价钱--指数型
横向 - 可以增加数量 性能和价钱 - 线性型
(2)不建议
1.不建议存储大量小文件 - 因为每一个小文件会产生一个元数据，而元数据存在内存中和fsimage，而在内存中存储的数据有限
2.不支持低延迟访问 - 由于数据量很大
3.不支持事务
二、技术架构
(1)概述
1、在HDFS中，存在两类主要的节点：NameNode和DataNode
2、NameNode负责管理DataNode，DataNode负责存储数据
3、在存储数据的时候会将数据进行切块
4、为了防止产生数据丢失，会将数据进行备份，备份称之为副本 - replication(hdfs-site.xml文件)。
在Hadoop中默认副本数量为3，备份2次加上原来的数据共3个，伪分布式情况下值为1
(2)Block
1、在存储数据的时候，会将数据进行切块，每一块称之为是一个Block
2、Block是HDFS的基本存储单位
3、在Hadoop2.0版本中，每一个Block是 128M，可以通过dfs.blocksize来更改块的大小，在更改的时候，单位是字节
4、如果一个文件的大小不足128M，那么这个文件是多大，在HDFS上就占多大
5、在HDFS中，会对Block进行编号 - BlockID，第一个BlockID是随机创建的，后续的是全局递增的
6、将数据切块的意义：
a.便于存储超大文件
b.便于进行快速的备份
(3)NameNode
用于管理DataNode和记录元数据Meta
元数据Meta：
1.元数据：大小是150B左右
a.记录数据的虚拟存储路径
b.记录文件的切块数量
c.记录数据块的存储位置
d.记录数据块的副本数量
e.记录文件的权限
2.NameNode将元数据维系在内存以及磁盘中
3.元数据维系在内存中的目的是为了快速查询
4.元数据维系在磁盘中的目的是为了崩溃恢复
5.元数据的存储位置是由hadoop.tmp.dir(core-site.xml文件)属性决定的，如果不配置则默认使用 根目录下的 /tmp
6.元数据在磁盘汇总是以edits文件和fsimage文件的形式存在的
※edits：记录写操作
※fsimage：记录元数据，fsimage中的元数据和内存中的元数据并不是同步的
7.当NameNode接收到请求后，会先将该请求记录到edits_inprogress文件中，如果记录成功，则将该请求同步更新到内存中，修改内存中的元数据，内存修改完成之后会给客户端返回一个ack表示成功。为什么要先写edits_inprogress文件，再更新内存？如果先写内存，再写文件，此时挂了，会导致内存数据丢失，而先写磁盘文件，如果挂了，后面可以从磁盘文件中找寻回到内存中
8.在HDFS中，会给每一次的写操作分配一个编号 - 事务id - txid(Transaction ID) 如：edits_inprogress_0000000000000000022 后面的编号
9.当edits文件达到条件的时候，会将操作更新到fsimage文件中，修改fsimage文件中的元数据：
※空间维度：当edits_inprogress达到指定大小的时候就会触发更新，默认64M大小，由fs.checkpoint.size(core-site.xml)属性来指定，默认单位字节
※时间维度：当距离上一次更新时间达到指定时间间隔的时候，就会触发更新，默认1小时，大小可以由fs.checkpoint.period来指定，默认单位是秒
※重启更新：NameNode重启之后，会自动的将edits_inprogress中的操作更新到fsimage中
※强制更新：执行 hadoop dfsadmin - rollEdits 命令->强制更新操作
10.在更新的时候，会将edits_inprogress重命名为 edits_xxxxx_xxxxxx，如edits_0000000000000000003-0000000000000000021，同时产生一个新的edits_inprogress
11.在Hadoop中，如果存在SecondaryNameNode，则更新过程时发生在SecondaryNameNode上
12.在HDFS中，最核心的节点是NameNode，但是在Hadoop1.0版本汇总只有1个NameNode，
在Hadoop2.0版本中，进行了改变，完全分布式下，允许多设置一个NameNode，代价是丢掉SecondaryNameNode
13.HDFS在启动之后，将写操作记录到 edits_inprogress，edits_inprogress 初始化默认大为1M
管理DataNode
1.NameNode通过心跳机制来管理DataNode：DataNode每隔定长时间会给NameNode发送心跳信息
2.默认情况下，DataNode每隔3s给NameNode发送一条信息
3.如果NameNode长时间(默认10min)没有收到某个DataNode的心跳信息，则认为这个DataNode已经lost(丢失)，此时NameNode会将这个DataNode中数据再次备份，保证副本数量
4.心跳信息：NameNode接收DataNode的心跳数据，a.当前 节点的状态 b.当前节点存放的数据块Block信息
5.NameNode重新启动之后，将edits中操作更新到fsimage中，将fsimage中的元数据加载到内存中，等待DataNode的心跳(如果DataNode没有心跳过来则要重新备份保证副本数量，校验数据总量)，这个过程称之为是安全模式(safe mode)。如果所有的校验都成功了，HDFS会自动退出安全模式
6.因为在安全模式的问题，所以在伪分布式下，副本数量必须为1 - 如果副本数量不为1，则副本默认为3，则在重启NameNode的时候，
根据 "副本的放置策略"的原则，试图将副本备份为3，会失败，一直循环，会导致HDFS一直处于安全模式
(4)副本的放置策略
1.在HDFS中，默认多副本策略，副本数量为3
2.副本放置策略
a.第一个副本：如果是外部客户端上传数据，则此时NameNode会选择一个相对空闲的DataNode节点存放；
如果内部上传(DataNode部署的机器作为客户端)，则第一个副本存放在本节点上
b.第二个副本：在Hadoop2.7之前，第二个副本要放在和第一个副本不同机架的节点上 (机架:请看"机架感知策略")
在Hadoop2.7之后，第二个副本放在和第一个副本相同机架的节点上
c.第三个副本：在Hadoop2.7之前，第三个副本要放在和第二个副本相同机架的节点上
在Hadoop2.7之后，第三个副本要放在和第二个副本不相同机架的节点上
d.更多副本：随机挑选空闲节点存放
(5)机架感知策略
1.在Hadoop中所指的机架并不是物理结构，而是逻辑上的结构
2.可以通过映射关系来指定节点对应的机架，也就意味着同一个物理机架上的节点可以映射到不同额逻辑机架上
3.实际使用中，一般会将一个或者几个物理机架上的所有节点放在一个逻辑机架上
(6)DataNode
1.用于存储数据，注意数据以Block形式存储
2.数据在DataNode上的存储位置由 hadoop.tmp.dir 属性决定，存储目录是
hadoop.tmp.dir属性值/dfs/data/current/BP-833565589-172.16.35.186-1592711419002(块池)/current/finalized/subdir0/subdir0
3.DataNode会通过心跳机制(RPC)来向NameNode发送心跳信息
(6)SecondaryNameNode
1. SecondaryNameNode 只是辅助NameNode进行元数据的合并
过程：将edits文件和fsimage文件拷贝到SecondaryNameNode上，然后将edits中的元数据合并到fsimage中，最后将合并好的数据返回到NameNode上
2.SecondaryNameNode 能起到一定备份的作用，但并不能做到和NameNode之间进行实时热备 - 在实际开发中，一旦利用到SecondaryNameNode进行备份，往往意味着数据已经产生了丢失，如：当SecondaryNameNode从NameNode上将edits和fsimage文件进行拷贝后，在将edits中的元数据合并到fsimage中的同时，NameNode还在接受请求操作，如果此时NameNode挂了，那么NameNode接收到的请求将会丢失，即请求中的数据会丢失。
3.在HDFS，最核心节点一定是NameNode，也因此在Hadoop2.0的完全分布式中，为了做到NameNode的热备，舍弃了SecondaryNameNode
(7)回收站机制
1.在HDFS中，回收站默认是不开启的，也就意味着一旦删除某个文件则这个文件就会被立即移除
2.可以通过 fs.trash.interval 来指定在回收站中停留的时间
开启回收站机制，需要停止hadoop后，修改配置文件 core.site.xml
<!-- 开启回收站策略，需要指定文件在回收站中停留的时间，默认单位是 min 分钟 -->
<!-- 被删除的文件在回收站中会停留1440分钟(1天),如果超过这个时间,回收站中的文件就会被删除--> <property> <name>fs.trash.interval</name> <value>1440</value> </property>
备注：
hadoop-env.sh - 环境变量
core-site.xml
fs.* 开头的属性
hadoop.* 开头的属性
hdfs-site.xml
dfs.* 开头的属性
mapred-site.xml
mapreduce.* 开头的属性
yarn-site.xml
yarn.* 开头的属性
slaves
