lakeFS vs DVC：版本控制想要成为文件系统
更新于 2025年9月28日
12 分钟
lakeFS vs DVC：版本控制想要成为一个文件系统
关于数据版本控制，大家似乎都认可它就是适用于一切的 Git——直到你尝试在一个团队中使用它来处理 PB 级的数据时，才会意识到 Git 实际上是用于代码的 Git。“就像对待你的 S3 存储桶一样对待你的代码仓库”，他们会这样说，这就像告诉交响乐团使用卡祖笛，因为它在技术上也是一种管乐器。
这是一个关于两种共享同一口号的世界观的故事：lakeFS vs DVC。两者都承诺在数据、模型和实验通常会迷失的地方提供理智。但它们从相反的方向着手解决问题。DVC 是一种开发者优先、与 Git 相邻的工具包，与你的代码仓库并肩作战。lakeFS 是一个存储原生层，它将你的对象存储变成一个具有分支、提交和合并的版本化文件系统。同样的旋律，不同的调号。
如果你是为了寻找结论而来：你可能已经知道你属于哪个阵营。如果你的日常痛苦是在保证可重复性的前提下移动大型文件和模型检查点，那么 DVC 会让你感觉像是一根非常巧妙的延长线。如果你的痛苦是多团队数据治理、隔离以及在数据湖上进行可重复读取，那么 lakeFS 就像是在实际房屋中安装断路器。
是的，你可以同时使用两者。这不是逃避问题。而是承认数据工作是许多工作穿着同一件 T 恤衫。
现状：DVC 和 lakeFS 实际上做什么
- DVC（数据版本控制）：存在于 Git 旁边，而不是在 Git 内部。你在 Git 中对指针（微小的元文件）进行版本控制，并将实际的大型工件——数据集、模型、图像——存储在 S3、GCS、Azure、SSH 或本地缓存等远程位置。你可以获得 CLI 驱动的流水线、用于可重复性的
dvc.lock、实验跟踪以及用于同步的dvc push/pull。
- lakeFS：位于你的对象存储（S3、GCS、Azure Blob）之前，并将分支和提交作为存储命名空间的一流特性。读取和写入会看到隔离的分支。你可以从“生产环境”创建一个分支，运行转换，然后合并回去——而无需复制 TB 级的数据。它是用于你的数据湖的类 Git 语义。
换句话说：DVC 将数据管理嫁接到开发者工作流程上；lakeFS 将工作流程语义刻入数据层。
核心差异（以及它为什么重要）
DVC 将大型数据视为代码库的扩展。一切都从 Git 代码仓库开始：你提交
*.dvc 文件，锁定依赖项，并编排流水线。非常适合 ML 实验，因为出处与创建它的代码位于一起。lakeFS 则相反：数据湖是真理的来源。分支不是隐喻——它们是同一底层对象上的命名空间。这意味着你可以：
- 在几秒钟内启动一个 200 TB 数据集的
feature/try-new-schema分支。
- 像对待真实数据一样在该分支上运行 Spark/Presto/Trino，因为它就是真实的。
- 合并（或中止）而无需移动整个数据湖。
你无法用巧妙的 Git 钩子来伪造这一点。
lakeFS vs DVC：不带营销色彩的用例
DVC 何时胜出
- 以模型为中心的团队：你拥有代码、数据快照和实验，这些必须是可重复且可共享的。DVC 的实验跟踪和
dvc repro流水线大放异彩。
- 单一代码仓库规范：你的组织生活在 Git 中。你想要“数据即代码”而无需发明存储抽象。DVC 很熟悉，
git add data.dvc，完成。
- 预算和简单性：无需运行任何基础设施层。DVC 可以与普通的 S3 存储桶和权限策略一起工作。CLI 很简单明了。本地优先是一个特点。
lakeFS 何时胜出
- 大规模的团队隔离：你需要多个团队安全地在同一数据湖上运行写入/读取操作，而不会相互干扰。基于分支的隔离是关键。
- 治理和审计：在存储边界的提交历史记录、可重复的快照和策略钩子。你可以在重要的地方强制执行规则。
- 大型引擎，大型表：Spark、Hive、Presto、Trino、Snowflake 外部表——可以识别对象存储的工具。lakeFS 在 URL 级别集成；你的计算堆栈不需要学习新的技巧。
何时同时使用两者（并感觉很聪明）
- DVC 用于与代码仓库绑定的模型工件和流水线；lakeFS 用于数据湖中的原始和精心策划的数据集。在 DVC 中跟踪和固定引用 lakeFS 提交哈希的数据集版本。代码存在于 Git 中；数据语义存在于数据湖中。没有人需要假装另一层可以很好地完成这两项工作。
lakeFS vs DVC：实际的权衡
设置和操作
- DVC：安装 CLI，配置远程仓库。你将管理缓存大小、存储成本和访问权限。Git 仍然是你的主基地。最小的摩擦。
- lakeFS：你正在运行一项服务。有一个服务器、元数据、GC、分支策略、凭据。不难，但它是基础设施。回报是数据湖上真正的隔离和原子提交。
性能和规模
- DVC：使用本地缓存和硬链接，推送/拉取大型工件可以很快，但该模型从根本上说是客户端驱动的。你不会在几毫秒内创建一个 PB 级的分支；你将引用它并根据需要移动部分。
- lakeFS：分支是元数据廉价的（写时复制）。读取是“原生速度”，因为它们只是对象存储读取。写入会产生间接成本，但不会产生“复制世界”的惩罚。合并冲突确实存在，但它们位于对象/键级别，而不是代码行级别。
可重复性
- DVC：你的
dvc.lock将代码、参数和数据工件哈希绑定在一起。重新运行上个月的实验应该会产生相同的位。这是代码边界上的可重复性。
- lakeFS：数据边界上的可重复性：“读取提交 Y 时的表 X。”你可以对整个输入表面进行时间旅行，以进行分析或回填。
协作模式
- DVC：以开发者为中心的协作——PR、审查和实验。非常适合 ML 循环：数据 → 训练 → 评估 → 发布。
- lakeFS：以数据团队为中心的协作——用于摄取、转换和验证的分支。非常适合分析循环：摄取 → 建模（如 dbt/ETL）→ 发布 → 服务。
简单英语的数据合约
人们说“数据合约”并开始挥舞模式注册表屏幕截图。这是简单版本：
- 使用 DVC，合约隐式地存在于你的流水线中：你声明为依赖项的文件构成合约。更改它们，你的流水线就会知道。
- 使用 lakeFS，可以在合并时强制执行合约：合并前钩子可以运行验证（模式检查、行计数、空值阈值），并阻止错误数据到达
main分支。它是房间里的大人。
开发者体验 (DX)：真刀真枪的地方
- CLI 人体工程学：DVC 的 CLI 是固执己见的，但可以预测：
dvc add、dvc push、dvc exp run。lakeFS 的 CLI（和 UI）在数据集级别考虑分支/提交：lakefs branch create、commit、merge。
- 心智模型：DVC 要求开发人员像对待带有哈希的第三方二进制文件一样对待数据。lakeFS 要求数据工程师像对待具有隔离层的文件仓库一样对待数据湖。
- 认知负荷：DVC 增加了每个代码仓库的仪式；lakeFS 增加了基础设施和策略。根据你的团队的所在地——IDE 或数据平台——来选择你的毒药。
成本：时间、金钱和云出口带宽的烦恼
- 存储：两者都有效地使用对象存储。如果你对缓存不小心，DVC 可能会复制工件；lakeFS 依赖于写时复制元数据，这种元数据在数据搅动之前很便宜。
- 出口带宽和移动：DVC 的推送/拉取会产生更多的对象搅动。lakeFS 的读取在很大程度上是直通的。如果出口带宽成本让你夜不能寐，那么 lakeFS 的“无复制分支”模型是友好的。
- 运维开销：DVC 的成本主要是开发人员的时间。lakeFS 的成本是服务维护——备份、升级、策略。
锋利的边缘（没有人喜欢谈论这些）
- DVC 合并冲突不是魔法：你不是在合并 CSV 行。你正在协调哪些 blob 获胜。对于细粒度的合并，你仍然需要实际的数据处理。
- lakeFS 合并语义不是 SQL：你可以分支和合并 S3 路径，但协调语义表更改（分区重新排列、更新插入）是你的工作，而不是 lakeFS 的工作。将其视为文件系统，而不是数据库。
- 访问控制是不同的：DVC 继承了 Git 的社交模型（PR、审查）。lakeFS 与 IAM 和策略挂钩集成。如果你的组织已经集中管理了数据的 IAM，那么 lakeFS 会感觉很自然；如果你生活在 GitHub 中，那么 DVC 会感觉很正确。
集成：引擎、编排器和现实世界
- DVC：可以很好地与 GitHub/GitLab CI、Makefile、Airflow 和本地开发配合使用。对于 ML 实验，DVC 的实验跟踪和工件管理是吸引人的地方。
- lakeFS：可以很好地与 Spark、Hive、Trino、Presto、dbt（通过外部表）、Airflow 以及任何读取
s3a://repo/branch/path的引擎配合使用。诀窍在于你的计算使用相同的存储语言。
没有流行语的安全性和合规性
- DVC：安全性取决于你的云存储和你的 Git 权限。可审计性位于流水线级别——什么产生了什么，以及何时产生。
- lakeFS：每个提交都是一个审计检查点。钩子可以在合并之前扫描数据。如果你关心 GDPR 风格的“何时更改了什么”，那么 lakeFS 更适合。
简单英语的正面交锋
- 主要关键词——“lakeFS vs DVC” 不仅仅是一个比较；它是哲学上的一个分叉。DVC 是具有大型文件和实验的 Git-with-benefits。lakeFS 是你的数据实际存在的类 Git 语义。
- 如果你的大部分时间都在处理接触 数据 的 代码，那么你会对 DVC 感到更满意。
- 如果你的大部分时间都在处理有时会遇到 代码 的 数据，那么你可能会选择 lakeFS。
- 如果你的时间既有代码又有数据，那么恭喜你：你是正常的。对面向代码的循环使用 DVC，对面向数据湖的循环使用 lakeFS。“两者”不是优柔寡断——它是准确的。
关于工具炒作的说明（以及 Sider.AI 的适用性）
只有当工具可以节省时间或防止混乱时，它们才是有趣的。其他一切都是演示。Sider.AI 实际上在这里有所帮助——不是通过假装成为你的数据湖，而是通过做那些不吸引人的工作：帮助你推理你的流水线，生成护栏检查，并保持你的文档和差异的真实性。如果你要将 DVC 和 lakeFS 连接在一起，Sider.AI 是明智的朋友，他说“标记你的断路器”，然后打印标签。
实践场景：真实环境中的 lakeFS vs DVC
场景 1：ETL 的功能隔离
- 你维护一个 Bronze/Silver/Gold 数据湖。你想要测试一个新的点击流摄取模式，而不会破坏下游仪表板。使用 lakeFS，从
silver分支etl/schema-v2，运行你的作业，在隔离环境中进行验证，并在检查通过后合并。没有影子存储桶，没有过夜副本。
场景 2：可重复的训练运行
- 你每周训练模型。DVC 固定确切的数据集快照（
data.dvc指向 lakeFS 提交或 S3 版本）、参数和代码。dvc repro启动运行。模型、指标和图是你可以推送和共享的工件。审计员喜欢这个。未来的你也会喜欢。
场景 3：修复错误的发布
- 有人将格式错误的 Parquet 集发布到
main。使用 lakeFS，你可以回滚到上一个良好的提交或分支，进行修补并合并。使用 DVC，你将在流水线中修复它并重新推送工件。两者都有效；当“发布”意味着“每个人都读取的数据湖”时，lakeFS 更好。
没有眼泪的迁移和共存
- 首先命名你的真相：哪些数据集是系统记录？哪些是短暂的？将系统记录放在 lakeFS 中。将实验工件放在 DVC 中。
- 轻量级集成：在 DVC 参数或元数据中存储 lakeFS 提交 ID。将它们视为不可变的数据集版本。
- 不要煮沸整个数据湖：在隔离可以为你节省真金白银或周末时间的地方采用 lakeFS。在可重复性可以为你节省重新运行的地方采用 DVC。
辩证法：它不是非此即彼，而是真理所在
软件团队想要一个工具来统治它们。这是一个错误的问题。正确的问题是：真理在哪里？
- 如果真理位于代码仓库中——代码、配置以及你训练的特定文件——那么 DVC 是 Git 的自然扩展。
- 如果真理位于数据湖中——为你的公司提供支持的表、分区和对象键——那么 lakeFS 会为你提供提交时的理智。
两者都是版本控制的形式。只有一种实际存在于数据所在的位置。
lakeFS vs DVC：人们实际提出的问题的快速解答
- “DVC 可以取代我的数据湖吗？” 不能。它可以组织你的工件并使实验变得理智。它不会使 S3 的行为像事务性存储。
- “lakeFS 可以取代我的 ML 实验跟踪器吗？” 也不能。它可以对实验的输入/输出进行版本控制，但它不关心你的 ROC 曲线。
- “这不只是 Git LFS 吗？” 这就像说自行车只是一辆金属较少的汽车。DVC 与 Git 相邻，但了解数据流水线。lakeFS 为你提供类 Git 语义，而无需将 Git 拖入 PB 级数据。
关于复杂性的简短说明（你总会在某个地方付出代价）
每个抽象都是稍后到期的账单。DVC 的账单是开发人员的仪式和偶尔的工件争论。lakeFS 的账单是运行服务并学习对象存储的新合并语义。如果一个工具看起来是免费的，那么它就会占用你的注意力。
告别一击
“lakeFS vs DVC”读起来像是一场对决。它更像是两个不演奏相同乐器的音乐家。你不会要求鼓手演奏旋律，也不会要求小提琴为进行乐队保持时间。在代码拥有循环的地方使用 DVC。在数据拥有房间的地方使用 lakeFS。如果你生活在两个世界中，那就太好了：这意味着你正在关注。
因为版本控制的真正意义——无论是包装 Git 还是包装 S3——都不是提交哈希。这是在不破坏世界的情况下更改事物的权限。其他一切都只是标签栏。
对关键词友好的简单语言标题（因为你问了）
用于 ML 流水线的 lakeFS vs DVC
如果你的 ML 流水线是代码繁重的，具有离散数据集和模型工件，那么 DVC 集成得更好：Git 中的指针文件、哈希、跟踪的实验。对于为多个团队提供数据的数据繁重流水线，lakeFS 通过跨整个数据湖的基于分支的隔离获胜。
用于数据治理的 lakeFS vs DVC
lakeFS 为你在存储边界提供可审计的提交和合并挂钩。DVC 为你提供流水线边界的来源。如果法律想要不可变的检查点，那就是 lakeFS；如果工程想要可重复的运行，那就是 DVC。
为对象存储选择 DVC 和 lakeFS
对象存储不执行事务。DVC 使用对象级哈希和推送/拉取来解决这个问题。lakeFS 通过写时复制元数据和分支语义来实现。根据你的痛苦是在代码仓库中还是在存储桶中来选择。
组合 lakeFS 和 DVC 而不会头痛
使用 lakeFS 对数据湖进行版本控制；将提交 ID 呈现给 DVC，以便实验固定到确切的输入。将模型工件保存在 DVC 远程仓库中；将原始和精心策划的数据集保存在 lakeFS 分支中。无需未经授权的黑客攻击。
FAQ
问题 1：哪个更适合 ML 实验：lakeFS 还是 DVC？
对于 ML 实验，DVC 通常会获胜。它将代码、参数、数据集和模型联系在一起，而 lakeFS 在数据湖级别处理数据集隔离和时间旅行。
问题 2：我可以一起使用 lakeFS 和 DVC 而不会造成混乱吗？
是的。使用 lakeFS 提交来对你的数据湖数据集进行版本控制，并在 DVC 中引用这些提交 ID。让 DVC 处理工件和流水线；让 lakeFS 处理对象存储上的分支和合并。
问题 3：DVC 是否取代数据湖或 lakeFS？
不。DVC 在 Git 周围组织大型文件和实验；它不会将 S3 变成事务性存储。lakeFS 位于你的数据湖之前，并添加分支、提交和隔离。
问题 4：lakeFS 对于小型团队来说是否矫枉过正？
通常，是的。如果你没有处理多团队隔离或治理，那么 DVC 的简单性很有吸引力。当基于分支的隔离和审计跟踪可以节省真金白银或中断时，lakeFS 才有意义。
问题5：lakeFS 与 DVC 的成本相比如何？
DVC 的成本倾向于开发人员的时间以及推送/拉取期间的存储变更。lakeFS 的成本倾向于运行服务和管理策略，但分支的成本很低且对出口友好。
