XLSX in Parquet umwandeln

In einem deutschen Mittelstandsunternehmen liegt die monatliche Auswertung häufig als Excel-Datei vor — ein Export aus dem ERP-System, eine vom Controlling gepflegte Liste, ein Bericht mit fünfzigtausend Zeilen. Sobald jemand diese Zahlen mit DuckDB, pandas oder einem Data-Lake-Ziel abfragen will, ist die Mappe selbst das Hindernis: Jede Frage lädt die ganze Datei, weil eine Tabelle zeilenweise gespeichert ist.

Diese Umwandlung transponiert das erste Blatt in spaltenweise gespeicherte, typisierte Daten. Das Ergebnis ist ein Bruchteil der Größe der Mappe, und es lässt sich abfragen, ohne die gesamte Datei einzulesen — genau die Eigenschaft, die eine Auswertung von Kundendaten oder Umsatzzahlen erst praktikabel macht, ohne die Datei irgendwohin hochzuladen.

Jedes andere Ziel, das eine Mappe hat, speichert einen Datensatz nach dem anderen. Parquet speichert ein Feld nach dem anderen: erst alle fünfzigtausend Bestelldaten zusammen, dann alle Städte, dann alle Beträge. Das ist keine Formatvorliebe, sondern der gesamte Grund, warum das Format existiert.

Die Folge zeigt sich bei der ersten Abfrage. Eine Frage, die zwei von zweihundert Feldern liest, berührt nur die Bytes dieser beiden Spalten statt jeder Zeile, und eine Spalte mit sich wiederholenden Werten komprimiert deutlich stärker als dieselben Werte über Zeilen verstreut. Die Datei trägt ihr Schema zudem in einem Fußbereich mit sich — eine Abfrage-Engine kennt Spaltennamen und -typen, ohne eine einzige Zeile zu lesen, was weder eine getrennte Datei noch eine Exceltabelle leisten kann.

Der Typ wird aus den Werten abgeleitet, nicht deklariert, denn eine Tabelle trägt kein Schema. Jede Spalte wird vollständig geprüft: Sind alle nicht leeren Werte Wahrheitswerte, wird sie BOOLEAN; sind es lauter ganze Zahlen innerhalb des 32-Bit-Bereichs, wird sie INT32; sind es Zahlen, aber nicht durchgehend ganzzahlig oder zu groß, wird sie DOUBLE; alles andere wird zur Zeichenkette.

Leerstellen zählen dabei nicht mit — eine Zahlenspalte mit Lücken bleibt numerisch, die Lücken werden als Null-Werte geschrieben, genau das, was eine Abfrage-Engine erwartet. Geprüft wird die gesamte Spalte, nicht eine Stichprobe, was eine ganze Klasse von Überraschungen ausschließt: Ein Import, der auf den ersten tausend Zeilen funktioniert hat, aber bei Zeile vierzigtausend an einer Ausnahme scheitert, ist ein bekanntes Muster bei Werkzeugen, die nur stichprobenartig prüfen.

Eine Postleitzahlenspalte, die mit fünftausend numerischen Einträgen beginnt und dann eine Zeile mit „SW1A 1AA" oder einem deutschen Länderkennzeichen enthält, wird zur Textspalte, und die numerischen Einträge werden mit ihr zu Zeichenketten. Dasselbe gilt für eine Mengenspalte mit „n/a" oder eine ID-Spalte, in die jemand eine Notiz getippt hat.

Die naheliegende Alternative — den Typ aus der ersten Zeile ableiten und alles Abweichende zu Null machen — liefert eine Datei, die klaglos lädt und dabei unbemerkt Werte gelöscht hat. Das fällt erst auf, wenn eine Summe zu niedrig ausfällt. Eine Textspalte ist sichtbar, mit einem Ausdruck castbar und verliert nie still eine Zeile. Kommt eine erwartet numerische Spalte als Text an, verrät eine Abfrage auf die nicht castbaren Werte meist eine Fußnote, eine Summenzeile oder ein Einheitenzeichen — jedes davon eine echte Tatsache über die Tabelle.

Parquet kennt einen 64-Bit-Ganzzahltyp, hier wird er nicht verwendet. Die Werte kommen aus der Mappe als JavaScript-Zahlen, die 53 Bit an ganzzahliger Genauigkeit halten — alles, was schon in der Pipeline steckt, hat diese Grenze also bereits durchlaufen, bevor der Schreiber es sieht.

Einen solchen Wert als INT64 zu schreiben würde eine Exaktheit versprechen, die die Zahl nicht mehr hat, und der Fehler wäre unsichtbar: Eine um eins verschobene Bestellnummer sieht wie eine Bestellnummer aus. DOUBLE ist die ehrliche Angabe dessen, was tatsächlich bekannt ist. Reichen die eigenen Kennungen über neun Billiarden hinaus, sollten sie vor der Umwandlung in der Tabelle als Text gespeichert werden — dann kommen sie unverändert als Textspalte an.

An einer Tabelle mit fünfzigtausend Zeilen und sechs Spalten kam die Parquet-Datei auf 301 KB. Dieselben Daten waren als .xlsx rund 4,3 MB groß und als tabgetrennter Text etwa 1,8 MB.

Der Abstand ist mehr als reine Kompression. Wiederkehrende Werte in einer Spalte werden einmal gespeichert und referenziert, weshalb Stadt- und Produktcode-Spalten fast nichts kosten, während eine Spalte mit lauter unterschiedlichem Freitext den Abstand deutlich verkleinern würde. Der Effekt verstärkt sich bei der Abfrage: Wer zwei von sechs Spalten liest, zahlt nur für diese zwei — gegenüber einer Tabelle, bei der jede Frage die ganze Mappe verlangt, ist das genau der Unterschied, für den das Format gebaut wurde.

Was eine Tabelle in einer Datumszelle speichert, ist eine Zahl mit einem Anzeigeformat, und die Umwandlung liest hier die zugrundeliegende Zahl statt eines aufbereiteten Zeitstempels. Ein naheliegender Test vorab lohnt sich also mehr als eine Annahme: eine Mappe mit einer bekannten Datumsspalte umwandeln und in der Parquet-Datei nachsehen, ob dort die im Tabellenkalkulationsprogramm übliche Tageszahl steht oder etwas anderes.

So oder so kennt die Ausgabe keine Zeitstempel-Semantik, eine Abfrage-Engine behandelt die Spalte zunächst als das, was sie typisiert wurde — eine Ganzzahl oder eine Zahl mit Nachkommastellen. Den Kalender darauf anzuwenden ist ein Ausdruck bei der Abfrage, sobald klar ist, welches Epochendatum die Zahl tatsächlich meint, und das dort zu erledigen ist besser, als die Mappe vorher zu Text umzuformatieren, was ein Rechenproblem in ein Parsing-Problem verwandelt.

Nichts Besonderes ist nötig. DuckDB liest die Datei direkt in einer FROM-Klausel, pandas mit einem einzigen Aufruf, und Spark und darauf aufbauende Engines behandeln sie als natives Tabellenformat. Die Datei beginnt und endet mit den vier Bytes PAR1, woran jede der drei sie erkennt, bevor der Fußbereich gelesen wird.

Als erstes lohnt sich ein Blick auf die abgeleiteten Typen, nicht auf die ersten zehn Zeilen. Eine erwartet numerische Spalte, die als Text ankommt, sagt etwas Wahres über die Tabelle, und das früh zu erfahren ist deutlich billiger, als es nach einem Join mit drei anderen Tabellen zu bemerken. Blindes Casten auf dem Weg in eine Tabelle sollte man vermeiden — genau das würde die Werte still zu Null machen, die der Schreiber bewusst nicht typisiert hat.

Die Umwandlung liest das erste Blatt der Mappe. Parquet trägt eine Tabelle mit einem Schema, eine Mappe mit mehreren Blättern lässt sich also nicht in eine einzige Datei quetschen, ohne eine Zusammenführung zu erfinden, die niemand verlangt hat — das erste Blatt zu nehmen, ist die einzige Wahl, die genau das vermeidet.

Zählen mehrere Blätter, jedes einzeln umwandeln und die Abfrage-Engine wieder zusammensetzen lassen — dafür sind diese Engines gebaut: mehrere Dateien, gemeinsam gelesen, beim Laden gefiltert. Das hält außerdem die Schemata ehrlich, denn drei ähnlich aussehende Blätter unterscheiden sich in der Praxis oft um eine Spalte oder einen Typ, und diese Unterschiede gehören in eine Abfrage entschieden, nicht stillschweigend von einem Konverter verwischt.

Beide Schritte laufen im eigenen Browser: der Tabellen-Leser und der Parquet-Schreiber sind Bibliotheken, die diese Seite bei Bedarf nachlädt, und keine Anfrage trägt die Mappe irgendwohin. Bei einem Export von Kunden- oder Finanzdaten ist genau das oft der entscheidende Punkt — eine Datenschutzrichtlinie verbietet meist nicht die Umwandlung, sondern das Hochladen dafür.

Die Grenze ist der Arbeitsspeicher, nicht eine Kontostufe. Das Blatt wird eingelesen, in Spalten transponiert und geschrieben, die ganze Tabelle liegt also gleichzeitig vor — zig Megabyte sind unproblematisch, bei mehreren hundert beginnt ein Browser-Tab zu ächzen. Ab dort gehört die Arbeit in ein Skript mit einem streamenden Leser, und das vorher zu wissen ist besser, als mitten in einer großen Datei zu scheitern.