HDFS工作原理以及流程

1.Datanode进行上传数据流程
1.client node 向Namenode发起请求

2.Nomenode通过验证，向client node节点返回信息。
信息包含：1.同意上传文件 2.上传的文件被分成几个block
【分块的好处：1.由整化零，分块存储更加方便。
2.磁盘最少能分多少个块可以事先知道。】
【分块的大小：hadoop2上默认为128M hadoop1中默认为为64M
】
3.【为什么选取128M作为分块的大小：1.要去读取速度要快，所有不宜设置太大。2.
同时如果设置过小，会产生太多的小文件，同样影响读取速度。】

3.每个block存储在哪个datanode上
3.client依次以block上传数据
4.在datanode之间建立管道流（pipe line），将块以packet为单位依次写入第一个datanode，第二个datanode，及第三个datanode.写入的时候会以chunk来进行校验。
5.返回写入结果是否成功

由此过程进行引申：
1.根据我们hadoop的 默认设定，每一个block应该有三份复本，那么复本到底应该放置在哪三个不同的datanode上呢？
解释这个问题前首先要说明“集群“”.集群一般包含【节点 机架（机柜）机房 数据中心】四个层次。
并且我们的hadoop可以实现机架感知
一个datanode即为一个节点。我们在进行block的放置时遵循的原则有两种解释
①官方文档版本：
1.以client node节点所在机架中的随机一个剩余容量充足的节点放置第一复本
2.以client node节点所在机架中的随机一个剩余容量充足的节点放置第二个复本
3.以client node节点所在机架之外的其他机架上选一个剩余容量充足的节点放置第三个复本
②技术大牛编写的权威证书：
1.以client node 节点所在机架中随机一个剩余容量充足的节点放置第 一个复本
2.以client node节点所在机架之外的另外机架上随机选取一个剩余容量充足的节点放置第二个复本
3.以第二个复本所在的机架随机选取一个剩余容量充足的节点放置第三个复本
即：2.packet以及chunk的大小？
这个问题可以在官方文档进行查阅
进入官方文档的hdfs-site.xml中可以查阅到该项数值可以自己进行设定！
packet：默认值为65536字节 即64K

chunk：默认!值为512字节
3.返回上传成功的时间？
默认设定为上传完一个副本就会进行就行返回成功标识。
该值可以修改，默认最小值为1.

4.如果在写入过程中，Datanode宕机了，会怎么处理？
如果写入过程中Datanode宕机了，那么client node 就会停止传输数据，并且记住该datanode节点，然后重置管道，绕过该datanode节点。正常的datanode会把通过了校验文件的id进行修改，完成正常传输。宕机的datanode节点会在重启后将id陈旧的数据删除。那么此时这样默认就只有两个dotanode有复本，我们需要有三份复本，剩余的一个副本会由Namenode来补齐。

2.上一个大点datanode如何进行文件传输得以了解，但留下一个问题，我们Namenode是如何补全复本的呢？
.
Namenode与Datanode是主仆关系，Namenode负责管理Datanode，Datanode负责主要存储数据。
Datanode：主要存储block
Namenode：主要存储元数据，存储是文件的映射关系，文件被分成哪些块即块映射信息，以及一些其他的权限信息与所属信息等。
Namenode内存：在每次开启hdfs的时候，会将磁盘中fsimag与edits（不止一个，有后缀吧编号，此处简略）文件读入内存，同时进行一次checkpoint操作，来保证内存中元数据的最新状态。
fsimage：文件保存的是元数据的镜像，即元数据的备份。
edits：保存的是操作日志。
由于内存文件容易丢失，Hadoop考虑到稳定性，将fsimage文件与edits文件存储在磁盘中，但由于磁盘的读写速度有限。所以即时更新fsimage文件响应时间很长会影响集群性能。开发者便运用fsimage文件来记录元数据在某个时刻的数据，edits文件来记录对系统对元数据进行的操作。运用fsimage+edits就可以更新到最新状态的元数据状态。由于edits是记录操作的文件，虽然在磁盘上，但由于文件小，写入的成本相对就低了。
我们将用fsimage+edits来更新到最新元数据的操作叫做checkpoint。
Secondarynamenode：用来辅助Namenode进行checkpoint.

我们在每次进行开启hdfs的时候，我们的Namenode会进行两步操作：
①：将fsimage和edits读入内存中，进行一次checkpoint操作来保证内存中的元数据为最新状态，
②：在进行完第一步操作后，系统会进入safe mode,即安全模式。此时用户无法进行增删改操作，只能进行查操作。在safe mode 下，所有的datanode会向Namenode汇报自己节点上的所有的block信息。此时Namenode中记录的元数据中的block信息得到补全（他事先并不知道哪个块存储在哪个datanode节点上）。并且进行查漏补缺操作。将少于设定复本数量的block进行补全，多余的进行删除。（直接拷贝到其他节点）
之后的Namenode就正常运行了

那么我们之前所说的Secondarynamenode帮助Namenode进行checkpoint操作，是否就只有每次hdfs开机的时候才进行checkpoint呢？
答案当然是否定的，我们每次实际运行HDFS时间可能会非常长，那么将会积累很多的edits操作日志，这个数据量可能非常大，那么我们在下一次开机的时候便有可能要花费大量的时间来进行第一步操作以恢复内存中的元数据是最新状态。这样相当耗费时间。
所有我们的HDFS需要定期来进行Checkpoint的操作，但又不能再本机，因为我们设计之初就是用来降低写入磁盘的成本，那么我们依然在本机进行不就是多此一举吗。
所以有了Secondarynamenode通过checkpoint操作来辅助Namenode。
接下来我们详细介绍checkpoint流程。

我们正常进行操作时流程。
1.我们所在的client会向Namenode发起操作。
2.Namenode检查操作的合理性
3.Namenode将进行操作更新元数据，保证内存中的元数据为最新状态。
4.将操作记录到日志文件edits中， 等待Secondarynamenode发起checkpoint请求
Secondarynamenode发起checkpoint的条件：满足一下一条：1.时间上，根据所设定的时间及3600秒进行一次checkpoint 2.数量上：edits记录数量大招100W条。
（该俩条数据都可以自行设置，可以通过hadoop官网中hdfs-site.xml中搜索关键字100W 3600来查看）
5.Secondarynamenode向Namenode发起checkpoint请求
6.Namenode关闭掉当前正在写的edits文件并且创建一个新的edits（用来保存此次checkpoint开启之后的操作记录）文件。同时将上一次checkpoint到这一次之间产生的所有edits文件拷贝到Secondarynamenode。
7.Secondarynamenode将上一次进行checkpoint所更新dump到磁盘保留的fsimage和拷贝过来的edits操作日志一起读入内存得到新的fsimage.ckpt dump到磁盘保存。同时将上一次的上一次的fsimage文件删除，（由于需要增强hadoop集群的稳定性，系统会保留上一次进行checkpoint的fsimage和所有的edits，以防你最新的fsimage.ckpt文件丢失，还可以通过读入上上次checkpoint所用的fsimage到内存中来还原丢失的文件。增强系统的可靠性（reliable）。）
8.将新生成的fsimage.ckpt文件拷贝到Namenode上并进行更名。同时删除上一次的上一次进行checkpoint所生成的fsimage文件。（即SN和NN都只保留两份fsimage但会保留所用的edits，我所用的hadoop2.6.0会保留所用的edits。据说别的版本的hadoop会删除之前的edits，尚未考证。）
至此，我们Namenode和Secondarynamenode便形成了闭合的环。

最后，说明几个问题。
1.系统存储达到100W条数据后，就会新增几条数据，便删除之前的几条数据。
2.Namenode进行格式化
会在Namenode定义的数据目录中，生成一个dfs的文件夹，dfs文件夹下会生成一个name文件夹。该文件夹是由于初始化了Namenode生成的，里面包含的重要信息有VERSION，fsimage_000000000000000000000，seen_txid，
同时会发现有edits文件，但edits文件并不是初始化生成的。seen_txid记录的是你当前内存中记录的fsimage的编号。
我们可以看到edits_inprogress表面内存中的edits为000…234
我们cat seen_txid会发现其显示为234

初始化启动之后，除了namenode所在节点，其他节点会在定义的数据存储目录下创建一个新的dfs文件夹。
并且初始化启动之后NN会进行合并元数据操作，SN也会进行合并元数据操作。
NN进行合并元数据操作将fsimage读入内存以便内存中存有fsimage方便后续操作。
NN进行合并元数据操作时在安全模式之前。
SN进行合并元数据操作在安全模式之后。
3.如果使用命令 # hdfs dfsadmin -saveNamespace人为的在NameNode上创建一个检查点fsimage的话，SN会怎么来checkpoint呢？
secondarynamenode会按照自己设置好的条件（3600s或100W条edits）来checkpoint，因为与正常情况相比这种情况下checkpoint时会产生NameNode和secondaryNameNode上的fsimage有一个版本的偏差，所以secondaryNameNode会将自己没有的所有的edits拷贝过来，进行checkpoint，这个过程相当于自己更新了两个版本的fsimage。