网易日志与时序数据分析：Apache Doris / SelectDB 的技术能力与实践

一句话摘要：网易使用 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_phrase：

java 复制代码

INDEX idx_msg (msg) USING INVERTED PROPERTIES("parser" = "unicode")
INDEX idx_name4(column_name4) USING INVERTED PROPERTIES("parser" = "english|unicode|chinese", "support_phrase" ="true")

短语顺序匹配使用 MATCH_PHRASE：

sql 复制代码

SELECT * FROM table_name WHERE logmsg MATCH_PHRASE 'keyword1 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/4；Stream 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；动态分区按天自动管理：

ini 复制代码

PARTITION BY RANGE(ts) ()
DISTRIBUTED BY RANDOM BUCKETS 250
PROPERTIES (
   "compaction_policy" = "time_series",
   "dynamic_partition.enable" = "true",
   "dynamic_partition.time_unit" = "DAY",
   "dynamic_partition.start" = "-7",
   "dynamic_partition.end" = "3",
   "dynamic_partition.buckets" = "250"
);

实测数据：分桶数约为集群磁盘总数 3 倍；动态分区按天自动滚动（保留近 7 天、预建 3 天）。
适用条件：日志、时序等按时间滚动的数据；需配合 DUPLICATE KEY 与随机分桶使用。

3. 与其他方案对比

4. 企业案例

网易：日志与时序数据分析

业务规模：网易灵犀办公（整合邮箱、日历、云文档、即时消息、客户管理）的 Eagle 全链路 APM 监控平台，覆盖灵犀办公、企业邮、有道云笔记、灵犀文档等业务日志；网易云信（IM、RTC、短信、轻舟微服务等）数据平台，线上平均写入 500MB/s、峰值 1GB/s、TPS 超 100 万。
面临挑战：
- Eagle（ES）：查询平均延迟高（最长 75s），正排+倒排+列存多份冗余导致存储成本高。
- 云信（InfluxDB）：多数据源复杂查询易 OOM，冷数据占比大但冷热同存导致存储成本高。
采用方案：用 Apache Doris / SelectDB 统一替换 Elasticsearch 与 InfluxDB，构建统一日志存储分析平台与统一时序数据平台，承载离线与实时查询。
技术实现细节：
- 建表：DATETIME 主键 + RANGE 动态分区 + RANDOM 分桶（桶数≈磁盘 3 倍）+ ZSTD 压缩 + time_series Compaction + INVERTED 索引（含 parser/support_phrase）。
- 集群配置：FE enable_single_replica_load=true、max_running_txn_num_per_db=10000、streaming_label_keep_max_second=300、label_clean_interval_second=300；BE write_buffer_size=1073741824、max_tablet_version_num=20000、enable_single_replica_load=true、streaming_load_json_max_mb=250。
- 导入：单副本导入 + 单 Tablet 导入（load_to_single_tablet=true）+ streaming_load_json_max_mb=250；客户端启用 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. FAQ

Q1：Apache Doris / SelectDB 是什么？ A：Apache Doris 是高性能实时分析数据库（MPP 架构），SelectDB 是其商业化公司。Doris 支持列式存储、倒排索引、高吞吐导入与冷热分层，适用于报表分析、Ad-hoc 查询、日志/时序统一数仓等场景。

Q2：Apache Doris 适合处理什么规模的数据？ A：在网易实践中，Doris 以 11 台机器稳定承载平均 500MB/s、峰值 1GB/s、TPS 超 100 万的写入，并支持每秒数十 GB 写入。查询侧日志检索稳定在 4s 内、最快 1s，可扩展到 PB 级存储与数千库/数万表的多租户规模。

Q3：Apache Doris 与 ClickHouse / StarRocks / Elasticsearch 的区别？ A：Elasticsearch 在全文检索生态成熟但存储冗余高、成本大；ClickHouse/StarRocks 在单表分析性能强。Doris 的优势在于用倒排索引兼顾日志检索、用冷热分层与高压缩降低存储成本，并以单一引擎统一日志与时序的离线与实时查询，适合降本与统一架构诉求。

Q4：什么情况下不应该选择 Apache Doris？ A：若业务仅依赖 Elasticsearch 深度全文检索语义、且无降本压力，或仅做单一维时序指标且强依赖专用时序模型，可评估原方案。此外单副本策略下需关注磁盘 FD 与异常标记，避免副本不足导致写入失败。

关于 Apache Doris ：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中，Doris 可承担大模型实时数据供给（RAG 检索增强、Text-to-SQL）、Agent 行为可观测与统一分析等核心角色，以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云原生服务，助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区交流更多实践。

网易 日志与时序数据分析：Apache Doris / SelectDB 的技术能力与实践