Monolithische Jupyter-Pipelines Hold

Überblick

Monolithische Jupyter-Notebooks, die ganze ETL-, Training- und Deployment-Pipelines kodieren, erzeugen untestbare, nicht planbare Assets mit verstecktem State und schlechter Kollaboration (Jupyter).

Hold für neue Produktions-Pipelines. Der Weg führt zu modularen Packages, Orchestratoren (Airflow, Dagster) und versionierten Datasets; Notebooks bleiben der Exploration vorbehalten.

Adoptionssignale

• Eine groß angelegte Studie, vorgestellt auf der MSR 2019, hat 1,16 Mio. Notebooks aus 264.023 GitHub-Repositories analysiert: Von 863.878 Ausführungsversuchen liefen nur 24,11 % fehlerfrei und 4,03 % reproduzierten die gespeicherten Ergebnisse; bei 36,36 % der Notebooks mit eindeutiger Ausführungsreihenfolge wurden Zellen außer der Reihe ausgeführt (Pimentel et al., MSR 2019).
• Ein späterer Vergleich von Notebooks und Python-Skripten ergab, dass Notebooks zwar weniger komplex sind, aber 1,4-mal mehr Stilprobleme aufweisen und der Code verflochtener wirkt (Grotov et al., 2022).
• Plattformen, die Notebooks planbar machen, lenken in Richtung Versionskontrolle: Databricks empfiehlt ein entferntes Git-Repository für die Versionierung von Assets, die über Jobs geplant werden (Databricks Notebook Task).
• Orchestratoren behandeln ein Notebook als einen Schritt in einem größeren Graphen statt als die Pipeline: Dagstermill reicht Inputs und Outputs zwischen Notebooks und anderen Assets weiter und führt deren Logs zusammen (Dagster Jupyter Integration).
• Neuere Notebook-Werkzeuge setzen an den Ursachen an: marimo speichert Notebooks als reines Python, führt abhängige Zellen reaktiv neu aus und macht Notebooks als Skripte ausführbar (marimo Docs).

Risiken

• Versteckter State. Außer der Reihe ausgeführte oder nachträglich geänderte Zellen hinterlassen einen Kernel-Zustand, den niemand rekonstruieren kann; die MSR-2019-Studie nennt versteckten State und Ausführungsreihenfolge als Hauptursachen gescheiterter Reproduktion (Pimentel et al., MSR 2019).
• Keine Einheit für Retry oder Backfill. Teilen sich Extraktion, Feature Engineering, Training und Veröffentlichung einen Kernel, bedeutet ein später Fehler einen kompletten Neustart, und Partitionen oder einzelne Schritte lassen sich nicht nachladen.
• Ungetestete Produktionslogik. In Zellen definierte Funktionen lassen sich kaum in Test-Suites importieren, sodass Geschäftsregeln und Datentransformationen ohne automatisierte Prüfung in Produktion gelangen.
• Undichte Artefakte. Ausgaben werden im .ipynb-JSON gespeichert; während eines Laufs ausgegebene Beispielzeilen, personenbezogene Daten oder Credentials landen so in der Git-Historie und in Code-Review-Tools.
• Schwacher Audit-Trail. Ohne versionierten Code, Parameter und Eingangsdaten pro Lauf lässt sich nicht belegen, welche Daten und welche Logik ein Modell erzeugt haben, was regulierte Umgebungen und Model-Risk-Reviews verlangen.

Empfehlung

Hold: Neue Produktions-Pipelines sollten nicht als einzelne Notebooks entstehen. Notebooks bleiben für Exploration, Prototypen und Berichte; wiederverwendbare Logik gehört in versionierte Python-Packages mit Unit-Tests. Pipelines laufen als getrennte Schritte in einem Orchestrator wie Airflow, Dagster oder Prefect, damit jeder Schritt wiederholt, nachgeladen und überwacht werden kann; Datasets und Modellartefakte werden pro Lauf versioniert.

Bei bestehenden Notebook-Pipelines empfiehlt es sich, mit der geschäftskritischsten zu beginnen: Funktionen in ein Package extrahieren, Tests um die Transformationen legen, Ausgaben vor dem Commit entfernen und das Package vom Orchestrator aufrufen lassen. Wo ein Notebook im Ablauf bleiben muss, etwa für einen parametrisierten Bericht, sollte es über Papermill oder Dagstermill als ein expliziter Schritt mit festen Parametern laufen, nicht als ganze Pipeline. Wer Notebook-Ergonomie ohne versteckten State sucht, kann marimo evaluieren, das Notebooks als reines Python speichert.

Quellen

• JupyterLab
• nbconvert
• Papermill
• Pimentel et al.: A Large-scale Study about Quality and Reproducibility of Jupyter Notebooks (MSR 2019, Preprint)
• MSR-2019-Paperseite
• Grotov et al.: A Large-Scale Comparison of Python Code in Jupyter Notebooks and Scripts (arXiv)
• Databricks Notebook Task für Jobs
• Dagster Jupyter Integration (Dagstermill)
• marimo Docs