HDFS——分布式文件管理系统（一）

前言

　　作为初学Hadoop的小白，这里只是总结，没有很高的囊括性，在后续的学习我也会优化推出更有深度的文章。

　　HDFS的第一部分只是讲解理论，关于核心API部分的会在后续推出。

　　HDFS作为分布式文件管理系统的一员，适合一次写入，多次读出的场景；能够处理的数据规模达到GB、TB、甚至PB级别；在文件规模上，能够理百万规模以上的文件数量。

一、HDFS的架构

　　HDFS有四个架构，NameNode、DataNode、Client、Secondary NameNode。

　　NameNode，主要维护的是元数据。负责管理HDFS的名称空间，配置副本策略、管理数据块（Block，在2、3的版本中是128M,也可以通过dfs.blocksize设置）映射信息、处理客户端的读写请求

　　DataNode，执行实际的操作。存储实际的数据块、执行数据块的读写操作。

　　Client，客户端。用Java（IDEA)来编写客户端程序，将文件上传到HDFS的时，Client会将文件切分为一个一个的block再进行上传；与NameNode交互，获取文件的位置信息；与DataNode交互，进行读写数据；可以通过命令来管理和访问HDFS。

　　Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务。辅助NameNode，分担其工作量，比如定期合并Fsimage和Edits，并推送给NameNode ；在紧急情况下，可辅助恢复NameNode。

　　HDFS的读写流程

　　在上述对HDFS架构的了解中，从Client就可以看出大致的流程。

　　首先客户端向NameNode发送请求，想要将ss.avi发送至集群的/user/atguigu的路径下。

　　NameNode接受请求后，查看是否有权限和目录是否存在，符合条件反馈可以上传文件

　　客户端接受反馈后，发送第一个切分所得的block，请求获取节点

　　NameNode对节点的选择是就近原则和负载均衡，如图返回所示的3个节点

　　Client创建输出流（先创建缓冲队列，对数据采用流式传递，只需与一个节点应答，边读边存边写），数据流中最小单位，一个64K的数据包（节点中的小球）

　　在数据流先是形成chunk512个字节和4位校验位，然后攒到64K就是数据包，多个packet（数据包）放在一个缓冲队列，发送。

　　packet下发的同时会准备一个ack队列（接受下一段是否应答成功），应答成功会删除数据，没有成功会将数据再返回packet中，起一个备份作用

　　读流程还是客户端先向NameNode发送请求，NameNode会查看权限和要访问的文件是否存在

　　返回元数据（描述数据的数据，跟索引的性质一样）

　　客户端创建流来读取数据，读取选择的节点，就近原则负载均衡。串型读先读第一块再度第二块。

　　节点距离计算

　　在上一环节节点到底怎么取呢？最近距离如何计算？

　　节点距离=两个节点到达共同祖先的距离总和

　　节点A:/d1/r1/n1　　节点B:/d1/r1/n2　　AB节点的共同祖先为r1，n1到r1为1，n2到r1为1，所以节点距离为2

　　机架感知（副本存储节点选择）：

　　第一个节点一般优先在哪台机器上提交就选择谁，图的是节点距离最最近效率高

　　第二个节点保证数据的可靠性

　　第三个节点又兼顾效率

二、NameNode的工作机制

　　我们知道NameNode主要维护的就是元数据，所以元数据的存储就很重要。下图我们终于看到了Secondary NameNode，它的设定也与元数据的存储有很大关系。

　　元数据是数据的索引，存放在内存虽说很效率，但一经断电元数据便丢失，集群随之瘫痪。但在硬盘中虽然可靠但不效率。

　　这里用可Fslmage（存储数据）和Edits（追加）存储数据，在服务器开启时Fslmage和Edits会加载到内存中，服务器关闭时Fslmage和Edits合并，合成元数据。

　　当数据量变大，服务器关机时的合并时间太长效率低。这就需要Secondary NameNode来打辅助。

　　当客户端对NameNode发出请求（这里是增删改查），先记录信息再允许你对内存信息进行操作。

　　Secondary NameNode，对NN（NameNode）发出是否需要服务的请求CheckPoint，CheckPoint的触发条件：定时时间到（默认1小时）、Edits中数据已满。在请求执行通过后会新建一个Edits..002将正在或者以后访问的记录记录在此。而原先的Edits..in..001修改名称为edits_001。接着NN2会将fsimage拉取过来，拷贝，再次与Edits加载到内存。　最终会形成一个新的fsimage.chepoint，将其再拷贝回NN重命名为fsimage覆盖历史的fsimage，覆盖之后与Edits..002合并在一起就是当前最新的元数据。

　　每当元数据有更新或添加元数据时，修改内存中的元数据并追加到Edits中。