一. 前提和设计目标
1. 硬件错误是常态,因此需要冗余,这是深入到HDFS骨头里面去了
HDFS可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。我们面对的现实是构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分HDFS的组件是不工作的。因此错误检测和快速、自动的恢复是HDFS最核心的架构目标
2. 流式数据访问
即:数据批量读取而非随机读写(OLTP),Hadoop擅长的是数据分析而不是事物处理
3. 大规模数据集
HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。
4. 简单的一致性模型
为了降低系统复杂度,HDFS应用需要一个“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。
5. 数据就近
一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。将计算移动到数据附近，比之将数据移动到应用所在显然更好。HDFS为应用提供了将它们自己移动到数据附近的接口。
二. HDFS体系架构
HDFF 体系架构主要分为以下几个部分
NameNode
DataNode
SecondaryNameNode
事物日志
映像文件
如图:
1. NameNode
名称节点(元数据节)点用来管理文件系统的命名空间,
- 其将所有的文件和文件夹的元数据保存在一个文件系统树中,这些信息也会在硬盘上保存成以下文件：命名空间镜像(namespace image)及修改日志(edit log)
记录每个文件数据块在个个DataNode上的位置和副本信息,协调客户端对文件的访问 协调客户端对文件的访问 ,
- 这些信息并不存储在硬盘上，而是在系统启动的时候从数据节点收集而成的
协调客户端对文件的访问
记录命名空间内的改动或者空间本身属性的改动
NameNode使用事物日志记录HDFS元数据的变化,使用映像文件存储文件系统的命名空间,包括文件映射,文件属性等
NameNode 的存储结构如下:
VERSION文件是java properties文件，保存了HDFS的版本号。
root@VM_160_34_centos:~> cat /usr/local/hadoop-2.2.0/dfs/name/current/VERSION
#Mon Sep 01 16:17:18 CST 2014
namespaceID=1671627874
clusterID=CID-d5e5b442-3fe0-49e0-b25e-f41f5f241153
cTime=0
storageType=NAME_NODE
blockpoolID=BP-903224288-10.207.160.34-1409559438288
layoutVersion=-47
layoutVersion是一个负整数，保存了HDFS的持续化在硬盘上的数据结构的格式版本号。
namespaceID是文件系统的唯一标识符，是在文件系统初次格式化时生成的。
cTime此处为0
storageType表示此文件夹中保存的是元数据节点的数据结构。
2. DataNode
负责所在物理节点的存储管理
一次写入,多次读取(不修改)
文件由数据块组成(典型的块大小为64M)
数据块尽量散布到各个节点
周期性的向元数据节点回报其存储的数据块信息.
secondaryNameNode
辅助名称节点(又称 从元数据节点)并不是元数据节点出现问题时候的备用节点，它和元数据节点负责不同的事情。
其主要功能就是
周期性将元数据节点的命名空间镜像文件和修改日志合并，以防日志文件过大。这点在下面会相信叙述。
合并过后的命名空间镜像文件也在从元数据节点保存了一份，以防元数据节点失败的时候，可以恢复。
读取数据流程
客户端要访问HDFS中的一个文件,
首先冲NameNode获取组成这个文件的数据块的位置列表,
根据列表知道存储数据块的DataNode
访问DataNode 获取数据
NameNode 并不参与数据实际传输.
如下图
