开发者社区> 开发者小助手> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

Vineyard | 开源分布式内存数据管理引擎

简介: 阿里巴巴技术专家迪杰&高级开发工程师临竹在阿里云开发者社区特别栏目《周二开源日》直播中,介绍了Vineyard的设计动因和整体架构,并通过示例展示如何使用Vineyard来共享数据,分享Vineyard结合云原生能力,赋能更大数据应用场景的尝试和愿景。本文为直播内容文字整理,看直播回放,请点击文首链接~
+关注继续查看

查看精彩回放:https://developer.aliyun.com/live/246411

内容简要

一、Vineyard的创建初衷
二、Vineyard的定义及功能
三、Vineyard和云原生结合
四、案例演示
五、Roadmap

一、Vineyard的创建初衷

(一)为什么需要一个分布式内存数据管理引擎?

首先,对于单机数据计算,PyData生态已经成为事实标准,这里数据在不同的Python库间0拷贝的共享非常的简单,因为数据都在一台机器的内存里,彼此间通过传递参数的引用就可以实现。

临时图.png

这里先是声明了一个numpy的array,然后另一个库pytorch可以从这个numpy array构造一个tensor,这个过程是0拷贝。可以看到,如果我们修改了tensor的值,array的值同样被修改了,因为它们指向同一个进程里的同一段内存。

那么,如果对于更复杂的计算场景,我们需要在不同的进程或者运行时之间0拷贝的共享数据呢?
一种方法是使用Apache Arrow的Plasma,它使用进程间内存映射来实现0拷贝,但这还是在单机环境下。

临时图.png

对于我们业务中常见的无法放在一台机器上的大数据,如果还要实现跨系统的0拷贝数据共享,应该如何解决呢?
Vineyard可以提供这种分布式环境下跨系统数据0拷贝共享的能力,进一步,如果和Kubernetes结合的话,还可以产生一种更灵活的计算范式,下面我将逐步展开。

(二)现实生活中的大数据应用

临时图.png

  • 我们先看一个例子,如上所示,一个经典的反作弊工作流大致包含以下四个部分:

1) 购买记录的提取,这里会用到一些分布式的SQL引擎;
2) 从原始数据构造用户商品关系图,并通过标签传播等图算法计算节点风险,所以会引入图计算系统进行处理;
3) 用机器学习的方法,来提升风险检测的精度;
4) 对于得到的高风险用户和商品,进行在线人工处理,这里会用到一些数据可视化的系统。

可以看到,一个经典的大数据应用工作流中,往往会出现多种不同的计算需求,需要用到各种专业性的计算系统来逐一解决,而且往往都会使用一个分布式文件系统,例如HDFS,来解决跨系统数据共享的问题,这也导致每个子任务只有在前序子任务完全结束以后才能被启动。

这就带来如下三个问题:
1) 每个专业性的计算系统想要达到生产可用都非常困难,光是开发各种数据平台数据类型的I/O接口就要花费大量时间;
2) 使用文件系统交换数据带来大量的I/O以及序列化和反序列化开销;
3) 由于工作流被文件系统人为割裂,导致全局性优化方法无法实施。

临时图.png

以图计算为例,由于图计算的复杂性,针对各种场景下的具体问题,这些年从学界和工业界涌现了大量的针对性的图计算系统,但是它们却很少能达到生产可用。
这里面一个主要原因就是光是I/O,分布式部署,容错机制,系统扩展性,以及各类数据源数据格式的接入就需要花费大量的时间和人力。

(三)设计初衷

针对以上三个问题,我们研发Vineyard。

首先,Vineyard不仅为上层应用提供存储,同时采用可扩展设计,为上层系统提供I/O,分块,扩容和容错能力,从而减少上层系统在这些方面的开发工作;
其次,Vineyard采用基于共享内存的0拷贝数据共享,减少I/O和数据拷贝的开销;
最后,Vineyard提供系统间的Stream,提升工作流的整体并行效率。

二、Vineyard的定义及功能

(一)定义

首先,Vineyard管理的是分布式的内存中的不可变数据,也就是说,这些数据被存放在Vineyard以后,一经封存,就不再允许被更改。

这类数据在大数据应用中非常常见,一般来说,在一个大数据工作流中,上一个计算步骤结束后,它要传给下个步骤的数据就固定了,下一个计算系统对它的使用仅仅是读的操作。

其次,这类数据通过Vineyard传递给下一个步骤是0拷贝的,这是通过内存映射实现的。

同时,Vineyard还为这些数据提供开箱即用的高层次抽象,方便计算系统对这些数据的使用,例如Graph图、Tensor张量和DataFrame等等。

这使得上层系统可以像使用本地数据变量一样使用Vineyard上的分布式数据;
最后,Vineyard内建了大量的数据分块,读写,检查的驱动,同时采用可扩展设计,允许新的驱动以即插即用的形式在工作流中动态扩展Vineyard的功能,从而更好的支持上层工作流的开发和计算。

(二)系统架构

临时图.png

Vineyard系统架构图

具体来看,Vineyard的系统架构如上方所示。
首先,Vineyard里的每一个数据对象都包含数据负载和元数据两个部分,其中数据负载保存数据本身。

例如对于一个DataFrame而言,就是每一行每一列实际的值,而元数据包含DataFrame的shape、schema,以及DataFrame在分布式环境中是如何被切分和部署的信息等。这里元数据可以完备的解释数据负载,从而实现数据正确的复用。在Vineyard里,数据负载存储在共享内存中,而元数据通过后端的ETCD在集群上共享。

其次,Vineyard会在集群的每个节点上运行一个守护进程,负责这个节点上的数据负载。数据负载只能被IPC连接获取,并且通过共享内存实现0拷贝的数据共享,而元数据还可以通过RPC连接来获取。
这是因为对于一个经典的并行数据处理场景,我们可以先通过RPC连接访问元数据来获得数据在集群上的分布情况,然后再分布式的启动一系列工作进程,并通过IPC连接来真正获取数据负载并进行处理。
最后,Vineyard以驱动的形式,为其存储的数据对象提供各种内建的和即插即用的功能。

(三)案例说明

临时图.png

上图为一个分布式DataFrame的例子。

首先我们在第一台机器上,通过IPC域套接字连接到Vineyard,如下方所示:

临时图.png

然后我们通过对象ID获得这个分布式DataFrame,我们可以看到,它被分成多块,每个分块是一个单独的DataFrame;
在这里,这个大的分布式DataFrame是Vineyard的一个全局对象,而这个编号为0的分块是一个局部对象;
通常来说,一个Vineyard全局对象,由多个局部对象组成,并且这些局部对象分布在多台机器上。

临时图.png

这里我们可以看到,编号为0的分块存储在第一台机器上,相对于第一台机器,它是本地数据;
相反,编号为1的分块数据存储在第三台机器上,它不是第一台机器的本地数据。

临时图.png

我们继续获取编号为0的分块的数据负载,这里数据通过共享内存映射到当前进程,实现了数据0拷贝的共享。
而编号为1的分块不是本地数据,我们无法获取数据负载,但是可以获取它的元数据。

三、Vineyard和云原生结合

我们已经了解了Vineyard的基本概念,接下来我们来看Vineyard和云原生的结合的情况,以及我们打造的全新的计算范式。

我们会先介绍如何在Kubernetes上部署Vineyard,然后介绍Vineyard如何利用Kubernetes的能力,去实现数据和工作的共同调度,从而产生一种全新的大数据计算范式。

(一)Vision: 大数据任务的云原生范式

临时图.png

如上所示,还是之前的例子,在我们全新的计算范式下,它是这样被部署的:

首先,Vineyard以Daemonset的形式部署在Kubernetes上;

其次,每个步骤的计算系统也被迁移到Kubernetes上,这使得它们获得了动态扩展的能力;

最后,这些系统间以CRD,也就是Kubernetes上Vineyard自定义资源的形式,抽象中间数据。同时,Vineyard会利用Kubernetes的能力,协同部署中间数据和工作进程,确保每个工作进程都能获得它需要的数据,从而实现计算工作流的高效运行。

(二)在Kubernetes上部署Vineyard

目前Vineyard已经可以通过Helm来安装。

同时,Kubernetes上的数据共享是这样实现的:

首先,每个节点上的Vineyard服务Pod和其他工作Pod依然通过IPC连接来实现内存共享。
在Kubernetes环境中,域套接字可以通过被挂载到Pod中的hostPath或者PVC在不同Pod之间共享。
而对于Vineyard服务容器和工作容器被绑定在同一个Pod的情形,可以通过一个emptyDir类型的Volume在两个容器之间共享。

(三)Kubernetes的能力: CRDs

在使用Kubernetes的能力方面,首先Vineyard存储的对象会被抽象为Kubernetes的自定义资源,这个CRD中包含其对应对象的元数据。

同时,如果是局部对象,也就是比如刚刚说到的一个分布式DataFrame的某个分块,还会包含位置信息,也就是这个分块存储在哪个节点上。。

(四)Kubernetes的能力:协同调度数据和工作负载

由于局部对象的CRD中包含位置信息,我们可以利用它来协同调度数据和工作负载:

  1. 在工作负载Pod里描述这个工作需要的Vineyard对象的ID(通常是一个全局对象);
  2. 通过Kubernetes的scheluder-plugin来增强调度器的调度能力,使得当工作Pod被调度时,调度器会先通过CRD查看它需要的Vineyard对象所包含的局部对象的位置信息,从而优先将工作Pod调度到相应的节点上。
  3. 如果因为种种原因,无法调度成功,数据迁移则会被自动触发,从而保证工作Pod总是能够访问到它需要的数据。

四、案例演示

下面,我们通过一个Demo来展示Vineyard如何借助Scheduler Plugin实现数据和工作的协同调度。

临时图.png

这里使用一个简化版本来做Demo,我们会针对作弊交易数据构造一个作弊交易的分类器,在这个Demo里面我们会用Pandas和Mars分别在单机和分布式的情况下来预处理数据,同时用Pytorch训练一个作弊交易的分类器。

临时图.png

好,我们先来看看数据。如上所示,通常情况下Vineyard以及它上面的系统用到的数据都是非常大规模的数据,这里我们用一个小数据来做Demo,否则的话光是加载这个数据就要花费大量的时间。

这里有三张表,分别是用户表、商品表,还有交易表。用户表和商品表主要包含用户和商品的ID,以及它们各自Feature的向量。而这个交易表每一条记录表示一个用户购买一个商品,还有一个标签Frod来标识这条记录是否是一个作弊的交易,同时一些关于这些交易的Feature也都存在这个表里面。

对于这样一个问题,我们在单机的情况下是如何实现的呢?我们看一下 Pandas版本的代码,如下所示。

临时图.png

首先我们会加载数据,用Pandas读这三个文件得到三个DataFrame,然后把这三个DataFrame合并成一个大的Dataset,这里用到了DataFrame的Join,这是第一步。

临时图.png

第二步我们通过Dataset来训练模型,通过Dataset来构造Feature数据和Label数据。

临时图.png

然后使用一个最简单的线性模型来训练分类器,这是单机版本的实现。
如果数据非常大,无法在一台机器上存储的话,那么这个单机版本的代码显然是无法实现这样的功能,因为Pandas甚至都无法去读这样的一个文件,这种情况下我们如何实现呢?
这里我们使用Mars来做第一步DataFrame处理的工作。

临时图.png

Mars是集团开源的一个项目,支持大规模DataFrame的计算。

对于一个Mars中的DataFrame分类,它和Vineyard类似,包含多个分块,并且分布在多台机器上,所以这里可以先用Vineyard将文件读成一个GlobalDataFrame,然后直接加载为Mars的一个DataFrame。

同时Mars支持DataFrame的计算,比如Join操作。Mars通过多台机器上多个分块间的并行计算,实现分布式DataFrame的交易操作。最后,Mars合并的大的DataFrame会以Global DataFrame的形式存进Vineyard。

临时图.png

第二步使用Distributed Pytorch来进行计算。这里Distributed Pytorch要从Vineyard里Log出GlobalDataFrame,这个Distributed Pytorch会起多个工作进程,每个工作进程会得到相应的分块。

首先会建立一个Vineyard Client连接到VINEYARD_IPC_SOCKET,然后获得本地分块的ID,随后Client会拿到这些数据负载,并且把它们合并成一个总的表,并且通过总表和之前一样构建Pytorch Dataset,接下来训练的内容就和刚刚一致了。

临时图.png

上图为实际执行Demo过程。

首先我们有一个干净的Kubernetes环境,接着用Helm安装Vineyard,安装了Vineyard以后得到了两个CRD,一个是全局对象,一个是本地对象。Vineyard在集群上运行是以Demon Set的形式,也就是说每个Log上都有一个Vineyard Pod。

临时图.png

上图为Run Mars,Mars会启动一个集群,然后分布式地做这个计算,得到一个GlobalDataFrame与它的ID。

同样的,在Kubernetes里面有一个和GlobalDataFrame对应的全局对象,这个全局对象包含多个分块,也就是多个局部对象。可以看到全局对象分布在192和193两台机器上,可以登录192查看其中一个分块具体长什么样。

通过Import Vineyard然后建立一个IPC Socket Client,然后选取一个192上面的一个分块来Get。

临时图.png

可以看到我们得到了DataFrame,它是我们刚刚大的DataFrame的一个分块。

临时图.png

我们再试图get一下193上面的分块,可以看到我们无法拿到这个分块,所以如果我们的工作Pod在被调度的时候,没有和数据所在的节点对齐,就会发生无法获取数据的问题。应该如何解决呢?我们看一下Pytorch的Yaml。

临时图.png

在InitContainers里面我们增加了一些内容,它可以确保当数据和工作负载没有被对齐的时候,数据迁移会自动地被触发,下面我们来Run Pytorch。

临时图.png

首先查看全局对象并拿到 ID,然后把ID输入给要Run 的Pytorch。
Pytorch部署到Kubernetes后,可以看到其中两个Pod运行在188和187上,和刚刚的192、193没有对齐,那么这里会发生什么呢?我们看一下worker-0的Log,可以看到数据被自动地迁移了,但是数据迁移的过程是很花费时间的。

临时图.png

这里由于数据迁移,我们会产生重复的局部对象,比如31a也被复制了,它从193被复制到了188,从而我们的Worker可以使用它。

可以看到,数据迁移的过程不仅会花费时间,而且还会浪费内存,所以我们应该想办法去尽量减少这种数据迁移的发生,这也就是为什么我们要用Scheduler Plugin来增强Kubernetes的调度能力,从而减少这种数据迁移的发生。

下面把环境清理一下,重新Run以上过程,不过这一次会使用Scheduler Plugin。

临时图.png

重新安装Vineyard,重新再执行一遍Mars,又得到了一个GlobalDataFrame,那么我们接下来检查一下,全局对象所包含的局部对象在我们集群中的位置。

临时图.png

可以看到,它依然是在192和193这两台机器上,接下来要安装Scheduler Plugin。

临时图.png

Scheduler Plugin会根据工作负载所需要的Vineyard对象的位置来调度这个工作的Pod。后面会通过观察Scheduler Plugin的Log来查看这个过程。

临时图.png

再次打开Pytorch的Yaml,可以看到我们把需要的Vineyard对象的ID写在了这里,Scheduler Plugin可以通过读取这个Spec来知道工作负载是需要哪一个Vineyard对象。

临时图.png

我们运行Pytorch拿到 ID,Set Scheduler Plugin,可以看到两个Pod已经运行在192和193上面,接着我们去看一下Scheduler Plugin的Log,可以看到Scheduler Plugin给193和192两台机器打了最高分。回到Worker-0的Log,可以看到没有数据迁移发生,也没有重复的局部对象被创建,是因为没有进行任何的数据迁移。

在这里我们通过Scheduler Plugin成功地将数据和工作负载对齐,进行协同地调度,从而实现了高效的并行计算。
以上是Vineyard利用Scheduler Plugin实现协同调度的Demo,这为我们打造基于Vineyard和Kubernetes的高效且灵活的大数据计算范式,打开了一扇大门。

五、Roadmap

(一)项目状态

目前,Vineyard在GitHub已经收获375颗星,同时有6位同事在维护这个项目,我们期待获得来自社区的更多的支持,也希望有社区成员可以逐步成为Vineyard的维护者。

(二)Roadmap

  • 当前:

1) 通过Github Actions构建和测试;
2) 支持各种数据类型,如数组、图形,并支持多种计算引擎,如pytorch, mars, GraphScope;
3) 在DockerHub和Quay上释放;
4) 与Helm进行集成。

  • 未来:

1) Vineyard Operator for Kubernetes;
2) 性能改进;
3) 更多语言SDK,如Java, Go等;
4) 存储层次结构;
5) Scheduler-plugin:Fluid
在未来的规划中,我们首先会在Kubernetes上做功能性更强的Vineyard Operator,比如检查点,容错等。此外,我们还会和集团的Fluid合作,进一步优化调度能力。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
JVM00_面试官对类加载器子系统、运行时数据区、内存分布、执行引擎的灵虚拷问,你能坚持到第几问?(二)
⑧. 判定一个常量是否"废弃”还是相对简单,而要判定一个类型是否属于"不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件 ⑨. 说说类的加载器分类? ⑩. 说说你对引导类加载器、扩展类加载器和应用程序类加载器的理解 ⑩①. 谈谈你对双亲委派机制的理解
35 0
JVM00_面试官对类加载器子系统、运行时数据区、内存分布、执行引擎的灵虚拷问,你能坚持到第几问?(七)
③⑥. 谈谈你对操作数栈的理解? ③⑦. 说说你对动态链接的理解? ③⑧. 方法返回地址? ③⑨. 附加信息(了解) ④0. 调整栈大小,就能保证不出现溢出吗? ④①. 分配的栈内存越大越好吗?
24 0
Libgdx仿安卓R文件通过Id访问资源
博客已迁移:更多精彩内容尽在AyoCrazy.com 在Libgdx开发过程中,对资源的引用是直接通过一个资源路径的字符串来获取的,这给我们开发过程中造成了很大的不便。例如我们修改了某个资源文件的路径后,编译器并不会报错,但是运行的时候却提示找不到这个文件,因为编译器无法判断这个资源路径是否为有效路径,这个时候我们需要手动去修改这个路径字符串,如果是一
1267 0
1915
文章
368
问答
来源圈子
更多
阿里巴巴相信开源的世界里人人贡献代码,人人获得收益,共同创造一个互帮互利的社区,促进技术进步和发展。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载