一、Kubeflow 数据管理全景：存储架构概览、数据流转路径与核心组件关系

大家好，我是你们的讲师。今天咱们聊聊 Kubeflow 里最绕不开的话题——数据管理。说实话，我见过太多团队在模型训练上花了大把时间，最后却因为数据管不好，导致整个 pipeline 跑不起来。嗯，这其实是个老生常谈的问题，但 Kubeflow 给了我们一套挺优雅的解法。

1.1 Kubeflow 存储架构概览

先看整体架构。Kubeflow 的存储层，说白了就是围绕 Kubernetes 的 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）来设计的。我个人习惯把 PV 想象成一个“存储仓库”，PVC 就是“仓库租约”。你申请多大空间、什么访问模式，PVC 说了算。

但 Kubeflow 不止于此。它把存储分成了几个层次：

• 原始数据层：通常是对象存储（比如 MinIO、S3），存放原始数据集。
• 中间结果层：Pipeline 里每个步骤的输出，可能存成 Parquet、TFRecord 等格式，放在 PVC 或对象存储里。
• 模型与元数据层：训练好的模型、实验参数、指标等，交给 Metadata 组件管理。

我在项目中遇到过一种情况：团队把所有数据都塞到一个大 PVC 里，结果不同 pipeline 之间互相干扰，数据版本也乱成一锅粥。后来我们按 pipeline 粒度拆分 PVC，配合 ReadWriteMany 模式，才解决了这个问题。

1.2 数据在 ML 工作流中的流转路径

数据是怎么在 Kubeflow 里流动的？我画了一张图，帮你理清脉络。

你看，数据从源头进来，经过预处理、训练、评估，最后注册成模型。中间结果和元数据会持久化存储。这里有个关键点：每个步骤的输出，都可能成为下一个步骤的输入。我曾经见过一个 pipeline，因为中间结果没清理，导致磁盘爆满，训练任务直接 OOM。所以，数据流转路径上一定要做好生命周期管理。

1.3 核心组件的关系：PVC、Pipelines、Metadata

这三个组件，是 Kubeflow 数据管理的“铁三角”。它们怎么配合？我拆开来说。

1.3.1 PVC：数据的“临时工”与“长期工”

PVC 在 Kubeflow 里有两种用法：

• 临时 PVC：Pipeline 运行时动态创建，步骤结束后自动删除。适合中间结果。
• 持久 PVC：预先创建好，多个 pipeline 共享。适合原始数据、模型文件。

我记得有一次，团队把训练数据放在临时 PVC 里，结果 pipeline 重跑时数据全没了。后来我们改成持久 PVC + 数据版本控制，才稳下来。

1.3.2 Pipelines：数据的“调度员”

Pipelines 负责编排数据处理的每一步。每个步骤（Component）都会声明自己的输入输出，Kubeflow 会自动把数据从一个步骤传到下一个步骤。你想想看，如果没有 Pipelines，你得手动写脚本去搬运数据，多累啊。

Pipelines 里数据传递有两种方式：

• 小数据：通过参数传递（比如文件路径、配置字符串）。
• 大数据：通过 PVC 或对象存储传递（比如数据集、模型文件）。

1.3.3 Metadata：数据的“档案管理员”

Metadata 组件记录每次实验的“档案”：用了什么数据、什么参数、训练了多久、最终指标多少。它跟 PVC 和 Pipelines 的关系是这样的：

组件	职责	与 Metadata 的关系
PVC	存储原始数据、中间结果、模型	Metadata 记录 PVC 的名称、挂载路径、数据大小
Pipelines	编排数据处理步骤	Metadata 记录每次运行的输入输出、执行时间、状态
Metadata	存储实验元数据	自身就是数据管理的“大脑”

说白了，PVC 管数据“放哪”，Pipelines 管数据“怎么流”，Metadata 管数据“是什么”。三者缺一不可。

1.4 实战中的一点感悟

最后说点实在的。Kubeflow 的数据管理，核心就一句话：让数据在正确的时间，出现在正确的位置，并且能被正确的人找到。PVC 解决“位置”，Pipelines 解决“时间”，Metadata 解决“人”。

我在做第一个 Kubeflow 项目时，完全没管数据管理，结果模型上线后，想回溯训练数据都找不到。后来老老实实把 PVC、Pipelines、Metadata 配合好，才算是真正把 ML 工作流跑通了。

嗯，这一章就到这里。记住，数据是 ML 的命根子，管好数据，你的模型才能站得稳。

---

公众号:蓝海资料掘金营，微信deep3321