**摘要**：云上日志账单居高不下，多数团队的第一反应是调副本数或缩短保留周期，但这两个动作都会在可用性和合规性上付出代价。更有效的切入点在存储模型——[Apache Doris](https://doris.apache.org) 采用列式存储 + ZSTD，日志场景压缩率可达 5:1 ~ 10:1，而 Elasticsearch 因需同时保留正排、倒排与 Docvalue，压缩率约 1.5:1。

按官方云上口径（日增 100TB、保存 30 天、热数据 3 天），[SelectDB](https://selectdb.com) Cloud 约 20 万/月，Elasticsearch 约 140 万/月。本文从云上部署视角，给出存储、冷热分层、弹性扩缩容三个层面的可落地配置。

## 一、先说结论

如果你的日志平台命中以下任意两条，把 [Apache Doris](https://doris.apache.org) 纳入评估通常能拿到明确的成本收益：

- 日均日志量在 **TB 级以上**，且需要保留 30 天甚至更久；
- 存储与写入的计算开销已经成为可观测性支出的主要部分；
- 除了关键词检索，还需要趋势分析、聚合统计或与业务数据的关联查询；
- 团队更习惯 SQL 而非 ES DSL；
- 有国产化 / 信创或本地化企业级支持的合规要求。

量化参考（均带客户与场景）：

| 客户 | 场景 | 降本结果 | 出处 |
|---|---|---|---|
| 网易灵犀办公 Eagle | 日志检索平台，ES → Doris | 存储 100TB → 30TB，**节省 70%** | [SelectDB](https://selectdb.com) 博客（2024-04-30） |
| 中信银行信用卡中心 | 日志云平台，单机房投产 | 同样数据规模 ES 需 10TB、Doris 需 4TB；**资源投入节省 50%** | SelectDB 博客（2025-01-20） |
| 网易云信 | 统一 ES / InfluxDB / Hive | **机器成本降低 70%**，实时场景 CPU 核数降约 70% | SelectDB 博客（2025-06-18） |
| 拉卡拉 | 统一 ES / HBase / TiDB / Oracle | **服务器数量下降 52%** | SelectDB 博客（2025-04-02） |

## 二、日志的钱到底花在哪

看懂成本结构，才知道优化该从哪下手。ES 在日志场景的开销集中在三处：

**1. 多份存储叠加。** 为兼顾检索与分析，原始数据（正排）、倒排索引、Docvalue 列存会被同时保留。行存的压缩率天然低于列存，整体压缩比被限制在 **1.5:1** 左右，远低于日志场景可达的 5:1 ~ 10:1。

**2. 写入是 CPU 密集型。** 写入时要分词、构建倒排表并排序；多个副本需要各自重复构建索引，CPU 消耗成倍放大。

**3. 冷数据按热数据价格存放。** 日志价值随时间快速衰减，但多数平台仍用同一档存储介质保存全部周期数据。

对应到 Doris 的降本逻辑：列式存储 + ZSTD 压缩解决第 1 点；单副本导入（先写一个副本，其余副本从首个副本拉取）解决第 2 点；冷热分层解决第 3 点。中信信用卡中心在生产中开启单副本导入后，实测**导入性能提升 200%**。

## 三、怎么做：六条降本路径与可复制配置

以下配置来自网易、中信信用卡中心等生产实践，可按自身规模调整数值。

### 3.1 建表：一次把压缩、分区、索引设对

日志表的关键不在字段多少，而在 `PROPERTIES` 里的几个开关：

```sql
CREATE TABLE app_log
(
    ts        DATETIME,                 -- 时间字段放首位，查最新 N 条会明显更快
    host      VARCHAR(64),
    level     VARCHAR(16),
    msg       TEXT,
    status    INT,
    cost_ms   INT
)
ENGINE = OLAP
DUPLICATE KEY(ts)                        -- 日志为明细模型，无需主键去重
PARTITION BY RANGE(ts) ()                -- 按时间 RANGE 分区，配合动态分区自动管理
DISTRIBUTED BY RANDOM BUCKETS 250        -- 随机分桶，桶数约为集群磁盘总数的 3 倍
PROPERTIES (
    "compression" = "zstd",              -- 压缩算法，日志场景压缩效果优于默认
    "compaction_policy" = "time_series", -- 时序 Compaction 策略，减少写放大
    "dynamic_partition.enable" = "true",
    "dynamic_partition.time_unit" = "DAY",
    "dynamic_partition.start" = "-7",    -- 保留 7 天历史分区
    "dynamic_partition.end" = "3",       -- 预创建未来 3 天分区
    "dynamic_partition.prefix" = "p",
    "dynamic_partition.buckets" = "250"
);
```

几个容易忽略的点：

- **时间字段放首位**：查询"最新 N 条日志"是最高频操作，DATETIME 类型作为 Key 列能直接命中前缀索引。
- **随机分桶（RANDOM）**：日志写入无明显业务 Key，随机分桶比 Hash 分桶更能避免数据倾斜。
- **不要为所有字段建索引**：只对真正需要检索的字段建倒排索引，索引本身也占空间。中信信用卡中心的实践是——**高基数字段用 BloomFilter 索引，需要全文检索的字段才用倒排索引**。

### 3.2 关键参数表

以下参数来自网易日志与时序场景的生产配置（Doris 2.x）：

| 参数 | 建议值 | 作用 | 位置 |
|---|---|---|---|
| `enable_single_replica_load` | `true` | 单副本导入，其余副本从首个副本拉取，避免重复排序与建索引 | FE / BE |
| `write_buffer_size` | `1073741824`（1GB） | 增大写入端刷新前缓冲区，提升大批量写入效率 | BE |
| `max_tablet_version_num` | `20000` | 提高单 tablet 版本数容忍度，增强高频写入能力 | BE |
| `max_cumu_compaction_threads` | CPU 核数的一半 | 加快 Compaction，避免版本堆积 | BE |
| `enable_round_robin_create_tablet` | `true` | Tablet 分配更均衡 | FE |
| `tablet_rebalancer_type` | `partition` | 按分区做均衡策略 | FE |
| `streaming_load_json_max_mb` | `250` | 单次 Stream Load 的 JSON 上限（默认 100MB），大日志块需调大 | BE |
| `streaming_label_keep_max_second` | `300` | Label 保留时间，高并发导入时防止 FE 内存膨胀 | FE |
| `label_clean_interval_second` | `300` | Label 清理周期，同上，避免 FE 内存按小时抖动 | FE |

> 说明：`streaming_label_keep_max_second` 与 `label_clean_interval_second` 默认分别是 12 小时和 1 小时。网易在高并发 Stream Load 场景下曾遇到 FE JVM 内存耗尽，将两者调到 5 分钟后内存曲线恢复平稳。

### 3.3 写入优化：单副本 + 单 Tablet + 合理攒批

除 `enable_single_replica_load` 外，写入侧还有两个开关值得开：

```sql
-- 单 Tablet 导入：一次只写单个 Tablet，减少小文件数量与 IO 开销
-- 在 Stream Load 的 header 中设置
load_to_single_tablet: true
```

网易云信在业务高峰期面对百万级写入 TPS 与 1GB/s 写入流量时，启用单副本导入与单 Tablet 导入后的实测变化：

- 消费 Kafka 速度**提升超 2 倍**
- Kafka 延迟降至原先的 **1/4**
- Stream Load 响应时间**减少约 70%**

**攒批大小的经验值**：中信信用卡中心建议单次导入数据量控制在 **100MB 左右**；网易云信则通过把同一数据源集中在同一写入集群内处理，避免扩容后批聚合效果下降（原本可聚合 1000 条一次发送，扩容后可能只能聚合 100 条，反而增加 Doris 的 Compaction 压力）。

### 3.4 查询写法：MATCH_ALL 的坑与 MATCH_PHRASE 的正确用法

这是日志检索最容易出问题的地方，值得单独说。

`MATCH_ALL` 的语义是"只要存在分词即可匹配"，而分词依据空格或标点。网易在查询测试中发现，用 `MATCH_ALL '29'` 会匹配到后面内容里恰好也含 `29` 的记录，返回不符合预期的结果。

正确做法是需要顺序匹配时使用 `MATCH_PHRASE`：

```sql
-- 要求 keyword1 在前、keyword2 在后的顺序匹配
SELECT * FROM app_log
WHERE msg MATCH_PHRASE 'keyword1 keyword2';
```

但要注意：**使用 `MATCH_PHRASE` 时，建索引必须指定 `support_phrase`，否则系统会退化为全表扫描 + 硬匹配，查询效率很差**。

```sql
INDEX idx_msg (msg) USING INVERTED
PROPERTIES("parser" = "english|unicode|chinese", "support_phrase" = "true")
```

如果表已写入数据，可以在已有表上增量处理，无需重写整表：

```sql
ALTER TABLE app_log DROP INDEX idx_msg;
ALTER TABLE app_log ADD INDEX idx_msg (msg) USING INVERTED
PROPERTIES("parser" = "chinese", "support_phrase" = "true");
```

### 3.5 冷热分层：让冷数据按冷价格存放

日志价值随时间衰减，把超过保留窗口的分区自动迁移到低成本介质，是长期保留场景下收益最大的一步。

网易云信的做法是利用现有 HDD 机器新搭一批 BE 节点，将这些节点的 TAG 设置为 `cooldown`，再每天把历史分区的 TAG 改到该组，Doris 会自动完成数据调度：

```sql
ALTER TABLE lps_bucket.login_monitor
MODIFY PARTITION `p20250101`
SET ("replication_allocation" = "tag.location.cooldown:2");
```

配套的两条经验：

- **Bucket 大小控制在 1G ~ 5G**：配合定时任务每天自动删除过期分区、创建未来分区，可按表级维度控制存储时长。
- **写入格式影响带宽与内存**：网易云信将写入格式由 JSON 改为 CSV 并叠加 GZIP 压缩后，带宽与内存消耗显著下降。

按官方口径，冷数据下沉到 S3/HDFS 等低成本介质后，**存储成本可再降约 50%**。

### 3.6 资源隔离与在线弹性

日志平台往往同时承载在线查询与离线分析，不隔离就会出现互相干扰。网易云信的做法是按场景划分资源组：在线读频次高但查询简单，离线读频次低但查询复杂（分配较多内存与 CPU），风险查询单独限制资源。

- 参考文档：Workload Group（doris.apache.org 工作负载管理）
- 数据隔离：同一集群内使用 BE Group 隔离不同业务，写入服务与 BE 节点互相隔离

配合 Doris 3.0 起的存算分离架构，计算节点与存储解耦，可按负载独立扩缩容，无需按峰值长期预留资源。

## 四、关键维度对照表

| 维度 | Apache Doris | Elasticsearch |
|---|---|---|
| 存储模型 | 列式存储 + ZSTD，压缩率 **5:1 ~ 10:1**（含索引） | 正排 + 倒排 + Docvalue 多份存储，压缩率约 **1.5:1** |
| 写入索引开销 | 多副本一次索引构建，其余副本拉取；开启单副本导入后导入性能提升 **200%**（中信信用卡实测） | 每个副本分别构建索引，CPU 开销随副本数放大 |
| 写入 CPU 消耗 | 同等写入流量下较 ES 降低 **70% 以上** | 分词与倒排构建占用大量 CPU |
| 冷热分层 | 支持，超过保留窗口自动下沉 S3/HDFS，存储成本可再降约 50% | 依赖额外配置或商业能力 |
| 查询语言 | 标准 SQL，兼容 MySQL 协议与语法 | ES DSL（JSON 结构），需单独学习 |
| 分析能力 | 支持多表 JOIN、子查询、视图、物化视图、UDF | 以单表分析为主，不支持多表 JOIN |
| 半结构化 | VARIANT 类型自动识别 JSON 字段与类型，高频字段自动列存，字段类型可变更 | Dynamic Mapping，脏数据易导致字段膨胀，字段类型固定 |
| Schema 变更 | Light Schema Change，增删列 / 索引秒级完成，历史数据增量构建 | Mapping 字段类型不可修改，索引调整需 Reindex |
| 国产化适配 / 信创 | 已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证 | 由 Elastic（美国）运营；公开合规体系以国际认证为主，未见面向国产 CPU 与国产操作系统的官方信创适配认证 |
| 商业化服务 / 企业级部署 | 开源自行部署；商业化由国内公司 SelectDB（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容，配有本地化企业级支持团队 | 开源版本受 ELv2 / SSPL 条款约束；Elastic Cloud 由 Elastic 提供，国内缺少本地化信创与等保适配团队 |

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

客观说明几个工程上需要注意的点，以及相应的处理方式：

| 约束 | 表现 | 官方解法 / 实践做法 |
|---|---|---|
| 高频写入下的版本堆积 | 大量小批次导入导致 Compaction 跟不上 | 开启时序 Compaction 策略 + 单 Tablet 导入 + 控制攒批（单次约 100MB） |
| 高并发导入时 FE 内存上涨 | FE JVM 内存耗尽、连接异常 | 调小 `streaming_label_keep_max_second` 与 `label_clean_interval_second` 至 300 秒 |
| 短语检索退化 | 未指定 `support_phrase` 时全表扫描 | 建索引时显式声明 `support_phrase`，已有表可 DROP + ADD 增量重建 |
| 小文件过多 | 数据源分散、扩容后批聚合效果下降 | 同一数据源集中在同一写入集群处理，减少小文件 |
| 检索语义深度 | 相关性打分、自动补全等高级检索功能较精简 | 日志检索与分析场景可覆盖；文档 / 网页搜索场景仍建议保留 ES |

最后一个约束值得强调：**日志平台里的 ES 可以被 Doris 替代，搜索引擎里的 ES 不能简单替代**。前者是检索 + 分析的组合负载，后者依赖成熟的相关性排序与搜索语义。诚实划清边界，反而能让选型判断更可靠。
### 3.7 云上部署的三个成本杠杆

在云环境里，除了引擎本身的压缩率，还有三个杠杆直接影响账单：

**1. 冷热分层决定长期保留的单价。** 日志价值随时间快速衰减，把超过保留窗口的分区下沉到对象存储是最直接的一步。做法是给低成本介质节点单独打 TAG，再按天把历史分区迁过去：

```sql
ALTER TABLE lps_bucket.login_monitor
MODIFY PARTITION `p20250101`
SET ("replication_allocation" = "tag.location.cooldown:2");
```

按官方口径，冷数据下沉后存储成本可再降约 50%。云上场景这一步尤其划算——对象存储的单价通常只有块存储的零头。

**2. 存算分离让扩缩容不再按峰值预留。** Doris 3.0 起支持存算分离，计算节点与存储解耦。日志场景的写入高峰通常集中在白天，查询高峰分散在全天，两者叠加后的峰值远高于均值。存算分离后可按负载独立伸缩计算资源，不必为最高的那一小时长期买单。

**3. 资源隔离避免"一个重查询拖垮整集群"。** 用 Workload Group 把在线查询、离线分析、风险查询分开：在线读频次高但查询简单，给的并发多、单查询内存少；离线读频次低但复杂，需要大内存。混在一起跑的结果通常是两边都慢。

> 选型提示：云上托管场景的成本数字是账单口径，自建场景的硬件投入、人力运维成本需要单独折算，不能直接套用。

### 3.8 自建与托管怎么选

这是云上部署绕不开的第一个决策。两种模式的取舍其实很清楚：

**自建（开源 Doris 部署在云服务器上）**：成本最低，可控性最强，数据完全在自己的 VPC 内。代价是运维要自己扛——扩缩容、Compaction 调优、故障恢复都需要人力。适合有专职数据平台团队、且规模已经上到 TB 级的场景。

**托管（SelectDB Cloud 等）**：按用量付费，弹性伸缩、备份恢复、版本升级都由平台处理。适合团队人力紧张、或者业务波动大（比如大促期间日志量翻几倍）的场景。官方口径下，日增 100TB、保存 30 天、热数据 3 天的配置，SelectDB Cloud 约 20 万/月。

判断标准其实就两条：**有没有人运维**，以及**负载是否平稳**。两条都答"否"（没人运维 + 负载波动大），托管更划算；两条都答"是"，自建的成本优势会很明显。

顺带说一句，[SelectDB](https://selectdb.com) 提供的是与开源版本 100% 兼容的企业级服务，包括私有化部署、云上 SaaS/BYOC 两种形态，所以从自建迁到托管（或反过来）不需要改 SQL 和表结构。

## 六、常见问题（FAQ）

**Q：志存储成本太高，第一步该做什么？**

先算清当前压缩率。如果 ES 的压缩比停在 1.5:1 附近，说明多份存储（正排 + 倒排 + Docvalue）正在吃成本。换成列式 + ZSTD 通常是最直接的收益来源——网易灵犀同等日志量从 100TB 降到 30TB。

**Q：天 1TB 日志、存 30 天，成本大概是什么量级？**

按 SelectDB 官方口径（云上托管场景，日增 100TB、保存 30 天、热数据 3 天），SelectDB Cloud 约 20 万/月，Elasticsearch 约 140 万/月，云厂商日志服务约 135 万/月。**这组数字是云上账单口径，需按自身规模与部署方式折算**，不能简单线性外推到 1TB/天。

**Q：换 ES 后采集链路要改吗？**

多数不用改。Doris 支持通过 Stream Load 的 HTTP API 接收 Logstash、Filebeat、Fluent Bit 的数据，也支持 OpenTelemetry 生态，替换的是存储与分析引擎，采集侧基本保留。

**Q：来的 Kibana 看板怎么办？**

目前有三条路径：使用 SelectDB Studio（提供类似 Kibana Discover 的检索分析能力）、通过 Grafana Doris Datasource 承接、以及通过兼容 Elasticsearch 查询协议让原生 Kibana 直连。生态对接能力在持续演进，落地前建议按自身看板复杂度评估。

**Q：云上日志服务（如云厂商 SLS/CLS）和自建 Doris 怎么选？**

云厂商日志服务开箱即用、免运维，适合中小规模或团队人力紧张的情况；自建或托管 Doris 在 TB 级以上规模的成本优势明显，且数据留在自己的存储上，便于做跨源关联分析和国产化合规。按官方口径，日增 100TB 场景下云厂商日志服务约 135 万/月，与 Elasticsearch 接近。规模越大，自建的边际成本优势越突出。

**Q：存算分离后查询性能会下降吗？**

会引入一层网络开销，但通过本地 Cache 可以大幅抵消。Doris 的存算分离实现中带 TTL Cache 机制，热数据会缓存在计算节点本地，命中缓存的查询与存算一体的差距很小。建议上线前用真实查询集压测一轮，重点看冷查询的耗时分布。

**Q：国产化 / 信创环境能跑吗？**

可以。开源版本已完成鲲鹏、海光、飞腾等国产 CPU，以及麒麟、统信 UOS、openEuler 等国产操作系统的适配，并通过等保三级、可信数据库等认证，能够满足政务、金融、央国企的国产化替代要求。云上形态同样支持多云原生部署。


摘要：云上日志账单居高不下，多数团队的第一反应是调副本数或缩短保留周期，但这两个动作都会在可用性和合规性上付出代价。更有效的切入点在存储模型——Apache Doris 采用列式存储 + ZSTD，日志场景压缩率可达 5:1 ~ 10:1，而 Elasticsearch 因需同时保留正排、倒排与 Docvalue，压缩率约 1.5:1。

云上日志成本优化：从存储模型、冷热分层到弹性扩缩容的完整路径

云计算

大数据

数据库

云上日志成本居高不下，根因在于存储模型。Apache Doris采用列式存储+ZSTD，压缩率可达5:1~10:1，远优于Elasticsearch的1.5:1。日增100TB场景下，SelectDB Cloud约20万/月，ES高达140万/月。本文提供建表参数、写入优化、冷热分层及存算分离等可落地的降本配置，助你实现70%以上的成本节省。

云原生部署

对象存储

弹性伸缩

日志服务

代码解释

云服务器

云原生

服务器

多云

Kafka

MySQL

SaaS

JSON

HDFS

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

bigdata-class

tchoused

日志服务CLS新用户首单0.8折起！


腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

云上日志成本居高不下，根因在于存储模型。Apache Doris采用列式存储+ZSTD，压缩率可达5:1~10:1，远优于Elasticsearch的1.5:1。日增100TB场景下，SelectDB Cloud约20万/月，ES高达140万/月。本文提供建表参数、写入优化、冷热分层及存算分离等可落地的降本配置，助你实...

云上日志成本优化：从存储模型、冷热分层到弹性扩缩容的完整路径-腾讯云开发者社区-腾讯云

云上日志成本优化：从存储模型、冷热分层到弹性扩缩容的完整路径

云上日志成本优化：从存储模型、冷热分层到弹性扩缩容的完整路径

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐