HDFS

分布式文件系统

传统的网络文件系统（NFS）

• 文件存储在单机上，无法提供可靠性暴躁。

• 很多客户端同时访问NFS Server时，容易造成服务器压力。

• 对文件修改时，得先同步到本地。在未同步到服务端之前，其他客户端是不可见的。

HDFS设计原则

设计目标

• 存储非常大的文件：指的是几百M、G或者TB级别。

• 采用流式的数据访问方式： HDFS基于这样的一个假设：最有效的数据处理模式是一次写入，多次读取数据集。经常从数据源生成或者拷贝一次，然后在其上做很多分析工作。 收集到部分数据就开始读取，而不是收集到全部数据再处理。如果一个文件太大，不需要把一个文件全部读到内存中，然后再做计算；只需要一小块一小块的读。（通过分块机制解决）

• 运行于商业硬件上：Hadoop不需要特别贵的、可靠的机器，可运行于普通商用机器。

HDFS不适合的应用类型

• 低延时的数据访问

• 大量小文件：文件的元数据（目录结构、文件block的节点列表，block-node mapping）保存在NameNode的内存中，整个文件系统的文件数量会受限于NameNode的内存大小。 经验而言，一个文件、目录、文件块一般占有150字节的元数据内存空间。

• 多方读写，需要任意的文件修改：HDFS采用追加（append-only）的方式写入数据，不支持文件任意offset的修改，不支持多个写入器（writer）。

HDFS核心概念

Blocks

• 默认大小为128M。

• 比Block小的文件不会占用整个Block，只会占据实际大小。

• HDFS的Block为什么设置这么大：为了最小化查找时间。控制 定位文件与传输文件所用时间的比例。 如果Block设置过大。在MapReduce任务中，Map或者Reduce任务的个数如果小于进群机器数量，会使得作业运行效率很低。

• Block抽象的好处：使得单个文件大小可以大于整个磁盘的容量。构成文件的Block可以分布在整个集群，理论上，单个文件可以占据集群中所有机器的磁盘。 Block的抽象也简化了存储系统，对于Block，无需关注其权限，所有者等内容。（这些内容都在文件级别上进行控制）。 Block作为容错和高可用机制中的副本单元，即以Block为单位进行复制。（如果某个数据块丢失或损坏，只需复制丢失或损坏的数据块，而不需要复制整个文件）

Namenode & Datanode

整个HDFS集群有Namenode和Datanode构成master-worker（主从）模式。Namenode负责构建命名空间，管理文件的元数据等。Datanode负责实际存储数据，负责读写工作。

Namenode

Namenode存放文件系统树及所有文件、目录的元数据。元数据持久化为2种：

• namespace image

• edit log

持久化数据中不包括Block所在的节点列表，及文件的Block分布在集群的哪些节点上。这些信息在系统重启的时候重新构建（通过Datanode汇报的Block信息）。

在HDFS中，Namenode可能成为集群的单点故障。有两种解决机制：

• 备份持久化数据

  将文件系统的元数据同时写到多个文件系统，例如同时将元数据写到本地文件系统及NFS。这些备份操作都是同步的，原子的。

• Secondary Namenode Secondary节点定期合并主Namenode的namespace image和edit log，避免edit log过大。通过创建检查的checkpoint来合并。它会维护一个合并后的namespace image副本，可用于在Namenode完全崩溃时恢复数据。 Secondary Namenode通常运行在另一台机器，因为合并操作需要耗费大量的CPU和内存。其数据落后于Namenode，因此当Namenode完全崩溃时，会出现数据丢失。通常做法是拷贝NFS中的备份元数据到Second，将其作为新的Namenode。 在HA（High Availability高可用性）中可以运行一个Hot Standby，作为热备份，在Active Namenode故障之后，替代原有Namenode成为Active Namenode

Datanode

数据节点负责存储和提取Block，读写请求可能来自namenode，也可能直接来自客户端。数据节点周期性向Namenode汇报自己节点上所存储的Block相关信息。