HadHoop分布式框架简介(一)
????图 2.1: DataNodes 存储着文件的文件块?，备份的数量是2 。NameNode 结点负责将文件名映射到文件块的ID上。
?
?? 多数块结构的文件系统使用4k或者8k 数量级别的块大小。相比之下，HDFS的块大小默认下是64MB---一个大很多的数量级别。这个设计减少了HDFS持有的文件块的数量（文件块的容量大的时候，块的数量就会相应的减少了）。这样做更有利于流式读取方式。显而易见，HDFS 非常喜欢 特大的文件，并且更喜欢流式地读取它们。不像NTFS 或EXT这样的文件系统，它们通常保存很多的小文件，HDFS更希望存储适中数量的特大文件，几百M的、几百G的。毕竟，一个100M的文件也才不过两个文件块而已。在我们平常的计算机中，文件通常是被随机访问的，应用程序可能会读取一个文件的不同的几个部分，这些部分通常不是连续的存储在硬盘上的。相比之下，HDFS期望程序一次读完整个文件。这种做法刚好非常适合MapReduce编程的风格。也就是说，像平常使用一般分布式系统那样去使用HDFS，不是一个明智的选择。
?
?? HDFS将文件分成块，并存储在几台机器上，这些文件不可能被当成正常文件系统的一部分了。在一台跑Hadoop的机器上使用ls命令，返回的结果是linux系统的内容，而并不会包括任何存储在HDFS系统里面的文件。HDFS是一个建立在本地文件系统之上的应用。HDFS的文件（更确切的说，组成文件的那些文件块） 被存储在 DataNode 结点的一个特定的目录下，但这些文件块只有id。所以，你根本就没有办法使用linux 文件系统的一些工具（ls，cp，mv等等）去操作这些文件。不用操心，HDFS 自带了文件管理功能，操作起来跟（ls，cp，mv）等命令一样地简单。
?
?? 数据的可靠性是相当重要的。HDFS的数据被设计成只允许一次写入和多次读取操作，当大量的客户端同时需要对文件目录进行修改的时候，同步工作就显得异常重要了。所以，对文件目录的维护由单独的一台机器来完成，这台机器我们称之为NameNode。NameNode将会存储 文件系统的文件目录和文件名称。因为，每个文件需要记录的东西是很少的（例如，文件名、权限、文件块的位置等），所以，所有的数据都可以被存储在一台机器上，并提供快速的访问功能。
?
?? 假设，客户端要访问文件A。客户端从NameNode中取得组成文件A的文件块的位置列表。这个列表知道文件块被存储在哪台机器上。然后客户端 直接 从DataNode上读取文件数据。NameNode是不参与文件的传输的，我们要保证NameNode的消耗尽可能的小。
?
?? 当然，我们还有预防NameNode机器崩溃的情况。我们使用冗余来保证文件系统的数据不会丢失，即使是在NameNode忽然崩溃的情况下。显然，NameNode的崩溃要比集群里面的任何一台DataNode的崩溃要严重得多了。当一台DataNode故障的时候，整个集群还可以继续运行，但当NameNode故障的时候，集群就无法运行了，这时候，我们得手动的采取措施修复故障。当然，NameNode的工作量是相当的小的，它发生故障的概率要比其他机器发生故障的概率小得多了。
?
?? 关于HDFS的设计与实现，下面的这篇文章阐述的更加详细。document
