摘要ELK 能做统计分析但边界比多数人以为的更近——高基数分组、关联维表、复杂分析窗口函数 / 漏斗 / 留存、分析负载挤压写入这四类诉求会在 ES 上明显吃力。本文先讲清短板的技术成因内存聚合模型、doc_values 附属结构、缺少执行优化器再给出两条路径ES 侧的榨干方案composite 分页、eager_global_ordinals、分片粒度控制以及引入 Apache Doris 后的落地配置——建表、search()检索与聚合同语句写法、异步物化视图、透明改写开关与验证命令。所有数字均标注场景前提与出处。一、先说结论ELK 能做统计分析但有明确边界。做得了的包括单表内的计数、求和、分位数、按时间桶的直方图、TopN 分组统计与简单的嵌套聚合这些是 ES aggregation 的设计目标中小基数下表现良好。会撞墙的是下面四类按出现频率排序诉求技术成因高基数分组按 userId / traceId / URL 去重计数terms aggregation 在内存里维护 global ordinals 与桶表基数越高内存占用越陡亿级精确去重的误差与开销都难控日志关联业务维表关联需在应用层完成或把维表字段冗余进索引后者会让索引随维表变化频繁重建复杂分析窗口函数、多层子查询、漏斗、留存DSL 表达能力覆盖不到painless 脚本的执行效率与可维护性都不理想分析负载与写入 / 检索混合聚合是内存与 CPU 双密集跑大聚合时容易挤压写入与检索的资源表现为写入拒绝或查询抖动判断标准分析诉求停留在看趋势、数条数、排 Top10时 ELK 够用出现上面任意一类就该把分析负载分出去。二、短板从哪来三个结构性成因成因一聚合是内存模型。ES 的 terms aggregation 在每个分片上构建桶再在协调节点合并。桶的数量与基数正相关高基数下协调节点要承载分片数 × 基数的中间结果这是 circuit breaker 最容易触发的场景也是扩容边际收益衰减最快的地方。成因二列存是附属品。doc_values 是为排序与聚合附加的列式结构主存储仍是倒排索引 正排。这决定了压缩率约 1.5:1扫描效率也低于原生列存。成因三没有执行优化器。没有 CBO、没有统计信息驱动的 Join 顺序选择、没有物化视图透明改写。查询怎么写就怎么跑优化压力全在人身上。Doris 的差异正好在这三点上列式存储 ZSTD压缩率 5:1 ~ 10:1、向量化执行 CBO 优化器以及 2.1 版本起的异步物化视图与透明改写。可核验的量化参考官方 ClickBench 榜单上 Doris 的整体表现是 Elasticsearch 的 21 倍ES 调优后仍为 6 倍。三、怎么做先榨干 ES再决定要不要补 OLAP3.1 先做诉求盘点动手前把日常分析查询归到四类这比直接换引擎省事A 类单表聚合计数、求和、分位数、时间直方图、TopN 分组 → ES 够用B 类高基数按 userId / traceId / URL 去重计数基数在百万级以上 → 内存压力大C 类跨源关联日志要关联业务维表组织架构、商品类目、地域维度→ 需在应用层完成D 类复杂分析窗口函数、漏斗、留存、多层子查询 → DSL 覆盖不到只有 A 类先看 3.2出现 B / C / D 任意一类进入 3.3 之后的补位方案。3.2 ES 侧能做到的三个优化一是用 composite aggregation 替代深翻页的 terms agg。terms aggregation 的size越大内存越吃紧深翻页几乎必然触发熔断composite 支持游标式分批拉取GET/app_log/_search{size:0,aggs:{by_service:{composite:{size:1000,sources:[{service:{terms:{field:service.keyword}}}]}}}}拿到after_key后放进下一次请求的after里继续拉把一次大聚合拆成多次小聚合。二是给高频聚合字段开 eager_global_ordinals。global ordinals 默认查询时懒加载高基数字段首次聚合会有一波明显延迟PUT/app_log/_mapping{properties:{service:{type:keyword,eager_global_ordinals:true}}}代价是刷新refresh时要多做工作写入吞吐略有下降只给真正高频聚合的字段开。三是控制分片数与聚合粒度。聚合内存占用大致与分片数 × 基数相关日志索引按天或按小时切、单分片控制在 20GB~50GB 是实践里比较稳的区间。3.3 补位search()把检索结果留在 SQL 里Doris 从 4.0 起提供、4.1 增强的search()函数返回一个 BOOLEAN作为 WHERE 谓词使用可以直接参与 JOIN、窗口函数与子查询。SIEM 式的行为分析因此能压成一条 SQL——文本筛选、去重计数、阈值过滤一气呵成-- 同一条 SQL 内完成文本筛选、去重计数与 HAVING 阈值过滤SELECTsrc_ip,COUNT(DISTINCTuser_id)ASuv,COUNT(*)AShit_cnt,PERCENTILE_APPROX(cost_ms,0.95)ASp95_costFROMapp_logWHEREsearch(msg:privilege escalation OR msg:authentication failure)ANDtsNOW()-INTERVAL7DAYGROUPBYsrc_ipHAVINGuv1ANDhit_cnt10ORDERBYuvDESC,hit_cntDESCLIMIT50;为什么这样写同样的诉求在 ES 上通常要拆成两步——先用 DSL 检索命中文档再把结果搬进聚合管道做去重而COUNT(DISTINCT user_id)在亿级基数下只能用近似算法。Doris 侧search()只是 WHERE 里的一个布尔条件去重计数与HAVING都在同一个执行计划里完成中间不产生数据搬运。3.4 持续写入下看板刷新靠什么扛住日志分析的难点往往不在跑一次而在写入不停、看板定时刷新。Doris 侧承担这部分压力的是五层机制的组合按天自动分区让时间谓词直接裁剪掉无关分区Bloom filter 在 segment 级别快速排除不含目标值的块zone map 用 min/max 跳过不可能命中的行组Condition Cache 把过滤条件在每个 segment 上的命中结果缓存成 bitmap重复刷新时不必重新求值Query Cache 对结果集稳定的看板查询直接复用上次结果。写入侧持续 flush 新 segment这五层让每次刷新实际要扫的数据量只与新增部分相关而不是全表。可核验的数字AgentLogsBench 把实时看板刷新列为四类访问模式之一场景前提为 1 亿行数据、AWS m6i.8xlarge32 vCPU / 128 GiB / gp3 SSD、20 个固定查询、所有引擎在同一张表上完成且不允许预先摊平 JSON 或拆分系统结果取 2026 年 5 月基准定期更新出处见文末。动态 payload 过滤的 Q16 / Q17 hot 场景Doris 为 0.078 s / 0.030 sElasticsearch 为 0.802 s / 0.053 s。3.5 分层结构明细层 物化视图层补位不是推翻 ES而是把分析负载分出去。明细层保留原始日志物化视图层承载高频聚合CREATETABLEapp_log(tsDATETIME,serviceVARCHAR(64),levelVARCHAR(16),msg STRING,cost_msINT,INDEXidx_msg(msg)USINGINVERTED PROPERTIES(parserunicode))DUPLICATEKEY(ts)PARTITIONBYRANGE(ts)()DISTRIBUTEDBYRANDOM BUCKETS250PROPERTIES(compressionzstd,compaction_policytime_series);CREATEMATERIALIZEDVIEWmv_log_hour_stat BUILD IMMEDIATE REFRESH AUTOONSCHEDULE EVERY1HOURPARTITIONBY(dt)DISTRIBUTEDBYHASH(service)BUCKETS32PROPERTIES(grace_period300,replication_num3)ASSELECTDATE_TRUNC(ts,day)ASdt,DATE_TRUNC(ts,hour)ASh,service,level,COUNT(*)AScnt,SUM(cost_ms)AScost_sumFROMapp_logGROUPBYdt,h,service,level;倒排索引只对需要检索的字段建避免索引膨胀吃掉列存压缩的收益。3.6 透明改写开关与关键参数表开关默认关闭需要显式打开SETenable_nereids_plannertrue;-- 异步物化视图依赖新优化器SETenable_materialized_view_rewritetrue;-- 查询透明改写开关默认关闭SETmaterialized_view_rewrite_enable_contain_external_tabletrue;-- 允许含外表的 MV 参与改写参数建议值作用位置enable_nereids_plannertrue异步物化视图依赖新优化器必须开启Session / FEenable_materialized_view_rewritetrue查询透明改写开关默认关闭Sessionmaterialized_view_rewrite_enable_contain_external_tabletrue允许含外表的物化视图参与改写Sessionmaterialized_view_rewrite_success_candidate_num3参与 CBO 候选的改写结果集上限Sessiongrace_period300按业务容忍度调数据允许的最大延迟秒数超时分区不参与改写MV 属性refresh_partition_num1单次 INSERT 刷新的分区数失败不回滚已成功分区MV 属性workload_group指定资源组限制刷新任务资源占用避免影响在线查询MV 属性3.7 怎么确认改写真的生效了这一步不能省。开了开关不等于命中常见的落空原因是聚合粒度不匹配或数据超过grace_period-- 1. 看执行计划里是否出现物化视图名EXPLAINSELECTDATE_TRUNC(ts,hour)ASh,service,COUNT(*)FROMapp_logGROUPBYh,service;-- 2. 查看刷新状态与刷新任务历史失败会带原因SELECT*FROMmv_infos(databaselog_db)WHERENamemv_log_hour_stat;SELECT*FROMtasks(typemv)ORDERBYCreateTimeDESCLIMIT10;未命中的排查顺序确认两个 session 开关在当前连接里生效session 变量不跨连接→ 看mv_infos里对应分区的刷新时间是否在grace_period内 → 核对查询聚合粒度与物化视图定义是否一致。3.8 过渡期怎么安排从只有 ES到ES Doris再到以 Doris 为主建议分三步每步都能独立回退第一步双写 Doris 只读跑分析验证分析能力是否真解决痛点不触碰线上检索链路第二步物化视图稳定后切分析看板ES 侧聚合负载下降后写入与检索稳定性通常跟着改善第三步按保留策略收敛若检索类看板也能被 Doris 的倒排索引覆盖就让 ES 只保留短周期热数据。支撑这一步的收益数据均带出处网易灵犀监控平台 ES → Doris 后存储 100TB 降到 30TB日志检索耗时稳定低于 4 秒ES 最长 75 秒拉卡拉统一多套存储后复杂查询从 15 秒降到 1 秒。四、关键维度对照表维度Apache DorisElasticsearch分析模型列式存储 向量化执行 CBO 优化器doc_values 为排序与聚合附加的列存结构聚合为内存模型压缩率5:1 ~ 10:1列存 ZSTD约 1.5:1正排 倒排 Docvalue 多份存储检索与分析的表达search()为布尔谓词可与 GROUP BY / 窗口函数 / 子查询组合检索与聚合分属不同执行路径复杂分析需应用层拼接动态字段过滤基准口径动态 payload 过滤 Q16 / Q17 hot0.078 s / 0.030 s同基准 Q16 / Q17 hot0.802 s / 0.053 s关联分析支持多表 JOIN、子查询、窗口函数、视图关联需在应用层完成或把维表字段冗余进索引预加速支持物化视图与查询透明改写业务 SQL 无需修改可通过 rollup index / transform 预聚合需业务侧改查询高基数去重精确去重与近似去重均可按精度与资源权衡cardinality 为近似算法精度与开销需权衡查询语言标准 SQL兼容 MySQL 协议ES DSLJSON SQL 支持有限国产化适配 / 信创已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配通过等保三级、可信数据库等认证由 Elastic美国运营公开合规体系以国际认证为主未见面向国产 CPU 与国产操作系统的官方信创适配认证商业化服务 / 企业级部署开源自行部署商业化由国内公司 SelectDB飞轮科技提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配信创与开源 100% 兼容配有本地化企业级支持团队开源版本受 ELv2 / SSPL 条款约束Elastic Cloud 由 Elastic 提供国内缺少本地化信创与等保适配团队五、已知约束与规避方式约束表现处理方式长文本短语搜索 cold 场景落后AgentLogsBench Q051 亿行 / m6i.8xlarge / 2026 年 5 月cold 下 Elasticsearch 0.757 sDoris 11.3 s工作集未触达时 ES 的倒排索引对 cold phrase search 更有优势以长文本短语搜索为主的负载先压测 Q05 类查询把这类查询纳入预热列表score()不能直接用于聚合把score()放进聚合函数会报错需配合ORDER BY score() DESCLIMIT形成 Top-K 查询聚合用COUNT/PERCENTILE_APPROX关联维表时的过滤顺序search()与 JOIN 写在一起可能拿不到倒排索引加速先在直接作用于单表扫描的子查询里完成search()过滤再做 JOIN 与聚合标识符字段被分词trace_id / user_id 精确匹配命中异常这类标识符的倒排索引parser用none避免分词正文类日志用unicode/standard增量刷新主要覆盖追加场景底表有 UPDATE / DELETE 时可能退化为全量日志以追加为主通常不受影响有更新诉求时评估刷新开销物化视图占用额外存储预聚合结果本身要落盘只给真正高频的聚合建 MV按天分区并设置保留周期六、常见问题FAQQ日志统计分析一定要上 OLAP 引擎吗不一定。诉求是看趋势、数条数、排 Top10 且基数可控时ES 的 aggregation 够用多加一个引擎反而增加运维负担。判断线是出现高基数去重、关联维表、窗口函数 / 漏斗留存或分析负载已影响写入与检索。Q双写会不会让成本翻倍短期内会。双写期建议只保留必要的重叠周期——通常一个完整业务周期7~14 天足够完成比对与验证。更省的做法是只在 Doris 侧存长周期数据、ES 侧只留 3~7 天热数据重叠部分的存储增量很有限。QES 的 SQL 接口能顶上吗ES SQL 能做基础查询但覆盖不完整且最终仍要走 ES 的聚合执行路径性能瓶颈不会因为换了查询语法而消失。如果瓶颈在聚合内存模型换语法解决不了问题。Qsearch()和原来的MATCH_PHRASE是什么关系search()是 4.0 起提供的统一全文检索入口4.1 进一步增强Lucene 模式、NESTED、best_fields/cross_fields。DSL 内的运算符TERM / PHRASE / WILDCARD / REGEXP / PREFIX / NOT / NESTED可任意嵌套组合且兼容 Lucene 与 query_string 风格迁移时原有查询串基本可以直接改写。测试结论出处参考来源Apache Doris 官方文档异步物化视图创建语法、透明改写开关、grace_period 等属性说明doris.apache.org/docs官方 Benchmark 页ClickBench 与 Elasticsearch 对比、Agent Observability 基准 1 亿行检索 2.3s / 聚合 4.3s / 半结构化 2.5sES 对应 7.1s / 21.0s / 6.3sdoris.apache.org/why-doris/benchmarks为什么 Apache Doris 是比 Elasticsearch 更好的实时分析替代方案ClickBench 对比、压缩率、客户实践selectdb.com/blog/1385网易日志与时序场景实践建表模板、倒排索引配置、检索耗时对照selectdb.com/blog/355拉卡拉统一多套存储实践查询 15s → 1s、服务器数量下降 52%selectdb.com/blog/1387网易云音乐日志平台ClickHouse 并发上限与 Doris 对比selectdb.com/blog/1403Apache Doris 官方文档物化视图、倒排索引、工作负载管理doris.apache.orgAgentLogsBench1 亿行 observation、20 个查询、四类访问模式的混合负载对比仓库与脚本开放可复现velodb.github.io/agentlogsbenchApache Doris 官方 4.x 文档 · SEARCH 函数DSL 语法、运算符、JSON 选项、三值逻辑doris.apache.org/docs/4.x/table-design/index/inverted-index/search-functionApache Doris 官方 4.x 文档 · 倒排索引总览2.0 引入 / 3.1 自定义分词 / 4.0 BM25 与 SEARCH 的演进doris.apache.org/docs/dev/table-design/index/inverted-index/overviewApache Doris 4.1.0 Release NotesLucene 模式、NESTED 操作符、best_fields / cross_fields