A Little Big Data
Schon toll dieses Big Data: Die Welt wird nicht nur digital, sie wird smart! Aber was ist, wenn man gar keine hoch komplexen oder immensen Daten hat, sondern einfach nur Alltagsdaten, aus denen man ordentliche Erkenntnisse ziehen will und für die man keine Cloud-Ressourcen anmieten muss – hat Big Data dann eine Relevanz? Wie auch Sie in Datenhaltung und -Transfer von diesen Technologien und Erfahrungen profitieren können, ist das Thema dieses Artikels. Dieser erste Teil richtet sich dabei an alle, die mit Daten aus fremder Quelle hantieren, auch ohne besondere technische Vorkenntnisse. Es werden dabei erst die Ursachen häufiger Datenprobleme beleuchtet und dann im Zusammenhang mit den Eigenschaften gängiger Dateiformate wie xlsx (Excel) oder CSV Tipps zur Vermeidung gegeben. Der folgende Teil 2, der am 16.2.2017 veröffentlicht wird, richtet sich an Nutzer mit etwas fortgeschrittenen Kenntnissen, die ihre Datenhaltung zumindest teilweise automatisiert haben oder überlegen, diesen Schritt zu gehen. Ich werde darin einige nützliche Werkzeuge hauptsächlich im Umfeld der Skriptsprache Python anhand konkreter Beispiele vorstellen.
Blödes Ding!
Nun, was sind denn die größten Ärgernisse bei dieser Arbeit? – Die Daten wollen irgendwie nicht so wie ich will: KPIs, Übersichtstabellen, Plausibilitätsprüfungen – eigentlich eine Kleinigkeit, und meine Formeln stimmen, aber dann summiert das blöde Ding die Spalte nicht, oder findet den Lookup-Wert nicht, obwohl doch da steht, wonach gesucht werden soll! Ganz besonders fällt dies auf, wenn die Daten vorher durch viele Hände gegangen sind – woraus man (in den meisten Fällen richtigerweise) schließen kann, dass der Mensch wohl nicht ganz unbeteiligt daran ist.
Hier bei PAYMILL hantieren wir mit Daten aus verschiedensten Quellen: Webseiten oder Schnittstellen öffentlicher Einrichtungen, technischen Dienstleistern und Akzeptanz-Banken; oder wir arbeiten über Ländergrenzen hinweg mit anderen Teilen der CYBERservices Europe Gruppe zusammen. Einiges davon fällt wohl unter die sehr vagen Kriterien von Big Data. Aber im Alltag zeigt sich, dass auch im Kleinen sehr viel Potenzial für Optimierung steckt! Daten aus zweiter oder dritter Hand kranken oft an Lücken, Fehlern oder – besonders im internationalen Datenaustausch – an uneinheitlicher Formatierung. Mit jeder weiteren Station summiert sich der Zeitaufwand (und die Frustration) der Mitarbeiter, um diese Probleme zu umschiffen – und zu spät erkannte Fehler ziehen weiteren Ärger nach sich.
Was auf kleiner Skala ein Ärgernis ist, ist bei Big Data allerdings ein Show-Stopper. Aus purer Notwendigkeit haben sich daher über die Jahre des Daten-Booms neue Standards etabliert und Technologien zur Bereinigung und Problemvermeidung entwickelt.
Die Wurzeln des Übels
Die meisten Probleme entstehen darin, dass der Mensch keine brauchbare digitale Schnittstelle hat – wir sind einfach extrem ineffizient, wenn wir beispielsweise Morse-Codes blinzeln. Die Art und Weise, wie wir Information aufnehmen (d.h. dargestellt haben wollen), passt oft nicht zu dem, wie sie für digitale Verarbeitung benötigt wird. Daraus entstehen Fehler und Ungenauigkeiten.
Zahlenformate
Wir benutzen im Alltag 10 Ziffern, der Computer nur zwei. Bei ganzen Zahlen funktioniert das noch recht gut, aber bei Kommazahlen fängt der Ärger an: Sie kann in der einen Darstellung abbrechen und in der anderen nicht. Beispiel: 1,110 = 1,0001100110011…2 . Durch Tricks wird das Problem etwas entschärft, aber ab einer Länge von 8 bis 16 Ziffern (je nach Technik) ist die Grenze der genauen Darstellung erreicht und es entstehen die ersten Rundungsfehler. Wissen Sie etwa, nach welchen Regeln Ihr Programm rundet?
Oftmals werden Zahlen gar nicht für Arithmetik benutzt, sondern zur Identifikation, als fortlaufende Nummerierung. Der Computer unterscheidet streng zwischen Ganz- und Kommazahlen. Was passiert, wenn man den falschen Typ gewählt hat und auf die Präzisionsgrenze zuläuft? Die Nummerierung stoppt, da die Addition von 1 die Zahl nur unterhalb der Genauigkeit erhöht. Da der Computer für Berechnungen alle Zahlen im gleichen Typ benötigt, kann ein einziges unachtsam gesetztes Komma ausreichen (Beispiel “+ 1,0” statt “+1”), um alle Genauigkeit zu reduzieren.
TIPP: Bei Export und Import von Zahlen ist besondere Vorsicht geboten, da es verschiedene Darstellungen gibt, wie länderspezifische Trennzeichen für Dezimale, Tausender oder Exponential-Darstellung. Wenn man die Kontrolle darüber hat, sollte auf Trennzeichen für Tausender komplett verzichtet werden, da sie die Anpassung an Lokalisierungen erschweren. Zahlen werden in der Regel nur dann als Ganzzahl interpretiert, wenn sie keinen Dezimal-Trenner enthalten und auch nicht in Exponential-Darstellung stehen. Man sollte beim Import trotzdem prüfen, ob sie nicht doch als Kommazahlen interpretiert wurden.
Textformate
Dieser Datentyp – allgemein als String bezeichnet, da er eine Folge von Zeichen ist – wird in Berechnungen nicht direkt verwendet, aber er kann Felder und Spalten bezeichnen, weshalb typische Operationen des Computers die Suche und der Vergleich mit anderen Strings oder Teilen von Strings sind.
Die gängige Informationseinheit Byte kann 256 verschiedene Werte annehmen. Das klingt zunächst üppig für 26 Buchstaben in Groß- und Kleinschreibung, Satzzeichen und 10 Ziffern. Es gibt allerdings mehr. Viel mehr. Nicht nur Umlaute, die die lateinische Schrift erweitern, müssen darstellbar sein, auch zahlreiche andere Alphabete benötigen eine eindeutige Zuordnung von Zeichen zu gespeicherten Werten. Eine bestimmte Zuordnung heißt Encoding und es gibt viele davon, was bereits für unzählige graue Haare gesorgt hat. Wenn Systeme miteinander kommunizieren, die unterschiedliche Encodings nutzen, schleichen sich Fehler in die Daten ein, da oftmals das empfangende System den Wert des Zeichens kennt, nur eben in einen anderen Buchstaben übersetzt. Typischerweise erkennt man dies an verschluckten oder verfälschten Sonderzeichen – und schon hat man keine Chance mehr, sinnvoll nach Wörtern mit Umlauten zu suchen. Als das Internet noch langsam und Speicherplatz rar waren, war es sinnvoll, an den Texten ein bisschen Platz einzusparen, indem man beispielsweise ein Encoding mit den gängigen westeuropäischen Zeichen nutzte. Heute gibt es dafür nur noch wenige Gründe.
TIPP: Der Standard, den man nutzen sollte, heißt Unicode, oder UTF-8, und beinhaltet praktisch alle Zeichen aller existierenden Encodings, und wird mit der Zeit erweitert, wenn neue Zeichen benötigt werden (Beispiele: Euro oder Bitcoin).
Datumsformate
Die Art und Weise, wie absolute Zeitpunkte abgespeichert werden, variiert stark nach Programm und Anwendungsfall. Für Berechnungen wie Zeitdifferenzen ist es vorteilhaft, sie als fortlaufenden Wert zu speichern, beispielsweise als ganze Zahl, die dann als Differenz in Sekunden zu einem festgelegten Zeitpunkt interpretiert wird. Dies hat Limitierungen, ist aber per se selten problematisch, da die Konvertierung in ein lesbares Format für den Anwender unsichtbar abläuft. Probleme tauchen eher in der Gegenrichtung auf: Man gibt dem Computer einen String, den er als Datum interpretieren soll. Man lernt schon in der Schule, wie so ein Datum (evtl. mit Uhrzeit) auszusehen hat – nur eben in jedem Land anders. Was er daraus macht – falls überhaupt – hängt also auch von den Spracheinstellungen des lokalen Computers und/oder Programms ab.
TIPP: Wenn man einen Zeitpunkt als String darstellt, empfiehlt sich daher der internationale Standard: ISO 8601. Beispiel: “1999-12-24T23:59:00”. In ihm ist die Darstellung auch für Kalenderwochen und Zeitzonen eindeutig definiert. Die Reihenfolge JJJJ-MM-TT mag ungewohnt sein, sie hat aber einen klaren Vorteil: Die alphabetische Sortierung der Strings entspricht auch der chronologischen.
Dateiformate in der Praxis
Excel
Streng genommen ist Excel kein Dateiformat, aber Sie wissen, was ich meine: Man nutzt das Programm – oder eine beliebige andere Tabellen-Kalkulationssoftware – und tauscht die Dateien mit anderen aus. Neben .xls und .xlsx gibt es auch noch .ods und viele weitere eigentliche Dateiformate; deren Funktionalität ändert sich dadurch aber nur marginal, weshalb Excel hier stellvertretend für die ganze Familie behandelt wird. Auch wenn Sie mit Excel alleine noch nicht zum Data Engineer werden, es hat eine Reihe von guten Seiten zu bieten, die Datenaustausch zum Erfolg machen können. Die Wichtigste ist wohl, dass es Datenformate unterscheidet und auch entsprechend speichert. Wenn die Felder richtig definiert sind, werden Zahlen, Strings und Datumsangaben unabhängig von lokaler Einstellung richtig angezeigt und erhalten ihren internen Wert auch, wenn beispielsweise die Anzeige von Nachkommastellen begrenzt wird.
Probleme können sich hierbei aber in mehrerlei Hinsicht ergeben:
- Der Datentyp ist nicht direkt ersichtlich: Wenn sie eine Datei von Dritten erhalten, kann es sein, dass sich unter eine Spalte mit Zahlenwerten einige Strings mit Zahleninhalt mischen, da sich der Datentyp nicht Spaltenweise erzwingen lässt. TIPP: Zahlenfelder sind per default rechtsbündig. Linksbündige Zahlen sollten Sie immer unter die Lupe nehmen. Noch schwieriger wird es in Datumsspalten mit eingestreuten Strings, was bei Tabellen aus dritter Hand oft vorkommt. Hier hilft oft nur das Erzwingen eines neuen Darstellungsformats auf die ganze Spalte, um falsche Zellen zu identifizieren.
- Implizite Konversionen: Excel wählt das Datenformat typischerweise selbständig bei der Eingabe der Daten, wobei man bei Kommazahlen und Zeitstempeln die Abhängigkeit von lokalen Einstellungen beachten muss. Wenn man sich vertippt, kann es leicht geschehen, dass ein falscher Datentyp gewählt wird, der in der Zelle auch nach Korrektur erhalten bleibt. Auch dies bleibt am häufigsten bei Zeitstempeln unentdeckt. Genauso kann es sein, dass aufgrund der Bearbeitungshistorie eines Dokuments vermeintlich freie Felder bereits einen Datentyp definiert haben. TIPP: Es kann also Ärger ersparen, den gewünschten Typ einer Spalte explizit zu setzen.
- Absolute Koordinaten: Spalten haben in Excel oft einen Titel definiert, werden aber in den meisten Fällen per absoluten Koordinaten adressiert. Wenn Tabellen in teilautomatisierte Prozesse eingebunden werden, kann das zu Problemen führen, wenn diese händisch erzeugt wurden oder erweitert werden und dadurch ihre Ordnung ändern. TIPP: Es empfiehlt sich, entweder Lookup-Funktionen mit Spaltennamen zu verwenden, oder in Skripten die Kopfzeile einzulesen und mit den Erwartungen zu vergleichen.
CSV
CSV-Dateien bieten eine solide Grundlage für den Austausch tabellarischer Daten – sofern die Formatierung der Datentypen klar definiert ist. Ein Vorteil ist, dass die Datei menschenlesbar ist, man also per Texteditor den Inhalt begutachten und verändern kann, oder mit den richtigen Werkzeugen auch eine Vielzahl von Dateien nach bestimmten Einträgen durchforsten. Bei hoher Anzahl von Spalten ist das in der Praxis aber kaum noch übersichtlich. Ein weiterer Vorteil ist, dass das Regelwerk sehr übersichtlich ist und das automatisierte Einlesen damit sehr einfach sein kann.
Fallstricke bei der Benutzung sind:
- Lokale Formate: Es wird weder Codierung noch Dezimaltrenner vorgegeben. Bei Import oder Export beispielsweise mit Excel können Zahlen, Sonderzeichen und Zeitstempel bei abweichenden Ländereinstellungen stark verfälscht werden.
- Steuerungszeichen: Zeichen, die die Struktur der Datei bestimmen, sind zwar innerhalb einer Datei einheitlich, aber nicht global definiert. Dies sollte extern geschehen. Auch muss klar sein, wie beispielsweise ein Strichpunkt innerhalb eines Strings dargestellt wird, wenn er gleichzeitig Trennungszeichen (genannt Delimiter) der Felder ist. Stichworte: Quotechar, Escape
- Keine Datentypen: Die Konvertierung der Felder in bestimmte Datentypen unterliegt der Kontrolle des importierenden Programms. Zusätzlich zur Kopfzeile empfiehlt sich daher die externe Dokumentation der Spalteninhalte.
JSON
Dieses Datenformat ist noch nicht so bekannt wie die obigen beiden, aber hat sich bereits fest etabliert, besonders im Bereich dynamischer Webinhalte. Es kommt aus der JavaScript-Welt, wird aber aufgrund vieler positiver Eigenschaften weit darüber hinaus eingesetzt: Es ist sehr gut menschenlesbar, unterscheidet Unicode-Strings, Ganz- und Fließkommazahlen, wahr/falsch-Werte und null, das leere Felder repräsentiert. Dazu kann jedes Feld ein Container und dieser verschachtelt sein. JSON kennt dabei arrays, also eine Menge von Werten in festgelegter Reihenfolge ([“Hund”, “Katze”, “Maus”’]), und Objekte, die ungeordnet aus String-Wert-Paaren bestehen ({“Hersteller”: “VW”, “Kilometerstand”: 12345.8, “Unfall”: []}). JSON bildet also nicht automatisch eine Tabelle ab, wie CSV, sondern verschachtelte Dokumente, deren Inhalte gezielt über deren Namen in den Objekten abgerufen werden.
In der Praxis bedeutet das, dass man erst klar die Form definieren muss, bevor man tabellarische Informationen per JSON transferiert, da es weit mehr als eine Möglichkeit gibt, die Reihen und Spalten darzustellen und auch wieder zu interpretieren. Es bedeutet aber auch, dass man die Datei einfach um weitere String-Wert-Paare erweitern kann, um beliebige zusätzliche Informationen zu speichern, ohne die Funktionalität der bestehenden Information zu verändern.
XML
XML wurde in seinen Anfangstagen als Nachfolger von HTML gehandelt, hat sich aber hauptsächlich im Datenaustausch etabliert. Es besitzt ähnliche Eigenschaften wie JSON, aber deutlich mehr Möglichkeiten, da es nicht nur ein Datenformat, sondern gleich eine Auszeichnungssprache ist. Es kann Datenbanken sehr gut abbilden und wird zu diesem Zweck auch oft eingesetzt.
Allerdings gehen die erweiterten Möglichkeiten gegenüber JSON zu Lasten der einfachen Handhabung und der (trotzdem noch vorhandenen) Lesbarkeit für Menschen. In Fällen, die dieser Artikel adressieren will, ist XML meist Overkill.
Dieses Format hat viele sinnvolle Einsatzgebiete. Datentransfer gehört nicht dazu.
Fazit
CSV- und Excel-Dateien sind durchaus brauchbare Formate für den Datentransfer, die in ihrer Einfachheit aber einige Schwächen aufweisen, die man kennen und berücksichtigen sollte, um damit effizient zu arbeiten. Falls man beabsichtigt, die Verarbeitung der Daten zu automatisieren, ist CSV die robustere Wahl. Wenn man sich schon in diesen Bereich begibt, lohnt es sich oft auch einen Blick auf JSON zu werfen, das auch hierarchische Informationen abbilden kann und Datentypen eindeutig zuweist.
In Teil 2 stellen wir Ihnen Techniken zum konkreten Umgang mit Daten vor: Lesen Sie hier weiter!
