ES存储账单太吓人？且看Doris倒排索引，如何把老板的血压和成本一起降下来！

PowerData

编者荐语：

来自PowerData-张彬华同学的精彩分享！

以下文章来源于一臻数据，作者ADC张彬华

[

一臻数据 .

一臻数据致力于大数据AI时代的前沿内容分享，欢迎大家投稿，共建共进❗️

](#)

点击上方蓝字关注一臻数据👆

免费领取 DeepSeek➕数据AI知识库 🔗 一起共建共进

❝
凌晨3点，线上日志系统分析突然告警，用户反馈交易失败！
运维小张急忙点开日志平台开始排查，输入几个关键词，等待结果...10秒...30秒...1分钟过去了，系统仍在"努力加载中"
小张叹了口气："又要等到天亮了。"
"为什么查询日志这么慢？有没有更高效的解决方案？"
正巧，Apache Doris 从2.0版本开始推出了倒排索引技术，让日志查询速度大幅度提升，并且同样的原始数据，Doris 的存储成本只需要 Elasticsearch 的 20% 左右。
本文将带你深入了解Apache Doris倒排索引技术，从原理到实践，全方位掌握这把日志分析的利器。

Doris倒排索引：日志查询的超级加速器

一本厚厚的字典，如果你想查找包含某个字的所有页码，传统方式需要逐页翻找。但字典尾部的索引部分却能直接告诉你：这个字在第25、68、129页出现。这就倒排索引*的基本思想**。

倒排索引是什么？

在Apache Doris中，倒排索引是一种存储结构，它建立了"词->行"的映射关系。与传统的正排索引（根据行ID找内容）相反，倒排索引允许你直接根据内容找到对应的行。

核心原理：

1. 将文本拆分成一个个词（分词）

2. 为每个词建立指向包含该词的行ID列表

3. 查询时，直接定位包含指定词的所有行

这种方式特别适合日志分析场景，因为日志查询通常是基于内容的过滤，如"查找所有包含'ERROR'的日志"。

什么样的查询能被加速？

Doris的倒排索引支持多种查询类型：

1. 全文检索：MATCH_ANY(匹配任一词)、MATCH_ALL(匹配所有词)、MATCH_PHRASE(短语匹配)

2. 普通等值查询：=、!=

3. 范围查询：>、>=、<、<=

4. 数组类型：支持字符串、数字、日期时间数组的各种查询

5. 逻辑组合：支持AND、OR、NOT的任意组合

相比传统的LIKE '%keyword%'模糊匹配，倒排索引的全文检索能提供N倍以上的性能提升。

Doris倒排索引的技术突破

为什么Apache Doris的倒排索引在处理日志查询时如此高效？这得益于其多项技术创新。

1. 高性能写入

传统日志系统如Elasticsearch在高速写入时常遇到瓶颈，主要源于两点：

1. 解析JSON数据消耗大量CPU

2. 构建多种索引结构导致写放大严重。

Doris针对这些问题做了巧妙优化：

1. SIMD向量化：利用CPU向量指令加速JSON解析和索引构建

2. 简化索引结构：针对日志场景，去掉了不必要的索引数据结构

3. 批量写入优化：支持一次导入写入单个分桶，减少小文件数量

综合这些优化，Apache Doris的写入性能比Elasticsearch高3-5倍，即使面对每秒GB级别的日志流量也能稳定处理。

2. 低成本存储

日志数据通常体积庞大，存储成本是一个不容忽视的问题。

Doris通过多项技术大幅降低存储成本：

1. 列式存储：按列存储并压缩，压缩比可达5-10倍

2. 冷热分层：自动将老日志迁移到对象存储，成本降低70%以上

3. 去除冗余：移除日志场景不需要的正排索引，节省约30%空间

实际生产环境中，同样数据量下Doris的存储成本只有Elasticsearch的20%左右。

3. 超快检索分析

Doris对日志场景的查询做了专门优化：

1. 跳过打分：去掉日志场景不需要的相关性排序，专注于快速检索

2. TopN剪枝：针对"查最新N条日志"这类场景做了动态剪枝优化

3. SQL强大分析：支持标准SQL，可以与各种BI工具结合进行复杂分析

4. 灵活Schema

日志数据的结构经常变化，新字段不断添加。

Doris通过以下技术支持这种灵活性：

1. Light Schema Change：支持秒级完成增/删列、增/删索引

2. VARIANT类型：自动识别JSON中的字段名和类型，支持半结构化数据

相比Elasticsearch的Dynamic Mapping，Doris的方案更灵活，允许一个字段有多种类型，减少冲突。

实战指南：构建高性能日志分析平台

接下来，我们跟着小张，一起来看看：基于Apache Doris的倒排索引如何构建一个高性能低成本的日志分析平台：

Step 1：需求分析与资源评估 - "算算你的日志有多重"

小张负责一个电商平台的日志系统迁移，每天日志量约100TB。

他首先计算了资源需求：

日平均写入吞吐 = 100TB/86400s ≈ 1.2GB/s 考虑峰值系数2倍，峰值写入 ≈ 2.4GB/s 估算单核写入性能10MB/s，需要约240核心专用于数据写入

存储需求：

假设压缩比5:1，每天20TB压缩后的数据热数据保留3天，需要60TB存储冷数据保留30天，需要600TB对象存储

根据这些数据，小张规划了15台BE节点（32核256GB内存，10块600GB SSD盘）和3台FE节点。

Step 2：集群部署 - "搭建你的日志大本营"

小张使用物理机部署集群，特意选择了本地SSD而非云盘，因为测试显示前者随机I/O性能至少高3倍。

"集群搭建看似简单，但有个小技巧，"小张说，"我们把FE和BE放在不同机器上，避免资源争抢。另外，把网络调整为万兆，这样数据传输不会成为瓶颈。"

Step 3：参数优化 - "调教你的引擎"

这一步极为关键，小张根据日志场景特点调整了大量参数：

FE配置优化：

max_running_txn_num_per_db = 10000 # 支持高并发导入 enable_round_robin_create_tablet = true # 均匀分布数据

BE配置优化：

write_buffer_size = 1073741824 # 1GB写缓冲，减少小文件 disable_storage_page_cache = true # 日志数据太大，关闭页缓存 inverted_index_searcher_cache_limit = 30% # 增加索引缓存

"有一次半夜系统写入变慢，"小张回忆道，"排查后发现是默认的BE心跳容忍次数太低，导致临时网络抖动就误判BE宕机。

调整max_backend_heartbeat_failure_tolerance_count后，系统稳如泰山。"

Step 4：创建表结构 - "定义你的日志模型"

小张设计了一个优化的表结构：

CREATE TABLE log_table ( `ts` DATETIME, `host`TEXT, `path`TEXT, `message`TEXT, INDEX idx_host (`host`) USING INVERTED, INDEX idx_path (`path`) USING INVERTED, INDEX idx_message (`message`) USING INVERTED PROPERTIES("parser" = "unicode", "support_phrase" = "true") ) ENGINE = OLAP DUPLICATEKEY(`ts`) PARTITIONBYRANGE(`ts`) () DISTRIBUTEDBY RANDOM BUCKETS 60 PROPERTIES ( "compression" = "zstd", "compaction_policy" = "time_series", "dynamic_partition.enable" = "true", "dynamic_partition.create_history_partition" = "true", "dynamic_partition.time_unit" = "DAY", "dynamic_partition.start" = "-30", "dynamic_partition.end" = "1", "dynamic_partition.prefix" = "p", "dynamic_partition.buckets" = "60", "storage_policy" = "log_policy_3day"-- 存算分离不需要 );

这个设计包含几个关键要点：

1. 时间列作为主键，加速基于时间的查询

2. 关键字段建立倒排索引，优化全文检索

3. 使用zstd压缩算法提高压缩比

4. 配置time\_series compaction策略减轻写放大

5. 启用动态分区自动管理数据生命周期

6. 配置冷热分层策略，3天后自动迁移到对象存储

小张解释道："我们最初没用support_phrase，结果用户抱怨短语搜索慢。

Step 5：日志采集 - "让数据流动起来"

小张团队使用Filebeat采集应用日志，通过Stream Load API直接写入Doris：

filebeat.inputs: -type:log enabled:true paths: -/path/to/your/log multiline: pattern:'^[0-9]{4}-[0-9]{2}-[0-9]{2}' negate:true match:after output.doris: fenodes:["http://fehost1:http_port"] user:"your_username" password:"your_password" database:"your_db" table:"log_table" headers: format:"json" read_json_by_line:"true" load_to_single_tablet:"true"

"采集环节有个坑，"小张说，"如果不设置load_to_single_tablet，会导致大量小文件，压缩效率低下。

修改后写入性能提升了3倍，还节省了35%的空间。"

Step 6：查询分析 - "让数据会说话"

平台上线后，用户通过SQL查询日志，比如：

-- 查找包含错误关键词的最新日志 SELECT ts, host, message FROM log_table WHERE message MATCH_ANY 'error exception failed' ORDERBY ts DESCLIMIT100; -- 查找特定IP在特定时间段的访问日志 SELECT * FROM log_table WHERE host = '10.0.0.123' AND ts BETWEEN'2023-06-01'AND'2023-06-02' ANDpath MATCH_PHRASE '/api/payment';

小张团队还将Doris与Grafana集成，创建了实时监控面板（也可以直接使用Doris Manager对Doris集群进行运维管理，自带监控告警体系）。

"以前分析一个bug可能需要一整天导出日志、筛选分析，"一位开发说，"现在直接一条SQL，几秒钟就能定位问题根源。"

性能对比，数据说话

小张团队对比了迁移前后的性能数据：

指标

原Elasticsearch集群

Apache Doris集群

提升倍数

写入吞吐

500MB/s

2.4GB/s

4.8倍

全文检索延迟

3-10秒

0.2-0.8秒

12.5倍

存储空间占用

150TB

30TB

5倍

运维成本

45台服务器

18台服务器

2.5倍

"数据不会撒谎，"小张说，"Doris的倒排索引技术确实改变了我们处理日志的方式。"

实用技巧与陷阱避坑

基于团队血泪经验，小张总结了几点建议：

1. 索引不是越多越好：每个倒排索引都会增加写入负担和存储空间，只为真正需要快速检索的字段建索引

2. 分词器选择很重要：

英文日志用"english"分词器

中文日志用"chinese"分词器

混合多语言用"unicode"分词器

3. 避免范围过滤的坑：不要用MATCH_ANY做范围过滤，如message MATCH_ANY '>= 500'，这会匹配包含">="或"500"的所有记录，而非大于500的值

4. 添加冷数据策略：

CREATE RESOURCE"log_s3" PROPERTIES( "type" = "s3", "s3.endpoint" = "your_endpoint", "s3.bucket" = "your_bucket" ); CREATESTORAGEPOLICY log_policy_3day PROPERTIES( "storage_resource" = "log_s3", "cooldown_ttl" = "259200" );

5. 分区粒度权衡：日分区是最常用的，但如果写入量特别大，可以考虑小时分区；如果数据量小但跨度长，可以用月分区