腾讯音乐如何基于大模型 + OLAP 构建智能数据服务平台( 三 ) _大数据

在这里希望可以与大家分享该开源项目，让更多人体验和学习大模型构建，也欢迎感兴趣的读者们共同参与大模型开发与建设。
超音数开源框架：
超音数平台框架演进
在平台构建的过程中，OLAP 引擎作为整体架构的基建对 SQL 语句处理、数据存储分析、上游应用层的查询响应等有着至关重要的作用，我们希望通过架构升级以加强大模型到 OLAP 引擎的转化效率与结果输出准确性。
接下来我们将对比介绍 OLAP 早期架构与新一代架构在数据写入与查询两方面的差异，分享在架构演进过程中大模型 + OLAP 模型优化历程，最终助力超音数平台的构建，开启新一代的数据服务模式。
01 数据架构 1.0
我们初期的业务架构如上图所示，分为处理层、分析层、应用层三部份，用户文本在进入大模型之后解析为 SQL 语句使 OLAP 开始执行任务，具体的工作原理如下：
在实际业务使用中，早期架构的数据处理方式存在大宽表带来的数据延迟与存储浪费、多套组件导致架构冗余带来指标维度重复定义、学习与运维成本高等问题，具体如下：
02 数据架构 2.0
基于以上问题，我们开始对架构进行改造升级，并在众多 OLAP 引擎中选择了Doris 来替换原有组件，主要因为Doris 具备以下核心优势：
在数据架构 2.0 版本中，数据架构保留处理层部份，主要升级分析层架构，并进行了语义层叠加：
03 数据架构 3.0
由于宽表开发过程中，维度数据一般变化较小、字符存储空间较大，且分析查询一般只需要查询最新的维度数据。在这种情况下，如果不断叠加维度数据制作宽表，会造成存储空间浪费的问题，同时查询响应速度也受到影响。
为了进一步提升架构性能，数据架构 3.0 主要将处理层中大宽表进行拆分，同时将分析层统一使用Doris 作为查询分析引擎：
04 数据架构 4.0
我们延续了 3.0 架构中分析层统一的优势，对处理层、分析层、语义层架构进一步优化，使查询性能显著提升：
数仓架构基于Doris 迭代升级，最终实现导入实时、引擎统一、查询高效的现代化湖仓 OLAP 引擎，简化架构链路的同时，有效解决大宽表中指标重复定义所带来的问题。在架构演进的过程，我们也积累许多关于Doris 性能优化经验，希望通过分享给读者们带来一些参考。
Apach Doris 性能优化实践01Join 宽表优化
在上文架构改造中我们提及，由于宽表开发会不断叠加字符数据，消耗存储空间，降低查询性能，因此我们充分利用了Join 功能对宽表拆分、本地关联查询加速进行优化，具体过程如下：
02解决指标膨胀问题
宽表拆分为指标表与维度表后，我们发现每一次视图产生都需要定义多个指标，出现指标膨胀的情况。以“歌曲播放量结算”为例，当仅定义单一指标时，我们需要将各个平台 + 各类内容进行排列组合，使语义层定义很多指标数据，造成指标数量过多。此外这些指标都需要通过离线生产任务进行加工，并通过 Hive 导入至Doris 中，造成链路较长、加工维护比较困难。
平台指标：覆盖四大音乐平台，包括酷我、音乐、酷狗、K 歌内容指标：包含歌曲、歌手、专辑以及厂牌等数据
为了有效解决指标膨胀问题，我们引入了 Doris功能。如图所示，在 Doris Base 表数据基础之上，可以根据指定维度来创建任意多个视图并自动进行GROUP BY，实现各个平台与各类内容指标定义不重复、查询性能提升的目标。
03 物化视图实现查询加速
【腾讯音乐如何基于大模型 + OLAP 构建智能数据服务平台】除了减少指标数量外，我们还希望能够衍生指标并且做到查询加速。在Doris 2.0 版本中我们采用了物化视图功能进行衍生指标的开发。目前，我们主要在单一维度表中单独地去查询自定义标签与维度，在定义复杂口径后自动的通过语义层物化任务。