Hadoop分布式文件系统（一）
分布式文件系统
当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区（partition）并存储到若干台单独的计算机上。管理网络中跨多台计算机存储的文件系 统成为分布式文件系统。
HDFS的设计
HDFS以流式数据访问模式来存储超大文件，运行于商用硬件集群上。
超大文件
“超大文件”在这里指具有几百MB、几百GB甚至几百TB大小的文件。目前已经有存储PB级数据的Hadoop集群了。
流式数据访问
HDFS的构建思路是这样的：一次写入，多次读取是最搞高效的访问模式。数据集通常由数据源生成或从数据源复制而来，接着长时间的在此数据集上进行各类分析。每次分析都将涉及该数据集的大部分数据甚至全部，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。
商用硬件
Hadoop并不需要运行在昂贵且高可靠的硬件上。它是设计运行在商用硬件的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS遇到上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。
低时间延迟的数据访问
由于HDFS是为高数据吞吐量应用优化的，这可能会以高时间延迟为代价的，所以 要求低时间延迟数据访问的应用，不适合在HDFS上运行。
大量的小文件
由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于啊namenode的内存容量。每个文件，目录和数据块的存储信息大约150字节。举例来说：如果有一百万个文件，且每个文件占一个数据块，那么需要300MB内存。尽管存储上百万个文件是可行的，但是存储十亿个文件就超出了当前硬件的能力。
多用户写入，任意修改文件
HDFS中的文件可能只有一个writer，而且写操作总是将数据添加在文件的末尾。它不支持具有多个写入者的操作，也不支持在文件的任意位置进行修改。可能以后会支持这些操作，但它们相对比较低效。
HDFS的概念
数据块
HDFS中的数据块默认是64MB，与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块，作为独立的存储单元。但与其他文件系统不同的是，HDFS中小与一个块大小的文件不会占据整个块的空间。（HDFS的块比磁盘块大的目的是为了最小化寻址开销。）
与磁盘文件系统相似，HDFS中fsck指令可以显示块信息。执行以下命令将列出文件系统中各个文件由哪些块构成：hadoop fsck / -files blocks
NameNode和DataNode
HDFS集群有两类节点，是主从结构模式运行，即一个namenode和多个datanode。
NameNode管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件和编辑日志文件。Namenode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时由数据节点重建。
客户端代表用户通过与namenode和datanode交互来访问整个文件系统。客户端提供一个类似与POSIX（可移植操作系统界面）的文件系统接口，因此用户在编程时无需知道namenode和datanode也可实现其功能。
DataNode是文件系统的工作节点。他们根据需要存储并检索数据块（受客户端或namenode调度），并定期向namenode发送他们所存储的块的列表。
namenode容错问题
没有namenode，文件系统将无法使用。如果运行namenode服务的机器毁坏，文件系统上所有的文件将会丢失，因为我们不知道如何根据datanode的块来重建文件，为此Hadoop提供了两种机制（现在主要用第二种）：
第一种机制是备份那些组成文件系统元数据持久状态的文件。Hadoop可以通过配置实用namenode在多个文件系统上保存原数据的持久状态。这些写操作是实时同步的，是原子操作。一般的配置是，将持久状态写入本地磁盘的同时，写入一个远程挂在的网络文件系统NFS。
第二种是运行一个辅助namenode，SecondaryNameNode，它不能被用作namenode。SecondaryNameNode的重要作用是定期通过编辑日志合并空间镜像，以防止编辑日志过大。一般SecondaryNameNode在另一台单独的物理计算机上运行，因为它需要占用大量的CPU时间与NameNode相同容量的内存来执行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。但是secondaryNameNode保存的状态总是滞后于主节点，所以当主节点失效时，难免会丢失部分数据。在这种情况下，一般把存储在NFS上的namenode元数据复制到secondaryNameNode并作为新的主NameNode运行。
