huggingface/datasets: Lader und Verarbeitungsschicht für Trainingsdaten

Welches Problem die Bibliothek abnimmt

Wer ein Modell trainiert, verbringt den ersten Teil der Arbeit nicht mit dem Modell, sondern mit Daten: eine Quelle finden, sie herunterladen, das Format erraten, die Felder umbenennen, ein Trainings- und ein Validierungssplit bilden, das Ergebnis zwischenspeichern. Jeder dieser Schritte ist einzeln trivial und in Summe lästig. huggingface/datasets setzt genau dort an. Die README beschreibt zwei Hauptfunktionen: Einzeiler-Loader für öffentliche Datensätze und eine Verarbeitungsschicht für eigene Dateien. Der Anspruch ist nicht, Daten zu erzeugen oder zu kuratieren, sondern sie in eine Form zu bringen, die ein Trainingsloop direkt konsumieren kann. Die Zielgruppe sind damit nicht Datenkuratoren, sondern ML-Ingenieure und Forschende, die einen Datensatz in Numpy, Pandas, PyTorch, TensorFlow oder JAX weiterverwenden wollen. Die Bibliothek positioniert sich als Zwischenschicht, nicht als Endpunkt.

Arrow als Speicher, map() als Verarbeitung

Das sichtbare Architekturelement ist Apache Arrow. Die README nennt es als Backend und beschreibt es als zero-copy und memory-mapped, sodass Datensätze nicht vollständig in den RAM passen müssen. Praktisch heißt das: Nach dem ersten Laden liegt der Datensatz als Arrow-Datei auf der Platte, und der Zugriff auf eine Zeile ist ein Zugriff auf einen Speicherbereich, kein Parsen von JSON. Darauf setzt die Verarbeitung auf. Der zentrale Aufruf ist dataset.map(process_example), im Quick Start in zwei Varianten gezeigt: einmal elementweise mit einer Lambda-Funktion, die eine neue Spalte length aus der Länge des Feldes context berechnet, einmal batched=True mit einem Tokenizer aus der Transformers-Bibliothek. Der zweite Fall ist der wichtige, weil Tokenisieren in Stapeln deutlich weniger Aufrufe pro Sekunde kostet als zeilenweise. Dazu kommt map(num_proc=N) für parallele Verarbeitung. Ergebnisse landen im Cache, und laut README werden zwischengespeicherte Resultate automatisch wiederverwendet. Diese Kopplung von Arrow, map() und Cache ist der eigentliche Kern der Bibliothek. Wer sie umgeht und stattdessen direkt mit Pandas arbeitet, verliert genau die Eigenschaften, wegen derer man sie installiert.

Installation und optionale Abhängigkeiten

Die Installation ist ein Befehl: pip install datasets, ausgeführt in einer virtuellen Umgebung, wie die README ausdrücklich empfiehlt. Für die Entwicklungsversion gibt es pip install "datasets @ git+https://github.com/huggingface/datasets.git", für Conda conda install -c huggingface -c conda-forge datasets. Interessanter sind die Extras, weil sie zeigen, wo die Bibliothek Abhängigkeiten auslagert. Audio braucht torchcodec über datasets[audio], Bild und Video brauchen Pillow und torchcodec über datasets[vision], PDF und NIfTI brauchen pdfplumber und nibabel über datasets[pdfs,nibabel], und die Framework-Anbindung kommt über datasets[torch,tensorflow,jax]. Diese Aufteilung ist bewusst: Eine Installation ohne Audio-Extra zieht keinen Codec mit. Die Kehrseite ist eine Fehlerklasse, die man kennen sollte. Ein Datensatz mit Audiodateien lässt sich laden, aber die Dekodierung schlägt fehl, wenn das Extra fehlt. Die README benennt die Extras, aber nicht, welche Fehlermeldung dabei entsteht. Das ist einer der Punkte, die man vor dem ersten Einsatz selbst prüfen muss.

Streaming: der Ausweg, wenn die Platte nicht reicht

Ein Datensatz, der als Arrow-Datei auf der Platte liegt, muss erst vollständig heruntergeladen und geschrieben werden. Bei großen Korpora ist das der teuerste Schritt, und in manchen Umgebungen ist er gar nicht möglich, etwa in einem Container mit wenig persistentem Speicher. Dafür gibt es streaming=True. Die README beschreibt den Modus als Iterieren über die Daten ohne Download und nennt eine Beschleunigung um bis zu 100x durch das Xet-Backend. Diese Zahl stammt aus der Projektbeschreibung, nicht aus einer unabhängigen Messung, und sie sagt nichts über den Durchsatz im eigenen Netzwerk. Wichtiger als die Zahl ist die Konsequenz für die Verarbeitung: Im Streaming-Modus sind die Daten ein Iterator, kein indexierbarer Datensatz. Man kann nicht einfach dataset['train'][0] aufrufen, und Operationen, die einen vollständigen Durchlauf und eine Neuanordnung voraussetzen, verhalten sich anders. Die README zeigt den Streaming-Modus als Feature, nicht als Modus mit eingeschränkter API. Wer ihn nutzt, sollte das vorher wissen.

Formate, Modalitäten und die Grenze zur Datenbank

Die Formatliste ist breit: CSV, JSON, JSONL, Parquet, Arrow, XML, Text und Webdataset auf der strukturierten Seite, dazu PNG, JPEG, WAV, MP3, PDF und NIfTI für Medien. Auf der Hub-Seite kommen laut README Textdatensätze in 467 Sprachen und Dialekten, Bild-, Audio-, Video-, 3D-Medizin- und Agent-Trace-Datensätze zusammen. Diese Breite ist der Grund, warum die Bibliothek in so vielen Trainingsskripten auftaucht. Sie ist aber keine Datenbank. Es gibt kein Transaktionsmodell, keine Nebenläufigkeitskontrolle für schreibende Zugriffe und keine Abfragesprache. Wenn ein Team mehrere Prozesse gleichzeitig in denselben Datensatz schreiben lassen will, ist das nicht der vorgesehene Anwendungsfall. Dasselbe gilt für inkrementelle Updates: Ein Datensatz wird geladen, transformiert und als neue Version abgelegt, nicht zeilenweise fortgeschrieben. Die README nennt Hugging Face Storage Buckets für veränderliche Rohdaten, was die Lücke adressiert, aber die Verarbeitungsschicht bleibt auf unveränderliche, materialisierte Datensätze ausgelegt.

Alternative: WebDataset und der Unterschied im Ansatz

Wer Trainingsdaten aus vielen kleinen Dateien in großem Maßstab über mehrere Knoten verteilt liest, greift häufig zu WebDataset. Der Unterschied liegt nicht im Funktionsumfang, sondern im Speichermodell. WebDataset speichert Beispiele als Folge von Einträgen in großen Tar-Shards und liest sie sequenziell; die Reihenfolge ist Teil des Formats, und jedes Beispiel bleibt an einem festen Platz im Shard. Das lässt sich gut mit mehreren Workern und Shuffle-Puffern kombinieren, weil kein globaler Index nötig ist. huggingface/datasets geht den umgekehrten Weg: Es materialisiert den Datensatz in Arrow, baut einen Index und erlaubt wahlweise wahlfreien Zugriff oder Streaming. Das ist bequemer für Inspektion, Filterung und Splits, aber es kostet den Schritt der Materialisierung. Interessant ist, dass die README Webdataset als unterstütztes Eingabeformat nennt. Man kann also WebDataset-Shards laden und trotzdem map() und den Cache nutzen. Die Wahl ist damit nicht binär, sondern eine Frage dessen, ob man die Indexierung braucht.

Wartung, Versionierung und Lizenz

Die Release-Historie zeigt einen schnellen Takt: 4.8.5 im April 2026, 5.0.0 im Juni 2026, 5.0.1 im Juli 2026, dazu ein letzter Push im September 2026. Ein Sprung auf eine neue Hauptversion bedeutet in der Praxis, dass man die eigenen Aufrufe gegen die Release Notes prüfen muss, bevor man die Version in einer laufenden Pipeline anhebt. Das ist der eigentliche Upgrade-Aufwand, nicht die Installation. Hinzu kommt der Cache: Wenn map() Ergebnisse zwischenspeichert, kann ein Versionswechsel dazu führen, dass alte Cache-Einträge nicht mehr passen und neu erzeugt werden müssen. Wer den Speicherverbrauch planen will, muss diesen Pfad kennen. Die Lizenz ist Apache-2.0, also eine permissive Lizenz mit einer ausdrücklichen Patentklausel. Sie erlaubt kommerzielle Nutzung und Modifikation unter Bedingungen, die im LICENSE-File stehen. Das betrifft die Bibliothek. Für die Datensätze selbst gilt das nicht: Jeder Datensatz auf dem Hub kann eine eigene Lizenz haben, und die prüft man beim jeweiligen Datensatz, nicht beim Loader. Diese Unterscheidung wird in der README nicht ausgeführt.

Was man vor dem ersten Commit prüfen sollte

Drei Dinge lassen sich aus dem Material ableiten und sollten vor dem Einbau in eine Pipeline geklärt werden. Erstens die Extras: Ob datasets[audio], datasets[vision] oder datasets[pdfs,nibabel] die im eigenen Datensatz vorkommenden Dateitypen abdecken, steht nicht in der README, sondern ergibt sich erst beim Laden. Zweitens der Cache-Pfad: Die automatische Wiederverwendung von map()-Ergebnissen setzt voraus, dass der Speicherort ausreichend groß und im Container persistent ist, sonst wird bei jedem Start neu gerechnet. Drittens der Unterschied zwischen Streaming und materialisiertem Laden: Ein Skript, das dataset['train'][0] aufruft, läuft mit streaming=True nicht unverändert. Wer diese drei Punkte vorab testet, spart sich Fehlersuchen, die nichts mit dem Modell zu tun haben.

Redaktionelles Fazit

Sinnvoll ist die Bibliothek für Teams, die öffentliche Datensätze aus dem Hugging Face Hub nutzen oder lokale Dateien in CSV, JSON, Parquet und ähnlichen Formaten in eine einheitliche, an PyTorch oder TensorFlow anschlussfähige Struktur bringen wollen. Wer eine Datenbank mit Transaktionen, Indizes und Mehrbenutzer-Schreibzugriff braucht, ist hier falsch; dafür ist das Format nicht gedacht. Vor dem ersten produktiven Einsatz sollte man prüfen, ob datasets[audio] oder datasets[vision] die eigenen Codecs abdeckt, ob der Cache-Pfad auf einer Platte mit genug Platz liegt und ob das Laden eines einzelnen Datensatzes im Streaming-Modus dieselben Spalten liefert wie im nicht gestreamten Modus.

Offizielle Quellen

1. huggingface/datasets on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases