Schlechte Datenqualität – Symptom oder die Ursache von Problemen?

Letzte Tage hatte ich ein Gespräch mit den BI-Verantwortlichen einer mittelständischen Versicherung. Grund des Gesprächs war, dass der Kunde sowohl einen Data Lake für seine Analytics Projekte als auch ein Datawarehouse für diverse Reports nutzt und insbesondere bei Kundeninformationen/-daten es immer wieder zu abweichenden Ergebnissen aus den beiden Systemen kommt. 

Ein bei dem Gespräch anwesender IT Consultants hat daraufhin sofort das Konzept eines Data Lake Houses ins Spiel gebracht. Was ist nun ein Data Lake House? Stark Vereinfacht gesagt ist ein Data Lake House ein Data Lake, dem mittels eines Metadatenlayers bzw. damit verbundenen Schemata die notwendigen Strukturen für die Nutzung als Data Warehouse aufgesetzt werden, es wird aber nur ein Daten Repository, der Data Lake, vorgehalten – im Prinzip versucht man die Vorteile beider Technologien in einer zu verbinden. Eine gutes und kurzes Erklärvideo findet sich im Link oben.

Aber löst ein Data Lake House nun prinzipiell das Problem des Kunden?  Betrachten wir dazu mögliche Szenarien für die Ursache des eigentlichen Problems:

Eine mögliche Fehlerursache könnte darin bestehen, dass durch einen technischen Implementierungsfehler die Daten beim Ladeprozess in den beiden jeweiligen Systemen unterschiedlich behandelt werden (ETL-Prozess). Es könnte dadurch geschehen, das zwar die gleichen Daten geladen werden, diese aber aufgrund eines fehlenden oder unvollständigen Metadatenmanagements unterschiedlich beim Laden oder auch der Auswertung in den verschiedenen Fachbereichen interpretiert werde. Ein triviales, aber leider in der Praxis immer wieder vorkommendes Beispiel ist die nicht eindeutige Verwendung von Netto und Bruttopreisen, inkorrekter Anwendung von Voucher-Daten etc.

Hier hilft dann auch kein Data Lakehouse, weil das dann zu implementierende Schema für die Reports bzw. die Analyse womöglich den gleichen Fehlinterpretationen unterliegt, wie heute bei der Nutzung des Datawarehouses. Hier hilft nur ein entsprechender Datenkatalog bzw. Metdatenmanagement und die Schulung der MitarbeiterInnen in der Nutzung derselben.

Eine andere Möglichkeit für die Ursache des Problems könnte sein, dass die beiden Systeme die Daten aus unterschiedlichen Systemen laden, deren Daten nicht synchron oder eben auch unterschiedlich manipuliert / interpretiert werden, also eher ein Problem in der Data Lineage in den vorgelagerten Systemen. Aber welche Daten sind denn nun die Richtigen? Vereinfacht man den Import mit einem Data Lake House auf ein System, hat man eine 50% Chance, die richtigen Daten zu laden. Aber eben auch eine 50% Chance, die fehlerhaften Daten zu laden. Und dann würden die fehlerhaften Daten in beiden Systemen genutzt. Auch hier benötigt es einen Datenkatalog respektive Metadatenmanagement und auch hier die nötige Governance, dass diese Tools dann auch entsprechend genutzt werden, um eine klar nachzuvollziehende Data Lineage zu erhalten und damit mögliche Abweichungen erkennen zu können.

Das Beispiel zeigt, dass Technologie und insbesondere IT Lösungen keine organisatorischen Probleme bzw. Prozesse alleine lösen können. Hat der Kunde die Data Lineage im Griff und ein Metadatenmanagement, um die Daten korrekt zu interpretieren, werden die Ergebnisse auch in zwei unterschiedlichen Systemen dieselben sein. Und umgekehrt, werden die DQ Probleme weiter bestehen, auch wenn die Daten nur aus einem System kommen, aber unterschiedlich interpretiert werden. 

Sicher bietet ein Data Lake House viele Vorteile und Nutzen für so manchen Kunden und hilft auch gewisse Fehler zu vermeiden, aber nur mit der entsprechenden Data Governance, einer dokumentierten und gelebten Datenarchitektur können solche Lösungen ohne großen Aufwand betrieben und mögliche Fehler in der Nutzung von Anfang verhindert werden.