当前，大语言模型的应用正在全球范围内引发新一轮的技术革命与商业浪潮。腾讯音乐作为中国领先在线音乐娱乐平台，利用庞大用户群与多元场景的优势，持续探索大模型赛道的多元应用。本文将详细介绍腾讯音乐如何基于 Apache Doris 构建查询高效、实时统一分析的 OLAP 引擎，使 OLAP 作为底层基建加强模型连接转化效率、结果输出准确率，最终将大模型 + OLAP 引擎结合为用户提供个性化、实时化、灵活化的智能数据服务平台。
腾讯音乐基于公司丰富的音乐内容资产，需要将歌曲库、艺人资讯、专辑信息、厂牌信息等大量数据进行统一存储形成音乐内容数据仓库，并通过产品工具为业务人员提供数据分析服务。在内容数仓搭建的过程中，我们的工作始终围绕降本增效为主要目的进行优化与迭代，希望在数据服务方面不断提升产品工具的开发与分析效率，同时在数仓架构方面能够有效减少架构成本与资源开销。
在传统数据服务中，我们为业务分析师提供了多种数据服务，包括 SQL 查询、固定看板、定制化的分析工具以及人工跑数。然而，在实际应用过程中仍然存在一定痛点：
随着行业发展趋势，LLMs 大语言模型（LLMs - Large Language Models，以下统一简称为大模型）出现有效地解决了这些问题。当平台融入大模型后，平台用户输入的问题会进入大模型进行语义解析，自动转化为 SQL 语句触发 OLAP 引擎开启数据分析与查询。通过平台智能问答交互的方式，业务分析师不再需要依靠人工编写 SQL 提供查询分析结果，技术人员也不需要再制作过于固定或者过于定制化的产品工具。大模型 + OLAP 引擎结合的全新数据服务模式，不仅为平台用户提供了个性化、灵活表达、秒级回复的服务体验，还大幅降低了企业内部技术与业务学习成本，加速数据分析效率，实现多端入口统一、界面统一的平台构建。
本文将详细介绍腾讯音乐如何基于 Apache Doris 构建查询高效、实时写入且统一的 OLAP 分析引擎，使 OLAP 作为底层基建加强大模型与之连接转化的效率、结果输出的准确率，最终提供更智能化的问答交互服务，也希望通过这篇文章为有相关业务需求的公司提供不同视角和思路。
大模型 + OLAP ：开启数据服务平台新模式
在大模型 + OLAP 架构方案中，目前经典方案如下图所示，大模型充当中间层将用户输入的自然语言转化为 SQL 执行语句，OLAP 作为底层存储和数据处理的引擎，负责接受和执行从大模型发送过来的 SQL 语句，对数据进行预聚合、多维分析等操作，满足大规模数据集的查询分析需求。
然而，这种架构在实际落地过程中也面临一定挑战，例如语义理解的准确性、查询效率的优化、私域知识的理解等方面，具体如下：
面对经典方案中的落地难点，我们的总体解决思路是将以上四大挑战逐一拆解，通过组件叠加分阶段完善大模型 + OLAP 架构构建，最终实现全新的交互问答服务模式，接下来我们将介绍各阶段挑战对应的解决方案。
01增加语义层：处理复杂数据问题
为了解决复杂数据处理问题，我们在大模型与 OLAP 中间增加 Semantic Layer（以下简称语义层）。
一方面语义层作为连接技术与业务之间的转换桥梁，能够将数据字段翻译为业务用户的术语，使业务知识作为额外的抽象层。通过语义层，业务分析师不需要在定义指标后存储于 OLAP 数仓中，能够直接在语义层中指定过滤条件，将所需指标筛选后生成 SQL 语句并在 OLAP 中进行字段查询。这意味着，业务分析师能够把多源数据按照需求定义成语义信息并形成语义标准，有效解决了多种指标、多类维度计算口径不统一的挑战。
另一方面语义层能够针对业务计算逻辑，进行语义加工、描述、关联和运算。语义层在过滤数据后，能够屏蔽由表关联所产生的复杂指标计算公式，将多表 Join 场景进行拆解、转化，形成较为简单的单表查询，以提升语义转化的准确性。
02设定人工经验：处理模型效率问题
针对模型效率问题，我们的解决思路是对指标计算、明细查询、人群圈选等查询场景进行复杂度判定，将简单查询场景直接跳过大模型解析的步骤，进入底层 OLAP 进行处理分析，使大模型更加专注处理复杂查询场景。
为此，如上图所示我们在模型中添加人工经验判断。当业务分析师输入 “查询各大音乐平台收入”问题时，模型依据判定规则发现该场景只需要提供某个指标或几个维度即可完成，这时不需要将问题进入大模型解析，直接使用 OLAP 进行查询分析，能够有效缩短响应时间，提升结果反馈效率。此外，跳过大模型解析的步骤也能够节省 API 调用经费，解决平台使用成本升高的问题。
03增加内容映射：处理私域知识问题
针对私域知识的问题，我们在大模型上游增加 Schema Mapper 、在外部建立业务知识库，将平台用户的问题与知识库进行连接，通过 Schema Mapper 判定是否存在部份文字能够与知识库内容匹配。如果匹配成功，大模型将进一步解析转化、OLAP 分析处理。Schema Mapper 与业务知识库的引入，有效解决了大模型对私域知识理解不足的问题，提升语言处理的效果。
目前，我们正在不断对 Schema Mapper 匹配准确性进行测试与优化，将知识库中的内容进行分类处理、字段评级等操作，同时将输入文本进行不同范围的内容映射（如全文本映射与模糊映射），通过映射结果来加强模型语义解析的能力。
04插件接入：处理定制场景问题
定制化场景主要指代业务范围之外的查询需求，需要将音乐内容数据与法律、政治、金融、监管等方面信息结合提供问答服务。通过增加插件，使平台用户能够访问实时更新且无法包含在训练数据或业务知识库中的信息，以实现定制化交互。
由于插件类型不同，模型接入方式也会有所不同，常见的接入方式主要分为两种：
超音数平台框架构思
根据上述大模型 + OLAP 的四大解决方案进行了方案整合，以此进行框架设计并将其命名为超音数平台。大模型主要作用于自然语言与 SQL 分析语句的连接与转化，OLAP 引擎则作为数据存储与查询分析的核心基建。
超音数平台对于业务流程如图所示，模型运转具体过程如下：
以“某首歌曲能否在综艺节目播出”为例，在经过检索匹配、语义解析后，大模型选择利用 OLAP 数据查询与第三方版权行业插件结合的方式进行回答，最终呈现结果由数仓中的歌曲信息与插件判定结果构成。
如今，业务分析师只需要在超音数平台中定义指标含义、维度类型即可直接开展自然语言的问答交互服务。同时还可以在平台中内置插件、丰富指标市场来拓展语义解析能力，完全覆盖了业务在常规与定制化场景下的查询需求。平台基于大模型 + OLAP 的模式加速业务分析效率，减少技术开发成本，向智能化、个性化、实时化的全新业务服务模式更近一步。
在这里希望可以与大家分享该开源项目，让更多人体验和学习大模型构建，也欢迎感兴趣的读者们共同参与大模型开发与建设。
超音数开源框架：
超音数平台框架演进
在平台构建的过程中，OLAP 引擎作为整体架构的基建对 SQL 语句处理、数据存储分析、上游应用层的查询响应等有着至关重要的作用，我们希望通过架构升级以加强大模型到 OLAP 引擎的转化效率与结果输出准确性。
接下来我们将对比介绍 OLAP 早期架构与新一代架构在数据写入与查询两方面的差异，分享在架构演进过程中大模型 + OLAP 模型优化历程，最终助力超音数平台的构建，开启新一代的数据服务模式。
01数据架构 1.0
我们初期的业务架构如上图所示，分为处理层、分析层、应用层三部份，用户文本在进入大模型之后解析为 SQL 语句使 OLAP 开始执行任务，具体的工作原理如下：
在实际业务使用中，早期架构的数据处理方式存在大宽表带来的数据延迟与存储浪费、多套组件导致架构冗余带来指标维度重复定义、学习与运维成本高等问题，具体如下：
02数据架构 2.0
基于以上问题，我们开始对架构进行改造升级，并在众多 OLAP 引擎中选择了 Apache Doris 来替换原有组件，主要因为 Apache Doris 具备以下核心优势：
在数据架构 2.0 版本中，数据架构保留处理层部份，主要升级分析层架构，并进行了语义层叠加：
03数据架构 3.0
由于宽表开发过程中，维度数据一般变化较小、字符存储空间较大，且分析查询一般只需要查询最新的维度数据。在这种情况下，如果不断叠加维度数据制作宽表，会造成存储空间浪费的问题，同时查询响应速度也受到影响。
为了进一步提升架构性能，数据架构 3.0 主要将处理层中大宽表进行拆分，同时将分析层统一使用 Apache Doris 作为查询分析引擎：
04数据架构 4.0
我们延续了 3.0 架构中分析层统一的优势，对处理层、分析层、语义层架构进一步优化，使查询性能显著提升：
数仓架构基于 Apache Doris 迭代升级，最终实现导入实时、引擎统一、查询高效的现代化湖仓 OLAP 引擎，简化架构链路的同时，有效解决大宽表中指标重复定义所带来的问题。在架构演进的过程，我们也积累许多关于 Apache Doris 性能优化经验，希望通过分享给读者们带来一些参考。
Apach Doris 性能优化实践01Colocate Join 宽表优化
在上文架构改造中我们提及，由于宽表开发会不断叠加字符数据，消耗存储空间，降低查询性能，因此我们充分利用了 Colocate Join 功能对宽表拆分、本地关联查询加速进行优化，具体过程如下：
02Rollup 解决指标膨胀问题
宽表拆分为指标表与维度表后，我们发现每一次视图产生都需要定义多个指标，出现指标膨胀的情况。以“歌曲播放量结算”为例，当仅定义单一指标时，我们需要将各个平台 + 各类内容进行排列组合，使语义层定义很多指标数据，造成指标数量过多。此外这些指标都需要通过离线生产任务进行加工，并通过 Hive 导入至 Apache Doris 中，造成链路较长、加工维护比较困难。
平台指标：覆盖四大音乐平台，包括酷我、QQ 音乐、酷狗、K 歌
内容指标：包含歌曲、歌手、专辑以及厂牌等数据
为了有效解决指标膨胀问题，我们引入了 Doris Rollup 功能。如图所示，在 Doris Base 表数据基础之上，可以根据指定维度来创建任意多个 Rollup 视图并自动进行GROUP BY ，实现各个平台与各类内容指标定义不重复、查询性能提升的目标。
03物化视图实现查询加速
除了减少指标数量外，我们还希望能够衍生指标并且做到查询加速。在 Apache Doris 2.0 版本中我们采用了物化视图功能进行衍生指标的开发。目前，我们主要在单一维度表中单独地去查询自定义标签与维度，在定义复杂口径后自动的通过语义层物化任务。
如上图所示我们将指标 M1 、M2、M3 与维度 T1、T2、T3 分别进行定义，并通过 SUM 加工衍生标签，在加工完成之后创建物化视图加速查询。此外，在 Doris 后续 2.1 版本中还会支持多表创建物化视图，我们也非常期待使用该功能。
Apach Doris 导入性能调优实践
目前，腾讯音乐具有 90+ 数据来源表、 3000 + 维度和指标、导入数据量达到千亿级别，我们希望数仓能够支持大规模数据快速导入，且导入过程中保证数据写入的准确性。
导入链路如图所示，主要分为离线与实时两个部分，离线链路中指标表与变更维度表通过 Spark 进行批量导入，两类表利用 Flink 聚合形成宽表后写入；实时链路主要利用 Kafak 消息队列进行流式写入。最终，离线与实时两条链路利用 Flink 实时写入 Apache Doris 数仓中。
由于 Flink 聚合为攒批写入，如果出现写入任务失败，会导致数据丢失；同时，在聚合任务过多、字段过多的情况下存在 Compaction 不及时的情况，导致实时能力不可控；此外在加工宽表的过程中，也会造成重复写入的问题，无法保证数据写入准确性。
在 Apache Doris 2.0 版本发布后，我们引入了其全新功能 Flink Doris Connector 与 Doris Compaction，有效解决了 Flink 聚合引起的问题。
01Flink Doris Connector 实现快写入
Flink Doris Connector 主要是依赖 Checkpoint 机制进行流式写入，同时该功能默认开启两阶段提交，保证写入过程中 Exactly Once 语义。值得注意的是，我们在引入最新版的 Flink Doris Connector 功能后，实现了从关系型数据库到 Apache Doris 的一键整库同步，承载了我们实际业务中千亿级别的实时并行写入，满足数据快写入与不丢不重的需求。
02Doris Compaction 保证写入稳定性
为了解决 Flink 聚合引起的偶发性 Compaction 不及时问题，我们引入最新版的 Vertical Compaction 与 Segment Compaction 功能。
如上图所示在引入 Doris Compation 功能后，在写入量增加 50 % 的情况下，Compaction Score 从平均 650 分降低至 80 分，技术人员不再需要担心夜间出现告警的情况，保证了整体链路的稳定性。
总结收益与展望
在引入 Apache Doris 后，数据架构围绕降本增效的目标，不仅在写查方面的性能得到大幅度提升，并且有效减少架构成本与资源开销，具体的收益如下：
在未来，我们将进一步拓展使用 Apache Doris 湖仓一体功能，对 Hive、MySQL、数据湖等多源异构数据库进行网关统一，实现真正意义上的实时统一分析引擎。同时，尝试 CCR 跨集群数据同步功能，通过用户多集群的数据库表自动同步以提升在线服务数据的可用性。未来，我们也将在测试环节中验证读写负载分离以及多机房备份的性能效果。
目前，Apache Doris 社区已经公布了后续版本中将推出的存算分离全新架构，能够利用低成本的共享存储系统简化上层计算节点的复杂度，使架构带来巨大的成本经济优势。我们也希望能够进一步探索，基于 Apache Doris 本地高速缓存 + 共享存储系统的混合模式，在保障性能的同时降低系统存储开销。
最后，非常感谢 SelectDB 技术团队的积极响应与专业解答，希望通过这篇文章分享大语言模型在互联网业务中的应用，也欢迎更多人参与 Apache Doris 社区与超音数平台的开源框架构建。最后，我们也会持续参与社区活动，将相关成果贡献回馈社区，希望 Apache Doris 飞速发展，越来越好！
作者介绍：腾讯音乐 大数据架构师 张俊、罗雷
