Ein neues Data Lakehouse ist soeben eingeführt. Die gewählten Technologien und die neue Plattform versprechen flexible und performante Auswertungen. Der schrittweise Aufbau von Data Science und KI ist möglich. Entsprechend wird der Erfolg gefeiert. Niemand trauert dem in die Jahre gekommen Data Warehouse nach, wären da nicht noch die Daten, die möglicherweise weiterhin von Interesse sind.
Bevor nun das alte System endgültig außer Betrieb genommen wird, muss geklärt werden, was nun mit den Daten geschieht. Eine Standardantwort darauf gibt es nicht.
Werden die Daten noch benötigt?
Diese Frage ist der Ausgangspunkt für die Wahl der geeigneten Lösung. Das Einfachste ist, wenn niemand mehr Bedarf für diese Daten hat, entweder weil in den Berichten wenig oder keine lange Historie benötigt wird oder die Datenqualität so schlecht ist, dass sowieso niemand einem Ergebnis aus dem alten Data Warehouse traut.
Sollten die Daten weiterhin benötigt werden, ist die Frage welche und wie viele davon. Benötigen wir vielleicht nur die letzten zwei Jahre und die 25 Jahre davor können gelöscht oder archiviert werden? Oder benötigen wir einen Teil der Daten nach anderen Gesichtspunkten, beispielsweise nur Produkthistorie, jedoch keine Logistikinformationen?
Können die Daten migriert werden?
Datenmigration ist eine aufwändige Sache. Es müssen Mappings aufgebaut und verschiedene Herausforderungen aus Sonderfällen der ehemaligen Datenerfassung gelöst werden. Das Zielsystem benötigt Daten, die es so im alten System noch nicht gab. Qualitätsprobleme in den Altdaten müssen gelöst werden.
Im Wesentlichen ist Datenmigration ein Projekt zur Erstellung von ETL-Jobs, die gerade ein einziges Mal laufen. Etwas einfacher fällt die Migration unter Data Vault aus. Die Altdaten werden einfach in separate Satellite-Tables geschrieben.
Behalten wir die alte Datenbank?
Die Datenbank des alten Data Warehouse wird nur noch lesend verwendet. Der Migrationsaufwand entfällt. Jedoch müssen Berichte auf das alte und neue Data Warehouse zugreifen und diese kombinieren. Die Komplexität in den Berichten steigt und Fehler nehmen zu.
Ein virtueller Layer hilft die Komplexität zu kapseln. Das Zusammenführen wird einmal definiert. Berichte greifen nur auf den virtuellen Layer zu, der die Queries aufteilt und die Ergebnisse zusammengeführt an den Bericht zurückgibt.
Wird das alte Datenbank-Managementsystem weiterhin genutzt, bleiben auch Lizenz- und Betriebskosten. Die Entscheidung zum Abschalten wird dadurch nur herausgezögert.
Data Lake als Archiv?
Werden die alten Daten nur selten benötigt, oder gibt es Anforderungen an die gesetzliche Aufbewahrung, ist ein Datenarchiv der sinnvollere Weg. Ein Object Storage als Data Lake ist eine deutlich kostengünstigere Lösung als ein DBMS. Wird der Data Lake in Zonen strukturiert, bietet sich dafür eine eigene Archivzone an.
Benötigen wir die Details?
In den seltensten Fällen werden die Detaildaten von inaktiven Geschäftsfallen der letzten zehn Jahre benötigt. Durch verschiedene Einflüsse, wie Reorganisationen oder andere Anpassungen, sind die Daten für direkte Vergleiche nicht mehr geeignet. Für Trendanalysen reichen verdichtete Daten aus. Das heisst, es genügt ein vereinfachtes dimensionales Modell mit aggregierten Daten. Die Details können getrost in ein Archiv geschrieben werden.
Bei Projekten zur Data-Warehouse-Modernisierung ist der Umgang mit den alten Daten die größte Herausforderung, neben der Evaluation der geeigneten Plattform.
