带你读《Apache Doris 案例集》——05 当 Apache Doris 遇上大模型:探秘腾讯音乐如何 基于大模型+ OLAP 构建智能数据服务平台(1)

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 带你读《Apache Doris 案例集》——05 当 Apache Doris 遇上大模型:探秘腾讯音乐如何 基于大模型+ OLAP 构建智能数据服务平台(1)

作者:腾讯音乐大数据架构师,张俊、罗雷

 

导读: 当前,大语言模型的应用正在全球范围内引发新一轮的技术革命与商业浪潮。腾讯音乐作为中国领先在线音乐娱乐平台,利用庞大用户群与多元场景的优势,持续探索大模型赛道的多元应用。本文将详细介绍腾讯音乐如何基于Apache  Doris构建查询高效、实时统一分析的 OLAP引擎,使OLAP作为底层基建加强模型连接转化效率、结果输出准确率,最终将大模型+OLAP  引擎结合为用户提供个性化、实时化、灵活化的智能数据服务平台。

 

腾讯音乐娱乐集团(以下简称腾讯音乐”)是中国在线音乐娱乐服务开拓者,有着广泛的用户基础,总月活用户数超过8亿,通过一站式的音乐娱乐平台,用户可以在多场景间无缝切换并享受多元的音乐服务。我们希望通过技术和数据赋能,为用户带来更好的体验,为音乐人和合作伙伴在音乐制作、发行、销售等方面提供支持。

 

基于公司丰富的音乐内容资产,需要将歌曲库、艺人资讯、专辑信息、厂牌信息等大量数据进行统一存储形成音乐内容数据仓库,并通过产品工具为业务人员提供数据分析服务。在内容数仓搭建的过程中,我们的工作始终围绕降本增效为主要目的进行优化与迭代,希望在数据服务方面不断提升产品工具的开发与分析效率,同时在数仓架构方面能够有效减少架构成本与资源开销。

 

 在传统数据服务中,我们为业务分析师提供了多种数据服务,包括 SQL 查询、固定看板、定制

化的分析工具以及人工跑数。然而,在实际应用过程中仍然存在一定痛点:

 

SQL查询平台: 业务分析师根据需求进SQL语句编写,对平台数据进行查询分析,每位业务人员都需要掌握SQL,导致学习成本高、上手难度大。

 

固定看板(Dashboard)  : 技术人员基于常规业务开发制作数据看板,虽然能够简化业务分析师查询的过程,但是看板制作成本高且灵活度低,当面对复杂的用户问题时,看板无法及时调整以满足需求变更。 

 

定制分析工具:基于特定的业务需求,技术人员需要定制化开发产品分析工具,整体开发成本过高,且单一的开发工具不具备通用性,随着工具数量增加,操作介面变得散乱,从而降低业务效率。

 

人工跑数:当以上三个场景都无法满足业务需求时,业务分析师需要向技术人员提需求进行人工跑数,沟通成本过高、整体解决效率低下。

 

image.png

随着行业发展趋势,LLMs大语言模型(LLMs-Large  Language  Models, 以下统一简称为大 模型)出现有效地解决了这些问题。当平台融入大模型后,平台用户输入的问题会进入大模型进行语义解析,自动转化为 SQL语句触发 OLAP  引擎开启数据分析与查询。通过平台智能问答交互的方式,业务分析师不再需要依靠人工编写 SQL 提供查询分析结果,技术人员也不需要再制作过于固定或者过于定制化的产品工具。大模型+OLAP  引擎结合的全新数据服务模式,不仅为平台用户提供了个性化、灵活表达、秒级回复的服务体验,还大幅降低了企业内部技术与业务学习成本,加速数据分析效率,实现多端入口统一、界面统一的平台构建。

 

本文将详细介绍腾讯音乐如何基于 Apache Doris 构建查询高效、实时写入且统一的 OLAP  分析引擎,使OLAP 作为底层基建加强大模型与之连接转化的效率、结果输出的准确率,最终提供更智能化的问答交互服务,也希望通过这篇文章为有相关业务需求的公司提供不同视角和思路。

 

大模型+OLAP: 开启数据服务平台新模式

 

在大模型+OLAP  架构方案中,目前经典方案如下图所示,大模型充当中间层将用户输入的自然语言转化为SQL执行语句,OLAP  作为底层存储和数据处理的引擎,负责接受和执行从大模型发送过来的SQL语句,对数据进行预聚合、多维分析等操作,满足大规模数据集的查询分析需求。 

image.png

 

然而,这种架构在实际落地过程中也面临一定挑战,例如语义理解的准确性、查询效率的优化、私域知识的理解等方面,具体如下:

 

复杂数据口径不统一:大模型对于技术方面的词汇,如字段、行列、表等无法理解,相反对 于业务方面的词汇,如公司收入情况、日活跃用户数量等能够提供有效翻译与转换。因此挑战之一是需要思考如何引导用户进入指标范围内提问,挑战之二是当用户存在对多种指标、多类指标查询时,需要考虑如何保持指标维度口径的统一、如何有效生成对应的指标计算公式。

 

模型处理效率较低:现阶段大模型虽然支持交互能力,但推理速度较慢,需要花费十秒级以上响应,用户每增加一个问题输入,就需要花费更多等待时间,使服务质量降低。同时大模型整体按照Token 收费,使用量增加时也会导致平台成本升高。

 

私域知识无法识别:虽然大模型已经开展许多公开数据集的语言转换训练,但面对企业内部 的大量专业术语仍无法很好地理解转化。以音乐内容数据库为例,大模型时常缺少对于某些冷门歌曲的认知,在问答过程中无法正确给出交互反馈,因此我们需要增强大模型对于私域知识的理解。

 

定制场景无法满足:大模型主要依据自身数据集进行回答,会出现知识幻”(输出缺乏依据的内容)问题,我们需要允许第三方插件的接入使大模型得以联网,让用户借助内部插件完成更定制化、更多样的任务。因此如何接入、匹配并触发组件功能是我们的重点优化目 标。 

 

面对经典方案中的落地难点,我们的总体解决思路是将以上四大挑战逐一拆解,通过组件叠加分阶段完善大模型+ OLAP 架构构建,最终实现全新的交互问答服务模式,接下来我们将介绍各阶段挑战对应的解决方案。 

 

增加语义层:处理复杂数据问题

 案:处理复杂数据

 image.png

为了解决复杂数据处理问题,我们在大模型与 OLAP  中间增加Semantic Layer (以下简称语义

) 

 

一方面语义层作为连接技术与业务之间的转换桥梁,能够将数据字段翻译为业务用户的术语,使业务知识作为额外的抽象层。通过语义层,业务分析师不需要在定义指标后存储于OLAP 数仓中,能够直接在语义层中指定过滤条件,将所需指标筛选后生成SQL语句并在OLAP  中进行字段查询。这意味着,业务分析师能够把多源数据按照需求定义成语义信息并形成语义标准,有效解决了多种指标、多类维度计算口径不统一的挑战。

 

另一方面语义层能够针对业务计算逻辑,进行语义加工、描述、关联和运算。语义层在过滤数据后,能够屏蔽由表关联所产生的复杂指标计算公式,将多表 Join 场景进行拆解、转化,形成较为简单的单表查询,以提升语义转化的准确性。 

 

设定人工经验:处理模型效率问题 image.png 针对模型效率问题,我们的解决思路是对指标计算、明细查询、人群圈选等查询场景进行复杂度判定,将简单查询场景直接跳过大模型解析的步骤,进入底层 OLAP 进行处理分析,使大模型更加专注处理复杂查询场景。

 

为此,如上图所示我们在模型中添加人工经验判断。当业务分析师输入查询各大音乐平台收问题时,模型依据判定规则发现该场景只需要提供某个指标或几个维度即可完成,这时不需要将问题进入大模型解析,直接使用OLAP 进行查询分析,能够有效缩短响应时间,提升结果反馈效率。此外,跳过大模型解析的步骤也能节省API调用经费,解决平台使用成本升高问题。

 

增加内容映射:处理私域知识问题


image.png

针对私域知识的问题,我们在大模型上游增加Schema    Mapper在外部建立业务知识库,将平台用户的问题与知识库进行连接,通过Schema  Mapper判定是否存在部份文字能够与知识库内 容匹配。如果匹配成功,大模型将进一步解析转化OLAP分析处理。Schema  Mapper与业务知识库的引入,有效解决了大模型对私域知识理解不足的问题,提升语言处理的效果。

 

目前,我们正在不断对Schema  Mapper匹配准确性进行测试与优化,将知识库中的内容进行分类处理、字段评级等操作,同时将输入文本进行不同范围的内容映射(如全文本映射与模糊映),通过映射结果来加强模型语义解析的能力。


插件接入:处理定制场景问题

image.png 

定制化场景主要指代业务范围之外的查询需求,需要将音乐内容数据与法律、政治、金融、监管等方面信息结合提供问答服务。通过增加插件,使平台用户能够访问实时更新且无法包含在训练数据或业务知识库中的信息,以实现定制化交互。

 

由于插件类型不同,模型接入方式也会有所不同,常见的接入方式主要分为两种:

 

·Embedding  本地文本接入:该方式首先对本地文档进行向量化处理,通过语义向量搜索,找到本地文档中相关或者相似的词语进行匹配,之后将文档内容注入大模型解析窗口中生成答案。这种方式非常适合业务分析师希望将音乐内容数据库与最新政策等一类较为私有的文件结合完成查询需求。

 

·ChatGPT  第三方插件接入: 每款插件具备对应的Prompt 与调用函数。业务人员在安装某款插件之后,在与模型对话中可以通过Prompt 词触发函数开启调用。目前第三方插件类型丰富,涉及行业广泛,能够有效增加多元场景的处理与响应能力。

 


更多精彩内容,欢迎观看:

带你读《Apache Doris 案例集》——05 当 Apache   Doris 遇上大模型:探秘腾讯音乐如何 基于大模型+ OLAP  构建智能数据服务平台(2):https://developer.aliyun.com/article/1405739

相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
25天前
|
缓存 安全 Java
阿里云数据库 SelectDB 内核 Apache Doris 2.0.6 版本正式发布
阿里云数据库 SelectDB 内核 Apache Doris 2.0.6 版本正式发布
|
1月前
|
SQL 存储 JSON
阿里云数据库 SelectDB 内核 Apache Doris 2.1.0 版本发布:开箱盲测性能大幅优化,复杂查询性能提升 100%
亲爱的社区小伙伴们,Apache Doris 2.1.0 版本已于 2024 年 3 月 8 日正式发布,新版本开箱盲测性能大幅优化,在复杂查询性能方面提升100%,新增Arrow Flight接口加速数据读取千倍,支持半结构化数据类型与分析函数。异步多表物化视图优化查询并助力仓库分层建模。引入自增列、自动分区等存储优化,提升实时写入效率。Workload Group 资源隔离强化及运行时监控功能升级,保障多负载场景下的稳定性。新版本已经上线,欢迎大家下载使用!
阿里云数据库 SelectDB 内核 Apache Doris 2.1.0 版本发布:开箱盲测性能大幅优化,复杂查询性能提升 100%
|
1月前
|
存储 缓存 分布式计算
Apache Hudi数据跳过技术加速查询高达50倍
Apache Hudi数据跳过技术加速查询高达50倍
38 2
|
22天前
|
关系型数据库 MySQL OLAP
PolarDB +AnalyticDB Zero-ETL :免费同步数据到ADB,享受数据流通新体验
Zero-ETL是阿里云瑶池数据库提供的服务,旨在简化传统ETL流程的复杂性和成本,提高数据实时性。降低数据同步成本,允许用户快速在AnalyticDB中对PolarDB数据进行分析,降低了30%的数据接入成本,提升了60%的建仓效率。 Zero-ETL特性包括免费的PolarDB MySQL联邦分析和PolarDB-X元数据自动同步,提供一体化的事务处理和数据分析,并能整合多个数据源。用户只需简单配置即可实现数据同步和实时分析。
|
25天前
|
存储 SQL 数据管理
阿里云数据库 SelectDB 内核 Apache Doris 如何基于自增列满足高效字典编码等典型场景需求|Deep Dive 系列
自增列的实现,使得 Apache Doris 可以在处理大规模时展示出更高的稳定性和可靠性。通过自增列,用户能够高效进行字典编码,显著提升了字符串精确去重以及查询的性能。使用自增列作为主键来存储明细数据,可以完美的解决明细数据更新的问题。同时,基于自增列,用户可以实现高效的分页机制,轻松应对深分页场景,有效过滤掉大量非必需数据,从而减轻数据库的负载压力,为用户带来了更加流畅和高效的数据处理体验。
|
25天前
|
SQL 数据可视化 Apache
阿里云数据库内核 Apache Doris 兼容 Presto、Trino、ClickHouse、Hive 等近十种 SQL 方言,助力业务平滑迁移
阿里云数据库 SelectDB 内核 Doris 的 SQL 方言转换工具, Doris SQL Convertor 致力于提供高效、稳定的 SQL 迁移解决方案,满足用户多样化的业务需求。兼容 Presto、Trino、ClickHouse、Hive 等近十种 SQL 方言,助力业务平滑迁移。
阿里云数据库内核 Apache Doris 兼容 Presto、Trino、ClickHouse、Hive 等近十种 SQL 方言,助力业务平滑迁移
|
1月前
|
SQL 数据采集 存储
数据仓库(12)数据治理之数仓数据管理实践心得
这边文章聊聊自己对数据治理开发实践的一些思路,就是聊聊怎么开始去做数据治理这件事情。说起数据治理,有时候虽然看了很多文章,看了很多的介绍,了解数据治理的理论,但是实际上需要我们去搞的时候,就会踩很多的坑。这里记一下自己做数据治理的一些思路,做做笔记,也分享给需要的同学。 当然,想要做数据治理,想要学习了解,一下数据治理的范围,理论等,最好可以看看别人怎么做的,了解数据治理可以参考:[数据仓库(11)什么是大数据治理,数据治理的范围是哪些](https://zhuanlan.zhihu.com/p/467433967)。
136 0
|
1月前
|
Apache 开发者
揭秘!Apache Hudi社区发展数据盘点
揭秘!Apache Hudi社区发展数据盘点
29 0
|
1月前
|
分布式计算 Java 数据管理
使用Apache Hudi + Amazon EMR进行变化数据捕获(CDC)
使用Apache Hudi + Amazon EMR进行变化数据捕获(CDC)
87 0
|
1月前
|
分布式计算 大数据 测试技术
查询时间降低60%!Apache Hudi数据布局黑科技了解下
查询时间降低60%!Apache Hudi数据布局黑科技了解下
22 0

推荐镜像

更多