Data Quality Dashboards – Erfahrungen aus unserem Projekt für mehr Durchblick in punkto Datenqualität

Daten spielen heute eine essenzielle Rolle in Unternehmen. Ein gutes und kontinuierliches Überwachen der Datenqualität (DQ) ist unabdingbar, damit die Unternehmensgeschicke nicht durch falsche, oder unvollständige Daten gefährdet werden. In bestimmten Branchen ist Dataquality und deren Messung durch klare regulatorische Anforderungen bereits länger etabliert (z.B. in Banken durch BCBS 239). In betroffenen Unternehmen ist oftmals die gesamte Datenintegration auf die Erfüllung dieser Regulatorik ausgerichtet.

In anderen Branchen fehlen meist vergleichbare Datenintegrationslösungen. Dort fehlt es an vielen Stellen noch an gängigen Vorgehensweisen für die Überwachung der Datenqualität. Beispielsweise sind uns keine Beispiele für fertige Systeme zur Überwachung der Datenqualität bekannt, welche einen Rahmen bieten, um die Datenqualität in dritten Systemen zu prüfen. Auch direkte Praxiserfahrungen für das DQ-Monitoring in den individuellen Systemkonstellationen fehlen oft, hier kann man nur auf vorhandene Erfahrungen aus der Verwendung der jeweiligen Datenhaltungssysteme und dem Überwachen von Softwaresystemen ziehen. Sicher ist aber, dass eine hochgradige Automatisierung der Überwachung der Datenqualität nur dienlich sein kann.

Genau an diesem Punkt stand unser Kunde und fragte uns, „Wie kann die Qualität von Daten kontinuierlich und automatisiert überwacht werden?“ In einem Projekt haben wir eine Lösung für diese Frage für die Daten von Gebrauchtfahrzeugen gefunden und implementiert. In diesem Artikel werden wir dieses Projekt und unsere gewonnen Erkenntnisse vorstellen. Doch zunächst möchten wir kurz darlegen, warum Datenqualität für Unternehmen sehr wichtig ist, auch wenn der Regulator es nicht in allen Branchen explizit fordert.

Warum ist die Datenqualität von Bedeutung?

Entscheidungen können besser getroffen werden, wenn Daten in guter Qualität zur Verfügung stehen. Nur so liegen die erforderlichen präzisen und verlässlichen Informationen vor, welche für fundierte Entscheidungen unerlässlich sind. (1),(2),(3)

Der Schaden aus Daten mit schlechter Qualität betrug nach Schätzungen bereits 2018 im Schnitt 15 Millionen Dollar in Firmen. Geld, dass vielerorts sinnvoller eingesetzt werden kann. Von diesem Problem sind viele Wirtschaftszweige wie Gesundheitsfürsorge, Finanzen und der öffentliche Bereich betroffen. (4)

Generell ist Datenqualität wichtig, um guten Erfolg sicherzustellen, beim:

• Steigern der Effizienz: Mit qualitativ hochwertigen Daten können Prozesse und Projekte reibungsloser und schneller umgesetzt werden, da weniger Zeit für Datenbereinigung und -validierung aufgewendet werden muss. (1),(3)
• Verbessern der Datenanalyse: Nur durch präzise und konsistente Daten können Unternehmen das volle Potenzial ihrer Datenanalyse ausschöpfen und wertvolle Erkenntnisse gewinnen. (2)
• Erhöhen der Kundenzufriedenheit: Qualitativ hochwertige Daten ermöglichen es Unternehmen, ihren Kunden besseren Service und genauere Informationen zu bieten, was die Kundenzufriedenheit steigert. (2),(5)

Von der Idee zur Umsetzung

Unser Projekt bei unserem Kunden ist im Bereich des Gebrauchtwagenhandels angesiedelt. Auch wenn der Gesetzgeber für diese Branche keine expliziten regulatorischen Vorgaben für Datenqualität vorsieht, ist die Datenqualität für unseren Kunden aus den oben genannten Gründen wichtig.

Vor dem Start unseres Projekts wurde die Qualität der Daten mittels SQL-Statements im angeschlossenen Data Warehouse ermittelt. Die technischen Daten der Fahrzeuge werden aus den Katalogsystemen des Herstellers geladen. Die Katalogsysteme enthalten die Metadaten und Beschreibungen der Bauteile, Ausstattung und Modelle. Dabei existiert eine komplexe Kette an Vorsystemen, welche die Daten schließlich über eine Suchmaschine dem betrachteten System zuführt. Allerdings werden diese Daten im Laufe der Zeit bearbeitet oder archiviert. Wir haben es also teilweise mit fehlerhaften und fehlenden Daten zu tun. Damit ist es notwendig sicherzustellen, dass die benötigten Daten zuverlässig und qualitätsgesichert zur Verfügung stehen.

Die DQ-Ergebnisse wurden in der Vergangenheit über CSV- beziehungsweise Excel-Dateien zusammengetragen. Ziel unseres Projekts ist es die Datenqualität automatisiert und kontinuierlich zu ermitteln.

Technisch gibt es folgendes Setup für das Projekt zur Ermittlung der Datenqualität. Zwei unabhängige Schemata in einem PostgreSQL DBMS sind relevant: Fahrzeugkatalogdaten (Informationen zu Baureihen, Teilen etc.) und Fahrzeugbestandsdaten (Informationen welche Fahrzeugen im Lager sind inkl. der jeweiligen Fahrzeuginformationen wie Kilometerstand, Modell etc.). Der Fahrzeugkatalog und der Fahrzeugbestand werden jeweils durch einen eigenen Service zur Verfügung gestellt und auf einem aktuellen Stand gehalten. Die Metriken des genutzten Kubernetes-Clusters und der Systeme werden bereits über Prometheus gesammelt und mittels Grafana ausgewertet. 

Abbildung 1: Stand vor der Implementierung

Ausgangssituation und Zielsetzung

Ziel ist es eine Lösung zur Überwachung der Datenqualität zu finden, die sich möglichst nahtlos in die vorhandene Umgebung einfügen lässt und die bereits vorhandenen Kenntnisse der Teams beim Kunden berücksichtigt. Die aus fachlicher Sicht notwendigen Prüfungen, lagen zu Beginn des Projekts bereits in Form von SQL-Statements vor. Im Projekt liegt daher der Fokus auf der Automatisierung der DQ-Checks und einer Vereinheitlichung der Ergebnisdarstellung.

Nach Diskussionen mit dem Kunden, gab es folgende Entscheidung: Wir entwickeln einen neuen Service zum Überwachen der Datenqualität, basierend auf dem Kubernetes-nativen Java-Framework Quarkus. Dieser DQ-Monitoringservice nimmt SQL-Statements und führt diese stündlich per Scheduler aus. Die gefundenen DQ-Probleme pro Fahrzeug werden gespeichert, um eine gute Nachvollziehbarkeit der Probleme zu gewährleisten.
Der Service arbeitet, zur besseren Isolation, auf einer eigenen DBMS-Instanz, um seine Daten zu speichern. Er benötigt also zwei Datenbankverbindungen, eine zum Prüfen der Daten (Fahrzeugkatalog und -bestand) und eine weitere zum Schreiben der DQ-Prüfergebnisse. Die Auswertung für das Monitoring wird, wie für die bereits bestehenden Dienste, in den Prometheus geschrieben. Die Ergebnisse der Auswertung werden in Grafana visualisiert.

Die nachfolgende Grafik zeigt den ersten Architekturentwurf. Nachfolgend werden wir die verschiedenen Ausbaustufen und identifizierten Fallstricke des Projekts darstellen.

Abbildung 2: Erster Architekturentwurf

Stufe 1: Aufbau eines Monitoringservices

Als erstes begann das initiale Einrichten des Systems, das Service-Skelett wurde aufgesetzt, die Datenbank für das Datenqualitätsmonitoring eingerichtet und Nutzer konfiguriert. Die Ausführung der Checks musste so isoliert werden, dass ein Abbruch auf Grund von Fehlern, nicht zu einem Abbruch der Ausführung aller weiteren Checks führt. Zunächst war die Idee einen extra Scheduler pro Statement einzurichten, allerdings war das zum Zeitpunkt der Implementierung in Quarkus nicht möglich, da Scheduler nicht programmatisch angelegt werden konnten. Da bereits initial über 30 Checks bestanden, verbot sich auch eine manuelle Konfiguration, daher werden die Checks in einem Lauf ausgeführt und durch entsprechende Fehlerbehandlung voneinander isoliert.

Fallstrick: Speichern der Ergebnisse dauert zu lange

Einige Checks identifizieren viele Fehlerfälle. Dadurch gibt es eine erhebliche Anzahl an Einzelergebnissen, welche in die Ergebnisdatenbank geschrieben werden. Das Schreiben verzögert die Ausführung der weiteren Checks schnell im zweistelligen Minutenbereich. Abhilfe schafft hier das asynchrone Speichern der Ergebnisse. Dabei sind jedoch spezielle Datenbanktreiber für Java, bzw. Quarkus notwendig. Die Standard-JDBC-Treiber sind nicht dazu in der Lage Verbindungen zur Datenbank asynchron zu bedienen. Daher müssen alternative Treiber gewählt werden und die Implementierung in der Folge auf die asynchrone Verarbeitung angepasst werden.

Stufe 2: Erweitern der Filterkriterien und änderbare SQL-Statements

Eine Anforderung an das System sind erweiterte Filterkriterien für die Fahrzeugkatalog- und -bestanddaten (z.B. Herstellungsjahr des Fahrzeugs) auf Basis derer eine zielgerichtete Auswertung der DQ-Prüfungen im Dashboard ermöglicht wird.

Zusätzlich soll es möglich sein neue SQL-Statements hinzufügen und alte zu entfernen. Um diese Anpassungen mit minimalem Aufwand zu erreichen, muss ein nahtloser und einfacher Ansatz gefunden werden, sodass unerfahrene oder fachfremde Personen Checks in Form von SQL-Statements zum Dienst hinzufügen können. Die Lösung besteht darin, dass jedes Prüfstatement in einer separaten Datei gespeichert wird. Der Dateiname bestimmt dabei den Namen der Prüfung. Zusätzlich kann man die Checks in unterschiedliche Ordner gruppieren. Der Service folgt hierbei der Prüfsumme der Dateien, sodass Änderungen erkannt werden. Dadurch sind das Hinzufügen und Aktualisieren der vorhandenen Checks lediglich eine Frage des Ersetzens einer Datei.

Fallstrick: Ermitteln, der Ergebnisse erzeugt zu viel Last.

Mit der Erweiterung der Filterkriterien, sowie den hinzugekommen, neuen Checks ergibt sich die Schwierigkeit, dass die Datenbank für das Ermitteln der betroffenen Fahrzeuge zu lange braucht. Hier verwenden wir mehrere Lösungsansätze gleichzeitig. Das eine war die Maßgabe die zu lesende Datenmenge zu verkleinern.
Hier verwenden wir zwei Unterteilungen: Einerseits das marktweise Aufteilen (bspw. nach Region) der Prüfungen, damit nicht alle Märkte gleichzeitig geprüft werden, andererseits das Einführen eines Deltamechanismus. Letzteres ist möglich, da wir die eigentlichen Prüfungsergebnisse aus den vergangenen Läufen weiter zur Verfügung hatten.

Zusätzlich optimieren wir die Datenbank, durch Einführung neuer und die Abschaltung nicht mehr benötigter Indizes.

Damit das Lesen der Daten und das Prüfen der Qualität den Livebetrieb nicht einschränken, haben wir zusätzlich noch ein Read Replica eingefügt. Das Read Replica ist eine weitere DBMS-Instanz mit einem Abbild der Produktionsdatenbank. Diese wird kontinuierlich asynchron aktualisiert, so dass durch die Aktualisierung keine Lastspitze auf der Datenbank für die Produktion entsteht. Das bringt zwar die Einschränkung mit sich, dass in dieser Datenbank nicht geschrieben werden kann, aber für Auswertung und Analysen ist dies die beste Möglichkeit Last von der Produktionsdatenbank zu nehmen. Diese Optimierung erkauft man sich durch einen geringen Zeitversatz, der durch die Synchronisation entsteht. Im Allgemeinen gelten Replicas für lastintensive Lesezugriffe auf Produktionsdaten als Best-Practice.

Abbildung 3: Finale Zielarchitektur

Stufe 3: Implementierung der Dashboards

Zunächst war die Idee, ein großes Dashboard für den kompletten Überblick über die Datenqualität zu erstellen. Hier sollten alle Informationen schnell und übersichtlich zusammengeführt werden, um einen einfachen Einstieg zu ermöglichen. Auf einer praktischen Ebene stellte sich hier das Problem ein, dass sehr viele Abfragen identische Anzeigen benötigten. Durch die Einführung von Variablen in Grafana in einem dynamischen Dashboard wurde eine Mehrfachentwicklung vermieden.

Fallstrick: Ladezeiten der Dashboards

Neben dem visuellen Überfrachten das ein großen Dashboards mit sich bringen kann, war auch die Ladezeit so hoch, dass es nicht möglich war, dieses Dashboard zuverlässig anzuzeigen. Hier stand vor allem die Last auf Prometheus im Fokus. In den Abfragen wurden viele Datenpunkte gleichzeitig abgerufen, was zu einer hohen Datenmenge und damit Last führte.

Auch hier gab es wieder mehrere Ansätze, um das Problem zu beheben. Das eine war, dass Filterkriterien nur sparsam eingesetzt werden, da jede Ausprägung eines Filterkriteriums zu einem eigenen Datenpunkt führt. Somit können bei sehr vielen Datenfiltern (z.B. nach Herstellungsjahr) sehr viele Datenpunkte entstehen. Die Kombinatorik mit den anderen Datenfilterkriterien, führt dann zu einer regelrechten Datenflut. Der Prometheus braucht sehr viele Hardwareressourcen, um solche Anfragen schnell genug beantworten zu können. Hier sollte also genau abgewogen werden, ob das hinzuzufügende Filterkriterium notwendig ist und die verfügbaren Ressourcen ausreichen, um den Mehrbedarf zu decken.

Ein anderer Punkt ist die Einschränkung der Metriken, die auf einem Dashboard dargestellt werden. Hier bietet es sich an die Daten thematisch aufzuteilen, einerseits in die Qualitätsdaten zu den Fahrzeugen, andererseits in die eigentlichen Verkaufsdaten. Damit waren deutlich weniger Metriken pro Dashboard darzustellen, was insgesamt die Anzahl der Datenpunkte deutlich reduzierte. Zusätzlich wird der standardmäßig ausgewählte Betrachtungszeitraum für die Daten deutlich verkleinert, was ebenfalls zu einer Reduktion der Datenpunkte führt, welche gleichzeitig geladen werden müssen.

Projektergebnis

Im Ergebnis werden die Zahlen zur Datenqualität auf drei Dashboards verteilt. Die Checks laufen einmal täglich und versorgen den Kunden mit aktuellen Zahlen und Daten zur aktuellen Datenqualität. Dabei werden nur geänderte Datensätze überprüft. Dargestellt werden die Datenqualität zu den Fahrzeugsbestands- und Fahrzeugkatalogdaten und der Zustand der ausgeführten Checks. Mit diesen Informationen kann unser Kunde sicherstellen, dass die Informationen auf deren Basis er Entscheidungen trifft, eine fundierte Datenbasis haben.

Zum Schluss noch einmal die wichtigsten Punkte, die wir unterwegs gelernt haben:

• Vereinheitlichte Prüfung der Daten: In diesem Fall, die gleiche Ausgestaltung der SQL-Statements, damit neue Checks keine Änderungen am restlichen System erfordern
• Schutz der Produktionsdatenbank vor Überlastung: Einführung einer Read Replica mit asynchronem Abgleich, damit keine zusätzliche Last durch die Synchronisation entsteht, während die Produktionsdatenbank unter Last steht.
• Speichern der Monitoringdaten getrennt von Produktionsdaten: Die Datenbank für das Monitoringsystem läuft auf einer eigenen Instanz. Idealerweise laufen die Monitoringsysteme ebenfalls auf nicht für die Produktion bestimmten Ressourcen.
• Ausreichend Hardwareressourcen für Monitoringsysteme: Insbesondere Prometheus benötigt bei großen Anfragen erhebliche Ressourcen
• Reduktion der Anzahl der Datenpunkte auf den Dashboards: Durch die thematische Beschränkung der Dashboards, die Verkleinerung des Betrachtungszeitraums und das maßvolle Einführen von Filterkriterien
• Monitoringsysteme überwachen: Überwachen, dass alle Checks dauerhaft laufen, damit kein falsches Sicherheitsgefühl entsteht.

Für diesen Artikel genutzte Quellen:

(1) Kobold AI: Datenqualität: Definition, Merkmale und Analyse (Guide); https://www.kobold.ai/datenqualitaet-guide/; abgerufen am 15.5.2024
(2) Roger Heckly: Die Bedeutung der Datenqualität für Analytics; https://s-peers.com/wiki/die-bedeutung-der-datenqualitaet-fuer-analytics/; abgerufen am 15.5.2024
(3) Michaela Tiedemann: Die 5 wichtigsten Maßnahmen für eine optimale Datenqualität; https://www.alexanderthamm.com/de/blog/die-5-wichtigsten-massnahmen-fuer-eine-optimale-datenqualitaet/; abgerufen am 15.5.2024
(4) Susan Moore: How To Create a Business Case For Data Quality Improvement; https://www.gartner.com/smarterwithgartner/how-to-create-a-business-case-for-data-quality-improvement; abgerufen am 15.3.2024
(5) lbarrera: Argumente für die Datenqualität: Was ist sie und warum ist sie wichtig?; https://dataladder.com/de/argumente-fuer-die-datenqualitaet-was-ist-sie-und-warum-ist-sie-wichtig/; abgerufen am 26.6.2024