lakeFS vs DVC：版本控制想成為檔案系統
更新於 2025年9月28日
12 分鐘
lakeFS vs DVC：版本控制想要成為檔案系統
關於資料版本控制，大家都會點頭同意，認為它就像是所有東西的 Git——直到你嘗試在一個團隊中使用它來處理 PB 級別的資料，才會發現 Git 實際上只是程式碼的 Git。「只要把你的 S3 bucket 當作 repo 就好了，」他們會這樣說，這就像是告訴交響樂團使用卡祖笛，因為它嚴格來說也是一種管樂器。
這是一個關於兩種共享標語的世界觀的故事：lakeFS vs DVC。兩者都承諾在資料、模型和實驗通常會迷失的地方提供理智。但它們從相反的方向來解決問題。DVC 是一個以開發者為先、與 Git 相鄰的工具包，與你的 repo 並肩作戰。lakeFS 是一個儲存原生層，將你的物件儲存變成一個具有分支、提交和合併的版本控制檔案系統。同樣的旋律，不同的調性。
如果你是來尋求結論的：你可能已經知道你屬於哪個陣營。如果你的日常痛苦是在可重現性的前提下移動大型檔案和模型檢查點，DVC 會感覺像是一條非常聰明的延長線。如果你的痛苦是多團隊資料治理、隔離以及對資料湖的可重現讀取，那麼 lakeFS 感覺就像是在實際房屋中安裝斷路器。
是的，你可以同時使用兩者。這不是逃避。這是一種承認，資料工作是許多工作穿著同一件 T 恤。
現狀：DVC 和 lakeFS 實際上做了什麼
- DVC (Data Version Control)：位於 Git 旁邊，而不是在 Git 裡面。你可以在 Git 中對 指標（微小的元檔案）進行版本控制，並將實際的大型 artifacts——資料集、模型、圖像——儲存在像 S3、GCS、Azure、SSH 或本地快取這樣的遠端位置。你可以獲得 CLI 驅動的 pipelines、用於可重現性的
dvc.lock、實驗追蹤以及用於同步的dvc push/pull。
- lakeFS：位於你的物件儲存（S3、GCS、Azure Blob）前面，並使分支和提交成為儲存命名空間的一流特性。讀寫操作會看到隔離的分支。你可以從「production」建立一個分支，執行轉換，然後合併回去——而無需複製 TB 級別的資料。這是用於你的資料湖的類似 Git 的語義。
換句話說：DVC 將資料管理嫁接到開發者工作流程中；lakeFS 將工作流程語義刻入資料層。
核心差異（以及為什麼它很重要）
DVC 將大型資料視為你的程式碼庫的延伸。一切都從 Git repo 開始：你提交
*.dvc 檔案，鎖定 dependencies，並協調 pipelines。非常適合 ML 實驗，其中 provenance 與建立它的程式碼位於一起。lakeFS 顛倒了它：資料湖是真理的來源。分支不是隱喻——它們是同一底層物件上的命名空間。這意味著你可以：
- 在幾秒鐘內啟動一個 200 TB 資料集的
feature/try-new-schema分支。
- 像對待真實資料一樣，在該分支上運行 Spark/Presto/Trino，因為它確實是真的。
- 合併（或中止）而無需重新整理整個湖。
你無法用聰明的 Git hooks 來偽造它。
lakeFS vs DVC：沒有行銷術語的使用案例
DVC 獲勝的情況
- 以模型為中心的團隊：你有程式碼、資料快照和實驗，這些必須是可重現且可共享的。DVC 的實驗追蹤和
dvc repropipelines 非常出色。
- 單一 repo 紀律：你的組織生活在 Git 中。你想要「資料即程式碼」，而無需發明儲存抽象。DVC 很熟悉，
git add data.dvc，完成。
- 預算和簡化：沒有要運行的 infra 層。DVC 可以與普通的 S3 bucket 和權限策略一起使用。CLI 很簡單。本地優先是一個功能。
lakeFS 獲勝的情況
- 大規模的團隊隔離：你需要多個團隊在同一個湖上安全地運行讀寫操作，而不會互相干擾。基於分支的隔離是重點。
- 治理和稽核：儲存邊界的提交歷史、可重現的快照和策略 hooks。你可以在它們重要的地方強制執行規則。
- 大型引擎、大型表格：Spark、Hive、Presto、Trino、Snowflake 外部表格——可以與物件儲存對話的工具。lakeFS 在 URL 層級整合；你的計算堆疊不需要學習新的技巧。
何時同時使用兩者（並感覺很聰明）
- DVC 用於與 repo 綁定的 模型 artifacts 和 pipelines；lakeFS 用於湖中的 原始和精選資料集。在 DVC 中追蹤和固定引用 lakeFS 提交雜湊的資料集版本。程式碼存在於 Git 中；資料語義存在於湖中。沒有人需要假裝另一個層可以很好地完成這兩項工作。
lakeFS vs DVC：實際的權衡
設定和運營
- DVC：安裝 CLI，配置 remotes。你將管理快取大小、儲存成本和存取權限。Git 仍然是你的基地。最小的摩擦。
- lakeFS：你正在運行一個服務。有一個伺服器、元資料、GC、分支策略、憑證。不難，但它是 infrastructure。回報是在資料湖上的真正隔離和原子提交。
效能和規模
- DVC：使用本地快取和硬連結，pushing/pulling 大型 artifacts 可能很快，但該模型從根本上是客戶端驅動的。你不會在幾毫秒內分支一個 PB 級別的資料；你將引用它並根據需要移動 pieces。
- lakeFS：分支是元資料廉價的（寫時複製）。讀取是「原生速度」，因為它們只是物件儲存讀取。寫入會產生間接性，但不會產生「複製世界」的懲罰。合併衝突存在，但它們位於物件/金鑰層級，而不是程式碼行。
可重現性
- DVC：你的
dvc.lock將程式碼、參數和資料 artifact 雜湊連結在一起。從上個月重新運行實驗應該產生相同的位元。這是程式碼邊界的可重現性。
- lakeFS：資料邊界的可重現性：「讀取截至提交 Y 的表格 X。」你可以對整個輸入 surface 進行時間旅行，以進行分析或 backfills。
協作模型
- DVC：以開發者為中心的協作——PR、審閱和實驗。非常適合 ML 迴圈：資料 → 訓練 → 評估 → 發布。
- lakeFS：以資料團隊為中心的協作——用於提取、轉換和驗證的分支。非常適合分析迴圈：提取 → 模型（如 dbt/ETL）→ 發布 → 服務。
簡單英語的資料合約
人們說「資料合約」並開始揮舞 schema registry 螢幕截圖。這是簡單版本：
- 使用 DVC，合約隱含在你的 pipeline 中：你宣告為 dependencies 的檔案構成合約。更改它們，你的 pipeline 就會知道。
- 使用 lakeFS，可以在合併時強制執行合約：合併前 hooks 可以運行驗證（schema 檢查、行數、空值閾值），並阻止不良資料到達
main分支。它是房間裡的大人。
開發者體驗 (DX)：橡膠與道路的交匯處
- CLI 人體工學：DVC 的 CLI 是固執己見但可預測的：
dvc add、dvc push、dvc exp run。lakeFS 的 CLI（和 UI）在資料集層級考慮分支/提交：lakefs branch create、commit、merge。
- 心智模型：DVC 要求 devs 將資料視為具有雜湊的第三方二進位檔案。lakeFS 要求資料工程師將湖視為具有隔離層的 repo。
- 認知負荷：DVC 增加了每個 repo 的儀式；lakeFS 增加了 infra 和策略。根據你的團隊已經存在的地方——IDE 或資料平台——來選擇你的毒藥。
成本：時間、金錢和雲端出口的麻煩
- 儲存：兩者都有效地使用物件儲存。如果你對快取不小心，DVC 會複製 artifacts；lakeFS 依賴於寫時複製元資料，這在 churn 之前很便宜。
- 出口和移動：DVC 的 push/pull 會產生更多的物件 churn。lakeFS 讀取在很大程度上是直通的。如果出口成本讓你夜不能寐，那麼 lakeFS 的「無複製分支」模型是友好的。
- 運營開銷：DVC 的成本主要是開發者時間。lakeFS 的成本是服務維護——備份、升級、策略。
鋒利的邊緣（沒有人喜歡談論這些）
- DVC 合併衝突不是魔法：你不是在合併 CSV 列。你正在協調哪些 blobs 獲勝。對於細粒度的合併，你仍然需要實際的資料處理。
- lakeFS 合併語義不是 SQL：你可以分支和合併 S3 路徑，但協調語義表格更改（分割區重新整理、upserts）是你的工作，而不是 lakeFS 的工作。考慮檔案系統，而不是資料庫。
- 存取控制是不同的：DVC 繼承了 Git 的社交模型（PR、審閱）。lakeFS 與 IAM 和策略 hooks 整合。如果你的組織已經集中化了資料的 IAM，那麼 lakeFS 感覺很自然；如果你生活在 GitHub 中，那麼 DVC 感覺是對的。
整合：引擎、協調器和真實世界
- DVC：與 GitHub/GitLab CI、Makefiles、Airflow 和本地開發配合良好。對於 ML 實驗，DVC 的實驗追蹤和 artifacts 管理是吸引人的地方。
- lakeFS：與 Spark、Hive、Trino、Presto、dbt（通過外部表格）、Airflow 以及任何讀取
s3a://repo/branch/path的引擎配合良好。訣竅是你的計算說相同的儲存語言。
沒有流行語的安全性和合規性
- DVC：安全性取決於你的雲端儲存和你的 Git 權限。可稽核性位於 pipeline 層級——什麼產生了什麼，以及何時。
- lakeFS：每個提交都是一個稽核檢查點。Hooks 可以在合併之前掃描資料。如果你關心 GDPR 風格的「什麼時候更改了什麼」，那麼 lakeFS 是一個更好的選擇。
簡單英語的正面交鋒
- 主要關鍵字——「lakeFS vs DVC」 不僅僅是一個比較；它是哲學上的一個分叉。DVC 是具有大型檔案和實驗優勢的 Git。lakeFS 是你的資料實際存在的 Gitlike 語義。
- 如果你的日子主要是接觸 資料 的 程式碼，你將會對 DVC 感到更滿意。
- 如果你的日子主要是偶爾遇到 程式碼 的 資料，你可能會選擇 lakeFS。
- 如果你的日子兩者都是，恭喜你：你是正常的。對面向程式碼的迴圈使用 DVC，對面向湖的迴圈使用 lakeFS。「兩者」不是優柔寡斷——它是準確的。
關於工具炒作的說明（以及 Sider.AI 的適用位置）
工具只有在節省時間或防止混亂時才有趣。其他一切都是演示。Sider.AI 實際上在這裡有所幫助——不是假裝成為你的湖，而是通過做那些不迷人的工作：幫助你推理你的 pipelines、生成 guardrail 檢查，並保持你的文件和差異的誠實性。如果你要將 DVC 和 lakeFS 連接在一起，Sider.AI 是明智的朋友，他說：「標記你的斷路器」，然後列印標籤。
實用情境：野外的 lakeFS vs DVC
情境 1：ETL 的功能隔離
- 你維護一個 Bronze/Silver/Gold 湖。你想要測試 clickstream 提取的新 schema，而不會破壞下游儀表板。使用 lakeFS，從
silver分支etl/schema-v2，運行你的工作，在隔離中驗證，並在檢查通過後合併。沒有影子 buckets，沒有隔夜副本。
情境 2：可重現的訓練運行
- 你每週訓練模型。DVC 固定確切的資料集快照（
data.dvc指向 lakeFS 提交或 S3 版本）、參數和程式碼。dvc repro啟動運行。模型、指標和圖表是可以推送和共享的 artifacts。稽核員喜歡這個。未來的你也是如此。
情境 3：修復不良發布
- 有人將格式錯誤的 Parquet 集合發布到
main。使用 lakeFS，你回滾到最後一個良好的提交或分支，修補並合併。使用 DVC，你正在 pipeline 中修復它並重新推送 artifacts。兩者都有效；當「發布」意味著「每個人都讀取的湖」時，lakeFS 更好。
沒有眼淚的遷移和共存
- 首先 命名你的真相：哪些資料集是系統記錄？哪些是短暫的？將系統記錄放在 lakeFS 中。將實驗 artifacts 放在 DVC 中。
- 精簡整合：在 DVC 參數或元資料中儲存 lakeFS 提交 ID。將它們視為不可變的資料集版本。
- 不要煮沸湖：在隔離可以節省你真金白銀或週末的地方採用 lakeFS。在可重現性可以節省你重新運行的地方採用 DVC。
辯證法：這不是非此即彼，而是真理所在
軟體團隊想要一個工具來統治它們。這是錯誤的問題。正確的問題：真理在哪裡？
- 如果真理在 repo 中——程式碼、配置和你訓練的特定檔案——DVC 是 Git 的自然延伸。
- 如果真理在湖中——為你的公司提供支援的表格、分割區和物件金鑰——lakeFS 為你提供提交時的理智。
兩者都是版本控制的形式。只有一個實際存在於資料所在的位置。
lakeFS vs DVC：人們實際提出的問題的快速解答
- 「DVC 可以取代我的資料湖嗎？」不能。它可以組織你的 artifacts 並使實驗變得理智。它不會使 S3 表現得像一個交易儲存。
- 「lakeFS 可以取代我的 ML 實驗追蹤器嗎？」也不能。它可以對實驗的輸入/輸出進行版本控制，但它不關心你的 ROC 曲線。
- 「這不只是 Git LFS 嗎？」這就像說自行車只是一輛金屬較少的汽車。DVC 與 Git 相鄰，但了解資料 pipelines。lakeFS 為你提供類似 Git 的語義，而無需將 Git 拖入 PB 級別的資料中。
關於複雜性的簡要說明（你總會在某處付出代價）
每個抽象都是以後到期的帳單。DVC 的帳單是開發者儀式和偶爾的 artifact 爭論。lakeFS 的帳單是運行服務和學習物件儲存的新合併語義。如果一個工具看起來是免費的，那麼它正在收取你的注意力。
告別鏡頭
「lakeFS vs DVC」看起來像是一場對決。它更像是兩個不演奏同一樂器的音樂家。你不會要求鼓手來演奏旋律，也不會要求小提琴手為行進樂隊保持節拍。在程式碼擁有迴圈的地方使用 DVC。在資料擁有房間的地方使用 lakeFS。如果你生活在這兩個世界中，那就太好了：這意味著你正在關注。
因為版本控制的真正重點——無論它是包裝 Git 還是包裝 S3——都不是提交雜湊。它是允許在不破壞世界的情況下更改事物的權限。其他一切都只是選項卡欄。
關鍵字友好、簡單語音標題（因為你問了）
用於 ML pipelines 的 lakeFS vs DVC
如果你的 ML pipelines 是程式碼繁重，具有離散資料集和模型 artifacts，那麼 DVC 整合得更好：Git 中的指標檔案、雜湊、追蹤的實驗。對於為多個團隊提供資料的資料繁重 pipelines，lakeFS 在整個湖中以基於分支的隔離獲勝。
用於資料治理的 lakeFS vs DVC
lakeFS 為你在儲存邊界提供可稽核的提交和合併 hooks。DVC 為你在 pipeline 邊界提供 provenance。如果法律想要不可變的檢查點，那就是 lakeFS；如果工程想要可重現的運行，那就是 DVC。
在 DVC 和 lakeFS 之間為物件儲存選擇
物件儲存不進行交易。DVC 通過物件層級雜湊和 push/pull 來解決這個問題。lakeFS 傾向於使用寫時複製元資料和分支語義。根據你的痛苦是在 repo 還是 bucket 中來選擇。
組合 lakeFS 和 DVC 而不會頭痛
使用 lakeFS 對湖進行版本控制；將提交 ID 呈現給 DVC，以便實驗固定到確切的輸入。將模型 artifacts 保留在 DVC remotes 中；將原始和精選資料集保存在 lakeFS 分支中。無需未經授權的駭客攻擊。
FAQ
Q1：哪個更適合 ML 實驗：lakeFS 還是 DVC？
對於 ML 實驗，DVC 通常獲勝。它將程式碼、參數、資料集和模型連結在一起，而 lakeFS 處理湖層級的資料集隔離和時間旅行。
Q2：我可以同時使用 lakeFS 和 DVC 而不會造成混亂嗎？
是的。使用 lakeFS 提交來對你的湖資料集進行版本控制，並在 DVC 中引用這些提交 ID。讓 DVC 處理 artifacts 和 pipelines；讓 lakeFS 處理物件儲存上的分支和合併。
Q3：DVC 是否取代資料湖或 lakeFS？
否。DVC 在 Git 周圍組織大型檔案和實驗；它不會將 S3 變成交易儲存。lakeFS 位於你的湖前面，並添加分支、提交和隔離。
Q4：lakeFS 對於小型團隊來說是否過於 overkill？
通常，是的。如果你沒有處理多團隊隔離或治理，DVC 的簡單性很有吸引力。當基於分支的隔離和稽核追蹤可以節省真金白銀或中斷時，lakeFS 才有意義。
Q5: lakeFS 與 DVC 的成本比較如何？
DVC 的成本傾向於開發者時間以及推送/拉取期間的儲存變動。lakeFS 的成本傾向於運行服務和管理策略，但分支很便宜且便於輸出。
