Fluid支持子数据集

简介: 什么是Fluid?在云上通过云原生架构运行AI、大数据等任务,可以享受计算资源弹性的优势,但同时也会遇到,计算和存储分离架构带来的数据访问延迟和远程拉取数据带宽开销大的挑战。尤其在GPU深度学习训练场景中,迭代式的远程读取大量训练数据方法会严重拖慢GPU计算效率。另一方面,Kubernetes只提供了异构存储服务接入和管理标准接口(CSI,Container Storage Interface),

什么是Fluid?

在云上通过云原生架构运行AI、大数据等任务,可以享受计算资源弹性的优势,但同时也会遇到,计算和存储分离架构带来的数据访问延迟和远程拉取数据带宽开销大的挑战。尤其在GPU深度学习训练场景中,迭代式的远程读取大量训练数据方法会严重拖慢GPU计算效率。

另一方面,Kubernetes只提供了异构存储服务接入和管理标准接口(CSI,Container Storage Interface),对应用如何在容器集群中使用和管理数据并没有定义。在运行训练任务时,数据科学家需要能够管理数据集版本,控制访问权限,数据集预处理,加速异构数据读取等。但是在Kubernetes中还没有这样的标准方案,这是云原生容器社区缺失的重要能力之一。

Fluid对“计算任务使用数据的过程”进行抽象,提出了弹性数据集Dataset的概念,并作为“first class citizen”在Kubernetes中实现。Fluid围绕弹性数据集Dataset,创建了数据编排与加速系统,来实现Dataset管理(CRUD操作)、权限控制和访问加速等能力。

Fluid中有两个最核心的概念:Dataset和Runtime。

  • Dataset 是指数据集,是逻辑上相关的一组数据的集合,会被计算引擎使用,比如Spark,TensorFlow,PyTorch等等。
  • Runtime 指的是提供分布式缓存的系统,目前 Fluid 支持的 Runtime 类型有 JuiceFS、Alluxio、JindoFS,GooseFS,其中 Alluxio、JindoFS 都是典型的分布式缓存引擎; JuiceFS 是一款分布式文件系统,具备分布式缓存能力。这些缓存系统使用Kubernetes集群中节点上的存储资源(如:内存和磁盘)来作为远程存储系统的计算侧缓存。

为什么Fluid需要支持子数据集(subDataset)?

Fluid最早的模式默认支持一个Dataset独占一个Runtime,可以理解为一个数据集就有专门的缓存集群加速。可以针对于数据集的特点,比如单文件大小特征,文件数量规模,客户端数量进行定制优化;并且提供单独的缓存系统。它能够提供最好的性能以及稳定性,并且不会互相干扰,但是它的问题在于硬件资源浪费,需要为每个不同的数据集部署缓存系统;同时运维复杂,需要管理多个缓存Runtime。这种模式其实本质上是单租户架构,适合于对于数据访问吞吐和延时高要求的场景。

当然随着Fluid使用的深入,也有不同的需求出现。其中社区一个比较共性的需求:

  1. 可以跨namespace访问数据集缓存 
  2. 只允许用户访问数据集的某个子目录

特别是JuiceFS的用户,他们倾向于使用Dataset指向JuiceFS的根目录。然后对于不同数据科学家组分配不同的子目录作为不同的数据集,并且希望彼此间的数据集不可见;同时还支持子数据集的权限收紧,比如根数据集支持读写,子数据集可以收紧为只读。

本文以AlluxioRuntime为例子向您演示如何使用Fluid支持子数据集能力。

使用样例:

想像一下,用户A在Kubernetes的命名空间spark下创建数据集spark, 该数据集包含spark的三个版本,希望团队A只能看到数据集spark-3.1.3, 团队B只能看到数据集spark-3.3.1。

.
|-- spark-3.1.3
|   |-- SparkR_3.1.3.tar.gz
|   |-- pyspark-3.1.3.tar.gz
|   |-- spark-3.1.3-bin-hadoop2.7.tgz
|   |-- spark-3.1.3-bin-hadoop3.2.tgz
|   |-- spark-3.1.3-bin-without-hadoop.tgz
|   `-- spark-3.1.3.tgz
|-- spark-3.2.3
|   |-- SparkR_3.2.3.tar.gz
|   |-- pyspark-3.2.3.tar.gz
|   |-- spark-3.2.3-bin-hadoop2.7.tgz
|   |-- spark-3.2.3-bin-hadoop3.2-scala2.13.tgz
|   |-- spark-3.2.3-bin-hadoop3.2.tgz
|   |-- spark-3.2.3-bin-without-hadoop.tgz
|   `-- spark-3.2.3.tgz
`-- spark-3.3.1
    |-- SparkR_3.3.1.tar.gz
    |-- pyspark-3.3.1.tar.gz
    |-- spark-3.3.1-bin-hadoop2.tgz
    |-- spark-3.3.1-bin-hadoop3-scala2.13.tgz
    |-- spark-3.3.1-bin-hadoop3.tgz
    |-- spark-3.3.1-bin-without-hadoop.tgz
    `-- spark-3.3.1.tgz

这样就实现了不同团队可以访问不同子数据集,并且彼此间的数据不可见。

阶段1: 管理员创建数据集,指向根目录

  1. 在运行该示例之前,请参考 安装文档 完成安装,并检查Fluid各组件正常运行
kubectl get po -n fluid-system
NAME                                         READY   STATUS      RESTARTS   AGE
alluxioruntime-controller-5c6d5f44b4-p69mt   1/1     Running     0          149m
csi-nodeplugin-fluid-bx5d2                   2/2     Running     0          149m
csi-nodeplugin-fluid-n6vbv                   2/2     Running     0          149m
csi-nodeplugin-fluid-t5p8c                   2/2     Running     0          148m
dataset-controller-797868bd7f-g4slx          1/1     Running     0          149m
fluid-webhook-6f6b7dfd74-hmsgw               1/1     Running     0          149m
fluidapp-controller-79c7b89c9-rtdg7          1/1     Running     0          149m
thinruntime-controller-5fdbfd54d4-l9jcz      1/1     Running     0          149m
  1. 创建命名空间spark
$ kubectl create ns spark
  1. 在命名空间development创建Dataset和AlluxioRuntime, 其中数据集为可读写
$ cat<<EOF >dataset.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: spark
  namespace: spark
spec:
  mounts:
    - mountPoint: https://mirrors.bit.edu.cn/apache/spark/
      name: spark
      path: "/"
  accessModes:
    - ReadWriteMany
---
apiVersion: data.fluid.io/v1alpha1
kind: AlluxioRuntime
metadata:
  name: spark
  namespace: spark
spec:
  replicas: 1
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 4Gi
        high: "0.95"
        low: "0.7"
EOF

$ kubectl create -f dataset.yaml
  1. 查看数据集状态
$ kubectl get dataset -n spark
NAME    UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
spark   3.41GiB          0.00B    4.00GiB          0.0%                Bound   61s
  1. 在命名空间spark创建Pod访问数据集
$ cat<<EOF >app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: spark
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: spark
  volumes:
    - name: spark
      persistentVolumeClaim:
        claimName: spark
EOF

$ kubectl create -f app.yaml
  1. 查看应用通过dataset可以访问的数据, 可以看到3个文件夹:spark-3.1.3, spark-3.2.3, spark-3.3.1, 同时可以看到 挂载权限为RW( ReadWriteMany )
$ kubectl exec -it -n spark nginx -- bash
mount | grep /data
alluxio-fuse on /data type fuse.alluxio-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=131072)
root@nginx:/# ls -ltr /data/
total 2
dr--r----- 1 root root 6 Dec 16 07:25 spark-3.1.3
dr--r----- 1 root root 7 Dec 16 07:25 spark-3.2.3
dr--r----- 1 root root 7 Dec 16 07:25 spark-3.3.1
root@nginx:/# ls -ltr /data/spark-3.1.3/
total 842999
-r--r----- 1 root root  25479200 Feb  6  2022 spark-3.1.3.tgz
-r--r----- 1 root root 164080426 Feb  6  2022 spark-3.1.3-bin-without-hadoop.tgz
-r--r----- 1 root root 231842529 Feb  6  2022 spark-3.1.3-bin-hadoop3.2.tgz
-r--r----- 1 root root 227452039 Feb  6  2022 spark-3.1.3-bin-hadoop2.7.tgz
-r--r----- 1 root root 214027643 Feb  6  2022 pyspark-3.1.3.tar.gz
-r--r----- 1 root root    347324 Feb  6  2022 SparkR_3.1.3.tar.gz
root@nginx:/# ls -ltr /data/spark-3.2.3/
total 1368354
-r--r----- 1 root root  28375439 Nov 14 18:47 spark-3.2.3.tgz
-r--r----- 1 root root 209599610 Nov 14 18:47 spark-3.2.3-bin-without-hadoop.tgz
-r--r----- 1 root root 301136158 Nov 14 18:47 spark-3.2.3-bin-hadoop3.2.tgz
-r--r----- 1 root root 307366638 Nov 14 18:47 spark-3.2.3-bin-hadoop3.2-scala2.13.tgz
-r--r----- 1 root root 272866820 Nov 14 18:47 spark-3.2.3-bin-hadoop2.7.tgz
-r--r----- 1 root root 281497207 Nov 14 18:47 pyspark-3.2.3.tar.gz
-r--r----- 1 root root    349762 Nov 14 18:47 SparkR_3.2.3.tar.gz

阶段2: 管理员创建子数据集,指向目录spark 3.1.3

  1. 创建命名空间spark-313
$ kubectl create ns spark-313
  1. 管理员在 spark-313 命名空间下,创建:

引用数据集spark,其mountPoint格式为dataset://${初始数据集所在namespace}/${初始数据集名称}/子目录,  在本例子中应该为dataset://spark/spark/spark-3.1.3 

注: 当前引用的数据集,只支持一个mount,且形式必须为dataset://(即出现dataset://和其它形式时,dataset创建失败),数据集权限为读写;

$ cat<<EOF >spark-313.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: spark
  namespace: spark-313
spec:
  mounts:
    - mountPoint: dataset://spark/spark/spark-3.1.3
  accessModes:
    - ReadWriteMany
EOF

$ kubectl create -f spark-313.yaml
  1. 查看dataset状态
$ kubectl get dataset -n spark-313
NAME    UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
spark   3.41GiB          0.00B    4.00GiB          0.0%                Bound   108s
  1. 用户在 spark-313  命名空间,创建Pod:
$ cat<<EOF >app-spark313.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: spark-313
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: spark
  volumes:
    - name: spark
      persistentVolumeClaim:
        claimName: spark
EOF

$ kubectl create -f app-spark313.yaml
  1. 在spark-313命名空间访问数据, 只能看到spark-3.1.3文件夹中的内容,并且可以 看到pvc权限RWX
$ kubectl get pvc -n spark-313
NAME    STATUS   VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
spark   Bound    spark-313-spark   100Gi      RWX            fluid          21h
$ kubectl exec -it -n spark-313 nginx -- bash
root@nginx:/# mount | grep /data
alluxio-fuse on /data type fuse.alluxio-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=131072)
root@nginx:/# ls -ltr /data/
total 842999
-r--r----- 1 root root  25479200 Feb  6  2022 spark-3.1.3.tgz
-r--r----- 1 root root 164080426 Feb  6  2022 spark-3.1.3-bin-without-hadoop.tgz
-r--r----- 1 root root 231842529 Feb  6  2022 spark-3.1.3-bin-hadoop3.2.tgz
-r--r----- 1 root root 227452039 Feb  6  2022 spark-3.1.3-bin-hadoop2.7.tgz
-r--r----- 1 root root 214027643 Feb  6  2022 pyspark-3.1.3.tar.gz
-r--r----- 1 root root    347324 Feb  6  2022 SparkR_3.1.3.tar.gz

阶段3: 管理员创建子数据集,指向目录spark 3.3.1

  1. 创建命名空间spark-331
$ kubectl create ns spark-331
  1. 管理员在 spark-331 命名空间下,创建:

引用数据集spark,其mountPoint格式为dataset://${初始数据集所在namespace}/${初始数据集名称}/子目录,  在本例子中应该为dataset://spark/spark/spark-3.3.1 

注: 当前引用的数据集,只支持一个mount,且形式必须为dataset://(即出现dataset://和其它形式时,dataset创建失败),并且指定读写权限为只读ReadOnlyMany

$ cat<<EOF >spark-331.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: spark
  namespace: spark-331
spec:
  mounts:
    - mountPoint: dataset://spark/spark/spark-3.3.1
  accessModes:
    - ReadOnlyMany
EOF

$ kubectl create -f spark-331.yaml
  1. 用户在 spark-331  命名空间,创建Pod:
$ cat<<EOF >app-spark331.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: spark-331
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: spark
  volumes:
    - name: spark
      persistentVolumeClaim:
        claimName: spark
EOF

$ kubectl create -f app-spark331.yaml
  1. 在spark-331命名空间访问数据, 只能看到spark-3.3.1文件夹中的内容, 并且可以 看到PVC权限ROX( ReadOnlyMany )
$ kubectl get pvc -n spark-331
NAME    STATUS   VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
spark   Bound    spark-331-spark   100Gi      ROX            fluid          14m$ kubectl exec -it -n spark-331 nginx -- bash
mount | grep /data
alluxio-fuse on /data type fuse.alluxio-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=131072)
root@nginx:/# ls -ltr /data/
total 842999
-r--r----- 1 root root  25479200 Feb  6  2022 spark-3.1.3.tgz
-r--r----- 1 root root 164080426 Feb  6  2022 spark-3.1.3-bin-without-hadoop.tgz
-r--r----- 1 root root 231842529 Feb  6  2022 spark-3.1.3-bin-hadoop3.2.tgz
-r--r----- 1 root root 227452039 Feb  6  2022 spark-3.1.3-bin-hadoop2.7.tgz
-r--r----- 1 root root 214027643 Feb  6  2022 pyspark-3.1.3.tar.gz
-r--r----- 1 root root    347324 Feb  6  2022 SparkR_3.1.3.tar.gz

总结:

在本例子中,我们展示了Sub Dataset的能力,也就是将某个Dataset的子目录作为Dataset。能够实现同一套数据集,根据不同的细分策略,被不同的数据科学家使用。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
存储 缓存 弹性计算
阿里巴巴开源 容器镜像加速技术DADI 上手指南
阿里资深技术专家在阿里云开发者社区特别栏目《周二开源日》直播中,介绍刚于3月份开源的容器镜像加速器项目 DADI ,并带大家快速上手使用。本文为直播内容文字整理,看直播回放,请点击文首链接~
阿里巴巴开源 容器镜像加速技术DADI 上手指南
|
Kubernetes Cloud Native Docker
云原生|kubernetes|网络插件flannel二进制部署和calico的yaml清单部署总结版
云原生|kubernetes|网络插件flannel二进制部署和calico的yaml清单部署总结版
1414 0
|
IDE 开发工具 Windows
QT应用编程: windows下QT调用COM组件
QT应用编程: windows下QT调用COM组件
1174 0
QT应用编程: windows下QT调用COM组件
|
DataWorks 数据可视化 前端开发
《阿里云飞天大数据平台 DataWorks 前端技术解密:工作流调度可视化》(脱敏版本)
## ![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/13481/1614773723538-e8d99a86-b04d-47bb-86ad-90cdb07ac657.png#height=220&id=QQWI7&margin=%5Bobject%20Object%5D&name=image.png&or
1068 0
|
6月前
|
存储 缓存 人工智能
Mooncake 最新进展:SGLang 和 LMCache 基于 Mooncake 实现高效 PD 分离框架
Mooncake 的架构设计兼具高性能和灵活性,为未来的扩展性和生态建设奠定了坚实基础。
|
JavaScript 安全 前端开发
乾坤js隔离机制
乾坤js隔离机制
|
5月前
|
缓存 自然语言处理 监控
基于通义大模型的智能客服系统构建实战:从模型微调到API部署
本文详细解析了基于通义大模型的智能客服系统构建全流程,涵盖数据准备、模型微调、性能优化及API部署等关键环节。通过实战案例与代码演示,展示了如何针对客服场景优化训练数据、高效微调大模型、解决部署中的延迟与并发问题,以及构建完整的API服务与监控体系。文章还探讨了性能优化进阶技术,如模型量化压缩和缓存策略,并提供了安全与合规实践建议。最终总结显示,微调后模型意图识别准确率提升14.3%,QPS从12.3提升至86.7,延迟降低74%。
1753 15
|
Arthas 监控 Java
拥抱 OpenTelemetry:阿里云 Java Agent 演进实践
本文介绍了阿里云 Java Agent 4.x 版本在基于 OTel Java Agent 二次开发过程中的实践与思考,并重点从功能、性能、稳定性、兼容性四个方面介绍了所做的工作。同时也介绍了阿里云可观测团队积极参与开源建设取得的丰厚成果。
1041 109
拥抱 OpenTelemetry:阿里云 Java Agent 演进实践
|
12月前
|
存储 人工智能 缓存
官宣开源|阿里云与清华大学共建AI大模型推理项目Mooncake
2024年6月,国内优质大模型应用月之暗面Kimi与清华大学MADSys实验室(Machine Learning, AI, Big Data Systems Lab)联合发布了以 KVCache 为中心的大模型推理架构 Mooncake。
|
监控 安全 开发工具
git fatal: detected dubious ownership in repository at ‘xxx‘ 彻底解决方法
调整文件所有权和权限后,你应该能够无误地进行Git操作。持续的维护与监控文件系统的安全性能降低将来遇到类似问题的风险,并保证团队能够高效协作。如果你是在团队环境中工作,建议建立明确的协作规则和文件管理实践,以避免此类问题。
1780 3