データバージョン管理システム

 (dvc.org)
2 ポイント 投稿者 GN⁺ 2024-10-21 | 1件のコメント | WhatsAppで共有
  • Data Version Control は、コードのようにデータを管理する Git 類似モデルで、データ・AI/ML・データサイエンスチームにソフトウェアエンジニアリングの実践を適用できるようにするツール群
  • 大規模な AI/ML およびデータインフラには lakeFS が対応し、複雑な AI 運用とビッグデータ環境で、ペタバイト規模のマルチモーダルオブジェクトストレージとデータレイクを扱う方向
  • 小規模なデータサイエンスプロジェクトには DVC Git 拡張 が適しており、個々のデータサイエンティストが低いオーバーヘッドでデータバージョン管理をワークフローに組み込める
  • DVC は無料のオープンソースとして提供され、DVC for VS Code 拡張もあり、GitHub リポジトリには 15,713 個のスターが表示されている
  • DVC コミュニティが lakeFS family に加わったことで、lakeFS と DVC の役割分担および関連 FAQ を別途確認できる

Data Version Control が担う役割

  • Data Version Control は、「コードを管理する方法でデータを管理する」という目標を掲げている
  • Git に類似したモデルを通じて、データ、AI/ML、データサイエンスチームが ソフトウェアエンジニアリングのベストプラクティス を活用できるよう支援する構造
  • ユースケースは大きく 2 つに分かれる
    • AI/ML およびデータインフラ チーム
    • ローカルワークフロー と小規模なデータサイエンスプロジェクト

製品ごとの対象と開始方法

  • lakeFS は、エンタープライズ AI およびデータエンジニアリングチーム向けのデータバージョン管理インフラ
    • 複雑な AI 運用とビッグデータ環境を対象とする
    • ペタバイト規模の マルチモーダルオブジェクトストレージ とデータレイクを扱う
    • 開始リンクとして Get started with lakeFS と Book a Demo が提供されている
  • DVC は、個々のデータサイエンティスト向けの Git 拡張
    • 小規模なデータサイエンスプロジェクトに合わせた 簡単なデータバージョン管理 を目指す
    • データサイエンスのワークフローに最小限のオーバーヘッドで適用できる
    • 開始リンクは Get started with DVC
  • DVC for VS Code 拡張を通じて VS Code でも利用できる
  • DVC コミュニティは lakeFS family に加わっており、関連案内として lakeFS and DVC と FAQs がリンクされている
  • DVC の GitHub リポジトリは treeverse/dvc で、ページには 15,713 個のスターが表示されている

関連記事

1件のコメント

 
GN⁺ 2024-10-21
Hacker Newsの意見

  • 過去5年間、ほとんどのプロジェクトでDVCを使ってきましたが、長所はGitのように動く点です。
    研究者がブランチ、コミット、差分を理解していれば、DVCも理解できます。短所もGitのように動く点で、実際には研究者はブランチ、コミット、差分をよく理解していなかったり、使っていなかったりすることが多いです。いちばん良い点は、事実上 Ten Simple Rules for Reproducible Computational Research に従うことを強制してくれることです。私が働いてきたチームでは、再現性が大きな課題でした

    • 私も同じように感じていて、Git学習への抵抗はかなり大きく、ある程度は理解できます。
      研究者はGitが何で、価値があることも分かっていますが、学ぶのに時間がかかりすぎると考えており、早く先へ進みたがります。そうした研究者のために、GitとDVCを単純化して統合しようと、Calkit（https://github.com/calkit/calkit）というツールを作り始めました。再現可能な形で作業することは長期的にはより速く、結果として分野全体をより速く前進させるために、自分の作業をより直接的に活用できるようになるのだと説得したいです

  • DVCのメンテナー兼作者ですが、DVCがトップページに上がっていてうれしいです。
    DVCと姉妹プロジェクトのDataChain https://github.com/iterative/datachain について質問に答えられます。DataChainはファイルのコピーなしで、組み込みのデータ変換を備えた、少し異なる前提のデータバージョン管理ツールです

    • データファイルがすべてテキストファイルなら、DVCと純粋なGitの違いは何なのか気になります
    • 主にデータエンジニアとしてコンサルティングしていて、MLOpsの専門家ではありませんが、この部分に関心があります。
      300を超えるKafkaトピックから出た10年分のParquetファイルがあり、現在Apache Icebergへ移行中です。必要な場合にだけバックフィルする予定ですが、その過程をGitで追跡できるとよいと思っています。こうした用途にうまく合うのか気になります。もう1つの可能性は、現在より良い方法でスキーマ変更を追跡することです。20年以上この分野にいて、anything-as-codeはデータと相性が良いと見ています

  • DVCがここで議論されているのを見てうれしいです。
    ツールとしてデータとモデルのバージョン管理を大きく単純化し、MLOps領域の多くの人にとって大きな転換点になりました。特にgit-lfsのような別のアプリケーションサーバーやGitの書き換えなしに、任意のオブジェクトストレージへ大きなファイルをGitリポジトリと直接結び付けて保存する賢いやり方です。DagsHub https://dagshub.com ではかなり以前からDVCと直接統合し、チームがデータセットの可視化とラベリング、モデル管理、共同での実験実行、コード・データ・モデルの追跡を一か所でできるようにしてきました。すでにDVCを使っている、または検討しているなら、よりエンドツーエンドに近いツールチェーンの構成要素として使う選択肢もあります

  • Oxenと比べるとどうなのか気になります。
    https://github.com/Oxen-AI/Oxen

    • Oxenのメンテナーですが、最初にOxenを作った理由は、DVCがかなり遅く、不要な機能が多かったからです。
      内部的にMerkleツリー構造、ハッシュアルゴリズム、ネットワークプロトコルなどを最適化して、大きなデータセットでも高速になるようにしました。https://oxen.ai にはデータを見たりクエリしたりできる、かなり良いフロントエンドもあります
    • これをGitHubと一緒に使えるなら、DVCからすぐ移行すると思います
    • Oxenは初めて聞きましたが、非常に興味深い代替案に見え、両方使った人の話を聞いてみたいです。
      第一印象では、DVCはGitリポジトリ内の任意のフォルダをDVCが管理する形でGitと一緒に使うよう作られており、Oxenは別個のデータリポジトリの代替に近く見えます。またOxenはデータフレーム、表形式データ、AIの学習・推論データとの統合が多く、DVCにない部分を補っているようです。一方でDVCには完全なDAGパイプラインエンジン、インポート・エクスポート、差し替え可能なバックエンドが統合されています

  • これがデータとどう相互作用するのか、あまりピンときません。
    ADLSにDeltaテーブルを保存していて、プロダクションデータをローカルに持ってこられない場合でも使えるのか気になります。過去バージョンへ切り替えるのにDeltaログを見るだけでよいなら、DVCを使う理由があるのかも疑問です

    • 私の使い方を基準にすると、DVCは複数のバックエンドをサポートするgit LFSに近く、より単純なgit-annexとも言えます。
      そこにMLOpsに特化した機能が加わっています。S3上のデータが変わるモデル学習をバージョン管理するときに便利です

  • 私たちもDVCを検討しましたが、特定のユースケースではGitのパラダイムがあまり有用ではありませんでした。
    ほとんど変化しない巨大な動画ファイルで、オリジナル側にデータのコピーが1つ、学習を行う各システムにさらに1つずつコピーが必要でした。結局NAS上のファイルとフォルダに落ち着き、それで十分うまく動きました。データセットのメタデータだけをDVCで管理し、それをバージョン管理するハイブリッド方式は可能そうです。ただし数年前の話で、オンプレミスのデータバージョン管理ソリューションが今はもっとあるのか気になります。最後に調べたときは、ほとんどがクラウド志向に見えました

  • Apache Icebergと比べたとき、DVCの利点が何なのか気になる
    両方使ったことがある人がいれば見解を聞きたい

    • それが気になるなら、今週オープンソース化された Icechunk も見るべき
      Apache Icebergに似ているが、Zarrのような多次元データ向けのツール。 https://earthmover.io/blog/icechunk および https://news.ycombinator.com/item?id=41850352
    • はっきりした利点はあまり見えず、すでに知っているツールを合わない場所で使っている感じがする
      Icebergはこの方式より、変化の遅いモデルにより合わせられているのかもしれない
    • 頭の中が少し整理できていないが、試しに言うと、ここでいう blobデータ の良い例は、とても長い1080p動画ファイルのまとまり
      要約すると、非構造化blobデータはDVCに入れ、構造化データはIcebergに入れるのが正しい。DVCがIcebergより優れている点は、blobデータを表形式に無理やり押し込まなくてよく、その過程で付いてくる面倒な処理ステップを避けられること。実質的にParquetファイルからblobデータを取り出す処理ステップを回す必要もなく、dvc pull のようなコマンドで各ファイルをそのままダウンロードすればよい。ローカルでファイルを修正したあと、おおよそ3つほどのコマンドでコミットでき、blobデータをテーブルに無理やり入れるデータ取り込みパイプラインも不要。完全にスキーマレスなので、型を気にせずリポジトリに入れてコミットすればよい。最後のvacuum/checkpointまでだけでなく、コミット履歴全体をたどってロールバックできる。表形式データフォーマットにblobデータを押し込むのは苦痛の公式に近く、blobをGitのようなリポジトリに入れるほうがはるかに速くて簡単。全バージョン履歴や、異なる結果のためのブランチが必要なら特にそうで、長い1080p動画ファイル群にブランチごとに異なるffmpegフィルターを適用し、全員がすべての結果と履歴にアクセスできるようにすることをIcebergでやろうとすると悪夢のようだが、DVCでは簡単。結局すべてがバージョン管理されるので、データ沼にならないデータレイクを作る感覚

  • 多数のjpgファイルからなるデータセットに使ったとき、問題が多かった
    dvc status のたびに全ファイルを確認する インデックス作成 が数分かかり、キャッシュも機能しなかった。残念ながら諦めるしかなかった

    • その通りで、性能はかなり悪く、キャッシュ のせいで面倒なことが多くなり得る
      特にreflinkをサポートしないファイルシステムを使っている場合はなおさら。WebDatasetのような大きなシャーディング済みデータセットには別のソリューションのほうがよく、機械学習パイプラインがオブジェクトストレージから直接ストリーミングできるなら特にそう

  • S3オブジェクトストレージ上のデータバージョン管理ツールとして lakeFS も聞いたことがある
    DVCがこの領域で競合になり得るのか気になる