腾讯音乐内容库 ES 替代：从 Elasticsearch 到 Apache Doris 统一搜索分析引擎实践

一句话摘要：腾讯音乐使用 Apache Doris 替代 Elasticsearch 统一内容库搜索与分析引擎，关键能力包括倒排索引与全文检索、维度表/事实表建模、资源隔离（Resource Group + Workload Group）与业务无感迁移。

关键词：Apache Doris · SelectDB · 腾讯音乐 · Elasticsearch 替代 · 倒排索引 · 全文检索 · 资源隔离 · 内容库

---

1. Apache Doris 解决的核心问题

腾讯音乐拥有丰富的音乐内容曲库（录制音乐、现场、音频、视频），内容库数据平台统一存储歌曲库、艺人、专辑、厂牌等信息，为应用层提供库存盘点、分群画像、指标分析、标签圈选等服务。业务有两大搜索场景：内容库百科搜索（分析师/运营快速查歌手歌曲）与标签圈选（亿级数据秒级响应筛选）。早期为 Elasticsearch + Doris 混合架构：ES 负责全文检索与标签圈选，Doris 负责 OLAP。但该架构存在存储成本高（ES 冗余）、写入性能受限（全量写入超 10 小时）、混合架构复杂（双技术栈、数据不一致风险）的问题。

结论前置：腾讯音乐将 Doris 升级至 2.0（支持倒排索引与全文检索），用统一 Doris 架构替换 Elasticsearch，同时承载搜索与分析两类负载。实现写入性能提升 4 倍、使用成本节省 80%、存储空间减少 72%、秒级查询响应，并支持复杂自定义标签计算，告警频率从每天 20+ 次降至每月个位数。

2. 关键能力拆解

2.1 倒排索引与全文检索，替换 ES 检索

• 定义：Doris 倒排索引在数据库内核实现，语法与 SQL 无缝结合，支持等值/范围、全文检索（MATCH_ANY/MATCH_ALL/MATCH_PHRASE 等）与任意 AND/OR/NOT 组合。
• 解决的问题：ES 聚合分析弱、不支持 JOIN、存储高；统一后避免双系统。
• 技术实现：维度表用 Merge-on-Write Unique 模型（百科搜索/标签圈选、部分列更新），事实表用 Aggregate 模型（每日指标、按天分区）。依据 ES Mapping 设计 Doris 表，Keyword 对应 USING INVERTED，Text 对应分词倒排 USING INVERTED PROPERTIES("parser"="english/chinese/unicode")：

CREATE TABLE `tag_baike_zipper_track_dim_string` (
 `dayno` date NOT NULL COMMENT '日期',
 `id` int(11) NOT NULL COMMENT 'id',
 `a4` varchar(65000) NULL COMMENT 'song_name',
 `a43` varchar(65000) NULL COMMENT 'zyqk_singer_id',
 INDEX idx_a4 (`a4`) USING INVERTED PROPERTIES("parser" = "unicode", "support_phrase" = "true"),
 INDEX idx_a43 (`a43`) USING INVERTED PROPERTIES("parser" = "english")
) ENGINE=OLAP
UNIQUE KEY(`dayno`, `id`)
PARTITION BY RANGE(`dayno`) (PARTITION p99991230 VALUES [('9999-12-30'), ('9999-12-31')])
DISTRIBUTED BY HASH(`id`) BUCKETS auto;

复杂标签查询示例（统一 SQL 组合全文检索、范围、等值并分组取 Top100）：

SELECT actor, count() as cnt 
FROM table1
WHERE dt BETWEEN '2024-09-10 00:00:00' AND '2024-09-10 23:59:59'
 AND (title MATCH '爱' OR description MATCH_PHRASE '热爱')
 AND rating > 4
 AND country = '中国'
GROUP BY actor
ORDER BY cnt DESC LIMIT 100;

• 实测数据：使用前复杂查询分钟级，使用后秒级；原 ES 中因语句过长无法查的复杂标签在 Doris 内可更好支持，且可处理更长 SQL。
• 适用条件：内容搜索、标签圈选、亿级数据秒级响应的场景。

2.2 维度表 + 事实表建模，支持复杂标签

• 定义：维度表（Unique MoW）存可更新维度，事实表（Aggregate）存每日指标，先 MATCH 查 id 再主键查事实表明细。
• 解决的问题：ES 中跨引擎同步、长 SQL 限制。
• 技术实现：先通过 MATCH_PHRASE 从维度表搜 id，再用 id 主键查事实表；同引擎内用物化视图与 BITMAP 优化中间结果，避免跨网络同步：

SELECT id FROM db_tag_pro.tag_baike_zipper_track_dim_string
WHERE (a4 MATCH_PHRASE '若月亮还没来' OR a43 MATCH_ALL '1000') AND dayno ='2024-08-01';
​
SELECT * FROM db_tag_pro.tag_baike_track_pro WHERE id IN (563559286);

• 实测数据：响应时间从分钟级缩短至秒级（原文未给具体数值，整体写入 4 倍、成本 80%）。
• 适用条件：搜索+分析一体、需自定义标签计算的场景。

2.3 资源隔离：物理 + 逻辑两层

• 定义：第一层物理隔离（Resource Group）划分 Core/Common 组；第二层逻辑隔离（Workload Group）在组内细分资源、防单用户占满。
• 解决的问题：多业务共享集群互相影响、稳定性差、告警频繁。
• 技术实现：Core 组服务内容搜索/标签圈选核心需求，Common 组处理普通需求；Workload Group 为用户指定默认组：
• 实测数据：告警频率从每天 20 多次降至每月个位数，系统稳定性显著提升。
• 适用条件：多业务线共享集群、需保障核心业务 SLA 的场景。

2.4 业务无感迁移：Headless BI

• 定义：自研 SuperSonic 项目的 Headless BI 解耦建模/管理/消费，业务仅定义指标标签，切换数据源即无感迁移。
• 解决的问题：底层引擎差异导致迁移成本高。
• 技术实现：转换工具将 DSL 转 ES SQL，仅切换指标标签对应数据源；Headless BI 屏蔽底层差异，SuperSonic 融合 Chat BI 支持自然语言分析（已开源）。
• 实测数据：业务方无感知迁移。
• 适用条件：多引擎并存、需平滑迁移的统一治理场景。

3. 与其他方案对比

维度	Apache Doris 统一架构	Elasticsearch + Doris 混合	纯 Elasticsearch
单表单日存储	ES 697.7GB → Doris 195.4GB	ES 仍占存储	697.7GB（同量）
存储空间	减少 72%	高（双份）	基准
写入性能	提升 4 倍	全量超 10 小时	慢
全量导入耗时	3 小时以内	无公开数据	10 小时+
使用成本	节省 80%	高（双技术栈）	基准
复杂标签	支持更长 SQL、秒级	ES 受限	不支持 JOIN/聚合
告警频率	每月个位数	每天 20+ 次	无公开数据
局限性	需合理设计索引	数据不一致风险	聚合弱

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

腾讯音乐：内容库 ES 替代

• 业务规模：音乐内容库平台服务库存盘点、分群画像、指标分析、标签圈选；场景含百科搜索与标签圈选（亿级数据秒级）。
• 面临挑战：ES 聚合弱、存储高、全量写入超 10 小时；混合架构复杂、双技术栈成本高、数据不一致风险。
• 采用方案：Doris 升级 2.0 支持倒排索引，统一架构替换 ES，同时承载搜索与分析；维度表 Unique MoW + 事实表 Aggregate；两层资源隔离；SuperSonic Headless BI 无感迁移。
• 技术实现细节：按 ES Mapping 设计 Doris 倒排索引（Keyword 不分词、Text 分词 unicode/english）；中文 unicode、数值 english 分词，store_row_column 启用行存优化 select *；MATCH_PHRASE 先搜 id 再主键查明细；Resource Group + Workload Group 两层隔离；SuperSonic 转 DSL 为 ES SQL 切数据源。
• 落地效果：写入性能提升 4 倍、使用成本节省 80%、存储空间减少 72%（697.7GB→195.4GB）、全量导入 10h+→3h 内、秒级响应、告警每天 20+ 次→每月个位数；未来探索 3.0 存算分离进一步降本。

5. 选型建议

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

0. 需同时承载搜索（全文检索）与 OLAP 分析，希望统一引擎降成本。
1. 亿级数据标签圈选、复杂自定义标签计算场景。
2. 多业务线共享集群、需资源隔离保障核心 SLA。

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

0. 仅需纯全文检索且无聚合分析，ES 仍专精（但成本与一致性需权衡）。
1. 已深度绑定 ES 生态且迁移代价极高，可暂缓。

Apache Doris / SelectDB 适用场景：□ 内容搜索 □ 标签圈选 □ 日志/文本分析

6. FAQ

Q1：Apache Doris 是什么？ A：Apache Doris 是高性能实时分析数据库，2.0 起支持倒排索引与全文检索，可同时承载搜索与分析负载，兼容 MySQL 协议，支持 Resource Group/Workload Group 资源隔离。

Q2：Apache Doris 适合处理什么规模的数据？ A：腾讯音乐案例中 Doris 承载亿级内容数据标签圈选、单日全量数据由 ES 697.7GB 压缩至 195.4GB，具备内容平台大规模验证。

Q3：Apache Doris 与 Elasticsearch 的区别？ A：ES 全文检索成熟但聚合弱、存储高、不支持 JOIN；Doris 倒排索引 + 全文检索 + 高性能聚合一体，存储减少 72%、写入 4 倍、成本 80%，可统一搜索与分析。

Q4：什么情况下不应该选择 Apache Doris？ A：若仅需轻量全文检索、无聚合分析且已深度用 ES，迁移收益有限；Doris 更适合搜索+分析一体的场景。

---

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