Fluid 1.0版发布，打通云原生高效数据使用的“最后一公里”-阿里云开发者社区

Fluid 1.0版发布，打通云原生高效数据使用的“最后一公里”

2024-06-04 120

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

数据管理 DMS，安全协同 3个实例 3个月

云原生大数据计算服务MaxCompute，500CU*H 100GB 3个月

容器服务 Serverless 版 ACK Serverless，317元额度多规格

简介： Fluid 1.0版发布，提供云原生数据编排与加速，支持多级数据亲和性调度、自定义数据操作、数据流自动化，成为云原生AI场景最佳选择。

【阅读原文】戳：Fluid 1.0版发布，打通云原生高效数据使用的“最后一公里”

前言

得益于云原生技术在资源成本集约、部署运维便捷、算力弹性灵活方面的优势，越来越多企业和开发者将数据密集型应用，特别是AI和大数据领域应用，运行于云原生环境中。然而，云原生计算与存储分离架构虽然带来了资源经济性与扩容灵活性方面的优势，但也引入了数据访问延迟和带宽开销的问题。

在数据访问接口层面，Kubernetes只提供了传统数据访问接入层面的接口，即异构存储服务接入和管理标准接口（CSI，Container Storage Interface），对应用如何在容器集群中高效使用和灵活管理数据并没有定义。然而，这是很多数据密集型应用依赖这样的高层数据访问和管理接口，例如：在运行AI模型训练任务时，数据科学家需要能够管理数据集版本、控制访问权限、数据集预处理、动态数据源更新、加速异构数据读取等。但是，在Fluid开源项目诞生之前，Kubernetes开源生态社区中还没有这样的标准方案，这是云原生环境拥抱大数据与AI应用的一块重要拼图。

为了解决这些挑战，由来自学术界的南京大学，工业界的阿里云容器服务团队和Alluxio开源社区共同发起了Fluid开源项目，通过对“计算任务使用数据的过程”进行抽象，提出了云原生弹性数据抽象概念（如：DataSet），并作为“一等公民”在Kubernetes中实现。围绕弹性数据集Dataset，我们创建了云原生数据编排与加速系统Fluid，来实现Dataset管理（CRUD操作）、权限控制和访问加速等能力。在2021年4月份进入云原生计算基金会（CNCF）之后，经过36个月的不断研发迭代和生产环境验证，现在正式发布了其成熟稳定的v1.0大版本。

Website：

https://fluid-cloudnative.github.io/

GitHub：

https://github.com/fluid-cloudnative/fluid

开源驱动发展，生产环境验证

Fluid的测试体系涵盖了每日进行的单元测试、功能测试、兼容性测试、安全测试以及实际应用场景测试。每次版本发布前，Fluid会在不同的Kubernetes版本中进行兼容性测试。

Fluid技术源自校企科研合作，项目正式开源后，吸引了来自不同行业，不同规模的社区用户将Fluid应用到更广泛的场景中：AIGC，大模型，大数据，混合云，云上开发机管理，自动驾驶数据仿真等。Fluid在支撑云上真实应用中不断迭代改进，并应用到生产环境中，系统的稳定性，性能和规模也变得成熟。

据公有云和私有云环境的统计，目前已有上千个Kubernetes集群在持续使用Fluid，其中在用户机器学习平台可以支持最大上万节点规模。每天在云原生环境中创建Fluid的用户主要来自互联网、科技、金融、电信、教育、自动驾驶与机器人、智能制造等领域。Fluid开源社区用户包括有小米、阿里巴巴集团、阿里云PAI机器学习平台、中国电信、微博、B站、360、乾象、作业帮、赢彻、虎牙、Oppo、云知声、云刻行、深势科技等。更多使用信息请查看注册用户列表。

部分用户也在Fluid开源社区分享了他们在不同场景的实践：

•[1]小米机器学习平台：基于Fluid的高效Serverless混合云容器AI平台

•[2]从资源弹性到数据弹性，乾象如何将云上量化研究效率提升40%？

•[3]深势科技基于Serverless容器为科研人员打造高效的开发平台

•[4]阿里集团基于Fluid+JindoCache加速大模型训练的实践

•[5]作业帮检索服务基于Fluid的计算存储分离实践

Fluid 1.0新增核心功能速览

Fluid v1.0的发布，带来了以下几项核心功能：

1.可灵活配置的多级数据亲和性调度机制

Fluid的多级数据亲和性调度能力允许用户根据数据集缓存的位置信息对任务进行调度，而无需深入了解底层数据缓存的具体排布。Fluid通过以下方式实现这一调度策略：

a. 数据缓存本地性级别：Fluid根据数据缓存的本地性，即数据与计算任务的距离，将数据访问划分为不同的级别。这可能包括同一个节点（Node）、机架（Rack）、可用区（Availability Zone）、区域（Region）等不同级别。

b. 优先调度策略：Fluid优先将计算任务调度到数据缓存所在的节点，实现最佳的数据本地性。如果无法实现最佳本地性，Fluid会根据数据的传输距离，将任务调度到不同级别的节点上。

c. 灵活配置性：考虑到不同云服务提供商和对亲和性定义的各不相同，Fluid支持基于label进行自定义配置。用户可以根据具体的云环境和集群配置，调整调度策略，以适应不同的需求。

功能详见：[6]Fluid支持分层数据缓存本地性调度（Tiered Locality Scheduling）

2. 增加自定义数据操作DataProcess和触发策略的丰富

Fluid负责在Kubernetes中编排数据和使用数据的计算任务，不仅包括上文提到的空间上的编排，也包括时间上的编排。空间上的编排意味着计算任务会优先调度到有缓存数据和临近缓存的节点上，这样能够提升数据密集型应用的性能。而时间上的编排则允许同时提交数据操作和任务，但在任务执行之前，要进行一些数据迁移和预热操作，以确保任务在无人值守的情况下顺利运行，提升工程效率。

为此，在最新版本的 Fluid里提供一种新的数据操作类型DataProcess，为数据科学家提供自定义数据处理逻辑的抽象；并且在此基础针对所有的Fluid数据操作提供不同的触发机制，包括：once, onEvent, Cron。

以下例子为每2分钟运行一次数据预热。

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: cron-dataload
spec:
  dataset:
    name: demo
    namespace: default
  policy: Cron
  schedule: "*/2 * * * *" # Run every 2 min

3. 数据流DataFlow

进一步地，Fluid提供DataFlow数据流功能，允许用户通过Fluid提供的API定义自动化的数据处理流程: DataFlow支持Fluid的全部数据操作，包括缓存预热（DataLoad），数据迁移（DataMigrate），数据备份（DataBackup）等面向运维侧人员的自动化数据操作和面向数据科学家的数据处理(DataProcess)相结合，实现简单的数据操作。

以下图为例，整个的顺序是：

a.将需要消费的数据从云上低速存储（例如：OSS、HDFS）迁移到高速存储（例如：JuiceFS，GPFS）

b.启动AI模型训练

c.AI模型训练完成后将数据迁移回低速存储

注：DataFlow数据流仅支持串联多个数据操作，根据定义的先后顺序一个一个执行。不支持多步骤并行执行、循环执行、按条件选择性执行等高级语义，如果用户有明确此类需求，推荐使用Argo Workflow或者Tekton。

4. 通过Python SDK使用Fluid

在实践中，我们发现数据科学家更倾向于应该用代码（Python）而不是 YAML 来定义。为此Fluid提供更高层次的Python 接口来简化数据集的自动化操作和数据流的编写，下面是上面流程的Python实现：

flow = dataset.migrate(path="/data/", \
                     migrate_direction=constants.DATA_MIGRATE_DIRECTION_FROM) \
                     .load("/data/1.txt") \
                     .process(processor=create_processor(train)) \
                     .migrate(path="/data/", \
                     migrate_direction=constants.DATA_MIGRATE_DIRECTION_TO) 
run = flow.run()

样例详见：[7]文末链接

5. 新增Vineyard对象缓存引擎支持

Fluid支持以插件的方式接入分布式缓存，目前已经支持Alluixo, JindoFS, JuiceFS等针对文件系统的分布式缓存引擎。在Fluid 1.0版本接入了分布式内存数据管理引擎Vineyard，结合了 Vineyard 的高效数据共享机制和 Fluid的数据任务编排能力，为数据科学家提供了以Python 作为操作接口的方式，让他们能以熟悉的方式高效地进行 Kubernetes 上的中间数据管理。

更多细节请查看：[8]Fluid携手Vineyard，打造Kubernetes上的高效中间数据管理

6. 更多其他更新

在生产环境使用开源软件，稳定，规模和安全一直是重中之重。因此这也是Fluid持续关注和加强的领域。

a. 服务于大规模Kubernetes场景

在大规模的Kubernetes生产环境中，Fluid的性能和扩展性已得到了很好验证。在真实的用户环境中，Fluid能够稳定地支持有超过一万个节点的集群。在每天24小时的运行周期内，Fluid负责处理超过2500个数据集的全生命周期管理和超过6000个通过Fluid挂载数据集访问数据的AI工作负载(总共约有12万个Pods)。

考虑到Fluid已被广泛地部署在几个大规模的生产级Kubernetes集群中，我们对Fluid的控制平面组件进行了压力测试。测试结果显示，Fluid的Webhook在3个副本的情况下能够以每秒125个请求（QPS）的速度处理Pods的调度请求，而Webhook处理请求的90%的延迟少于25毫秒。针对于Fluid的控制器，测试结果表明，每分钟能支持配置500个Fluid数据集以上的自定义资源。以上结果充分证明了Fluid可以满足规模化集群的使用场景。

b. FUSE挂载点自动恢复增强的生产可用

在大规模的模型训练和推理任务场景下，FUSE进程可能因为内存资源不足以及其他原因崩溃重启，造成业务容器内FUSE挂载点断联，出现数据访问异常并影响在线业务可用性。基于FUSE的存储客户端更容易发生这样的问题，一旦这些问题无法自动修复，则可能中断任务和服务，同时人工修复的复杂度和工作量也是巨大的。针对此问题，Fluid 1.0优化了自恢复机制，并且已经在多个规模化用户场景下上线。

c. 收敛Fluid组件的安全权限

在1.0版本中，为了实践“权限最小化”的原则，Fluid移除了不必要的RBAC资源访问和权限。

更多的更新可以查看：[9]文末链接

后续版本规划

帮助AI/大数据的用户在Kubernetes中更加高效、灵活、经济、安全地使用数据，这是Fluid开源项目的目标和愿景:

在1.0版本，Fluid进一步打破了数据和计算的壁垒，实现了用户可以从异构Kubernetes环境（包括runC和KataContainer）灵活使用异构数据源（对象存储，传统分布式存储，可编程的内存对象), 同时通过Alluxio，JuiceFS，JindoFS，Vineyard等多种分布式缓存引擎和数据亲和性调度提升应用访问数据的效率。

在未来版本中， Fluid会继续与Kubernetes云原生生态紧密结合，同时更加关注数据科学家的效率和体验，我们计划专注解决以下问题：

1.针对大模型推理场景的优化，面向多种场景提升大模型加载效率。

2.与Kubernetes调度器相结合，自适应地实现根据Kubernetes调度器的调度结果，选择合适的数据访问方式（CSI模式和sidecar模式的自动识别）。

3.除了面向运行环境，支持数据科学家在使用开发环境中更灵活地使用Fluid，例如：解决数据源变更带来的容器重新启动，易造成临时数据丢失方面的问题。

致谢

我们感谢所有为Fluid 1.0版本发布付出努力的开源项目贡献者！详细贡献内容和贡献者信息请参见[10]Fluid开源项目1.0版本release note

我们感谢Fluid开源社区用户给予的开源项目验证反馈和支持！Fluid开源社区用户公开信息登记列表请参见[11]文末链接

相关链接：

[1]小米机器学习平台：基于Fluid的高效Serverless混合云容器AI平台

https://www.infoq.cn/article/kco7hi5TcVE08ySwNIw7

[2]从资源弹性到数据弹性，乾象如何将云上量化研究效率提升40%？

https://www.infoq.cn/article/AwaZ5xmgwguT7PJkYU2Q