Datenqualität in der Praxis

von DI (FH) Paul Heinzlreiter

Eines der zentralen Ziele des Data Engineering ist die Aufbereitung von Datensätzen entsprechend den Anforderungen der Anwender oder der nachfolgenden Prozessschritte. Der Einsatz der Daten kann sich hierbei vom Modelltraining im Bereich des Machine Learning bis zum verbessserten firmeninternen Reporting basierend auf einer intergrierten Datenbank erstrecken.

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
• Falsche Datentypen
• Fehlende Daten
• Fehlende Metainformation
• Verletzung des semantischen Gültigkeitsbereichs
• Falsche Reihenfolge
• Formatänderungen bei laufend gelieferten Daten

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

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.

Die RISC Software GmbH stellt mit ihrer über mehr als zehn Jahren aufgebauten Expertise im Bereich des Data Engineering einen verlässlichen Consulting- und Umsetzungspartner dar, unabhängig vom Anwendungsbereich.

Autor

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

Dieser Artikel wurde unter https://www.risc-software.at/datenqualitaet-in-der-praxis/ veröffentlicht.