Data-Juicer: Datenaufbereitung als YAML-Rezept

Welches Problem Data-Juicer adressiert

Rohdaten für Foundation Models liegen selten in einer Form vor, die sich direkt zum Trainieren eignet. Die Arbeit davor besteht aus vielen kleinen, wiederkehrenden Schritten: Duplikate entfernen, Längen filtern, Whitespace normalisieren, Sprachanteile schätzen, multimodale Paare prüfen. Diese Schritte werden in der Praxis oft als lose Skriptsammlung geschrieben, die niemand versioniert und deren Parameter niemand später rekonstruieren kann. Genau dort setzt Data-Juicer an. Das Projekt beschreibt sich selbst als Sammlung modularer Bausteine, die Daten über den gesamten Lebenszyklus bereinigen, synthetisieren und analysieren. Angesprochen sind Teams, die Korpora für Pre-Training, Fine-Tuning, Reinforcement Learning oder Evaluierung kuratieren, außerdem Gruppen, die Agent-Traces säubern oder Indizes für Retrieval-Systeme vorbereiten. Ein Einzelentwickler mit ein paar tausend Zeilen ist nicht die Zielgruppe, auch wenn das Projekt einen Einstieg über eine Python-API anbietet.

Rezept, Operator, Executor: der Aufbau

Die zentrale Abstraktion ist das Rezept. Es ist eine YAML-Datei, die eine geordnete Liste von Operatoren beschreibt, und laut README lässt es sich wie Code versionieren, teilen und forken. Operatoren sind die eigentlichen Arbeitsschritte und nach Typ getrennt: Filter entfernen Datensätze, Mapper schreiben Felder um. Das README zeigt beide Kategorien in einem kurzen Beispiel, in dem eine TextLengthFilter mit min_len=10 und eine WhitespaceNormalizationMapper hintereinander auf ein NestedDataset angewendet werden. Diese Trennung ist mehr als Namenskonvention. Sie bestimmt, wie die Ausführung geplant wird: Filter reduzieren die Datenmenge, Mapper ändern sie, und daraus ergeben sich unterschiedliche Möglichkeiten, Schritte zusammenzufassen. Die Release Notes zu v1.5.4 nennen eine Batch-local Stage Fusion, die genau hier ansetzt. Abseits der Python-API übernimmt ein Executor die Verteilung über Ray. Die Release Notes zu v1.6.0 beschreiben zwei Neuerungen an dieser Stelle: Partitionen werden cluster-aware berechnet, das heißt die Anzahl leitet sich aus den live verfügbaren Ray-Ressourcen ab; manuell gesetztes partition.size schneidet Daten an Zeilengrenzen, auch wenn die Eingabe weniger Blöcke als Partitionen hat. Zusätzlich prüft eine Konfigurationsvalidierung vor dem Lauf, ob Operatorparameter gültig sind und Executor und Schema zusammenpassen. Wer schon einmal einen mehrstündigen Lauf wegen eines falsch geschriebenen Schlüssels verloren hat, erkennt den Wert dieser Prüfung.

Installation und der erste Lauf

Das README nennt zwei Wege. Der kürzeste ist die Installation über uv und der Aufruf der Kommandozeile:

uv pip install py-data-juicer dj-process --config demos/process_simple/process.yaml

Der zweite Weg führt über Python und ist für kleine Experimente gedacht. Das Beispiel importiert NestedDataset aus data_juicer.core.data, TextLengthFilter aus data_juicer.ops.filter und WhitespaceNormalizationMapper aus data_juicer.ops.mapper, baut ein Dataset aus einem Dictionary mit dem Feld text und ruft ds.process mit einer Liste von Operatorinstanzen auf. Die Parameter stehen dabei direkt im Code, nicht in der YAML-Datei. Für den produktiven Betrieb ist das Rezept der relevante Pfad, weil nur dort die Konfiguration vom Ausführungscode getrennt bleibt. Wer einen Sprachmodell-Backend anbinden will, setzt laut Release Notes zu v1.6.0 in prepare_api_model den Wert api_backend="litellm" für Chat-, Embedding- und Responses-Anfragen; der OpenAI-kompatible Backend bleibt der Standard. Für den Export nennt dieselbe Version einen gemeinsamen Dateisystem-Dispatch für lokal, S3 und HDFS, wobei JSONL nun Python-Datumswerte im ISO-Format serialisiert.

Skalierung und ihre Kosten

Das README nennt zwei Zahlen zur Größenordnung: 70 Milliarden Samples in zwei Stunden auf 50 Ray-Knoten mit 6400 Kernen, und 5 TB Deduplizierung in 2,8 Stunden auf 1280 Kernen. Diese Werte stammen aus der Projektdokumentation und sind nicht unabhängig überprüft. Wichtiger als die Zahl selbst ist, was sie voraussetzt. Beide Szenarien beschreiben Cluster mit tausenden Kernen, und Ray ist keine optionale Beigabe, sondern die Grundlage der Verteilung. Wer diese Infrastruktur nicht betreibt, bekommt von Data-Juicer keinen Vorteil gegenüber einem einzelnen Prozess. Umgekehrt ist die automatische Operator-Fusion, die das README mit 2 bis 10 facher Beschleunigung angibt, ein Hinweis darauf, dass die Reihenfolge der Operatoren im Rezept die Laufzeit beeinflusst. Ein Rezept ist damit nicht nur eine Beschreibung der Datenverarbeitung, sondern auch eine Leistungsentscheidung. Die Reihenfolge zu ändern, um schneller zu werden, kann das Ergebnis verändern, wenn ein Filter vor oder nach einem Mapper greift.

Wo Data-Juicer die falsche Wahl ist

Die größte Einschränkung steckt in der Vielfalt selbst. Über 200 Operatoren bedeuten viele Kombinationen und viele Parameter. Die Konfigurationsvalidierung aus v1.6.0 fängt strukturelle Fehler ab, aber sie kann nicht beurteilen, ob eine Schwelle fachlich richtig gewählt ist. Ein TextLengthFilter mit min_len=10 entfernt kurze Einträge, ob das für den eigenen Korpus sinnvoll ist, bleibt eine offene Frage. Dazu kommt die Abhängigkeit von Modellen und externen Diensten. Manche Operatoren arbeiten mit Tokenizern, andere mit Bildmodellen, wieder andere mit API-Backends. Die Release Notes zu v1.6.0 erwähnen ausdrücklich, dass Token-Zählfilter die Batch-Größe des Tokenizers begrenzen, um den Spitzenverbrauch bei langen Eingaben zu senken. Das ist ein Beleg dafür, dass Speicherverbrauch ein reales Thema ist. Wer keinen Cluster betreiben will oder dessen Daten in eine einzelne Maschine passen, fährt mit pandas, DuckDB oder einem eigenen Skript schneller. Für einen einmaligen Bereinigungslauf mit wenigen Regeln ist der Aufwand für Installation, Rezept und Validierung nicht zu rechtfertigen.

Abgrenzung zu HuggingFace Datasets und Spark

Der naheliegende Vergleich ist HuggingFace Datasets mit map und filter. Beide Ansätze arbeiten über eine Liste von Transformationen auf einem Dataset, und für kleine bis mittlere Datenmengen ist der Unterschied gering. Die Abweichung liegt im Ausführungsmodell. Datasets führt Transformationen typischerweise innerhalb eines Prozesses oder über eine schmale Parallelisierung aus, während Data-Juicer die Verteilung an Ray delegiert und die Partitionierung an die verfügbaren Cluster-Ressourcen koppelt. Dafür bezahlt man mit einer schwereren Abhängigkeit. Ein zweiter Vergleich ist Spark. Spark ist eine allgemeine Daten-Engine mit eigener SQL-Oberfläche und eigenem Katalog, Data-Juicer ist auf die speziellen Operationen der Modell-Datenaufbereitung zugeschnitten: Deduplizierung, multimodale Filter, semantisches Tagging, synthetische Erzeugung. Wer bereits eine Spark-Umgebung betreibt, wird dort bleiben, solange die benötigten Schritte mit DataFrame-Operationen ausdrücken kann. Sobald multimodale Filter oder vorgefertigte Rezepte gebraucht werden, verschiebt sich die Rechnung. Die Rezepte selbst liegen übrigens nicht im Hauptrepository, sondern laut README in einem getrennten Repository datajuicer/data-juicer-hub.

Wartung, Versionen und Lizenz

Die Release-Kadenz ist eng. Zwischen v1.5.4 am 23. Juli 2026 und v1.6.0 am 9. September 2026 liegen drei Veröffentlichungen, jede mit Verhaltensänderungen. v1.5.5 brachte externe Operator-Plugins, HDFS-I/O und Optimierungen für Ray Data sowie elastisches Multi-Node-Sharding. v1.6.0 änderte unter anderem die Standardwerte der Reader, damit sie über Ausführung und Analyse hinweg konsistent gelten. Solche Angleichungen sind nützlich, aber sie sind auch ein Signal: Wer ein Rezept über Versionen hinweg unverändert weiterverwendet, sollte die Release Notes lesen, weil sich Ergebnisse verschieben können, ohne dass sich das Rezept geändert hat. Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen an Dateien kenntlich gemacht werden. Wer Data-Juicer als Bestandteil eines ausgelieferten Produkts einsetzt, muss die Weitergabe der Lizenztexte mitdenken. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Pflichten aus Apache-2.0 an das Produkt gebunden bleiben und nicht am Entwicklungswerkzeug enden.

Redaktionelles Fazit

Sinnvoll ist Data-Juicer für Teams, die Korpora wiederkehrend und nachvollziehbar aufbereiten müssen und bereits Ray oder ein Cluster betreiben. Wer einmalig ein paar tausend Zeilen filtert, sollte bei pandas oder einfachen Skripten bleiben, weil der Aufwand für Rezept, Installation und Konfigurationsprüfung den Nutzen übersteigt. Vor dem ersten produktiven Lauf ist zu klären, ob die im Rezept gesetzten Operatorparameter die eigene Datenverteilung treffen, ob der Ausführungsmodus jedes Operators zum gewählten Executor passt (die Release Notes zu v1.6.0 nennen hier Korrekturen an den Ausführungsmodus-Deklarationen von Deduplicatoren) und welche Schritte der Pipeline auf GPU oder API-Zugriff angewiesen sind, weil das die Kosten und die Reproduzierbarkeit des Laufs bestimmt.

Offizielle Quellen

1. datajuicer/data-juicer on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases