Zu oft gefragt #1: Warum nicht mit Rohdaten arbeiten?

Warum kann ich nicht einfach mit Rohdaten arbeiten?

Eines vorab: Wir lieben es in unserem Job die Probleme unserer Kunden zu lösen, aber manche Fragen, mit denen wir tagaus, tagein konfrontiert werden, hängen uns mittlerweile zu den Ohren raus. Damit wir nicht fünfmal am Tag die gleichen Antworten geben müssen, beantworten wir diese Fragen jetzt einfach in einer praktischen Blog-Serie, auf die wir künftig verweisen können.

Mike Kamysz, Data Engineer bei The Data Institute, und Bo Lemmers, Analytics Engineer bei Xebia, machen den Anfang: "Warum kann ich nicht einfach mit Rohdaten arbeiten?" Oh, wie schön, dass manche noch so unverdorben sind. Klar, ihr seid voller Tatendrang, neugierig, und ihr wollt eure Antworten jetzt. Aber sich ohne Plan auf Rohdaten zu stürzen, das ist in etwa so, wie die Nadel im Heuhaufen zu finden. Mit verbundenen Augen. In einem Schneesturm. Lasst uns also darüber sprechen, weshalb es eine so schlechte Idee ist, und wieso wir viel Zeit damit verbringen, schillernde, strukturierte Datenmodelle zu bauen, die uns vor dem Chaos bewahren.

Der Anreiz mit Rohdaten zu arbeiten: Wo die Leute richtig liegen

Bevor wir uns mit dem großen "No no" der Abfrage von Rohdaten beschäftigen, lasst uns verstehen, weshalb diese Frage gestellt wird. Es wirkt wie eine gute Idee - ihr sitzt auf einer Goldmine von Daten. Wieso solltet ihr nicht direkt darauf zugreifen, in ihrer wahren, unveränderten Form? Hier ist die Überlegung hinter dieser Anfrage:

1. Granularität: ‍

Rohdaten sind die detaillierteste Version eurer Datensets, die jede Transaktion, Interaktion und jedes Event in ihrere reinsten Form enthalten. Wenn ihr eine vollständige, ungefilterte Sicht auf eure Daten braucht - seien es transaktionale Daten, Nutzer-Clicks oder Sensor Logs - dann wirken Rohdaten wie die ultimative Quelle.

2. Flexibilität:

Es gibt kein Schema, das euch einschränkt. Wenn ihr Abfragen auf Rohdaten schreibt, ist es, als hättet ihr eine leere Leinwand zur Verfügung. Ihr könnt Metriken, Dimensionen und Transaktionen aus dem Stegreif erstellen. Keine vordefinierten Logiken oder Geschäftsregeln stehen euch im Weg - es gibt nur euch, euren SQL-Editor, und die Rohdaten.

3. Time to Insight:

Wenn einem eine Frage unter den Nägeln brennt, kann es sich wie eine Ewigkeit anfühlen darauf zu warten, dass das Data-Team eine neue Spalte oder Tabelle zur Datenbank hinzufügt. Warum also den Mittelsmann nicht überspringen? Die Arbeit mit Rohdaten kann den Eindruck eines direkten Weges zum Erkenntnisgewinn erwecken.

Die versteckten Nachteile der Arbeit mit Rohdaten

Kommen wir nun zum Punkt, weshalb Abfragen auf Rohdaten nicht das Gelbe vom Ei sind. Denn hinter dem Vorhang verursacht sie jede Menge Probleme - Probleme, mit denen eure freundlichen Analytics und Data Engineers (Hi, das sind wir!) sich herumschlagen müssen:

Datenqualität: Müll rein, Müll raus

Rohdaten sind unverarbeitet. Und das ist genau das, wonach es sich anhört. Roh, ungekocht, voll von Rauschen, Fehlern und fehlenden Werten. Bevor irgendeine seriöse Analyse vorgenommen werden kann, müssen Rohdaten üblicherweise einen Data Cleaning- und Transformationsprozess durchlaufen. Hier ist die Realität:

1. Inkonsistente Formate

Datumsfelder in unterschiedlichen Formaten, unterschiedliche Einheiten (z.B. Kilogramm vs. Pfund), und inkonsistente Kategorisierungen (z.B. "DE" vs. "Deutschland", oder "DE" vs. "de") sind nur einige wenige Formatierungsprobleme, die sich in Rohdaten tummeln. Jedes Mal, wenn ihr mit Rohdaten arbeitet, riskiert ihr eine fehlerhafte Interpretation oder Aggregierung eurer Ergebnisse.

2. Duplikate oder fehlende Datensätze

Rohdaten leiden häufig unter duplizierten Einträgen oder fehlenden Werten. Ohne einen vernünftigen Prozess, um die Daten zu säubern und zu validieren, werdet ihr den Großteil eurer Zeit damit verbringen, diese Herausforderungen manuell zu lösen, was zu lückenhaften oder schlicht falschen Analysen führt.

Wenn unterschiedliche Teams direkt mit Rohdaten arbeiten, werden diese Inkonsistenzen oft unterschiedlich gehandhabt, was sich folglich in unterschiedlichen Ergebnissen widerspiegelt. Ein Team behandelt fehlende Werte als Null, ein anderes Team ignoriert diese Datensätze vollständig, ein drittes Team verwendet den letzten bekannten Datensatz - und schon hat man ein unterschiedliches Verständnis derselben Datengrundlage geschaffen.

Performance und Kosten: Die versteckte Last

Obwohl das Abfragen von Rohdaten flinker erscheint, sind die versteckten Kosten sowohl auf Performance- als auch auf Kostenseite signifikant, vor allem in Cloud-basierten Umgebungen wie Snowflake, BigQuery usw. Die folgenden Gründe machen die unbedachte Arbeit mit Rohdaten zu einem Performance- und Kosten-Albtraum:

1. Große, nicht optimierte Tabellen‍

Rohdaten sind in aller Regel umfangreich. Werden unverarbeitete Daten abgefragt, scannt die Datenbank häufig Milliarden von Zeilen und Spalten, obwohl vieles davon für die eigentliche Analyse irrelevant ist.

2. Hohe Kosten für die Cloud‍

In Cloud Data Warehouses ist jede Abfrage mit Kosten verbunden. Da Rohdaten nicht auf Effizienz getrimmt sind, verbraucht jede Abfrage mehr Rechenleistung als notwendig. Rohdaten aus dem Stegreif zu aggregieren ist ein ressourcenintensiver Prozess, der Kosten über die Zeit in die Höhe treibt.

3. Wiederholte Transformationen

‍Da Rohdaten über keinerlei vordefinierte Logiken oder Berechnungen verfügen, erfordert jede Abfrage eine Wiederholung komplexer Transformationen wie Joins, Filterungen und Aggregierungen. Das macht Abfragen nicht nur langsamer und teurer, es verschwendet auch wertvolle Rechenzeit damit, dieselben Dinge wieder und wieder zu tun.

Das Rad neu erfinden: Vermehrte Anstrengung, inkonsistente Ergebnisse

Wenn mehrere Teams oder Personen mit Rohdaten arbeiten, erfindet im Grunde jede Partei das Rad neu. Das führt zu erhöhten Aufwänden und inkonsistenten Implementierungen von Geschäftslogiken im Unternehmen. Ohne ein zentrales Datenmodell ist jedes Team gezwungen, eigene Transformationen, Metriken und Berechnungen zu erstellen, was eine Reihe von Problemen mit sich bringt:

1. Mehraufwand‍

Jedes Team erstellt am Ende eigene Transformationen, um Rohdaten zu säubern und zu aggregieren. Beispielsweise verwendet ein Analyst Stunden darauf, Transformationen zu erstellen, um die monatlichen Umsätze zu berechnen, nur, damit ein anderes Team unabhängig davon das exakt selbe tut. Diese doppelten Aufwände verschwenden Zeit und andere Ressourcen innerhalb der Organisation.

2. Inkonsistente Geschäftslogiken‍

Ohne standardisierte Metriken, entsteht ein unterschiedliches Verständnis von KPIs in den verschiedenen Teams, beispielsweise zu "Monthly Active Users" oder "Churn Rates". Im besten Fall führt das zu Verwirrung, im schlimmsten Fall zu fehlausgerichteter Entscheidungsfindung, da unterschiedliche Reports widersprüchliche Stories zu denselben Daten erzählen.

Das Argument für ein sauber entworfenes Data Warehouse

Wenn die Abfrage von Rohdaten also so eine schlechte Idee ist, was ist die Alternative? Vorhang auf für das mit Weitsicht entwickelte Data Warehouse, beispielsweise nach einem Kimball- oder Data-Vault Ansatz. Dort werden Rohdaten in ein sauberes, strukturiertes und für Abfragen optimiertes Format gebracht. Statt dass jeder das Rad neu erfindet, bringt das Data Warehouse Ordnung ins Chaos. Aus diesen Gründen ist dieser Ansatz nicht nur hilfreich, sondern essentiell für alle, die Analytics ernsthaft angehen wollen:

Single Source of Truth

Ein zentrales Datenmodell stellt sicher, dass es eine einzige, standardisierte Version der Wahrheit gibt. Metriken, KPIs und Geschäftslogiken sind alle vordefiniert und über alle Abteilungen der Organisation hinweg konsistent. Vorbei sind die Streits darüber welche Version des monatlichen Umsatzreports nun korrekt ist, da alle mit derselben Grundlage arbeiten.

• Vordefinierte Metriken: In einem Kimball-Style Datenmodell werden wichtige Metriken (bspw. Umsatz oder Kundenzahlen) einmalig definiert und kalkuliert. So wird das Risiko von widersprüchlichen Ergebnissen eliminiert und sichergestellt, dass alle mit denselben Definitionen arbeiten.
• Zentralisierte Datenlogik: Alle komplexen Geschäftslogiken - zum Beispiel wie wir "aktive Nutzer" oder "Churn" definieren - sind im Datenmodell festgehalten. Das bedeutet, dass Analysten diese Logiken nicht mehr nachbauen müssen, wenn sie Daten abfragen.

Aggregiert und optimiert

In einem Data Warehouse werden Rohdaten in Tabellen transformiert, die für die Abfrage optimiert sind. Beispielsweise existieren in einem Kimball-Style Data Warehouse Faktentabellen, die transaktionale Daten enthalten (z.B. Verkaufstransaktionen), während Dimensionstabellen beschreibende Informationen enthalten (z.B. demographische Daten über Kunden). Dieses Design unterstützt schnelle und effiziente Abfragen.

• Vorab aggregiert: Daten können schon vorab auf das Niveau gebracht werden, in denen sie am häufigsten verwendet werden - beispielsweise Tages- oder Monatsumsätze. Das bedeutet, dass Analysten nicht jedes Mal Summen oder Durchschnitte über Milliarden von Zeilen berechnen müssen, wenn sie Abfragen schreiben.
• Für Abfragen optimiert: Dimensions- und Faktentabellen sind darauf ausgelegt, teure Table Scans in der Datenbank zu minimieren. Abfragen, die auf Rohdaten Stunden von Rechenleistung erfordern würden, können so in Sekunden abgehandelt werden.

Sicherung von Datenqualität

Ein grundlegendes Datenmodell sichert die Datenqualität, indem es wie ein Türsteher für saubere, gut strukturierte Daten fungiert. Idealerweise durchläuft es automatisierte Tests und prüft sowohl die Lesbarkeit des Codes, als auch die Zuverlässigkeit der Daten. Dieses Tests helfen dabei Fehler frühzeitig zu erkennen, sichern die Konsistenz und erhalten die Verlässlichkeit. So kann auf Daten und Datenmodell vertraut werden.

Conclusion

Obwohl es manchmal valide Anwendungsfälle für das Abfragen von Rohdaten gibt, etwa im Bereich Data Science, für Validierungszwecke oder andere Nischenfälle, führt es im Umfeld von Analytics zu mehr Problemen, als es löst. Von Problemen bei der Datenqualität und inkonsisten Metriken zu Engpässen in der Performance und unnötig hohen Kosten. Die Lösung? Ein gut strukturiertes, verwaltetes Datenmodell, welches Geschäftslogiken zentralisiert, Datenkonsistenz sichert und die Performance optimiert. Vertraut uns - sobald ihr die Vorteile eines kuratierten Datenmodells erlebt habt, wollt ihr nicht mehr mit Rohdaten arbeiten.

Steht euer Unternehmen gerade vor der Herausforderung Best Practices im Bereich Datenmodellierung zu implementieren? Wir sind hier um zu helfen. Kontaktiere uns und wir melden uns schon bald bei dir.

Photo by Cristi Ursea on Unsplash