更多精彩内容，欢迎观看：
带你读《Apache Doris 案例集》——05 当 Apache Doris 遇上大模型：探秘腾讯音乐如何 基于大模型+ OLAP 构建智能数据服务平台（1)：https://developer.aliyun.com/article/1405740
超音数平台框架构思
根据上述大模型+OLAP 的四大解决方案进行了方案整合，以此进行框架设计并将其命名为超音数平台。大模型主要作用于自然语言与SQL 分析语句的连接与转化，OLAP引擎则作为数据存储与查询分析的核心基建。
超音数平台对于业务流程如图所示，模型运转具体过程如下：
●用户输入问题通过 Schema Mapper检索，判定字段是否匹配与业务知识库。
●如若匹配则跳过大模型解析步骤，直接利用知识库中的指标计算公式触发OLAP 进行查询分析；如若不匹配则进入大模型，开启下一步判定。
●大模型首先通过人工经验判定问题复杂度，简单查询将指定OLAP引擎直接分析，复杂查询则开启语义解析形成 DSL 语句。
● DSL 语句通过语义层进一步过滤、拆解关联查询场景，生成简易单表 SQL 语句以触发OLAP 数据处理与查询加速。
●针对需要与外部信息结合的查询场景，大模型会判断是否调用第三方插件来辅助完成查询。
以“某首歌曲能否在综艺节目播出”为例，在经过检索匹配、语义解析后，大模型选择利用OLAP 数据查询与第三方版权行业插件结合的方式进行回答，最终呈现结果由数仓中的歌曲信息与插件判定结果构成。
如今，业务分析师只需要在超音数平台中定义指标含义、维度类型即可直接开展自然语言的问答交互服务。同时还可以在平台中内置插件、丰富指标市场来拓展语义解析能力，完全覆盖了业务在常规与定制化场景下的查询需求。平台基于大模型+OLAP 的模式加速业务分析效率，减少技术开发成本，向智能化、个性化、实时化的全新业务服务模式更近一步。
在这里希望可以与大家分享该开源项目，让更多人体验和学习大模型构建，也欢迎感兴趣的读者们共同参与大模型开发与建设。
超音数开源框架： https://github.com/tencentmusic/supersonic
超音数平台框架演进
在平台构建的过程中，OLAP 引擎作为整体架构的基建对 SQL 语句处理、数据存储分析、上游应用层的查询响应等有着至关重要的作用，我们希望通过架构升级以加强大模型到OLAP 引擎的转化效率与结果输出准确性。
接下来我们将对比介绍OLAP 早期架构与新一代架构在数据写入与查询两方面的差异，分享在架构演进过程中大模型+OLAP 模型优化历程，最终助力超音数平台的构建，开启新一代的数据服务模式。
数据架构1.0
我们初期的业务架构如上图所示，分为处理层、分析层、应用层三部份，用户文本在进入大模型
之后解析为 SQL 语句使OLAP 开始执行任务，具体的工作原理如下：
●处理层：在ODS-DWD-DWS 三层中将数据整合为不同主题的标签和指标体系之后，通过对 DWS 调度与采集所需字段，在DWM 层将维度与指标数据加工成大宽表。
●分析层：通过大宽表进入分析层，将数据导入Clickhouse 与Elasticsearch,其中Clickhosue 主要负责维度与指标两类数据的查询加速，作为分析引擎为后续提供报表开发服务； Elasticsearch 主要负责维度数据处理，作为搜索/圈选引擎。
●应用层：业务人员基于场景选取所需要的标签与指标，在应用层中创建数据集作为逻辑视图，同时可以二次定义衍生的标签与指标。
在实际业务使用中，早期架构的数据处理方式存在大宽表带来的数据延迟与存储浪费、多套组件导致架构冗余带来指标维度重复定义、学习与运维成本高等问题，具体如下：
● 数据延迟：处理层不支持部分列表更新，DWS 层数据写入产生延迟后会造成大宽表的延迟，进而导致数据时效性下降。
● 运维成本高： 在处理层大宽表中维度数据量平均占一张大宽表的50%,且在大部份情况下变化缓慢，这意味着每一张宽表的开发会将维度数据叠加，造成存储资源浪费、维护成本增加在分析层中存在多引擎使用问题，查询SQL 语句需要同时适配 Clickhouse 与 Elasticsearch两个组件，增加人力成本，且两套组件也会加大运维难度，运维成本进一步升高。
●架构冗余：在应用层进行指标与维度定义时，导致相同数据会进行多次定义使各种指标、维度定义口径不一致，造成权限不可控，例如上图所示的T1 (标签)与 M1 (维度)在应用层中，被不同数据集多次定义。
数据架构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 外表进行查询，实现查询出口统一；
●语义层：应用层不再需要创建数据集视图，直接通过语义层获取指标与标签内容执行查询任务，有效解决标签与指标口径问题。
数据架构3.0
由于宽表开发过程中，维度数据一般变化较小、字符存储空间较大，且分析查询一般只需要查询最新的维度数据。在这种情况下，如果不断叠加维度数据制作宽表，会造成存储空间浪费的问题，同时查询响应速度也受到影响。
为了进一步提升架构性能，数据架构3.0主要将处理层中大宽表进行拆分，同时将分析层统一使
用 Apache Doris 作为查询分析引擎：
● 处理层：按照业务分类在 DWM 中将大宽表拆分成缓慢维度表与指标表，使两类表在本地
Hive 中进行关联，通过Hive 导入Apache Doris 分析层中加速任务；
●分析层：将关联数据表直接导入 Apache Doris 中，结合语义层暴露指标与维度以实现语义
统一，用户只需要通过过滤条件就能够直接查询数据，得到所需要的结果。
数据架构4.0
我们延续了3.0架构中分析层统一的优势，对处理层、分析层、语义层架构进一步优化，使查询
性能显著提升：
●分析层+处理层：数仓 DWD 层数据采用 Rollup 功能使事实表与维度表实时关联并创建多个视图进入 DWS 中。通过这种方式，分析层与处理层中的各类指标数据无需再重复定义，能够基于Apache Doris 全部写入新建的 Rollup 视图中并利用 GROUP BY 将维度传入视图进行查询加速，直接对外暴露所需数据。
●语义层：利用 Apache Doris 物化视图对指标与维度自定义口径，通过语义物化层进行查询加速，并将指标与维度通过SUM 加工开发衍生标签与维度数据。
●应用层：利用Apache Doris 2.0 版本的倒排索引功能，对现有的索引结构进行丰富，满足了对知识库进行模糊查询、等值查询和范围查询等场景中的能力，进一步加速指标、维度查询响应速度。
数仓架构基于Apache Doris迭代升级，最终实现导入实时、引擎统一、查询高效的现代化湖仓 OLAP 引擎，简化架构链路的同时，有效解决大宽表中指标重复定义所带来的问题。在架构演进的过程，我们也积累许多关于Apache Doris 性能优化经验，希望分享给读者们带来一些参考。
更多精彩内容，欢迎观看：
带你读《Apache Doris 案例集》——05 当 Apache Doris 遇上大模型：探秘腾讯音乐如何 基于大模型+ OLAP 构建智能数据服务平台（3)：https://developer.aliyun.com/article/1405738
