HadoopHDFS设计原则–硬件错误是常态而不是异常–流式数据访问 –大规模数据集 –简单的一致性模型 –“移动计算比移动数据更划算” –异构软硬件平台间的可移植性 特性–容灾–大容量/大吞吐量（水平扩展能力）–为 mapreduce 计算设计的数据本地化能力 系统结构名称节点（NameNode）管理元数据和文件块管理元数据指管理元数据信息。元数据信息包括名字空间、文件到文件块的映射、文件块到数据节点的映射三部分。管理文件块包括创建新文件块、文件复制、移除无效文件块以与回收孤立文件块等容。（1）字空间或者文件到文件快的映射的任何修改，HDFS都会通过EditLog记录下来。保存到本地磁盘中。通过这种方式可以提高系统的可靠性，并凭借EditLog日志，误中恢复而不必担心数据的一致性问题。（2）块存放的位置信息并不固定而是常常发生变化，因此系统并没有将其持久化到本地中。NameNode启动后并不需要对DataNode进行维护，DataNode会周期性地向NameNode发生心跳响应汇报其文件块信息。（3）所有信息都保存在存中，所以NameNode可以周期性快速地扫描元数据的状态，然后确定出哪些文件块由于DataNode宕机而需要重新复制，哪些件块需要被回收，哪些文件块需要在DataNode间进行迁移来保证系统的负载均衡等元数据元数据一般有三种类型，都会被保存在 NameNode 存中（1） 文件（包括目录）的名称空间，如：/user/hongzhen.lm/search4tag/full/（2） 文件到文件块的映射，如：那个文件由几个文件块（Block）组成（3） 文件块的位置信息，组成 Block 的文件块持久化在那几个 DataNode 中。EditLog主要保存了元数据更改的历史信息（执行写操作，如新建文件或移动文件），因此具有非常重要的作用。EditLog不仅持久化记录了元数据信息，也记录了元数据修改顺序的逻辑时间线，而逻辑时间是对文件和文件块进行查找确认的唯一标识。因此，必须保证EditLog存储的安全性与可靠性。为了防止丢失整个文件系统或者客户端最近的几次操作记录，系统应保证在客户端对元数据的修改操作还没记录到EditLog之前，使该操作对其是不可见的。FsImageFsImage 文件是文件系统元数据的持久化检查点，磁盘上的元数据信息。当NameNode出现问题，是可以根据FsImage和EditLog 快速从错误中进行数据恢复，从而保存数据一致性fsImage文件不会更新文件系统的每个写操作，但是不影响系统的弹性，因为假如名称节点失败，其元数据的最新状态可以被重建，具体方式是从磁盘中...
