林伟：大数据AI一体化的解读

2023-12-05 13:14:10 22

原标题：林伟：大数据AI一体化的解读

今年是AI大爆发的一年，大语言模型的诞生推动了席卷整个行业的大模型热潮，许多人认为“AI的iPhone时代”到来了。训练大模型其实不简单，因为模型参数量的增加意味着需要更好的算力、更多的数据去锤炼，并且需要合适的工具让开发者快速迭代模型，只有这样才能更快地提高模型精度。这几年来阿里云一直在宣传AI工程化和规模化，其实是这轮AI爆发的主要推手。

我们看一个典型的模型开发过程，包括数据预训练、模型训练到模型部署。我们往往会非常关注训练，而忽视了整个生产流程。但是要训练出好的模型，数据越来越重要。包括数据采集、数据清理、特征提取、数据管理，再到训练过程中，需要分发哪些数据参与训练、哪些数据用来评测模型质量。所有数据都需要有验证部分，用于验证质量，这一步非常关键。低质量数据对模型的伤害力是超出想象的。这也是为什么吴达恩一直宣传了一个观点，就是更好的机器学习是80%的数据处理+20%的模型。

“以模型为中心”和“以数据为中心”的模型开发方式演进

这也体现了模型开发方式的演进。过去我们常常说以模型为中心的模型开发，算法工程师花大量的时间调模型结构，希望通过模型结构来去提高模型泛化能力，解决各类噪声问题。如果大家看5年前的Paper，会发现大量的研究都是围绕模型结构展开的，当时的数据、算力都还不足够支撑今天这样的大模型时代。那时候的模型训练更多是“有监督的学习”，用的都是标注数据，这些数据是非常昂贵的，这也决定了在训练过程中，数据上没有太多腾挪的空间，我们更多在考虑模型结构的变化。

今天的大模型训练有非常多的无监督的学习。模型结构反而是没有那么多变化的，大家好像趋同的，都采用Transformer结构。这个时候我们就慢慢演进到了以数据为中心的模型开发范式里面。这个开发范式是什么？就是需要用大量数据去做无监督的训练，通过大的算力、大的数据引擎，结合相对固定的模型结构去萃取出一些有趣的智能的东西。

因此，训练使用到的数据量会暴涨，也需要用到各种方法清洗和评测数据。我们可以看到许多大模型研究的团队都会花费大量的精力去处理数据，在各种环境里面反复地、多角度地验证数据质量。通过各种各样的维度，甚至有时候还会把模型产生出来去评测，通过模型结果反馈数据的质量。在这个过程中，就需要积累非常多的数据处理工具，只有这样才能有效地支撑以数据为中心的模型开发工作对于数据质量的要求。这也是大家说到以数据为中心的模型开发的范式的核心的一个想法。

正是在这种趋势下面，我们一直认为大数据和AI是一体两面，需要实现大数据和AI的一体化，这样才能顺应当下模型开发范式的演进。

在阿里云，我们一直努力将数据和AI两个系统紧密地联合在一起。我们在计算基础设施层，提供适应各种场景的计算集群，包括适合大数据的以CPU为主的集群，以及适合大模型训练的需要RDMA网络的异构计算集群。在此之上，打造了大数据和AI一体化平台，覆盖模型开发全过程的能力，包括数据采集和集成，再通过大数据平台，做大规模的离线分析，去验证数据质量。此外还有流式的计算能力。数据在大数据平台上处理好之后，就会被“投喂”到PAI这个负责人工智能开发的平台，去做训练和迭代。最后，在模型应用孵化上，依赖向量引擎的数据库，例如Hologres等，一起去构造场景化的应用。

大数据AI一体化的应用场景

在正式展开大数据AI一体化的技术点之前，先举两个应用的例子。

第一个例子是知识库检索增强的大模型问答系统。大家可以看到最近很多做大模型的通行，都会提到这个场景，通过一个大模型，可以获得特定行业的垂直知识库。这是怎么做到的呢？首先，需要把这个知识库的数据进行清理后分片，通过大模型把它转成一个向量，再把这些向量存在一个数据系统里面，这是向量检索的数据系统。当有真实请求过来的时候，会先把query对应的向量找出来，转译成知识，再用这个知识去约束大模型，控制大模型“胡说八道”的冲动，这样反馈的结果会更加准确。

这个场景里面用到了很多大模型能力，包括大规模分布式的批处理，因为在创建embedding的时候，其实是一个非常大的数据。同时，也会用到向量数据库这样的服务能力，真实业务场景对于查询时延的敏感度很高，需要非常快的给一个向量。当然也用到了大模型训练的能力，就需要一个很好的AI系统。

第二个例子是个性化推荐系统。在做实时推荐的过程中，所有推荐对象的兴趣是动态变化的，往往这样的系统它的模型是时时刻刻更新的，需要根据最新的行为数据来更新模型。我们往往会把所收集到的日志经过实时或者离线处理，离线数据用来生产一个比较好的基础模型，实时数据也会去提取这个特征，经过模型训练产生一个模型的delta，然后再把这个delta应用到线上的系统进行每天更新。在这里面我们可以看到有非常多的数据系统，有实时的像流计算的系统、有AI的系统、有批处理系统。

大数据AI一体化的技术实现

统一的数据和AI工作空间管理

首先，我们在模型构造最外层，把AI和大数据的流程串联在一起，这也是我们在PAI产品里构建工作空间的最初始的想法，这样就可以把多种资源统一在一个开发平台上管理。现在阿里云人工智能平台PAI已经可以支撑多种计算资源，包括ECS资源、流计算平台，还有PAI灵骏智算用于大模型训练的集群，还有这次云栖已经发布的容器计算服务ACS等等。

仅仅接入这些资源是不够的，用户需要的是把接入的资源有机串联到一起。所以我们推出了一个Flow框架，把这些流程串联起来，把模型训练和数据处理的各个步骤连接起来。这里面我们提供了多种构建连接的方式，包括静态构图、SDK、图形交互式等，用来去构建复杂的大数据和AI交互的流程图。

Serverless云原生服务

如果想进一步地去把大数据和AI融合好，用户希望能够在一份资源里面提供大数据和AI的服务。这时候就离不开Serverless云原生服务技术。我们一直在说云原生，但是云原生其实是有很多维度的，云原生更多的是资源是共享的，但是这个资源是什么？其实也是需要定义的。

这个定义也分很多层次。你可以说你是硬件层面的共享，那你共享的是服务器、虚拟服务器；你也可以共享更高层次的虚拟资源，比如容器和服务本身。在不同的层次，共享层次越高，单位计算成本就会越低，当然技术的复杂度也会越高。这也是为什么做云计算的团队一直在提高自己服务的云原生化，或者是去实现更高技术复杂度的能力，这样就能以更加经济实惠的方式去提供更高层次的计算资源共享的目的，更加经济高效地提供大数据和AI的服务。

也是因为此，我们所有的大数据产品都是在第六个维度，也就是Share Everything上的一个产品。但是我们都是架在了第五个维度，也就是Shared container，就是在容器计算服务这一层，这样我们就可以把大数据和AI的系统有机地连在一个资源上面。

统一调度：多负载、差异化SLO增强的调度

为了能够达到这样的能力其实并不是那么容易的，因为容器计算服务最开始的产生是为了支持微服务的。微服务在并行调度的力度上面，和大数据以及AI智算的场景有很大不同。为了能够让不同的大数据和AI的任务和服务，能够跑在一个资源池上，其实我们要做大量工作。比如说，大数据场景里面有些很多高并发、短时长的任务，需要大大增强K8S本身的吞吐能力，解决它各个层次上的性能问题，包括延时和规模。

同时我们有多元化的任务，它不仅仅有在线服务，还有计算任务，我们要在调度上增强资源的丰富度和多场景的能力。比如在复杂的AI场景，需要做网络拓扑感知，因为AI大模型训练对网络要求非常高。这时候我们怎么样在这层的容器服务上、计算服务上感知这个拓扑结构，有效做调度，我们怎么样让大数据和AI的Workload在上面存储资源，需要有非常多的负载感知、QS感知的调度。

多租安全隔离

对云服务来说，最重要的就是多租安全的隔离。我们需要加强云原生的K8S在这个方向上的能力，这样我们才能安心地把大数据和AI复用在一个资源上。我们在存储层、网络层都用了非常多的安全隔离的技术。这样才能把大数据和AI的多款产品，甚至是用户自己的在线服务，能够集成在一个资源池里面，来给云上提供企业化的使用。

容器计算服务ACS

这次云栖大会发布了容器计算服务ACS，PAI也是第一批容器计算服务支持的首批产品之一。在容器计算服务ACS平台上，用户可以很好地调配自己在大数据和AI的资源配比，然后在统一的资源底座上、在网络上、在存储IO上，就能够更加自然地联在一起。

多级Quota

我们都知道大模型的计算，计算资源是非常昂贵的。我们还要持续地加强这个底座上的一些精细化的资源管理的能力，所以我们也即将发布多级Quota能力，使集群的管理员可以更好地管理资源，平时让各个团队管理自己的资源，但是到了关键时刻。比如到了需要冲刺的阶段，管理员可以把所有的资源集中起来，然后去训练一些比较大的模型。这是我们的多级Quota。

自动拓扑感知调度

对于超大模型的模型训练，我们要加强容器服务的调度能力。举一个例子，我们可以看到在模型训练里面我们常常有一个步骤叫All-Reduce的环节，如果不加以调度的控制，稍微乱一个顺序，去构成reduce的ring，就会发现会带来一些cross的交换机的流量。最后我们经过拓扑感知的调度和非拓扑感知的调度，前后性能提升的增幅能有30-40%，这是非常可观的。

MaxCompute 4.0 Data+AI

大模型训练往往需要海量的数据，就跟我们前面说的我们不仅仅要把数据存下来，更多的是我们要进行批处理进行清洗、反复评估数据质量、并根据反馈来调整数据。这时候我们就需要大数据平台，以及湖仓一体的能力在背后支撑。阿里云数仓产品MaxCompute上推出了MaxFrame的开放的数据格式，可以把强大的数据管理、数据计算的能力，和AI系统进行有机和开放的连接。此外还有Flink-Paimon，在流计算的场景里，可以把流计算和online machine learning结合起来，把数据和训练的这条通路打通。

数据集加速 DataSetAcc

在PAI灵骏集群的AI智算场景里面，不仅仅是高密的机器学习任务，还有数据处理的任务，但是高密计算的资源是非常宝贵的，这个时候可以去连接远端的大数仓来解决。但这里又会出现一个矛盾，就是远端的数据I/O不能匹配高密度的计算。为了解决这个问题，我们提供了一个数据集加速的DatasetAcc能力，就是利用PAI灵骏集群本地的SD和本地的储存来做一个近端的cache，异步地把远端数仓的数据拉到近端。这样就能很好地解决大数据和AI智算集群在训练场景上的结合，提升训练效率。

正是因为具备了这样的有效连接大数据和AI智算集群的能力，我们才能在大规模的LLM训练过程中更好地使用大数据分析的能力。举个例子，我们在训练通义千问的过程中，获取了大量重复的文本信息，去重是非常关键的步骤，不然整个训练数据集会被这些数据拉偏，导致有一些过拟合的情况产生。我们利用我们构造的FlinkML的library构建了一个高效的文本去重算法，算法的同学就可以快速地进行多次文本去重，提高整个模型开发的效率。

我们前面说的都是大数据怎么能够助力于AI训练的部分，也就是我们经常听到的 Data for AI，但其实反方向，AI技术的成长也能够帮助数据系统，去提高它的服务质量和效率，现在的数据分析也从BI走向了BI+AI。

DataWorks Copilot

过去的数据分析做的更多的是 business intelligence，如今有更多AI技术可以去推动数据分析能力的提升。我们在这方面做了一些工作，比如说在数据开发和治理平台DataWorks，我们推出了 DatawWorks Copilot，也就是代码助手。代码助手可以帮助用户用自然语言的方式，去找到感兴趣的表格，然后再帮助用户构建SQL query，最后再去执行query。

当然，真正要做出一个好用的代码助手，只用基础模型是不够的。DataWorks平台基于大量的公开query，然后我们用本身的语言，就是MaxCompute的或者是Flink的语言，作为一个数据集，我们拿基础模型和这个数据集做了finetune，产生一个垂类模型，然后再在这个垂类模型做推理，产生了这个特定场景里的更有效的代码辅助工具。通过这种方式，我们能够提效30%的代码的开发。