php购物网站开发开发多久,国内做的比较好的数据网站,jsp编写网站,旅游网站建设方案书简介#xff1a; 为了解决大数据、AI 等数据密集型应用在云原生计算存储分离场景下#xff0c;存在的数据访问延时高、联合分析难、多维管理杂等痛点问题#xff0c;南京大学 PASALab、阿里巴巴、Alluxio 在 2020 年 9 月份联合发起了开源项目 Fluid。Fluid 本质上是一个云原…简介 为了解决大数据、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 2. 面临的问题 从用户的实际体验来看现有云原生编排框架对数据密集型应用支持不够友好主要体现在运行效率低下和数据管理复杂两方面。 运行效率低下如上图所示训练一个 RestNet50 神经网络如果基于本地内存运行大概每秒钟能训练近 1 万张图片然而在云原生环境下运行基于 Cloud Storage 存储架构每秒训练的图片只能达到约 3000 张/秒性能下降比较明显。 数据管理复杂数据版本的多变、数据接口的多样、数据类型的抽象以及数据存储的异构都给云原生环境下面向数据密集型应用支撑带来了挑战。 3. 问题的原因分析 云原生环境和数据密集处理框架在设计理念和机制上存在天然分歧这两部分技术的早先产生和发展过程是相互独立的。我们可以看到为了兼顾资源扩展的灵活性和使用成本计算和存储分离的基本架构在云原生环境中大行其道反观之以大数据! 2.jpg 和 AI 训练为代表的数据密集型应用框架为了减少数据传输设计理念更多需要考虑数据本地化架构两者在设计上存在分歧。 另外我们发现在云原生环境中应用通常是以无状态stateless微服务化的方式进行部署通过 FaaSFunction 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 扮演云原生的“数据物流系统”角色 我们可以将 Fluid 所扮演角色理解为云原生环境下“数据物流系统”。回顾一下在早先的大数据平台中数据的访问尽量都是通过本地化进行。当用户写一个 MapReduce JobJob 里包含很多 Task 其中关注比较多的就是 MapTask 处理数据时是尽量将 Task 调度到用户要处理的数据所在的节点上运行。这种情况下当用户访问数据时尽管该数据是在 HDFS 这个分布式系统中但本质上相当于从分布式系统中的本地节点上获取我们称之为 Data Fetch。 随着大数据生态系统的迅速发展其上的应用框架变得越来越多底层存储系统也变得越来越丰富各种上层应用要访问不同种类、多样化系统的痛点越来越明显于是出现了 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 PluginCache co-locality Plugin 做的事就是结合前面数据编排的信息把应用调度到最合适的节点上然后尽量能够让用户去读到缓存节点里面的信息。Prefetch Plugin当用户集群还没有缓存流入数据情况之下且知道应用肯定是要读哪一类数据时尤其在应用调度和编排运行之前可以做 Prefetch 的调度将这个数据从最底下的存储卷当中缓存到数据缓存里面可以手动触发。 再往下就是标准 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无需扩容后续可根据实际需求灵活扩容。通过这个工具用户可以有效查询存储容量与使用量从而实现可观测性。 5. 根据数据集本地性调度作业 对于使用数据集应用的编排也很容易只需要使用 PVC 模式把 Fluid 数据集挂载到应用当中然后 K8s 调度器就会和 Fluid 调度器进行交互。 如上图例子所示挂载之后进行交互根据调度策略安排 Pod 在对应的节点上运行。K8s 调度器和 Fluid 调度器交互时会看见三个节点其中有两个有 Alluxio 缓存节点。我们知道经典的 K8s 调度包括两个很重要的阶段一个是过滤阶段另一个是优选阶段。在过滤阶段就会将第三个节点直接过滤掉而在优选阶段可以利用一些内置优选的策略来选择更合适的节点例如缓存空间量大小这里面有很多未来可以拓展优化实现的空间。 Fluid 性能评估 如上图所示我们发现卡数量越来越多的时候使用 Fluid 会带来巨大的性能提升。这其中的本质原因是当 GPU 数量变得越来越多或 GPU 算力越来越强时访问大规模数据已经成为整个训练任务的瓶颈。从上图是训练结果来看使用 Fluid 训练的端到端的性能最后提升约1倍减少成本并提升了用户体验。 原文链接 本文为阿里云原创内容未经允许不得转载。