Git
- DVC 在 Git 的基础上引入了数据文件的概念。即大文件不应存储在 Git 存储库中，但仍需要跟踪和版本化。 它利用 Git 的功能来管理不同版本的数据、数据流水线和实验。
- DVC 从根本上不绑定到 Git，并且可以在没有它的情况下工作（与版本控制相关的功能除外）。
Git-LFS (Large File Storage)
- DVC 不需要像 Git-LFS 那样，有特殊的服务器需求。 任何云存储，如 S3、谷歌云存储，甚至 SSH 服务器都可以用作远程存储。不需要额外的数据库、服务器或基础设施。
- 默认情况下，DVC 不会向 Git 存储库添加任何钩子（Hook）（尽管它们可用）。
- Git-LFS 没有考虑到数据科学，因此它不提供相关功能（例如：流水线、指标等）。
- GitHub（最常见的 Git 托管服务）每个存储库的限制为 2 GB。
Hook 简述
Hook 就是在执行某个事件之前或之后进行一些其他额外的操作。 在Git 中，有许多的事件（commit、push等），每个事件对应了有不同的钩子（如 commit 前，commit 后），那么我们就可以在这些钩子这里配置一些自己需要执行的操作来实现各种各样的需求。
Git-annex
- DVC 可以使用
reflinks*或硬链接（取决于系统）而不是符号链接来提高性能和用户体验。 - Git-annex 是一个以数据文件为中心的系统，而 DVC 专注于为机器学习和可重复实验提供工作流程。 当通过
git clone克隆 DVC 或 Git-annex 存储库时，数据文件不会被复制到本地计算机，因为文件内容存储在单独的远程存储仓库。 但是，对于 DVC，提供可重现工作流的.dvc文件始终包含在 Git 存储库中。 因此，它们可以在本地以最小的工作量执行。 - DVC 优化文件哈希计算。
- 写时复制链接或"引用链接" 是在 UNIX 风格文件系统中链接文件的一种相对较新的方式。 与硬链接或符号链接不同，它们支持透明的写时复制。 这意味着编辑重新并链接的文件始终是安全的，因为该文件的所有其他链接都将显示更改。
Git 工作流程/方法，例如：Gitflow
- DVC 启用了一种新的实验方法，可以轻松地与现有的 Git 工作流集成。 例如，可以为每个实验创建一个单独的分支，如果实验成功，则随后合并该分支。
- DVC 通过让用户能够轻松浏览过去的实验而无需每次都重新计算来实现创新。
工作流管理系统
流水线和依赖图 (DAG)，例如：Airflow、Luigi等。
- DVC 专注于数据科学和建模。 因此，DVC 流水线是轻量级的，易于创建和修改。 但是，DVC 缺乏高级流水线执行功能，例如：执行监控、错误处理和恢复。
dvc是纯粹的命令行工具，没有图形用户界面 (GUI)，不运行任何守护程序或服务器。 尽管如此，DVC 可以生成带有管道和实验工作流可视化的图像。- 另请参阅我们的姊妹项目 CML，它有助于填补其中的一些空白。
实验管理软件
另请参阅实验管理指南。
- DVC 使用 Git 作为数据、管道和实验的底层版本控制层。 数据版本作为元数据存在于 Git 中，而不是使用外部数据库或 API，因此不需要额外的服务。
- DVC 不需要运行任何服务。 因此没有内置的 GUI，但我们也有我们的姊妹项目 Studio 来填补这一空白。
- DVC 可以生成带有实验工作流可视化的图像。
- DVC 具有透明设计。 DVC 文件具有人类可读的格式，可以很容易地被外部工具重复使用。
构建自动化工具
Make 或者其他。
文件追踪
- DVC 根据其哈希值 (MD5) 而不是使用时间戳来跟踪文件。 这有助于避免在签出（checkout）项目的先前版本时遇到繁重的过程，例如：模型重新训练（Make 将会重新训练模型）。
- DVC 使用文件时间戳和 inode* 进行优化。 这允许 DVC 避免重新计算所有依赖文件哈希，这在处理大文件（多 GB）时会出现很大问题。
DVC使用有向无环图（DAG）
- DAG 或依赖图由 stages 之间的连接隐式定义，基于它们的依赖关系和输出。
- 每个 stages 在 DAG 中定义一个节点，并且
dvc.yaml文件包含这些 stages 的定义（想想Makefiles）。 所有 stages（和相应的过程）通过它们的输入和输出隐式组合，简化了合并期间的冲突解决。 - DVC stages 可以在
dvc.yaml文件中手动编写或由辅助命令生成 dvc run（基于终端命令）编写其输入和输出。
- 索引节点是元数据文件记录，用于定位和存储对实际文件内容的权限。 有关技术的详细信息，请参阅此文档中的链接文件 (Linux)。
