存算分离实践指南：从Hadoop到对象存储的架构跃迁

1. 为什么存算分离被反复提起：从“扩容都要连坐”说起

大概三年前，我负责的那套Hadoop集群到了一个非常尴尬的阶段。HDFS节点磁盘用了不到六成，但整个集群的CPU和内存已经顶不住了。业务方跑一个日批任务，Spark的Executor从启动到稳定要等将近十分钟，YARN队列里积压的任务越来越多。要解决这个问题，按当时的老思路就是扩节点。可每扩一台物理机，意味着我又要买十几块大容量HDD——那些盘我根本用不上，现有节点的存储空间明明还很宽裕。这种“为了计算，连存储一起买单”的膨胀感，应该是很多做大数据平台的人都有过的体验。

等后来真正把存算分离落地之后再回头看，这种难受不是个例，而是传统Hadoop一体化架构的结构性矛盾。存算分离这个说法这些年被反复提及，本质上不是某个新玩意儿突然冒出来，而是数据规模增长到一定程度之后，计算和存储之间那种“绑死在同一个资源池里”的耦合关系，已经成了系统的天花板。

我见过很多团队的误区是：以为存算分离就是把数据扔到对象存储上，然后Spark去读一下就完事了。真这么干的人，十有八九会遇到性能暴跌、任务超时、小文件爆炸等一系列新的痛苦。因为存算分离是一个系统工程，它背后牵涉到任务调度策略、数据本地性的重新定义、缓存层的引入、元数据服务的解耦，甚至运维模型、成本模型都要跟着变。

这篇东西我打算从为什么必须做、拆的到底是什么、怎么落地、落地后会引发哪些连锁反应，以及哪些场景不适合硬上这五个方面来复盘。适合谁看？如果你正在被集群扩容成本、计算资源利用率不均、多套集群数据难共享这些问题困扰，或者你已经在做存算分离改造但踩了一些说不清的坑，这篇应该能帮上忙。

2. 老架构的“三宗罪”：数据本地性、扩容连坐与冷热同池

2.1 数据本地性的悖论：移动计算比移动数据便宜，但代价是调度被绑架

传统Hadoop架构的基石之一，就是数据本地性（Data Locality）。HDFS把文件切成128MB的块，每个块默认三副本分布在不同的机架上，YARN在调度计算任务时，优先把Container调度到数据所在的节点上，这就是NODE_LOCAL。为什么要这么做？因为网络带宽曾经是稀缺资源，把计算拉到数据旁边，比把数据拉到计算旁边便宜得多。

这个设计在十年前的硬件条件和企业数据规模下是合理的。但问题在于，像HDFS这样的大数据文件系统，文件只能追加不能随机写，数据一旦写入就基本固定了。而业务是不断变化的，今天的计算热点可能集中在刚写入的全量用户行为日志上，明天的热点可能跑到历史订单明细里。

于是调度器陷入了一个困境：为了追求数据本地性，它必须把任务调度到数据所在节点，但那些节点可能正是资源紧张的节点。我见过最典型的场景是，一个1000节点的集群，某个业务表的数据只有3个副本、分布在30个节点上，但访问这张表的任务量占整个集群的40%。YARN为了数据本地性，只能把这些任务压在这30个节点上，其他970个节点资源再空闲也帮不上忙。最终的结果就是局部过热，集群整体资源利用率上不去。

做了存算分离之后，计算节点和数据节点彻底分开，任务调度不再被数据位置绑架，资源利用率确实上来了。但代价是，网络变成了新的瓶颈。这是存算分离架构下的第一条经验：你省下的数据本地性红利，必须用一套新的缓存机制和网络架构补回来，否则就是拆东墙补西墙。

2.2 扩容的“连坐效应”：每加一份算力，被迫买两份存储

老架构下，扩容是一个很痛苦的决策。上面说了，我只需要算力，不需要存储，但物理上没办法只加计算。你买了一台新的服务器，上面带着CPU、内存和本地硬盘，进了HDFS集群之后，这12块盘就自动变成分布式存储的一部分了。然后把DataNode拉起，数据均衡器开始跑，新的节点会被均匀地填上数据，这个过程可能持续好几天，期间集群的磁盘IO、网络IO都会被拉高。

更难受的是缩容。业务高峰期过了，想释放一些计算资源，但DataNode不能随便下线，因为上面的副本数据要先被迁走。一个数据量上百TB的节点，迁移副本可能要跑三四天，期间这个节点还不能关。如果直接强杀节点，副本数下降，HDFS会自动补副本，又是一轮网络和IO风暴。

按我当时的估算，这种架构下，为了满足计算峰值而扩容的资源，其中有接近一半的存储容量是被动配置的，实际利用率很低。存算分离之后，计算集群和存储集群可以各自伸缩，计算压力上来了就快速拉起一批无状态的计算节点，用完直接释放。存储则是另外一个单独的横向扩展体系，不用跟着计算瞎折腾。

这个逻辑说起来简单，但很多没有实操过的人会忽略一个问题：计算集群释放之后，缓存也就没了。所以缩容不是简单的“节点减少”，它意味着缓存命中率会下降，导致任务重新去远端拉数据。这个细节在落地的时候一定要考虑进去，后面第四部分我会详细讲。

2.3 冷热数据同池：热数据给冷数据腾地方，是最大的隐性浪费

第三个老架构的痛点，是数据生命周期管理几乎做不起来。HDFS里的数据，一旦写入，就默认三副本，不管你是每天被访问几百次的活跃表，还是一年都没人查一次的归档日志，存储成本完全一样。我曾经统计过我们集群的数据访问情况，大概有接近45%的数据在过去180天内从来没被任何任务读过。但在HDFS统一存储模型下，这些冷数据占着跟热数据一样的存储资源，还要参与副本复制、数据均衡、节点心跳，甚至拖慢NameNode的元数据响应。

存算分离架构下，存储底座一般是可以配置多种存储策略的对象存储或者分布式文件系统。热数据放高吞吐的存储类型，冷数据自动转低频存储，再老一点的还能转归档存储。存储单价差别很大，低频存储通常只有标准存储的一半甚至更低，归档存储更是便宜。这一步做下来，存储成本的下降幅度非常可观，比你在计算引擎上抠参数来得直接得多。

3. 存算分离到底“拆”了什么：“三大解耦”才是本质

3.1 第一层解耦：计算与存储的物理分离，但元数据必须还在一起

很多人理解的存算分离，是“Spark跑在A集群，数据存在B集群”。这个说法对，但只说对了表象。更本质的拆解是三层：

第一层是计算资源与存储资源的物理解耦，也就是计算集群不再挂载存储节点，数据放在远程的、可以独立扩容的存储系统上。

第二层是元数据与数据的解耦。这里说的元数据，包括表的Schema、分区信息、文件路径、统计信息等，它们通常由Hive Metastore或者湖格式的Catalog（如Iceberg的Catalog、Hudi的表元数据）来管理。存算分离之后，元数据服务的地位变得更高了，因为任何计算集群都可以通过元数据服务找到数据位置。

第三层是计算引擎与存储格式的解耦。老架构下，Spark读HDFS上的Parquet文件，Hive也读HDFS上的Parquet文件，但它们的执行引擎、优化器、统计信息收集机制都是各自维护的。存算分离之后，大家共享同一份底层数据文件，只是用自己的引擎去读，格式层和表格式（Table Format）变成了共用的标准。

这三层解耦里面，我最想提醒的是第二层。很多团队做存算分离的时候，只想着把数据搬走，忽视了元数据服务的治理和重构。结果就是数据在远程，元数据还是每个计算集群各维护一套，Spark一套Hive表定义，Trino又一套，两边同步全靠手工，很快就对不上了。所以我一直觉得，存算分离改造的第一步不是搬数据，而是先把元数据架构理清楚，统一Catalog入口。

3.2 存储底座选型：对象存储不是唯一答案，HDFS也能做存算分离

提到存算分离的存储层，大多数人第一反应就是S3、OSS、OBS这些对象存储。这确实是主流选项，但不是唯一答案。我梳理一下常见的三种选择，各有各的适应场景：

对象存储（S3/OSS/COS等）：优点是完全弹性、按量计费、无限扩展、支持存储生命周期策略。缺点是延迟偏高（比本地HDD高一个数量级）、不支持随机写（只能覆盖写整个对象）、对小文件不友好、强一致性问题在某些环境需要确认。它适合作为主存储底座，尤其是海量数据、冷热分层诉求强的场景。

远程挂载的分布式文件系统（JuiceFS、Alluxio等）：本质是计算侧加了一层缓存，把对象存储封装成文件系统语义，提供更强的数据本地性缓存能力。如果你追求的是“SPARK照常跑、SQL语句不用改”的顺滑迁移，这类方案会更友好。代价是额外一套分布式缓存集群需要运维。

独立部署的HDFS集群：把老HDFS里的数据迁移到一个单独的、不再绑定计算任务的HDFS集群，计算集群通过hdfs://协议远程访问。这也能达到存算分离的目的，但HDFS本身维护成本高、NameNode仍有元数据压力，存储弹性比对象存储差很多。我自己的判断是，这是一个过渡方案，适合短期不想动历史数据的团队，但最终还是要往对象存储或云原生存储上引。

3.3 计算引擎侧：Spark、Flink、Trino的适配各有各的门道

存储底座定下来之后，计算引擎的适配是关键。不同引擎对远端读的适应能力差别很大，这里细说一下：

Spark：Spark是批处理引擎，跑长任务、大吞吐的ETL，对单次读延迟没那么敏感。它适配存算分离最常见的问题是Shuffle。老架构下，Shuffle的中间数据写在本地磁盘；存算分离后，如果你的Shuffle数据量很大，本地盘读写依然没问题，但如果你为了节省成本连本地盘都不想要了，就要考虑远程Shuffle Service。业界有Unshuffle、Remote Shuffle Service（RSS）之类的方案，但部署复杂度不低。我的建议是：Shuffle中间数据保留在计算节点本地盘，这只是临时文件，任务结束就清掉了，没必要追求极致的无状态化。真正需要远端读的是输入数据，也就是Source数据。

Flink：流式计算对延迟要求更严格。Flink有状态计算，状态数据（RocksDB或者内存状态）如果放远端，性能会灾难性地下降。所以在存算分离架构下，Flink任务只把输入数据的读取放在远端存储上，状态存储还是尽量留在本地。另外，Flink的Checkpoint可以写到对象存储上，这是很多团队已经接受的方案，比写HDFS省运维成本。

Trino/Presto：Trino是典型的MPP引擎，追求的正是低延迟的即席查询。它对远端读的性能非常敏感，所以每个Trino节点上的本地缓存、分布式缓存（如Alluxio）至关重要。我见过不少团队以为Trino直接读OSS就行了，结果跑一个复杂的Join查询，光拉取数据就花了翻倍的时间。

3.4 数据本地性的新定义：从NODE_LOCAL到“任意节点+智能缓存”

老架构的调度性能模型里，数据本地性是最核心的调度依据，NODE_LOCAL最优，RACK_LOCAL其次，ANY最差。但存算分离之后，计算节点和存储节点不在同一个物理机架甚至不在同一个机房，NODE_LOCAL这个概念已经不存在了。任何节点读远端数据的成本理论上是一样的，调度器可以从“考虑数据位置”变成“纯看资源可用性”。

但这不是说性能就一定好。远端读的网络开销是实打实的，所以出现了新的缓存层概念：把热点数据预取到计算节点本地，用本地缓存把这些数据装起来，后续任务再读时可以直接命中。

我自己的实践里，缓存层并不是所有任务都适合。日批任务读全量数据，缓存基本起不到作用，因为数据量太大，缓存永远装不下。倒是个别高频维表、热门的维度数据，缓存效果非常明显。所以做缓存设计的时候，别想着全局统一，要区分场景：ETL全量扫描不依赖缓存，即席查询和维表Join必须依赖缓存。

4. 从Hadoop到“存算分离”改造落地的完整路径

4.1 迁移前必须做的三件事：数据盘点、任务画像、元数据治理

很多团队迁移的第一反应是“写个分布式拷贝工具，把数据从HDFS拷到OSS”，这个顺序其实反了。我踩过坑之后总结出的正确顺序，是先做三件前置工作：

数据盘点：摸清到底有哪些库表、表多大、分区情况、压缩格式、小文件数量。这一步不需要特别复杂的工具，跑几个Spark SQL就能统计出来。但要注意，统计结果一定要落地成一份“数据地图”，这是后面迁移优先级排序的依据。

任务画像：统计每个任务调度的频率、一次读多少数据、任务的SLA要求、对延迟的敏感程度。我会把任务分成三类：第一类是核心业务日批任务，绝对不能出问题；第二类是一般性统计任务，可以接受一定时长的波动；第三类是探索性分析任务，随时可能调整SQL。这三类任务的迁移节奏完全不同，第一类要放到最后，第三类可以第一批切过去试水。

元数据治理：把Hive Metastore整理一遍。前面提到过，元数据是存算分离后所有计算集群共同依赖的部分，如果原来就有多个Metastore、多个Catalog，这时候就要统一了。另外对表的存储格式（Parquet/ORC）、压缩算法（Snappy/Zstd）、分区规范也要做一个标准化，因为迁移后如果格式不统一，查询引擎在谓词下推、列裁剪上的效果会大打折扣。

4.2 迁移执行：先跑双跑验证，再做灰度切流，最后才是全面切换

迁移过程我建议分三步走：

第一步是数据拷贝。常用工具是Spark的分布式写、或者专门的数据同步工具。数据拷贝这里最容易翻车的地方，是文件数量和对象存储的List性能。HDFS里的一个分区可能有几百上千个小文件，直接拷到对象存储，每次List操作都慢得让人崩溃。所以拷贝前要先做小文件合并，建议把文件合并到128MB～256MB，再写对象存储。

第二步是双跑验证。所谓双跑，就是在老架构和新架构上同时跑同一个任务，然后比对结果。双跑验证的项目包括：结果数据是否一致、任务运行时间对比、资源使用量对比、日志是否有异常。这里要特别提醒，双跑的比对不是一次性的，至少要覆盖一个完整的业务周期，比如日批任务就跑两周，把周末数据、月底结算数据都覆盖到。

第三步是灰度切流。切流的顺序很讲究，建议从非核心任务开始，再到查询类任务，最后才是核心批任务。切流的时候注意设置好回滚预案，一旦发现任务异常，快速切回老集群。

4.3 参数调优实战：那些影响性能的关键配置

存算分离之后，Spark和Trino读对象存储的性能，很大程度上取决于参数调优。我把最关键的几个参数和调优经验列出来，这部分是纯粹的“抄作业”环节：

关于网络参数，还有一个细节经常被忽略：连接超时。对象存储是公网或者专线访问，偶尔会有网络抖动，如果超时设置过短，任务会频繁失败重试。我一般把fs.s3a.connection.timeout设为180秒，fs.s3a.attempts.maximum设为20次，保证任务在面对网络波动时有一定的韧性。

4.4 缓存层怎么搭：Alluxio、JuiceFS还是纯本地缓存？

缓存层要不要上、上哪种，取决于你的查询模式。我见过以下几种组合：

没有缓存层：计算集群直接读对象存储。适合纯ETL批处理，因为每次读的都是全量数据，缓存没有意义。这种方案最简单，运维成本最低。

计算节点本地缓存：用SSD盘做本地缓存。Spark和Trino都可以通过配置实现。优点是不需要额外部署缓存集群，缺点是缓存容量受限于单节点磁盘大小，而且节点重启缓存就丢了。

分布式缓存层（Alluxio/JuiceFS）：独立部署的缓存集群，多个计算节点共享一份缓存数据。适合即席查询场景，多个引擎可以共享热点数据。缺点是部署运维复杂度高，如果数据本身没什么热点，这个缓存集群就是纯浪费。

表格对比一下：

如果你刚开始做存算分离，我的建议是第一版不要上分布式缓存。先把无缓存+节点本地缓存跑通，观察一段时间的任务表现，如果确实存在明显的热点数据重复读取，再考虑上Alluxio。

5. 存算分离带来的连锁反应：运维、成本与多引擎数据共享

5.1 运维模型被重构：扩容不再是“当天申请，三天交付”

老架构下扩容一次集群，从提交工单、采购服务器、上架配网、安装部署、数据均衡到业务恢复，通常要一周时间。这个节奏在业务是周更或者月更的场景下还能接受，但现在的业务方要求隔天甚至当天反应数据需求，这种节奏是跟上不上的。

存算分离之后，计算集群是无状态的。集群扩容变成了一次资源的“拉起”动作：只要有云资源配额或者裸金属资源池，节点启动后自动注册到计算集群，不需要经历数据均衡阶段，大概十几分钟就能上线。缩容也一样，节点可以随时释放，不用等副本迁移。

不过，这里的运维挑战也变了：你不再是一个HDFS管理员，而是一个资源调度管理员。需要关注的是Kubernetes上的Pod调度是否合理、节点的CPU/内存配比是否匹配实际任务、自动伸缩策略是否设置正确。原来那套“磁盘满了检查DataNode daemon日志、副本数降级跑fsck”的技能，慢慢就不太用得到了。

5.2 资源超卖可以做了，但别把内存超冒了

存算分离之后，计算集群的资源使用模式会发生一个显著变化：你再也不用为了“这个节点上某个盘满了”而无法运行任务了。数据都在远端，计算节点更像是一个“工位”，任务跑完就释放。这时候，超卖就成为一个技术可行且成本友好的策略。

超卖的意思是，调度器可以给一个节点分配超过其物理资源上限的任务。比如一个32核64GB内存的节点，你让它跑45个并发任务。CPU超卖问题不大，因为大多数任务CPU使用率不会持续打满，但内存超卖要格外小心。Spark Executor如果内存被超卖，非常容易触发OOM，而且一旦发生了，很难排查是哪个任务吃掉了内存。

我自己的经验是，CPU可以超卖到物理核数的150%～200%，内存在初期不要超卖，等稳定运行一段时间、调优出每个任务的具体内存画像之后，再小幅度超卖，比如从90%逐步上调到110%。这个节奏别贪快，内存超卖引发的问题比CPU超卖严重得多。

5.3 成本模型的变化：从“平均付费”到“按需付费”

这也算是存算分离落地后一个让财务满意的亮点。老架构下的成本模型非常粗放，所有数据都是三副本平均存储成本。存算分离之后，存储成本变成了分层计价：

• 热数据：标准存储，单价偏高，但响应快
• 温数据：低频存储，单价约为标准存储的40%～60%
• 冷数据：归档存储，单价约为标准存储的20%～30%，访问时需要先解冻

我们团队做完存算分离之后，把一大批超过半年没访问的历史数据转到了低频存储，再加上清理了重复的临时数据，整体存储成本降了差不多40%左右。而计算侧因为资源利用率上来了，实际上单位计算成本也有一定下降。

5.4 多计算引擎的一份数据共享：湖仓一体的雏形

存算分离的另一个隐性收益，是多计算引擎可以真正共享同一份数据。以前每个引擎都有自己的数据副本，Spark有一套分析宽表，Trino有一套，Flink又跑出一个Kafka的Topic，数据的多份复制不仅浪费存储，还容易造成数据不一致。

存算分离之后，底层是一份统一存储，上层是多个计算引擎。Spark批处理、Trino即席查询、Flink流式计算，它们可以同时访问同一张表，不需要为每个引擎各准备一份数据。如果要更严肃一点的表格式管理，可以引入Iceberg这种带ACID语义的表格式，进一步把数据的快照隔离做起来。这个时候的架构，就是现在常说的“湖仓一体”了。

6. 哪些场景不适合硬上存算分离：边界感比技术更重要

这部分可能是最容易被忽略的。存算分离不是银弹，它有自己的适用范围。我总结了几类不太适合的场景，供参考：

第一类，毫秒级延迟的在线查询场景。 如果你是做在线推荐的实时特征读取，每次请求要几百微秒内拿到特征数据，那存算分离实在不合适。对象存储的延迟比本地内存缓存高几个数量级，这种场景应该用Redis或者本地内存缓存，把特征数据加载进来，完全不是一套技术栈。

第二类，高频小文件访问的场景。 对象存储天生对小文件不友好。如果数据特征是大量几十KB的小文件，每次访问都要做一次HTTP请求，拉取开销、List开销都会成为瓶颈。这种场景更适合先把小文件合并成更少的大文件再考虑存算分离。

第三类，强一致性要求极高的交易系统。 存算分离架构下的存储层多数是最终一致性模型，虽然像S3在后端数据一致性上已经有很大改善，但对于那种要求严格ACID事务的在线交易系统，用一个传统关系型数据库会更稳妥，不必为了追赶“存算分离”这个热词而去动这类系统。

我做了一个自检清单，准备上存算分离的团队可以拿来问自己几个问题：

• 我的任务是否以批处理为主，对单次查询延迟容忍度超过数秒？
• 我是不是有明显的“计算不够、存储富余”的失衡现象？
• 我的数据有没有明显的冷热分层特征？
• 我是否需要让多个计算引擎共享同一份数据？
• 我是否有足够的时间去接受缓存层和网络IO的额外复杂度？

如果以上问题大部分是肯定的回答，那存算分离大概率适合你。如果基本是否定的，或者你只是单纯觉得“大家都在做，我也要搞一下”，那还是先把当前架构优化好再说。

7. 最后分享一点个人体会

做存算分离改造这一年多，最大的感受是：这个改造带来的收益是结构性的，但过程比想象中琐碎得多。它不是换个存储系统、改个访问路径就能完事的，而是整个大数据平台在架构范式上的一次迁移。数据本地性的包袱放下了，新的网络IO负担又扛起来了；扩容速度快了，运维的思维模式也得跟着变；存储成本下来了，但缓存层、网络带宽、元数据服务这些新环节又需要持续关注。

如果让我给正在考虑做这个事情的团队一个建议，那就是：不要一上来就追求“大而全”的存算分离，先挑出三类任务——探索分析类任务、非核心批任务、核心日批任务，依次迁移。每迁移一层，都要把性能、成本、稳定性三个维度对比老架构至少两周，再决定是否进入下一层。同时，务必把“回滚”预案做扎实，老集群先别拆，数据双跑验证的时间宁可多留，也不要急于切流。

技术选型的很多答案都不是非黑即白的。存算分离也是同样，它不意味着彻底告别HDFS，也不代表每个场景都要上对象存储。找到适合自己业务规模和团队能力的改造深度，才是更实际的事。