Datenversionsverwaltungssystem

• Data Version Control ist eine Werkzeugfamilie mit einem Git-ähnlichen Modell zur Verwaltung von Daten wie Code, die Daten-, AI/ML- und Data-Science-Teams die Anwendung von Software-Engineering-Praktiken ermöglicht
• Für große AI/ML- und Dateninfrastrukturen ist lakeFS gedacht; es zielt auf komplexe AI Operations und Big-Data-Umgebungen ab und verwaltet multimodale Objektspeicher und Data Lakes im Petabyte-Maßstab
• Für kleinere Data-Science-Projekte ist die DVC-Git-Erweiterung ausgelegt, mit der einzelne Data Scientists Datenversionsverwaltung mit geringem Overhead in ihren Workflow integrieren können
• DVC ist kostenlos und Open Source verfügbar, es gibt außerdem die Erweiterung DVC for VS Code; das GitHub-Repository zeigt 15.713 Sterne
• Da die DVC-Community der lakeFS family beigetreten ist, lassen sich die Rollenabgrenzung zwischen lakeFS und DVC sowie zugehörige FAQs separat nachlesen

---

Die Rolle von Data Version Control

• Data Version Control verfolgt das Ziel, „Daten so zu verwalten, wie man Code verwaltet“
• Über ein Git-ähnliches Modell hilft es Daten-, AI/ML- und Data-Science-Teams, Best Practices des Software Engineerings zu nutzen
• Die Anwendungsfälle lassen sich grob in zwei Bereiche einteilen
  • Teams für AI/ML- und Dateninfrastruktur
  • Lokale Workflows und kleinere Data-Science-Projekte

Zielgruppen und Einstiegspfade nach Produkt

• lakeFS ist eine Infrastruktur für Datenversionsverwaltung für Enterprise-AI- und Data-Engineering-Teams
  • Ausgerichtet auf komplexe AI Operations und Big-Data-Umgebungen
  • Verwaltet multimodale Objektspeicher und Data Lakes im Petabyte-Maßstab
  • Als Einstiegslinks werden Get started with lakeFS und Book a Demo angeboten
• DVC ist eine Git-Erweiterung für einzelne Data Scientists
  • Ziel ist einfache Datenversionsverwaltung für kleinere Data-Science-Projekte
  • Lässt sich mit minimalem Overhead in Data-Science-Workflows einsetzen
  • Der Einstiegslink ist Get started with DVC
• Über die Erweiterung DVC for VS Code kann es auch in VS Code genutzt werden
• Die DVC-Community ist der lakeFS family beigetreten; als zugehörige Hinweise sind lakeFS and DVC und FAQs verlinkt
• Das DVC-GitHub-Repository ist treeverse/dvc; auf der Seite werden 15.713 Sterne angezeigt

[GN⁺]

Meinungen auf Hacker News

• Ich habe in den letzten fünf Jahren in den meisten Projekten DVC verwendet; der Vorteil ist, dass es sich wie Git verhält.
  Wenn Wissenschaftler Branches, Commits und Diffs verstehen, können sie auch DVC verstehen. Der Nachteil ist ebenfalls, dass es sich wie Git verhält: In der Praxis verstehen oder nutzen Wissenschaftler Branches, Commits und Diffs oft nicht besonders gut. Das Beste daran ist, dass es einen im Grunde dazu zwingt, die Ten Simple Rules for Reproducible Computational Research zu befolgen. In den Teams, in denen ich gearbeitet habe, war Reproduzierbarkeit eine große Herausforderung.

  • Mir ging es ähnlich; der Widerstand gegen das Erlernen von Git ist ziemlich groß und bis zu einem gewissen Grad nachvollziehbar.
    Forschende wissen, was Git ist und dass es wertvoll ist, finden aber, dass das Lernen zu lange dauert, und wollen schnell vorankommen. Für solche Forschenden habe ich angefangen, ein Tool namens Calkit (https://github.com/calkit/calkit) zu entwickeln, um Git und DVC zu vereinfachen und zu integrieren. Ich möchte sie davon überzeugen, dass reproduzierbares Arbeiten langfristig schneller ist und dass man seine Arbeit dadurch direkter dafür einsetzen kann, das gesamte Fachgebiet schneller voranzubringen.

• Ich bin Maintainer und Autor von DVC und freue mich, DVC auf der Titelseite zu sehen.
  Ich kann Fragen zu DVC und dem Schwesterprojekt DataChain https://github.com/iterative/datachain beantworten. DataChain ist ein Datenversionsverwaltungstool mit etwas anderen Annahmen, ohne Kopieren von Dateien und mit eingebauten Datentransformationen.

  • Wenn alle Datendateien Textdateien sind: Was ist dann der Unterschied zwischen DVC und reinem Git?
  • Ich arbeite hauptsächlich als Data-Engineering-Berater und bin kein MLOps-Spezialist, interessiere mich aber für diesen Bereich.
    Wir haben Parquet-Dateien aus über 300 Kafka-Topics über einen Zeitraum von zehn Jahren und migrieren gerade zu Apache Iceberg. Backfills sollen nur bei Bedarf erfolgen, und es wäre gut, diesen Prozess mit Git nachverfolgen zu können. Ich frage mich, ob das für diesen Zweck gut passt. Eine weitere Möglichkeit wäre, Schemaänderungen besser als bisher zu verfolgen. Ich bin seit über 20 Jahren in diesem Bereich und finde, dass anything-as-code gut zu Daten passt.

• Schön zu sehen, dass DVC hier diskutiert wird.
  Als Tool hat es die Versionierung von Daten und Modellen stark vereinfacht und war für viele im MLOps-Bereich ein Wendepunkt. Besonders clever ist die Art, große Dateien in einem beliebigen Object Store zu speichern und direkt mit einem Git-Repository zu verknüpfen, ohne separaten Application-Server wie bei git-lfs oder ein Umschreiben von Git. Bei DagsHub https://dagshub.com haben wir DVC schon lange direkt integriert, damit Teams Datensätze visualisieren und labeln, Modelle verwalten, kollaborative Experimente ausführen und Code, Daten und Modelle an einem Ort nachverfolgen können. Wenn ihr DVC bereits nutzt oder in Betracht zieht, gibt es auch die Option, es als Bestandteil einer eher End-to-End-orientierten Toolchain zu verwenden.

• Ich frage mich, wie es im Vergleich zu Oxen abschneidet.
  https://github.com/Oxen-AI/Oxen

  • Ich bin Oxen-Maintainer; der ursprüngliche Grund für die Entwicklung von Oxen war, dass DVC ziemlich langsam war und viele Funktionen hatte, die wir nicht brauchten.
    Intern haben wir die Merkle-Tree-Struktur, Hash-Algorithmen, Netzwerkprotokolle usw. optimiert, damit es auch bei großen Datensätzen schnell ist. Auf https://oxen.ai gibt es außerdem ein ziemlich gutes Frontend, mit dem man Daten ansehen und abfragen kann.
  • Wenn man das zusammen mit GitHub verwenden könnte, würde ich wohl direkt von DVC wechseln.
  • Von Oxen habe ich zum ersten Mal gehört, aber es sieht nach einer sehr interessanten Alternative aus; ich würde gern von Leuten hören, die beide ausprobiert haben.
    Mein erster Eindruck ist: DVC ist dafür gemacht, zusammen mit Git verwendet zu werden, indem DVC beliebige Ordner innerhalb eines Git-Repositorys verwaltet, während Oxen eher wie eine Alternative für ein separates Daten-Repository wirkt. Außerdem hat Oxen viele Integrationen mit Dataframes, tabellarischen Daten sowie Daten für KI-Training und -Inferenz und scheint damit Lücken zu füllen, die DVC nicht abdeckt. DVC hingegen integriert eine vollständige DAG-Pipeline-Engine, Import/Export und austauschbare Backends.

• Mir ist nicht ganz klar, wie das mit Daten interagiert.
  Wenn man Delta-Tabellen in ADLS speichert und Produktionsdaten nicht lokal holen kann, frage ich mich, ob man es trotzdem nutzen kann. Wenn für den Wechsel zu früheren Versionen ein Blick in das Delta-Log reicht, frage ich mich auch, ob es überhaupt einen Grund gibt, DVC zu verwenden.

  • Nach meiner Nutzungsweise ist DVC eher wie git LFS mit Unterstützung für mehrere Backends, oder auch wie ein einfacheres git-annex.
    Dazu kommen MLOps-spezifische Funktionen. Es ist praktisch, wenn man Modelltraining versionieren will, bei dem sich Daten auf S3 ändern.

• Wir haben DVC ebenfalls evaluiert, aber für einen bestimmten Use Case war das Git-Paradigma nicht besonders nützlich.
  Es ging um riesige Videodateien, die sich kaum änderten, und wir brauchten eine Kopie der Daten an der Quelle sowie jeweils eine weitere Kopie auf jedem System, das das Training ausführte. Am Ende sind wir bei Dateien und Ordnern auf einem NAS gelandet, und das funktionierte ausreichend gut. Ein hybrider Ansatz, bei dem nur die Dataset-Metadaten mit DVC verwaltet und versioniert werden, scheint machbar. Das ist allerdings ein paar Jahre her, und ich frage mich, ob es inzwischen mehr On-Premises-Lösungen für Datenversionierung gibt. Als ich zuletzt geschaut habe, wirkten die meisten eher Cloud-orientiert.

• Ich frage mich, welche Vorteile DVC im Vergleich zu Apache Iceberg hat
  Wenn jemand beides genutzt hat, würde ich gern eine Einschätzung hören

  • Wenn dich das interessiert, solltest du dir auch Icechunk ansehen, das diese Woche als Open Source veröffentlicht wurde
    Es ähnelt Apache Iceberg, ist aber ein Tool für multidimensionale Daten wie Zarr. https://earthmover.io/blog/icechunk und https://news.ycombinator.com/item?id=41850352
  • Einen klaren Vorteil sehe ich nicht wirklich; es fühlt sich eher so an, als würde man ein bekanntes Tool an einer Stelle einsetzen, für die es nicht passt
    Iceberg ist vielleicht eher auf Modelle ausgelegt, die sich langsamer ändern als bei diesem Ansatz
  • Meine Gedanken sind noch nicht ganz sortiert, aber ich versuche es mal: Ein gutes Beispiel für die hier gemeinten Blob-Daten wäre ein Bündel sehr langer 1080p-Videodateien
    Kurz gesagt: Unstrukturierte Blob-Daten gehören in DVC, strukturierte Daten in Iceberg. Der Vorteil von DVC gegenüber Iceberg ist, dass man Blob-Daten nicht mit Gewalt in ein tabellarisches Format pressen muss und sich die dabei entstehenden lästigen Verarbeitungsschritte spart. Praktisch muss man auch keinen Verarbeitungsschritt ausführen, um Blob-Daten aus Parquet-Dateien herauszuholen; man lädt die einzelnen Dateien einfach unverändert mit einem Befehl wie dvc pull herunter. Lokal kann man eine Datei ändern und sie mit ungefähr drei Befehlen committen, und man braucht keine Datenerfassungs-Pipeline, die Blob-Daten mit Gewalt in Tabellen presst. Es ist komplett schemafrei, man muss sich also keine Gedanken über Typen machen, sondern legt es einfach ins Repository und committet es. Man kann entlang der gesamten Commit-Historie zurückrollen, nicht nur bis zum letzten Vacuum/Checkpoint. Blob-Daten in ein tabellarisches Datenformat zu pressen ist fast schon eine Formel für Schmerzen; Blobs in ein Git-ähnliches Repository zu legen ist viel schneller und einfacher. Das gilt besonders, wenn man eine vollständige Versionshistorie oder Branches für unterschiedliche Ergebnisse braucht. Wenn man auf lange 1080p-Videodateien je nach Branch verschiedene ffmpeg-Filter anwenden und allen Zugriff auf alle Ergebnisse und die Historie geben will, wäre das mit Iceberg ein Albtraum, mit DVC aber einfach. Am Ende fühlt es sich an, als würde man einen Data Lake bauen, der nicht zum Datensumpf wird, weil alles versioniert ist

• Bei einem Datensatz aus vielen jpg-Dateien hatte ich viele Probleme
  Die Indexierung, bei der bei jedem dvc status alle Dateien geprüft wurden, dauerte jeweils mehrere Minuten, und das Caching funktionierte auch nicht. Leider musste ich es aufgeben

  • Stimmt, die Performance ist ziemlich schlecht, und Caching kann viele Kopfschmerzen bereiten
    Besonders, wenn man ein Dateisystem verwendet, das keine Reflinks unterstützt. Für große geshardete Datensätze wie WebDataset sind andere Lösungen besser, vor allem wenn die Machine-Learning-Pipeline direkt aus dem Objektspeicher streamen kann

• Ich habe auch von lakeFS als Tool für Datenversionierung auf S3-Objektspeicher gehört
  Ich frage mich, ob DVC in diesem Bereich ein Konkurrent sein kann