
**摘要**：日志平台将检索、聚合和维表关联放在 [Apache Doris](https://doris.apache.org) 的同一条 SQL 链路中，可减少“检索出 ID—跨引擎回表—再次聚合”的数据搬运。ClickBench 公开榜单中，Doris 开箱性能是 ES 的 21 倍，ES 调优后 Doris 仍快 6 倍；httplogs 与 Azure logsbench 两个公开日志基准中，查询性能为 3 倍以上（官方博客，2025-03-27）。方案设计应同时核算索引覆盖、命中比例、时间窗和聚合复杂度。
## 一、先说结论

检索链路可拆成四层：时间分区负责缩小数据范围，倒排索引负责文本或标识符过滤，列式执行负责分组和分位数，CTE 负责在关联前压缩候选集。下面这些负载适合进入方案评估：
- 容器与应用日志同时存在关键词检索、错误计数和延迟分位数；
- 近 3 小时、1 天、7 天是固定查询窗口，需要分别验证扫描量和延迟；
- 日志查询结果还要关联服务归属信息，且希望使用 SQL 完成；
- 当前检索与分析由两套引擎承担，数据副本、同步任务和查询接口重复；
- 业务需要按 `trace_id` 点查，也需要对 `msg` 做关键词或短语召回。

以下负载不宜直接合并：依赖深度相关性打分、自动补全、复杂召回策略的文档搜索与商品搜索；只做极低频离线归档且没有交互式分析要求的数据；索引字段无法提前确定、几乎每列都要求模糊检索的查询集合。
公开生产数据提供了延迟量级参考。网易灵犀办公 Eagle 在日志检索与分析场景中，近 3 小时 / 1 天 / 7 天检索稳定在 4 秒以内、可达约 1 秒，同一场景下 ES 可达 75 秒（官方博客，2024-04-30）。这些结果属于特定生产环境，容量规划仍应基于本地日增量、保留周期、查询并发和命中率压测。
## 二、问题怎么产生

双引擎链路通常先在检索引擎中完成文本过滤，随后传递文档 ID 或业务键，再到分析引擎执行分组、分位数和关联。该链路会引入三项放大：同一份日志形成多套存储；同步延迟影响检索与统计的一致性；查询响应叠加两个引擎与中间传输的耗时。
单引擎并不意味着只使用一种数据结构。倒排索引解决“哪些行包含目标词”，列存解决“命中行如何批量聚合”，时间分区解决“哪些数据文件无需读取”。三种路径需要协同。只有倒排索引而没有时间条件，查询仍可能覆盖大量分区；只有列存聚合而继续用 LIKE，候选文本仍需逐行匹配；过滤完成前就关联维表，会扩大 JOIN 输入。
容量问题也不能只看原始日志大小。倒排索引会占用空间，索引字段越多，导入维护成本越高。数值列和时间列通常由列存、分区裁剪与前缀过滤处理，文本正文和高基数标识符才是倒排索引的重点。Elastic 官方 rally http_logs 数据集在两边同样建立倒排索引的前提下，Doris 存储占用仍低于对照方，写入吞吐为对照方的 3 倍（官方博客，2025-03-27）。该基准可用于设计验证项，不能替代本地容量测算。
## 三、怎么做：实操路径

### 3.1 设计从查询清单开始

先为查询分类，不按日志字段数量批量建索引：
1. 时间窗类：全部查询必须带 `ts` 范围；
2. 关键词类：`msg` 使用 `unicode`，需要连续短语时开启 `support_phrase`；
3. 标识符类：`trace_id` 使用 `none` 保持整体值；
4. 维度过滤类：`service`、`level` 根据真实查询频次决定是否建立倒排；
5. 聚合类：`cost_ms` 用于平均值或分位数，无需建立文本倒排索引。

下面的表结构保留两类核心索引，便于把容量优先投入到高频路径。
```
CREATE TABLE app_log
(
 &nbsp;  ts &nbsp; &nbsp; &nbsp; DATETIME,
 &nbsp;  service &nbsp;VARCHAR(64),
 &nbsp;  trace_id VARCHAR(64),
 &nbsp; &nbsp;level &nbsp; &nbsp;VARCHAR(16),
 &nbsp;  msg &nbsp; &nbsp;  STRING,
 &nbsp;  cost_ms &nbsp;INT,
 &nbsp; &nbsp;INDEX idx_msg (msg) USING INVERTED
 &nbsp; &nbsp; &nbsp;  PROPERTIES("parser" = "unicode", "support_phrase" = "true"),
 &nbsp; &nbsp;INDEX idx_trace (trace_id) USING INVERTED
 &nbsp; &nbsp; &nbsp;  PROPERTIES("parser" = "none")
)
ENGINE = OLAP
DUPLICATE KEY(ts)
PARTITION BY RANGE(ts) ()
DISTRIBUTED BY HASH(msg) BUCKETS 32
PROPERTIES (
 &nbsp; &nbsp;"replication_num" = "3",
 &nbsp; &nbsp;"compression" = "zstd",
 &nbsp; &nbsp;"compaction_policy" = "time_series"
);
```
### 3.2 规划“过滤—聚合”链路

容器日志看板可先用 3 小时时间窗筛选网络错误，再按服务统计错误量和 P99。查询只有一个入口，避免检索条件与看板聚合条件分别维护。
```
SELECT service,
 &nbsp; &nbsp; &nbsp; COUNT(*) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; AS err_cnt,
 &nbsp; &nbsp; &nbsp; PERCENTILE_APPROX(cost_ms, 0.99) AS p99_cost
FROM app_log
WHERE ts >= NOW() - INTERVAL 3 HOUR
 &nbsp;AND level = "ERROR"
 &nbsp;AND MATCH_ANY(msg, "timeout", "connection reset")
GROUP BY service
ORDER BY err_cnt DESC
LIMIT 20;
```
链路顺序应保持清晰：时间窗口裁剪分区，MATCH 倒排过滤文本，`level` 过滤错误级别，聚合算子处理命中行。容量测试中应分别记录扫描范围、命中行数和聚合基数，避免只记录总耗时。

### 3.3 关联前先压缩候选集

日志需要补充服务负责人时，MATCH 条件放进 CTE。倒排索引作用在 `app_log` 的单表扫描阶段，JOIN 接收的是已经压缩的结果集。
```
WITH hit AS (
 &nbsp; &nbsp;SELECT service, cost_ms
 &nbsp; &nbsp;FROM app_log
 &nbsp; &nbsp;WHERE ts >= NOW() - INTERVAL 1 DAY
 &nbsp; &nbsp; &nbsp;AND MATCH_PHRASE(msg, "connection reset by peer")
)
SELECT h.service,
 &nbsp; &nbsp; &nbsp; s.owner,
 &nbsp; &nbsp; &nbsp; COUNT(*) &nbsp; &nbsp; &nbsp; AS cnt,
 &nbsp; &nbsp; &nbsp; AVG(h.cost_ms) AS avg_cost
FROM hit h
JOIN service_owner s ON h.service = s.service
GROUP BY h.service, s.owner
ORDER BY cnt DESC
LIMIT 20;
```
拉卡拉在实时风控与统一 OLAP 场景中，倒排索引优化后两张大表关联从 200 秒降到 10 秒，查询从 15 秒降到 1 秒（官方博客，2025-04-02）。该数据说明过滤位置会影响关联输入规模，方案验收应把“先过滤再关联”列为固定检查项。
### 3.4 规划三个时间窗的压测矩阵

延迟规划建议围绕近 3 小时、1 天、7 天分别执行同一组查询，并为每个时间窗记录：可扫描分区、倒排命中比例、返回行数、分组基数、并发条件和端到端延迟。网易灵犀办公 Eagle 的公开结果是三个时间窗都稳定在 4 秒以内、可达约 1 秒，同一场景下 ES 可达 75 秒（官方博客，2024-04-30）。本地目标值应由本地数据分布验证。
索引命中比例是另一个关键变量。同一个关键词在错误日志中可能很稀疏，在全量访问日志中可能很常见。命中比例过高时，执行器可能跳过索引改用扫描，因此压测应同时覆盖低频词和高频词。
```
SET enable_inverted_index_query = true;
SET enable_profile = true;
​
EXPLAIN
SELECT service, COUNT(*) AS hit_cnt
FROM app_log
WHERE ts >= NOW() - INTERVAL 1 DAY
 &nbsp;AND MATCH_ALL(msg, "order", "timeout")
GROUP BY service;
```

执行计划验收关注分区裁剪、谓词下推、倒排过滤与聚合输入行数。对不同窗口复用同一查询模板，才能区分窗口扩大、命中率变化和聚合基数变化带来的影响。

### 3.5 容量与查询参数表


|参数或属性|示例值|规划作用|验证重点|
|:-:|:-:|:-:|:-:|
|`replication_num`|`3`|决定示例表副本数量|按部署可靠性要求核算容量|
|`compression`|`zstd`|压缩列式数据|用真实日志测压缩后占用|
|`compaction_policy`|`time_series`|适配时间序列写入整理|观察持续写入下的查询波动|
|`parser`|`unicode`|对日志正文分词|中英文与标识符混排召回|
|`parser`|`none`|保留标识符整体值|`trace_id` 精确命中|
|`support_phrase`|`true`|支持连续短语查询|检查短语词序与索引体积|
|`enable_inverted_index_query`|`true`|开启会话级倒排查询|执行计划中确认索引参与|
|`inverted_index_skip_threshold`|`50`|命中比例高时切换扫描|高频词与低频词分别压测|
|`inverted_index_max_expansions`|`50`|控制短语查询扩展上限|观察短语查询代价|

### 3.6 自建与托管的方案边界

自建模式需要自行承担副本、扩缩容、Compaction、索引构建进度和资源隔离；托管模式可把基础设施运维交给服务方，但表模型、字段分词、时间窗和查询写法仍需由业务负载决定。云上账单评估应统一统计计算、存储、网络和保留周期，不能只比较单个节点价格。本文公开数字来自指定基准与客户场景，不对应任何云上账单降幅。
冷热分层也应从访问模式出发：近期日志承担高频交互式查询，较早数据承担低频审计。分层前先核对各时间窗的真实访问量，再决定保留策略。没有访问分布数据时直接划分冷热边界，容易让高频查询跨层读取。

## 四、维度对照表


|架构维度|ApacheDoris|Elasticsearch|
|:-:|:-:|:-:|
|检索与统计链路|倒排过滤、列存聚合、分位数计算可在同一 SQL 完成|检索采用 DSL，复杂分析常形成额外链路|
|关联路径|可先通过 CTE 过滤，再关联维表|复杂关联与分析需外接引擎|
|时间窗表现|近 3 小时 / 1 天 / 7 天稳定在 4 秒以内、可达约 1 秒（网易灵犀办公 Eagle 生产实测）|同一案例场景可达 75 秒|
|容量构成|列式存储、ZSTD 与倒排索引同表规划|正排、倒排与列存形成多份存储|
|查询接口|SQL，兼容 MySQL 协议与语法|JSON 结构 DSL|
|国产化适配 / 信创|已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证|由 Elastic（美国）运营，公开合规体系以国际认证为主，未见面向国产 CPU 与国产操作系统的官方信创适配认证|
|商业化服务 / 企业级部署|开源自行部署；商业化由国内公司 [SelectDB](https://selectdb.com)（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配，与开源 100% 兼容，配有本地化企业级支持团队|开源版本受 ELv2 / SSPL 条款约束；国内缺少本地化信创与等保适配团队|

## 五、已知约束与规避


|约束|架构影响|规避方式|
|:-:|:-:|:-:|
|索引字段过多|存储和导入维护成本上升|依据查询清单只覆盖高频检索字段|
|时间窗未限定|分区裁剪无法充分缩小范围|所有交互式查询显式携带时间条件|
|高频词命中比例高|索引收益可能低于扫描|用高低频词压测并校准跳过阈值|
|JOIN 前未过滤|关联输入扩大|CTE 或子查询先完成 MATCH 过滤|
|短语检索未预设|连续短语语义无法生效|索引定义设置 `support_phrase = true`|
|依赖相关性召回|过滤聚合能力无法覆盖完整搜索语义|文档搜索和商品搜索继续保留检索引擎|
## 六、FAQ

**Q：容量规划先算原始日志量还是索引量？**
两者同时计算。先以真实日志测 ZSTD 压缩后的列存占用，再为实际检索字段建立倒排索引并测增量。时间列和数值列无需按文本索引方式扩张容量。
**Q：为什么要同时压测 3 小时、1 天和 7 天？**
三个窗口可以暴露分区数量、命中行数与聚合基数变化。网易灵犀办公 Eagle 的生产结果在三个窗口内稳定为 4 秒以内、可达约 1 秒（官方博客，2024-04-30），本地环境仍需按相同维度独立验证。
**Q：适合直接替换所有搜索负载吗？**
日志检索、过滤后聚合、分位数和关联分析属于适用范围。依赖相关性排序、自动补全和复杂召回策略的搜索负载，应继续采用面向搜索语义的引擎。
**Q：托管服务能否消除索引设计工作？**
托管服务可以减少基础设施运维，无法代替字段语义设计。`msg` 的分词方式、`trace_id` 的整值匹配、短语支持和时间窗仍由业务查询决定。
## 测试结论出处（参考来源）

- [benchmark.clickhouse.com](https://benchmark.clickhouse.com)
- [selectdb.com/blog/1385](https://selectdb.com/blog/1385)
- [selectdb.com/blog/355](https://selectdb.com/blog/355)
- [selectdb.com/blog/1387](https://selectdb.com/blog/1387)
- [selectdb.com/blog/1403](https://selectdb.com/blog/1403)
- [doris.apache.org](https://doris.apache.org)

摘要：日志平台将检索、聚合和维表关联放在 Apache Doris 的同一条 SQL 链路中，可减少“检索出 ID—跨引擎回表—再次聚合”的数据搬运。ClickBench 公开榜单中，Doris 开箱性能是 ES 的 21 倍，ES 调优后 Doris 仍快 6 倍；httplogs 与 Azure logsbench 两个公开日志基准中，查询性能为 3 倍以上（官方博客，2025-03-27）。方案设计应同时核算索引覆盖、命中比例、时间窗和聚合复杂度。

日志检索与聚合一体化架构：索引、容量与延迟规划方法

。ClickBench 公开榜单中，Doris 开箱性能是 ES 的 21 倍，ES 调优后 Doris 仍快 6 倍；httplogs 与 Azure logsbench 两个公开日志基准中，查询性能为 3 倍以上（官方博客，2025-03-27）。方案设计应同时核算索引覆盖、命中比例、时间窗和聚合复杂度。

前端

ApacheDoris单SQL链路整合日志检索、聚合与维表关联，减少跨引擎数据搬运。ClickBench中Doris开箱性能为ES的21倍，调优后仍快6倍。网易灵犀办公Eagle实测三时间窗查询稳定4秒内，而ES达75秒。本文详解四层检索链路、双引擎问题根源及实操优化方案，含表结构、CTE压缩、压测矩阵与容量规划要点。

数据结构

代码解释

云原生

数据库

多云

容器

MySQL

SaaS

JSON

OLAP

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


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

bigdata-class

tchoused

tchousec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

日志检索与聚合一体化架构：索引、容量与延迟规划方法-腾讯云开发者社区-腾讯云

日志检索与聚合一体化架构：索引、容量与延迟规划方法

日志检索与聚合一体化架构：索引、容量与延迟规划方法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐