本文导读：
以后，大语言模型的利用正在寰球范畴内引发新一轮的技术反动与商业浪潮。腾讯音乐作为中国当先在线音乐娱乐平台，利用宏大用户群与多元场景的劣势，继续摸索大模型赛道的多元利用。本文将具体介绍腾讯音乐如何基于 Apache Doris 构建查问高效、实时对立剖析的 OLAP 引擎，使 OLAP 作为底层基建增强模型连贯转化效率、后果输入准确率，最终将大模型 + OLAP 引擎联合为用户提供个性化、实时化、灵活化的智能数据服务平台。
作者 | 腾讯音乐大数据架构师 张俊、罗雷
腾讯音乐娱乐团体（以下简称“腾讯音乐”）是中国在线音乐娱乐服务开拓者，有着宽泛的用户根底，总月活用户数超过 8 亿，通过“一站式”的音乐娱乐平台，用户能够在多场景间无缝切换并享受多元的音乐服务。咱们心愿通过技术和数据赋能，为用户带来更好的体验，为音乐人和合作伙伴在音乐制作、发行、销售等方面提供反对。
基于公司丰盛的音乐内容资产，须要将歌曲库、艺人资讯、专辑信息、厂牌信息等大量数据进行对立存储造成音乐内容数据仓库，并通过产品工具为业务人员提供数据分析服务。在内容数仓搭建的过程中，咱们的工作始终围绕 降本增效 为次要目标进行优化与迭代，心愿在 数据服务方面 一直晋升产品工具的开发与剖析效率，同时在 数仓架构方面 可能无效缩小架构老本与资源开销。
在传统数据服务中，咱们为业务分析师提供了多种数据服务，包含 SQL 查问、固定看板、定制化的剖析工具以及人工跑数。然而，在理论利用过程中依然存在肯定痛点：
- SQL 查问平台 ： 业务分析师依据需要进行 SQL 语句编写，对平台数据进行查问剖析，每位业务人员都须要把握 SQL，导致学习老本高、上手难度大。
- 固定看板（Dashboard） ： 技术人员基于惯例业务开发制作数据看板，尽管可能简化业务分析师查问的过程，然而看板制作老本高且灵便度低，当面对简单的用户问题时，看板无奈及时调整以满足需要变更。
- 定制剖析工具： 基于特定的业务需要，技术人员须要定制化开发产品剖析工具，整体开发成本过高，且繁多的开发工具不具备通用性，随着工具数量减少，操作介面变得散乱，从而升高业务效率。
- 人工跑数： 当以上三个场景都无奈满足业务需要时，业务分析师须要向技术人员提需要进行人工跑数，沟通老本过高、整体解决效率低下。
随着行业发展趋势，LLMs 大语言模型（LLMs – Large Language Models，以下对立简称为大模型）呈现无效地解决了这些问题。当平台融入大模型后，平台用户输出的问题会进入大模型进行语义解析，主动转化为 SQL 语句触发 OLAP 引擎开启数据分析与查问。通过 平台智能问答交互 的形式，业务分析师不再须要依附人工编写 SQL 提供查问剖析后果，技术人员也不须要再制作过于固定或者过于定制化的产品工具。大模型 + OLAP 引擎联合的 全新数据服务模式，不仅为平台用户提供了个性化、灵便表白、秒级回复的服务体验，还大幅升高了企业外部技术与业务学习老本，减速数据分析效率，实现多端入口对立、界面对立的平台构建。
本文将具体介绍腾讯音乐如何基于 Apache Doris 构建查问高效、实时写入且对立的 OLAP 剖析引擎，使 OLAP 作为底层基建增强大模型与之连贯转化的效率、后果输入的准确率，最终提供更智能化的问答交互服务，也心愿通过这篇文章为有相干业务需要的公司提供不同视角和思路。
大模型 + OLAP：开启数据服务平台新模式
在大模型 + OLAP 架构计划中，目前经典计划如下图所示，大模型充当中间层将用户输出的自然语言转化为 SQL 执行语句，OLAP 作为底层存储和数据处理的引擎，负责承受和执行从大模型发送过去的 SQL 语句，对数据进行预聚合、多维分析等操作，满足大规模数据集的查问剖析需要。
然而，这种架构在理论落地过程中也面临肯定挑战，例如语义了解的准确性、查问效率的优化、私域常识的了解等方面，具体如下：
- 简单数据口径不对立： 大模型对于技术方面的词汇，如字段、行列、表等无奈了解，相同对于业务方面的词汇，如公司支出状况、日沉闷用户数量等可能提供无效翻译与转换。因而挑战之一是须要思考如何疏导用户进入指标范畴内发问，挑战之二是当用户存在对多种指标、多类指标查问时，须要思考如何放弃指标维度口径的对立、如何无效生成对应的指标计算公式。
- 模型解决效率较低： 现阶段大模型尽管反对交互能力，但推理速度较慢，须要破费十秒级以上响应，用户每减少一个问题输出，就须要破费更多等待时间，使服务质量升高。同时大模型整体依照 Token 免费，使用量减少时也会导致平台老本升高。
- 私域常识无奈辨认： 尽管大模型曾经发展许多公开数据集的语言转换训练，但面对企业外部的大量专业术语仍无奈很好地了解转化。以音乐内容数据库为例，大模型时常短少对于某些冷门歌曲的认知，在问答过程中无奈正确给出交互反馈，因而咱们须要加强大模型对于私域常识的了解。
- 定制场景无奈满足： 大模型次要根据本身数据集进行答复，会呈现“常识幻觉”（输入不足根据的内容）问题，咱们须要容许第三方插件的接入使大模型得以联网，让用户借助外部插件实现更定制化、更多样的工作。因而如何接入、匹配并触发组件性能是咱们的重点优化指标。
面对经典计划中的落地难点，咱们的总体解决思路是将以上四大挑战逐个拆解，通过组件叠加分阶段欠缺大模型 + OLAP 架构构建，最终实现全新的交互问答服务模式，接下来咱们将介绍各阶段挑战对应的解决方案。
01 减少语义层：解决简单数据问题
为了解决简单数据处理问题，咱们在大模型与 OLAP 两头减少 Semantic Layer（以下简称语义层）。
一方面语义层作为连贯技术与业务之间的转换桥梁，可能将数据字段翻译为业务用户的术语，使业务知识作为额定的形象层。通过语义层，业务分析师不须要在定义指标后存储于 OLAP 数仓中，可能间接在语义层中指定过滤条件，将所需指标筛选后生成 SQL 语句并在 OLAP 中进行字段查问。这意味着，业务分析师可能把多源数据依照需要定义成语义信息并造成语义规范，无效解决了多种指标、多类维度计算口径不对立的挑战。
另一方面语义层可能针对业务计算逻辑，进行语义加工、形容、关联和运算。语义层在过滤数据后，可能屏蔽由表关联所产生的简单指标计算公式，将多表 Join 场景进行拆解、转化，造成较为简单的单表查问，以晋升语义转化的准确性。
02 设定人工教训：解决模型效率问题
针对模型效率问题，咱们的解决思路是对指标计算、明细查问、人群圈选等查问场景进行复杂度断定，将简略查问场景间接跳过大模型解析的步骤，进入底层 OLAP 进行解决剖析，使大模型更加专一解决简单查问场景。
为此，如上图所示咱们在模型中增加人工教训判断。当业务分析师输出“查问各大音乐平台支出”问题时，模型根据断定规定发现该场景只须要提供某个指标或几个维度即可实现，这时不须要将问题进入大模型解析，间接应用 OLAP 进行查问剖析，可能无效缩短响应工夫，晋升后果反馈效率。此外，跳过大模型解析的步骤也可能节俭 API 调用经费，解决平台应用老本升高的问题。
03 减少内容映射：解决私域常识问题
针对私域常识的问题，咱们在大模型上游减少 Schema Mapper、在内部建设业务知识库，将平台用户的问题与知识库进行连贯，通过 Schema Mapper 断定是否存在部份文字可能与知识库内容匹配。如果匹配胜利，大模型将进一步解析转化、OLAP 剖析解决。Schema Mapper 与业务知识库的引入，无效解决了大模型对私域常识了解有余的问题，晋升语言解决的成果。
目前，咱们正在一直对 Schema Mapper 匹配准确性进行测试与优化，将知识库中的内容进行分类解决、字段评级等操作，同时将输出文本进行不同范畴的内容映射（如全文本映射与含糊映射），通过映射后果来增强模型语义解析的能力。
04 插件接入：解决定制场景问题
定制化场景次要指代业务范围之外的查问需要，须要将音乐内容数据与法律、政治、金融、监管等方面信息联合提供问答服务。通过减少插件，使平台用户可能拜访实时更新且无奈蕴含在训练数据或业务知识库中的信息，以实现定制化交互。
因为插件类型不同，模型接入形式也会有所不同，常见的接入形式次要分为两种：
- Embedding 本地文本接入： 该形式首先对本地文档进行向量化解决，通过语义向量搜寻，找到本地文档中相干或者类似的词语进行匹配，之后将文档内容注入大模型解析窗口中生成答案。这种形式非常适合业务分析师心愿将音乐内容数据库与最新政策等一类较为公有的文件联合实现查问需要。
- ChatGPT 第三方插件接入： 每款插件具备对应的 Prompt 与调用函数。业务人员在装置某款插件之后，在与模型对话中能够通过 Prompt 词触发函数开启调用。目前第三方插件类型丰盛，波及行业宽泛，可能无效减少多元场景的解决与响应能力。
超音数平台框架构思
根据上述大模型 + OLAP 的四大解决方案进行了计划整合，以此进行框架设计并将其命名为超音数平台。大模型次要作用于自然语言与 SQL 剖析语句的连贯与转化，OLAP 引擎则作为数据存储与查问剖析的外围基建。
超音数平台对于业务流程如图所示，模型运行具体过程如下：
- 用户输出问题通过 Schema Mapper 检索，断定字段是否匹配与业务知识库。
- 如若匹配则跳过大模型解析步骤，间接利用知识库中的指标计算公式触发 OLAP 进行查问剖析；如若不匹配则进入大模型，开启下一步断定。
- 大模型首先通过人工教训断定问题复杂度，简略查问将指定 OLAP 引擎间接剖析，简单查问则开启语义解析造成 DSL 语句。
- DSL 语句通过语义层进一步过滤、拆解关联查问场景，生成繁难单表 SQL 语句以触发 OLAP 数据处理与查问减速。
- 针对须要与内部信息联合的查问场景，大模型会判断是否调用第三方插件来辅助实现查问。
以“某首歌曲是否在综艺节目播出”为例，在通过检索匹配、语义解析后，大模型抉择利用 OLAP 数据查问与第三方版权行业插件联合的形式进行答复，最终出现后果由数仓中的歌曲信息与插件断定后果形成。
现在，业务分析师只须要在超音数平台中定义指标含意、维度类型即可间接发展自然语言的问答交互服务。同时还能够在平台中内置插件、丰盛指标市场来拓展语义解析能力，齐全笼罩了业务在惯例与定制化场景下的查问需要。平台基于大模型 + OLAP 的模式减速业务剖析效率，缩小技术开发老本，向智能化、个性化、实时化的全新业务服务模式更近一步。
在这里心愿能够与大家分享该开源我的项目，让更多人体验和学习大模型构建，也欢送感兴趣的读者们独特参加大模型开发与建设。
超音数开源框架：https://github.com/tencentmusic/supersonic
超音数平台框架演进
在平台构建的过程中，OLAP 引擎作为整体架构的基建对 SQL 语句解决、数据存储剖析、上游应用层的查问响应等有着至关重要的作用，咱们心愿通过架构降级以增强大模型到 OLAP 引擎的转化效率与后果输入准确性。
接下来咱们将比照介绍 OLAP 晚期架构与新一代架构在数据写入与查问两方面的差别，分享在架构演进过程中大模型 + OLAP 模型优化历程，最终助力超音数平台的构建，开启新一代的数据服务模式。
01 数据架构 1.0
咱们初期的业务架构如上图所示，分为解决层、剖析层、应用层三部份，用户文本在进入大模型之后解析为 SQL 语句使 OLAP 开始执行工作，具体的工作原理如下：
- 解决层：在 ODS- DWD- DWS 三层中将数据整合为不同主题的标签和指标体系之后，通过对 DWS 调度与采集所需字段，在 DWM 层将维度与指标数据加工成大宽表。
- 剖析层：通过大宽表进入剖析层，将数据导入 Clickhouse 与 Elasticsearch，其中 Clickhosue 次要负责维度与指标两类数据的查问减速，作为剖析引擎为后续提供报表开发服务；Elasticsearch 次要负责维度数据处理，作为搜寻 / 圈选引擎。
- 应用层：业务人员基于场景选取所须要的标签与指标，在应用层中创立数据集作为逻辑视图，同时能够二次定义衍生的标签与指标。
在理论业务应用中，晚期架构的数据处理形式存在大宽表带来的数据提早与存储节约、多套组件导致架构冗余带来指标维度反复定义、学习与运维老本低等问题，具体如下：
- 数据提早： 解决层不反对局部列表更新，DWS 层数据写入产生提早后会造成大宽表的提早，进而导致数据时效性降落。
- 运维老本高： 在解决层大宽表中维度数据量均匀占一张大宽表的 50%，且在大部份状况下变动迟缓，这意味着每一张宽表的开发会将维度数据叠加，造成存储资源的节约、保护成本增加；在剖析层中存在多引擎应用的问题，查问 SQL 语句须要同时适配 Clickhouse 与 Elasticsearch 两个组件，减少人力老本，且两套组件也会加大运维难度，运维老本进一步升高。
- 架构冗余： 在应用层进行指标与维度定义时，导致雷同数据会进行屡次定义使各种指标、维度定义口径不统一，造成权限不可控，例如上图所示的 T1（标签）与 M1（维度）在应用层中，被不同数据集屡次定义。
02 数据架构 2.0
基于以上问题，咱们开始对架构进行革新降级，并在泛滥 OLAP 引擎中抉择了 Apache Doris 来替换原有组件，次要因为 Apache Doris 具备以下外围劣势：
- 实时导入： Apache Doris 可能反对海量业务数据的高吞吐实时写入，时效性能够做到秒级实现导入。
- 引擎对立： 反对 Multi-Catalog 性能，可能通过 Elasticsearch Catalog 表面查问，实现查问进口对立，查问层架构实现链路极简，保护老本也大幅升高。
- 查问剖析性能： Apache Doris 是 MPP 架构，反对大表分布式 Join，其倒排索引、物化视图、行列混存等性能使查问剖析性能更加高效极速。
在数据架构 2.0 版本中，数据架构保留解决层部份，次要降级剖析层架构，并进行了语义层叠加：
- 剖析层：引入 Apache Doris 替换 Clickhouse 组件，利用 Doris 的 Elasticsearch Catalog 性能对 Elasticsearch 表面进行查问，实现查问进口对立；
- 语义层：应用层不再须要创立数据集视图，间接通过语义层获取指标与标签内容执行查问工作，无效解决标签与指标口径问题。
03 数据架构 3.0
因为宽表开发过程中，维度数据个别变动较小、字符存储空间较大，且剖析查问个别只须要查问最新的维度数据。在这种状况下，如果一直叠加维度数据制作宽表，会造成存储空间节约的问题，同时查问响应速度也受到影响。
为了进一步晋升架构性能，数据架构 3.0 次要将解决层中大宽表进行拆分，同时将剖析层对立应用 Apache Doris 作为查问剖析引擎：
- 解决层：依照业务分类在 DWM 中将大宽表拆分成迟缓维度表与指标表，使两类表在本地 Hive 中进行关联，通过 Hive 导入 Apache Doris 剖析层中减速工作；
- 剖析层：将关联数据表间接导入 Apache Doris 中，联合语义层裸露指标与维度以实现语义对立，用户只须要通过过滤条件就可能间接查问数据，失去所须要的后果。
04 数据架构 4.0
咱们连续了 3.0 架构中剖析层对立的劣势，对解决层、剖析层、语义层架构进一步优化，使查问性能显著晋升：
- 剖析层 + 解决层：数仓 DWD 层数据采纳 Rollup 性能使事实表与维度表实时关联并创立多个视图进入 DWS 中。通过这种形式，剖析层与解决层中的各类指标数据无需再反复定义，可能基于 Apache Doris 全副写入新建的 Rollup 视图中并利用
GROUP BY将维度传入视图进行查问减速，间接对外裸露所需数据。 - 语义层：利用 Apache Doris 物化视图对指标与维度自定义口径，通过语义物化层进行查问减速，并将指标与维度通过
SUM加工开发衍生标签与维度数据。 - 应用层：利用 Apache Doris 2.0 版本的倒排索引性能，对现有的索引构造进行丰盛，满足了对知识库进行含糊查问、等值查问和范畴查问等场景中的能力，进一步减速指标、维度查问响应速度。
数仓架构基于 Apache Doris 迭代降级，最终实现导入实时、引擎对立、查问高效的现代化湖仓 OLAP 引擎，简化架构链路的同时，无效解决大宽表中指标反复定义所带来的问题。在架构演进的过程，咱们也积攒许多对于 Apache Doris 性能优化教训，心愿通过分享给读者们带来一些参考。
Apach Doris 性能优化实际
01 Colocate Join 宽表优化
在上文架构革新中咱们提及，因为宽表开发会一直叠加字符数据，耗费存储空间，升高查问性能，因而咱们充分利用了 Colocate Join 性能对宽表拆分、本地关联查问减速进行优化，具体过程如下：
- 指标大宽表：采纳 Apache Doris 的 Aggregate Key 模型，应用增量的形式将数据笼罩写入；
- 迟缓维度表：次要通过
start_date和end_date的设置进行表建设，同时利用end_date进行分区，当咱们须要查问最新的维度数据时只须要将end_date设置为‘9999-12-31’即可。此外咱们援用 Doris 2.0 版本中的写时合并，利用 Unique Key 模型进行维度数据聚合，使查问性能在该场景中失去很大的晋升。 - 对外拜访视图：在指标与维度表建设实现之后，利用
CREAT VIEW提供对立对外拜访视图，同时增加end_date条件，使视图放弃最新数据的展现。通过这样的形式不仅可能大幅度降低查问的复杂性，还可能充分利用 Doris 个性实现查问减速。
02 Rollup 解决指标收缩问题
宽表拆分为指标表与维度表后，咱们发现每一次视图产生都须要定义多个指标，呈现指标收缩的状况。以“歌曲播放量结算”为例，当仅定义繁多指标时，咱们须要将各个平台 + 各类内容进行排列组合，使语义层定义很多指标数据，造成指标数量过多。此外这些指标都须要通过离线生产工作进行加工，并通过 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 聚合引起的问题。
01 Flink Doris Connector 实现快写入
Flink Doris Connector 次要是依赖 Checkpoint 机制进行流式写入，同时该性能默认开启两阶段提交，保障写入过程中 Exactly Once 语义。值得注意的是，咱们在引入最新版的 Flink Doris Connector 性能后，实现了从关系型数据库到 Apache Doris 的一键整库同步，承载了咱们理论业务中千亿级别的实时并行写入，满足数据快写入与不丢不重的需要。
02 Doris Compaction 保障写入稳定性
为了解决 Flink 聚合引起的偶发性 Compaction 不及时问题，咱们引入最新版的 Vertical Compaction 与 Segment Compaction 性能。
- Vertical Compaction 性能劣势： 在单次合并过程中，咱们不须要再将所有的列读出，只须要加载部份列数据即可，这能极大缩小合并过程中的内存占用问题，进步压缩的执行速度，实现在大宽表场景下的部份数据合并。
- Segment Compaction 性能劣势： 在单批次大数据量的导入场景下能够无效缩小 Flink 写入过程中产生的 Segment 数量，且可能使合并和导入两个过程并行，防止减少导入工夫。
如上图所示在引入 Doris Compation 性能后，在写入量减少 50 % 的状况下，Compaction Score 从均匀 650 分升高至 80 分，技术人员不再须要放心夜间呈现告警的状况，保障了整体链路的稳定性。
总结收益与瞻望
在引入 Apache Doris 后，数据架构围绕降本增效的指标，不仅在写查方面的性能失去大幅度晋升，并且无效缩小架构老本与资源开销，具体的收益如下：
- 极速查问剖析： 通过 Apache Doris 的 Rollup、物化视图、倒排索引性能，由原来的分钟级查问工夫达到现如今秒级毫秒级；
- 导入性能晋升： 导入优化实现后，本来 3000+ 维度、指标数据的导入工夫须要超过一天，现如今可能在 8 小时内实现导入，导入工夫缩短至原来的 1/3，实现疾速导入需要；更重要的是，Apache Doris 在保证数据快写入的同时，使数据可能不丢不重、精确写入；
- 链路极简与对立： Apache Doris 将查问与剖析进口引擎对立，去除 Elasticsearch 集群使架构链路极简；
- 存储老本升高： 通过大宽表拆分的形式，使存储老本升高 30%，开发成本升高 40%。
在将来，咱们将进一步拓展应用 Apache Doris 湖仓一体性能，对 Hive、MySQL、数据湖等多源异构数据库进行网关对立，实现真正意义上的实时对立剖析引擎。同时，尝试 CCR 跨集群数据同步性能，通过用户多集群的数据库表主动同步以晋升在线服务数据的可用性。将来，咱们也将在测试环节中验证读写负载拆散以及多机房备份的性能成果。
目前，Apache Doris 社区曾经颁布了后续版本中将推出的存算拆散全新架构，可能利用低成本的共享存储系统简化下层计算节点的复杂度，使架构带来微小的老本经济劣势。咱们也心愿可能进一步摸索，基于 Apache Doris 本地高速缓存 + 共享存储系统的混合模式，在保障性能的同时升高零碎存储开销。
最初，非常感谢 SelectDB 技术团队的积极响应与业余解答，心愿通过这篇文章分享大语言模型在互联网业务中的利用，也欢送更多人参加 Apache Doris 社区与超音数平台的开源框架构建。最初，咱们也会继续参加社区活动，将相干成绩奉献回馈社区，心愿 Apache Doris 飞速发展，越来越好！