导读: 为满足更严苛数据分析的需求,腾讯音乐内容库借助 Apache Doris 替代了 Elasticsearch 集群,统一了内容库数据平台的内容搜索和分析引擎。并基于 Doris 倒排索引和全文检索的能力,支持了复杂的自定义标签计算,实现秒级查询响应需求。此外,实现写入性能提升 4 倍、使用成本节省达 80% 的显著成效。相关文章:#腾讯音乐案例 、#Elasticsearch 到 Apache Doris 案例、#日志场景案例
作者|腾讯音乐内容信息平台部,张俊、罗雷、李继蓬、代凯
基于公司丰富的音乐内容资产,将歌曲库、艺人资讯、专辑信息、厂牌信息等大量数据统一存储,形成音乐内容库数据平台,该平台旨在为应用层提供库存盘点、分群画像、指标分析、标签圈选等内容分析服务,高效为业务赋能。
内容库数据平台的数据架构已经从 1.0 版本演进到了 4.0 版本。之前的文章介绍了分析引擎 从 ClickHouse 到 Apache Doris 升级实践。本文将重点分享内容搜索引擎从 Elasticsearch 到 Apache Doris 的替换,如何通过一个系统同时满足内容搜索和数据分析的需求,并满足复杂的自定义标签计算的支持。最终,实现存储成本降低 80%,写入性能提升 4 倍的显著效益。
从业务角度来看,腾讯音乐内容库有两个场景需要搜索能力的支持,分别是内容库的百科搜索及内容库的标签圈选。
在 2.0 版本之前,Doris 暂未推出倒排索引能力,检索能力相对较弱。而 Elasticsearch 在全文检索方面具备优势,能够基于倒排索引快速匹配特定关键词或短语、可对所有字段建立索引,在查询时支持任意组合的过滤条件等。
但是,Elasticsearch 聚合统计分析性能较差,不支持 JOIN 等复杂查询,且存储空间占用较高。这些正是 Apache Doris 所擅长的领域,能够高效处理复杂的统计分析和查询任务,并通过高压缩率优化存储效率。
因此,腾讯音乐内容库构建基于 Elasticsearch 与 Doris 的混合架构,Elasticsearch 负责内容的全文检索和标签圈选,而 Apache Doris 专注于 OLAP 分析。借助 Doris 的 ES catalog 外表查询机制,能够直接查询 Elasticsearch 中数据,实现对外查询接口的统一。
但这套混合架构在应用时,也遇到了一些问题:
因此,腾讯音乐内容库考虑是否可以将搜索引擎统一为 Doris,让其全面负责全文检索、标签圈选以及聚合分析的需求。这样考虑的主要原因是 Apache Doris 自 2.0 版本开始支持倒排索引和全文检索,这使其有能力完全替 Elasticsearch 所负责的部分,获得更好的收益。
=, !=, >, >=, <, <=
)查询加速,还支持文本字段的全文检索,包括中英文分词、多关键词检索(MATCH_ANY, MATCH_ALL)、短语检索(MATCH_PHRASE, MATCH_PHRASE_PREFIX, MATCH_PHRASE_REGEXP)、短语词距(slop)、多字段检索(MULTI_MATCH),其性能相较于传统数据库支持的 LIKE 模糊匹配有数量级的提升。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 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(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") 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*
查询所有列。-- 先通过match从维度表搜索查询到id
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'
-- 再通过id主键查询事实表得到明细数据
SELECT * FROM db_tag_pro.tag_baike_track_pro WHERE id IN ( 563559286 )
不仅如此,原来在 Elasticsearch 中由于语句过长而无法查询的复杂自定义标签,在 Doris 内能够更好的支持,Doris 能够处理更长的 SQL 语句。并且在同一个引擎内,可以通过物化视图和 BITMAP 类型轻松对查询后的中间结果进一步优化,避免了不同引擎之间的跨网络同步。
为了确保业务侧使用体验和成本可控,我们采用了 Doris 的资源隔离机制进行业务间的资源管理。
上述资源隔离机制显著提升了系统的稳定性,告警频率从每天 20 多次降低到每月个位数。这不仅保障了业务的可靠性,还减轻了团队运维管理压力,使他们能够将更多时间投入到系统优化中。
腾讯音乐内容库自研的 SuperSonic 项目内置了 Headless BI 功能,其核心理念是将数据建模、管理和消费进行解耦。通过这种架构,业务分析师只需在 Headless BI 平台上定义指标和标签,而无需关心底层数据源的具体实现。
在业务迁移过程中,业务团队通过 SuperSonic Headless BI 进行。利用转换工具将 DSL 转换为 Elasticsearch SQL 查询,只需切换已定义指标和标签所对应的数据源即可。由于 Headless BI 屏蔽了底层不同数据存储和分析引擎的差异,业务方能够实现无感知的迁移。
Headless BI 架构不仅实现了数据源的无缝迁移,还大大简化了数据管理和查询的复杂性。SuperSonic 将 Chat BI 与 Headless BI 融合,使用户能够实现统一的数据治理,并通过自然语言进行数据分析。经过腾讯音乐内容库的自主研发和实际应用,SuperSonic 平台现已开源,欢迎感兴趣的同仁使用与共同建设。(项目地址)
借助 Doris 替代 Elasticsearch 集群,腾讯音乐内容库统一了搜索和分析引擎。基于倒排索引和全文检索的能力,支持复杂的自定义标签计算,满足秒级响应需求。此外,写入性能提升了 4 倍,存储空间减少了 72%,使用成本节省达 80%。
未来,腾讯音乐内容库将与 Apache Doris 深度合作,探索更多特性在场景应用中的可能性,包括引入 3.0 版本的存算分离,以进一步降低成本。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。