CSV in Parquet umwandeln

Ein CSV, das aus einem Vorsystem oder einer Fachanwendung fällt, ist in vielen deutschen Datenabteilungen die am wenigsten aufbereitete Station der ganzen Kette — der Dump vor den Joins, vor der Maskierung, vor allem, was aus ihm ein geprüftes Datenmodell macht. Wer ihn in eine Analyseumgebung bringt, tut das meist genau einmal und will danach nicht mehr mit der Textdatei arbeiten müssen.

Parquet ist die Antwort darauf, weil es Typen und Schema selbst trägt, statt beides bei jedem Einlesen neu zu erraten. Genau das erwartet man von einem Datenformat, das mehrfach gelesen und nur einmal geschrieben wird — und ein Rohexport, der ein Datenschutz- oder Vertraulichkeitsproblem ist, sollte diese Umwandlung nicht auf einem fremden Server durchlaufen.

Alles, was ein CSV über sich selbst weiß, ist eine Kopfzeile, und eine Kopfzeile ist eine Liste von Namen. Sie kann nicht sagen, dass „betrag" eine Dezimalzahl ist, dass „aktiv" ein Wahrheitswert ist oder dass „kundennummer" niemals als Rechenwert behandelt werden soll. Jedes Werkzeug, das die Datei liest, muss das erneut herausfinden, und jedes tut es ein wenig anders — weshalb derselbe Export in drei Systemen drei verschiedene Ergebnisse liefert.

Eine Parquet-Datei endet mit einem Footer, der das Schema, die Zeilenzahl und Metadaten je Spalte trägt. Ein Abfragewerkzeug liest zuerst diesen Footer, wenige Kilobyte am Dateiende, und kennt Spaltennamen und -typen, bevor auch nur eine Zeile gelesen wird. Das ist keine Bequemlichkeit, sondern eine strukturelle Eigenschaft: Sie macht das Format sicher genug, um es jemandem zu geben, der beim Schreiben nicht dabei war.

Drei Effekte wirken je Spalte zusammen. Die Werte werden binär statt als Dezimaltext geschrieben, sodass eine Zahl, die im CSV elf Zeichen brauchte, vier Byte belegt. Jede Spalte wird danach für sich mit Snappy komprimiert, dem hier voreingestellten Verfahren. Und eine Spalte mit vielen Wiederholungen wird als Wörterbuch codiert: Die unterschiedlichen Werte stehen einmal in einer Wörterbuchseite, und die Spalte selbst wird zu einer Liste kleiner Verweise darauf.

Das Wörterbuch entsteht nur dort, wo es sich lohnt: Der Schreiber prüft die ersten tausend Werte und legt ein Wörterbuch an, wenn höchstens die Hälfte davon verschieden ist — genau die Spalten, die man erwarten würde: Land, Status, Produktcode, Währung. Eine Spalte mit lauter unterschiedlichem Fließtext bleibt ohne Wörterbuch, weil es dort größer wäre als die Daten selbst. Das erklärt, warum die Ersparnis bei einem operativen Export gewaltig und bei einer Tabelle mit lauter unterschiedlichen Sätzen bescheiden ausfällt.

Die Zeilen werden in Gruppen geschrieben statt als ein einziger Block — zwischen tausend und hunderttausend Zeilen je Gruppe, mit Seiten von einem Megabyte darin. Jeder Spaltenblock innerhalb einer Gruppe trägt Statistiken, und genau diese Statistiken machen aus einem Scan ein Überspringen.

Das ist der Effekt, den Leute meinen, wenn sie sagen, Parquet sei schneller. Eine Abfrage, die nach einem Datumsbereich filtert, liest den Footer, sieht, dass eine Zeilengruppe komplett außerhalb dieses Bereichs liegt, und liest diese Gruppe gar nicht erst. Eine Abfrage, die zwei von vierzig Spalten nennt, liest nur die Bytes dieser zwei Spalten. Beides ist bei einem CSV unter keinen Umständen möglich, weil eine CSV-Datei von vorn gelesen werden muss, um überhaupt herauszufinden, wo etwas steht.

Der Typ wird aus den Werten abgeleitet, denn die Quelle deklariert nichts. Jede Spalte wird vollständig gelesen: lauter Wahrheitswerte wird BOOLEAN, lauter ganze Zahlen im 32-Bit-Bereich wird INT32, Zahlen, die nicht alle ganzzahlig oder nicht alle klein genug sind, werden DOUBLE, alles andere wird Text. Leerwerte zählen dabei nicht mit, sodass eine numerische Spalte mit Lücken numerisch bleibt.

Ein einzelner abweichender Wert macht die gesamte Spalte zu Text, und das ist Absicht, keine Einschränkung. Den Typ aus der ersten Zeile abzuleiten, würde eine mit Zahlen beginnende Spalte als Integer schreiben und jeden späteren nicht-numerischen Wert stillschweigend zu einem Leerwert machen — eine Datei, die klaglos lädt und dabei unbemerkt Zeilen gelöscht hat. Eine Textspalte ist sichtbar, in einem Ausdruck umwandelbar und verliert nie etwas. Kommt eine Spalte unerwartet als Text heraus, zeigt eine Abfrage auf die Werte, die sich nicht umwandeln lassen, meist eine Handvoll Zeilen mit einer Fußnote, einer Summe oder dem Wort „keine Angabe" darin — jeweils ein wahrer Befund über den Export.

Die Umwandlung liest das CSV mit Typinferenz, sodass 007 zur Zahl 7 wird, noch bevor der Schreiber einen Spaltentyp wählt, und die entstehende INT32-Spalte gibt einen Wert getreu wieder, der schon vorher falsch war. Parquet bekommt dafür regelmäßig die Schuld und trägt sie zu Unrecht — der Verlust passiert beim Einlesen des Texts, demselben Schritt, den jeder andere CSV-Leser ebenfalls macht.

Gefährdet sind die Spalten, bei denen Rechnen keinen Sinn ergibt: Postleitzahlen, Artikelnummern, Telefonnummern, Kontoreferenzen, alles mit führenden Nullen. Steht der Export unter eigener Kontrolle, sind diese Spalten in Anführungszeichen oder mit einem Präfix zu exportieren, dann kommen sie unversehrt als Text an. Steht er nicht unter eigener Kontrolle, lohnt sich ein Blick auf die Spalte im Ergebnis, bevor die Datei irgendwo dauerhaft liegt — der ganze Sinn des Wechsels zu Parquet ist ja, dass die Datei nicht mehr neu abgeleitet werden muss.

Bei einer Tabelle mit fünfzigtausend Zeilen und sechs Spalten — einer Kennung, einem Produktcode, einer Stadt, einer Menge, einem Preis und einem Kennzeichen — maß das Parquet-Ergebnis 301 KB. Dieselben Daten als tabulatorgetrennter Text waren etwa 1,8 MB, und ein CSV davon unterscheidet sich nur dadurch, welches Zeichen die Felder trennt und ob Anführungszeichen um Werte mit Kommas stehen.

Das ist ungefähr eine Sechstel-Reduktion, ein vernünftiger Richtwert für operative Daten mit wiederkehrenden Codes und Kategorien. Eine Datei voller einmaligem Fließtext schneidet deutlich schlechter ab, weil weder das Wörterbuch noch die Binärcodierung dort viel zu tun haben. Beide Zahlen gehen von einem unkomprimierten CSV aus; ein gezipptes CSV schließt einen Teil der Lücke, um den Preis, bis zur vollständigen Entpackung nicht abfragbar zu sein.

Es braucht keine Einrichtung. DuckDB liest die Datei direkt in einer FROM-Klausel, pandas liest sie mit einem einzigen Aufruf, Spark behandelt sie als natives Tabellenformat. Die Datei beginnt und endet mit den vier Byte PAR1, woran jedes dieser Werkzeuge sie erkennt, bevor es den Footer liest.

Nach dem Laden lohnt sich zuerst ein Blick auf das erkannte Schema statt auf die ersten zehn Zeilen. Eine erwartet numerische Spalte, die als Text ankommt, sagt etwas Wahres über das CSV, und das jetzt zu wissen ist deutlich günstiger als erst, nachdem die Datei mit drei anderen verknüpft und in ein Data Warehouse kopiert wurde.

Die gesamte Tabelle liegt im Arbeitsspeicher: Das CSV wird in Zeilen eingelesen, die Zeilen werden in Spalten umgesetzt, und die Spalten werden geschrieben. Einige Dutzend Megabyte wandeln sich ohne Umstände um, bei einigen hundert beginnt ein Tab zu ächzen — eine reale Grenze und keine Preisstufe, denn es gibt weder einen Upload noch etwas zu bezahlen.

Für einen wirklich großen Export ist DuckDB das richtige Werkzeug: Es liest das CSV von der Platte und schreibt Parquet in einer Anweisung, ohne die Datei je vollständig im Speicher zu halten. Das offen zu sagen, ist nützlicher, als eine Zwei-Gigabyte-Umwandlung zu zwei Dritteln scheitern zu lassen. Diese Seite ist für die Datei gedacht, die passt — und das sind die meisten.

Beide Hälften laufen auf dieser Seite: CSV-Parser und Parquet-Schreiber sind Programmbibliotheken, die bei Bedarf nachgeladen werden, und keine Anfrage trägt die Datei irgendwohin. Für einen Rohexport aus einer Fachanwendung mit Kunden- oder Personaldaten ist das keine Nebensächlichkeit, sondern genau der Schritt, den ein Datenschutzkonzept verhindern soll — der Export vor jeder Maskierung ist selten der, den man einer fremden Website anvertrauen möchte.

Es entfällt außerdem eine ganze Stufe der Abwägung: kein Kontingent, keine Zeilenobergrenze, kein Konto. Die einzige verbleibende Frage ist, ob die Datei in den Speicher passt, und die lässt sich beantworten, indem man kurz hinschaut.

Parquet ist eine schlechte Ablage für alles, was ein Mensch lesen soll. Es ist binär, nicht editierbar, und ein Kollege ohne das passende Werkzeug kann es überhaupt nicht öffnen — die interne Registrierung führt die Unterstützung dafür ausdrücklich als lückenhaft. Geht die Datei an einen Menschen statt an eine Maschine, gehört CSV oder eine Tabellenkalkulation dorthin.

Es ist auch das falsche Ziel für eine Ladung, die einmal passiert und danach verworfen wird: Der Schreibaufwand zahlt sich nicht aus, wenn die Datei nie wieder abgefragt wird, und ein Bulk-Loader, der Text direkt liest, ist Ende zu Ende schneller. Parquet lohnt sich, wenn dieselben Daten wiederholt gelesen, gefiltert und verknüpft werden — genau dann zahlen sich typisierte Spalten und übersprungene Zeilengruppen aus.