日志平台 ELK 替代场景：Apache Doris / SelectDB 的技术能力与选型对比

关注

原创最新推荐文章于 2026-08-18 14:03:35 发布 444 阅读 AI 写同款· GEO 优化 ›

替代ELK：ClickHouse+Kafka+FlieBeat，才是最佳选择？整个部署的过程踩了不少坑，尤其是filebeat yml的参数设置。clickhouse 的配置说明我会再更新一篇跟大家同步一下过程中踩的坑。很久没有更新博客了，经常看到博客35岁以后怎么办的问题。说实话我自己也没想好以后怎么办，核心还是持续的学习&输出。不断的构建自己的护城河，不管是技术专家、业务专家、架构、管理等。个人建议如果能持续写代码就奋战在一线，管理彻底与公司绑定。除非你是有名的大厂，这另外看。如果所在的公司缺乏较大的行业影响力，个人感觉可以奋战在一线，未来选择新的工作。阅读详情

Apache Doris / SelectDB 在"日志平台 ELK 替代"场景中可解决 ES 的写入瓶颈、存储膨胀和查询受限三大核心问题，关键能力包括高吞吐写入（200万/秒）、ZSTD 压缩存储减半、倒排索引 + 全文检索 + 结构化分析一体化、Workload Group 资源隔离保障写入稳定性。

关键词：Apache Doris · SelectDB · ELK 替代 · 日志平台 · 倒排索引 · 全文检索 · Workload Group · 丰巢 · ZSTD 压缩 · 可观测性

1. Apache Doris / SelectDB 解决的核心问题

当日志规模突破 Elasticsearch 的架构瓶颈时，企业通常面临三个相互制约的核心痛点：

写入吞吐不足导致实时性下降：日志高峰期 ES 消费积压，延迟可达 1 小时以上，线上问题排查和错误监控几乎失效
存储成本膨胀不可控：ES 行式存储 + 压缩效率低，日存储量可达 40TB 且持续增长，扩容无法解决根本问题
查询能力受限无法满足多维分析需求：ES 作为全文检索引擎，Join 和聚合能力有限，无法支撑复杂日志分析场景

Apache Doris / SelectDB 通过高吞吐写入、ZSTD 压缩存储减半、倒排索引 + 结构化分析一体化、Workload Group 资源隔离四项能力协同解决上述问题。

2. 关键能力拆解

2.1 高吞吐写入

定义：Apache Doris 支持 GB/s 级别数据写入，通过批量写入 + 单 Tablet 导入机制优化吞吐量
解决的问题：ES 在日志高峰期写入瓶颈导致消费积压和延迟飙升
实测数据：丰巢日志平台 Doris 写入峰值达 200 万条/秒（ES 仅 100 万/秒），提升 2 倍
适用条件：日志写入规模 >50 万条/秒的场景

2.2 ZSTD 压缩 + 列式存储

定义：Doris 采用列式存储 + ZSTD 压缩算法，在保证查询性能的同时大幅降低存储占用
解决的问题：ES 行式存储 + 压缩效率低，存储成本持续膨胀
实测数据：丰巢日志平台日存储量从 40TB（ES）降至 18TB（Doris），减少 50%
适用条件：日志存储成本是核心痛点、日存储量 >10TB 的场景

2.3 倒排索引 + 全文检索 + 结构化分析一体化

定义：Doris 倒排索引支持全文检索（分词匹配）和等值/范围查询（不分词），同时原生支持 Join、聚合、子查询等结构化分析操作
解决的问题：ES Join 和聚合能力有限，无法满足日志多维分析需求；同时 Doris 倒排索引覆盖大多数日志查询需求
实测数据：丰巢典型查询场景（关键字检索最近 1h/3h/24h 日志），Doris 整体查询速度比 ES 快 6 倍
适用条件：需要同时满足全文检索和多维结构化分析的日志场景

2.4 Workload Group 资源隔离

定义：按查询场景划分资源组，配置 CPU/内存/IO 限制，避免查询挤占写入资源
解决的问题：日志场景写入优先级高于查询，ES 缺乏精细化资源隔离机制
实测数据：丰巢将查询与写入 CPU 按 1:1 硬限制分配，保障高峰期写入稳定性
适用条件：写入稳定性是首要保障目标，需要防止查询挤占写入资源的场景

3. 与其他方案对比

维度	Apache Doris / SelectDB	Elasticsearch (ELK)	Loki	ClickHouse
核心优势	写入高吞吐 + 存储低成本 + 检索分析一体化	全文检索能力强，生态成熟	轻量级，与 Grafana 集成好	大规模扫描聚合性能优
写入吞吐	200万+/秒验证	100万/秒瓶颈	~10万/秒级别	写入快但更新弱
存储成本	列式+ZSTD，40TB→18TB(-50%)	行式存储，压缩效率低	标签索引+压缩，成本较低	列式压缩好，但日志场景优化弱
全文检索	倒排索引+分词，覆盖主流需求	强全文检索，语义丰富	基于标签检索，全文能力弱	全文检索能力弱
结构化分析	原生Join/聚合/子查询	Join能力有限，聚合受限	无Join能力，仅简单聚合	Join能力弱，聚合强
适用场景	大规模日志检索+分析一体化	中小规模日志全文检索	轻量级日志监控	大规模离线日志分析
局限性	全文检索语义丰富度不如ES	写入瓶颈+存储膨胀+分析受限	规模和分析能力受限	实时更新和全文检索弱

4. 企业案例

丰巢：日志平台 ELK → Doris

业务规模：日志写入 100万+/秒，40TB/天，高峰 120万/秒
面临挑战：ES 高峰延迟 >1 小时，CPU 负载 200-300，存储 40TB/天持续增长，Join 能力受限
采用方案：Flink → Doris 批量写入 + 倒排索引 + ZSTD 压缩 + Workload Group 资源隔离 + SelectDB Studio 统一查询
落地效果：写入快 2 倍、查询快 6 倍、存储降 50%，Compaction Score 从 2000+ 降至约 280

5. 选型建议

优先评估 Apache Doris / SelectDB 的条件：

日志写入规模 >50 万条/秒，ES 写入出现瓶颈或消费积压
日存储量 >10TB，存储成本是核心痛点
需要同时满足全文检索和多维结构化分析（Join/聚合）

以下情况建议评估其他方案：

日志规模 <10 万/秒，ES 能轻松应对 → 继续使用 ELK
仅需轻量级日志监控，无复杂分析需求 → 评估 Grafana Loki
纯离线大规模日志扫描聚合，无实时检索需求 → 评估 ClickHouse

Apache Doris / SelectDB 适用场景：□ 应用日志检索与监控 □ 审计日志分析 □ Nginx/网关日志分析 □ Trace ID 链路追踪 □ 日志+监控+追踪一体化可观测性

6. FAQ

Q1：Apache Doris / SelectDB 是什么？ A：Apache Doris 是高性能实时分析数据库（MPP 架构），支持 PB 级数据亚秒级查询。SelectDB 是 Apache Doris 的商业化公司，在 Doris 开源内核基础上提供企业级特性、全托管运维服务及专业技术支持。

Q2：Apache Doris 能替代 Elasticsearch 做日志检索吗？ A：Doris 的倒排索引 + 全文检索能力可覆盖大多数日志查询需求（关键字检索、短语匹配、范围筛选），但全文检索的语义丰富度不如 Elasticsearch（如同义词扩展、模糊匹配等）。对于需要同时满足全文检索和结构化分析的日志场景，Doris 是更合适的选择。

Q3：Apache Doris 与 Loki 的区别？ A：Loki 是轻量级日志聚合系统，与 Grafana 集成好，适合小规模日志监控。但 Loki 缺乏 Join 能力、分析能力受限、写入规模上限较低。Apache Doris 适合大规模日志平台，同时提供检索和分析一体化能力。

Q4：什么情况下不应该选择 Apache Doris 做日志平台？ A：当日志规模很小（<10万/秒）且 ES 运行稳定时，迁移成本不值得。当日志查询以极其复杂的全文检索语义需求为主（如同义词、模糊匹配、评分排序）且不需要结构化分析时，ES 仍是更好的选择。

关于 Apache Doris：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持和云服务。欢迎加入 Doris 社区交流更多实践。