乐趣区

关于云原生:Fluid-云原生环境下的高效数据物流系统

jiezi

简介： 为了解决大数据、AI 等数据密集型利用在云原生计算存储拆散场景下，存在的数据拜访延时高、联结剖析难、多维治理杂等痛点问题，南京大学 PASALab、阿里巴巴、Alluxio 在 2020 年 9 月份联结发动了开源我的项目 Fluid。Fluid 实质上是一个云原生环境下的数据密集型利用的高效撑持平台。本文将向大家介绍 Fluid 我的项目是如何将数据密集型利用更高效地运行于 K8s 环境中的。

作者 | 顾荣  南京大学 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

  1. 面临的问题

从用户的理论体验来看，现有云原生编排框架对数据密集型利用反对不够敌对，次要体现在运行效率低下和数据管理简单两方面。

运行效率低下：如上图所示，训练一个 RestNet50 神经网络，如果基于本地内存运行，大略每秒钟能训练近 1 万张图片；然而，在云原生环境下运行，基于 Cloud Storage 存储架构每秒训练的图片只能达到约 3000 张 / 秒，性能降落比拟显著。

数据管理简单 ： 数据版本的多变、数据接口的多样、数据类型的形象以及数据存储的异构，都给云原生环境上面向数据密集型利用撑持带来了挑战。

  1. 问题的起因剖析

云原生环境和数据密集解决框架在设计理念和机制上存在人造一致，这两局部技术的新近产生和倒退过程是互相独立的。咱们能够看到，为了兼顾资源扩大的灵活性和应用老本，计算和存储拆散 的根本架构在云原生环境中大行其道；反观之，以大数据!

2.jpg

和 AI 训练为代表的数据密集型利用框架，为了缩小数据传输，设计理念更多须要思考 数据本地化架构，两者在设计上存在一致。

另外，咱们发现在云原生环境中，利用通常是以无状态（stateless）微服务化的形式进行部署，通过 FaaS（Function as a Service）形式串联。而在数据密集型框架利用中，是以数据抽象为核心发展，并进行任务分配执行，比方在 Spark 里都是围绕 RDD 构建整个大数据处理利用，两头加上算子。然而，无状态微服务并不是以数据为核心，这也存在设计上的一致。

以上问题导致以 Kubernetes 为代表的云原生编排框架对于数据密集型利用，尤其是 AI 和大数据利用的反对还不够敌对，具体体现在后面所述的运行效率低下、数据操作治理简单等方面。

咱们纵观 Fluid 呈现之前的云原生基金会（CNCF）全景图，涵盖了从利用交付 – 运维治理 – 底层存储的方方面面，然而短少数据高效撑持组件这块重要拼图（注：Fluid 近期刚进入 CNCF 全景图，侧面反映本文理念失去了认可）。然而，这块拼图的缺失，就会造成大数据密集型利用在云原生环境下运行时，面临数据拜访低效、数据隔离性弱、多数据源联结拜访简单方面的技术挑战。

  1. 云原生环境下的数据撑持挑战

具体地，云原生环境下数据撑持的挑战次要分为三个方面：

  • 第一：云平台计算存储拆散架构导致数据拜访延时高。为了监控资源灵活性满足本地无依赖的要求，云原生利用大多采纳计算存储拆散架构。然而从拜访效率的角度来看，要求用云网络传输带宽，当数据密集型利用在云上运行时，会造成数据拜访瓶颈、性能降落。
  • 第二：混合云场景下跨存储系统的联结剖析艰难。大多公司 / 组织通常基于不同存储管理数据撑持多样化利用，具备其各自的特点。Ceph、GlusterFS、HDFS 都会被宽泛应用，数据也通常会散落在这些异构存储当中。然而，当须要联结数据进行综合性剖析时，会减少数据挪动老本，必然导致在云原生环境下须要面对网络费用、期待延时、人工操作等比较复杂的问题。
  • 第三：云环境中数据安全治理与多维度治理简单。数据是很多公司的生命线，数据泄露、误操作、生命周期治理不当都会造成巨大损失。如何在云原生环境中保障数据的隔离，爱护好用户的数据生命周期，都存在较大挑战。

  1. Kubernetes 生态中缺失的一块形象

综上所述，咱们能够总结出一种景象：Kubernetes 生态中目前短少数据密集型利用高效撑持的这块拼图。现有 Kubernetes 环境能对很多资源进行很好的形象，包含将资源对象计算形象成 Pod、将存储形象成了 PV/PVC、将网络形象成了 Service。云原生畛域还有一些存储形象次要面向数据长久化进行工作，提供对象和文件的长久化存储管理。但这些软件的性能不足以利用为核心的数据抽象及相干生命周期治理。

  1. 商店购物模式演变的联想

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

  • 商品 和数据 都会被生产，商品会被消费者购买掉，数据会被利用读走，两者有肯定类似性。
  • 超市 和存储 相似，都起到储藏与供给的性能。商品平时会储藏在超市的货架上，当购买时表演到供给的角色；对于存储而言，咱们平时储藏的数据都会被长久化到存储设备里，当利用须要时提供给用户。
  • 客户 和利用 相似，客户会到商店生产购买商品。相似的，利用会到存储读取数据。

商品、超市（商铺）、客 户模式，在过来几千年里倒退得十分成熟，十分稳固。直到 2000 年之后产生了颠覆性的变动，这就是电商的产生。电商创造了线上购物模式，其特点体现在不再以店铺为核心而是以客户为核心，商品储藏在仓库，客户能够在线上虚构商铺筛选商品，最初由现代化物流将商品交付到客户，交易过程 高效便捷、交易量更大。商品间接放在仓库里，仓库能够进行规范化、独立化治理，之后客户到电商平台上购买货物，会十分便捷、不便。客户不须要到店铺，在地铁上、车上、办公室、家里都能够用手机、电脑进行购物，而且不会存在商品寻找低效的状况，因为客户是在互联网上购物，都能够通过检索形式查找海量商品；线上购物的另一个劣势是交易频次变得更高，交易量变得更大；客户也不须要必须去店里提货，快递能够间接送货上门，十分不便。

电商模式的胜利有很多因素，其中有两大因素十分要害，一是如支付宝这样的第三方数字化领取工具的呈现，二是如菜鸟这样专业化的物流零碎产生，构建起四通八达的物流网络，使疾速的商品寄送模式得以实现。反观回到当初计算机系统中，在古代云架构下，数据储存在云存储系统中，数据密集型利用也以 pod 等各种各样资源描述符的形式在云原生环境下运行，但两头却不足一个高效的数据交付、数据递送的形式。也就是说，在云原生架构上面，数据储藏在云存储系统当中，利用还是依据须要去拜访数据，但因为相似的数据“物流零碎”的缺失，导致数据密集型利用生产拜访数据在云平台上比拟低效。

Fluid 核心理念

基于以上的剖析，以及从察看中失去的联想，上面来介绍 Fluid 的核心理念。

  1. Fluid 表演云原生的“数据物流零碎”角色

咱们能够将 Fluid 所表演角色了解为云原生环境下“数据物流零碎”。回顾一下，在新近的大数据平台中，数据的拜访尽量都是通过本地化进行。当用户写一个 MapReduce Job，Job 里蕴含很多 Task，其中关注比拟多的就是 MapTask 解决数据时是尽量将 Task 调度到用户要解决的数据所在的节点上运行。这种状况下，当用户拜访数据时，只管该数据是在 HDFS 这个分布式系统中，但实质上相当于从分布式系统中的本地节点上获取，咱们称之为 Data Fetch。

随着大数据生态系统的迅速倒退，其上的利用框架变得越来越多，底层存储系统也变得越来越丰盛，各种下层利用要拜访不同品种、多样化零碎的痛点越来越显著，于是呈现了 Alluxio 这样一个优良的开源我的项目，来对立治理底层不同存储系统，为下层提供统一化的标准接口，对下层利用屏蔽不同存储的差别。而且 Alluxio 提供内存缓存，减速数据拜访。这个过程就解耦了本地化的状况，存储就能够实现拆散。这种拆散架构在部署好之后通常还是动态的，实现从 Data Fetch 变成 Data Access 的过程。

Fluid 是在 Alluxio 根底之上，在云原生环境的调度层面上进行进一步的钻研和拓展，心愿获取云原生环境下数据节点以及利用的动态变化信息，让这一类动态的缓存等中间件动静、灵便地调动起来，从而让利用灵活性变得更强，实现数据智能化递送到利用的成果，即动静弹性（Data Delivery）。

在进行我的项目设计时，咱们心愿 Fluid 从视角、思路、理念三个档次带来一些变革：

  • 新视角：从云原生资源调度联合与数据密集型解决两个方面，从新综合扫视云原生场景的数据抽象与撑持拜访。
  • 新思路：针对容器编排不足数据感知，数据编排不足对云上架构变动的感知，提出了协同编排、多维治理、智能感知的一系列理念和翻新办法；从而造成一套云原生环境下数据密集型利用的高效撑持平台。
  • 新理念 ：通过 Fluid 这个我的项目，心愿 让数据能够像流体一样在云平台中、在资源编排层和数据处理层之间可能灵便高效地被拜访、转换和治理。

  1. 核心理念

简略来说，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 做的事就是联合后面数据编排的信息，把利用调度到最合适的节点上，而后尽量可能让用户去读到缓存节点外面的信息。
  • Prefetch Plugin：当用户集群还没有缓存流入数据状况之下，且晓得利用必定是要读哪一类数据时，尤其在利用调度和编排运行之前，能够做 Prefetch 的调度，将这个数据从最底下的存储卷当中缓存到数据缓存外面，能够手动触发。

再往下就是规范 K8s。通过 K8s 能够对接底层不同的存储，具体的对接形式可通过 K8s 的 PVC 实现。因为通过 Alluxio 进行了形象，能够间接反对 Alluxio 自身反对的存储类型。

  1. 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）隔离

隔离机制使得对数据集的拜访能够在不同存储减速间进行隔离，并且实现权限管制治理。

  1. 如何应用 Fluid

以上图为例，用户在应用场景中须要应用来自两个不同中央的数据，假如一个来自阿里云，另外一个是本地存储 Ceph。在 Fluid 外面咱们能够很容易地形容这样的数据集，通过创立一个自定义 K8s 资源对象 Dataset，对应的 mountPoint 能够加载两个，别离是阿里云和 Ceph。

创立好就能够运行，这个过程中 Fluid 会创立一个 Dataset，并主动将它变成一个 PVC。当用户须要用这个数据时创立一个 Pod，以 PVC 挂载的形式，将 Dataset 关联到运行中的 Pod 中对数据进行拜访。甚至 Pod 基本都不晓得 PVC 后盾运行的是 Fluid，而不是其余的存储，例如 NFS。整个过程和背地的原理对用户都是通明的，这使得对遗留程序的对接十分敌对。

  1. 如何检查和观测 dataset 状态

当真正运行起来时有很多可观测的货色，咱们在 Dataset CRD 里定义了很多 metrics。如上图所以，缓存总容量为 200GB，理论须要的容量为 84.29GB，无需扩容，后续可依据理论需要灵便扩容。通过这个工具，用户能够无效查问存储容量与使用量，从而实现可观测性。

  1. 依据数据集本地性调度作业

对于应用数据集利用的编排也很容易，只须要应用 PVC 模式把 Fluid 数据集挂载到利用当中，而后 K8s 调度器就会和 Fluid 调度器进行交互。

如上图例子所示，挂载之后进行交互，依据调度策略安顿 Pod 在对应的节点上运行。K8s 调度器和 Fluid 调度器交互时会看见三个节点，其中有两个有 Alluxio 缓存节点。咱们晓得经典的 K8s 调度包含两个很重要的阶段，一个是过滤阶段，另一个是优选阶段。在过滤阶段就会将第三个节点间接过滤掉，而在优选阶段能够利用一些内置优选的策略来抉择更适合的节点，例如缓存空间量大小，这外面有很多将来能够拓展优化实现的空间。

Fluid 性能评估

如上图所示，咱们发现卡数量越来越多的时候，应用 Fluid 会带来微小的性能晋升。这其中的实质起因是当 GPU 数量变得越来越多（或 GPU 算力越来越强）时，拜访大规模数据曾经成为整个训练任务的瓶颈。从上图是训练后果来看，应用 Fluid 训练的端到端的性能最初晋升约 1 倍，缩小老本并晋升了用户体验。


原文链接
本文为阿里云原创内容，未经容许不得转载。

退出移动版