Hadoop源代码点滴-文件系统HDFS

1. HDFS是Hadoop集群的文件系统，这是一种分布（distributed）、容错（fault tolerant）的文件系统
2. 所谓分布，是说整个文件系统的内容并非集中存储在一台或几台“文件服务器上”，而是分散在集群的不同节点上
3. 对于大数据文件系统，文件之所以应该是分布式的，不再仅仅是容量和容错的问题，还有计算的问题。
4. 大数据处理有个原则，就是数据在哪里，计算就在哪里。
5. 分布的计算必然要求分布的数据存储，最好就是每个机诶但都存储数据，每个节点也都承担计算。
6. 按什么方式把整个文件系统的内容分布存储在集群中呢
   1. 远程挂在（mount）：这只是目录（文件子系统）层面的分布
   2. 粒度更细化一点，改成文件层面的分布：也就是说不是以目录为单位，而是以文件为单位的分布，并建立重要文件查名服务器
   3. 粒度更细化，改成文件块层面的分布：在存储的时候把文件拆散，HDFS的分布，是“块”这个层次的分布.
7. HDFS文件块是虚拟的，默认64MB，128MB也是很常用的
8. 集中的目录和查明服务，则不是告诉你这些文件在哪里，而是告诉你具体的块在哪里，然后你自己去访问
9. HDFS的查明服务都集中在一个节点上，成为nameNode；担负文件内容存储的节点则成为DataNode。
10. 在DataNode上，不管是1MB、64MB、一个（HDFS的）块对于宿主主机而言就是一个文件，其块号就编码在文件名中。从一个DataNode中读出一个块，实际上是读出一个文件。而在NameNode中，则存储的是HDFS“文件系统”，实际上存储整个目录树，或称“namespace”的映像。可想而知，这个映像也是作为宿主系统的文件而存储的。
11. 解决了怎么分布的问题，随之而来的是容错的问题。HDFS采用了“狡兔三窟”的策略，每个块都是一式几份。响应地，查明服务要提供的就不只是一个块在什么地方，而是这个块的几个副本分别在什么地方。这样，你就可以自己决定从哪个节点上读取这个块的副本，万一失败就换一个节点再去读取另一个副本。
12. 为NameNode提供热备的节点，则称为“Standby NameNode“。ActiveNN和StandbyNN之间的有同步才能保持一致。然而如果每一次有一点改变时就得同步一次，系统的开销太大，所以HDFS采用一个变通的方法。（类似Oracle的archive log）

原文：https://www.cnblogs.com/jiangtao1218/p/9129362.html