Wir von der Ceteris haben unsere gesammelten Erfahrungen zum Thema relationaler Datalake konsolidiert und haben uns zum Ziel gesetzt diesen an nur einem Tag bei Ihnen aufzubauen. Warum ein Datalake ein spannendes Thema sein kann, wollen wir mit einer kleinen Geschichte zeigen.
Prolog
Ich bin der einzige Mitarbeiter im Bereich Data Analytics der die Technologien T-SQL sowie Microsoft SQL Server Integration Services beherrscht und versuche Fragestellungen meines Unternehmens zu beantworten und meinen Kollegen datengetrieben bei Entscheidungen zu helfen.
Wie sieht meine bekannte IT Infrastruktur aus:
- Ene: ist ein SQL Server, welcher zwischen 7 und 22 Uhr unter Last des täglichen Arbeitens steht und auf dem keine Auswertungsanfragen erlaubt sind.
Um dennoch meine Fragen zu beantworten, wandele ich auf einen schmalen Grat. Entweder nutze ich die Zeit ab 18 Uhr und bekomme von meinem Systemverantwortlichen auf die Mütze, weil ich Last auf dem Server erzeuge oder ich fange ab 22 Uhr an zu arbeiten und bekomme von meiner Familie auf die Mütze, weil ich noch so lange arbeite. - Mene ist ein webbasiertes Portal, welches Informationen zu allen Newslettern beinhaltet, die ich an meine Kunden verschicke. Über vordefinierte Berichte kann ich diese Informationen auswerten. Ein nicht standardisierter Bericht ist nur über Umwege möglich. Haben genug Kunden die gleiche Anforderung, wird dieser Bericht grundlegend entwickelt. Oder ich zahle entsprechend, dann wird er speziell für mich entwickelt. Beides dauert lange!
- Miste ist ein SQL Server, mit dessen Daten ich arbeiten kann wie ich will: JACKPOT! Frei nach dem Motto „The Sky is the limit“ kann ich die Daten bearbeiten, analysieren und ungestört veredelte und wenn nötig automatische Berichte erstellen.
Kapitel 1: the awakening
Wie sieht somit mein Arbeitsalltag der vergangenen 3 Monate aus? Ich analysiere, erstelle Berichte, nehme neue Anforderungen auf und kann all meinen Kollegen durch unsere Miste-Daten bei den Entscheidungsprozessen unterstützen.
Über die Zeit gibt es Anfragen wie,
„Kannst du die Informationen mit Ene kombinieren? Kannst du die Informationen mit Mene kombinieren?“
„Ja kann ich, aber das wird etwas länger dauern, weil ich bei Ene und Mene limitiert bin auf..“
Jeder versteht das und jeder ist umso glücklicher, wenn ich zum Schluss die Informationen bereitstellen kann. Das Unternehmen wird erfolgreicher und alle sind glücklich.
Das Problem ist: „The Sky is the limit“. Die Anfragen kommen immer häufiger, die Analysen und Berichte mit Informationen von Ene und Mene anzureichern. Auch noch zwei weitere Datenquellen kommen ins Spiel, Rappelt und Kiste. Die eine ist ein MySQL Datenbank und die andere eine Oracle Datenbank. T-SQL kann ich ja, aber MySQL und PL/SQL. Ja, sie sind ähnlich, aber es gibt schon Unterschiede.
Kapitel 2: the possibilities
Im aktuellen Monat ist die Überlegung aufgekommen, alle Daten aus allen möglichen Quellen in einer SQL-Datenbank zu speichern und den Fachanwendern SQL zu schulen, sodass die Kollegen ihre Daten selbst auswerten können. Von der Idee, des sogenannten „Datalakes“ konnten wir alle überzeugen und jeder sah den heiligen Gral vor sich.
Hierbei gilt allerdings eine entscheidende Restriktion – das Tagesgeschäft darf nicht darunter leiden. Nun habe ich also wieder eine Gratwanderung vor mir. Wie schaffe ich es, meine Analysen weiterzuentwickeln und dennoch unseren Datalake bestehend aus Ene, Mene, Miste, Rappelt und Kiste fertigzustellen?
Um eine Antwort zu finden, habe ich mir Gedanken über eine zu erwartende Datenverteilung gemacht. Ich versuche daran eine Abschätzung zu machen, wie lange ich dafür brauchen würde, um alle Daten vom Quell- zum Zielsystem zu verschieben.
Bei Mene habe ich erfahren, dass ich die Rohdaten mithilfe einer RestApi erhalten könnte. Hierbei stehen mir 24 verschiedene Methoden zur Verfügung um Daten zu erhalten. Meine Schätzung: 3 Arbeitstage (AT) um die RestAPI zu verstehen, drei Stunden pro Methode um das erlernte zu verstehen. Für Mene wären das: 3 AT +(3h*24)/8 = 12 AT
Bei den Datenquellen Ene, Miste, Rappelt und Kiste haben wir in Summe 960 Tabellen. Wenn ich annehme, dass ich die Daten nur 1 : 1 aus dem Quellsystem kopieren will und dass ich in einer Stunde acht Ladeprozesse entwickeln kann, dann schaff ich 64 Tabellen pro AT und bräuchte in Summe 15 AT.
Epilog (aus Sicht eines Ceteris-Mitarbeiter)
Viele gute Ideen, die zum einen das Leben erleichtern und zum anderen erfolgreich werden können, scheitern bei der Umsetzung.
In der oben beschriebenen Geschichte aus dem Leben eines BI Mitarbeiters, könnte der viele Probleme lösen:
- Die Fachanwender könnten an zentraler Stelle ihre Fragestellungen selber stellen und beantworten
- Die Quellsysteme agieren unabhängig von dem Datalake, sodass Analyse Abfragen ohne Restriktion gemacht werden können
- In Summe können wir BI Mitarbeiter uns wieder unsere eigentlichen Aufgaben widmen.
Warum aber wird wie in diesem Falle die Umsetzung wahrscheinlich scheitern oder erst zu einem späteren Zeitpunkt realisiert?
Das Unternehmen müsste entscheiden, kann ein BI Mitarbeiter für einen Monat aus dem Tagesgeschäft herausgezogen werden oder will ich lieber die aktuelle Welle des Erfolges mitnehmen und mache den Datalake zu einem späteren Zeitpunkt? Wann ist dieser spätere Zeitpunkt? Stell ich einen neuen Mitarbeiter ein und was passiert, wenn ich keinen finde? Greife ich auf einen externen Dienstleister zurück?
Aber was passiert nach 27 Tagen Entwicklung des Datalakes? Können wir die Daten aus der Quelle gleich so verwenden? Bedarf es einer Stammdatenpflege? Wie kann ich vor meinen Chefs verargumentieren, dass ich 27 Tage Entwicklungszeit für einen Datalake brauche?
An dieser Stelle würden wir von der Ceteris AG gerne in Ihr Spiel kommen. Wir wollen den Datalake an einem Tag mit Ihnen zusammen erstellen.
Wie wir das mit Ihnen machen, zeige ich Ihnen gerne demnächst bei Ihnen vor Ort.