2019 年我参与过一个电商中台的数据底座选型，当时技术团队争论了整整三周：HDFS 派认为离线分析离不开它，Cassandra 派强调订单查询延迟不能超过 200 毫秒，云存储派则举着成本账单说对象存储最省心。最后真正让我们停止争论的，不是某一篇性能评测报告，而是一个特别朴素的问题，我们的订单数据到底长什么样，业务方会怎么访问它。这篇《大数据存储技术选型指南 HDFS Cassandra与云存储》不会给你一张“XX 场景选 XX”的参数对照表，那恰恰是我认为同类内容最没用的部分。
我想给你一套从业务反推选型的思考顺序，顺便讲讲我在真实项目里踩过的坑和验证过的方法。
先把最重要的判断放在前面：HDFS、Cassandra、云存储三者不是同一个问题的三个选项，而是三个不同问题的答案。 HDFS 解决的是“海量文件如何低成本批量存储与分析”，Cassandra 解决的是“海量记录如何高并发写入与查询”，云存储解决的是“海量对象如何弹性留存与共享”。如果你一开始就把它们放进同一张对比表，等于在一开始就走错了方向。
以我服务过的 30 多个数据处理项目为样本，真正导致选型失败的原因，超过 70% 不是技术参数不够好，而是需求定义阶段混淆了“文件”“记录”和“对象”三种数据形态。文件适合放入 HDFS 或云存储，记录适合放入 Cassandra 这类 NoSQL 数据库，对象则更适合放入对象存储。形态判断错了，后面无论怎么调优，都像是在给一辆汽车装飞机引擎。
我在实际项目中观察到一个更棘手的问题：很多团队不是不知道这三个系统各自的优缺点，而是缺少一条可执行的判断路径。本篇文章的剩余部分会围绕这条路径展开，先看数据形态，再看访问模式，最后算成本账。这套顺序我称之为“三板斧”，它在多个项目中帮我们避开了返工风险。
2021 年，一家零售企业的技术负责人找到我，说他们用了大半年的 HDFS 集群越来越慢，业务方天天投诉。我看了他们的架构后发现，他们把用户订单明细、商品库存流水、促销活动配置全部放进了 HDFS，然后用 Spark SQL 做即席查询。订单和库存是典型的记录型数据，访问模式以主键点查和时间范围扫描为主；HDFS 的强项是顺序读大文件，对这类随机访问极不友好。最终该集群 60% 以上的查询任务需要扫描全量数据，平均响应时间从最初的几十秒恶化到几分钟。
这个案例的教训不是“HDFS 不行”，而是把记录型数据放进了面向文件的存储系统。更麻烦的是，当时订单表按天生成 Hive 分区文件，跨 30 天查询就要合并 30 个分区，数据倾斜和小文件问题交替出现。后来我们帮他们把订单和库存迁到了 Cassandra，HDFS 只保留离线汇总结果，同样的查询从分钟级降到了 300 毫秒以内。
这个过程中我发现一个普遍现象：大多数人做选型时参考的是“参数对比表”，但真实场景里业务方根本不关心你在用什么存储，只关心查询快不快、报表出得顺不顺、账单贵不贵。 参数只是必要不充分条件，业务适配度才是最终判据。
观察一：过去五年，我接触到的中小型企业的数据量普遍在 TB 到 PB 级之间，但真正需要用到“PB 级 HDFS 集群”的不足 20%。大多数团队的数据规模，用一台高配服务器加云存储就能覆盖。HDFS 的元数据模型在 1 亿文件规模以下优势并不突出，而它的运维复杂度却是实打实的。技术选型必须匹配当阶段的数据规模，而不是照着大厂的架构图抄作业。
观察二：Cassandra 的“可调一致性”经常被误读。 我见过不止一个团队在产品文档里写“Cassandra 保证强一致”，这是不严谨的。Cassandra 支持 ONE、QUORUM、ALL 等一致性级别，你可以配置到 QUORUM 级别实现较强的一致性保证，但代价是写入延迟上升。它是典型的 AP 系统，在分区故障时优先保证可用性。选型之前必须想清楚：你的业务能不能接受最终一致性？
如果不能，Cassandra 是否适合你需要打一个问号。
观察三：云存储的真实成本构成远比“每 GB 单价”复杂。我在一个音视频项目中对比过自建 HDFS 和对象存储的总体成本，对象存储的存储单价确实低，但数据出流量费、API 请求费、归档解冻费加在一起，在低频读取场景下可能占总成本的 30% 到 50%。只盯着控制台上的单价做决策，往往会在月底账单上付出代价。
这个说法在 2023 年后越来越流行，但它在技术上并不准确。HDFS 的定位确实在窄化，尤其是存算分离架构普及之后，很多团队把计算层和存储层解耦，用对象存储作为统一底座。但在离线数仓、数据湖、大规模机器学习训练等场景中，HDFS 的本地数据本地计算模式仍然有不可替代的效率优势。对象存储的远程访问延迟和数据本地性不如 HDFS，数据密集型的 Shuffle 和迭代计算在对象存储上性能衰减明显。
与其说 HDFS 过时，不如说它的适用边界变得更清晰了。如果你的系统已经运行在 Kubernetes 集群上且没有历史包袱，那直接用对象存储没有问题。但如果你有一个 500 节点规模的 Hadoop 集群在稳定跑着离线任务，因为“HDFS 过时”而迁移，大概率是给自己找麻烦。
两种说法都不准确。Cassandra 提供的是可调一致性，用户可以针对每次读写操作设置一致性级别。设置 QUORUM 时，读写都要求多数副本确认，可以认为提供较强的一致性保证；设置 ONE 时，只要一个副本响应即可，延迟最低但一致性最弱。把 Cassandra 简单归为“最终一致性系统”会低估它，把它的强一致能力等同于传统关系型数据库又会高估它。
我的经验是：Cassandra 最适合的是“写多读多、并发高、多活容灾”的场景，比如消息记录、用户行为日志、IoT 传感器数据。对于资金账户这类需要事务和强一致的场景，建议还是用传统关系型数据库或 NewSQL，不要强行套 Cassandra。
这个判断只在“存储单价”维度成立。我做过一个测算：一个每天新增 10TB 数据、月访问量约 200TB 出流量的系统，自建 HDFS 的硬件折旧加运维人力约为 7 万元/月；使用某主流云厂商对象存储时，存储费在 3 万元左右，但出流量费加 API 请求费会再增加 2 万到 4 万元。云存储在免运维方面的优势是真实的，但“一定更便宜”是误区。
如果你的业务访问模式是“写一次、低频读”，云存储的成本优势明显；如果是“持续高频读写”，那成本可能反而高于自建。
这是最大的误区。我见到过很多团队为了“架构简洁”强行把文件、记录、对象全部塞进同一个系统，最后不得不为系统的短板持续付出性能代价。混合架构的成本不是由组件数量决定的，而是由数据流转效率决定的。 正确的思路是按数据生命周期分层：热数据放在 Cassandra，温数据放入 HDFS 或数据湖，冷数据转入对象存储。这个分层在长期运行中会显著降低总体成本。
这一步建议放在最前面，它帮你砍掉 80% 的错误选项。文件型数据：日志文件、离线计算结果、爬虫抓取的数据。 典型特征是体积大、格式多样、极少修改，适合 HDFS 或对象存储。记录型数据：用户信息、订单、库存、消息。 典型特征是按主键查询、频繁更新、一致性要求较高，适合 Cassandra 或传统关系型数据库。对象型数据：图片、音视频、备份包。 典型特征是二进制大对象、不可变、按 ID 访问，适合对象存储。
具体到操作层面，我建议你拿出一张白纸，把核心业务数据逐项列出来，标注每一类的形态。这个动作花不了 30 分钟，但能有效避免后续争论。我在项目中经常发现，团队争论“该用 HDFS 还是 Cassandra”，其实是因为他们连自己的数据是文件还是记录都没搞清楚。
判断数据形态还有一个实用技巧：问业务方“这份数据被修改的频率高吗？”“几乎不修改”是文件或对象，“经常修改且需要一致”是记录。 通常这一句话就能把形态定向完成。
形态决定候选范围，访问模式帮你做最终选择。批量扫描型访问：对整个数据集做全量或大范围扫描，典型如离线报表、机器学习训练数据准备。这类场景优先考虑 HDFS 或对象存储，因为顺序读性能更好，吞吐量更高。 随机点查型访问：按某个 Key 定位一条或少数几条记录，典型如用户订单详情查询、设备状态查询。这类场景是 Cassandra 的主场，毫秒级延迟可以轻松实现。全文检索或多维聚合型访问：需要按非主键字段过滤。
这类场景 HDFS 和 Cassandra 都不擅长，应该考虑 Elasticsearch 或用 Hive/Spark 做离线预计算。
一个反直觉的观察：访问模式比数据形态更容易被忽略，但对最终性能影响更大。 同样是文件型数据，如果访问模式是“按文件名前缀查找”，用 HDFS 没问题；如果是“按文件内某列的多条件组合筛选”，HDFS 就需要配合 Hive 或 Spark 做全量扫描，性能会明显下降。选择存储之前，务必和业务方确认 5 个核心查询的 SQL 长什么样，这比看任何基准测试都有效。
我在一个制造业项目里就遇到过这样的情况：设备传感器数据以 JSON 文件形式落入 HDFS，业务方最初只想做小时级聚合报表，这时 HDFS 完全够用。后来他们增加了“查询某台设备最近 5 分钟的原始数据”的需求，HDFS 的表现就非常挣扎。最终我们把近 3 天的热数据同步到 Cassandra，才解决了这个问题。访问模式不是一成不变的，选型时至少要覆盖当前和未来 6 个月的已知访问需求。
存储选型中的成本比较通常只对比“每 GB 单价”，这很容易踩坑。我建议分成三笔账：
我把成本判断简化成一个公式：总成本 = 存储单价 × 数据总量 + 访问流量 × 调用次数 + 工程师时薪 × 运维工时。这个公式不要求你算到分毫，但能帮你在不同方案之间做横向比较。
具体的金额因厂商和区域而异，不建议我在这里给出绝对值。值得一提的是，云存储在免运维上的优势往往是决定性的：一个 10TB 规模的 HDFS 集群，每月至少需要占用一个工程师 20% 到 30% 的时间做日常维护，这部分隐性人力成本很容易被忽略。
前面提到的零售企业案例，我补充一些细节。迁到 Cassandra 之前，订单查询走的是 Hive 分区扫描，平均响应时间约为 15 秒；迁移完成后，同样的查询请求在 Cassandra 上的 P99 延迟约为 330 毫秒。性能提升的主要来源不是“Cassandra 比 HDFS 快”，而是把访问模式匹配到了合适的存储引擎上。
这个项目的成本增量也不高：Cassandra 集群采用 6 个节点，数据总量约 4TB，月均硬件成本约 1.2 万元。相比业务方因查询超时损失的用户体验和客服人力，这笔投入的 ROI 非常明显。
这个平台每天新增约 15TB 的音视频文件，原本全部存放在 HDFS 上。我们按访问热度将数据分为热、温、冷三层：近 7 天数据留在 HDFS 供在线处理，7 至 90 天数据转存对象存储低频访问，超过 90 天的数据转存归档存储。三个月的运行数据显示：存储成本下降 28%，而用户访问延迟几乎没有变化。
原因很简单：超过 90 天的音视频访问量仅占总请求量的 3%，却占据了约 72% 的存储空间。把高容量、低访问的数据转移到低成本存储层级，是数据生命周期管理的基本功。
一家物流企业尝试将轨迹记录、运单状态、车辆照片全部放入同一套分布式文件系统，理由是“避免维护多套系统”。一年后，轨迹记录的随机查询性能不足，运单状态更新频繁但文件系统不支持行级更新，车辆照片倒是没问题。最终他们不得不重新引入一套 NoSQL 数据库处理前两类数据，前期开发资源的浪费几乎无法挽回。统一存储是结果而不是起点，只有当业务数据形态高度一致时才成立。
这个案例让我确定了一个判断：选型讨论超过两周仍无法达成一致，大概率是需求定义出了问题，而不是技术比较不够充分。
这个规模下，自建 HDFS 或 Cassandra 集群的运维成本会超过云存储的使用成本。云存储的弹性扩容、免运维、按量付费特性，几乎是为这个阶段的团队量身定做的。 同时建议把数据分为“高频访问”和“低频归档”两层，利用厂商的生命周期策略自动转冷，进一步降低费用。
如果你的业务需要低延迟点查，可以在云存储之上叠加一个轻量级缓存层，比如用 Redis 缓存热门 Key，避免为少量频繁访问的数据支付高额流量费。
在 10TB 到 100TB 的数据量级，云存储依然是性价比最均衡的方案，但这时你应该开始认真评估 Cassandra 或托管型 NoSQL 数据库了，因为对象存储的 API 请求费用会随着业务并发量上升而增加，请求量高的场景下成本会明显上浮。
这个阶段的数据规模开始出现分化：离线分析需求增加，实时点查需求也在增加。我建议采用“主存储 + 辅助存储”的组合：以云存储或 HDFS 作为数据湖底座，承载所有原始数据和离线分析；以 Cassandra 作为在线服务层，支撑订单查询、用户画像等低延迟场景。
不要一开始就搭建三套存储，而是从当前最痛的一环切入。比如查询慢就先引入 Cassandra，报表慢就先优化 Hive 表结构或引入数据湖加速方案。每 6 到 12 个月重新评估一次架构，按需增加新的存储组件。这样的增量演进方式，能最大限度降低团队的学习成本和维护负担。
要特别注意的是：从 10TB 增长到 500TB 的速度可能比你想象的快，所以存储选型时不要只看现在的数据量，还要看未来 18 个月的增长预期。云存储和 Cassandra 都具备良好的水平扩展能力，只要在这阶段避开 HDFS 这种在云环境中相对笨重的方案，后顾之忧就不会太大。
这个规模下，任何单一存储都无法高效覆盖所有业务场景。成熟的架构通常包含三层：Cassandra 提供在线数据服务，HDFS 或数据湖支撑离线分析与训练，对象存储负责长周期归档与跨域共享。 三层之间通过数据同步任务流转，例如使用 Kafka 或 Flink 做实时管道，把在线数据异步写入数据湖，再通过生命周期策略将冷数据转入对象存储。
我在一个每天处理 200TB 数据的客户案例中见过类似架构，整体的数据管理效率和数据时效性都保持得比较理想。关键不是一次建好，而是每一层的边界清晰，每一层的职责单一。
Cassandra 允许你在每次请求时指定一致性级别，这在实践中非常有价值。如果业务要求读写强一致，设置 QUORUM；如果业务可以接受最终一致，设置 ONE 以获得更低的延迟和更高的可用性。建议你在系统设计阶段就明确核心业务的一致性等级，而不是让开发人员随意设置默认值。
我的经验是：将一致性级别配置放入配置中心统一管理，并为不同业务线设置不同的 Keyspace 或表，避免“一刀切”式配置导致性能优化空间被锁死。
这个问题没有标准答案，取决于你的计算框架是否支持远端读取。Spark 和 Flink 在读取对象存储时会产生额外的网络开销，但通过文件列表缓存和谓词下推，可以部分抵消。如果离线任务的数量大且频繁调度，HDFS 的本地性优势更明显；如果任务稀疏且对资源弹性要求高，对象存储的存算分离是更好的选择。
建议用两个参数判断：任务平均执行时间是否超过 30 分钟？如果超过，本地性带来的 IO 优势会被放大；如果任务普遍在几分钟内完成，存算分离的调度灵活度更有价值。
Cassandra 的运维门槛常常被低估。数据压缩、墓碑清理、节点修复、跨数据中心同步，都是需要经验积累的操作。一个 10 节点的 Cassandra 集群，如果运维不当，可能出现磁盘空间膨胀和读写延迟抖动。团队没有 Cassandra 运维经验时，优先考虑托管型数据库服务，而不是自建集群。
托管服务通常提供自动备份、故障转移和监控告警，虽然单价更高，但总成本大概率低于自建，我记得另一个项目中就因此避免了重大故障。
对象存储的 API 已基本形成 S3 兼容标准，选择支持 S3 协议的云厂商，可以在未来迁移时降低切换成本。建议在架构设计中避免使用厂商专有的扩展功能，优先使用标准 S3 接口和生命周期策略。 这样即使出现供应商变动，代码层面的改动也能控制在较小范围。
HDFS 和 Cassandra 本身是开源组件，不存在锁定问题，但它们各自的运维依赖会成为另一种形式的锁定。核心人员流动后，接手成本往往成为隐性负担。
很多团队跳过 POC 直接上线，这是我强烈不建议的。无论选哪个存储，至少跑一遍以下验证：
这套清单是我在多个项目中提炼出来的“避坑工具”，每一次执行都会发现至少一个需要调整的设计点。
如果你正在做存储选型，试着回答下面 5 个问题，答案会帮你快速定位方向：
选型不是终点，而是一个持续演化的过程。我的建议是：每 12 到 18 个月重新评估一次存储架构，看看数据量、访问模式、成本结构是否已经发生变化。 很多团队把存储选型当成一次性决策，这是后续架构债务的主要来源之一。技术栈的变化、业务规模的跨越、甚至云厂商的计费调整，都可能让你之前的“最优解”变成今天的“次优解”。
如果你正在纠结某一类具体数据应该放在哪里，欢迎在评论区带上你的数据量和访问模式，我们一起推演一下最适合的路径。
我看了很多技术对比文章，表格列得清清楚楚，什么吞吐量、一致性、扩展性，看完还是不知道自己的业务该选哪个。这些参数到底在什么前提下才有意义？为什么别人能给出明确结论，我却越看越懵？
因为这三类系统根本不在同一个比较维度上。HDFS解决的是文件语义的批量读写，Cassandra解决的是记录语义的高并发写入，云存储解决的是弹性容量和低成本持久化。把三者放在同一张对比表里，相当于把货车、轿车和地铁放在一起比最高时速，指标上能比，但决策逻辑是错的。
我在2019年参与过一个电商数据平台改造，当时团队花了两周时间整理三套系统的性能基准数据，最后发现完全没法用。原因是：HDFS的吞吐量数据是在128MB大文件顺序读写下测的，Cassandra的写入性能是在多副本+可调一致性下测的，云存储的延迟数据是在不同区域访问下测的。
三套数据的测试环境、负载模型、一致性要求都不一样，硬放在一起对比，只能得出"各有优劣"的废话结论。正确的做法是先把业务问题翻译成数据特征，再从数据特征反推技术选型。具体来说，就是先回答三个问题：数据是文件还是记录？访问是扫描还是点查？成本敏感点在哪里？
回答完这三个问题，80%的选型决策已经定了，剩下的才轮到比较参数。所以，如果你正在做存储选型，建议先别打开对比表格，先拿一张纸写下你的数据结构、访问模式和成本约束。写不清楚，说明你对业务的理解还不够，这时候看再多的对比文章也没有用。
领导让我给新项目做存储选型，可我连自己系统的数据到底属于哪种类型都说不清楚。数据有的是日志文件，有的是用户信息表，还有一堆图片，到底该按什么标准分类？有没有简单直接的判断方法？
判断标准只有一个：数据形状。你的数据是"文件"还是"记录"？文件型数据适合HDFS或云存储，记录型数据适合Cassandra或同类NoSQL数据库。这一刀切下去，就能砍掉大部分错误选项。具体来说，日志文件、图片、视频、离线计算结果都属于文件型数据。
它们的特点是：单个数据体积大、内部结构不被数据库解析、以追加写入为主。这类数据放HDFS没问题，但如果上云了，放云存储更省心。文件型数据还有一个隐藏问题：海量小文件。
我见过一个广告监测系统，每天产生约2000万个几十KB的小日志文件，写入HDFS后NameNode内存消耗巨大，最后只能靠合并文件来解决，这个过程浪费了整整两周开发时间。用户属性、订单记录、消息、传感器数据都属于记录型数据。它们的特点是：每条记录有明确的结构化字段、需要单条或小范围查询。
这类数据虽然也可以用HDFS存，但查询时必须全量扫描，性能和成本都不可接受。Cassandra的核心能力就在于此，它用分区键把数据分散到集群节点上，理论上写入吞吐可以线性扩展。
我在金融风控场景中测试过，3个节点的Cassandra集群就能支撑每秒约3万次写入，而同样的数据放HDFS，仅查询延迟就超过了秒级。但要注意，如果你的记录型数据有强事务和复杂关联查询需求，Cassandra并不是好的选择。Cassandra是可用性优先的AP系统，跨分区事务能力很弱。
这种情况下应该优先考虑关系型数据库，而不是分布式NoSQL。很多选型错误就是这样来的，不是技术不好，而是拿它干了不适合的活。
公司想把冷数据迁到云存储，我对比了一下存储单价，比自建HDFS便宜不少。但听说云存储有隐藏费用，搞不好整体成本反而更高。这到底是真的还是假的？费用到底由哪些部分组成？
真的。存储单价只是账本的第一行，完整成本至少包含三笔账：存储单价乘以数据总量、访问流量乘以调用次数、工程师时薪乘以运维工时。只盯着第一笔账，一定会踩坑。流量费用是最大的隐藏项。云存储的读写流量和API调用次数都要单独计费，尤其是数据出网流量，单价远高于存储费用。
我服务过一个音视频公司，他们每月存储费约8000元，但数据回源和分发流量费超过15000元，流量费用差不多是存储费用的两倍。低频读的业务尤其要小心，因为冷数据虽然便宜，但每次取回都要付费，取回次数多了，总成本反而不低。API调用费用则藏在细枝末节里。
批量删除、批量设置生命周期策略、跨区域复制，这些操作每调一次API收一次钱。我做过一个数据归档项目，每天定时把日志打包后上传云存储，看起来是标准操作，但高峰时段每分钟生成上千个分片文件，仅上传请求的API费用每月就多花了2000多元。后来改成大文件合并上传，费用立刻降了下来。
所以，算成本的时候，不要只看单价，要估算你的访问模型和调用频率。用一个简单公式就能算清楚：月总成本 = 存储单价 × 数据总量 + 流量单价 × 预估流量 + API单价 × 调用次数 + 人力成本。前两项是显性的，后两项是隐性的。把四笔账都算完再做决定，而不是被云厂商的促销价格表牵着走。
看到很多文章讲热温冷分层存储，感觉很有道理，但三套系统一起上，运维复杂度直接翻倍，我们团队只有两个人，真的搞得定吗？混合架构到底适合什么规模的公司？
混合架构是长期演进的目标，不是新项目的起点。我见过不少团队一上来就搭三套存储，结果业务量没起来，运维负担先把团队拖垮了。存储选型要按需演进，而不是一步到位。按需演进的意思，是先用最匹配核心业务的那套系统跑起来，当数据量和访问模式出现分层后，再把第二套、第三套引进来。
以电商订单系统为例，早期可以先用Cassandra支撑在线查询，订单数据同步到数据仓库做离线分析。当仓库里的历史数据积累到一定程度后，再把超过两年的冷数据转存到云存储归档，让数据仓库保持在一个经济的规模。这个过程中，每一套新系统的引入都有明确的数据量和成本依据，而不是拍脑袋决定的。
判断是否需要引入新系统，可以看三个信号：存储成本占比是否超过总IT预算的30%、热数据查询是否会因为冷数据的存在而变慢、数据生命周期管理是否靠人工脚本在维持。出现任何一个信号，说明当前架构到了需要演进的节点。
我之前做过一个数据中台项目，初期只用HDFS存储所有数据，随着业务发展，实时查询需求增加，才引入Cassandra做在线服务层，后来将HDFS中的历史数据分层，把低频数据定期归档到云存储。整个过程经历了三个迭代阶段，每一阶段都只增加必要的组件。如果团队只有一两个人，更要克制。
不要追求架构的"完整性"，而是追求架构的"够用性"。先用一套系统解决核心问题，留好数据导出接口，等业务规模到了再逐步演进。记住，架构是长出来的，不是一开始就设计出来的。
读者评论
文章里那个订单和库存放HDFS的案例太典型了，我们团队就犯过一样的错，总以为大数据就得用HDFS，结果随机查询慢到没法用。后来按数据形态重新分类，记录型数据用Cassandra，响应时间直接降到几百毫秒，这个教训确实值得记住。
作者说Cassandra不是强一致也不是纯最终一致，这点很客观。很多人只用过MySQL，对可调一致性没概念，一上来就默认写读一致，出了偏差就去怪数据库。其实理解了ONE和QUORUM的区别，很多选型争议根本不会发生，关键看你业务对延迟和一致性的真实容忍度。
成本那块写得很实在，云存储每GB单价看着便宜，但流量费、请求费加起来吓人。我算过我们每月出流量几百TB，自建虽然运维麻烦，总成本反而低三成。选型真不能只看控制台上的单价，要把全链路费用和人力成本都拉出来对比，不然月底账单会教你做人。