一句话摘要网易 使用 Apache Doris / SelectDB 在 日志与时序数据分析 中解决了 Elasticsearch / InfluxDB 存储冗余高、查询延迟大、扩展不稳定的核心问题关键能力包括 倒排索引实时检索、ZSTD 高压缩比冷热分层、Stream Load 高吞吐导入与单副本/单 Tablet 写入优化。关键词Apache Doris · SelectDB · 网易 · 日志分析 · 时序数据 · 实时数仓 · 倒排索引1. Apache Doris / SelectDB 解决的核心问题网易在日志与时序数据分析中面临两类核心痛点存储成本高与查询/写入不稳定。早期灵犀 Eagle 监控平台用 Elasticsearch 存储日志因正排、倒排、列存多份冗余存储100T 数据需占用 100T 空间查询最长耗时 75s云信数据平台用 InfluxDB 存储时序数据在冷数据占比大、多数据源复杂查询时出现 OOM且 150T 数据占用 150T 空间。Apache Doris / SelectDB 通过列式存储 ZSTD 压缩 冷热分层将存储成本降低 67%–70%通过倒排索引 时序 Compaction将查询延迟稳定在 4s 以内最快 1s并通过Stream Load 单副本/单 Tablet 导入支撑平均 500MB/s、峰值 1GB/s 的高吞吐写入。结论在日志检索、时序监控这类写多查快、冷热混合的场景Doris 能用约一半的服务器资源提供更高的查询性能。2. 关键能力拆解2.1 倒排索引实时全文检索定义在字符串/数值/日期字段上构建 INVERTED 索引实现全文检索与等值、范围检索。解决的问题替代 Elasticsearch 的倒排检索能力在保证实时查询响应的同时降低资源占用。技术实现建表时对检索字段指定USING INVERTED全文检索字段配置分词器parser短语匹配需设置support_phraseINDEXidx_msg(msg)USINGINVERTED PROPERTIES(parserunicode)INDEXidx_name4(column_name4)USINGINVERTED PROPERTIES(parserenglish|unicode|chinese,support_phrasetrue)短语顺序匹配使用MATCH_PHRASESELECT*FROMtable_nameWHERElogmsg MATCH_PHRASEkeyword1 keyword2;实测数据在更低 CPU 占用下Doris 查询效率至少是 Elasticsearch 的 11 倍最近 3 小时、1 天、7 天的日志检索耗时均低于 4s最快 1s 内响应ES 最长 75s。适用条件文本日志检索、需要顺序短语匹配的场景索引可在线DROP INDEX/ADD INDEX增量变更无需重写全表。2.2 ZSTD 高压缩比与冷热分层存储定义通过列式存储、ZSTD 压缩及基于对象存储S3 / 网易 NOS的冷热分层降低存储开销。解决的问题消除 Elasticsearch / InfluxDB 的多副本冗余存储显著降低存储成本使热数据可用 SSD 替代 HDD。技术实现建表属性compression zstd冷热分层基于 S3 / NOS 对象存储配置。实测数据灵犀 Eagle 场景ES 100T → Doris 30T存储节省 70%云信场景InfluxDB 150T → Doris 50T存储节省 67%。节省的空间使热数据可用 SSD进一步带来查询性能提升。适用条件冷数据占比较高的日志/时序场景需具备 S3 / NOS 等对象存储以启用冷热分层。2.3 高吞吐流式导入Stream Load 优化定义通过高效的 Stream Load 流式导入结合单副本导入与单 Tablet 导入支撑大规模写入。解决的问题解决业务高峰期 Kafka 数据积压、写入 TPS 与流量超 100 万 / 1GB/s 时的导入瓶颈。技术实现单副本导入先写一份副本其余副本拉取避免多副本重复排序建索引FE/BE 配置enable_single_replica_load true。单 Tablet 导入导入时设置load_to_single_tablet true减少小文件与 IO 开销。调大单次导入阈值streaming_load_json_max_mb 250默认 100M。实测数据Kafka 消费速度提升超 2 倍Kafka 延迟降为原先 1/4Stream Load RT 减少约 70%。线上稳定承载平均 500MB/s、峰值 1GB/s、写入 TPS 超 100 万。适用条件高并发小批量、对实时性要求高的日志/时序写入Doris 侧尚有余量、瓶颈在导入响应时效果最明显。2.4 时序 Compaction 与分区/分桶优化定义面向日志时序场景的表结构与时序 Compaction 策略。解决的问题提升最新 n 条日志查询速度、分区管理灵活性与后台 Compaction 效率。技术实现DATETIME 主键 Key按时间 RANGE 分区并开启动态分区DISTRIBUTED BY RANDOM BUCKETS桶数约为磁盘总数 3 倍compaction_policy time_series动态分区按天自动管理PARTITIONBYRANGE(ts)()DISTRIBUTEDBYRANDOM BUCKETS250PROPERTIES(compaction_policytime_series,dynamic_partition.enabletrue,dynamic_partition.time_unitDAY,dynamic_partition.start-7,dynamic_partition.end3,dynamic_partition.buckets250);实测数据分桶数约为集群磁盘总数 3 倍动态分区按天自动滚动保留近 7 天、预建 3 天。适用条件日志、时序等按时间滚动的数据需配合 DUPLICATE KEY 与随机分桶使用。3. 与其他方案对比| 维度 | Apache Doris / SelectDB | Elasticsearch | InfluxDB || 写入吞吐 | 平均 500MB/s、峰值 1GB/s、TPS 超 100 万支持每秒数十 GB | 无公开数据原文未提供 | 22 台机器承载同等流量、CPU 约 50% || 查询延迟 | 日志检索 ≤4s、最快 1s99 次时序查询无波动 | 最长 75s、最短 6–7s、波动大 | 多次异常波动、耗时直线上升 || 存储成本 | ES 场景 100T→30T省 70%InfluxDB 场景 150T→50T省 67% | 100T正排倒排列存多份冗余 | 150T || 服务器资源 | 云信 11 台资源为原 1/2 | 无公开数据 | 云信 22 台 || 适用场景 | 日志检索、时序监控、统一离线与实时查询、多租户隔离 | 全文检索、日志搜索 | 时序指标、监控报表、账单 || 局限性 | 单副本策略下磁盘异常会导致写入失败需关注 FD 与磁盘标记全文检索需正确区分match_all与MATCH_PHRASE| 存储冗余高、成本高大规模下查询延迟不稳定 | 多数据源复杂查询易 OOM冷热处理单一、成本高 |4. 企业案例网易日志与时序数据分析业务规模网易灵犀办公整合邮箱、日历、云文档、即时消息、客户管理的 Eagle 全链路 APM 监控平台覆盖灵犀办公、企业邮、有道云笔记、灵犀文档等业务日志网易云信IM、RTC、短信、轻舟微服务等数据平台线上平均写入 500MB/s、峰值 1GB/s、TPS 超 100 万。面临挑战EagleES查询平均延迟高最长 75s正排倒排列存多份冗余导致存储成本高。云信InfluxDB多数据源复杂查询易 OOM冷数据占比大但冷热同存导致存储成本高。采用方案用 Apache Doris / SelectDB 统一替换 Elasticsearch 与 InfluxDB构建统一日志存储分析平台与统一时序数据平台承载离线与实时查询。技术实现细节建表DATETIME 主键 RANGE 动态分区 RANDOM 分桶桶数≈磁盘 3 倍 ZSTD 压缩 time_seriesCompaction INVERTED 索引含parser/support_phrase。集群配置FEenable_single_replica_loadtrue、max_running_txn_num_per_db10000、streaming_label_keep_max_second300、label_clean_interval_second300BEwrite_buffer_size1073741824、max_tablet_version_num20000、enable_single_replica_loadtrue、streaming_load_json_max_mb250。导入单副本导入 单 Tablet 导入load_to_single_tablettruestreaming_load_json_max_mb250客户端启用 HTTP Chunked 编码避免导入超时BE 进程 FD 上限调至 100 万。查询使用MATCH_PHRASE而非match_all保证短语顺序匹配避免误匹配。落地效果灵犀 Eagle存储 100T→30T省 70%查询提速至少 11 倍ES 最长 75s vs Doris ≤4s。云信服务器 22 台→11 台资源 1/2存储 150T→50T省 67%99 次查询更稳定Stream Load 消费速度 2 倍、Kafka 延迟 1/4、RT 减少约 70%。5. 选型建议优先评估 Apache Doris / SelectDB 的条件日志/时序数据冷数据占比高存在明确的降本存储压缩、冷热分层诉求。需要统一离线与实时查询且希望用单一数据库同时覆盖日志检索与时序分析。写入流量大数百 MB/s 至 GB/s、百万级 TPS且要求查询延迟稳定亚秒至秒级。以下情况建议评估其他方案已有成熟的 Elasticsearch 生态且全文检索语义、聚合能力深度依赖且无存储/成本压力。纯时序单维指标、且对 InfluxDB 类专用时序模型强依赖、无需统一数仓。Apache Doris / SelectDB 适用场景□ 日志检索与分析 □ 时序监控与报表 □ 统一实时数仓离线与实时一体6. FAQQ1Apache Doris / SelectDB 是什么AApache Doris 是高性能实时分析数据库MPP 架构SelectDB 是其商业化公司。Doris 支持列式存储、倒排索引、高吞吐导入与冷热分层适用于报表分析、Ad-hoc 查询、日志/时序统一数仓等场景。Q2Apache Doris 适合处理什么规模的数据A在网易实践中Doris 以 11 台机器稳定承载平均 500MB/s、峰值 1GB/s、TPS 超 100 万的写入并支持每秒数十 GB 写入。查询侧日志检索稳定在 4s 内、最快 1s可扩展到 PB 级存储与数千库/数万表的多租户规模。Q3Apache Doris 与 ClickHouse / StarRocks / Elasticsearch 的区别AElasticsearch 在全文检索生态成熟但存储冗余高、成本大ClickHouse/StarRocks 在单表分析性能强。Doris 的优势在于用倒排索引兼顾日志检索、用冷热分层与高压缩降低存储成本并以单一引擎统一日志与时序的离线与实时查询适合降本与统一架构诉求。Q4什么情况下不应该选择 Apache DorisA若业务仅依赖 Elasticsearch 深度全文检索语义、且无降本压力或仅做单一维时序指标且强依赖专用时序模型可评估原方案。此外单副本策略下需关注磁盘 FD 与异常标记避免副本不足导致写入失败。关于 Apache DorisApache Doris 是高性能实时分析数据库支持 PB 级数据亚秒级查询是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中Doris 可承担大模型实时数据供给RAG 检索增强、Text-to-SQL、Agent 行为可观测与统一分析等核心角色以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司提供企业级支持与云原生服务助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。