Datenqualität in der Praxis

Zentral ist in allen Fällen die Gewährleistung einer ausreichenden Datenqualität. Während in einem früheren Fachbeitrag die verschiedenen grundsätzlichen Aspekte von Datenqualität sowie ihre Bedeutung für Unternehmen betrachtet wurden, werden in diesem Fachbeitrag Datenqualitätsprobleme aus der Praxis exemplarisch präsentiert sowie mögliche Lösungsansätze diskutiert.

Datenformate

Ein Datenfehler stellt immer eine Abweichung von einem Sollwert dar. Daraus ergibt sich, dass mögliche Datenfehler stark von der Art und vom Format der vorliegenden Daten abhängig sind. Im Wesentlichen gilt es hier die Unterscheidung zwischen strukturierten und unstrukturierten Daten zu treffen. Unstrukturierte Daten – vor allem Textdaten – folgen meist keinem Schema, wodurch nur in seltenen Fällen ein Datenfehler maschinell erkannt werden kann.

In Textdateien ist ein typisches Beispiel eine falsche Lokalisierung von Gleitkommawerten durch inkonsistente Verwendung des Dezimaltrenners:

1.23
6.4532
7,564
-0.2

In diesem Beispiel wird in der dritten Zeile das falsche Dezimaltrennzeichen verwendet, in diesem Fall das im deutschen Sprachraum übliche Komma. Die Bestimmung, welcher Dezimaltrenner jeweils der richtige ist, erfolgt meist durch externe Zusatzinformation oder durch die Bestimmmung der Mehrheit innerhalb der gegebenen Daten.

Unstrukturierte Textdaten

Mögliche Datenfehler in Textdateien:

• Nicht definierte oder abweichende Zeichensätze:
  Ein Zeichensatz beschreibt die Abbildung von Zeichen (a, b, ä, €, …) auf deren Binärrepräsentation im Speicher. Wenn dieser nicht korrekt definiert oder unbekannt sind, führt dies zur falschen Darstellung und Verarbeitung von Sonderzeichen wie deutschen Umlauten.
• Codierung der Zeilenumbrüche:
  Ein Zeilenumbruch wird zwischen den Betriebssystemen Microsoft Windows, Apple MacOS und GNU/Linux jeweils unterschiedlich dargestellt:
  • In Windows werden hierfür zwei Zeichen verwendet: Eine Sequenz aus Carriage Return (Ascii-Code 13) und Line Feed (Ascii-Code 10)
  • In MacOS wird nur Carriage Return verwendet.
  • In GNU/Linux wird nur Line Feed verwendet.
• Unterschiedliche Lokalisierung der Daten wie beispielsweise deutsche und englische Dezimaltrenner

Binärformate und strukturierte Textdateien

Im Gegensatz dazu liegt bei strukturierten Daten ein Schema zugrunde, welches das Datenformat, die Struktur der Daten, sowie die Datentypen und Wertebereiche der enthaltenen Datenwerte beinhaltet. Datenschemata können je nach Datenformat explizit oder implizit vorliegen und beschreiben beispielsweise für tabellarische Daten pro Spalte:

• Datentyp
• können Zellen Nullwerte enthalten
• Gültigkeitsbereich bei numerischen Werten
• Format bei Stringwerten (z. B. Datum und Zeitstempel)

Ein Datenschema ermöglicht es jedenfalls den Inhalt eines Datensatzes zu validieren beziehungsweise auf Fehler zu prüfen. Aufgrund der einfacheren maschinellen Überprüfbarkeit fokussiert sich dieser Artikel auf strukturierte Daten, wie sie beispielsweise in einem industriellen Umfeld auftreten. Strukturierte Daten lassen sich aus der Sicht der Datenvalidierung jedenfalls in zwei grobe Klassen einteilen. Diese unterscheiden sich dadurch, ob das Format das Datenschema bereits mitliefert:

• Binärdatenformate mit Schema in den mitgelieferten Metadaten:
  Beispiele hierfür sind Speicherformate kommerzieller Programme wie beispielsweise Microsoft Excel, genauso wie Bilddateien, standardisierte Binärprotokolle wie OPC UA oder Protobuf, aber auch offene BigData-Formate wie Apache Parquet. Eine weitere sehr typische Klasse an Speicherlösungen, die in diese Kategorie fallen sind relationale Datenbanken wie beispielsweise Microsoft SQL Server, PostgreSQL oder MySQL.
• Strukturierte Textdateien ohne Schemainformation im Datenformat:
  • Comma separated values (CSV)
  • XML-Dateien
  • JSON-Dateien

Fehlerursachen in strukturierten Textdaten

Während XML- oder JSON-Dateien eher selten syntaktische Fehler enthalten, da sie meist programmatisch erzeugt werden, kommen in CSV Dateien Datenfehler häufiger vor, da diese oft händisch (z. B. in Microsoft Excel) gepflegt werden. Typische Ursachen für Datenformatinkonsistenzen in CSV Dateien sind dadurch gegeben, dass keine explizite Spezifikation des Formats vorliegt und bei der händischen Übernahme des Formats aus Vorgängerzeilen durchaus Fehler passieren können. Typische Beispiele dafür sind:

• Inkonsistente Verwendung von Anführungszeichen bei Stringfeldern
• Unterschiedliche Lokalisierung (z. B. Punkt oder Komma als Dezimaltrenner)
• Leere Spalten und verschiedene Spaltenanzahlen pro Zeile
• Unterschiedliche Stringrepräsentation von Zeitstempeln, Datums- und Zeitfeldern
• Zahlenwerte unter Anführungszeichen
• Schwankende Genauigkeit bei numerischen Einträgen von Integer bis Double

Abweichungen in der Datenrepräsentation können dabei nicht nur durch menschliche Fehler bei der händischen Datenerfassung, sondern auch durch Prozessumstellungen bei der automatisierten Datengenerierung entstehen. Gerade bei CSV und JSON Dateien ist die Feststellung des Typen eines Dateneintrags oft schwierig, gerade wenn die Ausgangsdaten nicht konsistent befüllt sind. Hierbei können dieselben Fehlerkategorien wie bei der händischen Datenübernahme auftreten.

Kategorien von Datenfehlern in strukturierten Daten

Je nach Art der strukturierten Daten können verschiedene Datenfehlerkategorien auftreten:

Verletzung der Datensyntax

Diese Fehlerkategorie nimmt im Vergleich zu den folgenden eine Sonderrolle ein, da sie im Normalfall nur in strukturierten Textdateien auftreten kann, da Binärdateien fast ausnahmslos algorithmisch erzeugt werden, und somit im Normalfall syntaktisch korrekt sind.

Ein Syntaxfehler liegt vor, wenn die Textdatei nicht der vorgegebenen Syntax des geforderten Dateiformats folgt. Beispiele hierfür sind:

• fehlende schließenden Tags in XML oder HTML-Dateien
• falsche Anzahl an Spalten in einer CSV-Datei
• falsches Format eines Datums oder Zeitstempels in einer Textdatei
• fehlende, überschüssige oder falsche Anführungszeichen
• Falsche Lokalisierung wie beispielsweise Komma statt Punkt als Dezimaltrenner

Falsche Datentypen

Dieser Fehler liegt vor, falls ein zu validierendes Feld einen falschen Datentypen aufweist. Typische Beispiele sind:

• Text in einem Feld, in dem numerische Werte erwartet werden.
• Spezifikation zu weniger strikten Datentypen in Binärformaten, beispielsweise die Definition eines Textfeldes, in dem semantisch ein Gleitkommawert erwartet wird.

Fehlende Daten

Datenschemata ermöglichen es oft, Datenfelder als optional zu kennzeichnen, somit ist es auch in strukturierten Binärdateien möglich, dass Datenfelder leer bleiben. Diese sind allerdings für die darauf aufbauende Anwendungssemantik erforderlich, wie beispielsweise Felder, die als Fremdschlüssel für die Verknüpfung von Tabellen verwendet werden sollen. Wenn Daten aus einem strukturierten Textdatenformat eingelesen werden sollen, kommt es im Vergleich zu Binärdaten wesentlich häufiger vor, dass Daten fehlen. Ein klassisches Beispiel dafür ist eine fehlende Spalte in einer CSV-Datei.

Fehlende Metainformation

Ein typisches Beispiel für eine fehlende Metainformation ist die Angabe einer Uhrzeit ohne Zeitzone. Die Speicherung von Lokalzeit ohne Kennzeichnung der Zeitzone kann je nach Art der Speicherung sogar zu Datenverlusten führen, weil es bei der Umstellung von Sommer- auf Winterzeit zu duplizierten Zeitstempeln für unterschiedliche Zeitpunkte kommt. Ein weiteres Beispiel für eine fehlende Metainformation ist eine Datentypspezifikation, falls sich diese nicht eindeutig aus dem Datenelement ableiten lässt.

Ein Beispiel hierfür ist folgende Repräsentation in einer CSV-Datei:

... ;10.3352; ...

Ein solches Feld wird üblicherweise als Fließkommawert interpretiert und gespeichert. Hierbei gibt es allerdings unterschiedliche Datentypen für einfache oder doppelte Genauigkeit. Welcher Datentyp gewählt werden soll, hängt davon ab, welche Wertebereiche (zB. minimale und maximale Werte) in der Gesamtmenge der Daten enthalten sind. Wenn alle Daten bereits vohanden sind, kann dies programmatisch abgeleitet werden. Wenn allerdings die Daten erst nach und nach angeliefert werden, ist es sicherer sich für den Datentypen mit dem größeren Werteberiech zu entscheiden. Der Nachteil hierbei ist natürlich der doppelte Speicherbedarf für das Datenfeld.

Verletzung des semantischen Gültigkeitsbereichs

Diese Fehler beschreiben Werte, die außerhalb ihres Gültigkeitsbereichs liegen, obwohl sie einen für ihren Datentypen gültigen Wert aufweisen. Ein Beispiel dafür sind Außentemperaturen von über 100° Celsius in Mitteleuropa.

Falsche Reihenfolge

Diese Fehlerkategorie beschreibt die Speicherung von Daten in der falschen Reihenfolge. Dies kann beispielsweise eine Zeitreihe von Sensorwerten sein, die nicht aufsteigend nach Zeitstempel sortiert abgelegt wurde. Solange der Zeitstempel für jeden Wert verfügbar ist, lässt sich ein solcher Datensatz trotzdem korrekt einlesen, aber oft werden zur Speicherplatzersparnis Zeitstempel nicht explizit gespeichert, wenn die Sensorwerte durch eine regelmäßige Abtastung ermittelt wurden. In einem solchen Fall reicht der Startzeitpunkt und der Zeitabstand zwischen zwei Messpunkten für die Bestimmung aller Zeitstempel – wenn die Speicherreihenfolge stimmt.

Ein anderes Beispiel, in dem die Reihenfolge der Speicherung für die Semantik kritisch ist, ist die sequentielle Speicherung von Messdatenpunkten in einer Textdatei, welche auf einem regulären Gitter angeordnet sind, und deren Positionierung am Gitter sich implizit aus Startposition und Schrittweite entlang der Achsen des Koordinatensystems ergibt.

Formatänderungen bei laufend gelieferten Daten

Dies ist in der Praxis eines der größten Datenqualitätsprobleme. Wenn Daten in einem konsistenten Format geliefert werden, kann die Verarbeitung der Daten auf dieses Format angepasst werden und auch gewisse immer wieder vorkommende Schwankungen in der Datenqualität abfangen. Wenn es aber zu einer abrupten Änderung des Formats der gelieferten Daten kommt, muss die Datenverarbeitung meist angepasst werden. Typischerweise handelt es sich dabei um Datenfelder, welche wegfallen oder dazukommen, Änderungen der Datentypen oder des Datenformats. Aus der Sicht der Datenqualität gibt es grundsätzlich keine Unterscheidung zwischen Daten, die in einem Block geliefert werden und ein uneinheitliches Format aufweisen und Daten, die über die Zeit als Datenstrom geliefert werden, und das Format im Lauf der Zeit ändern. Für den Datenempfänger ist allerdings der Unterschied, dass man bei bereits vorhandenen Datenfehlern den Datenimport gleich darauf anpassen kann, während Änderungen bei kontinuierlicher Datenlieferung oft überraschend passieren.

Beispieldatensatz

Typische strukturierte Daten aus dem Industrieumfeld sind Zeitserien von Sensordaten. Als Beispiel können hierbei die Zeitserien von Messdaten einer Wärmekraftmaschine dienen, die hier auszugsweise dargestellt werden. Diese Daten wurden über Sensoren direkt aus dem Betrieb der Maschine abgenommen und durch ein auf einem Raspberry Pi Minicomputer laufendes Programm in der CSV-Datei gespeichert, welche im Bezug auf die Datenqualität als durchaus repräsentativ für Industriedaten gesehen werden kann.

timestamp;temperature_heater;temperature_boiler;pressure_boiler;rpm;power_dynamo;power_heating;valve_aperture;water_level
2019-07-20T11:38:03;26.093750;48.555557;193.544373;0.000000;-0.001262;0.0;0.0;190
2019-07-20T11:38:04;26.093750;48.555557;180.865280;0.000000;-0.001262;0.0;0.0;190
2019-07-20T11:38:05;26.093750;47.416672;193.544373;0.000000;-0.001262;0.0;0.0;190
...
2019-07-20T11:38:58;26.093750;48.555557;206.114639;0.000000;-0.001262;0.0;0.0;190
2019-07-20T11:38:59;26.093750;47.416672;206.114639;0.000000;-0.001262;0.0;0.0;190
2019-07-20T11:39:00;26.093750;48.555557;206.114639;12.000000;-0.001262;446.973846;0.0;190
2019-07-20T11:39:01;26.093750;49.694443;193.489960;12.000000;-0.001262;442.720520;0.0;190
2019-07-20T11:39:02;26.093750;50.833328;206.060226;0.000000;-0.001262;446.973846;0.0;190
2019-07-20T11:39:03;26.093750;49.694443;193.435562;0.000000;-0.001262;446.973846;0.0;190
...
2019-07-20T11:46:09;35.774303;279.750000;1494.212524;0.000000;-0.006040;459.733795;0.0;190
2019-07-20T11:46:10;35.774303;276.333313;1494.212524;0.000000;-0.006702;459.733795;0.25;190
2019-07-20T11:46:11;35.774303;279.750000;1519.461914;0.000000;-0.006702;459.733795;0.25;
2019-07-20T11:46:12;35.774303;279.750000;1519.516235;0.000000;-0.006702;459.733795;0.25;
...
In dieser CSV-Datei sind einige der oben gezeigten Datenfehler ersichtlich:

• Der Zeitstempel in der ersten Spalte beinhaltet keine Zeitzone
• In der power_dynamo Spalte werden negative Werte ausgewiesen
• In den letzten beiden gezeigten Zeilen fehlt der Wert für water_level

Methoden der Datenfehlerbehebung

Ein offensichtlicher – und guter – Lösungsansatz zur Behebung von Datenqualitätsmängeln stellt die Einforderung einer verbesserten Version der Daten vom Datenlieferanten dar. Dieser Lösungsansatz ist aber oft in der Praxis nicht umsetzbar. Wenn beispielsweise in einer Produktionsstraße fehlerhafte Sensordaten aufgenommen wurden, weil ein Sensor defekt ist, ist es oft nicht möglich, oder zumindest sehr kostenintensiv, die Datenaufnahme zu wiederholen. Während der reale monetäre Wert der gesammelten Daten für die Projektbeteiligten oft zu Beginn noch nicht abschätzbar ist, sind die direkt angefallenen Kosten für eine Wiederholung einer Messung – z. B. durch eine Produktionsunterbrechung – sehr schnell quantifizierbar. Weiters kann der Austausch eines defekten Sensors ebenfalls durch die oft notwendige Einbeziehung externer Firmen zu einer erheblichen zeitlichen Verzögerung der geplanten Datenanalysen führen. Ein typisches Szenario hier ist das Sammeln von ausreichend Trainingsdaten für Machine Learning Modelle, welches oft über Monate laufen kann. Hier kann eine Verzögerung von möglicherweise mehreren Wochen durch das Ersetzen eines Sensors den gesamten Projektzeitplan gefährden, ohne dass der reale Nutzen einer solchen Intervention im Vorhinein klar ist.

Aus diesen Gründen ist eine algorithmische Handhabung des Datenfehlers in Summe oft die günstigste Lösung.

Algorithmische Datenfehlerbehebung

Leider gibt es keine allgemein verwendbaren Methoden, um Quelldaten immer in das gewünschte Zielformat zu bringen. Generell lässt sich aber sagen, dass die umfassende Verfügbarkeit von Metainformationen oder der Einsatz eines strukturierten Binärformats für die Quelldaten den Aufwand für die Datenvalidierung sehr stark senkt. Der gewünschte Typ eines Datenfeldes ist bereits bekannt und daher können die Daten auch nicht falsch gespeichert werden. Somit sind im Fall von Binärdaten der häufigste Fehlerfall fehlende Daten, falls sich das zugrundeliegende Schema verändert hat, oder ein Datenfeld als optional spezifiziert wurde, obwohl es für die Applikationslogik benötigt wird. Generell lässt sich sagen, das Datenfehler in strukturierten Binärdaten sich meist auf Fehler im Datenschema oder auf eine ungeplante Änderung desselben zurückführen lassen.

Falls strukturierte Textdaten als Datenquellen verwendet werden, kommen – wie oben beschrieben – zusätzliche Klassen an möglichen Fehlern hinzu.

Explizite Schemainformation in Textdaten

Im Fall von strukturierten Textdateien können aber Schemainformationen per Konvention mitgegeben werden, wie beispielsweise in der Header-Zeile der CSV-Datei, welche die Namen der Spalten umfassen kann. Als Erweiterung dieser verbreiteten Methodik kann man die Headerzeile im Datentyp-Informationen erweitern, um zu gewährleisten, dass der richtige Zieldatentyp verwendet wird:

timestamp:java.sql.Timestamp;pressure_boiler:java.lang.Double;rpm:java.lang.Double;valve_aperture:java.lang.Double;water_level:java.lang.Integer

In dem obigen Beispiel werden die korrespondierenden Java-Datentypen angegeben, wobei es natürlich vom Zieldatenhaltungssysten abhängt, welche Datentypen zur Speicherung zur Verfügung stehen. Im Normalfall reicht es allerdings aus, den Datentypen für eine Datenbank oder Programmiersprache eindeutig zu definieren, weil dann die Konvertierung für andere Zielsysteme automatisiert erfolgen kann.

Automatisierte Datenfehlerbehebung

Wie kann man nun im Rahmen eines automatisierten Prozesses auf Datenfehler reagieren? Wenn Daten im Rahmen eines Extract – Transform – Load (ETL) Prozesses unter Verwendung eines bestimmten Schemas abgelegt werden sollen und ein Datensatz den Anforderungen des Datenschemas nicht genügt, ist die einfachste Methode, diesen Datensatz zu verwerfen. Dies mag für einige Anwendungsfälle – wie beispielsweise große Datensätze für KI Modelltraining – passend sein, aber im Allgemeinen ist das Ziel, einen Datensatz so zu transformieren, um ihn im geplanten Schema ablegen zu können. Folgende Methoden können eingesetzt werden, um dies automatisiert durchzuführen:

• Schemaevolution oder optionale Typfelder
  Schemaevolution beschreibt die Möglichkeit ein Schema zu versionieren, wobei auch Daten, die mit einer früheren Version des Datenschemas gespeichert wurden, mit dem neuen Schema verarbeitbar bleiben. Eine Schemaweiterentwicklung kann dabei beispielsweise Hinzufügen, Entfernen und Typumwandlung von Datenfeldern umfassen. Ein gutes Werkzeug hierfür stellen optionale Typfelder dar, die es beispielsweise ermöglichen, neue Felder hinzuzufügen und bestehende Alt-Daten trotzdem korrekt zu verarbeiten. Optionale Datenfelder stellen weiters eine gute Möglichkeit dar, leere Datenfelder korrekt abzulegen, ohne den gesamten Datensatz verwerfen zu müssen.
• Implizite Typumwandlung
  Wenn ein Quelldatentyp ohne Verlust der Genauigkeit automatisch in den Zieldatentyp konvertiert werden kann, kann dies im ETL Prozess automatisch durchgeführt werden:
  • Beim Import einer CSV-Datei in eine SQL-Tabelle müssen alle Felder aus dem String-Format eingelesen und in das Zieldatenformat überführt werden.
  • Textbasierten oder binären Datumsformate können – vor allem bei bekannter Zeitzone – automatisiert ineinander überführt werden.
  • Die Genauigkeit von Fließkommawerten oder Zeitstempeln kann während der Datenverarbeitung angepasst werden.
• Dateninterpolation bei fehlenden Werten in Zeitserien
  Dies ist eine naheliegende Operation, allerdings ist es stark von der geplanten Verwendung der Daten abhängig, ob eine solche Operation zulässig ist.

Falls Datenfehler nicht automatisch behoben werden können, bietet es sich an, die Rohdaten aufzubewahren und beispielsweise eine Notifizierung abzusetzen, damit der Fehler untersucht und der ETL-Prozess – gegebenenfalls nach manueller Korrektur – abgeschlossen werden kann. Falls es sich nicht um einen einmaligen Fehler handelt, wird im Zuge der Untersuchung und Korrektur des Problems meist der ETL-Prozess angepasst, um den Fehler in der Zukunft auszuschließen. Dies gilt im Besonderen für Fehler, die sich aus einer Umstellung des Datenquellformats ergeben.

Verhinderung von Datenverlust

Wenn die Quelldaten über ein Streaming-Verfahren laufend angeliefert werden, ist es besonders wichtig, die Rohdaten zunächst abzuspeichern, bevor sie in die Weiterverarbeitung gehen. Damit kann verhindert werden, dass die Daten verloren gehen, falls die Datenverarbeitung an einer späteren Stelle des ETL-Prozesses fehlschlägt. Nachdem ein Fehler behoben wurde oder der ETL-Prozess nach einer Formatänderung angepasst wurde, können die gespeicherten Rohdaten nach verarbeitet werden. Meist verbrauchen die Rohdaten mehr Speicherplatz, im Speziellen, wenn sie als Textdateien angeliefert werden, im Vergleich zu einer späteren strukturierten und komprimierten Speicherung. Daher ist es oft ratsam, die erfolgreich verarbeiteten Rohdaten nach einer Validierung zu löschen. Zur Speicherplatzersparnis können Rohdaten natürlich auch mit Standardalgorithmen komprimiert werden, was gerade bei Textdaten zu einer signifikanten Speicherplatzersparnis führt.

Rolle der Datenqualität in der Projektplanung

Vor Beginn eines Data Science oder Data Engineering Projektes ist es für alle Beteiligten oft schwer, die Qualität der einzubindenden Daten abzuschätzen. Dies hat oft den Grund, dass die Daten bereits über einen gewissen Zeitraum gesammelt wurden, aber im Betrieb noch nicht genutzt wurden, da sie beispielsweise noch nicht in ausreichender Menge vorliegen.

Weiters stellt das Anheben der Datenqualität auf ein für die Projektziele erforderliches Level oft einen erheblichen Anteil der Projektaufwände dar, der sich ohne Kenntnis der Daten oder ihrer Qualität schwer abschätzen lässt. Um dieses Problem zu adressieren, ist es beispielsweise möglich, eine Vorprojektphase einzuziehen, um die Ausgangssituation gemeinsam abzuklären, oder auch einen agilen Ansatz zu wählen, der ein schrittweises gemeinsames Vorgehen mit flexibler Definition der Meilensteine ermöglicht.

Autor

DI Paul Heinzlreiter ist Senior Data Engineer in der Abteilung Logistics Informatics der RISC Software GmbH.

>> Hier kommen Sie zum Beitrag der RISC Software GmbH

Kontakt

RISC Software GmbH
Softwarepark 32a
4232 Hagenberg
www.risc-software.at