HDFS、S3、OSS到底该用哪个——存储选型和数据湖底座
先说结论
2025年的趋势是：对象存储（S3/OSS/GCS）作为数据湖底座 + 湖格式（Delta Lake/Iceberg）提供ACID事务。HDFS在存量系统中仍然大量存在，但新项目越来越少直接用HDFS了。选型的核心因素是：成本、运维复杂度、性能需求、团队能力。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
存储选型是数据架构的第一个决策，也是面试常考的对比题。我在四家公司用过三种存储方案——某短视频平台和某知名出海硬件品牌用的S3，某元宇宙社交公司用的本地HDFS（Doris），某短剧出海公司用的阿里云OSS+MaxCompute。每种方案都有适用场景。面试官问存储选型，考的是你对不同方案的理解深度和选型判断力。
三种存储方案对比
| 维度 | HDFS | S3/OSS（对象存储） | 云数仓存储（MaxCompute/BigQuery） |
|---|---|---|---|
| 存储成本 | 中（自建服务器成本） | 低（按量付费，分层存储） | 低（全托管，按量付费） |
| 运维成本 | 高（NN/DN维护） | 零（云厂商托管） | 零（全托管） |
| 读写性能 | 高（本地磁盘直读） | 中（网络IO延迟） | 高（内部优化） |
| 并发能力 | 中（受NN限制） | 高（无限水平扩展） | 高 |
| ACID事务 | 不支持 | 需要湖格式（Delta/Iceberg） | 内置支持 |
| 弹性扩展 | 差（加节点+数据均衡） | 无限（按量付费） | 自动 |
| 适用场景 | 自建集群/高性能 | 云上数据湖 | 云上数仓/全托管 |
HDFS的优势和局限
优势：① 数据本地性——计算可以在数据所在的节点上执行，省了网络传输；② 高吞吐顺序读写——对大文件的顺序读写性能极好；③ 成熟稳定——经过十几年大规模验证。
局限：① NameNode单点瓶颈——元数据在内存里，文件数有上限（几亿级别）；② 运维复杂——NN高可用、DN均衡、小文件治理都需要专人维护；③ 弹性差——扩容要加物理节点，缩容要迁移数据，不能按需伸缩；④ 不支持ACID——没有事务，并发写入可能数据不一致。
S3/OSS的优势和局限
优势：① 无限扩展——不需要担心容量上限；② 零运维——不用管节点、磁盘、副本；③ 分层存储——自动把冷数据降级到低成本存储；④ 高可用——11个9的持久性（99.999999999%），基本不可能丢数据。
局限：① 延迟高——每次读写都是HTTP请求，比本地磁盘慢10-100倍；② 列表操作慢——ls一个大目录可能要几十秒；③ 最终一致性——写入后可能短暂读不到最新数据（S3已经改成强一致了，但OSS部分操作还是最终一致）；④ 不支持ACID——需要Delta Lake/Iceberg提供事务能力。
存算分离——大趋势
# 传统架构（存算一体）
# Hadoop集群：每个节点既存数据又做计算
# 计算需要更多CPU？加节点（但也多了不需要的磁盘）
# 存储需要更多磁盘？加节点（但也多了不需要的CPU）
# 资源耦合，无法独立扩展
# 现代架构（存算分离）
# 存储层：S3/OSS（无限扩展，按量付费）
# 计算层：Spark on K8s / EMR / Databricks
# 计算需要更多CPU？加计算节点（不影响存储）
# 存储需要更多空间？S3自动扩展（不需要加节点）
# 两层独立扩展，互不影响
# 代价：计算节点读S3数据有网络延迟
# 解决：本地SSD缓存热数据（Databricks的Delta Cache）
# 实际效果：缓存命中时性能接近本地HDFS实战经验：四家公司的存储选型对比
| 公司 | 存储方案 | 计算引擎 | 选型原因 |
|---|---|---|---|
| 某短视频平台 | S3 | Hive+PySpark on EMR | AWS生态，团队熟悉S3 |
| 某出海硬件品牌 | S3+Delta Lake | Databricks | 从EMR迁移后，Delta Lake提供ACID |
| 某元宇宙社交 | Doris本地SSD+S3冷存 | Flink+Doris | 实时查询需要本地SSD性能 |
| 某短剧出海 | MaxCompute（内部存储） | MaxCompute SQL | 阿里云生态，全托管最省心 |
我的选型建议：如果在AWS上用S3+Databricks（或EMR），在阿里云上用OSS+MaxCompute（或EMR），在自建集群上用HDFS+Spark。不要跨云存储——数据出云的网络费用非常昂贵。
数据湖格式——弥补对象存储的缺陷
S3/OSS不支持ACID事务，Delta Lake/Iceberg/Hudi补齐了这个短板：
| 能力 | 裸S3 | S3+Delta Lake |
|---|---|---|
| ACID事务 | 不支持 | 支持（并发读写安全） |
| Schema演进 | 不支持 | 支持（加列/改类型） |
| Time Travel | 不支持 | 支持（查历史版本） |
| MERGE操作 | 不支持 | 支持（增量更新/CDC） |
| 小文件合并 | 手动 | OPTIMIZE自动合并 |
| Z-Ordering | 不支持 | 支持（加速多维查询） |
我在某知名出海硬件品牌迁移到Databricks后，Delta Lake的MERGE INTO替代了原来的UNION全量覆盖，代码量减少70%。Z-Ordering加速了多维查询，查询延迟降低70%。
面试高频追问
追问一：S3的性能够用吗？不会比HDFS慢很多吗？
单次请求延迟确实比HDFS高（S3约10-100ms vs HDFS约1ms）。但对于大数据批处理场景，瓶颈通常是吞吐量而非延迟——S3的吞吐量可以通过并行请求无限扩展。实际生产中，Spark on S3的性能和Spark on HDFS差距在20%以内。配合本地缓存（Delta Cache）甚至可以持平。
追问二：HDFS会被S3完全替代吗？
短期内不会。HDFS在数据本地性场景（计算和存储在同一节点）有性能优势，某些对延迟极度敏感的场景（HBase、实时查询）仍然需要HDFS。但长期看，存算分离是大趋势——Hadoop自己也在做存算分离（Ozone项目）。5-10年后HDFS可能只在特定场景使用。
追问三：MaxCompute和EMR有什么区别？
MaxCompute是全托管的计算+存储一体化服务，用户只需要写SQL，不需要管集群。EMR是半托管——AWS帮你创建Hadoop集群，但Spark作业/调度/调优还是你自己搞。MaxCompute更省心但灵活性低，EMR更灵活但运维多。我在短剧出海公司选MaxCompute就是因为团队小（就我一个数据人），没精力运维集群。
总结
存储选型面试讲三个层面：① HDFS vs S3/OSS的核心对比（性能/成本/运维/弹性）；② 存算分离趋势（存储和计算独立扩展是大方向）；③ 数据湖格式的价值（Delta/Iceberg在对象存储上补齐ACID/Schema演进/Time Travel）。能结合四家公司的真实选型经历讲'为什么选这个不选那个'，面试官会觉得你有架构选型的判断力。
下一篇聊Hive的执行引擎选择：Hive on MapReduce、on Tez、on Spark到底哪个好？
你们数据存在哪里？HDFS还是S3/OSS？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长