数据仓库存算分离架构演进：决策点与落地路径

存算分离这几年从概念变成了主流数仓的默认选项，但"要不要分离"从来不是一道引擎选型题，而是一组围绕"计算与存储解耦"的架构决策：数据放哪、计算怎么弹性、缓存怎么设计、延迟和成本怎么取舍。本文以 Doris 3.0 与 StarRocks 3.x 的真实落地案例为主线（SelectDB 博客），拆解存算一体的瓶颈、存算分离的形态、缓存机制与弹性代价，最后给出落地路径与反模式。

先看存算一体为什么成为瓶颈。传统 MPP 数仓把计算与存储绑在同一批节点上，每个节点既跑查询又存数据，问题有三个。一是资源利用率低：CPU、内存、磁盘必须按同一比例扩容，业务高峰要扩计算，连带磁盘一起扩，扩出来的存储常常用不满；反之存储吃紧时，计算资源也被迫跟着买。二是弹性差：扩缩容要搬数据，分钟级甚至小时级，无法按查询负载快速拉起或释放计算。三是高可用成本高：为保证数据可靠，每个副本都占用计算节点的磁盘，多副本带来存储放大；节点故障后的恢复依赖数据重分布，恢复时间与数据量成正比。混合负载场景下，ETL 与即席查询抢同一批节点，问题还会叠加。

存算分离的形态可以分成四层来看。存储层：主数据放到对象存储（S3、OSS 一类），对象存储按量计费、天然高可用，不再与计算节点绑定；计算层：拆成多个计算组（compute group）或计算仓（compute warehouse），各自独立扩缩容，共享同一份数据，可以按业务或负载类型划分，例如一个组跑 ETL、一个组跑 BI 查询；元数据层：统一 catalog 与事务管理，保证多计算组看到一致的数据视图；缓存层：每个计算组在本地磁盘或内存维护热数据缓存，避免每次查询都走远程 IO。Doris 3.0 的存算分离模式以计算组形式组织计算资源、数据落对象存储；StarRocks 3.x 的 shared-data 架构同样把数据放到对象存储，以计算集群方式提供弹性，两者在形态上高度相似，差异主要在缓存与元数据实现的细节。理解这套分层，是后面所有决策点的基础。

缓存机制是存算分离成败的关键。数据从对象存储读取的延迟远高于本地盘，所以每个计算组必须有一层本地缓存：热数据分片按需拉取到本地，按 LRU 等策略淘汰，缓存命中时查询延迟可以接近存算一体，未命中时才回源对象存储。缓存又分两层：数据缓存与元数据缓存，元数据（文件列表、分区信息、统计信息）缓存不进，任何查询都要先访问对象存储的 list 请求，延迟和费用都会失控。缓存一致性是更隐蔽的坑：对象存储中的数据被写入任务更新后，各计算组的本地缓存必须失效，否则查询读到旧数据；主流实现依赖事务版本号或事件通知机制让缓存失效，落地时要把"数据更新到缓存失效"的延迟作为正确性指标来测试，而不是想当然。

决策点可以从五个维度评估。一是查询延迟敏感度：热数据缓存命中后延迟可控，但冷数据首次查询必须回源，如果业务对首次查询延迟敏感（比如交互式报表直接查历史分区），要把预热机制纳入设计。二是成本模型：对象存储单价低，但按请求次数计费，小文件多、list 频繁时请求费用可能吃掉存储省下的钱；数据规模在 TB 级以下时，分离带来的弹性收益有限，反而多一套缓存与元数据运维成本。三是网络带宽：计算组与对象存储必须在同一区域，跨地域访问的延迟与流量费用都不可接受。四是数据规模与访问模式：读写比高、热数据占比高的场景收益明显；写多读少、冷数据占比极高的场景要算清缓存命中率。五是运维复杂度：多计算组、缓存预热、一致性失效、对象存储权限与配额，都进入日常运维清单。

弹性代价是很多团队落地后才发现的。冷启动：新拉起一个计算组时没有缓存，第一批查询全部回源，延迟明显高于常态，需要预热或让负载自然"暖起来"。缓存预热：主动把热数据预拉到新计算组，需要一份可靠的访问热度清单，否则预热的就是冷数据。扩容后缓存重建与缩容后缓存失效同样需要时间窗口，弹性是"分钟级拉起"与"小时级回暖"的组合，宣传里的秒级弹性在真实查询延迟面前要打折。对象存储对小文件不友好，写入侧还需要合并与 compaction 机制，否则小文件会同时放大请求费用与查询延迟。

落地路径建议分四步。第一步评估：用真实查询统计延迟分位、热数据占比与数据规模，算出分离后的成本模型，明确"省了什么、多了什么"。第二步试点：选一个业务域或一类查询（比如历史分区报表）先迁到对象存储，保留原集群并行运行，用真实流量验证缓存命中率与延迟。第三步迁移冷数据：把不常访问的分区先迁走，热数据留在本地，逐步扩大分离范围。第四步固化：把缓存预热、一致性失效、配额与告警固化成运维流程。反模式也要记牢：无脑全量迁移、忽视请求费用、跨区域部署、对 TB 级以下小集群过度设计、以及把高频低延迟查询直接放对象存储而不做缓存规划，都是常见翻车点。

给一个决策示例。假设集群共 100TB 数据，其中 20TB 是近 30 天的高频访问热数据，80TB 是历史归档；当前 12 个计算节点平均使用率只有 40%，但查询高峰时 CPU 吃满。分离后可以把 80TB 冷数据迁到对象存储，计算节点缩到 8 个，热数据留本地，查询高峰时再弹性拉起 4 个临时计算组。这样存储成本下降（对象存储单价低于本地盘且按量计费），计算资源不再被数据拖累，代价是历史查询首次访问需要回源，缓存命中前 p95 延迟可能从几十毫秒升到秒级。如果业务里"查三年历史明细"是高频动作，就要为这段数据专门设计预热或保留部分本地副本，而不是一刀切全迁。

下一步建议：先做一周的真实查询画像（延迟分位、热数据占比、请求量），用这份数据跑一遍成本模型，再选定一个低风险业务域启动试点迁移，以试点期的缓存命中率与 p95 延迟作为是否扩大范围的决策依据。