Parquet in NDJSON umwandeln

Ein Betroffener stellt nach Art. 15 DSGVO ein Auskunftsersuchen, und die zuständigen Datensätze liegen nicht in einer Datenbank mit fertiger Export-Funktion, sondern in einer Parquet-Ablage eines Data Lake — genau dort, wo Rohdaten aus Vorsystemen zusammenlaufen, bevor sie in ein Fachsystem geladen werden. Die Frist läuft, und was gebraucht wird, ist keine Analyse, sondern die einzelnen Zeilen zu einer bestimmten Kennung als etwas, das ein Auskunftssystem oder ein Sachbearbeiter tatsächlich lesen kann.

NDJSON ist dafür die naheliegende Zwischenstation, weil praktisch jedes Fallbearbeitungssystem, jede Programmierschnittstelle und jede Skriptsprache JSON versteht und keines davon einen Parquet-Footer parsen kann. Die Umwandlung läuft im Browser, was bei personenbezogenen Daten aus einem Auskunftsersuchen kein Nebenaspekt ist, sondern häufig die Voraussetzung dafür, dass die Datei überhaupt auf diesem Weg bearbeitet werden darf.

Eine Parquet-Datei erklärt im Footer, welchen Typ jede Spalte hat. Wird daraus CSV oder eine tabulatorgetrennte Datei, ist diese Erklärung weg: Jeder Wert wird zu Zeichen, und wer die Datei als Nächstes liest, muss den Typ erneut erraten — meist anders, und ohne das Schema, das direkt daneben lag.

JSON bringt eigene Typen mit. Eine Zahl bleibt eine Zahl, ein Wahrheitswert bleibt einer, ein Leerwert bleibt null, sodass der Datensatz am Ziel dasselbe über sich selbst aussagt wie die Parquet-Spalte. Für eine Schnittstelle mit eigenem Schema ist das kein kleiner Unterschied — es nimmt eine ganze Fehlerklasse aus dem Weg, bei der ein Feld abgelehnt wird, weil es plötzlich eine Zeichenkette statt einer Zahl ist.

Das ist die Einschränkung, die man kennen sollte, bevor man mit dem Ergebnis weiterarbeitet. Parquet hält Listen, Strukturen und Zuordnungen nativ, und diese Spalten werden in die JSON-Zeile als Zeichenkette geschrieben, die selbst JSON enthält, statt als echte verschachtelte Struktur. Eine Listen-Spalte kommt als `"[\"a\",\"b\"]"` an — ein korrekter und vollständiger Wert, aber eine Verschachtelungsebene entfernt von der Form, die ein Konsument erwartet, der ein Array sieht.

Ein Durchlauf mit jq behebt das: `jq -c '.notizen |= fromjson'` macht aus so einem Feld ein echtes Array. Das explizit zu tun, ist auch eine Gelegenheit zu entscheiden, wie das Feld eigentlich heißen und ob es am Ziel überhaupt verschachtelt sein soll — viele Ziele nehmen die Zeichenkette klaglos an. Wichtig ist, es zu wissen, denn ein Feld, das im Code-Review verschachtelt aussieht und zur Laufzeit eine Zeichenkette ist, fällt in einem Auskunftsschreiben ungünstiger auf als in einem internen Report.

Eine Zeitstempel-Spalte wird als ISO-8601-Zeichenkette geschrieben, etwa `2024-03-11T09:30:00.000Z`. Das ist die einzige ehrliche Antwort, denn JSON hat keinen eingebauten Datumstyp, und die ISO-Form lässt sich von jeder Sprache, jeder Datenbank und jedem Schema-Validator ohne zusätzliche Formatangabe einlesen.

Die Alternative wäre eine Epochenzahl, und in einem Auskunftsschreiben, das am Ende ein Mensch liest oder ein Sachbearbeiter prüft, wäre das schlechter: Ein Feld mit dem Wert 1710149400000 sagt für sich genommen nichts, ohne die Einheit zu kennen, und die beiden gängigen Einheiten unterscheiden sich um den Faktor tausend. ISO-Text ist auf den ersten Blick lesbar und sortiert als reiner Text trotzdem chronologisch richtig.

Parquet kennt 64-Bit-Ganzzahlen, und JSON-Zahlen sind in der Praxis durch das begrenzt, was die Parser auf beiden Seiten exakt darstellen können — bei den meisten sind das 53 Bit. Ein Wert jenseits dieser Grenze lässt sich nicht als Zahl übertragen, ohne ihn zu verändern.

Die Umwandlung schreibt solche Werte deshalb als Zeichenkette. Ein Wert innerhalb des sicheren Bereichs bleibt Zahl, einer außerhalb wird zu einer Zeichenkette mit jeder Ziffer unverändert, und eine Spalte, die über die Grenze hinausreicht, enthält beides. Eine Vertragsnummer oder Kundenkennung, die auf eine Ziffer genau gerundet wurde, sieht aus wie eine Kundennummer, passt aber zu nichts mehr — genau das soll diese Regel verhindern.

Die Datei besteht aus einem vollständigen JSON-Objekt je Zeile und sonst nichts — keine öffnende Klammer, kein Komma zwischen den Datensätzen, keine schließende Klammer. Ein Parser, der ein JSON-Array erwartet, scheitert an der zweiten Zeile, und das ist die Arbeitsweise des Formats, kein Fehler darin.

Was diese Form ermöglicht, ist Verarbeitung Zeile für Zeile, unabhängig von der Dateigröße: `head -n 1000` liefert eine Stichprobe, die selbst gültige Eingabe für alles Weitere ist, `split -l` erzeugt handhabbare Häppchen, und ein abgebrochener Import kann an einer Zeilennummer wieder aufsetzen statt von vorn zu beginnen — bei einer laufenden Frist ein handfester Vorteil.

Ein Null-Wert in einer Parquet-Spalte wird als `null` geschrieben, was einen Unterschied bewahrt, den keine getrennte Textdatei transportieren kann: null und eine leere Zeichenkette sind unterschiedliche Werte, und sie kommen unterschiedlich an.

Das ist relevant, sobald das Ziel ein eigenes Schema hat. Ein als Text deklariertes Feld lehnt null ab, wenn es nicht ausdrücklich als optional gekennzeichnet ist, und ein Validator meldet das am betroffenen Datensatz statt erst später bei der Auswertung — eine bessere Art zu scheitern als bei einer getrennten Datei, wo null und leer schon vor jeder Prüfung dasselbe geworden sind.

Das Ergebnis ist deutlich größer als die Parquet-Datei, aus der es stammt. Jeder Datensatz wiederholt jeden Feldnamen, jede Zeichenkette steht in Anführungszeichen, und von der Wörterbuchcodierung und der Kompression, die die Parquet-Datei klein gehalten haben, überlebt nichts in reinem Text.

Das ist in Ordnung, weil diese Datei ein Transportartefakt ist. Sie existiert, um einmal von einem Konsumenten gelesen und danach gelöscht zu werden; die dauerhafte Kopie bleibt Parquet. Wird die NDJSON-Datei stattdessen aufbewahrt, ist das ein Zeichen dafür, dass an anderer Stelle etwas falsch geplant wurde — eine komprimierte Spaltendatei ist in jeder Hinsicht besser für die dauerhafte Ablage geeignet als eine Textdatei mit wiederholten Feldnamen in jeder Zeile.

Der Parquet-Leser ist eine Programmbibliothek, die diese Seite bei Bedarf nachlädt, und die JSON-Zeilen werden dort geschrieben — keine Anfrage trägt die Datei irgendwohin. Für einen Auszug, der personenbezogene Daten vor jeder Maskierung enthält, ist das oft die Voraussetzung dafür, dass ein Werkzeug im Netz überhaupt infrage kommt.

Jede Zeile wird vollständig im Arbeitsspeicher aufgebaut, bevor etwas geschrieben wird, sodass der Speicher die Obergrenze setzt. Parquet ist komprimiert, eine mäßig große Datei kann sich also deutlich ausdehnen, und die Grenze kommt früher als die Dateigröße auf der Platte vermuten lässt. Für eine sehr große Tabelle liest DuckDB die Parquet-Datei und schreibt NDJSON in einer einzigen Anweisung, ohne beides je vollständig zu halten, und lässt sich dabei auf genau die Spalten beschränken, die für das Auskunftsschreiben tatsächlich gebraucht werden.

Die NDJSON-Datei enthält genau die Zeilen, die im Parquet-Auszug standen — nicht mehr und nicht weniger. Ob dieser Auszug bereits alle Tabellen und Systeme umfasst, in denen zu einer Person Daten vorliegen, ist eine Frage der Datenlandkarte, die vor der Extraktion beantwortet werden muss, nicht danach. Diese Umwandlung prüft weder Vollständigkeit noch führt sie einen Abgleich über mehrere Kennungen einer Person hinweg durch.

Ebenso wenig maskiert sie irgendetwas: Enthält der Parquet-Auszug Felder, die vor der Herausgabe geschwärzt werden müssen, ist das ein Schritt, der vor oder nach dieser Umwandlung erledigt werden muss, in jq oder im Quellsystem — die Umwandlung selbst ändert an den Werten nichts außer ihrer Darstellung.

Kann das Zielsystem Parquet lesen, sollte es das auch tun. Fast jedes Data-Warehouse und die meisten modernen Datenbibliotheken können das, und die Originaldatei zu übergeben hält das Schema intakt, hält die Übertragung klein und nimmt einen Schritt aus dem Prozess, an dem Typen driften könnten.

Umgewandelt wird, wenn das Ziel wirklich nur JSON versteht — das trifft auf die meisten Fallbearbeitungssysteme, Warteschlangen und Programmierschnittstellen zu. Das ist ein echter und dauerhafter Unterschied zwischen zwei Welten: operative Systeme tauschen Datensätze aus, analytische Systeme tauschen Spalten aus, und diese Umwandlung ist die Brücke dazwischen, kein Ersatz für eine der beiden Seiten.