lakeFS vs DVC: バージョン管理はファイルシステムになりたい
更新日: 2025年9月28日
12 分
lakeFS vs DVC: バージョン管理はファイルシステムになりたい
データバージョン管理について言えば、誰もがまるでそれがGitのすべてのためのものであるかのように頷きます。チーム全体でペタバイト規模のデータに使用しようとして、Gitが実際にはコードのためのGitであったことに気づくまでは。「S3バケットをリポジトリのように扱えばいい」と言うのは、交響楽団にカズーを使うように言うようなものです。なぜなら、それは技術的には管楽器だからです。
これは、同じスローガンを共有する2つの世界観についての物語です。lakeFS vs DVC。どちらも、データ、モデル、実験が通常迷子になる場所で正気を保つことを約束します。しかし、彼らは反対方向から問題に取り組みます。DVCは、開発者第一の、Gitに隣接するツールキットで、リポジトリと一緒に使用します。lakeFSは、オブジェクトストアをブランチ、コミット、マージを備えたバージョン管理されたファイルシステムに変えるストレージネイティブレイヤーです。同じメロディー、異なる調号。
もしあなたが結論を求めてここにいるなら、おそらくあなたはすでにどちらの陣営にいるかを知っているでしょう。もしあなたの毎日の苦痛が、再現性を保ちながら大規模なファイルやモデルチェックポイントを移動させることであるなら、DVCは非常に賢い延長コードのように感じられるでしょう。もしあなたの苦痛が、複数チームでのデータガバナンス、分離、およびデータレイク上での再現可能な読み取りであるなら、lakeFSは実際の家に回路ブレーカーを設置するように感じられます。
そして、はい、両方を使うことができます。それはごまかしではありません。それは、データ作業が同じTシャツを着た多くの仕事であることを認めるものです。
現状：DVCとlakeFSが実際にすること
- DVC (Data Version Control): Gitの中にではなく、Gitの隣に存在します。Gitでポインタ（小さなメタファイル）をバージョン管理し、実際の大きなアーティファクト（データセット、モデル、画像）をS3、GCS、Azure、SSH、またはローカルキャッシュのようなリモートに保存します。CLI駆動のパイプライン、再現性のための
dvc.lock、実験トラッキング、および同期のためのdvc push/pullを入手できます。
- lakeFS: オブジェクトストア（S3、GCS、Azure Blob）の前に座り、ブランチとコミットをストレージ名前空間の第一級の機能にします。読み取りと書き込みは、分離されたブランチを参照します。「production」からブランチを作成し、変換を実行し、テラバイトをコピーせずにマージバックできます。それはあなたのデータレイクのための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。lakeFSコミットハッシュを参照するデータセットバージョンをDVCで追跡およびピン留めします。コードはGitに存在し、データのセマンティクスはレイクに存在します。誰も他のレイヤーが両方のジョブをうまく実行できるふりをする必要はありません。
lakeFS vs DVC：実践的なトレードオフ
セットアップと運用
- DVC: CLIをインストールし、リモートを構成します。キャッシュサイズ、ストレージコスト、およびアクセスを管理します。Gitはあなたのホームベースのままです。最小限の摩擦。
- lakeFS: サービスを実行しています。サーバー、メタデータ、GC、ブランチングポリシー、資格情報があります。難しくはありませんが、インフラストラクチャです。見返りは、データレイク上の実際の分離とアトミックコミットです。
パフォーマンスとスケール
- DVC: 大きなアーティファクトのプッシュ/プルは、ローカルキャッシュとハードリンクを使用すると高速になりますが、モデルは基本的にクライアント駆動です。ペタバイトをミリ秒で分岐することはありません。必要に応じて参照して断片を移動します。
- lakeFS: ブランチングはメタデータ的に安価です（コピーオンライト）。読み取りは単なるオブジェクトストアの読み取りであるため、「ネイティブ速度」です。書き込みは間接化されますが、「世界をコピーする」というペナルティはありません。マージの競合は存在しますが、それらはコードの行ではなく、オブジェクト/キーレベルです。
再現性
- DVC: あなたの
dvc.lockは、コード、パラメータ、およびデータアーティファクトのハッシュを結び付けます。先月から実験を再実行すると、同じビットが生成されるはずです。それはコード境界での再現性です。
- lakeFS: データ境界での再現性：「コミットYのテーブルXを読み取る」。分析またはバックフィル用に、入力サーフェス全体をタイムトラベルできます。
コラボレーションモデル
- DVC: 開発者中心のコラボレーション— PR、レビュー、および実験。MLループに最適：データ→トレーニング→評価→出荷。
- lakeFS: データチーム中心のコラボレーション—取り込み、変換、および検証のためのブランチ。分析ループに最適：取り込み→モデル（dbt/ETLのように）→公開→提供。
平易な英語でのデータ契約
人々は「データ契約」と言い、スキーマレジストリのスクリーンショットを振り回し始めます。これが平易なバージョンです:
- DVCでは、契約はパイプラインに暗黙的に含まれています。依存関係として宣言するファイルが契約を構成します。それらを変更すると、パイプラインは認識します。
- lakeFSでは、契約はマージ時に適用できます。マージ前のフックは、検証（スキーマチェック、行数、nullのしきい値）を実行し、
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行をマージしているわけではありません。どのブロブが勝つかを調整しています。きめ細かいマージの場合、実際にはデータ処理が必要です。
- lakeFSマージのセマンティクスはSQLではありません: S3パスをブランチしてマージできますが、セマンティックテーブルの変更（パーティションの再シャッフル、アップサート）を調整するのはあなたの仕事であり、lakeFSの仕事ではありません。データベースではなく、ファイルシステムと考えてください。
- アクセス制御は異なります: DVCはGitのソーシャルモデル（PR、レビュー）を継承します。lakeFSはIAMおよびポリシーフックと統合されます。組織がすでにデータのIAMを集中化している場合、lakeFSは自然に感じられます。GitHubに住んでいる場合は、DVCが適切に感じられます。
統合：エンジン、オーケストレーター、および現実世界
- DVC: GitHub/GitLab CI、Makefiles、Airflow、およびローカル開発とうまく連携します。ML実験の場合、DVCの実験追跡とアーティファクト管理が魅力です。
- lakeFS: Spark、Hive、Trino、Presto、dbt（外部テーブル経由）、Airflow、および
s3a://repo/branch/pathを読み取るエンジンとうまく連携します。秘訣は、コンピューティングが同じストレージ言語を話すことです。
バズワードなしのセキュリティとコンプライアンス
- DVC: セキュリティは、クラウドストレージとGitのアクセス許可に依存します。監査可能性は、パイプラインレベル（何が何を、いつ生成したか）です。
- lakeFS: すべてのコミットは監査チェックポイントです。フックはマージ前にデータをスキャンできます。GDPRスタイルの「何がいつ変更されたか」を気にする場合、lakeFSの方が適しています。
平易な英語での直接対決
- プライマリキーワード—「lakeFS vs DVC」は単なる比較ではありません。それは哲学の分かれ道です。DVCは、大きなファイルと実験のためのGitの利点です。lakeFSは、データが実際に存在する場所でのGitlikeセマンティクスです。
- もしあなたの1日が主にデータに触れるコードであるなら、DVCで満足するでしょう。
- もしあなたの1日が主にコードに出会うこともあるデータであるなら、lakeFSを選ぶ可能性が高いでしょう。
- もしあなたの1日が両方であるなら、おめでとうございます。あなたは正常です。コードに面したループにはDVCを、レイクに面したループにはlakeFSを使用してください。「両方」は優柔不断ではありません—それは正確です。
ツールへの期待に関する注記（そして、Sider.AIが適合する場所）
ツールは、時間を節約したり、混乱を防いだりする場合にのみ興味深いです。それ以外はすべてデモです。Sider.AIは、実際にここで役立ちます—あなたのレイクであるふりをするのではなく、地味な作業を行うことで：パイプラインについて推論し、ガードレールチェックを生成し、ドキュメントと差分を正直に保つことを支援します。DVCとlakeFSを一緒に配線する場合、Sider.AIは「ブレーカーにラベルを付けなさい」と言ってからラベルを印刷する賢明な友人です。
実践的なシナリオ：野生のlakeFS vs DVC
シナリオ1：ETLの機能分離
- ブロンズ/シルバー/ゴールドレイクを維持します。ダウンストリームダッシュボードを壊すことなく、クリックストリーム取り込みの新しいスキーマをテストする必要があります。lakeFSでは、
silverからetl/schema-v2を分岐し、ジョブを実行し、分離して検証し、チェックがパスした後にマージします。シャドウバケットも、一晩中のコピーもありません。
シナリオ2：再現可能なトレーニングの実行
- 毎週モデルをトレーニングします。DVCは、正確なデータセットスナップショット（lakeFSコミットまたはS3バージョンを指す
data.dvc）、パラメータ、およびコードをピン留めします。dvc reproが実行をスピンします。モデル、メトリック、およびプロットは、プッシュして共有できるアーティファクトです。監査人はこれを愛しています。将来のあなたも同様です。
シナリオ3：不正な公開の修正
- 誰かが不正なParquetセットを
mainに公開します。lakeFSでは、最後の正常なコミットまたはブランチにロールバックし、パッチを適用してマージします。DVCでは、パイプラインで修正してアーティファクトを再プッシュします。どちらも機能します。「公開」が「誰もが読むレイク」を意味する場合、lakeFSの方が適しています。
涙なしの移行と共存
- まず、真実を命名することから始めます：どのデータセットがシステムオブレコードですか？どれが一時的なものですか？システムオブレコードをlakeFSに入れます。実験アーティファクトをDVCに入れます。
- 薄い統合: lakeFSコミットIDをDVCパラメータまたはメタデータに保存します。それらを不変のデータセットバージョンとして扱います。
- レイクを煮詰めてはいけません: 分離が実際のお金または週末を節約できる場合は、lakeFSを採用します。再現性が再実行を節約できる場合は、DVCを採用します。
弁証法：それはどちらか一方ではなく、真実がどこにあるかです
ソフトウェアチームは、それらをすべて支配する1つのツールを求めています。それは間違った質問です。正しい質問：真実はどこにありますか？
- もし真実がリポジトリにあるなら—コード、構成、およびトレーニングに使用した特定のファイル—DVCはGitの自然な拡張です。
- もし真実がレイクにあるなら—あなたの会社を動かすテーブル、パーティション、およびオブジェクトキー—lakeFSはあなたにコミット時の正気を与えます。
どちらもバージョン管理の形式です。実際にデータが存在する場所に住んでいるのは1つだけです。
lakeFS vs DVC：人々が実際に尋ねる質問への簡単な回答
- 「DVCはデータレイクを置き換えることができますか？」いいえ。アーティファクトを整理し、実験を健全にすることができます。S3をトランザクションストアのように動作させることはできません。
- 「lakeFSはML実験トラッカーを置き換えることができますか？」これも違います。実験の入力/出力をバージョン管理できますが、ROC曲線は気にしません。
- 「これは単なるGit LFSではないですか？」それは、自転車が金属の少ない車であると言うようなものです。DVCはGitに隣接していますが、データパイプラインを理解しています。lakeFSは、Gitをペタバイトにドラッグすることなく、Gitのようなセマンティクスを提供します。
複雑さに関する簡単な言葉（どこかで支払う）
すべての抽象化は、後で期限が来る請求書です。DVCの請求書は、開発者の儀式と時折のアーティファクトの操作です。lakeFSの請求書は、サービスの実行とオブジェクトストアの新しいマージセマンティクスの学習です。ツールが無料に見える場合は、あなたの注意を請求しています。
別れの言葉
「lakeFS vs DVC」は対決のように読めます。それは、同じ楽器を演奏しない2人のミュージシャンのようです。ドラマーにメロディーを運ぶように頼むことはありませんし、バイオリンに行進バンドの時間を守るように頼むこともありません。コードがループを所有している場合は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ブランチに保持します。許可されていないハックは必要ありません。
よくある質問
Q1：ML実験にはlakeFSとDVCのどちらが優れていますか？
ML実験の場合、DVCが通常勝利します。コード、パラメータ、データセット、およびモデルをまとめて結び付けますが、lakeFSはレイクレベルでデータセットの分離とタイムトラベルを処理します。
Q2：lakeFSとDVCを一緒に使用しても混乱しませんか？
はい。lakeFSコミットを使用してレイクデータセットをバージョン管理し、それらのコミットIDをDVCで参照します。DVCにアーティファクトとパイプラインを処理させます。lakeFSにオブジェクトストレージのブランチとマージを処理させます。
Q3：DVCはデータレイクまたはlakeFSを置き換えますか？
いいえ。DVCはGitを中心に大きなファイルと実験を整理します。S3をトランザクションストアに変えることはありません。lakeFSはレイクの前に座り、ブランチング、コミット、および分離を追加します。
Q4：lakeFSは小規模チームには過剰ですか？
多くの場合、はい。複数チームの分離やガバナンスを操作していない場合、DVCのシンプルさは魅力的です。ブランチベースの分離と監査証跡が実際のお金または停止を節約できる場合に、lakeFSは理にかなっています。
Q5: lakeFSとDVCでは、コストはどのように異なりますか？
DVCのコストは、push/pull時の開発者の時間とストレージの変動に偏っています。lakeFSのコストは、サービスの実行とポリシーの管理に偏っていますが、ブランチングは安価で、イグレスに適しています。
