分布式存储三国杀：对象存储 vs HDFS vs 列式存储，到底该怎么选？
——By Echo_Wish，一个在大数据江湖摸爬滚打多年的老朋友
老铁们，今天我们聊聊一个常被忽视但绝对关键的底层话题：分布式存储。
为什么说关键？因为 数据再牛逼，没有一个好用的存储，都是空中楼阁。
这事儿就像你有 100 吨粮食，
你得先决定——
是放在 粮仓（对象存储）、
还是 仓库货架（HDFS）、
还是 整齐切片的保鲜盒（列式存储）？
不同选择对应的成本、速度、业务特性全都不一样。
今天不搞概念灌输，我们用一个聊业务的方式，把对象存储、HDFS、列式存储这三货彻底捋清楚。
一、对象存储：云时代的“基础款大仓库”
对象存储（Object Storage）你肯定听过：S3、OBS、OSS…
核心特点一句话概括：
👉 “海量、便宜、持久、简单，用 URL 存文件。”
它不像传统文件系统那样有“文件夹”。
它所有东西都是“对象（Object）”，带元数据，通过 REST API 读写。
你可以把它理解成：
一个几乎无限大的网盘，并且性能不保证，但容量绝对够。
非常适合：
- 日志归档
- 图片/视频文件
- 模型文件（AI 训练完几十 GB 那种）
- 离线数据湖（S3-Lake、OBS-Lake）
但它不适合高频随机读写。
比如 Hive 在对象存储上跑小文件？慢！
Flink Checkpoint 要频繁写？也慢！
简单示例（Python 用 boto3 写 S3）：
import boto3
s3 = boto3.client('s3')
# 上传文件
s3.upload_file("local.txt", "my-bucket", "data/local.txt")
# 下载文件
s3.download_file("my-bucket", "data/local.txt", "downloaded.txt")
是不是很云原生、很 REST？
但你要做“快速扫描”“高速读写”？
抱歉，不是它的强项。
二、HDFS：大数据时代的“铁头功文件系统”
HDFS 是大数据时代的老基石。
用俩字总结：抗造。
特点非常鲜明：
👉 大文件吞吐量高、顺序读写爽、搭配计算框架简直天作之合。
比如你用 Spark、Hive，有大量顺序扫描，HDFS 给你妥妥的高带宽。
但你要问我 HDFS 哪里不行？
我给你列几条你肯定深有体会：
- 不适合小文件（NameNode 元数据爆炸）
- 扩容要加机器（不像对象存储交钱就行）
- 运维成本高（NameNode 挂了全世界都慌）
写文件示例（PyArrow 写入 HDFS）：
from hdfs import InsecureClient
client = InsecureClient('http://namenode:50070', user='hadoop')
client.write('/data/log.txt', data='hello hdfs!')
你能看出来，它就是文件系统，只不过分布式。
它适合企业内部大数据平台的刚需场景，比如：
- Spark 离线计算
- Hive 批处理
- 大规模日志处理
- 长时间稳定运行的大数据平台
一句话概括：
HDFS 是铁打的大数据离线引擎配套方案。
三、列式存储：分析查询的“性能怪兽”
列式存储不是“系统”，更像是一种存储格式：
- Parquet
- ORC
- Kudu（算是半系统）
列式的最大特点就是一句话：
👉 你查什么列，就只读什么列。读得少，自然更快。
再配合编码、压缩，例如：
- RLE（Run Length Encoding）
- Dictionary Encoding
- Bit Packing
能把一个表从几十 GB 砍到几 GB，甚至更小。
为什么列式让 SQL 飞起来？
举个栗子：
下面这样一个 SQL：
SELECT user_id, SUM(amount)
FROM t_order
WHERE city = 'Shenzhen'
GROUP BY user_id;
在行式存储中，你每次都要扫整行。
但在 Parquet 中，你只需要读 city, amount, user_id 三列。
I/O 直接砍掉 70% 以上。
Python 写 Parquet 示例：
import pandas as pd
import pyarrow as pa
import pyarrow.parquet as pq
df = pd.DataFrame({
'city': ['Shenzhen', 'Guangzhou', 'Shenzhen'],
'amount': [100, 200, 150]
})
table = pa.Table.from_pandas(df)
pq.write_table(table, 'orders.parquet')
我敢说，用过 Parquet 的人，再也不想回行式存储了。
列式适合：
- 数仓
- 离线分析
- BI 查询
- 数据湖（Lakehouse）
一句话：
列式是分析专用武器。
四、三者到底怎么选？我给一个最接地气的总结
我给你来个最粗暴但最有效的“场景决策表”：
| 需求 | 选什么 | 原因解释 |
|---|---|---|
| 业务系统文件、图片、日志存放 | 对象存储 | 无限容量 + 成本低 + 天然云原生 |
| Spark/Hive 离线计算 | HDFS | 高吞吐、大文件顺序读写王者 |
| 数仓分析、BI、SQL 查询 | 列式存储 | 只读需要的列，压缩率高，查询快 |
| 数据湖架构 | 对象存储 + 列式存储 | 池化大仓库 + 结构化列式文件 |
| 需要 ACID 和近实时 | Kudu/TiDB/Delta Lake | 对象/HDFS 不适合高并发小写 |
如果让我给一个更现实、更接地气的判断：
2025 年以前：
HDFS = 离线大一统
对象存储 = 云时代的容量池
列式 = 数据仓库必选2025 年以后：
对象存储 + 列式 = 大数据主流（Lakehouse）
HDFS 只在传统大数据平台持续存在
换句话说：
HDFS 的江湖地位在收缩；对象存储 + 列式存储正在成为新时代的“双子星”。
五、写在最后：存储不是技术，是业务逻辑的映射
很多同学选择存储时最容易犯的一个错：
“只看技术，不看业务。”
技术没有好坏，只有适不适合场景。
对象存储解决的是——
👉 规模问题、成本问题。
HDFS 解决的是——
👉 大数据高吞吐的工程问题。
列式存储解决的是——
👉 查询性能与压缩问题。
