HDFS架构与设计
- 一、背景和起源
- 二、HDFS概述
-
- 1.设计原则
-
- [1.1 硬件错误](#1.1 硬件错误)
- [1.2 流水访问](#1.2 流水访问)
- [1.3 海量数据](#1.3 海量数据)
- [1.4 简单一致性模型](#1.4 简单一致性模型)
- [1.5 移动计算而不是移动数据](#1.5 移动计算而不是移动数据)
- [1.6 平台兼容性](#1.6 平台兼容性)
- 2.HDFS适用场景
- 3.HDFS不适用场景
- 三、HDFS架构图
- 四、HDFS数据存储
- 五、元数据持久化
- 总结
- 参考
一、背景和起源
HDFS是一个构建在廉价机器上的分布式文件存储系统。最初是Doug Cutting为了解决Nutch网页搜索所面对的海量数据处理问题，根据Google的GFS论文，实现的一个分布式文件存储系统并命名为NDFS(Nutch Distributed File System)，之后改名为HDFS(Hadoop Distributed File System)，成为Hadoop项目的一部分。
二、HDFS概述
1.设计原则
1.1 硬件错误
硬件错误是比软件异常更容易出现的情况，HDFS由成千上百台廉价服务器组成、每个保存整个文件系统的部分数据。如果任意一台服务器出现硬件错误都会导致HDFS部分不可用，所以针对错误的快速检测和自动修复是HDFS框架需要解决核心问题。
1.2 流水访问
HDFS支持应用程序采用流式访问数据，更注重数据访问的吞吐量而不是数据访问的低延迟问题。
1.3 海量数据
存储在HDFS的数据量都是非常大的，一般都是几百G左右。HDFS支持大文件存储并且具有很高的数据带宽。一个HDFS集群需要控制数百个节点，保存几百万个文件。
1.4 简单一致性模型
简单一致性模型是指一个文件经过创建、写入和关闭之后不会在进行修改。也就是文件是一次写入多次读取，这样简化了数据一致性问题，也是提高数据访问吞吐量的一个基础。
1.5 移动计算而不是移动数据
当需要计算海量数据时，将海量数据传输到计算节点将在网络传输中消耗非常多资源和时间。HDFS因此提供了对应接口可以将计算移动到数据所在节点。
1.6 平台兼容性
HDFS需要兼容各种平台降低平台耦合性。
2.HDFS适用场景
- 由廉价大量服务器组建
- 批量访问
- 高吞吐量数据访问
- 大文件
3.HDFS不适用场景
- 随机访问
- 低延迟访问
- 小文件
三、HDFS架构图
1.架构图
HDFS采用master/slave架构。一个HDFS集群由一个Namenode和一定数量的Datanodes组成。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。
一个典型的部署场景是一台机器上只运行一个Namenode实例，而集群中的其它机器分别运行一个Datanode实例。这种架构并不排斥在一台机器上运行多个Datanode，只不过这样的情况比较少见。
2.Namenode
Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。
3.Datanode
Datanode一般是一个节点一个，负责管理它所在节点上的存储。Datanode负责处理文件系统客户端的读写请求，在Namenode的统一调度下进行数据块的创建、删除和复制。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上
四、HDFS数据存储
Namenode全权管理数据的存储，Namenode周期性的从集群中每个Datanode接受心跳信号和块状态报告。接收到心跳信号意味着DataNode节点工作正常，块状态报告包含该Datanode上的所有数据块列表。
1.数据块存储
HDFS是一个跨机器可靠的存储超大文件的集群。每个文件被划分为一系列的数据块存储，除了最后一个，所有数据块大小都是相同的。HDFS中的文件都是一次性写入的并且一个时刻只能有一个写入者。
2.副本机制
副本机制是HDFS容错、可靠性和性能的关键，可以指定文件的副本数量。HDFS采用一种为机架感知的策略来改进数据的可靠性、可用性和网络带宽的利用率。
五、元数据持久化
1.Namenode元数据
Namenode保存整个HDFS的元数据信息，这些数据都会被持久化到Fsimage文件和Editlog文件。
Fsimage文件是存放上次checkpoint生成的文件系统元数据。
EditLog 文件存放文件系统的操作日志，也就是用户对目录、文件的每个写操作（包括创建、删除、写入等）都会被记录到 Editlog 文件中。
2.元数据过程
2.1 Namenode启动，如果是第一次会创建Fsimage文件和Editlog文件。如果不是第一次启动，会从本地文件系统加载Fsimage文件和Editlog文件到内存，然后在内存中将两个文件内容进行合并。
2.2 客户端对元数据进行增删改请求
2.3 Namenode将操作记录到Editlog文件
2.4 Namenode将内存元数据更新
3.元数据checkpoint
文件系统的操作记录都会持久化到Editlog文件，随着系统运行会导致有大量的Editlog文件。hdfs会定期对Editlog文件进行日志合并，然后和内存中元数据一起写入到fsimage文件，这个过程就是checkpoint。
由于checkpoint过程会耗时比较长，如果在Active Namenode上执行checkpoint可能会影响文件的正常读写，因此checkpoint通常由Standby Namenode触发，其大概流程为：
3.1 Standby Namenoden向Active Namenode请求下载最新的一批editlog文件
3.2 Standby Namenoden完成editlog文件的下载后，执行所有这些editlog文件中的操作，并更新在内存中记录的元数据信息
3.3 Standby Namenoden将内存中的元数据信息按一定的格式保存到fsimage文件中
3.4 Standby Namenoden将生成的fsimage上传到ann中
3.5 Standby Namenoden和Active Namenode删除各自老的editlog文件和fsimage文件
总结
本文对Hadoop中的HDFS分布式文件系统的架构设计进行了解。hdfs采用常见的主从架构，由集中元数据存储Namenode和分散的数据存储Datanode节点组成，支持高可靠性高吞吐量的批量读取大文件海量数据。
参考
Apache HDFS文档: HDFS架构