Reading Time: 16 minutes

Python-Datenversionierung und Provenienz: DVC, DVC und wissenschaftliche Workflows

Bei der Datenversionierung in der wissenschaftlichen Simulation geht es nicht darum, Code-Änderungen zu verfolgen – Git verarbeitet das bereits perfekt. Es geht darum, zu verfolgen, welche Spezifische Kombination von Datendateien, Code-Commits und Parameterdateien zu einem bestimmten Ergebnis geführt hat. Diese Unterscheidung unterscheidet einen fragilen experimentellen Arbeitsablauf von einer reproduzierbaren Simulationspipeline.

Das am weitesten verbreitete Tool dafür ist DVC (Data Version Control), das das Versionsmodell von Git erweitert, um große Datensätze und Pipeline-Stufen zu verarbeiten. Dieser Artikel behandelt die praktische DVC-Implementierung für wissenschaftliche Workflows – Pipeline-Konstruktion mit dvc.yaml, Parameterisolierung mit params.yaml, HPC/Slurm-Integration und aufkommende Provenienz-Tracking von W3C Prov-JSON – so können Sie deterministische Simulationskampagnen erstellen, die das Team überleben Umsatz, Hardware-Migration und jahrelange Projektlebenszyklen.

Schlüssel zum Mitnehmen

  • Der Kernwert von DVC: Pipeline-Dateien (dvc.yaml) machen Simulationen abhängigkeitsbewusst, sodass dvc repro nur die Änderungen erneut ausführt.
  • Versionsreproduzierbarkeit: DVC verknüpft Daten-Snapshots (.dvc Dateien), Code-Commits (Git) und Parameterdateien (params.yaml) zu reproduzierbaren Experimentiereinheiten
  • HPC-Integration: Slurm-Batchplanung umschließt DVC für die Ausführung von Cluster-Native Pipeline ohne manuellen Eingriff
  • Provenance Standards: W3C Prov-JSON (YProv4ML) tritt als interoperables Format auf, das zu Ro-Crate-Verpackungen ergänzt
  • DVC vs Datalad: Wählen Sie DVC für Pipeline-orientierte Experimente; Wählen Sie DataLad für langfristige Datenkuration und verteilte Datensätze

Warum die Standardversionierung für Simulationsworkflows fehlschlägt

Git eignet sich hervorragend zum Tracking von Code-Änderungen. Es ist schrecklich, Datenänderungen zu verfolgen.

Wenn Sie eine DFT-Relaxationsberechnung ausführen, kann Git die resultierende .xyz-Kristallstrukturdatei (oft zehn MB) nicht speichern. Sie können es auf ein freigegebenes Laufwerk kopieren oder seinen SHA-256-Hash an eine Textdatei anhängen oder sich auf den Speicher verlassen. Alle drei Ansätze werden unterbrochen, wenn sich die Datenquelle ändert, wenn Sie sie mit Mitarbeitern teilen müssen, die keinen Zugriff auf das freigegebene Laufwerk haben, oder wenn Sie sechs Monate später wiederkommen und vergessen, welcher Parametersatz die Struktur mit der niedrigsten Energie erzeugt hat.

Datenversionstools lösen dies durch die Entkopplung von Datenverfolgung von Code-Tracking. Sie speichern aktuelle Dateien im Remote-Speicher (Google Drive, S3, ein freigegebenes NAS oder sogar ein anderes Git-Repository) und registrieren leichte Zeigerdateien im Git-Repository. Die Zeigerdateien – in der Regel kleine .dvc-Dateien oder Git-Annex-Symlink-Referenzen – enthalten Metadaten (Checksum, Remote-Standort, Versions-Tag), ohne die tatsächlichen Daten zu duplizieren.

Diese Trennung ist für Simulations-Workflows wichtig, da das Datenvolumen unabhängig vom Codevolumen skaliert wird. Eine einzelne Simulationskampagne kann Tausende von Trajektoriendateien erzeugen, während die Python-Skripte, die sie erzeugen, in einigen hundert Zeilen bleiben.

Die Pipeline-Lücke

Die meisten Forscher beginnen mit der Ad-hoc-Datenverfolgung: Ein Bash-Skript, das Berechnungen in der Reihenfolge ausführt, die Ergebnisse in ein Verzeichnis results/ kopiert und die endgültigen Zahlen in ein Google Sheet eingefügt werden. Das funktioniert für kleine Projekte. Es bricht zusammen, wenn:

  1. Neulauf mit unterschiedlichen Parametern – Sie müssen sich merken, welche params.yaml-Datei verwendet wurde, und nur die geänderten Phasen erneut ausführen
  2. Debugging-Fehler – Sie müssen wissen, ob der Fehler auf Datenbeschädigung, Code-Änderungen oder Parameterfehlanpassungen zurückzuführen ist
  3. Team Handoff – Ein neuer Schüler kann die Pipeline nicht aus einem bash-Skript und einem Ordner mit verwaisten Dateien rekonstruieren

Die DVC-Pipeline-Definitionsdatei (dvc.yaml) schließt diese Lücke, indem sie Phasen mit expliziten Abhängigkeiten und Ausgaben deklariert. Jede Phase wird nur dann erneut ausgeführt, wenn sich die Abhängigkeiten ändern (dvc repro <stage>), wodurch Simulationskampagnen beim erneuten Ausführen von Berechnungen mit unterschiedlichen Parametern dramatisch effizienter werden.

DVC-Pipeline-Konstruktion für wissenschaftliche Workflows

Eine DVC-Pipeline-Datei ist ein deklaratives YAML-Dokument, das die Abhängigkeit Ihrer Simulationsschritte voneinander abbildet. Hier ist ein konkretes Beispiel für einen Workflow für Computational Materials Science:

# dvc.yaml — DFT relaxation and energy calculation pipeline

stages:
  relax:
    cmd: python src/relax.py
    deps:
    - data/raw_crystal_structure.xyz
    - src/relax.py
    params:
    - params.yaml
    outs:
    - results/relaxed_structure.xyz

  energy:
    cmd: python src/energy.py
    deps:
    - results/relaxed_structure.xyz
    - src/energy.py
    params:
    - params.yaml
    outs:
    - results/energies.txt
    metrics:
    - results/energies.txt

  visualize:
    cmd: python src/plot.py
    deps:
    - results/energies.txt
    - src/plot.py
    outs:
    - figures/energy_plot.png

Jede Etappe erklärt:

  • cmd: Der Befehl, der die Ausgaben dieser Stufe generiert
  • deps: Dateien, die diese Phase, wenn sie geändert werden, auslösen
  • params: Parameterdateien, die bei einer erneuten Ausführung dieser Phase auslösen
  • outs: Dateien, die in dieser Phase erstellt wurden (verfolgen als Datenversionen)
  • metrics: Dateien, die DVC zum Experimentieren numerisch verfolgt

Warum params.yaml wichtig ist

Die Datei params.yaml isoliert Simulationsparameter aus Ausführungsskripten. Dies ist entscheidend für materialwissenschaftliche Workflows, bei denen derselbe Simulationscode hunderte Male mit unterschiedlichen Parametern ausgeführt wird:

# params.yaml
simulator:
  cutoff_energy: 500  # eV
  kpoints: [8, 8, 8]
  tolerance: 1e-6
  
optimization:
  max_steps: 200
  algorithm: ionic

Wenn Sie tolerance von 1e-6 in 1e-8 ändern und dvc repro ausführen, erkennt DVC die Änderung von params.yaml und führt jede davon abhängige Phase erneut aus. Die resultierende Datei relaxed_structure.xyz erhält ein neues Versions-Tag. Die alte Version bleibt im Cache verfügbar – Sie verlieren keine historischen Läufe.

Für Parameter-Sweeps können Sie --set-param verwenden, um Werte zu überschreiben, ohne die Datei zu ändern:

dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450

Dadurch wird ein neuer Experimentzweig erstellt, der sowohl die ursprünglichen als auch die geänderten Läufe in Ihrem Pipeline-Verlauf beibehält.

Versionierte Reproduzierbarkeit – der konzeptionelle Beitrag von DVC

Der Blog von DVC (Dezember 2021) führte die „versionierte Reproduzierbarkeit“ als die Fähigkeit ein, nicht nur ein Ergebnis, sondern auch den Exact experimental state nachzubilden, der es erzeugt hat. Dies unterscheidet DVC von der generischen Versionierung:

  • Standardversionierung Verfolgen Sie Änderungen an Dateien im Laufe der Zeit (Git-Zweck)
  • Versionsreproduzierbarkeit Verfolgen Sie, welche bestimmte Datenversion, Code-Commit und Parameterdateikombination ein bestimmtes Ergebnis erzeugt hat (DVC-Zweck)

DVC erreicht dies durch die Verknüpfung von drei unabhängig versionierten Artefakten:

Artefakt Versionierungssystem Was es verfolgt
.dvc Zeigerdateien DVC Datendateiversion + Remote-Standort + Prüfsumme
Git verpflichtet Git Codeversion + Commit-Nachricht + Diff
params.yaml Git Parameterdateiversion + Änderungen auf Feldebene

Die Kombination dieser drei schafft eine reproduzierbare Einheit – ein „versioniertes Experiment“, das isoliert rekonstruiert werden kann. Dies ist für die Simulation von Bedeutung, da Experimente iterativ verfeinert werden. Die Forscher müssen wissen, was funktioniert hat, und es reproduzieren können, ohne jeden Zwischenschritt erneut ausführen zu können.

Praktische Implikationen

Wenn ein Prüfer nach den Daten hinter einer veröffentlichten Figur fragt, können Sie Folgendes angeben:

  1. Der Git-Commit-Hash (Code-Version)
  2. Die Referenzdatei-Referenz .dvc (Datenversion)
  3. Die Datei params.yaml bei diesem Commit (Parameterversion)

Zusammen reichen diese drei Artefakte aus, um das Ergebnis auf jeder Maschine zu reproduzieren. Dies ist der Goldstandard für die Reproduzierbarkeit der Simulation – weit über Container (die Codeumgebungen einfrieren) oder nackte Git-Repositories (die keine großen Daten verarbeiten können).

Versuchswarteschlange und Management

Das Experiment-Management (dvc exp) von DVC erweitert das Pipeline-Modell, um gleichzeitige und in der Warteschlange gestellte Experimente zu unterstützen:

# Run a single experiment with custom parameters
dvc exp run -S sim.tolerance=1e-8

# Queue multiple experiments
dvc exp run --queue -S sim.tolerance=1e-8
dvc exp run --queue -S sim.tolerance=1e-6
dvc exp run --queue -S sim.tolerance=1e-5

# Execute queued experiments
dvc exp run

Das Flag --queue verzögert die Ausführung, sodass Sie mehrere Experimente vorbereiten und diese nacheinander ausführen können. Dies ist wertvoll für Computerexperimente, die stundenlang oder tagelang ausgeführt werden. Sie können einen Parameter-Sweep über Nacht in die Warteschlange stellen, ohne jeden Lauf manuell zu starten.

Für den Experimentvergleich bietet DVClive Echtzeit-Metrik-Tracking:

# src/metrics.py — DVCLive integration
from dvclive import Live

with Live() as live:
    for step in range(n_iterations):
        result = run_step(step)
        live.step = step
        live.log("energy", result["total_energy"])
        live.log("forces", result["max_force"])

Dies erzeugt ein interaktives Vergleichs-Dashboard, in dem Sie sehen können, wie sich Energie und Kräfte bei Parameter-Sweeps entwickeln.

Ausführen von DVC-Pipelines auf HPC-Clustern

Die meisten Computerwissenschaftler betreiben keine Pipelines auf Laptops. Sie führen sie auf Clustern mit Slurm-, PBS- oder LSF-Schedulern aus. DVC lässt sich über den srun-Wrapper in Slurm integrieren und ermöglicht die Ausführung von generativen Pipeline-Ausführungen:

# Run a single pipeline stage with SLURM resource allocation
srun dvc repro -n relax --job slurm-job.sh

# Run all pipeline stages on the cluster
srun dvc repro

Das Flag --job weist DVC an, jede Phase über den Job-Scheduler von Slurm auszuführen und automatisch zu bearbeiten:

  • Clusterspezifische Ressourcenzuordnung (Speicher, CPU, GPU-Knoten)
  • Batch-Modus-Ausführung ohne manuellen Eingriff
  • Automatische Jobwarteschlange für Pipeline-Stufen
  • Integration mit clusterspezifischen Dateisystemen und Speicher (LUSTRE, GPFS, BEEGFS)

ARXIV 2505.06558v2 (September 2025) zeigt diese Integration für materialwissenschaftliche Workflows mit DFT-Berechnungen auf HPC-Clustern. Der entscheidende Vorteil ist, dass dvc repro Cluster-fähig wird. Wenn eine Phase fehlschlägt oder sich ihre Abhängigkeiten ändern, übernimmt Slurm die Ressourcenzuweisung, um nur die erforderlichen Phasen erneut auszuführen.

Überlegungen zum Clusterspeicher

Der Remote-Speicher von DVC funktioniert gut mit Cluster-Dateisystemen. Sie können DVC so konfigurieren, dass das Lüster- oder GPFS-Dateisystem des Clusters als DVC-Remote verwendet wird:

# Configure a cluster storage remote
dvc remote modify cluster_storage token_url "https://cluster-storage.example.com"

Dies vermeidet den Aufwand beim Kopieren von Daten in den externen Cloud-Speicher und hält die Pipeline innerhalb der Speicherhierarchie des Clusters eigen.

W3C Prov-JSON Provenienz-Tracking

Während DVC Pipeline-Stufen und Datenversionen verfolgt, erzeugt es nativ kein maschinell umsetzbares Provenienzdiagramm. Dafür benötigen Sie einen Provenienzstandard – und das aufkommende Format ist W3C Prov-JSON.

Yprov4ML (ArXiv Juli 2025) implementiert die W3C Proven-JSON-Provenienz mit minimalen Code-Modifikationen. Es erfasst:

  • Wer hat das Experiment ausgeführt (Benutzeridentität)
  • Was Daten und Code wurden verwendet (Quelle Provenienz)
  • Wie Das Experiment lief (Execution Provenienz)
  • Warum (optionale Motivation, gebunden an Forschungsziele)

Die Ausgabe ist ein Prov-JSON-Diagramm – ein gerichteter Graph, in dem Knoten Entitäten (Dateien, Parameter, Code-Commits) und Kanten darstellen (abgeleitet von, erzeugt von, erstellt, verwendet von By). Dieses Format ermöglicht:

  • Interoperabilität über Provenienzsysteme: Prov-JSON ist maschinenlesbar und kann mit SPARQL- oder Graph-Datenbanken abgefragt werden
  • Faire Daten-Konformität: Prov-JSON-Diagramme erfüllen faire Prinzipien, indem sie die Datenlinien und die Wiederverwendungsbedingungen dokumentieren
  • Institutionelle Zusammenarbeit: Prov-JSON ist ein W3C-Standard, daher sind Provenienz-Diagramme verschiedener Institutionen kompatibel

Prov-JSON gegen Ro-Crate

Es ist nützlich, Prov-JSON von Ro-Crate zu unterscheiden, da beide in Reproduzierbarkeitsdiskussionen erscheinen:

Aspekt Ro-Crate prov-json
Zweck Paketformat für Rich-Metadaten Datenformat für Provenienzdiagramme
Umfang Ganzer Datensatz + zugehörige Ressourcen Ausführungslinie und Abhängigkeiten
Format json-ld JSON (PROV-Standard)
Interoperabilität Eigenständiges Paket Graph-basiert, abfragefähig
Beziehung Komplementär, nicht konkurrierend

Sie befassen sich mit verschiedenen Reproduzierbarkeitsschichten. Ro-Crate packt Ihr Dataset mit Metadaten. Prov-JSON verfolgt die Berechnungslinie der Erstellung dieses Datensatzes. Die Verwendung beider zusammen bietet die volle Reproduzierbarkeit: „Hier sind die Daten“ (Ro-Crate) plus „Hier ist, wie es produziert wurde“ (prov-json).

Wann verwenden Sie DVC vs DataLad vs. Prov-kompatible Bibliotheken

Die Wahl zwischen DVC-, DataLad- und Prov-kompatiblen Bibliotheken hängt von Ihren Workflow-Mustern ab:

Kriterium DVC datalad Prov-Bibliotheken
Hauptanwendungsfall Pipeline-orientierte Experimente Langfristige Datenkuration Maschinell umsetzbare Provenienz
Datengröße Große Dateien (Modelle, Simulationen) Große verteilte Datensätze N/A (metadatenorientiert)
Ausführungsmodell Bühnenbasierte Pipeline (dvc repro) Befehlsbasiert (datalad run) Dekorateur
HPC-Integration srun dvc repro Native Git-Anhang + SSH konfigurierbar
Provenienzausgabe .dvc Dateien + Git-Verlauf Git-Annex-Symlinks + Git-Log Prov-JSON-Diagramm
am besten für Material-Science-Pipelines, Parameter-Sweeps Langfristige Repository-Kuration, Einhaltung der Gebote Faire Daten, institutionelle Provenienz

DVC ist genau das Richtige für Sie, wenn:

  • Ihr Workflow hat mehrere abhängige Phasen (Entspannung → Eigenschaftsberechnung → Visualisierung)
  • Sie benötigen Parameter-Sweeps mit automatischer Nachlauf
  • Sie möchten verfolgen, welche Parameterkombination das Ergebnis mit der niedrigsten Energie erzeugt

Datalad ist genau das Richtige für Sie, wenn:

  • Sie kuratieren ein langfristiges Dataset-Repository
  • Sie benötigen Git-Annex-Symlinks für die effiziente Handhabung von Großdateien
  • Sie arbeiten mit verteilten Datensätzen über Institutionen hinweg
  • Sie benötigen die Einhaltung von Geboten (häufig in der Neuroimaging)

Pro-konforme Bibliotheken sind für Sie richtig, wenn:

  • Sie benötigen maschinell umsetzbare Provenienz für faire Einhaltung
  • Sie möchten ein abfragefähiges Provenienzdiagramm für die Datenabstammung
  • Sie arbeiten in verschiedenen Institutionen mit verschiedenen Provenienzsystemen zusammen
  • Sie veröffentlichen in einem fairen Daten-Repository

Zusammenstellen – ein praktischer Workflow

Hier ist ein praktisches Workflow-Muster, das alle oben genannten Konzepte kombiniert:

# 1. Initialize the repository
git init
dvc init

# 2. Add the data
dvc add data/raw_crystal_structure.xyz

# 3. Run the pipeline
dvc repro

# 4. Check the results
dvc metrics show results/energies.txt

# 5. Run experiments with different parameters
dvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550

# 6. Push data and experiments to remote
dvc push
dvc exp push
git push origin main

# 7. (Optional) Generate PROV-JSON provenance
python src/provenance.py --output provenance.json

Dieses Muster stellt sicher, dass jedes Simulationsergebnis auf seine genaue Datenversion, das Code-Commit und die Parameterdatei zurückgeführt werden kann. Die Prov-JSON-Ausgabe (Schritt 7) fügt eine maschinenaktionsfähige Provenienzschicht auf der DVC-Pipeline hinzu.

Häufige Fehler – was zu vermeiden

Fehler 1: Alles versionieren – Führen Sie nicht dvc add in jeder Ausgabedatei aus. Verfolgen Sie nur Dateien, die in nachfolgende Phasen eingegeben werden oder die Endergebnisse darstellen. Zwischendateien (wie Raw Force Arrays) sollten in git bleiben oder vollständig ausgeschlossen werden. Überaddieren erzeugt Pipeline-Lärm.

Fehler 2: Hardcoding-Pfade: Verwenden Sie in dvc.yaml keine absoluten Pfade. Verwenden Sie relative Pfade, damit die Pipeline auf verschiedenen Computern und Clusterkonfigurationen funktioniert.

Fehler 3: Datentypen mischen: Geben Sie keine Simulationsparameter und modellieren Sie Prüfpunkte in derselben .dvc-Datei. Halten Sie Datentypen getrennt, um Cache-Konflikte zu vermeiden.

Fehler 4: Provenienz ignorieren – DVC-Dateien allein reichen nicht für eine faire Einhaltung aus. Wenn Ihre Institution Provenienzdiagramme benötigt, koppeln Sie DVC mit Prov-JSON-Ausgabe (Yprov4ML) oder Ro-Crate-Verpackungen.

Fehler 5: Vergessen von params.yaml — Wenn Sie in Ihren Skripten Hardcode-Parameter in Ihren Skripten vergeben, anstatt sie in params.yaml zu isolieren, wird das Parameter-Tracking von DVC nutzlos. Verwenden Sie für Simulationsparameter immer params.yaml.

Zusammenfassung

DVC wandelt wissenschaftliche Workflows aus fragilen, speicherabhängigen Prozessen in deterministische, abhängigkeitsbewusste Pipelines um. Die wichtigste Erkenntnis ist, dass dvc.yaml Pipeline-Dateien und die Parameterisolation params.yaml „versionierte Reproduzierbarkeit“ erstellen – die Fähigkeit, nicht nur ein Ergebnis zu rekonstruieren, sondern auch den exakten experimentellen Status (Datenversion + Code-Commit + Parameterdatei), der es erzeugt hat. Dies geht über Container hinaus (die Code-Umgebungen einfrieren) und über Git hinaus (die keine großen Datensätze verarbeiten können).

Für die HPC-Integration ermöglicht der srun-Wrapper von Slurm die Ausführung einer Cluster-nativen Pipeline ohne manuellen Eingriff. Für die Provenienz bildet sich W3C Prov-JSON (Yprov4ML) als interoperables Format, das zu Ro-Crate-Verpackungen komplementiert wird und die maschinenschaltbare Datenlinie ermöglicht, die den Anforderungen der fairen Einhaltung genügt.

Die Wahl zwischen DVC-, DataLad- und Prov-kompatiblen Bibliotheken hängt von Ihren Workflow-Mustern ab: DVC für pipeline-orientierte Experimente, DataLad für die Langzeit-Datenkuration und Prov-Bibliotheken für maschinell umsetzbare Provenienzdiagramme. Die meisten Simulationsteams profitieren von der Verwendung von DVC für die Pipeline-Ausführung und Prov-JSON für die Provenienzverfolgung – die beiden Tools sind komplementär und konkurrieren nicht.

Verwandte Anleitungen

<tool_call>
<function=fs_write_file>
< Parameter=Content>

Python-Datenversionierung und Provenienz: DVC, DVC und wissenschaftliche Workflows

Bei der Datenversionierung in der wissenschaftlichen Simulation geht es nicht darum, Code-Änderungen zu verfolgen – Git verarbeitet das bereits perfekt. Es geht darum, zu verfolgen, welche Spezifische Kombination von Datendateien, Code-Commits und Parameterdateien zu einem bestimmten Ergebnis geführt hat. Diese Unterscheidung unterscheidet einen fragilen experimentellen Arbeitsablauf von einer reproduzierbaren Simulationspipeline.

Das am weitesten verbreitete Tool dafür ist DVC (Data Version Control), das das Versionsmodell von Git erweitert, um große Datensätze und Pipeline-Stufen zu verarbeiten. Dieser Artikel behandelt die praktische DVC-Implementierung für wissenschaftliche Workflows – Pipeline-Konstruktion mit dvc.yaml, Parameterisolierung mit params.yaml, HPC/Slurm-Integration und aufkommende Provenienz-Tracking von W3C Prov-JSON – so können Sie deterministische Simulationskampagnen erstellen, die das Team überleben Umsatz, Hardware-Migration und jahrelange Projektlebenszyklen.

Schlüssel zum Mitnehmen

  • Der Kernwert von DVC: Pipeline-Dateien (dvc.yaml) machen Simulationen abhängigkeitsbewusst, sodass dvc repro nur die Änderungen erneut ausführt.
  • Versionsreproduzierbarkeit: DVC verknüpft Daten-Snapshots (.dvc Dateien), Code-Commits (Git) und Parameterdateien (params.yaml) zu reproduzierbaren Experimentiereinheiten
  • HPC-Integration: Slurm-Batchplanung umschließt DVC für die Ausführung von Cluster-Native Pipeline ohne manuellen Eingriff
  • Provenance Standards: W3C Prov-JSON (YProv4ML) tritt als interoperables Format auf, das zu Ro-Crate-Verpackungen ergänzt
  • DVC vs Datalad: Wählen Sie DVC für Pipeline-orientierte Experimente; Wählen Sie DataLad für langfristige Datenkuration und verteilte Datensätze

Warum die Standardversionierung für Simulationsworkflows fehlschlägt

Git eignet sich hervorragend zum Tracking von Code-Änderungen. Es ist schrecklich, Datenänderungen zu verfolgen.

Wenn Sie eine DFT-Relaxationsberechnung ausführen, kann Git die resultierende .xyz-Kristallstrukturdatei (oft zehn MB) nicht speichern. Sie können es auf ein freigegebenes Laufwerk kopieren oder seinen SHA-256-Hash an eine Textdatei anhängen oder sich auf den Speicher verlassen. Alle drei Ansätze werden unterbrochen, wenn sich die Datenquelle ändert, wenn Sie sie mit Mitarbeitern teilen müssen, die keinen Zugriff auf das freigegebene Laufwerk haben, oder wenn Sie sechs Monate später wiederkommen und vergessen, welcher Parametersatz die Struktur mit der niedrigsten Energie erzeugt hat.

Datenversionstools lösen dies durch die Entkopplung von Datenverfolgung von Code-Tracking. Sie speichern aktuelle Dateien im Remote-Speicher (Google Drive, S3, ein freigegebenes NAS oder sogar ein anderes Git-Repository) und registrieren leichte Zeigerdateien im Git-Repository. Die Zeigerdateien – in der Regel kleine .dvc-Dateien oder Git-Annex-Symlink-Referenzen – enthalten Metadaten (Checksum, Remote-Standort, Versions-Tag), ohne die tatsächlichen Daten zu duplizieren.

Diese Trennung ist für Simulations-Workflows wichtig, da das Datenvolumen unabhängig vom Codevolumen skaliert wird. Eine einzelne Simulationskampagne kann Tausende von Trajektoriendateien erzeugen, während die Python-Skripte, die sie erzeugen, in einigen hundert Zeilen bleiben.

Die Pipeline-Lücke

Die meisten Forscher beginnen mit der Ad-hoc-Datenverfolgung: Ein Bash-Skript, das Berechnungen in der Reihenfolge ausführt, die Ergebnisse in ein Verzeichnis results/ kopiert und die endgültigen Zahlen in ein Google Sheet eingefügt werden. Das funktioniert für kleine Projekte. Es bricht zusammen, wenn:

  1. Neulauf mit unterschiedlichen Parametern – Sie müssen sich merken, welche params.yaml-Datei verwendet wurde, und nur die geänderten Phasen erneut ausführen
  2. Debugging-Fehler – Sie müssen wissen, ob der Fehler auf Datenbeschädigung, Code-Änderungen oder Parameterfehlanpassungen zurückzuführen ist
  3. Team Handoff – Ein neuer Schüler kann die Pipeline nicht aus einem bash-Skript und einem Ordner mit verwaisten Dateien rekonstruieren

Die DVC-Pipeline-Definitionsdatei (dvc.yaml) schließt diese Lücke, indem sie Phasen mit expliziten Abhängigkeiten und Ausgaben deklariert. Jede Phase wird nur dann erneut ausgeführt, wenn sich die Abhängigkeiten ändern (dvc repro <stage>), wodurch Simulationskampagnen beim erneuten Ausführen von Berechnungen mit unterschiedlichen Parametern dramatisch effizienter werden.

DVC-Pipeline-Konstruktion für wissenschaftliche Workflows

Eine DVC-Pipeline-Datei ist ein deklaratives YAML-Dokument, das die Abhängigkeit Ihrer Simulationsschritte voneinander abbildet. Hier ist ein konkretes Beispiel für einen Workflow für Computational Materials Science:

# dvc.yaml — DFT relaxation and energy calculation pipeline

stages:
  relax:
    cmd: python src/relax.py
    deps:
    - data/raw_crystal_structure.xyz
    - src/relax.py
    params:
    - params.yaml
    outs:
    - results/relaxed_structure.xyz

  energy:
    cmd: python src/energy.py
    deps:
    - results/relaxed_structure.xyz
    - src/energy.py
    params:
    - params.yaml
    outs:
    - results/energies.txt
    metrics:
    - results/energies.txt

  visualize:
    cmd: python src/plot.py
    deps:
    - results/energies.txt
    - src/plot.py
    outs:
    - figures/energy_plot.png

Jede Etappe erklärt:

  • cmd: Der Befehl, der die Ausgaben dieser Stufe generiert
  • deps: Dateien, die diese Phase, wenn sie geändert werden, auslösen
  • params: Parameterdateien, die bei einer erneuten Ausführung dieser Phase auslösen
  • outs: Dateien, die in dieser Phase erstellt wurden (verfolgen als Datenversionen)
  • metrics: Dateien, die DVC zum Experimentieren numerisch verfolgt

Warum params.yaml wichtig ist

Die Datei params.yaml isoliert Simulationsparameter aus Ausführungsskripten. Dies ist entscheidend für materialwissenschaftliche Workflows, bei denen derselbe Simulationscode hunderte Male mit unterschiedlichen Parametern ausgeführt wird:

# params.yaml
simulator:
  cutoff_energy: 500  # eV
  kpoints: [8, 8, 8]
  tolerance: 1e-6
  
optimization:
  max_steps: 200
  algorithm: ionic

Wenn Sie tolerance von 1e-6 in 1e-8 ändern und dvc repro ausführen, erkennt DVC die Änderung von params.yaml und führt jede davon abhängige Phase erneut aus. Die resultierende Datei relaxed_structure.xyz erhält ein neues Versions-Tag. Die alte Version bleibt im Cache verfügbar – Sie verlieren keine historischen Läufe.

Für Parameter-Sweeps können Sie --set-param verwenden, um Werte zu überschreiben, ohne die Datei zu ändern:

dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450

Dadurch wird ein neuer Experimentzweig erstellt, der sowohl die ursprünglichen als auch die geänderten Läufe in Ihrem Pipeline-Verlauf beibehält.

Versionierte Reproduzierbarkeit – der konzeptionelle Beitrag von DVC

Der Blog von DVC (Dezember 2021) führte die „versionierte Reproduzierbarkeit“ als die Fähigkeit ein, nicht nur ein Ergebnis, sondern auch den Exact experimental state nachzubilden, der es erzeugt hat. Dies unterscheidet DVC von der generischen Versionierung:

  • Standardversionierung Verfolgen Sie Änderungen an Dateien im Laufe der Zeit (Git-Zweck)
  • Versionsreproduzierbarkeit Verfolgen Sie, welche bestimmte Datenversion, Code-Commit und Parameterdateikombination ein bestimmtes Ergebnis erzeugt hat (DVC-Zweck)

DVC erreicht dies durch die Verknüpfung von drei unabhängig versionierten Artefakten:

Artefakt Versionierungssystem Was es verfolgt
.dvc Zeigerdateien DVC Datendateiversion + Remote-Standort + Prüfsumme
Git verpflichtet Git Codeversion + Commit-Nachricht + Diff
params.yaml Git Parameterdateiversion + Änderungen auf Feldebene

Die Kombination dieser drei schafft eine reproduzierbare Einheit – ein „versioniertes Experiment“, das isoliert rekonstruiert werden kann. Dies ist für die Simulation von Bedeutung, da Experimente iterativ verfeinert werden. Die Forscher müssen wissen, was funktioniert hat, und es reproduzieren können, ohne jeden Zwischenschritt erneut ausführen zu können.

Praktische Implikationen

Wenn ein Prüfer nach den Daten hinter einer veröffentlichten Figur fragt, können Sie Folgendes angeben:

  1. Der Git-Commit-Hash (Code-Version)
  2. Die Referenzdatei-Referenz .dvc (Datenversion)
  3. Die Datei params.yaml bei diesem Commit (Parameterversion)

Zusammen reichen diese drei Artefakte aus, um das Ergebnis auf jeder Maschine zu reproduzieren. Dies ist der Goldstandard für die Reproduzierbarkeit der Simulation – weit über Container (die Codeumgebungen einfrieren) oder nackte Git-Repositories (die keine großen Daten verarbeiten können).

Versuchswarteschlange und Management

Das Experiment-Management (dvc exp) von DVC erweitert das Pipeline-Modell, um gleichzeitige und in der Warteschlange gestellte Experimente zu unterstützen:

# Run a single experiment with custom parameters
dvc exp run -S sim.tolerance=1e-8

# Queue multiple experiments
dvc exp run --queue -S sim.tolerance=1e-8
dvc exp run --queue -S sim.tolerance=1e-6
dvc exp run --queue -S sim.tolerance=1e-5

# Execute queued experiments
dvc exp run

Das Flag --queue verzögert die Ausführung, sodass Sie mehrere Experimente vorbereiten und diese nacheinander ausführen können. Dies ist wertvoll für Computerexperimente, die stundenlang oder tagelang ausgeführt werden. Sie können einen Parameter-Sweep über Nacht in die Warteschlange stellen, ohne jeden Lauf manuell zu starten.

Für den Experimentvergleich bietet DVClive Echtzeit-Metrik-Tracking:

# src/metrics.py — DVCLive integration
from dvclive import Live

with Live() as live:
    for step in range(n_iterations):
        result = run_step(step)
        live.step = step
        live.log("energy", result["total_energy"])
        live.log("forces", result["max_force"])

Dies erzeugt ein interaktives Vergleichs-Dashboard, in dem Sie sehen können, wie sich Energie und Kräfte bei Parameter-Sweeps entwickeln.

Ausführen von DVC-Pipelines auf HPC-Clustern

Die meisten Computerwissenschaftler betreiben keine Pipelines auf Laptops. Sie führen sie auf Clustern mit Slurm-, PBS- oder LSF-Schedulern aus. DVC lässt sich über den srun-Wrapper in Slurm integrieren und ermöglicht die Ausführung von generativen Pipeline-Ausführungen:

# Run a single pipeline stage with SLURM resource allocation
srun dvc repro -n relax --job slurm-job.sh

# Run all pipeline stages on the cluster
srun dvc repro

Das Flag --job weist DVC an, jede Phase über den Job-Scheduler von Slurm auszuführen und automatisch zu bearbeiten:

  • Clusterspezifische Ressourcenzuordnung (Speicher, CPU, GPU-Knoten)
  • Batch-Modus-Ausführung ohne manuellen Eingriff
  • Automatische Jobwarteschlange für Pipeline-Stufen
  • Integration mit clusterspezifischen Dateisystemen und Speicher (LUSTRE, GPFS, BEEGFS)

ARXIV 2505.06558v2 (September 2025) zeigt diese Integration für materialwissenschaftliche Workflows mit DFT-Berechnungen auf HPC-Clustern. Der entscheidende Vorteil ist, dass dvc repro Cluster-fähig wird. Wenn eine Phase fehlschlägt oder sich ihre Abhängigkeiten ändern, übernimmt Slurm die Ressourcenzuweisung, um nur die erforderlichen Phasen erneut auszuführen.

Überlegungen zum Clusterspeicher

Der Remote-Speicher von DVC funktioniert gut mit Cluster-Dateisystemen. Sie können DVC so konfigurieren, dass das Lüster- oder GPFS-Dateisystem des Clusters als DVC-Remote verwendet wird:

# Configure a cluster storage remote
dvc remote modify cluster_storage token_url "https://cluster-storage.example.com"

Dies vermeidet den Aufwand beim Kopieren von Daten in den externen Cloud-Speicher und hält die Pipeline innerhalb der Speicherhierarchie des Clusters eigen.

W3C Prov-JSON Provenienz-Tracking

Während DVC Pipeline-Stufen und Datenversionen verfolgt, erzeugt es nativ kein maschinell umsetzbares Provenienzdiagramm. Dafür benötigen Sie einen Provenienzstandard – und das aufkommende Format ist W3C Prov-JSON.

Yprov4ML (ArXiv Juli 2025) implementiert die W3C Proven-JSON-Provenienz mit minimalen Code-Modifikationen. Es erfasst:

  • Wer hat das Experiment ausgeführt (Benutzeridentität)
  • Was Daten und Code wurden verwendet (Quelle Provenienz)
  • Wie Das Experiment lief (Execution Provenienz)
  • Warum (optionale Motivation, gebunden an Forschungsziele)

Die Ausgabe ist ein Prov-JSON-Diagramm – ein gerichteter Graph, in dem Knoten Entitäten (Dateien, Parameter, Code-Commits) und Kanten darstellen (abgeleitet von, erzeugt von, erstellt, verwendet von By). Dieses Format ermöglicht:

  • Interoperabilität über Provenienzsysteme: Prov-JSON ist maschinenlesbar und kann mit SPARQL- oder Graph-Datenbanken abgefragt werden
  • Faire Daten-Konformität: Prov-JSON-Diagramme erfüllen faire Prinzipien, indem sie die Datenlinien und die Wiederverwendungsbedingungen dokumentieren
  • Institutionelle Zusammenarbeit: Prov-JSON ist ein W3C-Standard, daher sind Provenienz-Diagramme verschiedener Institutionen kompatibel

Prov-JSON gegen Ro-Crate

Es ist nützlich, Prov-JSON von Ro-Crate zu unterscheiden, da beide in Reproduzierbarkeitsdiskussionen erscheinen:

Aspekt Ro-Crate prov-json
Zweck Paketformat für Rich-Metadaten Datenformat für Provenienzdiagramme
Umfang Ganzer Datensatz + zugehörige Ressourcen Ausführungslinie und Abhängigkeiten
Format json-ld JSON (PROV-Standard)
Interoperabilität Eigenständiges Paket Graph-basiert, abfragefähig
Beziehung Komplementär, nicht konkurrierend

Sie befassen sich mit verschiedenen Reproduzierbarkeitsschichten. Ro-Crate packt Ihr Dataset mit Metadaten. Prov-JSON verfolgt die Berechnungslinie der Erstellung dieses Datensatzes. Die Verwendung beider zusammen bietet die volle Reproduzierbarkeit: „Hier sind die Daten“ (Ro-Crate) plus „Hier ist, wie es produziert wurde“ (prov-json).

Wann verwenden Sie DVC vs DataLad vs. Prov-kompatible Bibliotheken

Die Wahl zwischen DVC-, DataLad- und Prov-kompatiblen Bibliotheken hängt von Ihren Workflow-Mustern ab:

Kriterium DVC datalad Prov-Bibliotheken
Hauptanwendungsfall Pipeline-orientierte Experimente Langfristige Datenkuration Maschinell umsetzbare Provenienz
Datengröße Große Dateien (Modelle, Simulationen) Große verteilte Datensätze N/A (metadatenorientiert)
Ausführungsmodell Bühnenbasierte Pipeline (dvc repro) Befehlsbasiert (datalad run) Dekorateur
HPC-Integration srun dvc repro Native Git-Anhang + SSH konfigurierbar
Provenienzausgabe .dvc Dateien + Git-Verlauf Git-Annex-Symlinks + Git-Log Prov-JSON-Diagramm
am besten für Material-Science-Pipelines, Parameter-Sweeps Langfristige Repository-Kuration, Einhaltung der Gebote Faire Daten, institutionelle Provenienz

DVC ist genau das Richtige für Sie, wenn:

  • Ihr Workflow hat mehrere abhängige Phasen (Entspannung → Eigenschaftsberechnung → Visualisierung)
  • Sie benötigen Parameter-Sweeps mit automatischer Nachlauf
  • Sie möchten verfolgen, welche Parameterkombination das Ergebnis mit der niedrigsten Energie erzeugt

Datalad ist genau das Richtige für Sie, wenn:

  • Sie kuratieren ein langfristiges Dataset-Repository
  • Sie benötigen Git-Annex-Symlinks für die effiziente Handhabung von Großdateien
  • Sie arbeiten mit verteilten Datensätzen über Institutionen hinweg
  • Sie benötigen die Einhaltung von Geboten (häufig in der Neuroimaging)

Pro-konforme Bibliotheken sind für Sie richtig, wenn:

  • Sie benötigen maschinell umsetzbare Provenienz für faire Einhaltung
  • Sie möchten ein abfragefähiges Provenienzdiagramm für die Datenabstammung
  • Sie arbeiten in verschiedenen Institutionen mit verschiedenen Provenienzsystemen zusammen
  • Sie veröffentlichen in einem fairen Daten-Repository

Zusammenstellen – ein praktischer Workflow

Hier ist ein praktisches Workflow-Muster, das alle oben genannten Konzepte kombiniert:

# 1. Initialize the repository
git init
dvc init

# 2. Add the data
dvc add data/raw_crystal_structure.xyz

# 3. Run the pipeline
dvc repro

# 4. Check the results
dvc metrics show results/energies.txt

# 5. Run experiments with different parameters
dvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550

# 6. Push data and experiments to remote
dvc push
dvc exp push
git push origin main

# 7. (Optional) Generate PROV-JSON provenance
python src/provenance.py --output provenance.json

Dieses Muster stellt sicher, dass jedes Simulationsergebnis auf seine genaue Datenversion, das Code-Commit und die Parameterdatei zurückgeführt werden kann. Die Prov-JSON-Ausgabe (Schritt 7) fügt eine maschinenaktionsfähige Provenienzschicht auf der DVC-Pipeline hinzu.

Häufige Fehler – was zu vermeiden

Fehler 1: Alles versionieren – Führen Sie nicht dvc add in jeder Ausgabedatei aus. Verfolgen Sie nur Dateien, die in nachfolgende Phasen eingegeben werden oder die Endergebnisse darstellen. Zwischendateien (wie Raw Force Arrays) sollten in git bleiben oder vollständig ausgeschlossen werden. Überaddieren erzeugt Pipeline-Lärm.

Fehler 2: Hardcoding-Pfade: Verwenden Sie in dvc.yaml keine absoluten Pfade. Verwenden Sie relative Pfade, damit die Pipeline auf verschiedenen Computern und Clusterkonfigurationen funktioniert.

Fehler 3: Datentypen mischen: Geben Sie keine Simulationsparameter und modellieren Sie Prüfpunkte in derselben .dvc-Datei. Halten Sie Datentypen getrennt, um Cache-Konflikte zu vermeiden.

Fehler 4: Provenienz ignorieren – DVC-Dateien allein reichen nicht für eine faire Einhaltung aus. Wenn Ihre Institution Provenienzdiagramme benötigt, koppeln Sie DVC mit Prov-JSON-Ausgabe (Yprov4ML) oder Ro-Crate-Verpackungen.

Fehler 5: Vergessen von params.yaml — Wenn Sie in Ihren Skripten Hardcode-Parameter in Ihren Skripten vergeben, anstatt sie in params.yaml zu isolieren, wird das Parameter-Tracking von DVC nutzlos. Verwenden Sie für Simulationsparameter immer params.yaml.

Zusammenfassung

DVC wandelt wissenschaftliche Workflows aus fragilen, speicherabhängigen Prozessen in deterministische, abhängigkeitsbewusste Pipelines um. Die wichtigste Erkenntnis ist, dass dvc.yaml Pipeline-Dateien und die Parameterisolation params.yaml „versionierte Reproduzierbarkeit“ erstellen – die Fähigkeit, nicht nur ein Ergebnis zu rekonstruieren, sondern auch den exakten experimentellen Status (Datenversion + Code-Commit + Parameterdatei), der es erzeugt hat. Dies geht über Container hinaus (die Code-Umgebungen einfrieren) und über Git hinaus (die keine großen Datensätze verarbeiten können).

Für die HPC-Integration ermöglicht der srun-Wrapper von Slurm die Ausführung einer Cluster-nativen Pipeline ohne manuellen Eingriff. Für die Provenienz bildet sich W3C Prov-JSON (Yprov4ML) als interoperables Format, das zu Ro-Crate-Verpackungen komplementiert wird und die maschinenschaltbare Datenlinie ermöglicht, die den Anforderungen der fairen Einhaltung genügt.

Die Wahl zwischen DVC-, DataLad- und Prov-kompatiblen Bibliotheken hängt von Ihren Workflow-Mustern ab: DVC für pipeline-orientierte Experimente, DataLad für die Langzeit-Datenkuration und Prov-Bibliotheken für maschinell umsetzbare Provenienzdiagramme. Die meisten Simulationsteams profitieren von der Verwendung von DVC für die Pipeline-Ausführung und Prov-JSON für die Provenienzverfolgung – die beiden Tools sind komplementär und konkurrieren nicht.

Verwandte Anleitungen