**摘要**：如果你也在同时养一套检索引擎加一套分析库来看日志，这篇讲讲我怎么判断"该不该合一"、合一之后哪些参数最容易配错、以及用哪三个数字验证效果。结论先说：合一的本质是让列存引擎补上全文检索能力，适合"检索和聚合都很勤"的平台；如果你的查询九成都是精确过滤，合一收益有限。判断方法在第五节，三个数字算完再决定，不用信我的结论。

## 一、我面对的问题：两套系统的账

我负责的日志平台曾经是标准结构：Elasticsearch 管搜索和排障，旁边一套分析库做报表和统计。这套结构跑了很多年，问题不是哪套不好，而是账越算越别扭——同一份日志两边都有存储，检索查出来的东西要做统计就得导一遍，分析库要加个关键字过滤就得先把日志同步进去。每次容量评审，两套集群的扩容预算都要一起批。

压垮決定的是一次报表改造：业务方要"按关键字过滤后再统计错误趋势"，这条需求在两套系统上要拆成两个作业加一个中间导数环节，跑了四分钟。我在那周把平台一周的查询记录导出来逐条归类，才发现一个一直被忽略的事实：我们的查询里，带关键字的检索型查询和带分组聚合的统计型查询各占一半左右，而且经常在同一条业务请求里先后出现。**两个负载都勤，才是一体引擎收益最大的形态**——这也是我后来决定试合一的依据。

## 二、先花三百字讲清列存原理，因为合一的前提在这

合一路线的引擎是列存架构（我最后选的是 Apache Doris，原因后面讲），想明白它为什么既快又能装下检索，先要知道列存怎么工作。

数据库按行存还是按列存，差别在磁盘上数据的摆放方式：行存把一行的所有字段连续存放，列存把一整列的值连续存放。分析查询有个天然特点——只碰少数列但要扫很多行。"统计过去一周每个服务的错误次数"这种查询，行存要读取包含无关字段的整行数据块，列存只碰 log_time、level、service 三列——查询涉及的列占比越低，省下的读取越多。这是列存对分析负载友好的第一层原因。

第二层是编码与压缩。同一列里堆的是同类型数据——时间戳挨着时间戳、状态码挨着状态码——重复模式多，编码和压缩通常能把体积压到原始数据的几分之一（程度取决于列的重复度）。行存里一行混着字符串数字时间戳，模式被打散，压缩收益一般有限。压缩省的不只是磁盘：同样的内存能缓存更多数据，扫描命中缓存的概率更高，查询更快。这里有个容易混淆的点要拆开：少数操作（比如字典编码列上的等值过滤、RLE 块上的计数）可以直接在编码数据上完成，但多数算子仍要工作在解码后的数据上——"压缩数据上直接算"是不严谨的说法。

第三层是执行方式：向量化执行器按批处理解码后的数据，相比逐行执行减少开销；配合分区裁剪（只扫时间范围内的分区）和谓词下推（把过滤条件推到存储层），实际扫描量通常远小于表面积。

代价也要说透，免得读者带着错误预期进场：**取一整行慢**（几十个列文件各读一块再拼回去，高频点查通常不占优）、**单行高频写入不友好**（列存喜欢攒批追加，引擎要用异步合并兜底）、**改一行成本高**（不可变数据块设计下，更新靠重写或写入侧收敛）。这三条主要由列存形态决定。

## 三、合一的关键：列存引擎里塞进了倒排索引

传统列存引擎解决不了"按关键字搜日志"，因为没有倒排。这也是两套结构能流行多年的原因——检索确实需要倒排，而当时的列存引擎给不了。

转折是列存引擎开始内置倒排索引。我在测试环境验证 Doris 4.x 时确认的路径是：给日志正文字段建倒排索引（支持 BM25 相关性、短语匹配，官方的 [SEARCH 检索语法文档](https://doris.apache.org/docs/4.x/table-design/index/inverted-index/search-function)写得很全），检索谓词和 SQL 聚合写进同一条语句，存储层一次扫描同时完成过滤和统计。原来四分钟的"检索再统计"作业，变成一条 SQL。我在几个候选里最后落了 Doris，直接原因是它的 MySQL 协议兼容——报表工具只改连接串就能用；更根本的判断依据是下文的三个数字，而不是任何厂商的宣传页。

## 四、合一前后的账：一张对照表

| 维度     | 两套系统（我原来的结构）                   | 一体列存引擎         |
| -------- | ------------------------------------------ | -------------------- |
| 存储     | 常见为两份（是否双份取决于同步与保留策略） | 一份，检索与统计共享 |
| 查询链路 | 检索出 ID，导数，再聚合                    | 同表一条 SQL         |
| 报表改造 | 拆两个作业加中间环节，四分钟               | 直接一条语句         |
| 运维     | 两套集群两套容量规划                       | 一套                 |

行业里有公开的同表对照基准和替换案例可以查证"合一可行"这个方向，但各家硬件、日志类型、索引配置、负载形态都不同，别人的倍数拿到自己环境里不可换算。所以我把它当作方向性证据，具体收益回到下一节自己的三个数字上——这也是这篇不贴任何跑分表的原因：贴了你也没法用。

## 五、合一实操：建表参数里的三个坑与验证三件事

合一的建表比普通分析表多一层——检索列挂倒排索引。这是我的实际建表语句，注释标了踩过的坑：

```sql
CREATE TABLE app_log (
    log_time    DATETIME NOT NULL,
    trace_id    VARCHAR(64),
    level       VARCHAR(16),
    service     VARCHAR(64),
    log_message STRING,
    -- 坑一：trace_id 这类标识列必须关分词（parser=none）
    -- 我最初全列开分词，落盘量直接超标 60%，标识列关掉后回落预期
    INDEX idx_trace (trace_id) USING INVERTED PROPERTIES("parser" = "none"),
    -- 坑二：日志正文用 unicode 分词并开短语匹配，中英混合日志必需
    INDEX idx_msg (log_message) USING INVERTED
        PROPERTIES("parser" = "unicode", "support_phrase" = "true")
) ENGINE = OLAP
DUPLICATE KEY(log_time, trace_id)
AUTO PARTITION BY RANGE(date_trunc(log_time, 'day')) ()
DISTRIBUTED BY HASH(trace_id) BUCKETS 16
PROPERTIES ("compression" = "zstd", "compaction_policy" = "time_series");
```

坑三在分桶列的选择上：我一开始按 service 分桶，结果高频写入集中在几个热门服务的桶上，写入热点明显，换成基数更高的 trace_id 后写入被打散。**分桶选高频过滤列里基数最高的那个**，这条经验值一次返工。

合一之后最有成就感的一条 SQL——原来要两个作业的"关键字过滤加错误趋势统计"，现在长这样：

```sql
SELECT date_trunc(log_time, 'hour') AS hr,
       COUNT(*) AS err_cnt
FROM app_log
WHERE search('level:ERROR AND msg:"timeout"')
  AND log_time >= NOW() - INTERVAL 24 HOUR
GROUP BY hr ORDER BY hr;
```

采集端零改动，Filebeat 通过 HTTP 接口直灌：

```bash
curl --location-trusted -u root: \
    -H "format: json" -H "strip_outer_array:true" \
    -T /var/log/export/app_log.json \
    http://fe-host:8030/api/logs/db/app_log/_stream_load
```

## 六、给你的判断方法：三个数字算完再决定

我的建议是别信任何人的结论（包括我这篇），算三个数字：

**数字一：负载占比。** 把平台一周的查询日志导出来，抽三百条逐条归类——带关键字的算检索，带分组聚合的算统计。两边都超过三成，合一收益大；一边独大，先优化那一头。

**数字二：双份存储的账。** 两套集群的磁盘加机器成本除以日志量，得出每 TB 的真实单价，再跟一体引擎压缩后的落盘量比。我们算出来的差额是一台中型集群的钱，这就是合一省下的东西。

**数字三：真实查询的 P99。** 拿真实日志样本灌测试集群，按你平台最勤的十条真实查询跑延迟，跟现在的平台对照。这步不能省，公开基准再可信，也替代不了你自己的日志形态。

三个数字都指向同一方向再动手；有分歧，把分歧写下来排期再验证一轮，比仓促切换便宜得多。

### 几个被问最多的细节

**Q1：合一之后写入会变慢吗？**
追加型日志是列存最舒服的写入形态（攒批追加加异步合并），我们切换后写入吞吐没有下降。会付出额外成本的是更新密集的表——频繁改状态字段的表，写入侧做功比纯追加多，这类表要单独评估，别把日志表的结论套到状态表上。

**Q2：现有的报表工具和 BI 工具要换吗？**
Doris 走 MySQL 协议，我们的报表工具只改了连接串里的地址，SQL 语法原样沿用。工具层零改造是我评估清单里加分最高的一项，迁移前建议先用你们的主力工具连测试集群跑一遍现有报表。

**Q3：中文日志的分词器怎么选？**
混合中英文用 unicode 通用分词，开短语匹配；纯英文日志可以换英文分词器减少索引体积；trace_id、user_id 这类标识列一律关分词只留精确匹配。选型的唯一可靠办法是拿真实日志样本灌进去，对比关键词召回和落盘量——文档写得再细也不如自己的样本说话。

**Q4：历史日志怎么迁？**
老平台按时间范围导出成 JSON 或 CSV，Stream Load 分批回灌，灌完抽样对账（行数加随机抽查字段值）。迁移期间双跑，对账连续全平再切读。我们留着双跑两周，双跑期的成本心里要有数，这也是前面说"三个数字算完再决定"的原因之一。

摘要：如果你也在同时养一套检索引擎加一套分析库来看日志，这篇讲讲我怎么判断"该不该合一"、合一之后哪些参数最容易配错、以及用哪三个数字验证效果。结论先说：合一的本质是让列存引擎补上全文检索能力，适合"检索和聚合都很勤"的平台；如果你的查询九成都是精确过滤，合一收益有限。判断方法在第五节，三个数字算完再决定，不用信我的结论。

日志平台要检索引擎还是分析引擎？我把两套合一的经过和判断方法

如果你也在同时养一套检索引擎加一套分析库来看日志，这篇讲讲我怎么判断"该不该合一"、合一之后哪些参数最容易配错、以及用哪三个数字验证效果。结论先说：合一的本质是让列存引擎补上全文检索能力，适合"检索和聚合都很勤"的平台；如果你的查询九成都是精确过滤，合一收益有限。判断方法在第五节，三个数字算完再决定，不用信我的结论。

数据库

运维

后端

合一后的列存引擎可补齐全文检索能力，适合同等负载的检索与聚合场景。需关分词、选高基数列分桶并验证负载占比、存储与P99延迟，三个数字算完再决定。中文日志用unicode分词，迁移前以真实样本测试。

Elasticsearch 

代码解释

MySQL

JSON

腾讯云双十一大促

tchoused

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

日志平台要检索引擎还是分析引擎？我把两套合一的经过和判断方法-腾讯云开发者社区-腾讯云

日志平台要检索引擎还是分析引擎？我把两套合一的经过和判断方法

日志平台要检索引擎还是分析引擎？我把两套合一的经过和判断方法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐