一、dateworks面临的挑战

1.概述

今天发布的产品可以说是Dateworks的一次重大革新。其实远远不只在执行呈现。因为现在呈现的其实是我们初步和用户交互的东西。未来我们会有更好更强的能力去推动。但在做这些的例子前，我们需要说清楚核心的本质上面的变化是什么这些变化可以带来一些什么样的产生空间，这是我今天想与大家一起交流的。变革之下我们会分析原来的情况，面临的问题以及解说的原因。dateworks本身是在云上推出是一项云产品，现在我们继续开展云原生，开放性，以及如何面对开发者的dateworks,以及ai和大数据的讲解。

2.面临挑战

dateworks诞生于阿里的数据资产的治理。我们强调的是治理和数仓。因为那个时候我们的数据主要是报表数据，我们的商家，货品，物流等报表需要做商业决策，而这些报表非常结构化。非常需要精细的数据和准确性。所以我们非常强调自理数据的正确性数据不可冗余，不可分叉。不能与不同的人用不同的方式去解读数据，否则会造成决策的分裂。为了去做更好的数据治理以及数据仓，最简单最直接的方式就是把大家的数据都放在一起。这就是为什么Dateworks 与nexcompeter成为最佳伴侣的原因。我们把阿里的所有的数据通过规整的方式放在统一的数仓上面。再用我们的数据治理平台进行管理数据的整个血缘分析。

我们非常强调数仓的治理，越是高强度的治理，对于开发者就越由所束缚。当你简单去实现治理和数仓管理，因为需要监管必然会牺牲掉易用性。当时有一些深入使用Dateworks的用户。你发现你写的代码没有本地化的代码，必须要把你的代码上交到工作流或者是上交到所有人都能看见流代码，因为你的代码牵涉到你对于数据的分析，是否符合商业的想法。那这样你失去了个人性，也没有很好的应用性。你的dibug必须要在云端根据真实的数据有一个报表，再对比报表，开放性也不足。现在这个挑战变得更加迫切必须要去解决。这是因为外界的需求在发生快速的变化，变化本身就是因为多模态的数据，AI更多的数据分析，它不仅仅是处于简单的数据报表，而是有多元化的数据。通过AI和数据的融合。举的一个例子，比如数据的种类不仅仅是报表,还有图片、有深度的、有比例的，但在ai方面，也会产生大量的使用。

比如为了能够让ai的模式训练出一个更高的模型，那么就需要模型管理，模型也有很多版本，也需要数据和模型和在定制化时的血缘关系等。这使得数据平台和ai平台需要进一步结合在一起。而太注重治理的dateworks 会束缚ai+大数据方面。这是因为非结构化的处理，不像只写一个SQL，它是一个非常decl的languge。非结构化有很多的工具。这些工具是形形色色的客户或是用户开发者，有可能写一段pathon的代码，你在市面上可以收到无数的pathon开源代码，一个代码可能只处理一种数据格式。比如PDF提取等等。而这种工具和格式会非常多元化。而我们原来的模式太注重的东西会束缚开发模式的演进。说到根源，我们会发现这些工具它都需要一些优良的自定义安装的能力，也叫容器化能力。为什么大家要去拥抱容器，那是因为容器给了用户自定义环境的能力。即每个用户可以有不同的语音环境。每一个工具有它的要求，每个要求不一样，固需要不同的混合逻辑，而容器的拉起需要一个容器的管理平台。正是这个原因K8S才会变得如此流行。在ai方面pathoncode是非常多开发工程师去使用的一个开发语，并不只有SQL。

二、开放云原生的Dateworks

1.云原生：Kubenetes作为资源底座

原来的dateworks对外做一个数据处理的产品，但它本身并不是云原生。dateworks是一体化的，我们有非常多的服务器上面构建了对外服务但他本身并没有架在云网络的层面。云网络服务关注于自身服务如何架在更开放性的网络之上。因为一旦将自己的服务变成了云原生，你就可以使用到我们阿里云其他的所有云产品，用户可以去对接各种各样的云产品。大家可能会听到很多叫伏羲或者飞天的调度系统或者资源系统，我们其实是把这个东西进行K8S改造化，让我们的调度系统变成一个能够支持容器化的调度。因为原来可能是任务型的调度。现在要将它变为容器性的调度，因为调度容器才调度形形色色的工具。因为这些工具需要不同的容器包裹起来支持多元化的工具。所以首先要把我们的调度系统从一个物理集群里面的调度任务，调度节点的东西变成立有任务边界的系统。前面我们讲过如何将云原生的serverless 演化成K8S的调度。在此基础上，我们还需要让用户的资源节点能够聚在云网络的层面以上而不是云网络以下。目的就是我们可以很好的去对接各种各样的云产品。

所以怎么样的把我们的底座能够云原生化的云网络化去对接。这样就可以去连接云网络的同步产品了。比如说人气分发的产品等。这就是我们在内部扩充部分做出的很大部分的变动。使得我们很好的去连接各种各样的云产品。

2.连接多样云产品

第一个是NAS产品。刚刚解说了个人工作环境是如何产生的。因为原来我们并没有个人存储空间。一旦有了个人的存储空间，这个存储空间就会成为一个标准化的存储产品，那么你可以在这个空间上面可以用GIT。你就可以动态跟踪GIT系统去下载代码，管理代码。就有了个人的开发环境。我们也有容器化的改造去对接PADNOTEBOOK就使得我们大数据的NOTEBOOK应用上ai已经做好的很多的NOTEBOOK的底座,能够复用到很多的ai已经沉淀好的一些算子。另外在数据源和计算资源上，我们会秉承着去JIEO，支持非常多的计算引擎和数据源。原来可能以数仓为主。但我们现在数据源是要多元化的。因为我们有很多多元态的数据，不管是QSIS数据，还是其他数据语言，我们怎么样把这个数据和资源的格式把它抽象出来，使得我们能够很方便对接新的数据源。

但是其难度要比大家看到的会更加复杂。因为我们阿里云是作为阿里公司的一个云产品。阿里云产品它区别于比如说我们大数据设计产品，最大的一个区别是它是一个数据产品，也就是用户可能把自己的这个流程和数据存在着他自己的ecs上它的一种虚拟性环境，它虚拟机是要有网络。就像我们的客户，他有他的ip部分，他的ip部门会出现各种各样的局域网，通过网络的构建去做好IT治理做的IT的安全性合理。这种网络会非常复杂。假设我们知道有一个很大的公司，我不知道大家原来在学校的阶段或者在工作阶段有没有做过网管。比如一个很大的公司，网络的货币网的配置设置，网关的设置都是非常复杂的因为用户有ecs的机器，它必然ecs机器必然会有一个局域网在管理ECS那我们的作为一个数据产品，就需要去帮助我们的客户去把这种网络的管理提供便利性的服务，使得我们的数据能够在这些复杂的局域网上怎么样通过云网络给我们的好的连接feature 去做快速的连接。右图是一个例子，我们怎么样的帮用户去比赛这里。就去探查各个计算引擎之间不同局域网建立网关。就像局域网的网关去跳过这个网络的边界，我们怎么一个数据产品去帮助大家去连接更多的资源，更多的计算资源在云网络以上，必然要去做的一个工作。

3.开源flowspec

另外一个数据就是开放性,我们做过有非常多的多云化，多多云挑战,很多的客户也会担心这个问题。我们一直有很好的一个UI可以用连连看或者是用托拉拽的方式来去构建一个LEPALY。但这个很多的客户也会担心在这上面构建出来的paplai，很难去做一个全局的review，并不知道其中的改动是什么。因为图片的图像图案的改动是很难去科学定位的，也很难去描述。我们整个调度的graf背后其实有一个完整的描述。我们将speck 的定义完整的进行开源以及文档化。我们提供很好的工具，可以将构成的FLAW调度的GRAF一键导出也很容易把外面的不管是airplo还是用dophons scadue生成的flaw一键导入到datewoos来帮助我们的客户很好的去选择适应它的产品。如图是一个spec的描述，右边的图可以描述成左边的文本。然后另外一个开放型是open api。因为我们的客户在有数据产品的时候需要和他的运维银牌，他的工具数据平台有很好的连接。不一定喜欢用我们的UI的方式，他可能会有很多定制化的需求。但是我们提供完整的api，是十分完整和严谨的，可以使得客户可以不依赖任何的ui来去构建自己的数据平台。

三、面向开发者的Dateworks

1.notebook

然后对于开发者，我们在过去的一年也做了非常大的改动。第一个是notebook产品。第二个是它可以很好的去连接容器分发服务，叫做ACR,这样你可以管理自己的运行环境，也可以拥有自己的工具，可以将工具建到自己的容器镜像里面，可以有自定义的镜像。有nas连接云网络，你可以有自己的私人目录，你可以通过自己的GIT去管理自己的代码。本身我们运营的IDE 里面就有一个官方容器，你也可以自定义你的IDE 容器。这个自定义里有非常强的pathon 特别性的环境，你可以去dibug 你的pathon 。然后我们支持计算平台的多个Pathon能力。最后dateworks有非常多的企业化的能力。它不是一个简简单单的IDE，我们还是继承了原来的feature 。

2.AI迭代

基于这些技术的革新，使得我们真正的能够去做到大数据和ai的一体话，使得开发者能在我们的环境里面能够很好的开发来满足ai的迭代。包含以下几个方面。第一是AIfor date提高数据开发的体验。刚刚已经提及了datework copilot。可以通过Naop2SQL可以通过代码补全，各种各样的agend帮助用户快速的开发date 的应用。同时我们也会通过ai的洞察能力，帮客户去做ai的智能的洞察，发现这个数据里面的一些有趣的inset。

四、大数据+AI：Dateworks+PAI

1. 为以数据为中心的模型开发

反过来数据也是for ai的，现在的ai训练已经步入了数据为中心的阶段，高质量的数据远远重于海量的数据。高质量的数据在工作链条上可以帮助算法工程师处理数据。首先在利用dateworks，利用我们的数据引擎的处理能力和通义实验室仪器构建了datejucior的面向大语言的处理系统。里面有非常多的算子，也有非常多的场景能够支持多元太的工具这个工具大大促进了通一实验室进行模型的迭代。因为我们有大量的数据处理工具就在这个集合里面。今年是模型应用的元年。这是关于datehus 的增长图，这是三款datehus项目的都是偏向于已有模型应用的。分别是pronflaw,lanaindex ,longtrain。可以看到其增长十分迅速。也就是说我们现在都希望把大元模型真正用起来，但真正用起来这个基本模型有一个典型的方法叫做资质增强。

真正的资质增强不像大家想的那么简单的一个文档，把这个文档分成tokales，然后把它建立一个下面引进建立向量引擎，再用这个模型去加工成向量引擎，然后来了一个请求后，在这个向量里去查找。把相关的数据拿起来，然后变成一个背景，然后再用大元模型综合这个背景。这个过程看起来是很简单，但是其实也有非常多的数据处理链路。我们的客户会关心数据是否丢失。第二，我的数据是否有张数据，数据格式被分析错误。数据加工链是否有问题。造成结果有问题。客户的数据并不是一成不变的，新增的数据如何更新模型结构。现在综合的时候prop，关于模型的指示是否正确是否合理，有无评估。这所有的过程里面，其实需要大量的数据加工的链条和数据管理的求。正是这个原因其实我们要非常重视datewors和pai这两个序列。在做数据治理的环节，也有同样的问题。我们经常处理客户的数据，因为发布了一个新的概念服务，需要更新我的日志。我们有补数据的流程，可以自动触发补数据，自动进行报表更新。

2. RAG开发流程构建

同样的我们也可以我们的文档在这个流程里面有缺失。那我们可以通过dateworks补数据的流程，自动去trigger我们的整个向量引擎和向量的更新。最后trigger模型服务的更新。在我们有模型的后，我们要部署，然后收集反馈。我们要知道模型到底是不是达到我们预期。那这些evaluate需要在ai的系统里面去去做。做完了之后，我们的那些收集出来的日志又需要回炉到大数据的系统里面去分析去评估。最后整个的这个构成其实也是一个很复杂的数据加工的过程。那我们怎么把它加工成一个比较复杂的一个派paplan，并且是发布成一个生产派的一个状态。所以任何用户有任何数据的大的更新或者其他情况，他都可以非常好的repfresh整个的生产出来的各种各样的物料。整体的过程需要把大数据和ai非常紧密结合。这也是为什么我们一定要去做刚刚说的那些工作使得整个过程能够变得更加顺利，完成构建。

以上是关于新一代dateworks为什么这么做,以及深层次的想法和理解。