阿里云大数据AI一体化最佳实践全解析
随着大模型项目逐渐成为主流，机器学习的开发范式正从“以模型为中心”转向“以数据为中心”。过去算力昂贵，处理海量数据成本过高，团队只能反复调整模型参数，与过拟合、欠拟合对抗。训练质量高度依赖标注数据的准确性，而标注成本往往居高不下。Transformer模型问世后，工程师的重心从调参转向提升数据质量——不再完全依赖标注数据，数据平台的效率反而成为整个流水线的核心瓶颈。
大数据AI一体化并非新课题，许多公司建设的推荐系统就是典型——通过数据打标签、构建特征库、训练推荐模型，模型版本持续迭代，AB测试反复执行，调优后上线。既有离线场景，也有在线场景，还有离在线混合模式。
上图展示了一条典型实现路径，也是阿里云上最经典的方案：Flink负责标签实时加工，MaxCompute处理离线批量数据，PAI-TF执行在线训练。模型上线后，还需实时采集指标、进行多维度对比分析，此时多数交互式分析场景采用Hologres这类OLAP工具，支持秒级快速查询。
然而，真正落地这类系统并不容易。成本、效率、运维等多方面因素都需要考量，踩坑点不少。
第一个问题是研发阶段严重割裂。数据团队和AI团队往往分属不同部门，使用不同平台和开发语言，沟通成本高。数据人员习惯数仓和结构化数据，聚焦元数据生产；AI人员通常基于Python在单机开发，完成开发后与数据再无闭环交互，数据单向流动，割裂明显。
其次，效率是另一道门槛。大数据团队擅长分布式并行处理，AI团队则擅长在单机上把模型调参到最优。但当前的关键已不再是模型是否需要反复调优，而是数据处理量需要提升几个数量级——单机算力能否扛住新场景？很可能遭遇性能瓶颈。
第三是工程化问题。过去公司的数据平台和AI平台往往因不同场景和目的采购不同供应商，平台之间难以打通。许多公司同时使用多个系统，账号、权限、运维各自独立，脆弱性暴露无遗。
最后是数据管理能力，这是整个项目的根基。系统割裂导致难以实现全局统一的数据治理。大数据平台与AI开发平台的元数据割裂，始终是一块难啃的骨头。
大数据AI一体化正是为了解决这些痛点。大数据平台需要做好统一元数据管理、大规模数据处理、分布式计算算子，并提供丰富、海量、弹性的计算资源。AI平台则需要统一模型管理、可视化建模流程、分布式训练环境以及充足的GPU资源。大数据与AI结合，本质上是相互支撑——大数据平台为AI提供数据底座，AI平台则通过智能算法让数据平台更易用。下面来看阿里云在这两个方向上的具体实践。
---
## 02 阿里云大数据AI一体化架构演进
上图是阿里云提供的整体解决方案，从底层的资源层，到中间的大数据AI一体化PaaS平台服务层，再到模型服务层和应用层。大部分应用和模型来自合作伙伴，蓝色部分为阿里云原生产品和服务。今天我们重点聚焦数据平台部分——在丰富的计算资源之上，提供易用、可扩展的数据处理平台，并与AI机器学习平台PAI集成打通。
数据平台的核心是MaxCompute，原名ODPS（Open Data Processing Service）。它包含两大引擎：离线数仓MaxCompute和实时数仓Hologres。MaxCompute是一款比Spark更易用、执行效率更高、企业级能力更丰富的大数据平台。
MaxCompute经历了15年迭代，不同阶段重点解决不同问题。最早从09年开始研发，源于阿里集团内部海量数据分析需求——既要替代Oracle降低成本，又需要强大的扩展性支撑业务快速增长。当时做了5K项目——单集群超过5000个节点，解决了扩展性问题，数据量从此不再是瓶颈。
17年之后开始提供公有云服务，转向Serverless，这本质上是运维方式的变革。背后的挑战巨大：升级如何做到业务无感、无中断？流量如何均衡分配？灰度回滚如何实施？Serverless背后是租户体系的改革——一个集群服务一个Region的所有用户和所有类型的作业。
第三阶段是湖仓一体改造。此时发现结构化数据已不够用，大量非结构化、半结构化数据需要管理和加工，第三方Hadoop集群需要托管，数据治理也需要更高质量。我们提出了湖仓一体架构，将基于开放存储、开放格式的数据统一纳管到MaxCompute的元数据体系下。同时实现了离线实时一体——让在线交互式分析引擎Hologres和离线数据加工引擎MaxCompute之间的元数据和数据集成交互打通。
从2023年开始进入下一个阶段。这一阶段的特征是开放架构——我们希望数仓是开放、多元的。在数仓存储层提供了MaxCompute Storage API，第三方计算引擎可以直接以原生、底层、高吞吐的方式访问数仓数据。过去数仓为性能优化而封闭设计，如今不再封闭。同时我们也提出了Data+AI的解决方案，稍后会详细解析。
MaxCompute的核心形态是完全Serverless。上图来自Gartner分析报告，Serverless分为多个级别，体现在资源共享力度的不同。从最原始的机器资源共享，到操作系统层面、容器层面、应用层面、租户层面的共享——每提高一层共享力度，对服务提供方的技术难度呈指数级提升，但对用户而言收益越来越大。资源复用得当，整个服务的成本就能降得足够低，为用户提供更便宜的计算服务。当然，这对资源隔离要求更高，系统升级也更难。
MaxCompute从设计之初就是Serverless定位——只有运维效率提高、资源利用率提升，才能提供有竞争力的数据计算服务。除了成本，另一个优势是弹性。尤其在机器学习场景，很多时段只有部分时间需要大量资源，如果采购一台机器大部分时间闲置，是巨大浪费。因此机器学习对Serverless的诉求非常强烈。
接下来讲讲Data+AI的解决方案。MaxCompute针对AI场景的创新主要体现在以下几个方向：
- 数据管理层：数仓擅长处理结构化数据，但机器学习场景有大量非结构化数据、文件数据、图像数据等。我们在非结构化数据管理上做了创新，引入了Object Table这种新型表类型。
- 计算框架：推出了面向Python开发的分布式执行框架MaxFrame。过去数据平台主要用SQL接口开发，但数据科学家最习惯使用Python和各类Python开源工具。通过MaxFrame，MaxCompute提供了SQL+Python双引擎能力，Python成为数据平台的一级开发语言。
- 交互式Notebook开发环境：这是AI同学非常偏好的开发环境，可以在其中进行交互式验证和作业分享。
- 镜像管理：Python开发中版本管理、镜像打包等一系列工程问题，同样是效率的关键。
数据管理能力的演进可分为几个阶段。
第一阶段解决联邦问题。当数据交互双方使用不同引擎时，数据能否兼容？能否不搬迁实现联邦查询？我们希望以联邦为中心，打通元数据管理，为用户提供统一的元数据视图和权限管理。
第二阶段，光有联邦还不够，还希望不同存储格式能放在湖上，提供一份数据多引擎的能力。因此做了湖仓一体，提高数据易用性，提供原生查询和元数据管理能力。
第三阶段，越来越多用户提出非结构化数据管理的需求。大量非结构化数据作为输入，交给Python库做向量化转化，但这些文件背后缺乏元数据管理能力，也很难做分布式计算。因此我们开发了Object Table来解决这个问题。
Object Table是一种新的表类型，专门处理非结构化数据。它存储的是非结构化数据的元数据，而非数据本身——包括文件路径、文件名、文件大小、更新时间等，以及不少可扩展的tag值。
基于这些元数据，可以做很多提升开发效率的事情。例如有1000万个PDF文件，希望平台并行处理这些文件并抽取文本。一种简单做法是一个文件启动一个进程，但1000万个文件就要启动1000万个进程，调度开销太大。如果有些文件可以跳过——比如太小的不打开、很久未更新的可以忽略——那么很多需要对元数据过滤的场景就很重要。过去没有元数据信息很难处理，现在表中有了元信息就可以实现。
还有并行化处理的问题。一个进程处理一个文件，还是一个进程处理10个文件？对吞吐的影响巨大。过去没有元信息难以决策，现在有了元信息，worker可以判断：假设一个worker能处理100MB数据，就可以将100MB数据以批量的形式输入给一个进程worker并行处理，整体吞吐量会有本质提升。这也是工程化中很常见的做法。
除了元数据管理，还有大量性能优化，例如海量小文件、碎片文件处理有几十倍的提效，单一大文件的IO访问也做了优化。
第二大创新是MaxFrame，将Python的开发体验做到原生化。我们希望给用户的心智是：在单机上本地开发的Python程序，基于主流Pandas接口编写的代码，可以100%透明地迁移到MaxFrame平台上，享受平台可扩展的计算算力。MaxFrame提供并行化计算能力。
用户编写的Python代码并非针对分布式场景，而是单机场景。但数据输入来自MaxCompute表，MaxFrame会将算子并行化，运行在不同分布式节点上。这意味着以前在单机上跑几十个小时的Python作业，现在可能只需几十分钟甚至更快。MaxFrame的核心理念就是：让使用Pandas接口开发的数据分析、数据加工程序，能无缝、透明地迁移到大数据平台上。同时平台与MaxCompute底层数据原生打通，可以高吞吐、高效率地访问所有数据——不仅读，也包括写。
上图左侧是Pandas算子——表连接、关联、过滤、聚合等，几乎所有常见的数据分析Pandas算子都支持。右侧是机器学习平台数据处理部分的55个算子——大量文本处理、文本过滤、文本去重、文本计数等，都是MaxFrame原生支持的。这些算子背后都做了性能和可扩展性支持，使用起来非常简便。
这里有一个对比例子。左侧是开源的RedPajama，在大模型场景下，端到端从数据采集加工到产出结果，七八个环节，每个环节有不同算子。以前单机运行，跑完整个流程需要59个小时。转成MaxFrame之后，仅用1.3小时就跑完了，效率提升非常明显。
Python开发高度依赖版本管理和镜像管理。一份作业中可能依赖几十个不同的library。因此我们做了一套镜像管理方案，包含内置镜像和自定义镜像。内置镜像将很多主流的常见数据分析、数据加工作业所需的Python library都内置了，用户直接引用即可。
讲完加工环节，再聊聊数据服务环节，以向量检索服务为例。这两年向量数据库非常热门，但业界一直有个困惑：每家公司是应该采购一个专属的向量数据库，还是选择一款带有向量扩展能力的通用分析数据库？我们看到主流的云厂商大多选了后者——在数据库里增加向量化检索能力，与原生OLAP能力结合，场景更丰富、开发更易用，用户门槛也更低。阿里云也是这个思路。
Hologres是一款分布式高性能OLAP引擎。2020年，Hologres与达摩院合作，将高性能向量化引擎Proxima集成到SQL引擎中，提供SQL查询接口。Proxima性能优异、精度高、计算效率快，内置多种检索算法。
Proxima和Hologres结合，能充分发挥Hologres的强大性能。Hologres面向高并发、低延迟场景设计，性能可达毫秒级响应。同时易用性出色——无需学习新接口，直接用SQL，数据同学上手极快。
向量这件事其实并不复杂——将文本、图片等转化为向量数组，存在数据库表的一个字段里，Hologres在底层自动构建各类向量索引。向量计算广泛应用在推荐引擎、大模型推理等场景。
数据库与向量融合的好处在哪里？以前向量引擎只能做向量查询，数据库只能做结构化查询。现在两者合一，既可以做结构化过滤，也可以做向量化检索。写SQL语句变得很简单——很多以前必须在专业向量数据库里做的事，现在一个通用数据库就搞定了。一个SQL就能实现向量检索、过滤、排序、去重等操作。真正实现了“一个引擎、一份数据、多个场景”。
以上说的是数据平台如何为AI提供支持，是Data for AI的视角。反过来，AI平台怎么让数据平台更好用？今天所有数据分析都在从BI演化到BI+AI的场景。
Copilot从去年开始成为主流，NL2SQL是常见场景——帮用户写SQL、找表、更容易地诊断SQL错误。阿里云推出了DataWorks Copilot，工程师将大量SQL语料喂给Copilot模型，希望产出好用、更智能的SQL Copilot能力。
除了写SQL的开发阶段，分析阶段更为重要。DataWorks和DataV也在合作实现增强分析——过去以经验为主的分析范式，正在转化为由机器做推断。增强分析可以自动生成各种洞察、不同的报表、不同的视图、不同的看数角度。
---
## 03 Data+AI场景实践分享
最后通过一个具体场景，来看看数据平台怎么用。
这是通义大模型的一个加工场景的简化版本，主要处理文本去重。核心环节包括数据采集、读取、处理到模型训练，中间有很多小环节——文本去重、敏感词过滤、版权删除、文本标准化等，依赖了很多不同的Python library。
文本去重的基本流程：先做分词，然后计算哈希值，再求哈希近邻。
我们的做法是：先把依赖镜像做好管理——这个镜像里用户依赖了很多第三方library，不同Python版本、不同library版本，大家需要共享的开发环境。所以第一步是做镜像管理，将这些依赖镜像做成团队内可共享的。
之后是开发环节。右侧是一段demo代码，总共不超过100行。初始化依赖4-5行代码——初始化框架资源、身份认证，然后几行代码做数据过滤，再几行做分词，背后用的是Pandas开发接口，里面有各种数据转换逻辑。这100行代码，可以跑在几乎无限扩展的计算平台上。我们希望达到的效果是：用小代码快速迭代的方式，在规模化计算平台上处理规模化问题。至于分布式怎么调度、怎么容错、数据怎么切分、怎么做并行化——大量类似的工程细节都由底层大数据平台完成，效率提升非常明显。
如果不喜欢写代码，也可以用拖拽的方式。平台提供了可拖拽的pipeline组合方式，将整个计算流程中不同算子拖拽组合在一起即可。
从通用场景来看，绝大部分性能提升在70%到90%之间，数据量越大，提升越明显。同时环境准备方面，我们反复强调工程一定要提效率——效率不一定只是计算效率，开发、调试、环境准备往往会占用大量精力。我们希望通过平台来减少这部分工作量，实际效果也相当不错。
最后总结一下大数据AI一体化的工作。这次分享没有专门讲大数据做什么，也没有专门讲AI做什么，更多是在讨论二者如何更好地集成。阿里云大数据平台MaxCompute做了非结构化元数据管理，支持Python开发语言，让Python可以跑在并行化运行环境里，还有大量IO优化、调度优化，提供了Notebook交互式开发环境和镜像管理能力。这些工程化能力实现之后，大数据和AI之间实现了数据一体化、权限一体化和开发界面一体化。通过这些一体化，可以让AI同学更熟悉数据平台，也让数据平台同学能更快上手AI应用。这正是我们希望实现的效果。
**以上就是本次分享的内容，谢谢大家。**