传统云数仓按峰值买资源，闲时 70% 都在空转。SelectDB Serverless 把计算、缓存、存储三层彻底拆开，配个弹性区间就能自动伸缩，弹性从 10 分钟级压到秒级。本文从零配置一个 Serverless 实例，实测弹性效果。
关键词：SelectDB · Serverless · 云数仓弹性 · 秒级伸缩 · 降本 · Pay As You Go · 阿里云
问题：为什么你的云数仓账单里 70% 的钱白花了
假设你的团队用云数仓支撑 BI 报表，每天上午 9-11 点是查询高峰，需要 64 核计算资源。其他 20 个小时负载很低，8 核就够。在传统固定规格模式下，你只能按 64 核购买------剩余 20 小时里 56 核都在空转，资源利用率不到 30%。
而且遇到临时大查询或突发流量，传统云数仓的扩容需要 10 分钟到小时级（节点拉起 + 缓存预热），期间查询延迟飙升，甚至可能触发雪崩。
SelectDB Serverless 的设计思路很简单：让资源跟负载走，高峰补齐，低谷释放，按实际使用量计费。
Step 1：理解三层解耦------为什么"弹性"要做到三层
传统存算分离架构（如 Snowflake）已经分离了计算和存储，但缓存仍然和计算节点绑定------固定核数对应固定容量的本地 SSD。想加大缓存提升命中率？不好意思，必须同时升级计算规格，等于为不需要的算力买单。
SelectDB Serverless 的做法是把三层全拆开：
传统架构： 三层解耦后：
┌─────────────────┐ ┌──────────┐
│ Compute Node │ │ Compute │ ← 按实际 CPU 使用率弹性
│ ┌───────────┐ │ ├──────────┤
│ │ Cache │ │ → │ Cache │ ← 独立弹性，不再绑死计算
│ ├───────────┤ │ ├──────────┤
│ │ Storage │ │ │ Storage │ ← 按实际数据量伸缩
│ └───────────┘ │ └──────────┘
└─────────────────┘这意味着：
- 扩容时计算层独立伸缩，不影响缓存命中率（因为缓存没跟着变）
- 想增加缓存容量提高热数据命中率？直接加缓存，不需要为额外的计算付钱
- 存储按实际数据量，删了数据账单自动降
Step 2：配弹性区间------只需要一个 min/max
在 SelectDB Serverless 控制台创建实例时，你只需要设一个弹性区间，比如：
计算弹性区间：8 CCU ~ 128 CCU剩下的全自动。系统会按以下规则决策：
yaml
扩容触发:
CPU: 5秒均值 > 60% # 一旦检测到持续高负载，立即触发
内存: 瞬时利用率 > 60% # 内存敏感场景也能及时响应
缩容触发:
CPU: < 30% # 双指标同时满足
内存: < 30% # 且持续 1 分钟以上才开始缩
策略: 渐进式缩容 # 避免频繁抖动设计原则很明确：扩容要果断，缩容要稳健。
除了简单的阈值规则，系统还有一层 AI 辅助决策------当弹性请求触发后，AI 会综合历史负载模式、周期特征和当前资源水位来判断这次扩容/缩容是否合理。相比纯规则策略，弹性准确率提升 40%。
什么场景能触发多少弹性？
| 场景 | 峰值 | 谷值 | 弹性倍数 | 适合 Serverless？ |
|---|---|---|---|---|
| 工作日 BI 报表 | 上午 64 核 | 夜间 8 核 | 8x | ✅ 典型场景 |
| ToC 日夜间流量 | 白天 128 核 | 凌晨 8 核 | 16x | ✅ 直接上限 |
| 大促秒杀 | 活动 256 核 | 日常 32 核 | 8x | ⚠️ 超 16 倍需横向 |
| 稳定 ETL | 全天 32 核 | 32 核 | 1x | ❌ 包年包月更划算 |
Step 3：验证弹性效果------一次完整的扩缩容过程
扩容（低负载 → 高负载）
触发条件：CPU 5 秒均值超过 60% 动作：系统在原地纵向扩容，计算规格实时上调 耗时：秒级 影响：正在执行的查询不受影响（原地伸缩 + 连接不断）
sql
-- 模拟高负载：并发跑大查询，CPU 撑到 70%
-- 控制台可观测到 CCU 从 8 自动升至 24 → 48 → 根据需要继续升缩容（高负载 → 低负载）
触发条件：CPU 和内存同时低于 30%，持续 1 分钟 动作：渐进式缩容，逐步释放计算资源 耗时：渐进式（非一次性降到谷值） 影响：查询不受影响
极端场景（峰谷比 > 16 倍）
纵向弹性上限是单集群 16 倍。大促等场景超过这个范围时，通过控制台触达横向弹性（增加节点数），耗时约 3 分钟，查询延迟有小幅波动但整体可控。
成本测算：Serverless vs 包年包月
回到开头 64 核 BI 场景做个简单估算：
ini
高峰期：4 小时/天 × 64 CCU
平峰期：6 小时/天 × 16 CCU
低谷期：14 小时/天 × 8 CCU → 这 14 小时原方案按 64 CCU 付费
弹性释放 = (64-8) / 64 = 87.5% >>> 28% 临界点当弹性可释放的计算资源超过 28% 时，Serverless 按量计费开始优于包年包月。87.5% 远超这个门槛，降本效果显著。
当然，如果你的负载长期稳定在 32 核，峰谷差异几乎为零，那包年包月更经济。Serverless 不是万能药，但峰谷越明显它越香。
缓存独立配置------一个容易被忽略的省钱点
在三层解耦架构中，缓存可以独立配置。实际场景中，你的查询可能只依赖 200GB 的热数据，但计算规格被峰值需求定在 128 核。传统架构下缓存跟着计算走，你只能接受 128 核对应的缓存容量（可能远超实际需求）。
SelectDB Serverless 允许你减小计算规格的同时保持甚至增大缓存容量，匹配实际的热数据量和查询并发，进一步优化成本结构。
适合什么样的团队
- BI 团队：工作日集中查询，夜间/周末几乎无负载，弹性释放比例极高
- AI Agent 平台：查询负载完全不可预测，模型调用可能随时爆发
- 不想管运维的数据团队：只设弹性区间，扩缩容全托管
- 成本敏感型创业公司：用多少付多少，没有沉没成本
关于 Apache Doris ：Apache Doris 是高性能实时分析数据库。SelectDB Serverless 基于 Doris 内核构建，在阿里云已正式商用。SelectDB 提供企业级支持。欢迎加入 Doris 社区。