分布式文件系统
从块/文件/对象三种存储类型,到 GFS 与 HDFS 架构原理、读写流程、容错机制,再到对象存储 S3/MinIO 与 Ceph 统一存储。
🎯学习目标
- 区分块存储、文件存储、对象存储三种类型及适用场景;
- 掌握 GFS 架构(Master/ChunkServer/Client)、64MB Chunk 与控制流/数据流分离;
- 掌握 HDFS 架构(NameNode/DataNode/Block)、读写流程、副本策略与机架感知;
- 理解 HDFS 容错:心跳、HA 高可用、Federation、纠删码 EC;
- 理解对象存储(S3/MinIO)与 Ceph 统一存储(RADOS/CRUSH/三大接口)。
1三种存储类型:块 / 文件 / 对象
块存储
划分为固定大小块,裸设备级接口(如 /dev/sda)。代表 AWS EBS、Ceph RBD。
文件存储
层级树状目录,POSIX 路径访问(/data/x.txt)。代表 NFS、HDFS、CephFS。
对象存储
扁平命名空间,HTTP REST API(GET /bucket/key)。代表 AWS S3、MinIO、OSS。
| 维度 | 块存储 | 文件存储 | 对象存储 |
|---|---|---|---|
| 抽象层级 | 最低(裸盘) | 中(树状目录) | 最高(扁平桶) |
| 访问接口 | SCSI/iSCSI | POSIX/NFS/SMB | HTTP REST API |
| 性能 | 极低延迟、高 IOPS | 较高吞吐、中等延迟 | 超高吞吐、延迟较高 |
| 扩展能力 | 较弱(SAN 受限) | 中等(元数据受限) | 极强(EB 级) |
| 修改方式 | 支持随机修改 | 支持随机修改 | 只能整体覆盖替换 |
| 适用场景 | 数据库、虚拟机系统盘 | 多机共享、办公文档 | 海量图片视频、冷数据归档 |
2Google File System ⭐(核心考点)
2003 年 Google 的存储挑战:需存储 PB 级网页索引;用廉价商用服务器(组件故障是常态);负载特征是大文件为主(GB 级)、追加写入为主、随机修改极少;高吞吐率比低延迟更重要。
GFS 四大核心假设
- 系统由大量廉价易损节点组成(需自我监控、容错、自动恢复);
- 主要存储大文件(数百万个 100MB 以上对象,无需优化 KB 级小文件);
- 读写模式固定(大规模流式读取、少量随机读取,主要顺序追加);
- 并发追加语义(多客户端并发追加同一文件,需高效与一致)。
GFS 三大组件职责
| 组件 | 职责 |
|---|---|
| Master | 唯一主节点,管理全部元数据(目录树、文件→Chunk 映射、Chunk 位置) |
| ChunkServer | 存储实际数据块 Chunk,默认 64MB,通常保存 3 个副本 |
| Client | 先向 Master 询问元数据,随后直接与 ChunkServer 交互数据 |
3GFS 追加写入流程
为什么关注追加(Record Append)? GFS 专门优化追加写入,允许数百客户端并发向同一文件追加,无需加分布式锁,极高吞吐,适合日志场景。
流水线(Pipeline)机制
- 授权主副本:Master 在 3 个副本中指定一个为 Primary(主),负责确定写入顺序;
- 数据链式推送:Client 不向 3 副本同时发,而是发给最近的副本 A,A 推给 B,B 推给 C(充分利用全双工带宽);
- 执行写入顺序:数据推送完成后 Client 通知 Primary 执行,Primary 定好顺序后通知所有 Secondary 按相同顺序落盘。
4HDFS 架构
HDFS(Hadoop Distributed File System)是 Apache Hadoop 大数据生态的底层基石,设计深度借鉴 GFS 论文,用 Java 实现。
| 设计目标 | 放弃的特性 |
|---|---|
| 超大文件处理(TB/PB 级) | 不适合海量小文件 |
| 流式访问(一次写入多次读取) | 不支持低延迟随机访问 |
| 高容错低成本(普通硬件) | 不支持随机修改(仅追加) |
| 计算向数据移动(数据本地性) | 计算与存储分离架构 |
三大组件
| 组件 | 职责 |
|---|---|
| NameNode(大脑) | 维护文件系统树、管理元数据;全内存运行,靠 FsImage(命名空间镜像)+ EditLog(编辑日志)持久化。1GB 内存约管 100 万 Block,惧怕海量小文件 |
| DataNode(躯干) | 实际存储数据,以 Block(默认 128MB)为单位;每 3 秒发心跳,每隔几小时发全量块报告 |
| Secondary NameNode(秘书) | 不是热备份!仅定期合并 EditLog 与 FsImage(Checkpoint),防日志膨胀 |
5HDFS 读写流程与机架感知 ⭐
副本放置策略(Rack Awareness)
HDFS 默认 3 副本机制,放置算法是极佳的工程折中:
- 副本1:放在客户端所在 DataNode(集群外则随机选低负载节点)——保证写入速度;
- 副本2:放在不同机架的某 DataNode——防单机架断电/交换机故障导致全损;
- 副本3:放在与副本2相同机架的另一 DataNode——避免跨机架传输过多占用核心带宽。
数据本地性优先的读取
客户端读取时 NameNode 返回 Block 所在 DataNode 列表,按网络拓扑距离排序:
Node Local
同节点直读本地磁盘,速度最快。
Rack Local
同机架交换机读取,速度次之。
Off Rack
跨核心交换机读取,最耗带宽。
流水线写入与 Packet 传输
客户端将数据切成多个 64KB 的 Packet,在 Pipeline 中"排队流转":Client→DN1→DN2→DN3。确认机制:只要至少有一个副本写入成功,HDFS 就认为写入成功,剩余副本由 NameNode 后续异步补充。
6HDFS HA / Federation / 纠删码
单点故障与 HA 高可用
Hadoop 1.x 时代 NameNode 是单点故障(SPOF),宕机则整个 PB 级集群瘫痪。HA 采用 Active/Standby 双机热备:
- Active NameNode:提供所有读写服务;
- Standby NameNode:热备份,时刻准备接管;
- JournalNode 集群:取代本地硬盘,实时同步 EditLog(基于 Paxos 变体,过半写成功);
- ZooKeeper 与 ZKFC:自动脑裂保护与故障切换。ZKFC 监控 NN 心跳,Active 无响应则发起选举将 Standby 推举为新 Active。
Federation 与纠删码 EC
| 机制 | 解决的问题 | 方案 |
|---|---|---|
| Federation 联邦 | 单 NameNode 内存天花板(亿级文件触顶) | 引入多个独立 NameNode,各管独立 Namespace(/user→NN1, /data→NN2),底层共享 DataNode 池 |
| 纠删码 EC | 3 副本存储开销高达 200% | 类似 RAID 5/6,数据分片+校验块。RS-6-3:6 数据+3 校验=9 块,任丢 3 块可恢复,开销从 200% 降至 50%,适合冷数据 |
7对象存储与 Ceph 统一存储
对象存储核心要素
对象存储采用扁平命名空间(无目录层级),数据以对象存储在桶(Bucket)中:
| 要素 | 说明 |
|---|---|
| Key(对象键) | 全局唯一标识符,用户眼中的"文件路径" |
| Value(数据体) | 不透明二进制块,最大可达 5TB,只能整体覆盖替换 |
| Metadata(元数据) | 与数据强绑定,可自定义标签,驱动检索与生命周期管理 |
Amazon S3(2006)确立云存储行业标准:无限扩展、11 个 9 持久性(99.999999999%)、生命周期分层(Standard→IA→Glacier→Intelligent-Tiering 自动降级降本)。预签名 URL(Presigned URL)可签发带时效的私密下载直链,后端无需中转流量。
MinIO(2014):极致轻量(~50MB 单二进制零依赖)、100% 兼容 S3 API、Go+SIMD 集群吞吐 GB/s、原生纠删码防 Bit Rot,是 Kubernetes 时代云原生存储利器。
import boto3
s3 = boto3.client('s3', endpoint_url='http://localhost:9000',
aws_access_key_id='admin', aws_secret_access_key='password123')
s3.put_object(Bucket='demo-bucket', Key='config/app.json',
Body=b'{"version":"1.0"}', Metadata={'author':'dai'})
url = s3.generate_presigned_url('get_object',
Params={'Bucket':'demo-bucket','Key':'config/app.json'}, ExpiresIn=3600)
Ceph 统一存储
Ceph 核心愿景 "All in One":底层构建可靠分布式对象存储引擎 RADOS,上层模拟出块(RBD)、文件(CephFS)、对象(RGW)三种标准接口。一套硬件满足所有需求。
| 守护进程 | 职责 |
|---|---|
| OSD | 真正干活者,一块硬盘对应一个 OSD 进程,负责存储/复制/恢复/心跳 |
| MON(Monitor) | 维护集群拓扑图状态机,必须奇数部署(Paxos 保强一致) |
| MDS | 仅 CephFS 需要,处理目录树元数据,动态子树分区 |
⭐重点例题
选型:海量小文件/图片应改用对象存储(S3/MinIO,扁平命名空间、EB 级扩展);若必须用 HDFS 可先合并为大文件(HAR/SequenceFile)。
🎯自测(点击展开)
块/文件/对象存储分别适合什么场景?
GFS 的三大创新点是什么?
HDFS 的 Block 默认多大?为什么这么大?
Secondary NameNode 是热备份吗?
HDFS 副本2 为什么放在不同机架?
Ceph 的 CRUSH 算法解决了什么问题?
📝强化题库
选择题点选即时判分;填空题输入后"检查"或"显示答案"。