日志系统选型笔记：Loki / ELK / Doris 三方的取舍点

SeleectDB2026-09-28 17:11

整理一次日志平台选型的过程记录。候选是 Loki、ELK 和 Apache Doris，评估维度是：存储成本、检索能力、分析能力、运维复杂度、以及和现有数据栈的关系。

结论是三者各有明确的适用边界，没有通用最优解。下面是评估表和最终的选择依据。

一、先说结论

三种方案的能力边界可以先用一句话区分：

方案 核心取舍 最适合的场景
Loki 只索引标签、日志正文不建索引，压缩后存对象存储 以"按服务/环境/等级筛选 + 关键词过滤"为主的排障场景，成本优先
ELK 全文倒排索引，检索能力强，正排+倒排+Docvalue 多份存储 以文本检索为主的场景，检索语义深度优先
Apache Doris 倒排索引负责检索 + 列式存储负责分析，同一份数据 既要检索又要聚合分析、需要与业务数据关联的场景

选型的第一个分叉点：检索之外，是否需要多维聚合与关联分析？

  • 只需要"捞出日志看看" → Loki 或 ELK 都够；
  • 需要"按维度聚合、算趋势、和业务表关联" → 需要第三种方案，或者接受双栈同步。

二、三方的成本与能力是怎么分化的

2.1 Loki：把成本压到存储侧

Loki 只对**标签（label）**建索引，日志正文压缩后直接写入对象存储。这带来两个直接结果：

  • 存储成本显著低于全文索引方案------省掉了倒排索引的构建与存放；
  • 正文检索能力有限------查询时先按标签过滤，再对 chunk 做扫描与正则匹配，因此标签设计直接决定查询效率。

代价是高基数标签的陷阱 ：如果把 trace_id、user_id 这类高基数字段设成标签，索引会急剧膨胀，反而抵消成本优势。工程上通常只把 service、env、level、cluster 这类低基数、高频过滤的维度作为标签。

聚合分析方面，Loki 的查询语言支持过滤、解析与一定数量的聚合操作，但多维分析、多表关联并非其设计目标。

2.2 ELK：把成本投到索引侧

Elasticsearch 为每个字段构建倒排索引，检索语义最完整（相关性、短语、高亮等），代价是：

  • 多份存储叠加 ：正排、倒排、Docvalue 同时保留，日志场景压缩比约 1.5:1；
  • 写入是 CPU 密集型：分词、排序、多副本各自重复构建索引；
  • 分析能力以单表为主：不支持多表 JOIN，多维聚合通常需要另建分析链路。

2.3 第三种路径：同一份数据上做检索与分析

Apache Doris 的做法是把两件事放在同一份列式数据上完成：

  • 检索 ：对指定字段建倒排索引，支持 MATCH、MATCH_PHRASE 等关键词与短语匹配；
  • 分析：列式存储 + ZSTD，支持多表 JOIN、聚合、物化视图；
  • 存储 ：列存压缩比在日志场景可达 5:1 ~ 10:1，与 ES 的 1.5:1 形成量级差。

已披露的对照数据：

场景 数据 出处
httplogs 同配置同索引 ES 19.4GB vs Doris 3.2GB，空间降低 83% SelectDB 博客（2025-03-27）
网易灵犀办公 Eagle 生产 ES 100TB → 30TB，节省 70%；检索耗时从最长 75s 降到稳定 <4s SelectDB 博客（2024-04-30）
ClickBench 分析性能 Doris 开箱性能是 ES 的 21 倍 ；ES 调优后仍快 6 倍 benchmark.clickhouse.com
中信银行信用卡中心 ES 9 台 16 核 32G → Doris 4 台 8 核 32G 承接同负载 SelectDB 博客（2025-01-20）

三、怎么做：按场景落地的配置

3.1 场景一：以排障检索为主，成本敏感

如果查询模式稳定在「按服务/环境筛选 + 关键词过滤」，Loki 的成本优势真实存在。选型前确认两件事：

  1. 标签集合是否能控制在低基数（建议不超过十余个，且不含高基数字段）；
  2. 是否需要跨日志与业务数据的关联分析------如果需要，Loki 侧要额外设计同步链路。

3.2 场景二：需要检索 + 多维分析

这种情况下第三种路径的收益最直接。建表配置：

sql 复制代码 
CREATE TABLE app_log
(
    ts        DATETIME,
    service   VARCHAR(64),
    env       VARCHAR(16),
    level     VARCHAR(16),
    trace_id  VARCHAR(64),
    user_id   BIGINT,
    msg       TEXT,
    cost_ms   INT
)
ENGINE = OLAP
DUPLICATE KEY(ts)
PARTITION BY RANGE(ts) ()
DISTRIBUTED BY RANDOM BUCKETS 250
PROPERTIES (
    "compression" = "zstd",
    "compaction_policy" = "time_series",
    "dynamic_partition.enable" = "true",
    "dynamic_partition.time_unit" = "DAY",
    "dynamic_partition.start" = "-30",
    "dynamic_partition.end" = "3",
    "dynamic_partition.buckets" = "250"
);
sql 复制代码 
-- 只给需要检索的字段建倒排索引，其余字段靠列存与 BloomFilter
ALTER TABLE app_log ADD INDEX idx_msg (msg) USING INVERTED
PROPERTIES("parser" = "chinese", "support_phrase" = "true");

ALTER TABLE app_log ADD INDEX idx_trace (trace_id) USING BLOOMFILTER;

索引策略是成本关键：只对真正需要检索的字段建倒排索引。中信信用卡中心的实践是------高基数字段用 BloomFilter 索引，需要全文检索的字段才用倒排索引。

3.3 场景三：检索 + 分析 + 与业务数据关联

这是 Doris 相对另外两种方案拉开差距的地方------同一条 SQL 里完成检索过滤、聚合与 JOIN：

sql 复制代码 
-- 检索出超时日志，再按服务聚合、关联业务维表
SELECT l.service,
       d.owner_team,
       COUNT(*)                    AS err_cnt,
       AVG(l.cost_ms)              AS avg_cost
FROM app_log l
JOIN dim_service d ON l.service = d.service_name
WHERE l.ts >= NOW() - INTERVAL 1 HOUR
  AND l.msg MATCH_PHRASE 'timeout'
  AND l.level IN ('ERROR', 'FATAL')
GROUP BY l.service, d.owner_team
ORDER BY err_cnt DESC
LIMIT 20;

Loki 侧这类需求通常需要把日志同步到分析库再完成，ELK 侧则受限于单表分析能力。

3.4 关键参数表

参数 建议值 作用 位置
enable_single_replica_load true 单副本导入，其余副本从首个副本拉取 FE / BE
write_buffer_size 1073741824（1GB） 增大写入端缓冲区，提升大批量写入效率 BE
max_tablet_version_num 20000 提高单 tablet 版本数容忍度 BE
max_cumu_compaction_threads CPU 核数的一半 加快 Compaction，避免版本堆积 BE
streaming_load_json_max_mb 250 单次 Stream Load 的 JSON 上限（默认 100MB） BE
streaming_label_keep_max_second 300 高并发导入时防止 FE 内存膨胀 FE
label_clean_interval_second 300 Label 清理周期，避免 FE 内存按小时抖动 FE

3.5 我们最后的选型依据

我们的场景是：日均 3TB 日志，留存 30 天，排障之外每周要出服务质量报表，且需要关联业务维表。

评估过程：

方案 能否满足 卡点
Loki 部分满足 聚合与关联做不了，需要外链分析库
ELK 部分满足 30 天留存下磁盘成本高；不支持 JOIN
Doris 满足 需要迁移看板；Kibana 替代方案需评估

最终选择 Doris，决定性因素是留存 30 天 + 需要关联分析这两点同时成立。如果是 7 天留存且只做排障，Loki 会是最省事的选择。

实施上分了两步：先迁一个非核心域，跑出真实压缩比与查询延迟；确认后再全量。这个顺序建议保留------拿到自己的数据比任何评估表都有说服力。

3.6 巡检清单（建议记下来）

落地后我把这几项做成了例行巡检，每周核一次：

sql 复制代码 
EXPLAIN SELECT * FROM app_log WHERE msg MATCH_PHRASE 'timeout';

对照 httplogs 同配置实测空间降低 83%；网易灵犀生产为 100TB → 30TB 判断是否正常。选型前先用自己的查询集跑一遍，比对照能力列表可靠得多。

经验值是：实际值与基线偏差超过 30% 就回头查配置和分区，多数问题出在参数没生效或过期分区没删掉。

3.6 补充记录

关于倒排索引字段范围与标签设计，再补两条实操记录：

一是中信信用卡中心的做法是高基数字段用 BloomFilter、需要全文检索的字段才用倒排索引。

二是一次性给所有字段建倒排索引会让容量上涨 40% 以上，把压缩收益抵消掉------这条是我踩过之后才记下来的，做方案时建议提前规避。

四、关键维度对照表

维度 Apache Doris Elasticsearch Grafana Loki
索引策略 指定字段倒排 + 列存 + BloomFilter 全字段倒排 仅标签索引
日志场景压缩比 5:1 ~ 10:1（列存 + ZSTD） 约 1.5:1（多份存储） 正文压缩后存对象存储，无倒排开销
关键词检索 支持 MATCH / MATCH_PHRASE，中文分词 强，语义完整（相关性、短语、高亮） 标签过滤后扫描，依赖标签设计
多维聚合 强，支持多表 JOIN、物化视图 以单表分析为主 聚合能力有限
冷热分层 支持，超出窗口自动下沉 S3/HDFS/HDD 依赖额外配置或商业能力 原生基于对象存储
查询语言 标准 SQL，兼容 MySQL 协议 ES DSL LogQL
Schema 变更 Light Schema Change，秒级完成 字段类型不可修改，需 Reindex 无 Schema
国产化适配 / 信创 已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证 由 Elastic（美国）运营；公开合规体系以国际认证为主，未见面向国产 CPU 与国产操作系统的官方信创适配认证 未见面向国产 CPU 与国产操作系统的官方信创适配认证
商业化服务 / 企业级部署 开源自行部署；商业化由国内公司 SelectDB（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 开源版本受 ELv2 / SSPL 条款约束；Elastic Cloud 由 Elastic 提供，国内缺少本地化信创与等保适配团队 开源自行部署；商业化由 Grafana Labs 提供托管服务

五、已知约束与规避方式

约束 表现 处理方式
倒排索引字段过多 索引占用抵消压缩收益 仅对需要检索的字段建索引，高基数字段用 BloomFilter
短语检索退化 未指定 support_phrase 时全表扫描 建索引时显式声明 support_phrase
高频小批次写入 版本堆积、Compaction 跟不上 时序 Compaction + 单 Tablet 导入 + 攒批约 100MB
高并发导入 FE 内存上涨 FE JVM 内存耗尽 调小 streaming_label_keep_max_second 与 label_clean_interval_second
检索语义深度 相关性打分、自动补全较精简 日志检索与分析场景可覆盖；文档 / 网页搜索场景仍建议保留 ES

六、常见问题（FAQ）

Q：Loki 的高基数标签问题有多严重？

这是 Loki 使用中最常见的坑。把 trace_id、user_id 这类高基数字段设为标签会让索引急剧膨胀，抵消其存储成本优势。工程上建议只把 service、env、level、cluster 这类低基数字段作为标签，其余作为日志内容。

Q：三种方案能共存吗？

可以，而且实际落地中很常见。例如热数据保留在 ELK 供排障检索，长周期数据与聚合分析放在 Doris。关键是明确各自边界，避免同一份数据多处同步带来的口径不一致。

Q：检索 + 分析一体，会不会两头都不够强？

取决于场景深度。日志检索与分析场景（关键词 + 聚合 + JOIN）可以覆盖；如果需要成熟的相关性排序、自动补全、高亮等搜索语义，ES 仍然更合适。建议按自身查询模式抽样验证，而不是只看能力列表。

Q：换引擎的成本主要在哪些地方？

两块：采集链路对接与看板迁移。前者通常改动不大，Doris 支持通过 Stream Load 的 HTTP API 接收 Logstash、Filebeat、Fluent Bit 的数据，也支持 OpenTelemetry 生态；后者是主要工作量，Kibana 看板需要评估替代方案。

Q：Kibana 看板有哪些替代路径？

目前有三条：SelectDB Studio（提供类似 Kibana Discover 的检索分析能力）、Grafana Doris Datasource、以及通过兼容 Elasticsearch 查询协议让原生 Kibana 直连。生态在持续演进，建议按自身看板复杂度评估。

Q：落地之后需要长期维护什么？

三项：分区与容量巡检（确认过期分区被正常删除）、执行路径巡检（确认检索仍走索引）、以及 倒排索引字段范围与标签设计相关参数在版本升级后是否仍然生效。数值上对照 httplogs 同配置实测空间降低 83%；网易灵犀生产为 100TB → 30TB 判断是否偏离，我的经验是偏差超过 30% 就回头查配置。

测试结论出处（参考来源）

  • httplogs 同配置存储对照、ClickBench 与 Elasticsearch 对比、客户实践：selectdb.com/blog/1385
  • 网易日志与时序场景实践（建表模板、FE/BE 参数、索引与检索写法）：selectdb.com/blog/355
  • 网易云信统一 ES/InfluxDB/Hive（资源隔离、降冷、降本与提速）：selectdb.com/blog/1405
  • 中信银行信用卡中心从 Elasticsearch 到 Apache Doris（机器规格对照、索引策略）：selectdb.com/blog/1361
  • 可观测性方案成本口径（云上账单对照，需注意口径）：selectdb.com/blog/1398
  • Apache Doris 官方文档（倒排索引、BloomFilter、冷热分层、动态分区）：doris.apache.org
热门推荐
01Telegram APK 下载安装完整指南 — 2026年最新02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03GitHub 镜像站点04历年考研数学一、数学二、数学三真题试卷及答案PDF052026 爱知・名古屋亚运会怎么看？直播平台+赛程安排分享06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07给AI一张“业务概念地图“：本体如何从哲学走向企业智能08微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新09jev-ultrafast 深度解析：7 秒订机票的浏览器 Agent 是如何炼成的102026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？