HADOOP之HDFS学习

HDFS原理以及读写流程

1. 最近从零开始学习大数据，所以也开始学习他的一些框架，这是我所理解的hdfs

• [ ] 1.HDFS系统架构
  
• 2.三个角色
• Client：客户端，系统使用者，调用HDFS API操作文件;与NN交互获取文件元数据;与DN交互进行数据读写
• Namenode
  存储：
  文件系统的命名空间，文件名称，文件目录结构，文件的属性[权限,创建时间,副本数];
  文件对应哪些数据块–>数据块对应哪些datanode节点
  当然namenode节点不会持久的存储这种映射关系,是通过集群在启动和运时,datanode定期发送blockReport给namenode,以此namenode在内存中来动态维护的这种映射关系
  作用:
  管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件fsimage和编辑日志文件editlog。
• 3.Datanode
  存储：
  数据块和数据块校验和
  与Namenode通信:
  每隔3秒发送一个心跳包
  每十次心跳发送一次blockReport.
  作用(主要):
  读写文件的数据块
• 4副本放置策略
  1、 第一副本：放置在上传文件的DataNode上;如果是集群外提交，则随机挑选一台磁盘不太慢、CPU不太忙的节点上;
  2、第二副本：放置在于第一个副本不同的机架的节点上;
  3、第三副本：与第二个副本相同机架的不同节点上;
  如果还有更多的副本：随机放在节点中;
• 5.文件写流程
  
  1.客户端向NameNode发出写文件请求。
  2.检查是否已存在文件、检查权限。若通过检查，直接先将操作写入EditLog，并返回输出流对象。 （注：WAL，write ahead log，先写Log，再写内存，因为EditLog记录的是最新的HDFS客户端执行所有的写操作。如果后续真实写操作失败了，由于在真实写操作之前，操作就被写入EditLog中了，故EditLog中仍会有记录，我们不用担心后续client读不到相应的数据块，因为在第5步中DataNode收到块后会有一返回确认信息，若没写成功，发送端没收到确认信息，会一直重试，直到成功）
  3.client端按128MB的块切分文件。
  4.client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点，此后client端和NameNode分配的多个DataNode构成pipeline管道，client端向输出流对象中写数据。client每向第一个DataNode写入一个packet，这个packet便会直接在pipeline里传给第二个、第三个…DataNode（注：并不是写好一个块或一整个文件后才向后分发）
  5.每个DataNode写完一个块后，会返回确认信息。
  （注：并不是每写完一个packet后就返回确认信息，个人觉得因为packet中的每个chunk都携带校验信息，没必要每写一个就汇报一下，这样效率太慢。正确的做法是写完一个block块后，对校验信息进行汇总分析，就能得出是否有块写错的情况发生）
  6。写完数据，关闭输输出流。
  7.发送完成信号给NameNode。
  （注：发送完成信号的时机取决于集群是强一致性还是最终一致性，强一致性则需要所有DataNode写完后才向NameNode汇报。最终一致性则其中任意一个DataNode写完后就能单独向NameNode汇报，HDFS一般情况下都是强调强一致性）

总结：这一方法不仅提供了很好的稳定性（数据块存储在两个机架中）并实现很好的负载均衡，包括写入带宽（写入操作只需要遍历一个交换机）、读取性能（可以从两个机架中选择读取）和集群中块的均匀分布（客户端只在本地机架上写入一个块）。

• 8.文件读流程
  
  1.client访问NameNode，查询元数据信息，获得这个文件的数据块位置列表，返回输入流对象。
  2.就近挑选一台datanode服务器，请求建立输入流 。
  3.DataNode向输入流中中写数据，以packet为单位来校验。
  4.关闭输入流
• 9.读写过程，数据完整性如何保持
  通过校验和。因为每个chunk中都有一个校验位，一个个chunk构成packet，一个个packet最终形成block，故可在block上求校验和。

HDFS 的client端即实现了对 HDFS 文件内容的校验和 (checksum) 检查。当客户端创建一个新的HDFS文件时候，分块后会计算这个文件每个数据块的校验和，此校验和会以一个隐藏文件形式保存在同一个 HDFS 命名空间下。当client端从HDFS中读取文件内容后，它会检查分块时候计算出的校验和（隐藏文件里）和读取到的文件块中校验和是否匹配，如果不匹配，客户端可以选择从其他 Datanode 获取该数据块的副本。

• 10.nameNode的主从的数据同步
  为了让Standby节点保持其与Active节点的状态同步，两个节点都与一组名为JournalNodes(JNs)的独立守护进程进行通信。当Active节点执行任何namespace修改时，Active节点将修改记录持久地记录到这些JN中的大多数中。Standby节点从JN读取edits并持续监视JN以更改edit log。一旦Standby节点观察edits后，会将这些edits应用于其自己的namespace。当使用QJM时，JournalNodes将执行shared editlog storage。在故障切换事件中，Standby服务器确保在将自己提升为Active状态之前，已从JounalNodes中读取所有edits。（这种机制确保在故障切换完成之前namespace状态已完全同步。）
  11.HDFS的安全模式
  在hadoop启动namenode的时候，会启动安全模式（safemode），在该模式下，namenode会等待datanode向它发送块报告（block report），只有接收到的datanode上的块数量（datanodes blocks）和实际的数量（total blocks）接近一致， 超过 datanodes blocks / total blocks >= 99.9% 这个阀值，就表示 块数量一致，就会推出安全模式。达到99.9%的阀值之后，文件系统不会立即推出安全模式，而是会等待30秒之后才会退出。
  在安全模式下不可以进行以下操作：
  1）创建文件夹2）上传文件3）删除文件
  注意：启动了namenode，未启动datanode，则文件系统处于安全模式，只可以查看文件系统上有哪些文件，不可以查看文件内容，因为datanode都还没启动，怎么可能可以查看文件内容
  启动命令：hdfs dfsadmin -safemode enter
  12.HDFS主从数据同步（namenode standbynamenode）
  https://blog.csdn.net/zhanyuanlin/article/details/78077977
  13.小文件过多 ，对hdfs影响
  1、小文件过多，会过多占用namenode的内存，并浪费block。
• 文件的元数据（包括文件被分成了哪些blocks，每个block存储在哪些服务器的哪个block块上），都是存储在namenode上的。
  HDFS的每个文件、目录、数据块占用150B，因此300M内存情况下，只能存储不超过300M/150=2M个文件/目录/数据块的元数据
• dataNode会向NameNode发送两种类型的报告：增量报告和全量报告。
  增量报告是当dataNode接收到block或者删除block时，会向nameNode报告。
  全量报告是周期性的，NN处理100万的block报告需要1s左右，这1s左右NN会被锁住，其它的请求会被阻塞。
  2、文件过小，寻道时间大于数据读写时间，这不符合HDFS的设计:
  HDFS为了使数据的传输速度和硬盘的传输速度接近，则设计将寻道时间（Seek）相对最小化，将block的大小设置的比较大，这样读写数据块的时间将远大于寻道时间，接近于硬盘的传输速度。

namenode详解：
Secondary NameNode：在一个比繁忙的集群中，长时间的运行会生成一个很大的edits log。Secondary NameNode会定期（合并的策略可以自定义配置，默认为1小时）的合并edits log和镜像。这样可以使得NameNode在重启时，节约镜像和Edits log的合并时间，节约内存空间。Secondary NameNode存储了最新的CheckPoint在NameNode目录下。所以，Secondary NameNode的镜像，如果需要的话，NameNode可以随时读取

ChekPoint工作流程：

BackUp Node:

BackUp Node提供了与CheckPoint一样的功能(都是 用于备份集群状态，以便于发生故障时，能够恢复),维护一个与NameNode一样的内存工作空间(NameSpace)，并且实时更新最新的NameNode状态到BackUp Node自己的工作空间。同时接收NameNode的edits，持久化到硬盘。BackUp Node目的与CheckPoint一致，但是，BackUp Node动态的同步NameNode的状态到内存中，不需要通过创建checkpoints下载镜像和edits log，所以它的处理更加有效，快速。BackUp Node只需要保存镜像和edits log到它自己的命名空间。