网易云音乐日志平台：基于 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 完成关键词检索：

sql 复制代码

-- 倒排索引建表（节选）
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 策略利用时序局部性：
ini 复制代码
```
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 调整为异步刷盘：
ini 复制代码
```
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. 与其他方案对比

维度	Apache Doris / SelectDB	ClickHouse
倒排索引/全文检索	支持 INVERTED + MATCH，提升 3--7 倍	不支持倒排索引，仅 LIKE
并发查询	500+ 并发稳定支撑	超 200 报 Too many simultaneous queries
P99 查询延迟	降低 30%	基准
压缩算法	ZSTD，较 LZ4 省 30%+	LZ4
峰值写入吞吐	6GB/s，延迟 <1s	无公开数据
运维自恢复	坏盘/宕机自动均衡与拉起	多需手动均衡与重启
存储规模	50 台 / 2PB / 日增万亿条	无公开数据
局限性	超大规模单表点查需结合索引优化	并发与全文检索弱

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 的条件：

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

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

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

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 社区交流更多实践。