Fluid新魔法:跨namespace共享数据

简介: 什么是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需要支持跨namespace共享?

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

当然随着Fluid使用的深入,也有不同的需求出现。比如用户会在多个不同的Namespace中创建数据密集型作业,且这些作业将访问相同的数据集。多个数据科学家共享相同的数据集,各数据科学家拥有自己独立的Namespace提交作业。如果对于每个Namespace重新部署缓存系统并进行缓存预热,那么就会造成数据冗余和作业启动延迟问题。

此时社区用户能够为了节省资源和运维简单降低对于性能的要求,社区用户就开始有了跨Namespace访问数据集的需求。跨namespace需求本质上是在呼唤多租户架构,即集群管理员将Runtime指向某个存储的根目录,多个数据科学家可以在不同的Namespace中创建多个Dataset共用同一个Runtime。更近一步,管理员可以为不同Namespace的数据科学家配置子目录和不同的读写权限。

共享Runtime模式

独占Runtime模式

性能

相对低

高

可靠性

相对低

高

隔离性

相对低

高

可定制配置能力

相对低

高

升级能力

升级简单,只需要更新一次,维护人员不需要对每个用户更新,节省了很大的运维成本。

可以控制升级的时间和方式,选择延迟甚至跳过升级周期。

运维复杂度

简单

多个数据集管理成本高

硬件成本

相对低

高

所有的架构选择上并不存在银弹,都是取舍。本文以AlluxioRuntime为例子向您演示如何使用Fluid共享Runtime。

使用样例:

想像一下,用户A在Kubernetes的命名空间development下对于数据集spark进行预热,用户B可以在另一个命名空间production中访问缓存过的数据,做到一次预热,不同namespace的用户都得到收益。

  1. 在运行该示例之前,请参考 安装文档 完成安装(目前该功能存在于master分支)。并检查Fluid各组件正常运行:
NAME                                        READY   STATUS              RESTARTS   AGE
csi-nodeplugin-fluid-mwx59                  2/2     Running             0          5m46s
csi-nodeplugin-fluid-tcbfd                  2/2     Running             0          5m46s
csi-nodeplugin-fluid-zwm8t                  2/2     Running             0          5m46s
dataset-controller-5c7557c4c5-q58bb         1/1     Running             0          5m46s
fluid-webhook-67fb7dffd6-h8ksp              1/1     Running             0          5m46s
fluidapp-controller-59b4fcfcb7-b8tx5        1/1     Running             0          5m46s

  1. 创建命名空间development
$ kubectl create ns development
  1. 在命名空间development创建Dataset和AlluxioRuntime, 
$ cat<<EOF >dataset.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: spark
  namespace: development
spec:
  mounts:
    - mountPoint: https://mirrors.bit.edu.cn/apache/spark/
      name: spark
      path: "/"
---
apiVersion: data.fluid.io/v1alpha1
kind: AlluxioRuntime
metadata:
  name: spark
  namespace: development
spec:
  replicas: 1
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        quota: 4Gi
        high: "0.95"
        low: "0.7"
EOF
  1. 查看数据集状态
$ kubectl get dataset -A
NAMESPACE     NAME    UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
development   spark   3.41GiB          0.00B    4.00GiB          0.0%                Bound   2m54s
  1. 在命名空间development创建Pod访问数据集
$ cat<<EOF >app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: development
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可以访问的数据, 并且执行拷贝。可以发现拷贝1.4G数据(7个文件)
$ kubectl exec -it -n development nginx -- ls -ltr /data
total 2
dr--r----- 1 root root 6 Dec  4 15:39 spark-3.1.3
dr--r----- 1 root root 7 Dec  4 15:39 spark-3.2.3
dr--r----- 1 root root 7 Dec  4 15:39 spark-3.3.1
$ kubectl exec -it -n development nginx -- bash
root@nginx:/# time cp -R  /data/spark-3.3.1/* /tmp

real	3m16.761s
user	0m0.021s
sys	0m3.520s
root@nginx:/# du -sh /tmp/
1.4G	/tmp/
root@nginx:/# du -sh /tmp/*
348K	/tmp/SparkR_3.3.1.tar.gz
269M	/tmp/pyspark-3.3.1.tar.gz
262M	/tmp/spark-3.3.1-bin-hadoop2.tgz
293M	/tmp/spark-3.3.1-bin-hadoop3-scala2.13.tgz
286M	/tmp/spark-3.3.1-bin-hadoop3.tgz
201M	/tmp/spark-3.3.1-bin-without-hadoop.tgz
28M	/tmp/spark-3.3.1.tgz
  1. 通过dataload对于指定数据集子目录进行加载
$ cat<<EOF >dataload.yaml
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: spark
  namespace: development
spec:
  dataset:
    name: spark
    namespace: development
  target:
    - path: /spark-3.3.1
EOF

$ kubectl create -f dataload.yaml
  1. 查看dataload状态
$ kubectl get dataload -A
NAMESPACE     NAME    DATASET   PHASE      AGE     DURATION
development   spark   spark     Complete   5m47s   2m1s
  1. 查看缓存效果, 可以看到38.4%的数据已经缓存完成
$ kubectl get dataset -n development
NAME    UFS TOTAL SIZE   CACHED    CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
spark   3.41GiB          1.31GiB   4.00GiB          38.4%               Bound   79m
  1. 再次拷贝1.4G数据仅耗时0.8秒,  访问速度比之前的提升了245倍
$ kubectl exec -it -n development nginx -- bash
root@nginx:/# time cp -R  /data/spark-3.3.1/* /tmp

real	0m0.872s
user	0m0.009s
sys	0m0.859s
root@nginx:/# du -sh /tmp/
1.4G	/tmp/
root@nginx:/# du -sh /tmp/*
348K	/tmp/SparkR_3.3.1.tar.gz
269M	/tmp/pyspark-3.3.1.tar.gz
262M	/tmp/spark-3.3.1-bin-hadoop2.tgz
293M	/tmp/spark-3.3.1-bin-hadoop3-scala2.13.tgz
286M	/tmp/spark-3.3.1-bin-hadoop3.tgz
201M	/tmp/spark-3.3.1-bin-without-hadoop.tgz
28M	/tmp/spark-3.3.1.tgz
  1. 创建production命名空间
$ kubectl create ns production
  1. 在  production  命名空间下,创建:

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

注: 当前引用的数据集,只支持一个mount,且形式必须为dataset://(即出现dataset://和其它形式时,dataset创建失败),Spec中其它字段无效;

$ cat<<EOF >spark-production.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: spark
  namespace: production
spec:
  mounts:
    - mountPoint: dataset://development/spark
      name: spark
      path: "/"
EOF

$ kubectl create -f spark-production.yaml
  1. 查看数据集, 可以看到在production这命名空间下的spark数据集,并且都已经完成了数据缓存
$ kubectlkubectl get dataset -n production
NAME    UFS TOTAL SIZE   CACHED    CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
spark   3.41GiB          1.31GiB   4.00GiB          38.4%               Bound   14h
  1. 在production命名空间,创建Pod:
$ cat<<EOF >app-production.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: production
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: spark
  volumes:
    - name: spark
      persistentVolumeClaim:
        claimName: spark
EOF

$ kubectl create -f app-production.yaml
  1. 在production命名空间访问数据的耗时也是0.878s,
$ kubectl exec -it -n production nginx -- ls -ltr /data
total 2
dr--r----- 1 root root 6 Dec  4 15:39 spark-3.1.3
dr--r----- 1 root root 7 Dec  4 15:39 spark-3.2.3
dr--r----- 1 root root 7 Dec  4 15:39 spark-3.3.1
$ kubectl exec -it -n production nginx -- bash
root@nginx:/# ls -ltr /tmp/
total 0
root@nginx:/# time cp -R  /data/spark-3.3.1/* /tmp

real	0m0.878s
user	0m0.014s
sys	0m0.851s
root@nginx:/# du -sh /tmp
1.4G	/tmp
root@nginx:/# du -sh /tmp/*
348K	/tmp/SparkR_3.3.1.tar.gz
269M	/tmp/pyspark-3.3.1.tar.gz
262M	/tmp/spark-3.3.1-bin-hadoop2.tgz
293M	/tmp/spark-3.3.1-bin-hadoop3-scala2.13.tgz
286M	/tmp/spark-3.3.1-bin-hadoop3.tgz
201M	/tmp/spark-3.3.1-bin-without-hadoop.tgz
28M	/tmp/spark-3.3.1.tgz

总结:

上面的例子展示了如何使用Fluid实现跨namespace共享数据集的能力,下一步Fluid会支持在Serverless Kubernetes上的跨Namespace数据集访问,实际上对于用户来说整个使用体验没有任何差别。

在近一步我们会支持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
目录
相关文章
|
7月前
|
缓存 运维 监控
从踩坑到高效落地:淘宝天猫商品详情API的实操心得
本文分享淘宝天猫商品详情API从踩坑到高效落地的实战经验,涵盖准入权限避坑、签名与调用规范、异常处理、缓存优化、批量调度及监控运维等关键环节,助开发者快速稳定接入,提升开发效率与系统稳定性。(239字)
|
4月前
|
存储 缓存 人工智能
缓存输入便宜120倍,DeepSeek V4 怎么做到的
DeepSeek V4创新采用CSA+HCA混合注意力架构,支持1M超长上下文,并通过KV缓存压缩、磁盘存储与智能命中复用,大幅降低prefill成本。其Pro版未命中/命中输入价差达120倍,显著高于竞品,真正实现长上下文“又便宜又高效”。
1250 0
缓存输入便宜120倍,DeepSeek V4 怎么做到的
|
9月前
|
数据采集 安全 前端开发
堪比Log4j!Next.js CVSS 10.0漏洞席卷39%云环境,这些场景已成为攻击重灾区
CVSS评分10.0的Next.js高危漏洞正席卷全球,波及39%云环境。无需认证、利用简单,攻击者可远程执行代码,窃取数据、植入后门。关联React漏洞CVE-2025-55182,启用App Router的公网项目成重灾区。企业须立即排查资产、部署WAF、升级至安全版本,24小时内完成应急防护,严防大规模攻击。
|
5月前
|
数据采集 人工智能 算法
罗兰艺境GEO内容工程实战复盘:CSDN 92分技术文章是怎样炼成的?
本文深度复盘罗兰艺境GEO内容团队如何在2天内连续产出3篇CSDN 92+高分技术文章。拆解其选题策略、写作框架与技术深度打磨,揭示平台算法与AI大模型双重认可背后的内容工程方法论,为技术创作者提供可复现的实战参考。
473 3
罗兰艺境GEO内容工程实战复盘:CSDN 92分技术文章是怎样炼成的?
|
6月前
|
存储 人工智能 监控
openclaw造神记录-02:通俗解释xyvaclaw的核心功能
本文档用生活化比喻详解V5六大核心能力:模式库(经验笔记本)、意图分类(听懂人话)、推理链(深度思考)、DAG分解(做菜步骤图)、记忆检索(大脑搜索)、情绪检测(察言观色),展现AI如何从“工具”进化为有思考、有记忆、懂情感的智能伙伴。(239字)
|
6月前
|
JSON 安全 算法
如何安全使用 JWT 作为访问凭证
本文深入解析JWT安全使用规范,涵盖核心概念、六步验证清单(签名、时效、签发者、受众等)、算法混淆等真实漏洞案例,并给出六大实践建议:硬编码算法白名单、严验所有声明、短生命周期令牌、过滤kid注入、选用可信库、遵循RFC 9068标准,助开发者筑牢API安全防线。(239字)
1008 0
|
8月前
|
人工智能 中间件 API
【架构最佳实践】大模型落地的隐形英雄:为何企业级应用必须引入“AI调度官”?
本文提出“AI调度官”架构,作为连接业务与模型的智能中间件,在阿里云环境下实现模型路由、流量分发与成本优化。通过意图识别、动态调度与熔断降级,平衡智能与成本,助力企业构建高性价比的生成式AI应用。
538 3
|
机器学习/深度学习 自然语言处理 计算机视觉
反转了?在一场新较量中,号称替代MLP的KAN只赢一局
【8月更文挑战第18天】近期研究重新评估了KAN(Kolmogorov-Arnold Networks)与MLP(Multi-Layer Perceptrons)在网络性能上的差异。通过对多种任务领域的全面比较,包括机器学习、视觉、音频及NLP等,研究显示MLP在多数场景下性能更佳,仅在符号公式表示上KAN略胜一筹,而这优势源于其B-spline激活函数。有趣的是,KAN在连续学习中表现出更严重的遗忘问题。尽管研究提供了有价值的观点,但也指出了其实验局限性,强调了模型选择时需综合考量的重要性。[论文链接](https://arxiv.org/pdf/2407.16674)
500 5
|
算法 计算机视觉
YOLOv11改进策略【卷积层】| AKConv: 具有任意采样形状和任意参数数量的卷积核
YOLOv11改进策略【卷积层】| AKConv: 具有任意采样形状和任意参数数量的卷积核
892 0
YOLOv11改进策略【卷积层】| AKConv: 具有任意采样形状和任意参数数量的卷积核

热门文章

最新文章