内容简要：
（一）项目背景简介
（二）Fluid核心理念
（三）Fluid架构功能
Fluid是在Cool Natives的环境下自由流动，支撑弹性的机器学习和大数据应用，能够更好的访问数据进行数据管理。
（一）项目背景简介
1）技术发展背景
过去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）面临的问题
实践中,在云原生环境下运行大数据和AI应用，实际上效果并不好，具体分成两个方面，第一运行效率比较低下，以图为例，在英伟达的GPU环境为100GPU环境下，通过本地内存去进行模型训练，发现训练速度是1万张图片每秒。 当用云存储的时候，在计算分存储分离场景下，速度变成原来的1/3，效率急剧下降。
另外一方面，由于在Docker和Kubernetes场景下，对于数据集的管理和考虑比较欠缺，像一些数据多版本多变的问题，数据接口的问题如何去对接。
对于数据类型是几TB的大文件，还是几百兆的小中等文件，甚至是几百k的小文件如何去接受缺乏思考。
底层的存储hdfs safe，各种各样存储如何对接，也是欠缺的，究其原因，实际上是在于云原生环境和数据密集型处理框架之间，它的设计理念是有天然分歧的，本质上是因为出现要解决的问题不一样，所以思考的角度也不同。
3）问题的原因分析
在云原生环境下，在计算存储分离是最主要的思考，要考虑降低成本，计算和存储需要单独扩缩容，才能达到成本的最优效果。
在大数据场景下，更多的是数据访问的效率。
第一个矛盾是关于数据是本地化的访问，计算要围绕数据来进行调度，计算存储分离和数据本地化。
第二个矛盾，云原生应用考虑到弹性的扩缩融和自动化的故障恢复，希望应用尽量是一个无状态的应用，这样恢复的速度会非常快。
数据密集型的框架是以数据抽象为中心来进行工作，以Spark为例，核心理念rdd弹性数据集，弹性数据集中有算子，这些算子都是有状态的，通过Dag图进行关联，这里面一旦某个算子出现问题，就有非常大的恢复成本。 它是以数据为核心，有状态的计算这两者也是很明显的差异，同时也发现在cncf云原生全景图中，是缺少针对于数据高效支撑的组件。
4）云原生环境下的数据支撑挑战
综上看到有三个最核心的问题;
第一，如何在云原生上面去支撑数据应用，进行计算存储分离，因为计算存储分离会导致数据访问的延时影响计算的效率。
第二，现有的云原生的调度器，是Kubernetes的默认调度器中，对于应用的调度时没有考虑到数据的相关的信息，只把它作为了一个资源调度，而不是应用调度，所以它的调度有效性值得商榷。
第三，混合云场景下的跨存储的联合分析，在云原生环境下很难支撑，但是在大数据场景下，以Alluxio为例，它最擅长的是跨云的以Pattylan为理念的数据运算。
5）Kubernetes生态中缺失的一块抽象
Kubernetes架构，它的成功之处在于，对于应用和底层的计算资源做了非常好的抽象,把计算抽象成了一个Pod;把存储抽象了成了PVC;把网络又抽象成了Service，应用有相应的对应的抽象，但其实缺乏于这种对于数据的抽象。云原生整个大图中，对于存储抽象中其实也有一定帮助，像Rook如何解决的是对于Ceph有状态的应用和服务，生命周期如何在Kubernetes的环境下面进行管理，如何去做它的升级。
ChubaoFS是京东和中科大一起开源的软件，解决的是另外一种分布式存储，这个分布式存储如何部署在Kubernetes这个环境下，缺乏的是以应用为中心的数据抽象，及对其的生命周期管理。
6）商店购物模式演变的联想
在云原生环境下应用是有弹性的，当应用开始做弹性的时候，如何有相应的数据和它相对应满足lps，这些都需要考虑。 一个主要的初衷，把它和应用弹性相关联,数据的访问和商品的类比有很多的相似之处，把商品超市客户类比成数据存储和应用，商品和数据非常类似，一个核心特点就是消费被使用，而超市和存储是有非常大的类似性，提供两个核心功能:
第一，数据的贮藏，如何把数据存到超市里面。
第二，顾客如何在超市里面购买（即获得这些数据），和应用很类似，通常是在超市里面进行数据消费（即进行商品购买）。
直到2006年出现了电商模式,电商模式最核心的价值，就是它带来了更大的交易量，更加以客户为中心，客户可以选择所需要的任何一种商品。当电商模式出现之后，整个网上的购物方式就发生根本性变化，仓库负责贮藏商品，客户在虚拟的服务商店购买商品，由现代化的物流服务，把商品投递到客户手中。
在现在的云架构环境下，两者非常相识。
数据贮存在云存储系统中，应用部署在计算的集群里面，二者是分离的，但是由于高效的物流系统缺失，导致密集型应用访问这些数据的时候，效率非常低下。
高效的物流体系，对于整个应用的访问非常重要，通过类比可以看到为什么会有电商模式，有两点优势：
第一，支付模式。
第二，高效的物流体系。
对此思考，当我们有更高的IO需求时，也需要云平台上有数据的交付平台，Fluid可以扮演云原生平台下面的数据物流系统这个角色。
（二）Fluid的核心理念
Fluid扮演云原生的数据物流系统角色
回顾整个应用，如何在存储中访问数据场景的变化。最早的时候，当储存在Hadoop场景的时候，是计算和存储相绑定的场景，一个节点，它既提供计算又提供存储，实际是datafetch取数据，应用要被放到存储上，才能够运行。这种方式提供了很好的性能，与此同时，又带来一个巨大的问题，就是成本非常高昂，机器需要非常大的存储，非常多的计算资源和内存。这种方案没有办法持续，第一，成本高；第二，计算和存储虽然是两个不在一起，当计算和存储发生了分离，计算是固定的，他们是一个静态部署，永远都在某个节点上启动。
这个时候就出现了Alluxio，第一，提供应用访问数据的路由机制，相当于可以把不同的协议进行相互转化，提供远程访问的能力。 第二，提供数据缓存的能力，可以把数据缓存到某个节点上，这种在计算存储分离的场景下，如果计算是静态部署，就会有优势，因为热数据持续被访问。
今天，云环境变得更加灵活，第一，资源池化，应用的部署非常的灵活，并不能够固定到某些节点上。第二，弹性伸缩，有时候它属于由波峰波谷，属于削峰、天谷的情况大量存在，这个时候的应用特性，变成了动态的弹性部署。数据交付，开始负责应用的部署和调度，会有应用部署调度的信息，部署到哪些节点上，结合要使用的数据，就可以把数据去交付到更近的节点上。甚至某些场景下，可以先把数据放到节点上，再把应用调度上去，实现数据交付效果。
Fluid核心的想法，希望Fluid扮演云原生下的数据物流的角色，又有了很多变化。
第一，视角的转变：从云原生资源调度结合数据密集处理两方面，综合审视云原生场景的数据抽象与支撑访问；
第二，思路的转变：针对容器编排缺乏数据感知，数据编排缺乏 架构感知，提出协同编排、多维管理、智能感知创新方法；
第三，理念的转变：让数据像流体一样在资源编排层和计 算处理层灵活高效地访问、转换和管理。
在这种操作之下，通过和数据引擎交互，做数据的迁移，让更数据集灵活的在整个Spark环境下进行变化。
最后如何消费数据的应用，因为他也在叫集群调度，需要知道数据相关的信息。获得这之前，我们对数据集进行了编排和部署，知道哪些数据在哪些节点上，当调度应用的时候，就会根据信息来调度应用。
（三）Fluid架构功能
1）Fluid的系统架构
如上图所示：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存储对接；第三：数据集隔离。
加速的意思，并不是部署了缓存就能得到加速，涉及到三点：
·
第一，能够提供多大的缓存，如缓存量是很小，而且同时你的据访问又不是很规则化，缓存未必是有好的效果的。对于缓存的能力可观测性，首先知道数据特点，然后再知道缓存特点，才能判断缓存是否带来效益；
·第二， Prtable和scalable，通过观测了解到缓存能力是什么样子，涉及到是否要对它进行迁移，是否要换到一些更合适的节点，是否要对它整体换存档来进行扩容，在k8s面，都是一键式的配置；
·第三， Colocality信用在k8s度器里面，让计算和应用更近，对接不同的存储，然后以PVC以k8s能够接受的一种接口，接入到k8s的体系中，在k8s中的name、space作为隔离，来让不同的数据集对于不同的数据科学家有可见性。
举例说明，如下图所示：
用户在一个场景下，使用来自两个不同地方的数据源，一个数据源是在阿里云上的对象存储OSS，另外一个数据源是数据中心里面搭建的self。场景比较常见，有些数据是脱敏信息，可以在阿里云上用，有些是敏感信息，它可能只能部署在线下的数据中心。
通过编排在API描述对应的就是两个mountPoint，而这两个mountPoint只要定义好之后，通过Fluid就会把它转化成PV/PVC。这样计算可以把k8s里面定义的Pod只要把 PVC挂载下来，可以同时去访问线上的数据。阿里云上面OSS数据和线下数据中心的数据，整个的操作是一个透明的，增加了使用数据的方便性。
如何对数集进行检查，当把dataset部署下去cache capability，能够提供多少的缓存能力也能看到底层存储、数据集底层存储需要多大的量，在这个例子中底层存储只需要84g，上层缓存能力能提供200g，就不需要再做扩容操作。
当打算做扩容的操作的时候，可以去设置它的 work的数量，可以把4变成3，这样它的缓存的能力就可以在降低。
而整个工具也把它做成了一个直接可以在k8s里面直接去查询，有时候性能不好，是因为缓存的量还不够多，这个时候就可以做对于缓存能力有一个可观测性，根据这种观测性来决定我是否要skill out，还是skill in。
三个节点中有两个节点是有缓存引擎的，有一个节点是没有缓存引擎，首先kps调度分成两个，一个叫做过滤，一个叫做优选，在过滤的时候，第三个节点就可以把它过滤，因为它没有缓存能力，而前两个节点在优选的时候，会判断谁的缓存能力更大，就先把应用优先部署到哪个节点上。
选择第一个节点，和调度相结合，通过一个demo，如何通过Fluid去加速一个已有k8s的持久化的数据卷，加速一个已有的纳斯的nfs的这种已有的PVC只通过服务的用非常简单的方式使它速度得到极大的提升。
