一句话摘要：网易云音乐使用 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 的边际收益有限，可继续沿用现有方案。

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