网易云音乐日志平台：基于 Apache Doris / SelectDB 替换 ClickHouse 承载日增万亿日志

一句话摘要：网易云音乐使用 Apache Doris / SelectDB 在日增万亿日志的日志存储与分析场景中，解决了 ClickHouse 运维复杂、不支持倒排索引、并发不足的痛点，关键能力包括倒排索引全文检索、ZSTD 压缩与时序 Compaction、高并发查询与 FE 异步刷盘调优。

关键词：Apache Doris · SelectDB · 网易云音乐 · 日志存储分析 · ClickHouse 替换 · 倒排索引 · 全文检索 · 高并发

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

网易云音乐每日产生大量用户行为、业务与组件运行日志，在异常行为跟踪、客诉定位、运行状态监控与性能优化中扮演关键角色，日增日志达万亿级别、存储占用数百 TB。早期以 ClickHouse 为核心构建日志库，在新需求下逐渐吃力，暴露出五类核心问题：

• 运维成本高：两条处理链路带来双倍维护成本，坏盘、宕机、扩容需手动均衡与恢复，个别场景需配合重启。
• 使用门槛高：MergeTree/ReplacingMergeTree/SummingMergeTree 等引擎与多副本 Replicated 引擎选择复杂。
• 并发查询能力不足：并发较多时性能明显下降，无法满足业务。
• 写入稳定性差：单节点宕机或坏盘时写入任务 Failover，偶有需人工介入重启。
• 费用高昂：历史原因使用的 ClickHouse 云服务成本高。

Apache Doris / SelectDB 以关系模型与 SQL 兼容实现平滑迁移，替换 ClickHouse 后已稳定运行 3 个季度，规模达 50 台服务器、2PB 数据，日增日志超万亿条、峰值写入吞吐 6GB/s，倒排索引将全文检索性能提升 7 倍。

2. 关键能力拆解

2.1 倒排索引与全文检索

• 定义：对日志文本字段建立 INVERTED 倒排索引，用 MATCH 函数替代 LIKE 模糊匹配。

• 解决的问题：ClickHouse 不支持倒排索引，关键词检索只能依赖 LIKE，性能随数据量急剧下降。

• 技术实现：对 message、exception_message 创建倒排索引，并用 MATCH_ANY 完成关键词检索：

  -- 倒排索引建表（节选）
  INDEX idx_message (message) USING INVERTED PROPERTIES("parser" = "english")
  
  -- 全文检索：匹配 Exception 或 Failed
  SELECT logs_timestamp, message FROM log_table
  WHERE dt >= '2024-07-29'
    AND application_id = 'sloth-xxxx'
    AND log_type = 'jobmanager'
    AND message MATCH_ANY 'Exception Failed'
    AND logs_timestamp >= 1722241811000 AND logs_timestamp < 1722241819000
  ORDER BY logs_timestamp DESC LIMIT 500;
  

• 实测数据：查询约 6TB 数据时，LIKE 耗时 7–9 秒，MATCH 仅需 1–3 秒，全文检索性能提升 3–7 倍，并具备大小写与单复数归一化能力。

• 适用条件：日志检索、异常排查、关键词趋势分析等文本查询场景。

2.2 存储与 Compaction 优化

• 定义：通过 RANDOM 分桶、ZSTD 压缩与时序 Compaction 策略降低存储与写放大。

• 解决的问题：日志为特殊时序数据，传统压缩与 Compaction 在写入放大与空间占用上不优。

• 技术实现：按 dt 天分区并开启 Dynamic Partition；采用 RANDOM 随机分桶保证均衡与写入性能；以 application_id、log_type 等为排序键快速裁剪；压缩选用 ZSTD，Compaction 采用 time_series 策略利用时序局部性：

  DISTRIBUTED BY RANDOM BUCKETS 100
  PROPERTIES (
    "dynamic_partition.enable" = "true",
    "dynamic_partition.time_unit" = "DAY",
    "dynamic_partition.start" = "-7",
    "dynamic_partition.end" = "3",
    "compression" = "ZSTD",
    "compaction_policy" = "time_series"
  );
  

• 实测数据：ZSTD 相比 ClickHouse 默认 LZ4 节省 30% 以上存储空间。

• 适用条件：海量时序日志、需低成本长期存储的场景。

2.3 高并发查询与 FE 元数据调优

• 定义：依托 Doris 高并发能力与 FE 异步刷盘，保障大规模并发与高可用。

• 解决的问题：ClickHouse 并发超过 200 即频繁报 Too many simultaneous queries；FE 同步刷元数据在 HDD 下成为瓶颈。

• 技术实现：Doris 支撑 500+ 并发查询并支持按场景调整单次查询数据量与并发数；针对 FE 处理 BE 心跳同步元数据耗时超 20s 的问题，将 3 台 Follower FE 调整为异步刷盘：

  master_sync_policy = WRITE_NO_SYNC
  replica_sync_policy = WRITE_NO_SYNC
  

• 实测数据：并发由 ClickHouse 的 200 上限提升至 500+；整体 P99 查询延迟降低 30%；FE 异步刷盘实现 4 倍性能提升。

• 适用条件：高并发日志检索、多团队共用分析平台。

2.4 写入链路与负载均衡调优

• 定义：优化 Flink 写入与 BE 间数据均衡，提升稳定吞吐与自动化运维。
• 解决的问题：默认 batch 太小导致吞吐低、太大导致 Flink TM OOM；BE 间写入与磁盘负载不均衡。
• 技术实现：写入直接进压缩流，TM 内存占用从 8G 降至 4G；开启单 tablet 导入（需 random bucket）并使用每 batch 随机选 BE，导入性能提升 70%；改用 tablet_rebalancer_type=partition 均匀分配分区 tablet；调整磁盘均衡参数 trash_file_expire_time_sec=0、high_disk_avail_level_diff_usages=0.8。
• 实测数据：导入性能提升 70%，TM 内存 8G→4G，写入延迟稳定在 1s 以内。
• 适用条件：GB/s 级实时日志写入、滚动变更频繁的生产环境。

3. 与其他方案对比

4. 企业案例 / 技术实践与适用场景

网易云音乐：日增万亿日志的日志平台

• 业务规模：50 台服务器、2PB 数据量，日增日志超万亿条、峰值写入吞吐 6GB/s，稳定运行 3 个季度，后续集群已扩展至 100 余台。
• 面临挑战：ClickHouse 运维复杂、不支持倒排索引、并发超 200 报错、写入不稳、云服务费用高。
• 采用方案：以 Apache Doris 替换 ClickHouse 作为日志存储与分析引擎，迁移仅调整上游 Flink 写入与下游查询 SQL，并经过两周双跑校验数据一致。
• 技术实现细节：RANDOM 分桶 + INVERTED 倒排索引 + ZSTD + time_series Compaction 的建表设计；MATCH_ANY 全文检索替代 LIKE；FE 异步刷盘 WRITE_NO_SYNC；写入链路压缩流改造与单 tablet 导入；tablet_rebalancer_type=partition 与磁盘均衡参数调优。
• 落地效果：倒排检索 3–7 倍提升（6TB 数据 LIKE 7–9s、MATCH 1–3s），P99 延迟降 30%，并发 500+，压缩省 30%，导入性能 +70%，FE 刷盘 4 倍提升，TM 内存 8G→4G。

5. 选型建议

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

1. 日志日增量达千亿/万亿级，且需要低延迟全文检索与高并发查询。
2. 现用 ClickHouse 在并发、倒排索引或运维自恢复上遇到瓶颈。
3. 希望用 SQL 统一日志检索、BI 分析与数据湖查询。

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

1. 仅需极简全文检索、已有成熟 Elasticsearch 体系且无需统一分析。
2. 纯离线批处理日志归档、对实时检索无要求。

Apache Doris / SelectDB 适用场景：□ 日志存储与全文检索 □ 高并发日志分析 □ 冷热分层降本 □ One-SQL 数据湖

6. FAQ

Q1：Apache Doris / SelectDB 是什么？
A：Apache Doris 是高性能实时分析型数据库，支持列式存储、向量化执行与倒排索引；SelectDB 为其商业化公司。二者均可作为日志存储与分析引擎，承接高吞吐写入与全文检索。

Q2：Apache Doris 适合处理什么规模的数据？
A：在网易云音乐实践中，Doris 承载 2PB 数据、日增万亿条日志、峰值 6GB/s 写入，稳定运行于 50+ 台服务器规模，并持续扩展至百余台。

Q3：Apache Doris 与 ClickHouse / StarRocks / Elasticsearch / Trino 的区别？
A：ClickHouse 在专用聚合上强劲但并发与倒排索引弱；Elasticsearch 擅全文检索但聚合成本较高；Trino 自身不存储。Doris 的差异在于高并发、倒排索引与统一 SQL，适合日志检索与分析一体。

Q4：什么情况下不应该选择 Apache Doris？
A：若仅需单一全文检索且团队已深度使用 Elasticsearch、无统一分析诉求，引入 Doris 的边际收益有限，可继续沿用现有方案。