Tech Talk: "Benefits of a Data Warehouse" mit Manuel Osterbauer

Tech Talk: "Benefits of a Data Warehouse" mit Manuel Osterbauer

Hallo und grüß euch! Ich erzähle euch heute über die Vorteile eines Data Warehouses. Kurz zu mir, ich bin Manuel Osterbauer, bin Senior Consultant bei der Firma Trivadis - Part of Accenture.

Kurz einmal zu Beginn ein Überblick über unsere standard Architektur eines Data Warehouse. Natürlich, je nach Kundenprojekt kann das ein wenig anders ausschauen, aber im Grunde sieht es grob einmal so aus – das heißt das Data Warehouse besteht aus unterschiedlichen Schichten. Ganz zu Beginn, das ist noch außerhalb des Data Warehouses, gibt es natürlich die unterschiedlichsten Quellen und nach dem Data Warehouse ist natürlich dann der Platz wo dann der Kunde oder der "Consumer" die Daten wieder abzieht und seine Entscheidungen daraus trifft. Ich will jetzt auch nicht viel mehr auf die Architektur eingehen, aber es ist trotzdem mal gut, es gesehen zu haben.

Wir kommen jetzt schon konkret auf der nächsten Folie zu den Vorteilen eines Data Warehouses – warum macht man das und was ist der Sinn dahinter? Hier, diese Matrix zeigt einerseits die Vorteile und in Summe auch die Verantwortlichkeiten pro Schicht – aber ich will jetzt gar nicht so genau auf die Schichten eingehen. Man sieht hier zumindest die Staging Area, die Cleansing Area, den Core und die Data Marts. Das sind die vier Schichten eines Data Warehouses und pro Vorteil oder Verantwortung habe ich hier eingezeichnet wo die Verantwortung einer jeden Schicht liegt. Kurz zu den Vorteilen und dann gehen wir ins Detail.

Zu Beginn, die Staging Area hat den Vorteil, einfach alle Daten die von den Quellen kommen, in unterschiedlichsten Varianten einfach einmal anzulanden und die in eine Schicht einmal abzulegen. Das ist auch schon der einzige Sinn dieser Schicht.

Die nächste Schicht ist dann schon, wo passiert diese ganze Transformation, Bereinigung, Anreicherung. Das ist die sogenannte Cleansing Area. Da passiert alles zentral – Filterungen, Übersetzungen, Validierungen und auch das Error Handling. Genauso passiert dort auch Daten Anreicherungen. Also von außen hin könnten hier Daten noch hinzu kommen und können bestehende Daten anreichern.

Der nächste Vorteil eines Data Warehouses ist, man hat dann irgendwann mal die Daten harmonisiert und integriert und persistent abgespeichert – man kann quasi die Daten nicht mehr verlieren – und hat sie dann auch historisiert. Das heißt, ich weiß auch im Nachhinein noch, wie haben sich gewisse Standarten in der Zeit geändert und verliere dadurch eigentlich nie Daten.

Der nächste Punkt: es gibt dann auch wieder eine zentrale Stelle, wo die gesamten Kennzahlen berechnet werden – das ist ein Vorteil – und natürlich auch die (Hoch-) Verfügbarkeit gewisser Daten soll immer gewährleisten, dass die Daten immer verfügbar sind und für den Kunden immer abrufbar sind. Und natürlich ist ein Data Warehouse so aufgebaut, dass eben diese Abfragen auf diese berechneten Daten im Data Warehouse schnell sind, sodass der Kunde die Daten und die Entscheidung schnell treffen kann. Und es ist gar nicht so wichtig, dass der geringste Speicherplatz genutzt wird, sondern es soll performant für den Kunden sein. Und natürlich auch – letzter Vorteil – verständlich und einfach zugreifbar, nicht irgendwie kompliziert, komplex mit huderttausend Tabellen, sondern einfach in einer Struktur.

Jetzt gehen wir schon in die Details hinein. Nochmals zur Staging Area – wie man hier auf der linken Seite sieht, gibt es hier unterschiedlichste Quellformate. Das können Dateien sein, das könnte eine relationale Datenbank sein, über Views und Tabellen es können Webschnittstellen sein, genauso könnten es irgendwelche Programmierschnittstellen sein. Die muss man natürlich alle mal auf einen gemeinsamen Nenner bringen und das ist im Endeffekt die Staging Area – dass man die Daten einmal dort landet und dass sie einmal alle zumindest in einer relationalen Tabelle dort vorliegen, dann geht es mal weiter in die nächsten Schichten.

Zentrale Datenbereinigung – zur Datenbereinigung oder Transformation gehört alles mögliche dazu von Filterung, Übersetzungen, Konvertierungen. Hier habe ich ein paar Beispiele mitgebracht, was etwa Data Cleansing sein könnte – hier eine ganz einfache Tabelle mit Personendaten und Gehälter. Welche Transformationen könnte man auf diese Daten anwenden – wie gesagt es kann einfach ein Filter passieren, dass man sagt okay in dieser Tabelle sind aktuell noch drei Zeilen. Nach dem Filter dürfen nur Personen dabei sein, die über achtzehn sind, habe ich dann noch eine kleinere Tabelle mit einfach einer Zeile weniger. Dann könnte eine nächste Transformation sein, ich rechne zum Beispiel den Gehalt in Euro in eine andere Währung zusätzlich um, das wäre auf der rechten unteren Seite und dann vielleicht auch noch in eine Sprachübersetzung. Das heißt ich habe her zum Beispiel die Spalte Geschlecht und will sie auch noch auf Deutsch übersetzten.

Das könnten sequenzielle – aber auch parallele – Schritte sein in einem Data Cleansing Ablauf, aber es können natürlich noch viel mehr und viel komplexere Regeln sein, aber ich wollte mal hier veranschaulichen welche Transformationen es in der Cleansing Area geben kann. Der Vorteil ist, sie sind auf einer zentralen Stelle – ich weiß genau, wenn es irgendwo einmal falsche Daten gibt, ich muss dort suchen und nirgendwo anders.

Datenanreicherung – das heißt jetzt ich habe die Daten schon bereinigt, transformiert und jetzt kommen von außen noch zusätzliche Daten hinzu und kann die bestehenden Daten um weitere Eigenschaften anreichern. Hier wieder ein Beispiel mit Personen, die in einem gewissen Land leben. Ich habe eine zusätzliche Tabelle, wo eben ein Kürzel eines Ländercodes noch auch der lange ausgeschriebene englische Name eines Landes steht und kann eben mit einem sogenannten Lookup meine Stammdaten, die ich habe, um diese Information anreichern. Ist natürlich jetzt auch wieder ein eher einfacherer Lookup, aber genau darum geht's – bestehende Daten um weiter Daten anzureichern.

Wenn ich die Daten gelandet habe in der Staging Area, dann habe ich sie transformiert und angereichert über die Cleansing Area, dann will die Daten strukturiert, harmonisiert und integriert im sogenannten Core ablegen. Das ist die erste Schicht wo die Daten persistent ablegen, dort werden keine Daten mehr gelöscht, hier kommen nur Daten hinzu oder es werden Daten angepasst. Da gibt es unterschiedlichste Modellierungsvarianten hier zum Beispiel sieht man einen sogenannten dimensionalen Snowflake Core, könnte auch genauso ein Data Vault Core sein. Aber hier in dieser Variante ist es diese Modellierungsform und hier denkt man oder redet man von Fakten und Dimensionen – also in den Dimensionen liegen die Stammdaten und in den Fakten liegen die Bewegungsdaten.

Was auch im Core passiert, ist – wie ich vorhin schon einmal kurz gesagt habe – ich habe die Daten wenn sich ein Datensatz ändert, kann er theoretisch auch überschrieben werden, aber meistens ist es so, dass man diesen Datensatz nicht ändert sondern einen neuen Datensatz einfügt, damit man auch noch weiß wie war der Datensatz zuvor oder noch weiter davor. Dadurch habe ich einen Verlauf und kann zum Beispiel Bewegungsdaten zu der richtigen Zeit zuordnen zu diesen Stammdaten.

Hier ein vielleicht etwas schwierigeres Beispiel, aber es soll hier nochmals zeigen, wir löschen nie Daten. Wenn sich Daten ändern werden die alten Daten quasi geschlossen und neue Daten als offen markiert – also man sieht hier oben noch eine quasi eigene, eine kleine Cleansing Tabelle mit genau den Daten die drinnen sind und die untere Tabelle ist das schon wie man sieht eine kleine technische Tabelle im Core. Man braucht einfach gewisse technische Felder, damit man einfach diesen Verlauf sieht. Und man sieht hier ein kleines Beispiel von der "Sue Porter", da hat sich das Alter geändert und das Land, das heißt die dürfte umgezogen sein und über die technischen Felder der rechten Seite weiß ich von wann bis wann dieser Datensatz gültig war und ab wann war quasi der nächste gültig. Ich sehe auch über die letzte Spalte genau, welcher Datensatz jetzt aktuell gültig ist, das ist die historisieren von Daten in Core.

Was auch ein großer Vorteil ist von einem Data Warehouse: der Kunde will natürlich Auswertungen haben, diese Kennzahlen werden dann an einer zentralen Stelle berechnet. Hier ein Beispiel, ich habe Fakten auf der linken Seite, gewisse Bestellungen, ich habe zu diesen Fakten gewisse Informationen welches Produkt hat der Kunde X in welcher Menge bestellt. Und jetzt aus diesen hochgranularen Daten gewisse Entscheidungen ableiten oder gewisse Kennzahlen berechnen. Da habe ich ein einfaches Beispiel dargestellt – der Kunde sagt einfach, ich will jetzt wissen pro Produkt wieviel Umsatz gemacht worden ist. Dann muss ich natürlich wissen, wie ein Umsatz berechnet wird – das wird einmal definiert – aber im Endeffekt aus diesen Basisdaten im Core werden dann im Data Mart Kennzahlen berechnet und dann kommt im Endeffekt ein aggregierter Data Mart raus wo dann pro Produkt ein gewisser Umsatz rauskommt. Und den kann der Kunde dann auswerten. Das heißt ich habe dann für den Kunden nicht einen Data Mart, sondern beliebig viele, je nach Varianten oder je nach Granularitätsstufe – wie es der Kunde haben will.

Und das ist der große Vorteil, ich kann aus den sehr fein granularen Core Daten beliebig viele Schlüsse oder Kennzahlen berechnen und das eben für den Kunden dann darstellen.

Auch ein wichtiger Punkt ist die Verfügbarkeit oder Hochverfügbarkeit der Daten. Beziehungsweise auch diese Daten müssen natürlich von der Quelle bis in den Core mal gelangen. Das kann in unterschiedlichsten Zyklen passieren, das kann einmal am Tag passieren, das kann in wenigen Minuten regelmäßig passieren. Das muss aber nicht der gleiche Zeitintervall sein wie die Data Marts beladen werden. Das heißt der Core, also das Staging und Cleansing im Core ist unabhängig von den Data Marts – mehr oder weniger, natürlich muss ich auch die Data Marts beladen. Aber der große Vorteil ist ich kann zum Beispiel gewisse Data Marts hochverfügbar gestalten, ich kann quasi einen Data Mart 1 replizieren, hier kann man einen Load Balancer dazwischenschalten und der Kunde geht mit seinen Tools, Front End Tools auf diesen Load Balancer und holt sich diese Daten über den Data Mart. Und sollte einmal der Core oder einer dieser zwei Data Marts ausfallen, ist es im Endeffekt egal, weil es ist trotzdem immer noch ein Data Mart verfügbar und das ist einfach der große Vorteil, ich habe die Daten einfach immer zumindest aktuell oder so aktuell wie möglich verfügbar und kann meine Auswertungen machen und meine Entscheidungen treffen.

Und zur guter Letzt – der letzte große Vorteil ist die Abfrage Performance. Der Kunde will dann natürlich nicht ewig auf diese Antworten oder auf diese Schlüsse warten. Er will eine einfache, lesbare Struktur haben, der Core kann unterschiedlich modelliert sein. Der Core ist sehr feingranular strukturiert, dass eben die Daten nicht redundant sind. Wir sprechen hier schon von den Data Marts – das soll einfach performant ablaufen, dass dieser auf die Data Marts schnell zugreifen kann und auch einfach und verständlich. Und dadurch sagen wir immer, ein Data Mart sollte immer als ein Star Schema modelliert sein. Star Schema kommt von dem Namen her weil die Darstellung wie ein Stern aussieht, in der Mitte gibt es eine Faktentabelle und rundherum gibt es eine bis n-beliebige Dimensionen. Das ist ein so ein Stern, es kann natürlich beliebig viele Sterne geben, aber das ist quasi eine Auswertung könnte man sagen.

Und man sieht genau, in der Mitte sind die Fakten rund um die Dimensionen und die Fakten stellen die Bewegungsdaten dar – Einkäufe, Verkäufe, Lieferungen – und die Dimensionen sind die Stammdaten und beschreiben diese Fakten genau.

Das Sternschema ist denormalisiert – heißt es sind redundante Daten da, aber das ist eben der große Vorteil – dadurch wird die Abfrageperformance erhöht, weil eben die Daten nicht so feinranular herumliegen und ich muss nicht so viele Joins machen. Ich muss eben, wenn ich von der Faktinformation zum Beispiel zum Produkt will, nur einmal joinen – ich muss nicht mehrmals joinen und dieser Bedarf an wenigen Joins, das erhöht meine Abfrageperformance. Und deswegen sollte man hier immer ein Star Schema gegenüber eines Snowflake Schema wählen. Man muss als Kunde einmal verstehen, was sind Fakten, was sind Dimensionen – das muss man kennen und wenn man das verstanden hat, dann kann man diese Daten auch noch verstehen und Abfragen um seine Schlüsse daraus ziehen.

Das ist der große Vorteil eines Stars Schemas.

Dankesehr!

 

 

Erfahre mehr zum DevTeam von Trivadis