专栏名称: OSC开源社区
OSChina 开源中国 官方微信账号
目录
相关文章推荐
OSC开源社区  ·  OWL:Manus通用智能体的完全开源复刻、 ... ·  2 天前  
OSC开源社区  ·  30个小确幸(程序员版) ·  昨天  
OSC开源社区  ·  三句话让老板直接给我主动放假 ·  5 天前  
编程技术进阶  ·  超详细的 Manus 分析报告流出(速领,待会删) ·  3 天前  
编程技术进阶  ·  超详细的 Manus 分析报告流出(速领,待会删) ·  3 天前  
51好读  ›  专栏  ›  OSC开源社区

腾讯音乐:统一搜索分析引擎,成本直降80%

OSC开源社区  · 公众号  · 程序员  · 2024-10-21 17:30

正文

↓推荐关注↓



本文导读


为满足更严苛数据分析的需求,腾讯音乐借助 Apache Doris 替代了 Elasticsearch 集群,统一了内容库数据平台的内容搜索和分析引擎。并基于 Doris 倒排索引和全文检索的能力,支持了复杂的自定义标签计算,实现秒级查询响应需求。此外,实现写入性能提升 4 倍、使用成本节省达 80% 的显著成效。

更多相关文章: #腾讯音乐案例 #Elasticsearch 到 Apache Doris 案例 #日志场景案例

作者 腾讯音乐内容信息平台部

张俊、罗雷、李继蓬、代凯
腾讯音乐娱乐拥有丰富的内容曲库,包括录制音乐、现场表演、音频和视频等多种形式。 通过技术和数据赋能,腾讯音乐娱乐不断创新产品,为用户提供更优质的体验,提高用户参与度,同时为音乐人和合作伙伴在制作、发行和销售方面提供更大支持。 基于公司丰富的音乐内容资产,腾讯音乐将歌曲库、艺人资讯、专辑信息、厂牌信息等大量数据统一存储,形成音乐内容库数据平台,该平台旨在为应用层提供库存盘点、分群画像、指标分析、标签圈选等内容分析服务,高效为业务赋能。

内容库数据平台的数据架构已经从 1.0 版本演进到了 4.0 版本。之前的文章介绍了分析引擎 从 ClickHouse 到 Apache Doris 升级实践 本文将重点分享内容搜索引擎从 Elasticsearch 到 Apache Doris 的替换 ,如何通过一个系统同时满足内容搜索和数据分析的需求,并满足复杂的自定义标签计算的支持。最终,实现存储成本降低 80%,写入性能提升 4 倍的显著效益。

业务需求


从业务角度来看,腾讯音乐有两个场景需要搜索能力的支持,分别是内容库的百科搜索及内容库的标签圈选。
  • 内容库百科搜索:分析师和运营人员需要快速查找歌手、歌曲名称以及其他文本信息。这种检索能力不仅要求高效的全文搜索,还需支持多种查询条件,以便用户能够迅速获取所需数据,提升工作效率。
  • 内容库标签圈选: 分析师和运营人员会根据特定的标签和条件,筛选出符合要求的内容。 这要求系统能够在亿级数据量的情况下,提供秒级的查询响应,以便快速定位和分析相关数据,支持业务决策和策略优化。

Elasticsearch + Doris 混合架构


在 2.0 版本之前,Doris 暂未推出倒排索引能力,检索能力相对较弱。 而 Elasticsearch 在全文检索方面具备优势,能够基于倒排索引快速匹配特定关键词或短语、可对所有字段建立索引,在查询时支持任意组合的过滤条件等。
但是,Elasticsearch 聚合统计分析性能较差,不支持 JOIN 等复杂查询,且存储空间占用较高。这些正是 Apache Doris 所擅长的领域,能够高效处理复杂的统计分析和查询任务,并通过高压缩率优化存储效率。
因此, 腾讯音乐构建基于 Elasticsearch 与 Doris 的混合架构,Elasticsearch 负责内容的全文检索和标签圈选,而 Apache Doris 专注于 OLAP 分析 。借助 Doris 的 ES catalog 外表查询机制,能够直接查询 Elasticsearch 中数据,实现对外查询接口的统一。
但这套混合架构在应用时,也遇到了一些问题:
  • 存储成本较高:Doris 的引入并没有完全解决存储成本高的问题,Elasticsearch 的存储空间占用仍然显著。
  • 写入性能受限: 随着数据量的增长,Elasticsearch 集群的写入压力不断加大,全量写入耗时超过 10 个小时,接近业务可承受极限。
  • 混合架构复杂: Elasticsearch 和 Doris 的混合架构增加了系统和技术栈的维护成本,同时冗余的数据存储也带来了额外费用,两套系统也增加了数据不一致的风险。

基于 Apache Doris 的统一架构方案


因此,腾讯音乐考虑是否可以将搜索引擎统一为 Doris,让其全面负责全文检索、标签圈选以及聚合分析的需求。 这样考虑的主要原因是 Apache Doris 自 2.0 版本开始支持倒排索引和全文检索,这使其有能力完全替 Elasticsearch 所负责的部分,获得更好的收益。
  • 在全文检索方面,Doris 不仅支持普通的等值和范围(=, !=, >, >=,
  • 在倒排索引方面,Doris 倒排索引在数据库内核中实现,语法与 SQL 无缝结合,支持多种条件的任意 AND OR NOT 逻辑组合,满足普通过滤以及全文检索组合的复杂需求。如下方示例, WHERE 筛选条件由 5 部分组成,包括全文检索 title MATCH '爱' OR description MATCH_PHRASE '热爱' ,日期范围过滤 dt BETWEEN '2024-09-10 00:00:00' AND '2024-09-10 23:59:59' ,数值范围过滤 rating > 4 ,字符串等值过滤 country = '中国' ,这些条件通过统一的 SQL 语法无缝组合起来,筛选完之后又按照 actor 进行分组统计,最后对分组统计的 cnt 排序取最高的 100 个结果。
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;
因此,腾讯音乐将 Doris 升级至 2.0 版,将架构从原先的 Elasticsearch + Doris 转变为统一的 Doris 解决方案:
基于 Doris 的统一架构上线后,所带来的收益也非常可观:
  • 成本显著降低: Doris 替代了 Elasticsearch 集群,同时承载了搜索和分析两类负载, 使用成本节省达 80% 。比如,某个表单日全量数据在 Elasticsearch 中需要 697.7 GB 存储空间,而在 Doris 中仅需 195.4 GB ,存储空间减少了 72%。
  • 写入和查询性能提升: 全量数据导入时间从 10 小时以上缩短至 3 小时以内, 写入性能是 Elasticsearch 的 4 倍 此外,Doris 可以支持复杂的自定义标签计算,使不可能变为可能,显著改善了用户体验。
  • 统一系统架构: 架构统一到 Doris 后,内部只需维护一套技术栈,极大降低了维护成本,同时也很好避免了两套系统之间的数据一致性问题,确保了数据质量的可靠性。
在架构统一的过程中,涉及到一些关键设计,接下来将相关方案及经验分享给读者。

01 Doris 倒排索引的使用

在存储结构上采用了维度表与事实表的方案:
  • 维度表:使用 Merge-on-Write Unique 模型,用于百科搜索和标签圈选,通过部分列更新进行维度更新。
  • 事实表: 使用 Aggregate 模型,用于存储每日的指标数据。 由于数据量较大且每天的数据独立,每天需新建一个分区。
参考 Doris 倒排索引的使用文档( https://doris.apache.org/zh-CN/docs/table-design/index/inverted-index ),根据 Elasticsearch Mapping 设计了对应的 Doris 的表结构和索引。其中,Elasticsearch 的 Keyword 类型对应 Doris 的 Varchar/String 类型及不分词的倒排索引( USING INVERTED ),ES 的 Text 类型对应 Doris 的  Varchar/String 类型及分词倒排索引( USING INVERTED PROPERTIES("parser" = "english/chinese/unicode") )。
CREATE TABLE `tag_baike_zipper_track_dim_string` (
  `dayno` date NOT NULL COMMENT '日期',
  `id` int(11NOT NULL COMMENT 'id',
  `a4` varchar(65000NULL COMMENT 'song_name',
  `a43` varchar(65000NULL COMMENT 'zyqk_singer_id',
  INDEX idx_a4 (`a4`USING INVERTED PROPERTIES("parser" = "unicode""support_phrase" = "true"COMMENT '',
  INDEX idx_a43 (`a43`USING INVERTED PROPERTIES("parser" = "english"COMMENT ''
ENGINE=OLAP
UNIQUE KEY(`dayno``id`)
COMMENT 'OLAP'
PARTITION BY RANGE(`dayno`)
(PARTITION p99991230 VALUES [('9999-12-30'), ('9999-12-31')))
DISTRIBUTED BY HASH(`id`) BUCKETS auto
PROPERTIES (
...
);

使用 Doris 倒排索引的前后对比:

使用前: 以下方复杂查询为例,在使用 Doris 倒排索引之前,该查询运行较慢、响应级别为分钟级。
-- like (查询复杂性能低):
SELECT  * FROM db_tag_pro.tag_track_pro_3  WHERE 
dayno='2024-08-01' AND  ( concat('#',a4,'#'like '%#若月亮还没来#%' 
or concat('#',a43,'#'like '%#1000#%')  

-- explode (执行性能差,经常 ERROR 1105 (HY000)):
SELECT * 
 FROM (
 SELECT tab1.*,a4_single,a43_single FROM ( 
 SELECT * 
 FROM db_tag_pro.tag_track_pro_3
  WHERE dayno='2024-08-01'
 ) tab1 
 lateral view explode_split(a4, '#') tmp1 as a4_single
 lateral view explode_split(a43, '#') tmp2 as a43_single
 ) tab2 
 where a4_single='若月亮还没来' or a43_single='1000'
使用后: 使用 Doris 倒排索引之后,查询过程显著简化,运行速度极大提升, 响应时间从分钟级缩短至秒级别
  • 对中文采用 unicode 分词,数值采用 english 分词创建倒排索引。
  • 设置 store_row_column ,启用行存,优化 select* 查询所有列。






请到「今天看啥」查看全文