Das CSV-Format hat sich für viele Anwendungen überlebt. Im ersten Teil dieser kleinen Blogserie zeige ich Vor- und vor allem Nachteile von CSV für die professionelle Arbeit mit Daten auf. Aber kein Niederschlag ohne Regenbogen: Ich erläutere auch kurz eine aus meiner Sicht valable Alternative, um im 21. Jahrhundert tabellarische Daten zu speichern und weiterzugeben.

Der Standard für tabellarische Daten

In welchem Format werden tabellarische Daten gespeichert? – Die genaue Antwort hängt davon ab, in welchem Kreis die Frage gestellt worden ist, aber: In schätzungsweise 9 von 10 Fällen wird die Antwort entweder «XLSX» oder «CSV» heissen. Im Umfeld der – möglichst Software-agnostischen – Bereitstellung von Daten, etwa im Kontext von Open Data oder Open Government Data, hat CSV in den letzten 10 Jahren einen enormen Popularitätsschub erfahren. Es gilt vor allem in OGD-Kreisen als der offene Standard (im Sinn von «nicht-proprietär») für die Bereitstellung von Daten.

Pros …

CSV ist ein sehr einfaches Format. Es kann durch sehr viele Programme gelesen und geschrieben werden. Klassische Data Engineering- und Data Science-Sprachen wie Python und R haben breiten Support für das Format. Als nicht-binäres Format ist es – begrenzt – human-readable (für beliebte Text-Editoren und IDEs existieren gar Plugins, welche die Lesbarkeit von CSV-Dateien verbessern).

… und Cons von CSV 🤕

CSV ist aber auch ein nerviges Format: Die Internet Engineering Task Force (IETF) hat 2005 im Request for Comments bzw. RFC 4180 zwar Vorschläge zur Standardisierung des Formats gemacht. Diese werden aber zum Teil nur sehr inkonsistent angewendet. Einige Stolpersteine oder Begrenzungen des Formats sind:

• Verwendung unterschiedlicher Trennzeichen («separators»): Neben dem für «CSV» namengebenden Komma sind unter anderem gebräuchlich: Strichpunkt, «|», Tabulator oder Leerzeichen. Der Strichpunkt ist besonders im deutschsprachigen Raum gebräuchlich, weil das Komma hier häufig als Dezimalzeichen verwendet wird. Eine deutschsprachige Excel-Installation kann mit Kommas strukturierte CSV-Dateien nicht per Doppelklick öffnen*, solche mit Strichpunkten aber schon… Umgekehrt kann englischsprachige Software (z.B. ein englischsprachiges Excel oder ArcGIS) ein mit Strichpunkten strukturiertes CSV nicht ohne weiteres korrekt verwenden. Kleine Umwege oder Workarounds sind also angesagt.
• Verwendung von Anführungszeichen als «delimiter»: Manchmal werden doppelte Anführungszeichen verwendet, um in CSV-Dateien spezielle Feldinhalte zu ermöglichen, zum Beispiel solche, die das Trennzeichen (separator), andere Spezialzeichen oder Zeilenumbrüche enthalten. Nicht alle Programme, die CSV-Dateien schreiben oder lesen, verwenden dieselben Konventionen bzw. können mit den CSV-Dateien aus anderen Programmen umgehen.
• Verwendung unterschiedlicher Zeilenenden: Manche Programme verwenden bzw. «verstehen» Zeilenenden im Windows- bzw. DOS-Stil (CR+LF = Carriage Return und Line Feed), andere solche im Unix- bzw. Mac OS-Stil (LF = nur Line Feed). Je nach verwendeter Software können vom einen System geschriebene CSV-Dateien daher im anderen System entweder den gesamten Dateiinhalt auf einer Zeile zeigen oder immer eine Leerzeile einfügen zwischen «Daten»-Zeilen.
• Verwendung beliebiger Character Encodings: Das CSV-Format schreibt kein Character Encoding vor. UTF-8 ist gebräuchlich, zum Teil aber auch ASCII oder – insbesondere im deutschsprachigen Raum und unter Windows – Windows-1252. Wenn man Character Encodings nicht korrekt handhabt (das CSV-Format unterstützt die Nutzenden dabei leider nicht), können insbesondere Umlaute («ä», «ö», «ü») und andere Buchstaben mit diakritischen Zeichen («à», «é», «ñ») in seltsame Spezialzeichen umgewandelt werden.
• Keine Komprimierung: CSV-Dateien sind zwar nicht so «verbose» oder aufgebläht wie zum Beispiel XML- oder JSON-Dateien, sie sind aber auch nicht ausserordentlich speichereffizient, da per se unkomprimiert.

* Ein Stockphoto, das ich ironischerweise häufiger in Vorträgen zu Daten-Themen sehe und mich immer etwas schmerzt, zeigt, was passiert, wenn man ein CSV mit Kommas in einem deutschsprachigen Excel per Doppelklick öffnet.

Verbesserungsbemühungen 🚑

Das CSV-Format hat im Lauf der Zeit einige Verbesserungsversuche erfahren: Beispielsweise kann man in Umgebungen, die die Microsoft JET Engine unterstützen, CSV-Dateien mittels einer schema.ini-Datei annotieren. Eine schema.ini-Datei kann generell den Inhalt von Textdateien spezifizieren. Im Kontext von CSV-Dateien kann man damit unter anderem das verwendete Trennzeichen und den Datentyp von Attributen bzw. Spalten definieren. Ich habe schema.ini schon in einem Python- und ArcGIS-gestützten Workflow genutzt, um mehr Kontrolle über die Verarbeitung von CSV-Dateien zu haben oder sie für ArcGIS überhaupt lesbar zu machen.

Einen ähnlichen Ansatz für die Verbesserung des CSV-Formats verfolgt die Frictionless Data-Initiative mit dem Tabular Data Package. Dieses besteht aus einer CSV-Datei und einer JSON-Datei. Letztere enthält eine standardisierte Beschreibung von Inhalt und Struktur der CSV-Datei. Die Initiative hat auch den Standard «CSV Dialect» spezifiziert. CSV Dialect ist ein JSON-Objekt, das Eigenschaften von CSV-Dateien dokumentiert (hier ist ein Beispiel). Programme, welche CSV-Dateien erzeugen, können CSV Dialect nutzen, um die verwendeten Konventionen festzuhalten und so downstream-Nutzenden die erfolgreiche Verarbeitung der CSV-Dateien zu vereinfachen.

Im Einzelfall können diese Verbesserungen nützlich sein. Aber ihr Support erscheint mir je nach betrachtetem Ansatz entweder nur im Microsoft-Umfeld gegeben oder in der Praxis äusserst schmal zu sein. Mir ist in der Schweiz kein Datenanbieter bekannt, der seine CSV-Daten bei der Publikation gesondert maschinenlesbar annotiert.

Was nun?

Bessere Alternativen zum Speichern tabellarischer Daten gibt es unterdessen einige. Auf eine bestimmte möchte ich im folgenden eingehen. Was tut man, wenn einem der Linoleum-Boden nicht mehr gefällt? — Genau:

Bei Parquet handelt es sich in unserem Zusammenhang um ein in Java quelloffen implementiertes Datenformat aus dem Umfeld der Big Data-Technologie Hadoop. Initial wurde es von Twitter und Cloudera entwickelt. Der erste Release von Parquet war vor gut 10 Jahren. Seit 2015 ist das Format unter der Schirmherrschaft der Apache Software Foundation (ASF).

Citius, altius, fortius

Parquet ist im Gegensatz zu CSV, das seine Inhalte streng zeilenweise abspeichert, ein spaltenorientiertes (column-oriented) Format. Durch die Spaltenorientierung können die Daten in Parquet-Dateien – optimiert für den Datentyp der jeweiligen Spalte – gut und effizient codiert und komprimiert werden. Abfragen von einzelnen Spalten sind performanter, da unter anderem nicht der gesamte Record (zum Beispiel die ganze Zeile in einer CSV-Datei) gelesen und verarbeitet werden muss. Auch sonst hat Parquet noch einige Asse im Ärmel, um Abfragen besonders schnell zu machen.

Parquet hat es natürlich noch nicht wie CSV bereits in typische Office-Software geschafft. Wird es womöglich auch nie. Zumindest bei proprietärer Office-Software bin ich diesbezüglich nicht optimistisch. Es wird unterdessen aber in der Daten-Community relativ breit unterstützt: Viele Apache-Produkte (z.B. Apache Spark, Apache Hive u.a.) funktionieren – erwartungsgemäss – gut mit Parquet. Aber auch typische Data Engineering- und Data Science-Sprachen und -Frameworks wie Python, R, das tidyverse, pandas oder polars können gut mit dem Format umgehen und es sowohl lesen als auch schreiben.

Das Zielpublikum von Parquet sind also (zumindest noch) nicht Herr und Frau Schweizer, Jacqueline Toutlemonde und Otto Normalverbraucher, sondern Fachleute, die Daten publizieren oder mit Daten arbeiten und sie für Analysen, Modellierungen und Visualisierungen nutzen.

Im nächsten Teil lasse ich den zahlreichen Behauptungen hier Daten folgen:
Death to CSV ☠️ – Part II

---

Haben Sie Data Engineering- oder Data Science-Herausforderungen, bei denen ein effizientes Datenformat nützlich sein könnte? Oder wo das Problem etwas komplizierter ist und Sie eventuell froh um einen Austausch wären? Kontaktieren Sie mich unverbindlich.