3. 存储成本分析：HDFS、对象存储、消息队列在流批一体中的权衡
存储成本，说白了就是数据在哪儿待着、待多久、怎么取出来最划算。流批一体架构里，HDFS、对象存储和消息队列这三兄弟，各有各的脾气，也各有各的账单。我这些年踩过的坑，多半跟没算清这笔账有关。
3.1 HDFS：批处理的“老黄牛”，但别让它干流式活
HDFS 的设计初衷就是大文件、顺序读写、一次写入多次读取。在批处理场景下，它的吞吐量确实没话说。但你要是拿它当消息队列用，那就麻烦了。
核心成本构成：
- 副本开销：默认 3 副本，存储利用率只有 33%。100TB 数据，实际占用 300TB 物理空间。
- NameNode 内存：每个文件/块约占用 150 字节内存。小文件一多，NameNode 先撑不住。
- 计算与存储耦合：DataNode 既存数据又跑计算，扩容时经常“买一送一”，浪费资源。
我记得有个项目，业务方把 Kafka 的实时数据直接落 HDFS，一天产生几千万个小文件。结果 NameNode 内存飙到 80%，GC 频繁，整个集群都不稳定。后来我让他们改成按小时合并成大文件，才缓过来。
我的习惯：HDFS 只存“冷批数据”，比如 T+1 的离线中间结果、历史快照。文件大小控制在 128MB 以上，小文件用合并工具定期处理。
3.2 对象存储：成本“杀手”，但延迟是硬伤
对象存储（比如 S3、OSS、COS）这几年在流批一体里越来越火。为什么？便宜。存储单价通常是 HDFS 的 1/3 到 1/5，而且没有副本概念（靠 erasure coding），利用率能到 80% 以上。
但便宜是有代价的。对象存储的读写延迟比 HDFS 高一个数量级，尤其是 LIST 操作，慢得让人抓狂。你想想看，一个实时任务每秒要查几百次文件列表，用对象存储做底层，延迟根本扛不住。
| 对比维度 | HDFS | 对象存储 |
|---|---|---|
| 存储单价 | 高（3 副本） | 低（EC 或单副本） |
| 读写延迟 | 毫秒级 | 几十毫秒到秒级 |
| 小文件性能 | 差（NameNode 瓶颈） | 更差（LIST 操作慢） |
| 扩容弹性 | 差（需规划） | 好（按需付费） |
| 适用场景 | 批处理中间结果 | 冷数据归档、湖仓底座 |
我曾经踩过的坑：把实时流处理的结果直接写到对象存储，每 5 秒一个文件。结果下游的批处理任务读数据时，LIST 操作耗时超过 10 分钟，整个 pipeline 都堵死了。后来改成先写本地磁盘，再异步上传，才解决问题。
3.3 消息队列：流式数据的“高速公路”，但别当数据库用
Kafka 和 Pulsar 是流批一体里消息队列的代表。它们的核心价值是低延迟、高吞吐、数据缓冲。但存储成本这块，很多人算不明白。
3.3.1 Kafka：磁盘顺序写，但副本和留存是成本大头
Kafka 的存储设计很聪明——顺序写、零拷贝、批量压缩。但它的成本陷阱在于：
- 副本数：默认 2 副本（min.insync.replicas=2），存储利用率 50%。
- 留存时间：很多人习惯设 7 天甚至 30 天，数据越积越多。
- Segment 文件：每个分区有多个 segment，小 segment 会浪费磁盘空间。
我个人习惯，Kafka 只保留 24-48 小时的数据。超过这个时间，数据就应该落到 HDFS 或对象存储里做长期保存。别把 Kafka 当数据湖用，那是烧钱。
3.3.2 Pulsar：存算分离，但 BookKeeper 的 IO 开销不容忽视
Pulsar 的卖点是存算分离，计算层（Broker）和存储层（BookKeeper）可以独立扩缩。理论上，存储成本可以更灵活。但实际项目中，我发现 BookKeeper 的写入放大问题比 Kafka 严重。
为什么？Pulsar 的每条消息要写多个 Bookie 节点（默认 3 副本），而且 Journal 和 Ledger 是分开写的。IO 路径更长，磁盘开销更大。我做过一个对比测试：同样 100MB/s 的写入流量，Kafka 的磁盘 IO 大约是 200MB/s，Pulsar 能到 350MB/s 以上。
成本权衡建议：
- Kafka 适合：高吞吐、短留存、对延迟敏感的场景。
- Pulsar 适合：需要长留存、多订阅、计算存储独立扩缩的场景。
- 通用原则：消息队列只做“缓冲”，不做“存储”。数据落地后尽快转移到低成本存储。
3.4 流批一体中的存储分层策略
说了这么多，到底怎么选？我的经验是：不要只用一种存储，而是做分层。
你看这个分层，其实很直观：
- 热数据（消息队列）：实时流处理，低延迟，短留存。成本高，但值得。
- 温数据（HDFS）：批处理中间结果，大文件，3 副本。成本中等，性能稳定。
- 冷数据（对象存储）：历史归档，湖仓底座，低成本。查询少，但必须能访问。
我的建议：数据从消息队列出来后，先落 HDFS 做批处理，然后定期（比如每天）把超过 7 天的数据迁移到对象存储。这样既保证了实时性，又控制了长期存储成本。
3.5 避坑指南：存储成本优化的 3 个常见误区
- 误区一：所有数据都存 3 副本。其实对象存储用 EC（纠删码）可以做到 1.3 倍冗余，成本直降 50% 以上。
- 误区二：Kafka 留存时间越长越好。留存超过 3 天，磁盘成本翻倍，而且消费性能下降。不如把数据转存到 HDFS 或对象存储。
- 误区三：忽略小文件问题。不管是 HDFS 还是对象存储，小文件都是性能杀手。我见过一个案例，对象存储里几亿个 1KB 的文件，LIST 一次要 30 分钟。后来合并成 128MB 的大文件，问题才解决。
我曾经犯过的错：为了省事，把实时流的数据直接写到对象存储，没做任何合并。结果下游的 Spark 任务读数据时，光 LIST 操作就花了 20 分钟，整个 pipeline 延迟从 5 分钟变成了 30 分钟。后来我加了一层本地磁盘缓冲，每 10 分钟合并一次再上传，才恢复正常。
嗯，存储成本这块，说白了就是“什么数据放什么地方，放多久，怎么取”。没有银弹，只有权衡。你想想看，你的业务里，哪些数据是热的，哪些是冷的？分清楚，成本自然就下来了。