网站建设技术风险,郑州哪里有做网站,和京东一样做电子产品的网站,一个专门做预告片的网站导读#xff1a; 为满足更严苛数据分析的需求#xff0c;腾讯音乐借助 Apache Doris 替代了 Elasticsearch 集群#xff0c;统一了内容库数据平台的内容搜索和分析引擎。并基于 Doris 倒排索引和全文检索的能力#xff0c;支持了复杂的自定义标签计算#xff0c;实现秒级查…导读 为满足更严苛数据分析的需求腾讯音乐借助 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 不仅支持普通的等值和范围 查询加速还支持文本字段的全文检索包括中英文分词、多关键词检索MATCH_ANY MATCH_ALL、短语检索MATCH_PHRASE MATCH_PHRASE_PREFIX MATCH_PHRASE_REGEXP、短语词距slop、多字段检索MULTI_MATCH其性能相较于传统数据库支持的 LIKE 模糊匹配有数量级的提升。在倒排索引方面 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:59AND (title MATCH 爱 OR description MATCH_PHRASE 热爱)AND rating 4AND 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 倒排索引的使用文档根据 Elasticsearch Mapping 设计了对应的 Doris 的表结构和索引。其中Elasticsearch 的 Keyword 类型对应 Doris 的 Varchar/String 类型及不分词的倒排索引USING INVERTEDES 的 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
) ENGINEOLAP
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
dayno2024-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_3WHERE dayno2024-08-01) tab1 lateral view explode_split(a4, #) tmp1 as a4_singlelateral view explode_split(a43, #) tmp2 as a43_single) tab2 where a4_single若月亮还没来 or a43_single1000使用后使用 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 类型轻松对查询后的中间结果进一步优化避免了不同引擎之间的跨网络同步。
02 业务间资源隔离
为了确保业务侧使用体验和成本可控我们采用了 Doris 的资源隔离机制进行业务间的资源管理。
第一层物理隔离Resource Group 将集群划分为两个资源组Core 和 Common以服务不同重要场景的需求。Core 组专注于内容搜索和标签圈选的核心需求而 Common 组则处理其他普通需求。通过在节点层面实施物理隔离可确保核心业务不受其他业务的影响。第二层逻辑隔离Workload Group 在每个物理隔离内部通过 Workload Group 对每个 Resource Group 进行逻辑资源的细分。例如在普通集群中建立多个 Workload Group并为用户指定默认的 Workload group以防止单个用户占满整个集群的资源。 上述资源隔离机制显著提升了系统的稳定性告警频率从每天 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 版本的存算分离以进一步降低成本。
相关文章#腾讯音乐案例 、#Elasticsearch 到 Apache Doris 案例、#日志场景案例
