这是我参与「第四届青训营 」笔记创作活动的第12天。 本文将以Apache HDFS为蓝本，重点介绍HDFS的相关概念及原理。
前言
-
认识Hadoop技术体系，理解“计算+存储”的程序应用逻辑
- 存储层：HDFS
- 调度层：YARN
- 计算框架：MapReduce。值得注意的是另外一个同属于Apache基金会的开源计算框架Apache Spark，当前业界的使用已经远超于MapReduce，尽管它不属于Hadoop项目，但是和Hadoop也有紧密关系。
认识非分布式与分布式存储系统
非分布式存储：在单机时代，将文件直接存储在服务部署的服务器上
- 直连存储（DAS） ：存储和数据直连，拓展性、灵活性差。
为了扩展，将文件和服务分离，通过网络连接
- 中心化存储（NAS、SAN） ：设备类型丰富，通过网络互连，具有一定的拓展性，但是受到控制器能力限制，拓展能力有限。同时，设备到了生命周期要进行更换，数据迁移需要耗费大量的时间和精力。
- 单机文件系统非常普遍，从Windows NTFS到Linux的Ext4等，分布式文件系统是单机文件的延伸，概念术语是相通的，比如目录、文件、目录树等，常见的如Windows NTFS，Linux的Ext4，虽然不同的操作系统和实现，但是本质都是一样的，解决相同的问题。
分布式存储： 通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。本质上扩展、延伸了单机文件系统，提供了大容量、高可靠、低成本等功能特性；实现上一般也更为复杂。
- 分布式存储系统，了解分布式存储系统的分类，理解不同存储系统的使用场景。直观的区别是用户使用方式，本质是针对不同的使用场景提供高效合理的系统。
- 对象存储：例如AWS的S3，阿里云的OSS，开源的Minio。
- 块存储：例如AWS的EBS，开源社区也有Ceph等。
- 文件系统：HDFS、GlusterFS、CubeFS等
- 数据库：KV数据库比如Cassandra，关系型数据库如TiDB、OceanBase等
HDFS 介绍
目前主流的分布式文件系统有：GFS、HDFS、Ceph、Lustre、MogileFS、MooseFS、FastDFS、TFS、GridFS等。
HDFS（Hadoop Distributed File System） 是 Hadoop 项目的一个子项目。是 Hadoop 的核心组件之一， Hadoop 非常适于存储大型数据 (比如 TB 和 PB)，其就是使用 HDFS 作为存储系统. HDFS 使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。
- HDFS功能特性：需要注意HDFS尽管是一个文件系统，但是它没有完整实现POSIX文件系统规范。
-
HDFS演示环境：展示一个完整的HDFS服务的部署结构和基本的基本的交互方式，通过简单的交互读写操作开始了解学习HDFS。
- 节点类型：ZooKeeper/JournalNode/NameNode/DataNode
- HDFS 命令行交互
- HDFS Web UI
HDFS 架构原理
- HDFS采用Master/Slave架构。
- 一个HDFS集群包含一个单独的NameNode和多个DataNode。
- NameNode作为Master服务，它负责管理文件系统的命名空间和客户端对文件的访问。NameNode会保存文件系统的具体信息，包括文件信息、文件被分割成具体block块的信息、以及每一个block块归属的DataNode的信息。对于整个集群来说，HDFS通过NameNode对用户提供了一个单一的命名空间。
- DataNode作为Slave服务，在集群中可以存在多个。通常每一个DataNode都对应于一个物理节点。DataNode负责管理节点上它们拥有的存储，它将存储划分为多个block块，管理block块信息，同时周期性的将其所有的block块信息发送给NameNode。
下图为HDFS系统架构图，主要有三个角色，Client、NameNode、DataNode。
HDFS组件
- Client/SDK：读写操作的发起点，HDFS很多读写逻辑都是在SDK中实现的。
- NameNode：元数据节点，是HDFS的中枢节点，也是服务的入口。
- DataNode：数据节点，存放实际用户数据。
HDFS的一些关键元素
- Block：将文件分块，通常为64M。
- NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间。保存整个文件系统的目录信息、文件信息及分块信息，由唯一一台主机专门保存。
- SecondaryNameNode：是一个小弟，分担大哥NameNode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给NameNode。（热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。）
- DataNode：是Slave节点，奴隶，干活的。负责存储Client发来的数据块block；执行数据块的读写操作。
- fsimage：元数据镜像文件（文件系统的目录树）
- EditLog：元数据的操作日志（针对文件系统做的修改操作记录）
关键设计
-
NameNode目录树设计，重点理解EditLog的设计，可类比关系型数据库中的Transaction Log概念。
- 仅在内存中修改：fsimage
- 需要立即保存到硬盘：EditLog
-
NameNode数据放置：数据分散在各个节点上，如何定位找到它们？
- 文件和数据块的映射关系
- 数据块的放置分布策略
-
DataNode设计：数据如何落盘存放？
- 数据块路径
- 启动扫盘获得本机文件块列表
-
Client读写链路的异常处理
- Server端异常
- Client端异常
- 慢节点
-
控制面建设：保障系统稳定运行
- HouseKeeping组件：比如Balancer，Mover等， 这些组件不运行不会马上影响读写操作，但是长时间会积累系统性问题，例如读写不均衡导致IO热点等。
- 可观测性设施：比如系统指标监控设施等，帮助快速发现定位问题。
- 运维体系建设：从最基本的命令行手工操作，脚本自动化再到完善的运维平台。
-
HDFS 数据备份HDFS被设计成一个可以在大集群中、跨机器、可靠的存储海量数据的框架。它将所有文件存储成block块组成的序列，除了最后一个block块，所有的block块大小都是一样的。
-
HDFS中的文件默认规则是write one（一次写、多次读）的，并且严格要求在任何时候只有一个writer。
-
NameNode全权管理数据块的复制，它周期性地从集群中的每个DataNode接受心跳信号和块状态报告（BlockReport）。接收到心跳信号以为该DataNode工作正常，块状态报告包含了一个该DataNode上所有数据块的列表。
-
NameNode内存中存储的是=fsimage+editlog。SecondaryNameNode负责定时（默认1小时）从NameNode上，获取fsimage和edits来进行合并，然后再发送给NameNode。减少NameNode的工作量。
分布式文件系统的对比
1、整体对比
| 文件系统 | 开发者 | 开发语言 | 开源协议 | 易用性 | 适用场景 | 特性 | 缺点 |
|---|---|---|---|---|---|---|---|
| GFS | 不开源 | ||||||
| HDFS | Apache | Java | Apache | 安装简单，官方文档专业化 | 存储非常大的文件 | 大数据批量读写，吞吐量高；一次写入，多次读取，顺序读写 | 难以满足毫秒级别的低延时数据访问；不支持多用户并发写相同文件；不适用于大量小文件 |
| Ceph | 加州大学圣克鲁兹分校Sage Weil | C++ | LGPL | 安装简单，官方文档专业化 | 单集群的大中小文件 | 分布式，没有单点依赖，用C编写，性能较好 | 基于不成熟的btrfs，自身也不够成熟稳定，不推荐在生产环境使用 |
| TFS | Alibaba | C++ | GPL V2 | 安装复杂，官方文档少 | 跨集群的小文件 | 针对小文件量身定做，随机IO性能比较高；实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；支持主备热倒换，提升系统的可用性；支持主从集群部署，从集群主要提供读/备功能 | 不适合大文件的存储；不支持POSIX，通用性较低；不支持自定义目录结构与文件权限控制；通过API下载，存在单点的性能瓶颈；官方文档少，学习成本高 |
| Lustre | SUN | C | GPL | 复杂，而且严重依赖内核，需要重新编译内核 | 大文件读写 | 企业级产品，非常庞大，对内核和ext3深度依赖 | |
| MooseFS | Core Sp. z o.o. | C | GPL V3 | 安装简单，官方文档多，且提供Web界面的方式进行管理与监控 | 大量小文件读写 | 比较轻量级，用perl编写，国内用的人比较多 | 对master服务器有单点依赖，性能相对较差 |
| MogileFS | Danga Interactive | Perl | GPL | 主要用在web领域处理海量小图片 | key-value型元文件系统；效率相比mooseFS高很多 | 不支持FUSE | |
| FastDFS | 国内开发者余庆 | C | GPL V3 | 安装简单，社区相对活跃 | 单集群的中小文件 | 系统无需支持POSIX，降低了系统的复杂度，处理效率更高；实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；支持主从文件，支持自定义扩展名；主备Tracker服务，增强系统的可用性 | 不支持断点续传，不适合大文件存储；不支持POSIX，通用性较低；对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略；同步机制不支持文件正确性校验；通过API下载，存在单点的性能瓶颈 |
| GlusterFS | Z RESEARCH | C | GPL V3 | 安装简单，官方文档专业化 | 适合大文件，小文件性能还存在很大优化空间 | 无元数据服务器，堆栈式架构(基本功能模块可以进行堆栈式组合，实现强大功能)，具有线性横向扩展能力；比mooseFS庞大 | 由于没有元数据服务器，因此增加了客户端的负载，占用相当的CPU和内存；但遍历文件目录时，则实现较为复杂和低效，需要搜索所有的存储节点，不建议使用较深的路径 |
| GridFS | MongoDB | C++ | 安装简单 | 通常用来处理大文件（超过16M） | 可以访问部分文件，而不用向内存中加载全部文件，从而保持高性能；文件和元数据自动同步 |
2、 特性对比
| 文件系统 | 数据存储方式 | 集群节点通讯协议 | 专用元数据存储点 | 在线扩容 | 冗余备份 | 单点故障 | 跨集群同步 | FUSE挂载 | 访问接口 |
|---|---|---|---|---|---|---|---|---|---|
| HDFS | 文件 | 私有协议（TCP） | 占用MDS | 支持 | 存在 | 不支持 | 支持 | 不支持POSIX | |
| Ceph | 对象/文件/块 | 私有协议（TCP） | 占用MDS | 支持 | 支持 | 存在 | 不支持 | 支持 | POSIX |
| Lustre | 对象 | 私有协议（TCP）/ RDAM（远程直接访问内存） | 双MDS | 支持 | 不支持 | 存在 | 未知 | 支持 | POSIX/MPI |
| MooseFS | 块 | 私有协议（TCP） | 占用MFS | 支持 | 支持 | 存在 | 不支持 | 支持 | POSIX |
| MogileFS | 文件 | HTTP | 占用DB | 支持 | 不支持 | 存在 | 不支持 | 不支持 | 不支持POSIX |
| FastDFS | 文件/块 | 私有协议（TCP） | 无 | 支持 | 支持 | 不存在 | 部分支持 | 不支持 | 不支持POSIX |
| GlusterFS | 文件/块 | 私有协议（TCP）/RDAM（远程直接访问内存） | 无 | 支持 | 支持 | 不存在 | 支持 | 支持 | POSIX |
| TFS | 文件 | 私有协议（TCP） | 占用NS | 支持 | 支持 | 存在 | 支持 | 未知 | 不支持POSIX |
什么是POSIX？
POSIX表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），也就是Unix下应用程序共同遵循的一种规范。支持POSIX的应用程序意味着在各个Unix系统间提供了跨平台运行的支持。
选型参考
- 适合做通用文件系统的有：Ceph，Lustre，MooseFS，GlusterFS；
- 适合做小文件存储的文件系统有：Ceph，MooseFS，MogileFS，FastDFS，TFS；
- 适合做大文件存储的文件系统有：HDFS，Ceph，Lustre，GlusterFS，GridFS；
- 轻量级文件系统有：MooseFS，FastDFS；
- 简单易用，用户数量活跃的文件系统有：MooseFS，MogileFS，FastDFS，GlusterFS；
- 支持FUSE挂载的文件系统有：HDFS，Ceph，Lustre，MooseFS，GlusterFS。
