Reproduzierbarkeit Workflows über Container hinaus: Datenversionierung und Provenienzverfolgung

Schlüssel zum Mitnehmen

• Container lösen ein Problem. Sie frieren die Softwareumgebung ein, verfolgen jedoch nicht, was sich in Ihren Daten geändert hat oder wie sich Ihre Analyse entwickelt hat.
• Datenversionierung fügt eine fehlende Ebene hinzu. Tools wie DVC und DataLad bringen die Versionskontrolle im Git-Stil in Datasets und erleichtern die Wiedergabe von Ergebnissen mit exakten Eingaben, Parameterdateien und ausgewählten Ausgaben.
• Provenienz ist der Audit-Trail. Es zeichnet jede Transformation, die Ihren Daten passiert ist, von RAW-Dateien bis zu endgültigen Zahlen auf.
• Container, Datenversionierung und Provenienzverfolgung ergänzen sich. Zusammen decken sie Code, Umgebung, Daten und Abstammung ab.

Was Sie zuerst wissen sollten

Container wie Docker und Singularity sind zu einem fast obligatorischen Teil der reproduzierbaren Forschung geworden. Sie lösen ein echtes Problem: Wenn Sie jemandem ein Docker-Image senden, sollte diese Person in der Lage sein, den Code auszuführen und die gleichen Ergebnisse auf einem anderen Computer zu erhalten.

Aus diesem Grund fragen Zeitschriften und Rezensenten neben Papieren zunehmend nach Containerbildern. Container lassen jedoch zwei kritische Lücken offen.

Erstens verfolgen Container keine Änderungen an Ihren Daten. Ein Datensatz entwickelt sich im Laufe der Zeit, wenn Sie ihn bereinigen, filtern und erneut verarbeiten. Wenn Sie sechs Monate später ein Ergebnis reproduzieren, müssen Sie wissen, welche Version der Daten diese Zahl erzeugt hat. Container zeichnen dies standardmäßig nicht auf.

Zweitens erfassen Container keine Abstammungslinie. Wenn ein Analyseskript falsch ist, ein Parameter versehentlich geändert wurde oder ein Vorverarbeitungsschritt inkonsistent angewendet wurde, gibt es möglicherweise keine automatische Aufzeichnung dessen, was passiert ist. Sie verlassen sich auf Speicher, manuelle Notizen oder Glück.

Dieser Artikel erklärt, wie moderne wissenschaftliche Workflows diese Lücken durch Datenversionierung und Provenienzverfolgung lösen. Die Datenversionierung verfolgt Datensatzänderungen im Laufe der Zeit. Die Provenienzverfolgung zeichnet jede Transformation auf die Daten auf.

Container reichen nicht aus

Vor der Erörterung der Datenversionierung hilft es zu verstehen, was Container tun und was nicht.

Ein Container erfasst:

• Das Betriebssystem, normalerweise eine Linux-Distribution.
• Installierte Pakete und ihre Versionen.
• Ihre Code- und Konfigurationsdateien.
• Der Befehl, mit dem die Analyse ausgeführt wird.

Ein Container erfasst nicht automatisch:

• Die genauen Dateien werden als Eingaben verwendet, es sei denn, sie werden in das Bild eingebrannt.
• Laufzeitparameter, es sei denn, sie werden explizit protokolliert.
• Zwischenausgänge, die während einer Pipeline generiert werden.
• Die Reihenfolge und Logik der Transformationen, die auf die Daten angewendet werden.

Die praktische Konsequenz ist einfach. Sie können einen Container auf einem anderen Computer ausführen und dieselbe Ausgabe nur erhalten, wenn auch die Eingaben und der Laufzeitkontext gesteuert werden. Wenn Sie eine bestimmte Analyse von vor Monaten reproduzieren möchten, insbesondere eine mit mehreren Schritten und einem sich ändernden Datensatz, benötigen Sie mehr als einen Container.

Betrachten Sie ein gemeinsames Szenario. Sie trainieren eine Phasenfeldsimulation auf experimentellen Mikrostrukturbildern. Die Bilder werden während der Vorverarbeitung gereinigt und dann in Trainings- und Validierungssätze aufgeteilt. Sechs Monate später bittet dich jemand, die Simulation zu reproduzieren.

Sie öffnen den Container, führen den Befehl aus und erhalten das falsche Ergebnis. Der Grund kann sein, dass der Datensatz neu organisiert wurde, neue Samples hinzugefügt wurden oder der Einstiegspunkt die Dateien verwendete, die sich gerade in einem Verzeichnis befanden. Ohne versionierte Eingaben und einen Audit-Trail kann der Container allein nicht beweisen, was passiert ist.

Hier werden Datenversionierung und Provenienzverfolgung notwendig.

Was ist Datenversionierung?

Die Datenversionierung bringt dieselbe Idee, die Git für Code nützlich macht, in die Welt der Datensätze. Anstatt jede große Binärdatei direkt zu verfolgen, werden in bestimmten Momenten leichte Schnappschüsse oder Zeiger auf bestimmte Datenzustände erstellt.

Die Kernidee ist einfach:

1. Sie ändern das Dataset, z. B. das Hinzufügen von Dateien, das Ändern von Dateien oder das Reorganisieren von Ordnern.
2. Sie begehen einen Snapshot, der aufzeichnet, was sich geändert hat und wo die aktuellen Daten leben.
3. Später können Sie diesen Snapshot überprüfen, um den genauen Datenstatus wiederherzustellen, der ein bestimmtes Ergebnis hervorgebracht hat.

Zwei führende Tools im wissenschaftlichen Python-Ökosystem sind DVC und DataLad.

DVC: Datenversionskontrolle

DVC ist ein weit verbreitetes Datenversionierungstool für Python-basierte Workflows. Es wird durch die Generierung kleiner Metadatendateien erstellt, die Datenspeicherorte und Prüfsummen verfolgen, während sich die tatsächlichen Daten im Remote-Speicher befinden, z. B. Cloud-Buckets, lokale Festplatten oder gemeinsam genutzte Netzwerke.

Für wissenschaftliche Workflows sind mehrere DVC-Funktionen wichtig:

• Pipelinedefinition. dvc.yaml Dateien ermöglichen Ihnen die Beschreibung der Analyse-Pipeline, einschließlich Eingaben, Ausgaben, Verarbeitungsschritten und Abhängigkeiten.
• Versuchsverfolgung. dvc exp run Erstellt isolierte Experiment-Namespaces, sodass Sie Parameterkonfigurationen testen können, ohne den Git-Verlauf zu überladen.
• Fernspeicher. DVC kann Daten an konfigurierte Remotes wie S3, Google Cloud Storage, Azure, SSH-Server oder freigegebene Dateisysteme übertragen.
• Zeitreise. Sie können einen Git-Commit auschecken, dvc pull und dvc checkout ausführen und den Datenstatus von diesem Punkt aus wiederherstellen.

Ein typischer wissenschaftlicher Arbeitsablauf kann wie folgt aussehen:

# Initialize DVC in your project
dvc init

# Add your dataset
dvc add data/raw_microstructures/

# Commit only the lightweight metadata
git add data/raw_microstructures.dvc
git commit -m "Initial microstructure dataset"

# Define a processing pipeline
dvc run -d data/raw_microstructures.dvc -o data/cleaned/ 
    python src/preprocess.py

# Run experiments
dvc exp run --set-param preprocessing.threshold=0.5

datalad

DataLad wurde für wissenschaftliche Datensätze entwickelt und verwendet Git-Annex unter der Haube. Es ist besonders nützlich für große Datensätze, die sich über viele Dateien erstrecken können, z. B. Simulationen, experimentelle Messungen, Bildgebungsdaten oder Sammlungen institutioneller Forschungsergebnisse.

DataLad bietet mehrere wissenschaftlich spezifische Vorteile:

• Dataset-zentriertes Design. DataLad behandelt jedes Verzeichnis als Dataset mit versioniertem Verlauf.
• Datenabruf bei Bedarf. Anstatt alles zu ziehen, kann DataLad bei Bedarf bestimmte Dateien oder Unterverzeichnisse abrufen.
• Eingebaute Replikation. DataLad kann Geschwister-Repositories in verschiedenen Institutionen verwalten, um Redundanz und Compliance zu gewährleisten.
• HPC-Integration. Erweiterungen können Chargenplanungssysteme wie Slurm und PBS unterstützen.

Ein grundlegender DataLad-Workflow sieht folgendermaßen aus:

# Initialize a dataset
datalad create -s my-dataset

# Add data using git-annex under the hood
datalad add data/raw_images/

# Record a provenance-rich commit
datalad save -m "Add raw imaging data, batch 2024-01"

# Clone to another machine and fetch data on demand
datalad clone my-dataset
datalad get data/processed_results/

Wann verwenden Sie welche

DVC ist oft besser für Teams, die in Python-Datenwissenschaften arbeiten, die Pipeline-Tracking und Experiment-Management benötigen. Es integriert sich natürlich in Tools wie scikit-learn, PyTorch und andere Python-Workflows.

DataLad ist oft besser für langfristige Datenkurationsprojekte, insbesondere wenn Datensätze groß sind, über Institutionen verteilt sind oder voraussichtlich über viele Jahre überleben werden.

Sie schließen sich nicht gegenseitig aus. Beide verwenden Git als Teil ihres Versionskontroll-Backbone und beide können mit containerisierten Ausführungsumgebungen kombiniert werden.

Was ist Provenienzverfolgung?

Provenienz ist die systematische Aufzeichnung darüber, woher Daten stammen und was damit passiert ist. In wissenschaftlichen Arbeitsabläufen beantwortet die Provenienz praktische Fragen:

• Welche Version der Eingabedaten wurde verwendet?
• Welche Parameter wurden während der Verarbeitung angewendet?
• Welche Zwischendateien wurden generiert?
• Welche Softwareversionen waren aktiv, als die Ausgabe produziert wurde?
• Wer hat den Workflow und wann ausgeführt?

Zwei Arten von Provenienz sind in wissenschaftlichen Arbeitsabläufen wichtig.

Prospektive Herkunft beschreibt, was passieren wird. Es ist die geplante Workflow-Spezifikation: das Rezept, wie Daten durch die Analyse verschoben werden sollen. Tools wie CWL und WDL verwenden deklarative Formate, um anzugeben, was bei der Ausführung eines Workflows passieren soll.

Retrospektive Provenienz beschreibt, was tatsächlich passiert ist. Es zeichnet Ausführungsprotokolle, Umgebungs-Snapshots, Datenprüfsummen und genaue Laufzeitdateien auf. Dies ist der Audit-Trail, der die Reproduzierbarkeit unterstützt.

Ro-Crate: Verpackungsforschungsartefakte mit Provenienz

Ro-Crate ist ein Standard für die Verpackung von Forschungsergebnissen, Datendateien, Workflow-Definitionen, Parametern und Logs in einem maschinenlesbaren Archiv.

Ein Ro-Crate-Archiv ist normalerweise ein Verzeichnis oder eine ZIP-Datei, die Folgendes enthält:

• Datendateien und Analyseausgaben.
• Eine ro-crate-metadata.json-Datei mit JSON-LD-Metadaten.
• Workflow-Definitionen wie CWL-, NextFlow- oder SnakeMake-Dateien.
• Ausführungsprotokolle und Umgebungserfassungen.

Ro-Crate ist nützlich, weil es leicht und tragbar ist. Sie benötigen keine spezielle Datenbank oder einen speziellen Dienst, um diese zu überprüfen. Jeder mit den Dateien kann die Metadaten lesen und die Herkunft verstehen.

Das Format unterstützt sowohl die prospektive Provenienz, die beschreibt, was der Workflow plant, als auch die retrospektive Provenienz, die aufzeichnet, was tatsächlich gelaufen ist.

Ro-Crate gewinnt im wissenschaftlichen Rechnen an Bedeutung. Plattformen wie Galaxy, WorkflowHub und Zenodo unterstützen Ro-Crate-Exporte und sind somit nützlich für publikationsfähige Forschungsartefakte.

Alles zusammen: Ein praktisches Workflow-Muster

Container, Datenversionierung und Provenienzverfolgung funktionieren am besten, wenn sie zusammen verwendet werden. Jeder deckt eine andere Reproduzierbarkeitsschicht ab.

Schritt 1: Version Ihrer Daten mit DVC oder DataLad

Beginnen Sie mit der Versionierung von RAW-Eingängen. Verwenden Sie dvc add oder datalad add für jeden Datensatz, der in die Analyse einspeist. Übergeben Sie die DVC- oder Git-Annex-Metadatendateien an Git neben dem Code.

Schritt 2: Definieren Sie Ihre Pipeline

Wenn Sie DVC verwenden, schreiben Sie eine dvc.yaml-Datei, die jeden Verarbeitungsschritt als Stufe beschreibt. Verwenden Sie bei Bedarf dokumentierte Skripte, konsistente Parameterdateien und Geschwister-Repositories, wenn Sie DataLad verwenden.

Schritt 3: Die Ausführung containerisieren

Umfassen Sie Analyseskripts in einen Container, der über Computer ausgeführt werden kann. Der Container hält Python-Pakete, C++-Bibliotheken und Binärdateien konsistent. Es ersetzt nicht versionierte Eingänge.

Schritt 4: Provenienz mit Ro-Crate oder CWLProv erfassen

Packen Sie am Ende jedes Workflow-Laufs Artefakte in ein Ro-Crate-Archiv. Das gibt dir:

• Ein einzelnes Verzeichnis oder eine ZIP-Datei mit Daten, Code, Protokollen und Metadaten.
• Maschinenlesbare Provenienz, die mit Datensätzen verknüpft ist.
• Persistente Identifikatoren, wenn sie in Repositories wie Zenodo oder FigShare hinterlegt werden.

Der Arbeitsablauf in der Praxis

Your Project Directory
├── .git/                     # Code and metadata
├── .dvc/                     # DVC pipeline state
├── src/                      # Analysis scripts
├── data/                     # Versioned datasets
├── results/                  # Output data
├── dvc.yaml                  # Pipeline definition
├── params.yaml               # Parameter file
└── Dockerfile                # Container definition

Das Ausführen des Workflows kann wie folgt aussehen:

# Restore exact data state
dvc checkout

# Run with pinned container
docker run -v $(pwd):/workspace my-analysis:1.2 python src/run.py

# Package results with provenance
ro-crate add data/results.csv params.yaml results/

Häufige Fehler

Dies sind häufige Fallstricke, wenn Forscher Datenversionierung und Provenienzverfolgung einführen.

1. Verfolgen Sie jede Zwischendatei

Die Versionierung jeder Zwischendatei ist in der Regel unnötig und kann schädlich werden. Es bläst Speicher und Metadaten auf, ohne die Reproduzierbarkeit zu verbessern.

Nur verfolgen:

• RAW-Eingaben, die die ursprünglich erworbenen Dateien sind.
• vorverarbeitete Daten, die kuratierte Version, die tatsächlich für die Analyse verwendet wird.
• Endgültige Ausgabedateien wie Abbildungen, Tabellen und veröffentlichte Simulationsausgaben.

Versionieren Sie nicht jede temporäre CSV- oder Scratch-Datei, es sei denn, es ist erforderlich, das Endergebnis zu reproduzieren.

2. Vergessen von Versionsparameterdateien

Wenn Parameter nur als Befehlszeilenargumente übergeben werden, können sie möglicherweise nicht nur von Git aus wiederhergestellt werden. Parameterdateien sind genauso wichtig wie Datendateien.

versionieren sie explizit:

dvc add configs/params.yaml
git add configs/params.yaml.dvc

3. Angenommen, Container lösen alles

Container sind wertvoll, aber sie sind nur eine Schicht. Ein Container ohne versionierte Eingaben und Provenienz reicht nicht aus, um zu beweisen, wie ein bestimmtes Ergebnis erzeugt wurde.

Stellen Sie sich Container als die Umgebungsschicht vor. Sie benötigen weiterhin Datenversionierung für Eingaben und Provenienz-Tracking für den Workflow-Verlauf.

4. Ignorieren der Remotespeicherkonfiguration

DVC und DataLad funktionieren am besten, wenn der Remote-Speicher frühzeitig konfiguriert ist. Ohne Remotes können Metadatendateien auf lokale Pfade verweisen, die beim Wechseln in einen Cluster oder eine Cloud-Umgebung verschwinden.

Konfigurieren Sie Remotes zu Beginn des Projekts, nicht während einer Terminkrise.

Auswahl des richtigen Werkzeugs für Ihr Projekt

Die Werkzeuglandschaft ist vielfältig. Verwenden Sie dieses Entscheidungsframework als Ausgangspunkt.

Sie können auch Werkzeuge kombinieren. Verwenden Sie beispielsweise DVC für die Datenversionierung, Docker für Umgebungsreproduzierbarkeit und Ro-crate, um den endgültigen Workflow-Lauf für die Veröffentlichung zu verpacken.

Was macht man als nächstes

Wenn Sie ein neues Projekt starten, ist der Pfad unkompliziert:

1. Initialisieren Sie ein Git-Repository für den Code.
2. Fügen Sie DVC mit dvc init und Versions-RAW-Datasets hinzu.
3. Schreiben Sie Analyseskripte als Python-Dateien oder Bash-Skripte.
4. Containerisieren Sie den Workflow mit Docker oder Singularity.
5. Paketergebnisse mit Ro-Crate bei jedem wichtigen Meilenstein.

Wenn Sie an einem bestehenden Projekt arbeiten, beginnen Sie klein:

1. Fügen Sie DVC zum Repository- und Versionsschlüssel-Datasets hinzu.
2. Schreiben Sie eine dvc.yaml-Datei, die die Pipeline beschreibt.
3. Containerisieren Sie den Hauptausführungsschritt.
4. Erstellen Sie ein Ro-Crate-Archiv für das wichtigste Ergebnis.

Mit diesem inkrementellen Ansatz können Sie Reproduzierbarkeitsschichten hinzufügen, ohne das gesamte Projekt neu zu schreiben.

Verwandte Anleitungen

• Versionierung und Integrität in der Forschungssoftware – Ein umfassenderer Blick auf Versionskontrolle, Reproduzierbarkeit und Rückverfolgbarkeit von Workflows für Forschungssoftwareteams.
• Python-Debugging für wissenschaftlichen Code – Debugging-Muster, die neben reproduzierbaren Workflows funktionieren.

Dieser Artikel behandelt die Datenversionierung und Provenienzverfolgung als praktische Werkzeuge für reproduzierbare wissenschaftliche Workflows. DVC, Datalad und Ro-Crate werden aktiv gepflegt und im wissenschaftlichen Python-Ökosystem weit verbreitet. Die neuesten Setup-Details finden Sie immer in der offiziellen Dokumentation für jedes Werkzeug.