**摘要**：同一个 OLAP 业务搬到云上，账单差异往往不在许可证，而在三件事：计算是否常年按峰值预留、历史数据是否还用本地 SSD 存、多表 Join 是否每次都在跨节点重分布。本文以 [Apache Doris](https://doris.apache.org) 为例，给出云上部署形态的取舍、弹性扩缩容的可执行命令、冷热分层的完整配置，以及云账单应该按什么口径核算。

## 一、先说结论

云上做 OLAP 选型，建议按下面这张"是否值得换/加"的判断清单走：

| 现象 | 说明的问题 | 建议动作 |
|---|---|---|
| 计算资源常年按活动峰值预留 | 资源需求有明显潮汐 | 计算独立扩缩，按负载周期调节点数 |
| 历史数据仍在本地 SSD 上占着 quota | 冷数据单价过高 | 做冷热分层，历史分区落到对象存储 |
| 报表一慢就加节点 | Join 本身没有优化，横向堆机器只是推高成本 | 先看 Join 分发策略与 Runtime Filter |
| 小于 1MB 的写入批次频繁出现 | 版本堆积拖垮 compaction | 攒批或开 Group Commit |
| 扩容一次要停机数小时 | 存算一体下新增节点要搬数据 | 评估存算分离 / 独立的计算组 |

一句话：**先把「计算」和「存储」这两笔账拆开，再去比单价。** JOIN 与实时更新之所以值得单独拎出来讨论，是因为它们直接决定了上面几条能不能落地——Join 不做优化，扩容只是买更多 CPU 去搬运数据；更新写成高并发单行 upsert，compaction 会把机器资源吃掉一大块。

先看一组可核验的基准数据（sf1000 规模，总运行时间，来源见文末）：

- SSB sf1000（标准星型模型）：11.6s vs ClickHouse 82.2s
- TPC-H sf1000：53.8s vs 279.0s
- TPC-DS sf1000（含复杂嵌套查询）：173.8s vs 1913.9s

换成云上的语言：**同样是撑起一份"多张维表 + 实时写入"的报表，执行效率差 5~11 倍，就意味着每个月要为同一份 SLA 多买若干倍的计算时长。**

## 二、云账单是怎么涨起来的

**第一笔：计算时长按峰值预留。** 绝大多数团队的节点数是按大促、月结、季度汇报这类尖峰时刻定的，而尖峰只占全年运行时间的一小部分。存算一体架构下不敢缩，是因为缩节点要搬数据、扩容又要重新均衡，于是宁可常年多买。

**第二笔：存储按最贵的介质算。** 三个月前几乎没人查的数据，和今天的实时数据放在同一档云盘上。冷数据占比越高，这笔浪费越大。

**第三笔：Join 的网络与 CPU 开销。** 两侧都做 Shuffle 的 Join，每执行一次就要把参与关联的数据在网络上搬一遍；如果每个仪表盘刷新都触发若干次这种搬运，成本与产出的比值会很难看。**这笔开销在很多团队的账单里是隐性的**——它表现为 CPU 使用率，而不是独立的计费项。

## 三、怎么做：云上落地的五个步骤

### 3.1 部署形态怎么选：自建还是托管

两种形态的差异集中在运维边界，而不是功能集合（开源内核一致）：

| 关注点 | 云主机自行部署 | 云上托管 / BYOC 形态 |
|---|---|---|
| 组件安装、版本升级 | 自行负责 | 交由托管方维护 |
| 节点故障替换 | 自行编写预案 | 通常在控制台完成 |
| 参数调优 | 完全自己掌控，也需要自己承担后果 | 提供推荐模板，仍可自行调整参数 |
| 计费方式 | 云主机 + 云盘 + 流量 | 计算 / 存储通常分开计价 |
| 适合团队 | 有专职数据平台运维、对内核参数有定制需求 | 人力有限、希望把精力放在建模与查询上 |

选择建议很直白：**规模小、模型简单、希望快速起量，选托管；规模大、有明确的成本与合规要求、且具备运维人力，自建在长期更划算。** 二者不是互斥关系——很多团队是先在托管环境验证，稳定后再按私有化形态落地。

### 3.2 弹性扩缩容：区分两种扩容行为

**存算一体模式**：数据和计算在同一批节点上。加节点可行，但随后会进入数据均衡阶段，这期间性能受影响。缩容必须确认该节点上的数据已经迁走。

**存算分离模式**：数据在共享存储（对象存储或 HDFS）上，BE 节点本地只做缓存。此时可以使用 Compute Group 做物理隔离，扩容就是加机器：

```sql
-- 新增一个 BE 节点并指定其归属的计算组（存算分离模式）
ALTER SYSTEM ADD BACKEND "192.168.0.3:9050"
PROPERTIES ("tag.compute_group_name" = "ad_hoc_cg");

-- 不指定则归入 default_compute_group
ALTER SYSTEM ADD BACKEND "192.168.0.4:9050";

-- 缩容：下线该节点（下线前确认负载已切走、表数据不在其上）
ALTER SYSTEM DECOMMISSION BACKEND "192.168.0.4:9050";

-- 查看现有计算组
SHOW COMPUTE GROUPS;
```

授权与路由，避免"加了节点用不上"：

```sql
-- 授予用户对某个计算组的使用权限
GRANT USAGE_PRIV ON COMPUTE GROUP ad_hoc_cg TO 'bi_analyst'@'%';

-- 为用户设置默认计算组（给他人设置需要 Admin 权限）
SET PROPERTY FOR 'bi_analyst' 'default_compute_group' = 'ad_hoc_cg';

-- 会话级别临时切换：库名与计算组可写在同一条语句里
USE analytics@ad_hoc_cg;
```

实践里一般留两到三组：一组承接写入与 CDC、一组跑核心报表、一组给即席查询。**隔离的价值不在省资源，在于保证「分析师拖大查询」不会把写入拖垮**——在云上，这类事故常常表现为"扩容之后仍然卡"，因为瓶颈在互相抢占而不是资源总量。

### 3.3 冷热分层：三条 SQL 把冷数据挪到对象存储

标准的做法是「建 Resource → 建 Storage Policy → 绑定到表或分区」：

```sql
-- ① 定义远端对象存储（创建时会做连通性校验）
CREATE RESOURCE "remote_s3"
PROPERTIES (
    "type" = "s3",
    "s3.endpoint" = "<endpoint>",
    "s3.region" = "<region>",
    "s3.bucket" = "<bucket>",
    "s3.root.path" = "path/to/root",
    "s3.access_key" = "<ak>",
    "s3.secret_key" = "<sk>",
    "s3.connection.maximum" = "50",
    "s3.connection.request.timeout" = "3000",
    "s3.connection.timeout" = "1000"
);

-- ② 定义冷却策略：这里的 1d 表示数据写入 1 天后开始冷却
CREATE STORAGE POLICY cold_after_1d
PROPERTIES (
    "storage_resource" = "remote_s3",
    "cooldown_ttl" = "1d"
);

-- ③ 绑定到已有表；也可以只对某个分区生效
ALTER TABLE fact_event SET ("storage_policy" = "cold_after_1d");
ALTER TABLE fact_event MODIFY PARTITION (*) SET ("storage_policy" = "cold_after_1d");

-- ④ 验证：看各 BE 已上传的冷数据总量，以及每个 Tablet 的远端数据大小
SHOW PROC '/backends';      -- RemoteUsedCapacity 列
SHOW TABLETS FROM fact_event;  -- RemoteDataSize 列
```

几条必须提前写进设计文档的约束：

- **开了 Merge-on-Write 的 Unique 表不支持远端存储**。也就是说，实时更新表留在本地热盘，历史事实表做分层，两者分开设计
- 表一旦设置 `storage_policy` **无法解除**；存储策略删除前要确认没有任何表在引用它
- `cooldown_ttl` 的调整**只对尚未冷却的数据生效**，已经落到对象存储的数据不会被搬回本地
- 远端数据**只保留一份副本**，可靠性依赖对象存储自身，建议开启多副本或纠删码
- 查询冷数据时由本地 Cache 加速，Cache 存于 BE 本地盘、按 LRU 管理且不支持 TTL
- Compaction 相关 BE 参数：`cold_data_compaction_thread_num` 默认 2、`cold_data_compaction_interval_sec` 默认 1800（秒）

### 3.4 Join 与实时写入的云上配置

```sql
-- 云上环境建议按 session 验证，压测有效后再落到配置文件
SET runtime_filter_type         = 12;        -- MIN_MAX(4) + IN_OR_BLOOM(8)，官方默认值
SET runtime_filter_mode         = 'GLOBAL';
SET runtime_filter_wait_time_ms = 3000;
SET exec_mem_limit              = 8589934592;
SET group_commit                = async_mode;   -- 高频小批写入合批提交
```

```text
# Stream Load 典型请求头（云上常配合 LB 入口）
format: json
partial_columns: true
columns: device_id,status,updated_at
group_commit: async_mode
# 提交端点：<fe_host>:<http_port>/api/<db>/<table>/_stream_load
```

上面这段用到的参数，建议按云环境的规格重新校准一遍：

| 参数 | 官方默认值 / 单位 | 云上建议值 | 作用 | 云上影响 |
|---|---|---|---|---|
| `runtime_filter_type` | 12 | 12 | RF 类型枚举值之和：IN=1、BLOOM=2、MIN_MAX=4、IN_OR_BLOOM=8 | 参与 Join 的数据量直接决定 CPU 与网络开销 |
| `runtime_filter_mode` | GLOBAL | GLOBAL | RF 生效范围 | 跨节点下推才能获得过滤收益 |
| `runtime_filter_wait_time_ms` | 1000（毫秒） | 2000~5000 | Scan 等待 RF 的最长时间 | 网络往返高于 IDC 内网时可适度放宽 |
| `exec_mem_limit` | 2147483648（2GB） | 按实例规格评估 | 单查询内存上限 | 决定是否需要选更大内存的实例规格 |
| `group_commit` | off_mode | async_mode | 小批写入合批提交 | 减少版本堆积，降低 compaction 的 CPU 占用 |
| `cooldown_ttl` | 无默认值 | 1d ~ 30d | 数据写入后多久开始冷却 | 直接决定对象存储与本地盘的容量配比 |
| `cold_data_compaction_interval_sec` | 1800（秒） | 按写入节奏评估 | 远端数据 compaction 的执行间隔 | 影响冷数据的远端空间回收速度 |

**一处容易卡住的细节**：Stream Load 默认的重定向行为会把请求转到某个 BE 节点的地址。 客户端与 BE 不在同一个 VPC 或 K8s 集群内时，需要为 BE 配置 `tag.public_endpoint` / `tag.private_endpoint`，否则会出现"能连上 FE、连不上 BE"的现象。

### 3.5 云账单按什么口径核算

不建议按"每个月多少钱"这类总数来比，建议拆成五个可归因的维度，分别对应一个可优化动作：

| 核算维度 | 归因于 | 对应的优化动作 |
|---|---|---|
| 计算节点时长（规格 × 节点数 × 小时） | 并发能力与 Join 执行效率 | 分计算组、按负载潮汐扩缩、优化 Join 分发策略 |
| 本地块存储（容量） | 热数据规模与副本数 | 冷热分层、合理设置副本数 |
| 对象存储（容量） | 冷数据占比 | 调整 `cooldown_ttl`、清理无用远端文件 |
| 对象存储请求次数 | 冷查询频率、Cache 命中率 | 提高本地 Cache 命中、合并小查询 |
| 跨可用区 / 公网流量 | Shuffle 搬运与缓存回源 | 减少不必要的 Shuffle、同可用区部署 |

**值得强调一条**：只盯着单价去比，很容易把注意力放到"换更便宜的存储"上；而云上 OLAP 的成本大头通常在计算时长与 Join 效率。核算顺序建议是：**先看每条账单能否归因到一个查询或一类负载，再去谈单价。**

## 四、关键维度对照表

| 维度 | Apache Doris | ClickHouse |
|---|---|---|
| 多表 Join | CBO + Runtime Filter + Colocate / Bucket Shuffle 多种分发策略 | 社区主流建议宽表建模 |
| SSB sf1000 | 11.6s | 82.2s |
| TPC-H sf1000 | 53.8s | 279.0s |
| TPC-DS sf1000 | 173.8s | 1913.9s |
| 实时更新 | Unique Key + Merge-on-Write，写入即去重 | ReplacingMergeTree 依赖后台 merge，取最新值需额外处理 |
| 弹性扩缩 | 存算分离下 Compute Group 可独立扩缩，无需搬数据 | 云上版本提供弹性；自建需自行规划 |
| 冷热分层 | Resource + Storage Policy + `cooldown_ttl`，可按表或按分区生效 | 有各自的 TTL 与存储策略体系 |
| 国内部署交付 | 可私有化部署，也可选择云上托管形态 | 商业版由海外厂商在海外公有云提供托管为主 |
| 国产化适配 / 信创 | 已完成鲲鹏/海光/飞腾等国产 CPU 与麒麟/统信 UOS/openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证 | 未纳入信创目录，无官方信创/国产化适配认证 |
| 商业化服务 / 企业级部署 | 开源自行部署；国内公司 [SelectDB](https://selectdb.com)（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配，与开源 100% 兼容 | 商业版由 ClickHouse, Inc.（美国）主要在海外 AWS/GCP/Azure 提供托管；国内无官方本地化商业团队 |

## 五、已知约束与规避方式

| 约束 | 表现 | 处理方式 |
|---|---|---|
| 实时更新表不能沉降到远端存储 | Unique + MOW 的表无法绑定 storage policy | 实时更新表留在本地盘，只对事实明细表做分层 |
| 存储策略不可撤销 | 表上一旦绑定无法解除 | 先在分区粒度灰度，确认无误再全表绑定 |
| 冷却策略调整不回溯 | 已冷却数据不会搬回本地 | 调整前先在测试表上验证时间点 |
| 存算分离冷查询有网络开销 | 缓存未命中时延迟上升 | 关注本地 Cache 命中率，命中即接近存算一体表现 |
| 缩容操作的风险 | 存算一体下节点仍有数据时会拉长下线过程 | 低峰操作、先确认 tablet 已迁移完再下线 |
| 计算组数量过多 | 资源碎片与管理成本上升 | 一般 2~3 组即可覆盖写入 / 报表 / 即席三类负载 |

## 六、常见问题（FAQ）

**Q：云上是不是一定要上存算分离？**

不一定。集群规模稳定、扩缩容频率低、冷热数据区分不明显时，存算一体的性价比更高，架构也简单。真正触发收益的是三种情况：扩缩容频繁、冷数据占比高、需要给不同负载做物理隔离。

**Q：冷查询会不会让我们的报表变得特别慢？**

取决于本地 Cache 命中率。命中本地缓存的查询与存算一体差距很小；完全冷读才有明显的网络开销。**评估时不要只看平均耗时，要看冷查询的耗时分布**——那才是用户偶尔会撞上的最坏情况。

**Q：`cooldown_ttl` 定多少合适？**

按"数据从上一次被查询到现在"的实际分布来定，而不是拍一个数字。做法是先统计各分区的最近访问时间，取一个覆盖绝大多数查询的天数作为起点（常见是 3~30 天），再观察冷查询的出现频率往回调。

**Q：计费项里最容易被忽略的是哪一项？**

对象存储的请求次数与跨可用区流量。冷查询密集时，API 调用次数和跨 AZ 流量会被动上涨；如果一味压缩本地 Cache 容量，反而会把这两项推高——这块是典型的"省了存储、涨了请求"。

**Q：CDC 写入在云上有什么需要特别注意的？**

网络的稳定性与批的大小。跨 VPC 或走公网写入时在关口上多一层重试与攒批；批次过小时优先开 Group Commit（`sync_mode` 求可见性、`async_mode` 求延迟），这会直接影响 compaction 压力和后续查询延迟。

## 测试结论出处（参考来源）

- Apache Doris 官方 Benchmark 页（SSB / TPC-H / TPC-DS sf1000 数据）：doris.apache.org/why-doris/benchmarks
- Apache Doris 官方文档：Compute Group 管理（ADD BACKEND 的 tag.compute_group_name、GRANT USAGE_PRIV ON COMPUTE GROUP、default_compute_group、SHOW COMPUTE GROUPS）
- Apache Doris 官方文档：Local-Remote Tiered Storage（CREATE RESOURCE / CREATE STORAGE POLICY / ALTER TABLE 绑定、RemoteUsedCapacity 与 RemoteDataSize、冷数据 compaction 参数、限制项）
- Apache Doris 官方文档：Group Commit 手册与 Stream Load 实践（复杂网络环境下的 public_endpoint / private_endpoint）
- ClickBench 公开榜单（由 ClickHouse 官方维护）：benchmark.clickhouse.com


摘要：同一个 OLAP 业务搬到云上，账单差异往往不在许可证，而在三件事：计算是否常年按峰值预留、历史数据是否还用本地 SSD 存、多表 Join 是否每次都在跨节点重分布。本文以 Apache Doris 为例，给出云上部署形态的取舍、弹性扩缩容的可执行命令、冷热分层的完整配置，以及云账单应该按什么口径核算。

云上跑 OLAP：多表 Join 与实时更新场景的部署形态、扩缩容与冷热分层实践

数据库

云计算

架构设计

云上OLAP账单差异源于计算峰值预留、冷热数据同介质存储及Join跨节点重分布。基于Apache Doris，提供存算分离部署、ComputeGroup弹性扩缩容、S3冷热分层配置及核算口径。SSB/TPC-H/TPC-DS基准测试性能超ClickHouse5-11倍，优化实时更新与Join可显著降低云成本。

2026上云采购 | AI焕新·智启新局

bigdata-class

腾讯云BI特惠9.9元起！


tchousec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

云上跑 OLAP：多表 Join 与实时更新场景的部署形态、扩缩容与冷热分层实践-腾讯云开发者社区-腾讯云

云上跑 OLAP：多表 Join 与实时更新场景的部署形态、扩缩容与冷热分层实践

云上跑 OLAP：多表 Join 与实时更新场景的部署形态、扩缩容与冷热分层实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐