🎓 总站 🏠 本课目录 01 概论 02 虚拟化 03 云原生 04 K8s基础 05 K8s进阶 06 消息队列 07 分布式存储 08 分布式文件系统 09 并行编程 10 Spark
云计算技术 · 第8讲

分布式文件系统

从块/文件/对象三种存储类型,到 GFS 与 HDFS 架构原理、读写流程、容错机制,再到对象存储 S3/MinIO 与 Ceph 统一存储。

📚 学习进度
0%

🎯学习目标

  • 区分块存储、文件存储、对象存储三种类型及适用场景;
  • 掌握 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/iSCSIPOSIX/NFS/SMBHTTP REST API
性能极低延迟、高 IOPS较高吞吐、中等延迟超高吞吐、延迟较高
扩展能力较弱(SAN 受限)中等(元数据受限)极强(EB 级)
修改方式支持随机修改支持随机修改只能整体覆盖替换
适用场景数据库、虚拟机系统盘多机共享、办公文档海量图片视频、冷数据归档
💡 选型口诀跑系统与数据库选块存储,多机共享读写选文件存储,海量多媒体与静态资源选对象存储

2Google File System ⭐(核心考点)

2003 年 Google 的存储挑战:需存储 PB 级网页索引;用廉价商用服务器(组件故障是常态);负载特征是大文件为主(GB 级)、追加写入为主、随机修改极少高吞吐率比低延迟更重要

GFS 四大核心假设

  • 系统由大量廉价易损节点组成(需自我监控、容错、自动恢复);
  • 主要存储大文件(数百万个 100MB 以上对象,无需优化 KB 级小文件);
  • 读写模式固定(大规模流式读取、少量随机读取,主要顺序追加);
  • 并发追加语义(多客户端并发追加同一文件,需高效与一致)。

GFS 三大组件职责

🧠 Master(唯一主节点)管理元数据:目录树/Chunk映射/位置 🖥 Client 💽 ChunkServer1 💽 ChunkServer2 💽 ChunkServer3 ①问元数据(控制流) ②直连读写数据(数据流)
图1 · GFS 架构:控制流(找 Master 问路)与数据流(直连 ChunkServer)分离
组件职责
Master唯一主节点,管理全部元数据(目录树、文件→Chunk 映射、Chunk 位置)
ChunkServer存储实际数据块 Chunk,默认 64MB,通常保存 3 个副本
Client先向 Master 询问元数据,随后直接与 ChunkServer 交互数据
⭐ GFS 三大创新点(必考)单一 Master:简化架构、避免复杂一致性协议,靠内存映射+操作日志解决性能;② 控制流与数据流分离:数据传输绝不经 Master,避免其成网络瓶颈;③ 大 Chunk(64MB):远大于 OS 的 4KB,极大减少 Master 元数据压力。

3GFS 追加写入流程

为什么关注追加(Record Append)? GFS 专门优化追加写入,允许数百客户端并发向同一文件追加,无需加分布式锁,极高吞吐,适合日志场景。

流水线(Pipeline)机制

  • 授权主副本:Master 在 3 个副本中指定一个为 Primary(主),负责确定写入顺序;
  • 数据链式推送:Client 不向 3 副本同时发,而是发给最近的副本 A,A 推给 B,B 推给 C(充分利用全双工带宽);
  • 执行写入顺序:数据推送完成后 Client 通知 Primary 执行,Primary 定好顺序后通知所有 Secondary 按相同顺序落盘。
⚠ 一致性妥协GFS 采用至少一次(At Least Once)语义不保证副本字节级完全一致,可能存在重复/废弃数据块,交由上层应用处理。秉持"够用就好"哲学——为极高并发吞吐,放弃完美强一致。

4HDFS 架构

HDFS(Hadoop Distributed File System)是 Apache Hadoop 大数据生态的底层基石,设计深度借鉴 GFS 论文,用 Java 实现。

设计目标放弃的特性
超大文件处理(TB/PB 级)不适合海量小文件
流式访问(一次写入多次读取)不支持低延迟随机访问
高容错低成本(普通硬件)不支持随机修改(仅追加)
计算向数据移动(数据本地性)计算与存储分离架构
💡 计算向数据移动传统是把数据读入内存计算(耗网络带宽);HDFS 配合 MapReduce/Spark,把计算程序调度到数据所在 DataNode 运行,实现网络零拷贝。

三大组件

组件职责
NameNode(大脑)维护文件系统树、管理元数据;全内存运行,靠 FsImage(命名空间镜像)+ EditLog(编辑日志)持久化。1GB 内存约管 100 万 Block,惧怕海量小文件
DataNode(躯干)实际存储数据,以 Block(默认 128MB)为单位;每 3 秒发心跳,每隔几小时发全量块报告
Secondary NameNode(秘书)不是热备份!仅定期合并 EditLog 与 FsImage(Checkpoint),防日志膨胀
⭐ 为什么 HDFS 用大 Block(128MB)?最小化寻道开销:寻道 10ms、传输 100MB/s,要让寻道占比 <1%,块至少 100MB;② 减少元数据:极大减轻 NameNode 内存负担。这也是 HDFS 惧怕海量小文件的原因。

5HDFS 读写流程与机架感知 ⭐

副本放置策略(Rack Awareness)

HDFS 默认 3 副本机制,放置算法是极佳的工程折中:

  • 副本1:放在客户端所在 DataNode(集群外则随机选低负载节点)——保证写入速度;
  • 副本2:放在不同机架的某 DataNode——防单机架断电/交换机故障导致全损;
  • 副本3:放在与副本2相同机架的另一 DataNode——避免跨机架传输过多占用核心带宽。

数据本地性优先的读取

客户端读取时 NameNode 返回 Block 所在 DataNode 列表,按网络拓扑距离排序:

🚀

Node Local

同节点直读本地磁盘,速度最快。

Rack Local

同机架交换机读取,速度次之。

🐢

Off Rack

跨核心交换机读取,最耗带宽。

流水线写入与 Packet 传输

Client DN 1 DN 2 DN 3 数据切为 64KB Packet → 流水线推送 → 至少一个副本确认即返回成功
图2 · HDFS 流水线写入: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 池
纠删码 EC3 副本存储开销高达 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)三种标准接口。一套硬件满足所有需求。

RBD 块设备 CephFS 文件 RGW 对象 RADOS — 可靠自主分布式对象存储统一底座 · 无单点 · 自动修复
图3 · Ceph:RADOS 统一底座上提供 RBD/CephFS/RGW 三大接口
守护进程职责
OSD真正干活者,一块硬盘对应一个 OSD 进程,负责存储/复制/恢复/心跳
MON(Monitor)维护集群拓扑图状态机,必须奇数部署(Paxos 保强一致)
MDS仅 CephFS 需要,处理目录树元数据,动态子树分区
⭐ CRUSH 算法(核心)HDFS 需 NameNode 内存记录"每个 Block 在哪台机器",EB 级会撑爆。CRUSH(Controlled Replication Under Scalable Hashing)让客户端不查任何表、仅靠本地计算就算出数据存哪块硬盘:① PG_ID=Hash(Object)%PG_Num;② OSD_List=CRUSH(PG_ID, Map, Rule);③ 直连 OSD。特性:确定性、拓扑感知(故障域隔离)、权重控制(异构硬盘)。

重点例题

例题1:20 亿张 50KB 头像存入 HDFS 会发生什么灾难?如何选型? 分析:HDFS 的 NameNode 全内存管理元数据,1GB 内存约管 100 万 Block。20 亿个小文件(每个至少占一个 Block 的元数据)会瞬间撑爆 NameNode 内存,导致集群无法工作——这就是 HDFS"惧怕海量小文件"。
选型:海量小文件/图片应改用对象存储(S3/MinIO,扁平命名空间、EB 级扩展);若必须用 HDFS 可先合并为大文件(HAR/SequenceFile)。
例题2:GFS 为何敢放弃严格一致性?上层如何配合? 解答:GFS 面向大文件追加写入、高吞吐优先的搜索引擎场景,强一致需加锁/同步会严重拖慢数百客户端的并发追加。GFS 采用至少一次语义,不保证副本字节级一致,可能有重复/废弃块。上层应用通过记录级校验和(checksum)、唯一标识去重、跳过填充块来容忍并处理这些不一致,换取极高吞吐。
例题3:HDFS 3 副本如何放置才能兼顾速度与容灾? 解答:副本1 放客户端所在节点(保证写入速度);副本2 放不同机架(防整机架断电/交换机故障全损);副本3 放与副本2 同机架的另一节点(避免跨机架传输过多占核心交换机带宽)。这一策略在容灾(跨机架)与带宽节省(同机架)之间做了精妙折中。

🎯自测(点击展开)

块/文件/对象存储分别适合什么场景?
块存储→数据库/虚拟机系统盘;文件存储→多机共享读写;对象存储→海量多媒体与静态资源、冷数据归档。
GFS 的三大创新点是什么?
单一 Master 简化架构;控制流与数据流分离(数据不经 Master);大 Chunk(64MB)减少元数据压力。
HDFS 的 Block 默认多大?为什么这么大?
默认 128MB。为最小化寻道时间占比(<1%)并减少 NameNode 元数据负担。
Secondary NameNode 是热备份吗?
不是!它仅定期合并 EditLog 与 FsImage(Checkpoint),无法在 Active NN 宕机时接管。真正热备是 HA 中的 Standby NN。
HDFS 副本2 为什么放在不同机架?
防止单机架断电或交换机故障导致数据全损,提高容灾能力。
Ceph 的 CRUSH 算法解决了什么问题?
客户端无需查中心元数据表,仅靠本地计算即可定位数据所在 OSD,避免了 NameNode 式的内存与寻址瓶颈。

📝强化题库

选择题点选即时判分;填空题输入后"检查"或"显示答案"。

已答 0/0答对 0正确率
已答 0/0答对 0