阿里云 X Apache Doris X Zilliz沙龙回顾｜大模型时代的数据存储与分析-阿里云开发者社区

前言

大模型的 AIGC 场景在近年来引起了大众的广泛关注。人们不再满足于简单的对话，而是开始探索更深入的行业应用场景，如通过自然语言实现SQL的数据分析，从而降低数据分析使用门槛，再比如利用个人或企业专属数据，构建专属智能知识库和在线智能客服。在这些场景中，有一个至关重要的前提，那就是要针对企业内部非结构化数据资产的知识进行特征提取，然后利用大模型实现更丰富的知识召回和补充。

阿里云对象存储 OSS 是一款海量、安全、低成本、高可靠的云存储服务，拥有海量非结构化数据，它提供了高效可靠的数据存储和管理，方便用户对数据进行存取和处理。为了更好地利用这些非结构化数据，9.16日阿里云存储和云原生联合两个热门的数据分析项目 Apache Doris 和 Zilliz 共同探讨非结构化数据处理和分析的最佳实践。

本次线下技术沙龙会议，与会嘉宾通过案例分析、实践经验等方式介绍了如何优化数据的采集和存取、利用函数计算处理对象存储 OSS 的非结构化数据、利用机器学习算法进行知识提取。此外，还分享了 NL2SQL 和在线智能知识库的实践参考，通过这些案例让大家了解如何用 Apache Doris 和 Zilliz 等技术手段实现非结构化数据的有效利用。

Serverless化的非结构化数据特征提取架构

来自阿里云智能云原生的解决方案架构师付宇轩介绍了什么是特征提取，并且阐述如何借助Serverless架构，实现更高效，成本更优的数据特征提取。

无论是早期的自然语言处理，还是到前几年的机器学习、神经网络，或者是现在的大模型时代，对数据的特征提取是亘古不变的核心环节，将高维数据转换为低维数据的方式方法和效率的优化程度从来都是决定最终结果好坏的关键所在。

将高维数据通过各种算法、模型转化为低维数据的过程，或者说提取事物特征向量的过程，在机器学习领域被称为Embedding。

在如今的大模型背景下，我们真正迎来了万物皆需Embedding，和万物皆能Embedding的时代。

各行各业的结构化数据、非结构化数据都可以通过开源的、商业化的模型或算法，将其转化为特征向量数据，然后存储在像Milvus、Zilliz Cloud、Pinecone、Chroma这类的向量数据库中，供各类业务进行检索，比如文章分类、以图搜图、知识库等。

随着近几年非结构化数据量的暴增，Embedding的需求量和工作量也是急剧增加，所以Embedding的流程也面临着越来越多的挑战，加之Embedding的相关模型分布在各个开源平台，获取模型步骤繁杂，让构建Embedding流程更是雪上加霜：

效率问题：从非结构化数据到可用的向量化数据，不是一个算子就能完成的，需要多个算子结合编排来实现。

-Pipeline 搭建复杂繁琐
-算子管理成本高。（可观测、灰度、治理等）
-构建通用算子样板间复杂

算力问题：无论是一个函数还是大模型运算，都可以是一个算子，但都需要算力支撑运算。

-长期持有算力，资源利用率不高，成本浪费
-异构计算资源搭配调度繁琐
-算力稳定性和算力扩展能力难解决

扩展问题：传统的Pipeline是一条路走到底，如何实现响应式，将不同存储介质串联起来的自动化流程。

-算子如何被上游服务自动触发
-算子可以支持多少种上游服务
-算子版本切换，快速验证，黑客增长

所以我们构建了以Serverless架构为基础的Embedding解决方案，帮助用户解决以上遇到的各类问题，以大家最常见也是最有刚需的知识库为例，可以做到快速的构建出完整的Embedding流程，用户只需要上传非结构化数据到数仓或数据湖存储（比如阿里云对象存储OSS），就可以自动触发Embedding流程，自动化的完成非结构化数据到向量化的转换并入库。

通过与开源项目合作，Embedding Pipeline引擎将Towhee做了封装，使用预置Python3.10运行环境的函数加Towhee layer，就变成了一个Towhee 运行环境的函数。我们将它封装为一个应用，部署在Serverless应用中心，这样用户便可以一键拉起Towhee函数，直接开始编写Embedding Pipeling代码，并且自带计算资源，节省了大量自己安装构建的时间成本和资源成本。

说到Serverless应用中心，我们提供了大量常用的样板间，供用户一键拉起所需的应用，并且每个拉起的应用底层都有完整的DevOps流程支撑和函数治理能力（可观测、限流降级、版本管理、灰度发布等）。所以针对Embedding方案，用户可以直接在应用中心一键拉起所需要的所有函数，比如Web端函数、AgentCraft函数、Towhee函数、各种Operator函数、各种开源模型函数等。极大提高了效率和管理能力。

在Embedding流程的扩展方面，得益于函数计算（FC）支持近百种触发器的能力，可以通过多种方式自动触发Embedding流程。这样就可以将Embedding流程集成到各行各业、各种领域的业务中，提高业务和产品的核心竞争力。

在降本增效是普世KPI、万物皆需Embedding的今天，Serverless Embedding方案切实地帮客户解决很多问题：

自带算力，成本优化：

-自带CPU、GPU算力，且可灵活搭配
-算力按需所取，按量计费，极大优化资源成本
-算力具备自适应扩缩能力，极大提高资源利用率

应用中心，效率提升：

-应用中心构建各类领域样板间，一键拉起所需组件（算法、大模型）
-提供丰富的开发者工具，提高研发运维效率
-适配主流DevOps组件，极大降低改造成本

上游生态丰富：

-提供近百种阿里云核心产品触发器，极大丰富上游生态
-集成EventBridge，可桥接市面主流组件及服务
-拥抱开源，共建社区

Apache Doris+大模型：OLAP智能数据分析服务探索

来自衔远科技的大数据研发工程师 & Apache Doris 社区贡献者王永臣阐述了大模型结合OLAP带来的新变化。

利用Apache Doris可以打造一个高效、实时的OLAP引擎，构建一个强大的智能数据服务平台，增强模型连接和数据转化的效率，确保结果输出的准确性。而通过将大型模型与OLAP引擎相结合，则可以为用户提供个性化、实时性高、灵活度强的数据分析服务。

传统数据服务中，会为业务分析师提供多种数据服务，其中包括sql查询、固定数据看板、定制化分析工具以及人工跑数。然而，在实际的应用过程中仍然有一些痛点：

SQL查询就需要业务分析师具备SQL编程能力，已编写复杂的查询语句
预设仪表盘，技术团队通常会创建预先设计好的数据仪表板，以简化业务分析师的工作。这些仪表板提供了可视化的数据呈现，但它们的定制性和灵活性有限
自定义分析工具，根据具体的业务需求，数据开发工程师可能会开发专门的分析工具。这些工具可以满足特定的数据处理和分析要求，但开发和维护成本较高
手动数据处理，当上述方法无法满足特定需求时，业务分析师可能需要与技术团队合作，进行手动数据处理。这通常需要沟通和协作，效率相对较低。

大模型与OLAP（Online Analytical Processing）引擎的结合，构成了一个强大的数据分析和处理联合体。这一组合充分发挥了大模型在自然语言理解和智能问答方面的潜力，以及OLAP引擎在高性能、多维数据分析方面的长处。

通过将大模型与OLAP引擎集成，用户可以以自然的语言方式向系统提出查询请求，大模型负责将这些请求转化为高效的SQL查询，然后交由OLAP引擎进行处理。这一联合体不仅能够实现个性化、智能化的数据分析，还能够以快速的速度提供查询结果。大模型负责实现用户友好的自然语言交互，而OLAP引擎则确保了高性能和准确性。

这种大模型与OLAP引擎的协同作用，为用户提供了一种前所未有的数据分析和查询体验，同时也提高了数据分析的效率和准确性，使企业能够更好地利用数据来支持决策和业务需求。

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

在典型的大模型 + OLAP 架构中，大模型充当中间层，将用户的自然语言转换为SQL执行语句，然后将这些SQL语句发送给底层的OLAP引擎。OLAP引擎负责接收和执行这些SQL语句，进行数据的预聚合和多维分析，以满足大规模数据集的查询和分析需求。

在大模型与OLAP架构方案中，尽管这一方案为数据分析提供了强大的工具和潜力，但仍然存在潜在痛点和挑战：

复杂性和集成问题：将大模型与OLAP引擎集成需要复杂的工程和技术工作，包括数据库模式的匹配、复杂数据的口径一致性问题、性能调优等。这可能需要大量的时间和资源。

为了解决复杂数据处理问题，我们在大模型与 OLAP 中间增加Langchain作为中间语义层转换，自定义DB Agent

训练领域特定模型：构建基于Doris数据库的训练数据集，基于小模型进行模型训练，使其更懂Doris
设定人工经验：以数据分析师角色进行相关prompt优化，使模型更好的充当分析师角色，以及设计规则，预设通用指标，进行规则判断是否需要进行大模型解析，如果不需要直接在OLAP中调用，如果需要责进行大模型解析用户输入，形成新的查询语句并执行

最佳实际案例分析：

嘉宾最后展示了衔远科技对外提供的电商平台ProductGPT产品案例，针对交互式查询和分析预测场景做了详细介绍。

基于Doris+大模型的智能数据交互式探察（Ad-hoc）

用户端输入文字，通过大模型转换成SQL语句后直接访问底层 Doris 数据库，可以支持多轮对话进行交互式数据探察，并将返回的查询结果智能生成可视化图表，所见即所得。

基于Doris+大模型的智能分析报表预测（Reporting）

将大模型对话嵌入在构建好的场景报表中，提取报表关键字并对客群/销售任务/渠道等关键信息进行智能分析，无需人工上卷下钻，智能预测分析结论。

向量数据库：大模型的记忆体

Zilliz 市场运营与生态负责人李晨从向量数据库作为大模型记忆体的角度出发分享了向量数据库和大模型结合的最佳应用实践。李晨表示，向量数据库是 AIGC 大模型的重要补充，是提供准确可靠、高度可扩展的长短期“记忆”的关键载体，其在 LLM领域的应用主要可以分为以下 6 类：管理私有数据和知识库、为大模型提供实时数据更新、实现大模型的个性化和增强、提供智能体的记忆、保存大模型的处理结果、构建更复杂的AI系统。当然，这其中离不开一个新的程序开发应用范式—— CVP Stack。

在 CVP Stack 中，C是以 ChatGPT 为代表的大模型，它在 AI 程序中充当中央处理器的角色；V 代表 Vector Database，即以 Zilliz Cloud 和 Milvus 为代表的向量数据库，为大模型提供知识存储；P 代表 Prompt Engineering，各环节通过 Prompt 的方式进行交互。

相比单模型架构，CVP 架构在灵活性、可扩展性、实时性、成本四个维度都有明显优势。最关键的原因是，在 CVP 架构中，领域知识可以用数据入库的形式进行更新，而非重新训练或微调模型，向量数据库是该架构的重要组成部分。这其中一个典型的应用实践就是 OSSChat（https://osschat.io/chat），它用于解决开源项目文档冗长、不易查找等问题，目前已经支持几十个主流的开源项目。

此外，为了进一步降低应用构建成本，提供标准化组件，Zilliz 已与全球头部大模型生态完成了 C-V 间对接。2023 年 3 月，Zilliz 作为 OpenAI 首批向量数据库合作伙伴，完成了 Milvus 与 Zilliz Cloud 插件化集成，作为官方推荐的向量数据库插件提供给广大应用开发者。同时，Zilliz 还与 LangChain、Cohere、LlamaIndex、Auto-GPT、BabyAGI 等热门项目进行了深度集成。值得一提的是，Zilliz Cloud在7月份官宣了和阿里云的合作，并正式开启在国内的向量数据库云服务，相信在双方的努力配合下，一定可以让用户享受到更好的产品和服务。

基于对象存储OSS进行AIGC相关数据和模型的高效存取

阿里云智能存储技术专家周翱（明锦）分享了几种不同的存储解决方案，加速模型的读存取。

作为一个共享存储，保存在对象存储OSS可以节省大量的客户端存储空间，让计算节点可以有更好的弹性能力，但是缺点是下载模型的速度变慢了，OSS直接下载一个6GB的文件甚至能达到100秒。

由于OSS2返回的stream流无法reopen和seek，所以在SD中我们加载的流程是，首先将整个文件下载到内存，然后封装为一个BytesIO对象提供给pytorch加载。除了了加载模型的时间外，pytorch还会进行模型的校验等操作，这部分数据我们不考虑，这里研究了模型加载时间。使用了不同的加速工具来下载模型。

服务侧加速能力

无限额外工具直接加速模型下载，无论使用什么客户端工具，大模型下载速度基本都有2倍-10倍的速度提升。其特点如下

缓存空间大

OSS加速器继承了OSS海量数据存储的优点，能够提供数TB至数百TB的缓存空间，支持直接缓存数仓中的多个表或者分区。

-吞吐能力：加速器的吞吐能力显著提升，带宽随容量大小线性增长，能有效解决多种应用场景的读吞吐的挑战。
-弹性伸缩：计算任务通常是周期性任务，每个任务所需资源存在差异。加速器可根据您的需求进行在线扩容或缩容，可有效避免资源浪费，降低您的使用成本。

OSS加速器提供秒级调整配额的弹性能力。对于批任务，下载流量通常存

在波峰，OSS加速器可以提供秒级扩缩容量（数十TB到数百TB）和带宽（数Gbps到上百Gbps）配额的能力。您可以在任务启动前扩大配额，任务完成后缩小配额，节约日常使用成本。

-低延迟：OSS加速器可以为业务提供更低的下载延迟，尤其适用于大文件的下载场景。对于容器化场景，云数据湖、数仓场景有较好的效果。
-存算分离：加速器可满足计算资源和存储资源分离。面对不同的计算任务，您无需再自建不同缓存进行匹配，满足多业务场景的吞吐加速。
-数据一致：加速器提供了传统缓存方案不具备的数据一致性。当OSS上的文件被更新时，加速器能自动识别并缓存更新后的文件，以确保计算引擎读取的都是更新后的数据。
多种预热策略