HDFS入门详解

一.　　前提和设计目标

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

1. 名称节点(元数据节)点用来管理文件系统的命名空间,

   • 其将所有的文件和文件夹的元数据保存在一个文件系统树中,这些信息也会在硬盘上保存成以下文件：命名空间镜像(namespace image)及修改日志(edit log)

2. 记录每个文件数据块在个个DataNode上的位置和副本信息,协调客户端对文件的访问 协调客户端对文件的访问 ,

   • 这些信息并不存储在硬盘上，而是在系统启动的时候从数据节点收集而成的

3. 协调客户端对文件的访问

4. 记录命名空间内的改动或者空间本身属性的改动

5. NameNode使用事物日志记录HDFS元数据的变化,使用映像文件存储文件系统的命名空间,包括文件映射,文件属性等

NameNode 的存储结构如下:

　　

VERSION文件是java properties文件，保存了HDFS的版本号。

root@VM_160_34_centos:~> cat /usr/local/hadoop-2.2./dfs/name/current/VERSION
#Mon Sep  :: CST
namespaceID=
clusterID=CID-d5e5b442-3fe0-49e0-b25e-f41f5f241153
cTime=
storageType=NAME_NODE
blockpoolID=BP--10.207.160.34-
layoutVersion=-

1. layoutVersion是一个负整数，保存了HDFS的持续化在硬盘上的数据结构的格式版本号。

2. namespaceID是文件系统的唯一标识符，是在文件系统初次格式化时生成的。

3. cTime此处为0

4. storageType表示此文件夹中保存的是元数据节点的数据结构。

　　

2.　　DataNode

1. 负责所在物理节点的存储管理

2. 一次写入,多次读取(不修改)

3. 文件由数据块组成(典型的块大小为64M)

4. 数据块尽量散布到各个节点

5. 周期性的向元数据节点回报其存储的数据块信息.

secondaryNameNode

辅助名称节点(又称 从元数据节点)并不是元数据节点出现问题时候的备用节点，它和元数据节点负责不同的事情。

其主要功能就是

1. 周期性将元数据节点的命名空间镜像文件和修改日志合并，以防日志文件过大。这点在下面会相信叙述。

2. 合并过后的命名空间镜像文件也在从元数据节点保存了一份，以防元数据节点失败的时候，可以恢复。

读取数据流程

客户端要访问HDFS中的一个文件,

首先冲NameNode获取组成这个文件的数据块的位置列表,

根据列表知道存储数据块的DataNode

访问DataNode 获取数据

NameNode 并不参与数据实际传输.

如下图