分布式存储入门 —— Ceph / HDFS / 对象存储

数据中心规模上去之后，单机 RAID 和 SAN 都扛不住——主流转向分布式存储。本文讲三类主流分布式存储（HDFS、Ceph、对象存储）的核心机制，以及它们和传统集中式存储的本质差别。

为什么需要分布式存储

传统 SAN：

2-4 个控制器 + 一个机柜的盘 = 一个孤岛
扩容靠加柜，性能瓶颈在控制器
单点故障域大
2-10 PB 是单台 SAN 上限

分布式存储：

1
2
3

N 台普通服务器 + 每台几十颗盘
N 越大容量越大、性能越高、容错越强
线性扩展到 EB 级

graph TB
  subgraph 传统SAN
    C1[控制器 1]
    C2[控制器 2]
    C1 --- D1[盘 × 100]
    C2 --- D1
  end
  subgraph 分布式
    N1[节点 1
盘 × 24]
    N2[节点 2
盘 × 24]
    N3[节点 3
盘 × 24]
    NX[... × 数十/数百]
    N1 -.- N2 -.- N3 -.- NX
  end

分布式存储的三大核心问题

graph TB
  P1[数据放哪里?
分片 / 哈希 / 一致性哈希]
  P2[一份还是多份?
多副本 / 纠删码]
  P3[出错怎么办?
心跳 / 选主 / 一致性]

每个分布式存储系统都在用自己的方式回答这三个问题。

数据放置：三种思路

1. 主从 + 元数据服务器（HDFS 风格）

1 2	`NameNode 知道：每个文件块放在哪几个 DataNode 上 Client 先问 NameNode → 得到位置 → 直接和 DataNode 读写`

优点：策略灵活
缺点：NameNode 是潜在瓶颈（HDFS 后期 federation / HA）

2. 算法决定位置（Ceph 风格）

1 2	`对象 → 哈希到 PG（placement group）→ CRUSH 算法决定 PG 在哪些 OSD 没有"中心元数据"，每个客户端按算法自行计算`

优点：无中心、无瓶颈
缺点：调整布局规则要全集群配合

3. 一致性哈希 / Ring（对象存储风格）

1
2
3

对象 key 哈希到环上
找环上下一个 N 个节点 = 副本位置
节点增减时只影响相邻

优点：扩展简单
缺点：故障域控制不如 CRUSH 精细

冗余：副本 vs 纠删码

多副本（Replication）

1 2	`一份原始 + N-1 份副本 3 副本是默认，最常见`


容量利用	1/N（3 副本 = 33%）
容错	任意 N-1 节点
写性能	N 份写入
重建成本	直接复制，最快

纠删码（Erasure Coding，EC）

源自 Reed-Solomon 编码，原理类似 RAID 6 的扩展：

EC(K+M)：
  K = 数据块数（典型 4 / 6 / 8 / 10）
  M = 校验块数（典型 2 / 3 / 4）
  K+M 块分散到不同节点
  任意 K 块就能恢复全部数据

例 EC(8+4)：

8 数据块 + 4 校验块 = 12 个块
任意 4 块丢失都能重建
容量利用 = 8/12 = 67%（比 3 副本的 33% 高一倍）
重建代价 = 读 8 块 + 计算

	3 副本	EC(8+4)
容量利用	33%	67%
容错	2	4
写性能	写 3 份	写 12 份（小 IO 严重放大）
重建成本	复制 1 份	读 8 块 + 计算
适合	热数据	冷数据 / 大块

EC 把 33% 的容量利用率拉到 67-80%，对超大规模数据中心是真金白银。

代价：

小写性能差（不能把单个 4K 写映射到 12 块）
重建消耗带宽
计算开销（CPU 或专用硬件）

行业普遍做法：热数据用 3 副本，冷数据用 EC——按温度分层。

HDFS：Hadoop 时代的”先驱”

graph TB
  subgraph CLIENT
    HC[HDFS Client]
  end
  subgraph META
    NN[NameNode
元数据]
    SN[Secondary NN
checkpoint]
  end
  subgraph DATA
    DN1[DataNode 1
本地盘]
    DN2[DataNode 2]
    DN3[DataNode 3]
    DNX[...]
  end
  HC -- "1. 询问位置" --> NN
  HC -- "2. 直接读写" --> DN1
  HC --> DN2
  HC --> DN3
  DN1 -- "心跳 / 块报告" --> NN
  DN2 -.- NN
  DN3 -.- NN

特点：

块大小 128 MB 起（适合大文件、批处理）
追加写 + 一次写多次读（不支持随机写）
3 副本为默认（机架感知）
大数据生态原生（HDFS + Yarn + MapReduce/Spark）

适用：批量分析、Hive/Spark 数据湖、AI 训练大数据集。

不适用：小文件多、随机写、低延迟。

待补充：HDFS 在你公司的实际使用情况，以及是否已迁移到对象存储。

Ceph：通用分布式存储的”瑞士军刀”

graph TB
  subgraph CEPH["Ceph 集群"]
    MON[Monitor × 3-7
集群状态]
    MGR[Manager
监控/可视]
    MDS[MDS
仅 CephFS 用]
    
    OSD1[OSD 1
1 盘 1 OSD]
    OSD2[OSD 2]
    OSDx[... × N]
  end
  C1[RBD
块] -. RADOS .-> CEPH
  C2[CephFS
文件] -. RADOS .-> CEPH
  C3[RGW
S3 / Swift] -. RADOS .-> CEPH

Ceph 用一套底层（RADOS）支持三种接口：

接口	用法	应用
RBD	块设备	虚拟化、容器持久卷
CephFS	POSIX 文件系统	文件共享
RGW	S3 / Swift 对象	对象存储

CRUSH 算法是 Ceph 的精髓——没有中心元数据，客户端按规则自己算位置：

1
2
3

对象 → hash → PG（placement group）
PG → CRUSH 规则 → OSD 列表
客户端拿到列表后直接读写

CRUSH 规则可以表达”分布到不同机架 / 不同机房 / 不同电源域”——故障域设计非常灵活。

Ceph 的痛点：

学习曲线陡（架构复杂、参数多）
写延迟相对高（RBD 数百微秒级）
大集群运维需要专门团队

但作为开源、统一、灵活的方案，Ceph 在私有云、超算、混合云非常普遍。

对象存储：S3 引爆的标准

S3（Amazon Simple Storage Service）2006 年推出，对象存储成了云时代的”事实标准”。

对象 = key + value + metadata
key 是字符串路径（"folder/sub/object.bin"）
value 是字节流（任意大小）
metadata 是键值对

特点：

HTTP/HTTPS 协议 —— 跨网络访问
扁平命名空间（没有真正的”目录”，只是 key 前缀）
不可修改（要改就重新上传整对象）
强 / 最终一致性 —— S3 现在是强一致
EB 级容量 —— 每桶可装无限多对象

API 几个核心动词：

PUT /bucket/object        上传
GET /bucket/object        下载
DELETE /bucket/object     删除
LIST /bucket?prefix=...   列举

兼容 S3 API 的实现：

公有云：AWS S3, 阿里 OSS, 腾讯 COS, Azure Blob (S3 兼容)
开源：Ceph RGW, MinIO, SeaweedFS
专用：Backblaze B2, Wasabi, Cloudflare R2
国内商业：浪潮、华为 OBS、深信服等

应用场景：

数据湖底座（Iceberg、Hudi、Delta Lake 都跑在 S3 上）
AI 训练数据集
备份和归档
CDN 源站
容器镜像仓库后端

对象存储是当前数据中心存储的事实底座。

三类对比

	HDFS	Ceph	S3 对象
接口	HDFS API / WebHDFS	RBD / CephFS / S3	S3 / Swift
文件特性	大文件、追加写	块/文件/对象	不可改对象
元数据	中心 NameNode	算法（CRUSH）	哈希环 / 平面
默认冗余	3 副本	3 副本 / EC	EC（云上）/ 副本（私有）
强一致	写时一致	强一致	S3 强一致 / 自建按选
典型容量	PB	PB	EB
主战场	大数据分析	私有云	云原生数据

CAP 与一致性取舍

分布式存储不能同时满足：

graph TB
  C[Consistency 一致性]
  A[Availability 可用性]
  P[Partition tolerance 分区容错]
  Note["在网络分区时，
只能保证 C 或 A 之一"]
  C --- Note
  A --- Note
  P --- Note

实际取舍：

系统	取向	说明
HDFS	CP	强一致，写期间不可写其他副本
Ceph	CP	强一致
早期 S3	AP	最终一致
现 S3（2020+）	CP	已切换到强一致
Cassandra/Dynamo	AP（可调）	最终一致或 quorum 强一致
etcd / ZooKeeper	CP	选主 + 共识

数据持久性 (Durability)

云对象存储常宣传 “11 个 9 的持久性”：

1 2	`99.999999999% (11 个 9) ≈ 1000 万对象一年期望损失 < 1 个`

实现方式：

多副本 / EC：通常 3 数据中心 × EC(10+4) 跨可用区
持续 scrubbing：后台扫描发现并修复 silent corruption
版本控制 + WORM：防止误删

性能数字直觉

本地 NVMe SSD 4K 随机读：~10 μs
本地 SAN（FC32G）：~100-200 μs
NVMe-oF / RDMA：~100-150 μs
Ceph RBD 4K 读：~300-500 μs
HDFS 大块读：~MB 级聚合
S3 GET 单对象：~30-100 ms（HTTP 层延迟）

待补充：你公司分布式存储的实测延迟数字。

一些工具命令

# Ceph 集群
sudo ceph -s
sudo ceph osd tree
sudo ceph df

# RBD 创建块设备
sudo rbd create mypool/myimage --size 100G
sudo rbd map mypool/myimage
mkfs.ext4 /dev/rbd0
mount /dev/rbd0 /mnt

# HDFS
hdfs dfs -ls /
hdfs dfs -put localfile /hdfs/path
hdfs dfsadmin -report

# S3 (aws cli / s3cmd / mc)
aws s3 ls s3://my-bucket/
aws s3 cp file.bin s3://my-bucket/path/

# MinIO 部署单机
docker run -p 9000:9000 -p 9001:9001 \
    -v /data:/data minio/minio server /data --console-address ":9001"

国内分布式存储格局

类别	代表
互联网自研	字节 ByteCS、阿里盘古、腾讯 YottaStore、京东 JFS
公有云对象存储	阿里 OSS、腾讯 COS、华为 OBS、火山引擎 TOS
开源 + 商业支持	XSky、SmartX、深信服、青云、易捷行云
传统厂商	华为 FusionStorage、浪潮 AS13000

待补充：你公司在用的分布式存储方案。

小结

分布式存储的三大问题：放置 / 冗余 / 容错
多副本简单粗暴，纠删码（EC）省容量但写有放大
HDFS 适合大文件批处理，Ceph 是统一池子，S3 对象是云原生底座
CAP 不可同时满足，强一致 vs 最终一致是常见取舍
11 个 9 的持久性靠跨域多副本 + 持续 scrubbing
数据中心存储正在向”本地 NVMe + 分布式 EB 池”两极分化

下一篇是第四章最后一篇——存储选型实战与小结。

04-存储

#分布式存储 #Ceph #HDFS #对象存储

存储选型实战与第四章小结上一篇

RAID 与企业级存储 —— 从单盘到存储阵列下一篇