白天查数、凌晨跑批：聚水潭如何基于 StarRocks 将资源利用率提升 3x

作者：番杏（张国鑫），大数据开发专家｜溪竹（李月），高级大数据开发专家

每天早高峰，电商商家陆续打开聚水潭后台，查看销售、库存、订单等核心报表。对商家来说，这只是一次普通的经营分析；但对底层数据平台来说，却意味着大量在线查询在短时间内集中到来。

与此同时，平台还需要承载离线计算、数据加工等任务。一旦计算任务占用过多资源，在线查询就容易受到影响，核心报表响应变慢，用户体验随之下降。

聚水潭数据团队面临的挑战，并不只是"让某几条查询更快"，而是如何在多业务、高并发、混合负载场景下，让查询与计算资源互不干扰，同时提升集群利用率、降低长期成本。

围绕这一目标，聚水潭数据团队基于 StarRocks 推动了三阶段架构演进，最终实现：

• 核心业务查询 P99 延迟 下降超过 36.6%

• 月均基础设施成本 降低 44.2%， 年度节省超 50 万元

• 集群资源平均利用率从不足 30% 提升至 78%

• 查询与计算资源彻底解耦， 避免相互影响

一、 原有架构瓶颈

随着业务规模持续增长，数据平台同时面临查询、计算和资源利用率三方面压力。

1.1 三大业务特征， 持续拉高数据平台复杂度

• 高并发、多主题查询

平台覆盖销售、库存、广告、利润、售后等多个分析主题。日间高峰时，数千商家会同时在后台查询报表；单个商家每天也可能查看数十种不同报表，对数据库的即席查询能力和高并发稳定性提出了很高要求。

• 海量数据批处理。

订单、库存变动、广告消耗等数据，需要在次日凌晨完成统一清洗、计算和入库。整体数据写入规模达到百亿级，主要集中在凌晨 04:00--08:00 的批处理窗口内。

• 明显的"潮汐型"资源特征

白天（09:00--18:00）是查询高峰，凌晨（04:00--08:00）则是计算高峰，两类负载在时间维度上几乎完全错开。

但在传统架构下，查询与计算往往由不同系统分别承担，比如使用 ODPS（MaxCompute） 承载计算，StarRocks 仅提供查询服务。这种模式虽然实现了职责拆分，但也导致查询集群与计算集群彼此独立：白天查询资源繁忙，而凌晨大量查询资源实际上处于闲置状态，整体资源利用率并不理想。

图 1：计算引擎资源消耗曲线

图 2：SaaS 查询业务资源消耗曲线

1.2 存算一体架构下，资源隔离与弹性开始成为瓶颈

在 StarRocks 存算分离改造前，聚水潭采用的是传统存算一体架构。随着业务规模扩大，这种架构在混合负载场景下逐渐暴露出三个问题。

• 计算与查询互相影响，故障容易扩散。 大促期间，如果离线计算任务出现延迟，就可能与早高峰的在线查询重叠。当 CPU 和 I/O 资源被大量占用时，受影响的不是某一张报表，而是整个集群上的查询响应。由于计算任务和查询任务共享同一组 BE 节点，资源争抢会直接影响在线业务稳定性。

• 资源利用率偏低，扩容成本较高。 为了保障白天查询高峰性能，集群往往需要按照峰值负载部署。但在凌晨查询低谷期，大量计算资源处于闲置状态。与此同时，存算一体架构下计算与存储绑定，扩展计算能力通常也意味着同步扩展存储资源，导致扩容成本和周期都比较高。

• 批处理响应周期较长。 当业务规则调整、需要重算历史数据时，传统架构下一次大规模批处理通常需要 30 分钟到 1 小时。对于依赖报表进行经营决策的商家来说，这样的延迟会影响数据更新效率和业务响应速度。

图 3：多业务混合负载影响查询性能

这些问题背后的根因相对明确： 计算与存储耦合，查询与计算混跑 。对应的优化方向也很清晰------解耦、隔离和弹性。

二、整体架构演进：从物理隔离到智能调度

聚水潭的数据平台演进并不是一次性替换，而是围绕"解耦、复用、降本"逐步推进。

2.1 阶段一：基于存算分离的多 Warehouse，实现资源隔离

架构改造的第一步，是将计算和存储从物理层面拆开。基于 StarRocks 存算分离架构，聚水潭将整体架构拆分为三层：

• FE（Frontend） ：统一 SQL 入口，屏蔽底层引擎差异

• CN（Compute Node） ：无状态计算节点，负责查询计算和本地缓存，不持久化数据

• OSS（对象存储） ：作为共享存储底座，承载持久化数据

在此基础上，聚水潭进一步使用 StarRocks 多 Warehouse 机制，对计算资源进行物理隔离：

• Query Warehouse（查询仓） ：面向在线 BI、即席查询、API 服务，保障 7×24 小时低延迟查询

• Compute Warehouse（计算仓） ：承载离线 ETL、批量导入和历史数据重算等任务

不同 Warehouse 之间资源相互独立。离线计算任务即使占用大量 CPU 和 I/O，也不会直接影响在线查询。查询仓与计算仓可以按各自负载独立扩缩容，避免了存算一体架构下"扩计算必须同步扩存储"的问题。

图 4：存算分离架构图 --- FE/CN/OSS 三层 + 双 Warehouse

落地挑战：存算分离后的写入吞吐问题

切换到存算分离架构后，计算节点不再持久化数据，数据读写都需要通过 OSS 完成。在大规模写入场景下，聚水潭很快遇到了新的瓶颈：写入吞吐受限，Compaction Score 持续升高，CPU 使用率也随之上升。

问题的根因在于，OSS 成为了所有 I/O 的关键路径，而原有网络与写入模式还没有针对高吞吐场景完成优化。

为解决这一问题，聚水潭数据团队一方面升级了内网带宽，提升 OSS 访问能力；另一方面与 StarRocks 社区持续沟通，对历史表启用 file_bundling 优化写入模式，并开启 merge-commit 参数，减少小文件带来的写放大。

经过验证后，相关优化通过版本升级对新表默认生效，写入链路逐步稳定下来。

图 5：File_bundling 优化前后 OSS 写入吞吐对比

图 6：merge commit 优化前后 OSS 写入吞吐对比

2.2 阶段二： 跨 Warehouse 调度，提升计算资源利用率

存算分离解决了查询与计算互相影响的问题，但在实际运行中，聚水潭又发现了新的资源浪费：

• Query Warehouse 白天负载较高， 夜间 CPU 利用率仅约 20%

• Compute Warehouse 白天基本空闲，凌晨批处理窗口又容易达到负载峰值

也就是说，查询和计算虽然完成了隔离，但资源仍然被固定在不同 Warehouse 中，无法根据业务负载在时间维度上灵活复用。对于"白天查询高峰、凌晨计算高峰"这种典型潮汐负载，单纯的物理隔离并不能充分释放资源价值。

基于这一特征，聚水潭数据团队进一步设计了跨 Warehouse 动态调度机制，如下图所示：

图 7：图为实例趋势，实际节点数据可能根据任务进度动态调整

具体调度策略如下：

• 凌晨 01:00 ：从 Query Warehouse 调出 14 个节点，挂载到 Compute Warehouse，将夜间闲置的查询资源复用于批处理计算；

• 早上 08:40 ：将出借节点切回 Query Warehouse，并自动预热本地 NVMe 缓存，确保 09:00 查询高峰到来前恢复在线查询能力。

这一机制基于 StarRocks ALTER SYSTEM 命令和弹性 Warehouse 特性实现，由聚水潭自研调度脚本完成自动化编排。在不新增机器的前提下， 集群资源利用率从不足 30% 提升至 78%。

落地挑战一：节点切换带来的任务重试与资源争抢

当节点在不同 Warehouse 之间切换时，部分正在运行的离线计算任务会因为节点下线而触发重试。与此同时，Tablet 迁移和数据均衡也会占用 I/O 资源，导致计算任务与均衡任务在同一时间窗口内竞争资源，反而影响了批处理产出时效。

图 8：节点迁移示意图

针对这一问题，聚水潭数据团队与 StarRocks 社区协作优化了均衡算法，将均衡时间压缩到 60 分钟以内。

图 9：Tablet 均衡时间线优化对比

在后续阶段，聚水潭进一步引入"移动计算"的思路：不再频繁搬动资源，而是让任务根据资源状态进行调度，从根本上减少节点切换带来的干扰。

落地挑战二：节点归还后，查询性能无法立即恢复

跨 Warehouse 调度上线后，每天早上 08:40，节点会从 Compute Warehouse 归还至 Query Warehouse。按预期，查询仓资源恢复后，在线查询性能也应随之恢复。但在实际运行中，查询耗时并没有立刻回到正常水平，早高峰报表仍然存在延迟。

进一步排查后，团队发现问题主要来自三个方面。

• 历史表分区设计不合理。 部分历史表分区粒度过细，导致 Tablet 数量远超合理范围。当 14 个节点跨仓转移时，需要重新均衡的 Tablet 数量非常庞大。早期一次均衡耗时可达 120 分钟，而均衡尚未完成时，早高峰查询已经开始进入高峰。

• Colocate Group 表数量过多。 Colocate 表要求同一 Group 内的 Tablet 分布在固定节点集合上。一旦节点发生变更，Group 内相关表的 Tablet 都需要重新迁移和均衡。这会进一步放大节点切换后的数据均衡压力。

• 节点切换导致本地缓存失效。 CN 节点切换 Warehouse 后，原有本地 NVMe 缓存无法继续复用，查询需要回源 OSS 读取数据。冷启动阶段，查询延迟因此明显上升。

图 10：跨仓调度后查询延迟

2.3 阶段三： 混合计费与弹性资源，进一步优化成本结构

跨 Warehouse 调度让计算资源具备了"流动性"，但节点转移本身仍然会带来额外成本，包括任务中断重试、Tablet 重新均衡、本地 Cache 失效等。也就是说，阶段二虽然提升了资源利用率，但仍需要进一步降低节点频繁切换带来的干扰。

因此，聚水潭在第三阶段将优化目标调整为： 在保持资源稳态的前提下，更精细地控制计算成本。

策略一：混合计费模型。

自动化流程：监控上游数据准备完成 → 调用云 API 购买按量节点 → 加入集群执行任务 → 进度 >99% 触发优雅下线释放资源。内置不同规格机型 fallback、任务失败自动重试、最晚完成时间告警等保障。

策略二：引入"移动计算"机制。

在凌晨时段，Query Warehouse 本身处于低负载状态。相比将节点从 Query Warehouse 搬到 Compute Warehouse，聚水潭选择将部分计算任务调度到 Query Warehouse 执行。

这样一来，不再需要频繁移动节点，也就减少了 Tablet 均衡和本地 Cache 失效带来的影响。

同时，聚水潭对任务运行窗口进行了限制：Query Warehouse 仅在 08:30 前同时承载查询和计算，并通过 StarRocks Resource Group 对不同任务进行资源隔离，确保核心查询 SLA 不受影响。

图 11：混合计费 + Resource Group 隔离架构图

相关参数说明：

• default_wg（查询仓-查询）：设置专属 CPU 核，用于保障核心查询 SLA

• rg_slow_query（查询仓-计算）：通过分类器识别并承载迁移至查询仓执行的计算任务

• rg_load（计算仓）：限定 user=jst_data_compute ，仅放行指定导入任务

落地挑战一：OSS 侧带宽与 QPS 限制

移动计算跑通后，Compute Warehouse 的弹性节点与 Query Warehouse 中的计算任务会同时访问 OSS，整体读写流量显著上升：内网流入达到 30 Gb/s， 流出超过 100 Gb/s， QPS 达到 50,000+。

这也说明，阶段一解决的是存算分离后的基础写入吞吐问题；而到阶段三，当计算资源被更充分地调度和使用后，OSS 侧的带宽与 QPS 配额开始成为新的瓶颈。

针对这一问题，聚水潭数据团队多次与云厂商协调，提升 OSS 侧带宽及相关配额。

图 12：OSS 多轮提升限速阀值，最大吞吐超 100Gb/S

落地挑战 二 ：高并发调度下的 FE 锁竞争问题

在前两个瓶颈逐步解决后，多 Warehouse 调度开始稳定运行。也正是在这一阶段，FE 层一个更深层的并发问题开始暴露出来。

当多仓业务同时高负载运行时，监控出现告警：FE 内部锁竞争加剧，并进一步造成查询阻塞。排查发现，当时数据库中超过 1800 个并发操作被阻塞，锁持有时间也从最初的 3 秒逐步上升至 116 秒。

图 13：StarManager Slow Lock 产生集群可用性风暴

问题根因在于 Broker Load 规划阶段的锁持有时间过长。

在原有实现中，Broker Load 规划阶段需要为每张表的每个 Tablet 查询写入位置，即 createLocation 。对于一张包含数千个 Tablet 的表，这意味着需要发起数千次 RPC 请求。

更关键的是，这些 RPC 请求是在持锁期间完成的。一旦某个 Tablet 出现副本缺失，StarOS 会触发副本重建，而这是一个同步阻塞操作。当线程池槽位被占满后，后续请求只能排队等待，锁也会被持续持有，最终放大为 FE 层的锁竞争问题。

可以把它理解为： 过去是"拿着公章逐个确认"，只要中间一个环节卡住，后面所有人都只能等；优化后则是"先批量确认信息，再集中盖章"，锁内只保留必要操作。

针对这一问题，聚水潭数据团队与 StarRocks 社区联合修复，将"逐个 RPC 查询"改为"批量预取"机制：系统会一次性收集所有 Tablet ID，发起批量查询，并将结果写入 Map，后续可通过 O(1) 复杂度直接获取；只有极少数未命中的 Tablet 才会走单点查询 fallback。

修复后，锁持有时间从 116 秒降低至 100 毫秒级别，FE 层的查询阻塞问题得到解决。

至此，多 Warehouse 负载隔离能力才真正稳定下来。从存算分离改造，到跨仓调度、移动计算，再到 FE 锁竞争问题修复，聚水潭逐步完成了查询与计算资源的解耦，使不同负载能够在同一平台上稳定运行、互不干扰。

2.4 弹性资源调度最佳实践

弹性资源调度并不只是"任务来了扩容、任务结束缩容"，而是需要在高频操作中建立一套稳定、可控的调度机制。聚水潭在实践中总结了四个关键原则。

• 上游事件触发，避免资源空转。

弹性扩缩容不再依赖固定时间点启动，而是由上游数据就绪事件触发。例如，当 MaxCompute ETL 任务完成后，通过回调通知守护进程，再发起按量节点申请。

这样可以避免资源已经扩容完成、但上游数据尚未产出的情况，确保按量资源真正用于有效计算。

图 14：极致弹升带来极致的资源利用率

• 进度持续监控，支持二次弹升。

任务执行过程中，守护进程会持续监控任务进度。如果在当前资源配置下，任务进度已经接近或低于 SLA 红线，系统会自动触发二次弹升，追加按量节点参与计算。

反之，如果任务进度提前完成，也会立即触发资源释放，而不是等待固定时间窗口结束。这样，弹性资源调度不再是一次性扩缩容，而是基于任务进度的闭环反馈。

• 手动任务可命令行触发弹升。

并不是所有计算任务都来自定时调度。对于运维人员临时发起的补数、回刷等任务，聚水潭也支持通过命令行交互触发资源弹升。

运维人员只需要输入命令，指定任务和预期资源量，守护进程即可自动完成资源申请、节点挂载、任务执行和资源释放等流程。这样，临时任务也可以复用与定时任务一致的弹性资源能力。

图 15：对话形式操作扩容计算 warehouse

• 多规格 fallback，提升资源申请成功率。

云厂商的按量资源并非始终充足。为提高弹性资源申请的成功率，聚水潭在调度流程中内置了多规格 fallback 机制。

例如，当 32 核规格资源申请失败时，系统会自动降级尝试 16 核规格，并通过组合多个小规格节点补足整体算力。对于单次申请失败的情况，系统也会自动重试，并结合最晚完成时间告警，确保在资源紧张时仍然具备可用的兜底路径。

2.5 持续优化任务优先级策略

随着核心任务数量增加，不同任务之间的资源竞争也开始显现。为进一步提升调度稳定性，聚水潭正在从任务侧和引擎侧两个方向推进优先级策略优化。

方向一：在任务侧控制并发与执行优先级。

通过控制不同任务的并发度，区分任务优先级；同时，为不同 Broker Load 任务设置优先级参数，决定任务执行顺序。这样可以优先保障高优先级业务的数据产出，低优先级任务则进入排队等待。

方向二：推动引擎层支持查询队列优先级。

聚水潭已向 StarRocks 社区提交相关需求，希望查询队列能够提供原生的优先级分级能力。相比只从资源维度进行隔离，查询队列优先级可以进一步从业务维度定义任务执行顺序。

未来，不同业务链路、不同报表主题可以获得差异化 SLA 保障：核心报表优先响应，长尾查询排队等待，从而在资源有限的情况下提升整体服务稳定性。

三、技术架构全景与效果评估

3.1 智能弹性架构

图 16：整体技术架构全景图

图 17：业务效果一览图 - 计算峰值

图 18：业务效果一览图 - 查询峰值

3.2 升级效果概览

以单 BI 业务为例，假设业务需要在 08:30 前完成 1000 CU 计算任务，并支撑约 100 TB 数据存储。基于查询性能优先、计算/存储配比最优的原则，测算中选用 i2.8xlarge 本地盘 ECS 规格进行对比。

图 19：i2.8xlarge 规格参考

模式一：存算一体架构

在存算一体模式下，集群配置为：

• FE：3 × g6.4xlarge

• CN：46 × i2.8xlarge

该模式下，为保证高可靠，数据至少需要 3 副本。同时考虑最大 95% 的锁盘阈值，100 TB 数据至少需要 46 台 CN 承载。

计算逻辑如下：

100 TB × 3（副本数） ÷ 0.95（锁盘阈值） ÷ 6.87 TB（单机磁盘） ≈ 46 台

模式二： 存算分离 架构

在极致弹性模式下，集群配置为：

• FE：3 × g6.4xlarge

• 常驻 CN：10 × i2.8xlarge （包年包月）

• 弹性 CN：20 × i2.8xlarge （按量弹升）

• 存储：OSS

该模式下，存储由 OSS 承载，计算资源可以按需配置。结合实际查询流量，8 台 CN 即可满足日常查询；计算高峰期再通过弹性节点补足算力。

资源状态可以分为两种：

• 日常态 ：2 个计算仓 CN + 8 个查询仓 CN + OSS 存储

• 弹升态 ：22 个计算仓 CN + 8 个查询仓 CN

相比存算一体模式，模式二显著减少了常驻 CN 数量，存储则由 OSS 承载，可按需扩展。虽然弹性节点的按量单价更高，但只要弹升时间控制在合理范围内，整体成本仍然更优。

以 ecs.i2.8xlarge 为例：

• 按量计费：10.708 元/小时

• 包年包月：74,131.2 元/台（三年 4 折）

可计算出单台机器的日均包年成本对应的按量使用临界点：

74,131.2 ÷ 3 ÷ 365 ÷ 10.708 ≈ 6.32 小时

也就是说，如果单台弹性节点每天使用时间少于 6.32 小时，按量弹升相比长期包年更具成本优势；弹升时间越短，节省效果越明显。

图 20：弹升时间和费用的线性关系

从初始架构到最终态架构，关键性能、成本与运维指标对比如下。为便于统一测算，本文采用以下费用口径：

• ecs.g6.4xlarge （16C 64G）：19,756.8 元 / 3 年（折后价）

• ecs.i2.8xlarge （32C 256G）：74,131.2 元 / 3 年（折后价）；按量计费 10.708 元 / 小时

• OSS 标准型存储：0.12 元 / GB / 月

四、实践总结

如果你所在团队也面临"混合负载、潮汐明显、成本敏感"的挑战，这套三步路径可以直接复用：

1. 空间解耦。

先将不同性质的负载隔离开：查询归查询，计算归计算。基于 StarRocks 存算分离架构和多 Warehouse 机制，可以较低改造成本完成这一步。

但在落地前，需要提前评估 OSS 带宽与 QPS 配额。存算分离后，数据读写都会经过 OSS，I/O 压力可能会比预期更早成为瓶颈。

1. 时间复用

如果业务存在明显潮汐特征，通常意味着部分算力会在不同时段闲置。通过自动化调度，可以在不新增机器的前提下提升资源利用率。

不过，在引入节点调度前，需要重点检查表分区设计、Tablet 数量以及 Colocate Group 使用情况。否则，历史表设计问题可能会在节点变更时集中暴露，带来额外的均衡压力和查询延迟。

1. 成本精细化。

以包年包月资源承载稳定负载，以按量资源覆盖短时峰值负载，是更适合潮汐型业务的成本模型。

当跨 Warehouse 调度稳定后，还可以进一步从"移动资源"演进到"移动计算"，减少节点迁移带来的 Tablet 均衡和本地 Cache 失效问题。同时，弹性资源调度需要形成闭环：上游数据就绪后触发、任务进度滞后时二次弹升、临时任务也能通过命令行触发。

最后，当资源利用率被充分拉高后，新的瓶颈可能会出现在 FE、OSS 或调度链路等更深层的位置。因此，容量规划不能只关注计算节点，也需要同步关注 FE 规划能力、元数据管理、锁竞争和对象存储侧配额。

聚水潭在这个过程中先后遇到了 1000 CU 压测下的 FE 资源瓶颈，以及高并发调度下的 FE 锁竞争问题。提前关注这些环节，可以帮助类似场景的团队少走一些弯路。

五、未来演进方向

1. 面向业务的成本治理

后续，聚水潭计划进一步完善成本治理能力，将资源成本按商家、报表主题等维度进行核算和分摊，并引入预算预警与 Admission Control 机制。

这样可以让不同业务场景的资源消耗更加透明，也便于在成本、性能和服务等级之间做更精细的平衡。

1. 面向 Data Agent 的基础能力建设

当前这套弹性调度体系已经实现了资源按需供给和任务自动化编排。下一步，聚水潭计划在此基础上构建 Data Agent 服务层。

未来，商家或内部运营人员可以通过自然语言发起数据查询和分析请求，由 Agent 自动解析意图、规划执行路径，并调度 StarRocks 弹性资源完成计算和结果返回。

总结

StarRocks 存算分离架构为聚水潭提供了弹性资源底座，但真正让这套架构发挥价值的，是"空间解耦---时间复用---成本精细化"的持续演进。

从存算分离改造，到跨 Warehouse 调度，再到混合计费与移动计算，聚水潭并不是一次性完成架构升级，而是在真实业务压力下持续验证、调整和优化。写入吞吐、Tablet 均衡、Cache 失效、OSS 限流、FE 资源瓶颈、锁竞争问题，每一次挑战都进一步明确了存算分离架构在大规模混合负载场景下的能力边界和优化路径。

对于类似场景下的团队来说，这个案例的价值不只在于最终方案，更在于演进过程中沉淀出的工程经验。如果你的团队也在推进类似架构升级，欢迎在评论区分享你们的实践与思考。