乐趣区

关于云原生:Vineyard-加入-CNCF-Sandbox将继续瞄准云原生大数据分析领域

jiezi

简介： Vineyard 是一个专为云原生环境下大数据分析场景中端到端工作流提供内存数据共享的分布式引擎，咱们很快乐发表 Vineyard 在 2021 年 4 月 27 日被云原生基金会（CNCF）TOC 承受为沙箱（Sandbox）我的项目。

作者 | Vineyard 团队
起源 | 阿里巴巴云原生公众号
​
Vineyard 是一个专为云原生环境下大数据分析场景中端到端工作流提供内存数据共享的分布式引擎，咱们很快乐发表 Vineyard 在 2021 年 4 月 27 日被云原生基金会（CNCF）TOC 承受为沙箱（Sandbox）我的项目。

我的项目介绍

现有的大数据分析场景中，对于端到端工作，不同的子工作之间通常应用例如 HDFS、S3、OSS 这样的分布式文件系统或对象存储系统，来共享工作之间的两头数据，这种形式在运行效率和研发效率上存在诸多问题，以下图所示的一个风控作业工作流为例：
​

  1. 工作流中不同工作之间为了共享两头数据，前一个工作将后果写入文件系统，实现之后，后一个再将文件读出作为输出，这个过程带来了额定的序列化及反序列化、内存拷贝、以及网络、IO 的开销，咱们从历史工作中察看到有超过 60% 的工作为此破费了 40% 以上的执行工夫。
  2. 对于生产环境，为了高效地解决某一个特定范式的问题往往会引入一个新零碎（例如分布式图计算），但这样的零碎往往难以间接与工作流中的其余零碎无缝连接，须要很多反复的 IO、数据格式转换和适配的研发工作。
  3. 应用内部文件系统共享数据给工作流带来了额定的中断，因为往往只有当一个工作齐全写完所有后果，下一个工作能力开始读取和计算，这使得跨工作的流水线并行无奈被利用。
  4. 现有的分布式文件系统在共享两头数据时，特地是在云原生环境下，并没有很好的解决分布式数据的地位问题，造成网络开销的节约，从而升高端到端执行效率。

为了解决现有大数据分析工作流中存在的上述问题，咱们设计和实现了分布式内存数据共享引擎 Vineyard。

Vineyard 从以下三个角度来应答上述几个问题：
​

  1. 为了使端到端工作流中工作之间的数据共享更加高效，Vineyard 通过内存映射的形式，支持系统间零拷贝的数据共享，省去了额定的 IO 开销。
  2. 为了简化新计算引擎接入现有零碎所须要的适配和开发，Vineyard 对常见的数据类型，提供了开箱即用的形象，例如 Tensor、DataFrame、Graph，等等，从而不同计算引擎之间共享两头后果不再须要额定的序列化和反序列。同时，Vineyard 将 IO、数据迁徙、快照等可复用的组件以插件的模式实现，使其可能很灵便地按需注册到计算引擎中去，升高与计算引擎自身无关的开发成本。
  3. Vineyard 提供一系列 operators，来实现更高效灵便的数据共享。例如 Pipeline operator 实现了跨工作的流水线并行，使得后续工作能够随着前序工作输入的产生，同时进行计算，进步了端到端整体效率。
  4. Vineyard 与 Kubernetes 集成，通过 Scheduler Plugin，让工作的调度可能感知所须要的数据的局部性，在 Kubernetes 让单个工作的 Pod 尽可能地调度到与 Pod 所需的输出数据对其的机器上，来减小数据迁徙须要的网络开销，晋升端到端性能。

在初步的比照试验中，相比于应用 HDFS 来共享两头数据，对于评测工作，Vineyard 可能大幅升高用于替换两头后果引入的额定开销，对于整个工作流的端到端工夫有 1.34 倍的晋升。

外围性能

接下来从 Vineyard 外围的设计与实现，以及 Vineyard 如何助力云原生环境中大数据分析工作两个方面来介绍 Vineyard 的外围性能。
​

  1. 分布式内存数据共享
    Vineyard 将内存中的数据表示为 Object。Object 能够是 Local 的，也能够是 Global 的，以分布式执行引擎 Mars 和 Dask 为例，一个 DataFrame 往往被拆分成很多个 Chunk 以利用多台机器的计算能力，每台机器上有多个 Chunk，这些 Chunk 是 Vineyard 中的 LocalObject，这些 Chunk 一起形成了一个全局的视图，即 GlobalDataFrame。这个 GlobalDataFrame 可能间接共享给其余计算引擎，如 GraphScope，作为图数据的输出。有了这些数据类型的形象，Vineyard 上的不同计算引擎之间就能够无缝地共享两头后果，将一个工作的输入间接用作下一个工作的输入。
    ​
    更具体地，Vineyard 中又是如果表白一个特定类型的 Object，使之可能很容易地适配到不同的计算引擎中去呢？这得益于 Vineyard 在 Object 的示意上提供的灵活性。Vineyard 中，一个 Object 包含两个局部，Metadata，以及一组 Blob。Blob 中存储着理论的数据，而 Metadata 则用于解释这些 Blob 的语义。例如对于 Tensor，Blob 是一段间断内存，存储着 Tensor 中所有的元素，而 Metadata 中记录了 Tensor 的类型、形态、以及行主序还是列主序等属性。在 Python 中，这个 Object 能够被解释为一个 Numpy 的 NDArray，而在 C++ 中，这个 Object 能够被解释为一个 xtensor 中的 tensor。这两种不同编程语言的 SDK 中，共享这个 Tensor 不会带来额定的 IO、拷贝、序列化 / 反序列化、以及类型转换的开销。
    ​
    同时，Vineyard 中的 Metadata 是可嵌套的，这使得咱们通过很容易地将任何简单的数据类型形容为 Vineyard 中的 Object，不会限度计算引擎的表达能力。以 GlobalDataFrame 为例，见下图中 Metadata 的构造。
    ​
  2. 云原生环境中数据与工作的协同调度

对于一个实在部署的大数据分析流水线，仅仅有工作之间的数据共享是远远不够的。在云环境中，一个端到端流水线中蕴含的多个子工作在被 Kubernetes 调度时仅仅思考了须要的资源束缚，间断的两个工作的 co-locate 无奈保障，在两个工作之间共享两头后果时依然有数据迁徙引入的网络开销，如下图，在运行 Task B 时，因为两个工作的 Pod 没有对齐，数据分片 A3、A4 须要被迁徙到 Pod 所在的 Vineyard 实例上。
​

对此，Vineyard 通过 CRD 将集群中的数据（Vineyard Objects）示意为可观测的资源，并基于 Kubernetes 的 Scheduler Framework 设计和实现了一个思考数据局部性的调度器插件。以后一个工作 Task A 实现后，从后果对象的 Metadata 中，调度器插件能够晓得所有分片的地位，在启动下一个工作时，调度器给数据所在的节点（图中的 Node 1、Node 2）更高的优先级，使工作 Task B 也尽可能地被调度到对应的节点上，从而省去了数据迁徙引入的额定开销，来改善端到端的性能。

疾速上手

Vineyard 集成了 Helm 以不便用户装置和部署：
​

helm repo add vineyard https://vineyard.oss-ap-southeast-1.aliyuncs.com/charts/
helm install vineyard vineyard/vineyard

装置之后，零碎中会部署一个 Vineyard DaemonSet，并裸露一个 UNIX domain socket 用于与利用的工作 Pod 之间的共享内存和 IPC 通信。
​
此外，还能够参考 Vineyard 的演示视频：
https://www.youtube.com/watch…

将来瞻望

Vineyard 曾经作为分布式科学计算引擎 Mars 和一站式图计算零碎 GraphScope 的存储引擎，Vineyard 助力大数据分析工作离不开与云原生社区的严密互动，将来 Vineyard 会进一步地欠缺与社区其余我的项目如 Kubeflow、Fluid 等的集成，助力更多云上大数据分析工作。

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

退出移动版