大数据之HDFS构架原理

断断续续看Hadoop已有两个多月，对于HDFS的构架原理，总是没有清晰的脉络，看了无数博客和视频教程，还是雾里看花，写篇博客清清脑子。正常启动hadoop伪分布式的hdfs后，运行jps命令，会出现几个进程名，从这几个进程来理解hdfs的体系结构：

从实现文件的分布式存储过程来来大体理解hdfs：假设有1G的文件要存储在PC上，可是很不幸，PC的可用磁盘空间不足，所以一台PC是不可能完成任务，需要用多台。但是好好的1G文件，怎么才能被切成一块块存储在多台PC中呢？而且保证当用户需要这1G文件时，在把它组装成原文件，返还给用户？还要保证被切分的每一块都不丢失不损坏？
HDFS是这样做的：首先通过HDFS 客户端将1G文件的描述信息报告给NameNode，告诉NameNode，我这有1G文件要存储，NameNode在收这个描述信息后，根据文件的大小，通知离这个1G文件最近的DateNode，去将这1G文件切成每份64M大小的block，DateNode会将这1G的文件以block为最小存储单元存储在本地磁盘上，并且流水线的复制给其他DateNode，即一个block存3份（这样保证数据的容错）。待文件存储完成后，会向NameNode报告这1G文件的存储位置等信息，即元数据。NameNode收到DateNode的确认消息后，会在内存中增加一条记录，记录着这个1G文件在DateNode的存储位置，维护该文件的存储信息（元数据）。NameNode还会将这些元数据持久化的存储在硬盘上，即为fsimage，同时在一个editlog文件中，来记录NameNode的本次操作。NameNode作为hdfs的主服务器，对于资源的需求和消耗非常的大，对于文件的操作非常频繁，每次操作都会产生新的元数据，不可能每次hdfs操作产生的元素据都立即实时的持久化存储在磁盘里。而是通过editlogs文件实时记录NameNode的操作信息，所以editlog增大到一定大小时，或者过了一段时间，再通过合并editlog文件和fsimage产生新的fsimage文件来替代旧的fsimage文件。
fsimage既是Namenode为存储HDFS的文件和目录元数据产生的二进制文件，每次保存fsimage之后到下次保存之间的所有hdfs操作，将会记录在editlog文件中，当editlog达到一定的大小（bytes，由fs.checkpoint.size参数定义）或从上次保存过后一定时间段过后（sec，由fs.checkpoint.period参数定义），namenode会重新将内存中对整个HDFS的目录树和文件元数据刷到fsimage文件中。而对于fsimage和editlogs文件的合并，即为SecondaryNameNode完成。但值得注意的是，hdfs集群在每次启动时都会加载fsimage，加载完毕后，会在内存中构建整个namespase，然后NameNode就会等待所有DateNode发送心跳包，将所存数据信息发给NameNode，这样NameNode就可以对外提供服务了。
现在再讲hdfs的几个进程，理解起来就容易了：

以下内容从两篇文章总结而来，原文见参考文献链接：

1. NameNode
Namenode 管理者文件系统的Namespace。它维护着文件系统树(filesystem tree)以及文件树中所有的文件和文件夹的元数据(metadata)。管理这些信息的文件有两个，分别是Namespace 镜像文件(Namespace image)和操作日志文件(edit log)，这些信息被Cache在RAM中，当然，这两个文件也会被持久化存储在本地硬盘。Namenode记录着每个文件中各个块所在的数据节点的位置信息，但是他并不持久化存储这些信息，因为这些信息会在系统启动时从数据节点重建。
2. DateNode
Datanode是文件系统的工作节点，他们根据客户端或者是namenode的调度存储和检索数据，并且定期向namenode发送他们所存储的块(block)的列表。集群中的每个服务器都运行一个DataNode后台程序，这个后台程序负责把HDFS数据块读写到本地的文件系统。当需要通过客户端读/写某个 数据时，先由NameNode告诉客户端去哪个DataNode进行具体的读/写操作，然后，客户端直接与这个DataNode服务器上的后台程序进行通 信，并且对相关的数据块进行读/写操作。
3. SecondaryNameNode
Secondary NameNode是一个用来监控HDFS状态的辅助后台程序。就想NameNode一样，每个集群都有一个Secondary NameNode，并且部署在一个单独的服务器上。Secondary NameNode不同于NameNode，它不接受或者记录任何实时的数据变化，但是，它会与NameNode进行通信，以便定期地保存HDFS元数据的 快照。由于NameNode是单点的，通过Secondary NameNode的快照功能，可以将NameNode的宕机时间和数据损失降低到最小。同时，如果NameNode发生问题，Secondary NameNode可以及时地作为备用NameNode使用。

突然想到一个问题：既然namenode每次重启时都加载fsimage，然后等待DataNode发送位置信息，才能确定block位置信息，那为什还需要fsimage？
重启时，fsimage加载到NameNode内存中时，在fsimage中，并没有记录每一个block对应到哪几个datanodes的对应表信息，而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储，而是在所有datanode启动时，每个datanode对本地磁盘进行扫描，将本datanode上保存的block信息汇报给namenode，namenode在接收到每个datanode的块信息汇报后，将接收到的块信息，以及其所在的datanode信息等保存在内存中。HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanode向namenode汇报块信息的过程叫做blockReport，而namenode将block -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。
因此在namenode启动并加载fsimage完成之后，实际上BlocksMap中的key，也就是Block对象都已经加载到BlocksMap中，每个key对应的value(BlockInfo)中，除了表示其所属的datanodes列表的数组为空外，其他信息也都已经成功加载。所以可以说：fsimage加载完毕后，BlocksMap中仅缺少每个块对应到其所属的datanodes list的对应关系信息。所缺这些信息，就是通过上文提到的从各datanode接收blockReport来构建。当所有的datanode汇报给namenode的blockReport处理完毕后，BlocksMap整个结构也就构建完成。
namenode在加载fsimage过程其实非常简单，就是从fsimage中不停的顺序读取文件和目录的元数据信息，并在内存中构建整个namespace，同时将每个文件对应的blockid保存入BlocksMap中，此时BlocksMap中每个block对应的datanodes列表暂时为空。当fsimage加载完毕后，整个HDFS的目录结构在内存中就已经初始化完毕，所缺的就是每个文件对应的block对应的datanode列表信息。这些信息需要从datanode的blockReport中获取，所以加载fsimage完毕后，namenode进程进入rpc等待状态，等待所有的Datanodes发送blockReports。
每个datanode在启动时都会扫描其机器上对应保存hdfs block的目录下(dfs.data.dir)所保存的所有文件块，然后通过namenode的rpc调用将这些block信息以一个long数组的方式发送给namenode，namenode在接收到一个datanode的blockReport rpc调用后，从rpc中解析出block数组，并将这些接收到的blocks插入到BlocksMap表中，由于此时BlocksMap缺少的仅仅是每个block对应的datanode信息，而namenoe能从report中获知当前report上来的是哪个datanode的块信息，所以，blockReport过程实际上就是namenode在接收到块信息汇报后，填充BlocksMap中每个block对应的datanodes列表的三元组信息的过程。
当所有的datanode汇报完block，namenode针对每个datanode的汇报进行过处理后，namenode的启动过程到此结束。此时BlocksMap中block->datanodes的对应关系已经初始化完毕。如果此时已经达到安全模式的推出阈值，则hdfs主动退出安全模式，开始提供服务。
综上，在加载fsimage时，会构建hdfs的namespace，如果没有namespace，整个hdfs都会崩溃，其他的更不用说了。
参考资料：NameNode启动过程分析，hdfs各进程作用，讲的比较详细的两篇文章
http://www.linuxidc.com/Linux/2012-01/51614p2.htm
http://www.aboutyun.com/thread-7088-1-1.html