Fluid-云原生环境下的数据密集型 应用的高效支撑平台-阿里云开发者社区

开发者社区> 云原生> 正文
登录阅读全文

Fluid-云原生环境下的数据密集型 应用的高效支撑平台

简介: Fluid-云原生环境下的数据密集型 应用的高效支撑平台

内容简要:

(一)项目背景简介

(二)Fluid核心理念

(三)Fluid架构功能

 

 

 

Fluid是在Cool Natives的环境下自由流动,支撑弹性的机器学习和大数据应用,能够更好的访问数据进行数据管理。

(一)项目背景简介

1)技术发展背景

image.png

过去10年IT的发展如火如荼,有非常多的技术,概念层出不穷,在这些概念、技术中,有三样东西应该是最主要的趋势:第一:云计算,第二:大数据,第三:人工智能。

在这些领域中,有非常多开源软件出现,互相竞争,不断迭代,部分软件随着时间的推移,成为了这个领域里面的主流。

在云计算领域的Docker和Kubernetes大约产生于2013年和2014年,到了2020年,根据云上的数据,通过调查5000家公司,发现其中有45%的公司已经开始使用Docker和Kubernetes,成为云计算平台上的一个主流技术方案。

大数据领域Hadoop、Spark、Flink已经成了真正的业界标准。

人工智能领域Tensorflow,已经是工业界使用最主要的一种工具,PyTorch得到了学术界的广泛应用,分别来自谷歌和Facebook。

三者的关系,发现大数据和AI更多的还是在应用层。大数据和AI的应用区别在于,大数据以结构化数据为主,人工智能 AI主要是以非结构化数据为主,他们的数据读取方式,大数据是由冷热数据之分,而AI场景之内都是以全量数据的运算为主。有区别也有相似,相似性是通过巨大的算力访问这些海量的数据。

现在使用多核的CPU,甚至使用GPU进行这种数据处理,是非常敏感型的应用。

云计算平台可以看到,随着Docker和Kubernetes技术,能够提供标准化的应用迭代,提升应用迭代的速度,同时通过计算成本降低规模化部署,提高整个平台的 OAI投入,也成为了大家关注的重要因素。

大数据和AI是在应用层,而像云计算、Docker和Kubernetes,是属于在基础架构层,当良性发展时,三者的融合会成为很重要的趋势。

当大数据和AI都已经发展到一定程度的时候,这三种融合实际上就是如何把大数据和AI等应用运行在云计算的平台上。Gartner预测到2023年70%的 AI的工作负载将以容器化的方式运行和service的方式去构建,而spark3.0一个很重要的趋势,原生的支持communities调度和communities语法。

 

2面临的问题

image.png

实践中,在云原生环境下运行大数据和AI应用,实际上效果并不好,具体分成两个方面,第一运行效率比较低下,以图为例,在英伟达的GPU环境为100GPU环境下,通过本地内存去进行模型训练,发现训练速度是1万张图片每秒。 当用云存储的时候,在计算分存储分离场景下,速度变成原来的1/3,效率急剧下降。

另外一方面,由于在Docker和Kubernetes场景下,对于数据集的管理和考虑比较欠缺,像一些数据多版本多变的问题,数据接口的问题如何去对接。

对于数据类型是几TB的大文件,还是几百兆的小中等文件,甚至是几百k的小文件如何去接受缺乏思考。

底层的存储hdfs safe,各种各样存储如何对接,也是欠缺的,究其原因,实际上是在于云原生环境和数据密集型处理框架之间,它的设计理念是有天然分歧的,本质上是因为出现要解决的问题不一样,所以思考的角度也不同。

 

3问题的原因分析

image.png

在云原生环境下,在计算存储分离是最主要的思考,要考虑降低成本,计算和存储需要单独扩缩容,才能达到成本的最优效果。

在大数据场景下,更多的是数据访问的效率。

第一个矛盾是关于数据是本地化的访问,计算要围绕数据来进行调度,计算存储分离和数据本地化。

第二个矛盾,云原生应用考虑到弹性的扩缩融和自动化的故障恢复,希望应用尽量是一个无状态的应用,这样恢复的速度会非常快。

数据密集型的框架是以数据抽象为中心来进行工作,以Spark为例,核心理念rdd弹性数据集,弹性数据集中有算子,这些算子都是有状态的,通过Dag图进行关联,这里面一旦某个算子出现问题,就有非常大的恢复成本。 它是以数据为核心,有状态的计算这两者也是很明显的差异,同时也发现在cncf云原生全景图中,是缺少针对于数据高效支撑的组件。

 

4云原生环境下的数据支撑挑战

image.png

综上看到有三个最核心的问题;

第一,如何在云原生上面去支撑数据应用,进行计算存储分离,因为计算存储分离会导致数据访问的延时影响计算的效率。

第二,现有的云原生的调度器,是Kubernetes的默认调度器中,对于应用的调度时没有考虑到数据的相关的信息,只把它作为了一个资源调度,而不是应用调度,所以它的调度有效性值得商榷。

第三,混合云场景下的跨存储的联合分析,在云原生环境下很难支撑,但是在大数据场景下,以Alluxio为例,它最擅长的是跨云的以Pattylan为理念的数据运算。

 

5Kubernetes生态中缺失的一块抽象

image.png

Kubernetes架构,它的成功之处在于,对于应用和底层的计算资源做了非常好的抽象,把计算抽象成了一个Pod;把存储抽象了成了PVC;把网络又抽象成了Service,应用有相应的对应的抽象,但其实缺乏于这种对于数据的抽象。云原生整个大图中,对于存储抽象中其实也有一定帮助,像Rook如何解决的是对于Ceph有状态的应用和服务,生命周期如何在Kubernetes的环境下面进行管理,如何去做它的升级。

ChubaoFS是京东和中科大一起开源的软件,解决的是另外一种分布式存储,这个分布式存储如何部署在Kubernetes这个环境下,缺乏的是以应用为中心的数据抽象,及对其的生命周期管理。

 

6商店购物模式演变的联想

image.png

在云原生环境下应用是有弹性的,当应用开始做弹性的时候,如何有相应的数据和它相对应满足lps,这些都需要考虑。 一个主要的初衷,把它和应用弹性相关联,数据的访问和商品的类比有很多的相似之处,把商品超市客户类比成数据存储和应用,商品和数据非常类似,一个核心特点就是消费被使用,而超市和存储是有非常大的类似性,提供两个核心功能:

第一,数据的贮藏,如何把数据存到超市里面。

第二,顾客如何在超市里面购买(即获得这些数据),和应用很类似,通常是在超市里面进行数据消费(即进行商品购买)。

直到2006年出现了电商模式,电商模式最核心的价值,就是它带来了更大的交易量,更加以客户为中心,客户可以选择所需要的任何一种商品。当电商模式出现之后,整个网上的购物方式就发生根本性变化,仓库负责贮藏商品,客户在虚拟的服务商店购买商品,由现代化的物流服务,把商品投递到客户手中。

在现在的云架构环境下,两者非常相识。

数据贮存在云存储系统中,应用部署在计算的集群里面,二者是分离的,但是由于高效的物流系统缺失,导致密集型应用访问这些数据的时候,效率非常低下。

高效的物流体系,对于整个应用的访问非常重要,通过类比可以看到为什么会有电商模式,有两点优势:

第一,支付模式。

第二,高效的物流体系。

对此思考,当我们有更高的IO需求时,也需要云平台上有数据的交付平台,Fluid可以扮演云原生平台下面的数据物流系统这个角色。

 

(二)Fluid的核心理念

Fluid扮演云原生的数据物流系统角色

 回顾整个应用,如何在存储中访问数据场景的变化。最早的时候,当储存在Hadoop场景的时候,是计算和存储相绑定的场景,一个节点,它既提供计算又提供存储,实际是data fetch取数据,应用要被放到存储上,才能够运行。这种方式提供了很好的性能,与此同时,又带来一个巨大的问题,就是成本非常高昂,机器需要非常大的存储,非常多的计算资源和内存。这种方案没有办法持续,第一,成本高;第二,计算和存储虽然是两个不在一起,当计算和存储发生了分离,计算是固定的,他们是一个静态部署,永远都在某个节点上启动。

这个时候就出现了Alluxio,第一,提供应用访问数据的路由机制,相当于可以把不同的协议进行相互转化,提供远程访问的能力。 第二,提供数据缓存的能力,可以把数据缓存到某个节点上,这种在计算存储分离的场景下,如果计算是静态部署,就会有优势,因为热数据持续被访问。

今天,云环境变得更加灵活,第一,资源池化,应用的部署非常的灵活,并不能够固定到某些节点上。第二,弹性伸缩,有时候它属于由波峰波谷,属于削峰、天谷的情况大量存在,这个时候的应用特性,变成了动态的弹性部署。数据交付,开始负责应用的部署和调度,会有应用部署调度的信息,部署到哪些节点上,结合要使用的数据,就可以把数据去交付到更近的节点上。甚至某些场景下,可以先把数据放到节点上,再把应用调度上去,实现数据交付效果。

Fluid核心的想法,希望Fluid扮演云原生下的数据物流的角色,又有了很多变化。

第一,视角的转变:从云原生资源调度结合数据密集处理两方面,综合审视云原生场景的数据抽象与支撑访问;

第二,思路的转变:针对容器编排缺乏数据感知,数据编排缺乏 架构感知,提出协同编排、多维管理、智能感知创新方法;

第三,理念的转变:让数据像流体一样在资源编排层和计 算处理层灵活高效地访问、转换和管理。

在这种操作之下,通过和数据引擎交互,做数据的迁移,让更数据集灵活的在整个Spark环境下进行变化。

最后如何消费数据的应用,因为他也在叫集群调度,需要知道数据相关的信息。获得这之前,我们对数据集进行了编排和部署,知道哪些数据在哪些节点上,当调度应用的时候,就会根据信息来调度应用。

 

(三)Fluid架构功能

1Fluid的系统架构

image.png

如上图所示:Fluid系统架构。从上到下来看,作为客户,用户左边其实要定义两个东西,一个是数据集的通用定义 Runtime,是数据的编排和缓存引擎,这里面主要会支持两个引擎,一个是Alluxio,一个是JindoFLS,这两个引擎能做到的是数据的缓存加速和自动的数据驱逐的工作。

还有两个核心组件在辅助的里面两个核心组件

第一,数据集的编排。

第二,使用数据集的应用的编排,左边是数据集的编排,三个Controller了。第一个是Dataset Controller数据集,负责整个数据集的生命周期,从创建到绑定;第二个是Runtime Controller负责数据集如何在云原生平台下调度,部署需要放到节点上;第三个是Volume controller要和Spark平台对接,需要一个对接的协议,这里会提供一个PVC协议,数据持有券,是spark本地的协议站。

右边这一侧,结合前面进行数据编排的一些相关的信息,可以对于现有的k8s调度器进行扩展,这里有两个Plugin:

第一个Cache co-locality Plugin结合前面的数据调度信息,把应用调度到最合适的节点能够读到缓存;

第二个Prefec Plugin,当你的整个集群里面没有任何缓存存在的情况下,会把应用先调度下去,调度应用的时候,会结合应用需要的数据信息,做智能预取。

第一层是服务的最主要工作。第二层就是k8s标准组件,只要一个标准的k8s就可以把整个的组件和模块运行起来。 最后一层就可以对接各种各样的存储,由于做了Fluid这层抽象,Alluxio支持存储类型和新的知识存储类型,还有他们不支持的存储类型,也可以支持。

 

2)Fluid的功能概念

需要强调的是服务的功能概念是辅助的,Fluid不是全存储加速和管理,而是应用使用的数据集加速和管理

这里面有三个概念:

第一,Dataset: 数据集是逻辑上相关的一组数据的集合,一致的文件特性,会被同一运算引擎使用;

第二,Runtime: 实现数据集安全性,版本管理和数据加速等能力的执行引擎的接口,定义了一系列生命周期的方法;

 第三个AlluxioRuntime: 来自Alluixo社区,是支撑Dataset数据管理和缓存的执行引擎高效实现。

核心的功能,第一:加速;第二:k8s存储对接;第三:数据集隔离

加速的意思,并不是部署了缓存就能得到加速,涉及到三点:

image.png·

第一,能够提供多大的缓存,如缓存量是很小,而且同时你的据访问又不是很规则化,缓存未必是有好的效果的。对于缓存的能力可观测性,首先知道数据特点,然后再知道缓存特点,才能判断缓存是否带来效益;

·第二, Prtable和scalable,通过观测了解到缓存能力是什么样子,涉及到是否要对它进行迁移,是否要换到一些更合适的节点,是否要对它整体换存档来进行扩容,在k8s面,都是一键式的配置;

·第三, Colocality信用在k8s度器里面,让计算和应用更近,对接不同的存储,然后以PVC以k8s能够接受的一种接口,接入到k8s的体系中,在k8s中的name、space作为隔离,来让不同的数据集对于不同的数据科学家有可见性。

举例说明,如下图所示:

image.png


用户在一个场景下,使用来自两个不同地方的数据源,一个数据源是在阿里云上的对象存储OSS,另外一个数据源是数据中心里面搭建的self。场景比较常见,有些数据是脱敏信息,可以在阿里云上用,有些是敏感信息,它可能只能部署在线下的数据中心。

通过编排在API描述对应的就是两个mountPoint,而这两个mountPoint只要定义好之后,通过Fluid就会把它转化成PV/PVC。这样计算可以把k8s里面定义的Pod只要把 PVC挂载下来,可以同时去访问线上的数据。阿里云上面OSS数据和线下数据中心的数据,整个的操作是一个透明的,增加了使用数据的方便性。

image.png

如何对数集进行检查,当把dataset部署下去cache capability,能够提供多少的缓存能力也能看到底层存储、数据集底层存储需要多大的量,在这个例子中底层存储只需要84g,上层缓存能力能提供200g,就不需要再做扩容操作。

当打算做扩容的操作的时候,可以去设置它的 work的数量,可以把4变成3,这样它的缓存的能力就可以在降低。

而整个工具也把它做成了一个直接可以在k8s里面直接去查询,有时候性能不好,是因为缓存的量还不够多,这个时候就可以做对于缓存能力有一个可观测性,根据这种观测性来决定我是否要skill out,还是skill in。

image.png

三个节点中有两个节点是有缓存引擎的,有一个节点是没有缓存引擎,首先kps调度分成两个,一个叫做过滤,一个叫做优选,在过滤的时候,第三个节点就可以把它过滤,因为它没有缓存能力,而前两个节点在优选的时候,会判断谁的缓存能力更大,就先把应用优先部署到哪个节点上。

选择第一个节点,和调度相结合,通过一个demo,如何通过Fluid去加速一个已有k8s的持久化的数据卷,加速一个已有的纳斯的nfs的这种已有的PVC只通过服务的用非常简单的方式使它速度得到极大的提升。

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

分享: