Eines der zentralen Ziele des Datenengineerings ist die Aufbereitung von Datensätzen entsprechend den Anforderungen der Nutzer*innen oder der nachfolgenden Prozessschritte. Die Verwendung von Daten kann von der Modellschulung im Bereich des maschinellen Lernens bis hin zu verbesserten internen Unternehmensberichten auf Basis einer integrierten Datenbank reichen.
Die Sicherstellung einer ausreichenden Datenqualität ist in allen Fällen zentral. Während die verschiedenen grundlegenden Aspekte der Datenqualität und ihre Bedeutung für Unternehmen in einem früheren Artikel untersucht wurden, stellt dieser Artikel Beispiele für Datenqualitätsprobleme aus der Praxis vor und diskutiert mögliche Lösungen.
Inhalt
Ein Datenfehler stellt immer eine Abweichung von einem Zielwert dar. Das bedeutet, dass mögliche Datenfehler stark von Typ und Format der verfügbaren Daten abhängig sind. Im Wesentlichen muss hier zwischen strukturierten und unstrukturierten Daten unterschieden werden. Unstrukturierte Daten – insbesondere Textdaten – folgen in der Regel keinem Schema, was bedeutet, dass ein Datenfehler nur in seltenen Fällen maschinell erkannt werden kann.
In Textdateien ist ein typisches Beispiel der falsche Lokalisierungsstandard von Gleitkommawerten aufgrund inkonsistenter Verwendung des Dezimaltrennzeichens:
1.236.45327,564-0.2 |
In diesem Beispiel wird das falsche Dezimaltrennzeichen in der dritten Zeile verwendet, in diesem Fall das Komma, welches in deutschsprachigen Ländern üblich ist. Welches Dezimaltrennzeichen das richtige ist, wird in der Regel durch externe Zusatzinformationen oder durch Bestimmung der Mehrheit innerhalb der gegebenen Daten festgelegt.
Mögliche Datenfehler in Textdateien:
Im Gegensatz dazu basieren strukturierte Daten auf einem Schema, das das Datenformat, die Struktur der Daten sowie die Datentypen und Wertebereiche der enthaltenen Datenwerte enthält. Daten-Schemata können je nach Datenformat explizit oder implizit sein und beschreiben beispielsweise tabellarische Daten pro Spalte:
In jedem Fall ermöglicht ein Daten-Schema die Validierung des Inhalts eines Datensatzes oder die Überprüfung auf Fehler. Da es maschinell leichter überprüfbar ist, konzentriert sich dieser Artikel auf strukturierte Daten, wie sie in einem industriellen Umfeld auftreten. Aus der Sicht der Datenvalidierung können strukturierte Daten in zwei grobe Klassen unterteilt werden. Diese unterscheiden sich darin, ob das Format bereits das Daten-Schema bereitstellt:
Während XML- oder JSON-Dateien selten syntaktische Fehler enthalten, da sie in der Regel programmatisch erzeugt werden, treten Datenfehler häufiger in CSV-Dateien auf, da diese oft manuell gepflegt werden (z.B. in Microsoft Excel). Typische Ursachen für Datenformatinkonsistenzen in CSV-Dateien sind, dass es keine explizite Spezifikation des Formats gibt und Fehler beim manuellen Übertragen des Formats von vorherigen Zeilen auftreten können. Typische Beispiele sind:
Abweichungen in der Datenrepräsentation können nicht nur durch menschliche Fehler bei der manuellen Dateneingabe auftreten, sondern auch durch Prozessänderungen bei der automatisierten Datengenerierung. Insbesondere bei CSV- und JSON-Dateien ist es oft schwierig, den Typ eines Dateneintrags zu bestimmen, besonders wenn die Quelldaten nicht konsistent befüllt sind. Dieselben Fehlerkategorien können hier auftreten wie bei der manuellen Datenübertragung.
Je nach Art der strukturierten Daten können verschiedene Kategorien von Datenfehlern auftreten:
Diese Fehlerkategorie nimmt im Vergleich zu den folgenden eine Sonderrolle ein, da sie in der Regel nur in strukturierten Textdateien auftreten kann, da Binärdateien fast ausnahmslos algorithmisch erzeugt werden und somit normalerweise syntaktisch korrekt sind.
Ein Syntaxfehler tritt auf, wenn die Textdatei nicht der vorgegebenen Syntax des gewünschten Dateiformats folgt. Beispiele hierfür sind:
Dieser Fehler tritt auf, wenn ein zu überprüfendes Feld einen falschen Datentyp hat. Typische Beispiele sind:
Datenschemata erlauben es oft, Datenfelder als optional zu kennzeichnen, so dass es möglich ist, dass Datenfelder auch in strukturierten Binärdateien leer bleiben. Diese sind jedoch für die darauf aufbauende Anwendungssemantik notwendig, wie z.B. Felder, die als Fremdschlüssel zur Verknüpfung von Tabellen verwendet werden sollen. Wenn Daten aus einem strukturierten Textdatenformat eingelesen werden sollen, kommt es viel häufiger als bei Binärdaten vor, dass Daten fehlen. Ein klassisches Beispiel hierfür ist eine fehlende Spalte in einer CSV-Datei.
Ein typisches Beispiel für fehlende Metainformationen ist die Angabe einer Uhrzeit ohne Zeitzone. Die Speicherung der Ortszeit ohne Angabe der Zeitzone kann je nach Art der Speicherung sogar zu Datenverlusten führen, da es bei der Umstellung von Sommer- auf Winterzeit zu doppelten Zeitstempeln für verschiedene Zeitpunkte kommt. Ein weiteres Beispiel für fehlende Metainformationen ist die Angabe eines Datentyps, wenn dieser nicht eindeutig aus dem Datenelement abgeleitet werden kann.
Ein Beispiel hierfür ist die folgende Darstellung in einer CSV-Datei:
... ;10.3352; ... |
Ein solches Feld wird normalerweise als Fließkommawert interpretiert und gespeichert. Es gibt jedoch unterschiedliche Datentypen für einfache oder doppelte Genauigkeit. Welcher Datentyp zu wählen ist, hängt davon ab, welche Wertebereiche (z.B. Minimal- und Maximalwerte) in der Gesamtdatenmenge enthalten sind. Wenn alle Daten bereits vorhanden sind, können diese programmatisch abgeleitet werden. Werden die Daten jedoch erst nach und nach geliefert, ist es sicherer, sich für den Datentyp mit dem größeren Wertebereich zu entscheiden. Der Nachteil dabei ist natürlich der doppelte Speicherbedarf für das Datenfeld.
Diese Fehler beschreiben Werte, die außerhalb ihres Gültigkeitsbereiches liegen, obwohl sie einen gültigen Wert für ihren Datentyp haben. Ein Beispiel hierfür sind Außentemperaturen von über 100° Celsius in Mitteleuropa.
Diese Fehlerkategorie beschreibt die Speicherung von Daten in falscher Reihenfolge. Dies kann z.B. eine Zeitreihe von Sensorwerten sein, die nicht in aufsteigender Reihenfolge nach Zeitstempel sortiert gespeichert wurde. Solange der Zeitstempel für jeden Wert vorhanden ist, kann ein solcher Datensatz noch korrekt eingelesen werden, aber oft werden Zeitstempel nicht explizit gespeichert, um Speicherplatz zu sparen, wenn die Sensorwerte durch regelmäßige Stichproben ermittelt wurden. In einem solchen Fall reichen die Startzeit und der zeitliche Abstand zwischen zwei Messpunkten aus, um alle Zeitstempel zu ermitteln – wenn die Reihenfolge der Speicherung stimmt.
Ein weiteres Beispiel, bei dem die Reihenfolge der Speicherung für die Semantik entscheidend ist, ist die sequentielle Speicherung von Messdatenpunkten in einer Textdatei, die auf einem regelmäßigen Gitter angeordnet sind und deren Positionierung auf dem Gitter sich implizit aus Startposition und Schrittweite entlang der Achsen des Koordinatensystems ergibt.
In der Praxis ist dies eines der größten Probleme mit der Datenqualität. Wenn die Daten in einem einheitlichen Format geliefert werden, kann die Verarbeitung der Daten an dieses Format angepasst werden und auch gewisse wiederkehrende Schwankungen in der Datenqualität auffangen. Ändert sich jedoch das Format der gelieferten Daten abrupt, muss die Datenverarbeitung in der Regel angepasst werden. Typischerweise handelt es sich dabei um wegfallende oder hinzukommende Datenfelder, Änderungen der Datentypen oder des Datenformats. Aus Sicht der Datenqualität gibt es im Grunde keinen Unterschied zwischen Daten, die in einem Block geliefert werden und ein uneinheitliches Format haben, und Daten, die im Laufe der Zeit als Datenstrom geliefert werden und ihr Format mit der Zeit ändern. Der Unterschied für den Datenempfänger besteht jedoch darin, dass man bei bereits vorhandenen Datenfehlern den Datenimport sofort darauf abstimmen kann, während bei kontinuierlicher Datenlieferung Änderungen oft unerwartet auftreten.
Typische strukturierte Daten aus dem industriellen Umfeld sind Zeitreihen von Sensordaten. Als Beispiel kann hier die Zeitreihe von Messdaten einer Wärmekraftmaschine dienen, die in Auszügen dargestellt ist. Diese Daten wurden direkt aus dem Betrieb der Maschine über Sensoren entnommen und von einem Programm, das auf einem Raspberry Pi Minicomputer läuft, in der CSV-Datei gespeichert, was in Bezug auf die Datenqualität als durchaus repräsentativ für Industriedaten angesehen werden kann
timestamp;temperature_heater;temperature_boiler;pressure_boiler;rpm;power_dynamo;power_heating;valve_aperture;water_level2019-07-20T11:38:03;26.093750;48.555557;193.544373;0.000000;-0.001262;0.0;0.0;1902019-07-20T11:38:04;26.093750;48.555557;180.865280;0.000000;-0.001262;0.0;0.0;1902019-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;1902019-07-20T11:38:59;26.093750;47.416672;206.114639;0.000000;-0.001262;0.0;0.0;1902019-07-20T11:39:00;26.093750;48.555557;206.114639;12.000000;-0.001262;446.973846;0.0;1902019-07-20T11:39:01;26.093750;49.694443;193.489960;12.000000;-0.001262;442.720520;0.0;1902019-07-20T11:39:02;26.093750;50.833328;206.060226;0.000000;-0.001262;446.973846;0.0;1902019-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;1902019-07-20T11:46:10;35.774303;276.333313;1494.212524;0.000000;-0.006702;459.733795;0.25;1902019-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 offensichtlich:
Ein naheliegender – und guter – Ansatz zur Behebung von Datenqualitätsmängeln besteht darin, eine verbesserte Version der Daten vom Datenlieferanten anzufordern. In der Praxis ist dieser Ansatz jedoch oft nicht durchführbar. Wenn zum Beispiel in einer Produktionslinie fehlerhafte Sensordaten aufgezeichnet wurden, weil ein Sensor defekt ist, ist es oft nicht möglich oder zumindest sehr kostenintensiv, die Datenaufzeichnung zu wiederholen. Während der reale monetäre Wert der erhobenen Daten für die Projektbeteiligten zu Beginn oft nicht abschätzbar ist, lassen sich die direkt anfallenden Kosten für eine Wiederholung einer Messung – z.B. aufgrund einer Produktionsunterbrechung – sehr schnell beziffern. Darüber hinaus kann auch der Austausch eines defekten Sensors durch die oft notwendige Einschaltung von Fremdfirmen zu einer erheblichen Verzögerung der geplanten Datenanalysen führen. Ein typisches Szenario ist hier die Sammlung von ausreichenden Trainingsdaten für Machine-Learning-Modelle, die oft Monate dauern kann. Hier kann eine möglicherweise mehrwöchige Verzögerung durch den Austausch eines Sensors den gesamten Projektablauf gefährden, ohne dass der tatsächliche Nutzen eines solchen Eingriffs im Vorfeld klar ist.
Aus diesen Gründen ist die algorithmische Behandlung des Datenfehlers oft die insgesamt günstigste Lösung.
Leider gibt es keine allgemein anwendbaren 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 die Verwendung eines strukturierten Binärformats für die Quelldaten den Aufwand für die Datenvalidierung stark reduziert. Der gewünschte Typ eines Datenfeldes ist bereits bekannt, so dass die Daten nicht fehlerhaft gespeichert werden können. Der häufigste Fehler bei Binärdaten sind daher fehlende Daten, wenn sich das zugrunde liegende Schema geändert hat oder ein Datenfeld als optional angegeben wurde, obwohl es für die Anwendungslogik benötigt wird. Generell lässt sich sagen, dass Datenfehler bei strukturierten Binärdaten in der Regel auf Fehler im Datenschema oder auf eine ungeplante Änderung desselben zurückgeführt werden können.
Werden strukturierte Textdaten als Datenquelle verwendet, kommen – wie oben beschrieben – weitere Klassen von möglichen Fehlern hinzu.
Bei strukturierten Textdateien können jedoch Schemainformationen per Konvention aufgenommen werden, z. B. in die Kopfzeile der CSV-Datei, die die Namen der Spalten enthalten kann. Als Erweiterung dieser üblichen Methodik kann man die Kopfzeile um die Datentypinformationen erweitern, um sicherzustellen, 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 |
Im obigen Beispiel werden die entsprechenden Java-Datentypen angegeben, wobei es natürlich vom Zieldatenspeichersystem abhängt, welche Datentypen zur Speicherung zur Verfügung stehen. In der Regel ist es jedoch ausreichend, den Datentyp für eine Datenbank oder Programmiersprache eindeutig zu definieren, da dann die Konvertierung für andere Zielsysteme automatisch erfolgen kann.
Wie kann man im Rahmen eines automatisierten Prozesses auf Datenfehler reagieren? Wenn Daten als Teil eines ETL-Prozesses (Extrahieren – Transformieren – Laden) unter Verwendung eines bestimmten Schemas gespeichert werden sollen und ein Datensatz die Anforderungen des Datenschemas nicht erfüllt, besteht die einfachste Methode darin, diesen Datensatz zu verwerfen. Dies kann für einige Anwendungsfälle – wie z. B. große Datensätze für das Training von KI-Modellen – angemessen sein, aber im Allgemeinen besteht das Ziel darin, einen Datensatz so umzuwandeln, dass er im vorgesehenen Schema gespeichert werden kann. Die folgenden Methoden können verwendet werden, um dies automatisch zu tun:
Wenn Datenfehler nicht automatisch korrigiert werden können, ist es sinnvoll, die Rohdaten aufzubewahren und z.B. eine Meldung zu senden, damit der Fehler untersucht und der ETL-Prozess – ggf. nach manueller Korrektur – abgeschlossen werden kann. Handelt es sich nicht um einen einmaligen Fehler, wird der ETL-Prozess in der Regel im Zuge der Untersuchung und Behebung des Problems angepasst, um den Fehler in Zukunft zu beseitigen. Dies gilt insbesondere für Fehler, die auf eine Änderung des Datenquellenformats zurückzuführen sind.
Wenn die Quelldaten kontinuierlich über einen Streaming-Prozess geliefert werden, ist es besonders wichtig, die Rohdaten zunächst zu speichern, bevor sie weiterverarbeitet werden. Dies kann verhindern, dass die Daten verloren gehen, wenn die Datenverarbeitung zu einem späteren Zeitpunkt im ETL-Prozess fehlschlägt. Nachdem ein Fehler behoben oder der ETL-Prozess nach einer Formatänderung angepasst wurde, können die gespeicherten Rohdaten erneut verarbeitet werden. Meistens verbrauchen die Rohdaten mehr Speicherplatz, insbesondere wenn sie als Textdateien geliefert werden, im Vergleich zu einer späteren strukturierten und komprimierten Speicherung. Daher ist es oft ratsam, die erfolgreich verarbeiteten Rohdaten nach der Validierung zu löschen. Um Speicherplatz zu sparen, können Rohdaten natürlich auch mit Standardalgorithmen komprimiert werden, was vor allem bei Textdaten zu erheblichen Speicherplatzeinsparungen führt.
Vor Beginn eines Data-Science- oder Data-Engineering-Projekts ist es für alle Beteiligten oft schwierig, die Qualität der einzubeziehenden Daten einzuschätzen. Dies liegt oft daran, dass die Daten bereits über einen gewissen Zeitraum gesammelt, aber noch nicht operativ genutzt werden, weil sie zum Beispiel noch nicht in ausreichender Menge vorliegen.
Darüber hinaus stellt die Anhebung der Datenqualität auf ein für die Projektziele erforderliches Niveau oft einen erheblichen Teil des Projektaufwands dar, der ohne Kenntnis der Daten oder ihrer Qualität nur schwer abzuschätzen ist. Um diesem Problem zu begegnen, kann beispielsweise eine Vorprojektphase zur gemeinsamen Klärung der Ausgangssituation eingeplant oder ein agiler Ansatz gewählt werden, der ein schrittweises gemeinsames Vorgehen mit flexibler Definition von Meilensteinen ermöglicht.
Die RISC Software GmbH ist mit ihrer über zehnjährigen Expertise im Bereich Data Engineering ein zuverlässiger Beratungs- und Implementierungspartner, unabhängig vom Anwendungsbereich.
Senior Data Engineer
