Fluid — 云原生环境下的高效“数据物流体系”

作者 | 顾荣南京大学 PASALab

得益于核算本钱低、易于扩展、布置快捷、运维高效等多方面的优势，云核算渠道招引了越来越多的数据密布型运用在上面运转。现在，以 Kubernetes 为代表的云原生架构，因其灵敏的资源可负载性以及高效的运用编列调度，在许多AI/大数据等数据密布型场景中运用广泛。可是，云原生环境和数据密布运用核算结构在新近规划理念和机制上存在天然不合。因而，怎么协助数据密布型运用在云原生场景下高效、安全、快捷地拜访数据，是一个既有理论含义又具运用价值的重要问题。

为了处理大数据、AI 等数据密布型运用在云原生核算存储别离场景下，存在的数据拜访延时高、联合剖析难、多维办理杂等痛点问题，南京大学 PASALab、阿里巴巴、Alluxio 在 2020 年 9 月份联合发起了开源项目 Fluid。Fluid 本质上是一个云原生环境下的数据密布型运用的高效支撑渠道。本文将向咱们介绍 Fluid 项目是怎么将数据密布型运用更高效地运转于 K8s 环境中的。

项目布景简介

1. 技能展开布景

曩昔十年云核算、大数据、人工智能等技能展开日新月异。

云核算渠道范畴

：以 Docker、Kubernetes 为代表的容器及其编列的云原生技能，在运用服务布置主动化运维的浪潮傍边得到了长足的展开。

大数据处理范畴

：以 Hadoop、Spark、Alluxio 为代表的大数据并行核算与分布式存储技能，在许多职业范畴大数据处理与存储的运用落地中简直构成了干流生态。

人工智能结构范畴

：PyTorch、Tensorflow、Caffe 等闻名 AI 练习结构，在广阔 AI 运用开发者重复运用和参加傍边，展开日益老练。

其间，大数据运用和 AI 运用一般需求环绕大规划数据打开核算剖析，是典型的数据密布型运用，而云核算渠道得益于其核算本钱和易于规划扩展的优势，以及容器化在高效布置和灵敏迭代方面的利益，招引了越来越多的数据密布型运用在上面布置运转。

大数据运用、AI、云核算三者的交融正在成为下一个重要的展开趋势。Gartner 猜测，到 2023 年，70% 以上的 AI workloads 都将以运用容器化的办法布置运转，然后经过 Serverless 编程模型在云原生环境下进行构建。Spark 3.0.1 版别也开端支撑 Kubernetes scheduler，拥抱云原生环境。

概况见 Gartner 陈述：

https://www.gartner.com/en/conferences/emea/data-analytics-switzerland/featured-topics/topic-ai-machine-learning

Spark3.0.1 runs on K8s：

https://spark.apache.org/docs/latest/running-on-kubernetes.html

2. 面临的问题

从用户的实践体会来看，现有云原生编列结构对数据密布型运用支撑不行友爱，首要表现在运转功率低下和数据办理杂乱两方面。

运转功率低下

：如上图所示，练习一个 RestNet50 神经网络，假如根据本地内存运转，大约每秒钟能练习近 1 万张图片；可是，在云原生环境下运转，根据 Cloud Storage 存储架构每秒练习的图片只能到达约 3000 张/秒，功用下降比较显着。

数据办理杂乱

：数据版别的多变、数据接口的多样、数据类型的笼统以及数据存储的异构，都给云原生环境下面向数据密布型运用支撑带来了应战。

3. 问题的原因剖析

云原生环境和数据密布处理结构在规划理念和机制上存在天然不合，这两部分技能的新近发生和展开进程是彼此独立的。咱们能够看到，为了统筹资源扩展的灵敏性和运用本钱，核算和存储别离数据本地化架构，两者在规划上存在不合。

别的，咱们发现在云原生环境中，运用一般是以无状况（stateless）微服务化的办法进行布置，经过 FaaS（Function as a Service）办法串联。而在数据密布型结构运用中，是以数据笼统为中心展开，并进行任务分配履行，比如在 Spark 里都是环绕 RDD 构建整个大数据处理运用，中心加上算子。可是，无状况微服务并不是以数据为中心，这也存在规划上的不合。

以上问题导致以 Kubernetes 为代表的云原生编列结构关于数据密布型运用，尤其是 AI 和大数据运用的支撑还不行友爱，详细表现在前面所述的运转功率低下、数据操作办理杂乱等方面。

咱们纵观 Fluid 呈现之前的云原生基金会（CNCF）全景图，涵盖了从运用交给 - 运维办理 - 底层存储的方方面面，可是短少数据高效支撑组件这块重要拼图（注：Fluid近期刚进入CNCF 全景图，旁边面反映本文理念得到了认可）。可是，这块拼图的缺失，就会构成大数据密布型运用在云原生环境下运转时，面临数据拜访低效、数据阻隔性弱、多数据源联合拜访杂乱方面的技能应战。

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

详细地，云原生环境下数据支撑的应战首要分为三个方面

：

榜首：云渠道核算存储别离架构导致数据拜访延时高。为了监控资源灵敏性满足本地无依靠的要求，云原生运用大多选用核算存储别离架构。可是从拜访功率的视点来看，要求用云网络传输带宽，当数据密布型运用在云上运转时，会构成数据拜访瓶颈、功用下降。

第二：混合云场景下跨存储体系的联合剖析困难。大多公司/安排一般根据不同存储办理数据支撑多样化运用，具有其各自的特色。Ceph、GlusterFS、HDFS 都会被广泛运用，数据也一般会散落在这些异构存储傍边。可是，当需求联合数据进行归纳性剖析时，会添加数据移动本钱，必定导致在云原生环境下需求面临网络费用、等候延时、人工操作等比较杂乱的问题。

第三：云环境中数据安全办理与多维度办理杂乱。数据是许多公司的生命线，数据走漏、误操作、生命周期办理不妥都会构成巨大损失。怎么在云原生环境中保证数据的阻隔，保护好用户的数据生命周期，都存在较大应战。

5. Kubernetes 生态中缺失的一块笼统

综上所述，咱们能够总结出一种现象：
Kubernetes 生态中现在短少数据密布型运用高效支撑的这块拼图。
现有 Kubernetes 环境能对许多资源进行很好的笼统，包含将资源目标核算笼统成 Pod、将存储笼统成了 PV/PVC、将网络笼统成了 Service。
云原生范畴还有一些存储笼统首要面向数据耐久化进行作业，供给目标和文件的耐久化存储办理。
但这些软件的功用缺少以运用为中心的数据笼统及相关生命周期办理。

6. 商铺购物形式演化的联想

为了更好地了解这些问题，咱们能够做一些联想性的考虑。如下图所示，引进产品购物形式，咱们将产品、超市、客户类比为数据、存储、运用。

产品

和数据都会被消费，产品会被顾客购买掉，数据会被运用读走，两者有必定相似性。

超市

和存储相似，都起到储藏与供给的功用。产品平常会储藏在超市的货架上，当购买时扮演到供给的人物；关于存储而言，咱们平常储藏的数据都会被耐久化到存储设备里，当运用需求时供给给用户。

客户

和运用相似，客户会到商铺消费购买产品。相似的，运用会到存储读取数据。

产品、超市（商铺）、客

户形式，在曩昔几千年里展开得十分老练，十分安稳。直到 2000 年之后发生了颠覆性的改变，这便是电商的发生。电商发明晰线上购物形式，其特色表现在不再以店肆为中心而是以客户为中心，产品储藏在库房，客户能够在线上虚拟商铺挑选产品，最后由现代化物流将产品交给到客户，买卖进程高效快捷、买卖量更大。产品直接放在库房里，库房能够进行规范化、独立化办理，之后客户到电商渠道上购买货品，会十分快捷、便利。客户不需求到店肆，在地铁上、车上、办公室、家里都能够用手机、电脑进行购物，而且不会存在产品寻觅低效的状况，因为客户是在互联网上购物，都能够经过检索办法查找海量产品；线上购物的另一个优势是买卖频次变得更高，买卖量变得更大；客户也不需求有必要去店里提货，快递能够直接送货上门，十分便利。

电商形式的成功有许多要素，其间有两大要素十分要害，一是如付出宝这样的第三方数字化付出东西的呈现，二是如菜鸟这样专业化的物流体系发生，构建起畅通无阻的物流网络，使快速的产品寄送形式得以完结。反观回到现在核算机体系中，在现代云架构下，数据贮存在云存储体系中，数据密布型运用也以pod等各式各样资源描绘符的办法在云原生环境下运转，但中心却缺少一个高效的数据交给、数据投递的办法。也便是说，在云原生架构下面，数据储藏在云存储体系傍边，运用仍是根据需求去拜访数据，但因为相似的数据“物流体系”的缺失，导致数据密布型运用消费拜访数据在云渠道上比较低效。

Fluid 中心理念

根据以上的剖析，以及从调查中得到的联想，下面来介绍 Fluid 的中心理念。

1. Fluid 扮演云原生的“数据物流体系”人物

跟着大数据生态体系的迅速展开，其上的运用结构变得越来越多，底层存储体系也变得越来越丰厚，各种上层运用要拜访不同品种、多样化体系的痛点越来越显着，所以呈现了 Alluxio 这样一个优异的开源项目，来一致办理底层不同存储体系，为上层供给一致化的规范接口，对上层运用屏蔽不同存储的差异。而且 Alluxio 供给内存缓存，加快数据拜访。这个进程就解耦了本地化的状况，存储就能够完结别离。这种别离架构在布置好之后一般仍是静态的，完结从 Data Fetch 变成 Data Access 的进程。

Fluid 是在 Alluxio 根底之上，在云原生环境的调度层面进步跋涉一步的研讨和拓宽，期望获取云原生环境下数据节点以及运用的动态改变信息，让这一类静态的缓存等中心件动态、灵敏地调集起来，然后让运用灵敏性变得更强，完结数据智能化投递到运用的作用，即动态弹性（Data Delivery）。

在进行项目规划时，咱们期望 Fluid 从视角、思路、理念三个层次带来一些改造：

新视角

：从云原生资源调度结合与数据密布型处理两个方面，从头归纳审视云原生场景的数据笼统与支撑拜访。

新思路

：针对容器编列缺少数据感知，数据编列缺少对云上架构改变的感知，提出了协同编列、多维办理、智能感知的一系列理念和立异办法；然后构成一套云原生环境下数据密布型运用的高效支撑渠道。

新理念

：经过 Fluid 这个项目，期望让数据能够像流体相同在云渠道中、在资源编列层和数据处理层之间能够灵敏高效地被拜访、转化和办理。

2. 中心理念

简略来说，Fluid 的中心理念，能够分为“一个笼统”和“两个编列”。

首先在云原生环境里，笼统出了数据集的概念，它能够供给一个对底层存储的包装，对上层也能供给各式各样的支撑和拜访才能，然后经过 API 的办法来简略地在 K8s 下完结对数据的操作。

在这个根底之上，Fluid 供给了两个编列的才能：

首先是关于数据集进行编列，详细是指根据容器调度办理的数据进行编列。传统的办法只对数据自身进行办理，而 Fluid 的数据集编列则转为对承载数据的引擎进行编列和办理。经过对数据引擎进行合理的扩容、缩容和调度操作，和数据引擎的交互，然后完结对数据的搬迁、缓存以及数据在 K8s 渠道下灵敏调度的办理和改变。

第二个编列是对运用和消费这类数据集的运用进行编列。咱们需求处理这些运用的调度，在调度时尽量使其感知缓存数据集，这样就能够在这调度运用的时分合理挑选节点，然后高效地进行相关核算。

总结来讲，Fluid 具有以下三大功用：

1）供给云渠道数据集笼统的原生支撑

数据密布型运用所需根底支撑才能功用化，完结数据高效拜访并下降多维本钱。

2）根据容器调度办理的数据集编列

经过数据集缓存引擎与 Kubernetes 容器调度和扩缩容才能的彼此配合，完结数据集可搬迁性。

3）面向云上数据本地化的运用调度

Kubernetes 调度器经过与缓存引擎交互取得节点的数据缓存信息，将运用该数据的运用以通明的办法调度到包含数据缓存的节点，最大化缓存本地性的优势。

Fluid 架构功用

1. Fluid 体系架构

Fluid 是构建在 K8s 上的体系，对原生 K8s 具有杰出的兼容性，无需修正恣意代码。如上图所示，用户需求界说两个 CRD，分别是 Dataset 和 Runtime。Dataset 是数据集的通用界说，这是咱们供给的 K8s 资源目标，需求写 YAML 文件来界说数据集从哪儿来，以及想要放到哪儿去；Runtime 是存储这些数据集的缓存引擎，现在运用的是开源的分布式缓存体系 Alluxio。这儿要注意的是 Dataset 和 Runtime 界说的时分，它一般是要具有相同 Namespace，然后完结很好的绑定。

Fluid Operator 是 Fluid 项意图中心，它分为两部分。榜首部分是 Fluid-controller-manager，包含许多 Controller；另一部分为 Fluid-Scheduler。这两个组件完结了编列调度的操作。Fluid-controller-manager 做的作业便是对数据进行编列，包含三个 Controller。这三个 Controller 从逻辑上它们是独立的，能够去做单进程。但为了下降杂乱性，许多 Controller 的功用编译时被合并成一个和多个可履行文件，所以在真实运转起来时，也是一个进程。

数据集的 Dataset Controller 担任整个数据集的生命周期办理，包含数据集的创立，以及要和哪个 Runtime 进行绑定。

Runtime Controller 担任数据集怎么在云原生渠道上被调度与缓存，应该放在哪些节点上，要有多少副本。

Volume Controller：因为 Fluid 是根据 K8s 运转，因而需求和 K8s 进行对接，这儿咱们运用的是 PVC（数据耐久卷）协议，这是 K8s 本地存储栈的协议，运用十分广泛，Fluid 与 PVC 的对接十分流通。

最下面为 Cache Runtime Engine，是真实完结缓存数据详细作业的当地。

图中右边部分的 Fluid-Scheduler 首要是根据界说好的 dataset、runtime controller 等详细信息，对 K8s 的调度器做一些扩展。这儿面包含两个 Plugin：

Cache co-locality Plugin：Cache co-locality Plugin 做的事便是结合前面数据编列的信息，把运用调度到最合适的节点上，然后尽量能够让用户去读到缓存节点里边的信息。

再往下便是规范 K8s。经过 K8s 能够对接底层不同的存储，详细的对接办法可经过 K8s 的 PVC 完结。因为经过 Alluxio 进行了笼统，能够直接支撑 Alluxio 自身支撑的存储类型。

2. Fluid 的功用概念

Fluid 不是全存储加快和办理，而是以运用为中心数据集加快和办理。

三个重要概念

：

Dataset：数据集是逻辑上相关的一组数据的调集，不同数据集的特性和优化都是不相同的，所以关于数据集是要分隔办理的，共同的文件特性，会被同一运算引擎运用。

Runtime：真实完结数据集安全性，版别办理和数据加快等才能的履行引擎的接口，包含怎么创立、生命周期怎么办理等等，界说了一系列生命周期的办法。

AlluxioRuntime：来自 Alluxio 社区，是支撑 Dataset 数据办理和缓存的履行引擎高效完结。

经过以上概念与架构，完结了以下功用：

1）加快

Observation: know the cache capacity easily.

Portableand Scalable: adjust the cache capacity on demand.

Co-locality: bring data close to compute, and bring compute close to data.

经过 K8s 供给了这个很好的可观测性，咱们能够知道咱们的缓存容量和当时状况，进一步地咱们就能够很灵敏的去搬迁和扩展缓存，然后按需添加缓存容量。而且在扩展和搬迁进程傍边会充分考虑 co-locality，即本地性。将数据和核算在编列和调度时放在一同，然后完结加快意图。

2）数据卷接口，一致拜访不同存储

从对接上面，支撑数据卷接口，然后一致拜访不同的存储，且 K8s 的任何数据卷都能够包装成 Fluid-Dataset 来进行运用加快。

3）阻隔

阻隔机制使得对数据集的拜访能够在不同存储加快间进行阻隔，而且完结权限操控办理。

3. 怎么运用 Fluid

以上图为例，用户在运用场景中需求运用来自两个不同当地的数据，假定一个来自阿里云，别的一个是本地存储 Ceph。在 Fluid 里边咱们能够很容易地描绘这样的数据集，经过创立一个自界说 K8s 资源目标 Dataset，对应的 mountPoint 能够加载两个，分别是阿里云和 Ceph。

创立好就能够运转，这个进程中 Fluid 会创立一个 Dataset，并主动将它变成一个 PVC。当用户需求用这个数据时创立一个 Pod，以 PVC 挂载的办法，将 Dataset 相关到运转中的 Pod 中对数据进行拜访。乃至 Pod 底子都不知道 PVC 后台运转的是 Fluid，而不是其他的存储，例如 NFS。整个进程和背面的原理对用户都是通明的，这使得对留传程序的对接十分友爱。

4. 怎么查看和观测 dataset 状况

当真实运转起来时有许多可观测的东西，咱们在 Dataset CRD 里界说了许多 metrics。如上图所以，缓存总容量为 200GB，实践需求的容量为 84.29GB，无需扩容，后续可根据实践需求灵敏扩容。经过这个东西，用户能够有用查询存储容量与运用量，然后完结可观测性。

本文来自网络，不代表快递资讯网立场。转载请注明出处： http://www.llaiot.com/express-industry-information/2354.html

标签:Fluid — 云原生环境下的高效“数据物流体系”