In einer idealen Welt ist die Lücke zwischen Theorie und Praxis nicht groß oder zumindest nicht von großer Auswirkung auf den Lebenszyklus eines Projekts. In der realen Welt weiß man jedoch, dass das nicht stimmt, schon gar nicht bei der Arbeit mit Daten. Die Datenspeicherung (vor allem Langzeitspeicherung), kann unordentlich werden und zu unsauberen Datentabellen führen, die irgendwann verarbeitet und für eine bessere und effizientere Analyse in Ordnung gebracht werden müssen, daher die Notwendigkeit von ETL-Pipelines.
Die theoretischen Faustregeln, die in diesem Beitrag erläutert werden, können in Verbindung mit kleineren (oder größeren) Anpassungen aufgrund von Dateninkonsistenzen zu sehr sauberen und nützlichen Data Warehouses (DWH) führen, die für ein Unternehmen von großem Wert sein können. Die Dateninkonsistenzen können recht umfangreich sein, da die meisten von ihnen auf menschliche Fehler zurückzuführen sind.
So kreativ die Menschen bei den von ihnen begangenen Fehlern auch sein mögen, die Arten von Problemen, mit denen man bei der Durchführung von ETL konfrontiert wird, sind recht häufig die gleichen.
Es gibt drei Hauptschritte, die jede ETL-Pipeline durchläuft:
- Datenanalyse
eine gründliche Analyse des IST-Zustandes mit dem Ziel, zu verstehen, welche Transformationen durchgeführt werden müssen.
- Modelldefinition
die Definition der Tabellen und der Beziehungen zwischen ihnen.
- ETL-Implementierung
die eigentliche Implementierung des Datenmodells, das mit Daten aus verschiedenen Datenquellen gefüttert wird und das entworfene Datenmodell erzeugt.
Analyse der Daten
Die Bedeutung dieses Schrittes ist zweifach:
1. Geschäftsbedürfnisse
Verständnis der Informationen, die aus dem Meer der Datenquellen für das zu implementierende Data Warehouse gewonnen werden müssen, unter der Leitung der Geschäftseinheit.
Ein Data Warehouse kann auf vielen verschiedenen Datenquellen basieren, die zusammengefügt werden, oder auf nur einer Datenquelle, aber mit nur einer Teilmenge der darin enthaltenen Tabellen. Es kann zwei Szenarien für den Geschäftsbedarf geben:
- eines, bei dem sie genau wissen, welche Art von Analyse sie anschließend mit dem Data Warehouse durchführen wollen,
- und eines, bei dem sie keine konkrete/ spezifische Vorstellung haben.
So oder so besteht die Aufgabe in diesem Schritt darin, zu verstehen, welche Tabellen für den Entwurf des Datenmodells verwendet werden sollen, und genauer gesagt, welche Attribute dieser Tabellen nützlich sind.
Die goldene Regel ist, ein DWH zu entwerfen, das die Anforderungen erfüllt – sofern sie existieren – und dabei Raum für mögliche zukünftige Erweiterungen dieser Anforderungen zu lassen.
Falls keine spezifischen Anforderungen definiert sind, kann eine Lösung darin bestehen, die gängigsten Analyseszenarien für die betreffenden Daten zu identifizieren und dann die Daten für diese Szenarien vorzubereiten. Der letztere Fall ist allerdings eher selten, da ein Unternehmen kaum in etwas investiert, das keine kurz- oder mittelfristigen Einnahmen in Aussicht stellt.
Verstehen und bewerten des aktuellen Zustands der Datenquellen, die verwendet werden sollen.
Sobald die gewünschten Tabellen identifiziert sind, ist es an der Zeit, in die Tiefe zu gehen: die Analyse dieser Tabellen und ihrer Attribute. In der Praxis bedeutet dies, dass für jede Tabelle die Attribute betrachtet werden müssen. Es könnte Tabellen mit über 200 Attributen geben, aber nicht alle davon sind nützlich und nicht alle sind mit Werten gefüllt.
Die erste Prüfung, die durchgeführt werden muss, ist die Suche nach fehlenden Werten und wie viele fehlende Daten es gibt. Ein Attribut, das, sagen wir, zu 90-95% NULL ist, kann kaum für die Analyse oder eine Berichtsvisualisierung verwendet werden, also kann es verworfen werden. Bei Datensammlungen über viele Jahre kann es zu Inkonsistenzen in der Grundgesamtheit der Tabelle kommen.
Eine weitere Quelle für Inkonsistenzen in den Daten kann entstehen, wenn dieselbe Tabelle aus mehr als einer Quelle gespeist wird. Für diese Art von Problemen ist es wichtig, die Logik hinter den Inkonsistenzen zu verstehen und zu sehen, ob sie behoben werden können.
Die Lösungen hängen von der Analyse ab:
alte Daten können für das DWH verworfen werden, wenn sie nicht mehr relevant sind, oder, wenn möglich, kann eine Transformation angewendet werden, um eine Vereinheitlichung der Daten zu erreichen.
Am Ende dieses Schrittes, also nach der Datenbereinigung und den Geschäftsanforderungen, hat man einen Pool, wenn man mit einem Meer von Daten begonnen hat.
Modelldefinition
Die Modelldefinition lässt sich auf die Aufteilung der Tabellen in Dimensionen und Faktentabellen sowie die Einrichtung der Beziehungen zwischen diesen Tabellen darlegen. Der Königsweg liegt hier zwischen den Anforderungen und datengestützter Möglichkeit, diese zu erfüllen. In der Praxis kommt es hier im Lauf der Zeit zu Anpassungen, so dass es sinnvoll ist, von Anfang an Möglichkeiten der Erweiterung zu berücksichtigen.
Dimensionen
Bei den Dimensionen (vergleichbar mit einer Spalte in Excel) ist zu beachten, ob es sich um eine „Slowly Changing Dimension“ (SCD) handelt und welcher Typ von SCD am besten zu Ihren Anforderungen passt. SCD vom Typ 2 ist der häufigste.
Beispielsweise können Filialleiter unterjährig wechseln, so dass für eine wirkliche Vergleichbarkeit der Daten diese Ausprägung berücksichtigt werden muss.
Fakten
Ein wichtiger Aspekt ist, dass die für die weitere Analyse und Definition von KPIs bereits das Datenmodell auf der niedrigsten Granularitätsebene implementiert wird so dass Raum für jede Art von Aggregation bleibt.
Visualisierungstools können die Möglichkeiten der Datentransformation einschränken oder sehr erschweren, so dass das Vorantreiben dieser Berechnung auf der Ebene der DWH-Implementierung eine große Erleichterung darstellt und auch die Implementierung zukünftiger visueller Analysen vereinfacht.
Beziehungen
Die Unterscheidung der beiden Kategorien Dimensionen und Fakten ist ziemlich einfach, aber was knifflig werden kann, ist das Einrichten der Beziehungen, wobei eines der Hauptprobleme auftritt, wenn mehrere Faktentabellen vorhanden sind, was recht häufig vorkommen kann, und diese Faktentabellen miteinander sowie Dimensionen sprechen müssen. Die Grundregel ist, dass Beziehungen zwischen zwei Faktentabellen zu vermeiden sind und man sich immer an das Sternschema halten sollte, was zu einem Data Warehouse mit mehr als einem Sternschema führen kann.
Namenskonventionen
Wählen Sie eine sprechende Namenskonvention und halten Sie sich daran. Ob Deutsch oder Englisch ist Geschmacksache.
Staging-Bereich / Temporärer Zwischenspeicher zum Datenabruf
Ziehen Sie eine Replikationsschicht für Ihre Quelldatentabellen in Betracht. Beispielsweise kann es sinnvoll sein eine Produktivdatenbank in einer zweiten Datenbank zu spiegeln, damit der Datenabruf nicht gegebenenfalls den Produktivbetrieb ausbremst.
Andererseits wissen ohne Replikationsschicht nach 5 Minuten ganze Abteilungen daß der Berater wieder im Haus ist, auch eine Facette die neue Möglichkeiten eröffnet.
Indizierung und Partitionierung
Für eine bessere (d.h. schnellere) Effizienz der Abfragen, basierend auf der Größe der zu erstellenden Tabellen, kann eine Partitionierung (chunks)in Betracht gezogen und gegebenenfalls implementiert werden. Auch die Wahl der richtigen Indizierung kann einen großen Einfluss auf die Abfrageleistung haben. Grundsätzlich machen sie mit einem aufsteigenden Index nichts falsch.
Technische / Verwaltungs- Attribute
Obwohl das Hinzufügen und Pflegen dieser Attribute mühsam sein kann, kann es für die Zukunft hilfreich sein, Zusatzinformationen wie z. B.
- Zeitstempel des Einfügens
- Aktualisierens von Datensätzen
- Ursache für die Aktualisierung
- Funktion des Attributs
festzuhalten.
Aktualisierungshäufigkeit
Abhängig von der Notwendigkeit der Analyse kann die Planung der DWH-Aktualisierung periodisch täglich, einigen Tagen pro Woche, oder auch Triggergesteuert variieren. Die Zeit, die für eine Aktualisierung benötigt wird, kann einen Einfluss darauf haben und muss daher bei der Planung der Aktualisierungen berücksichtigt werden.
Erweiterbarkeit
Machen Sie das Modell leicht erweiterbar, anpassbar an Veränderungen, das ist die Praxis. Immer.
Die ETL-Implementierung
Das letzte Puzzlestück: die eigentliche Implementierung der Einzelkomponenten und Befüllung des Modells mit Daten. Gerne gesagt: Jetzt kommt Fleisch an die Knochen.
Wenn sie die beiden vorangegangenen Schritte gründlich durchgeführt wurden, fällt dieser Schritt recht leicht und Sie werden trotzdem mit kleinen Überraschungen konfrontiert, die Sie in den vorangegangenen Analyseschritten vielleicht übersehen haben.
Das Werkzeug, das für die ETL-Implementierung verwendet wird, hat den größten Einfluss auf die Menschenkinder, die das entworfene Modell umsetzen und pflegen, weniger auf das Endprodukt.
Heutzutage gibt es eine Vielzahl von Tools, die diese Aufgabe erfüllen, aber die Wahl der ETL-Implementierungssoftware hängt stark von verschiedenen Faktoren ab, wie z. B. von anderer Software (Schnittstellen), Plattformen (Softwarebündel) und Programmiersprachen, die das Unternehmen verwendet, dem vorhandenen Budget für das Projekt und weiterer Faktoren.
Unabhängig von dem Tool, das zum Aufbau der Pipeline verwendet wird, ist der wichtigste Schritt das Testen auf technische und inhaltliche Korrektheit. Wenn alles implementiert wurde, wird die Korrektheit des gesamten Prozesses durch die Durchführung von Tests überprüft. Jede Tabelle muss geprüft werden und es muss auf alle Attribute jeder Tabelle geachtet werden, damit das Endergebnis korrekt ist und mit den ursprünglichen Anforderungen übereinstimmt.
Die Erstellung eines Schemas mit erschöpfenden Testfällen (Einfügen, Aktualisieren oder Löschen von Datensätzen sind die grundlegenden) kann entmutigend erscheinen, aber es ist der beste Weg, um die Gültigkeit Ihres Modells sicherzustellen. Das intensive Testen durch den zukünftigen Endnutzer ist auch ein praxistauglicher Weg, kann je nach Grad der Einbindung allerdings die Akzeptanz erhöhen, oder die Skepsis ausbauen.
Zu guter letzt
Das Design und die Entwicklung eines Data Warehouse ist genau genommen ein ziemlich mechanischer Prozess. Die Beteiligung der Endnutzer (in verschiedene kaufmännische Aspekte) ist es, die die Analyse vorantreibt und die Analyse ist es, die den Rest des Prozesses vorantreibt.
Das Design und die Implementierung des Modells sind eine Ansammlung von Anforderungen, die evaluiert und bei Bedarf implementiert werden müssen. Ein gut entworfenes Modell kann die zukünftige Datenanalyse und die Entwicklung von Dashboards zu einer sehr einfachen und dankbaren Aufgabe machen.
