Analytische Applikationen in der Cloud überzeugen durch unschlagbare Skalierbarkeit, Kostenvorteile und Sicherheit. Doch bei der Migration in die Cloud kann einiges schief gehen, wenn man die Best Practices nicht kennt.
Data Analytics ist die Grundlage für eine gute Entscheidungsfindung. Analytische Anwendungen zuverlässig in der Cloud verfügbar gemacht, tragen dazu bei, Entscheidungen in Unternehmen zu demokratisieren und zu fundieren, selbst in immer komplexeren Geschäftsumgebungen mit steigendem Zeitdruck. Und zwar auf jeder Hierarchiestufe, barrierefrei, sicher und jeder Zeit bedarfsgerecht verfügbar.
Gründe für die Cloud-Migration. Neben dieser Zukunftsvision einer offenen und datenbasierten Organisationskultur streben Unternehmen mit der Cloud noch weitere, direkt messbare Mehrwerte an: kürzere Time-to-Market-Zyklen für analytische Anwendungen und signifikante Reduktionen von Kosten und Aufwand. Im Jahr 2020 beauftragte Microsoft beispielsweise Forrester Consulting mit einer »Total Economic Impact«-Studie, bei der Kunden zu ihrer Migration nach Azure SQL befragt wurden. Im Durchschnitt erzielten sie die Amortisierung nach nur drei Monaten oder weniger beziehungsweise einen ROI von insgesamt 238 Prozent innerhalb von drei Jahren nach dem initialen Investment.
Unabhängig vom Cloud-Anbieter geht die Tendenz überall in dieselbe Richtung: Zwar ist eine bereits beschaffte On-Premises-Software immer günstiger als eine neue Anschaffung. Doch gewinnt die Cloud bei der Skalierbarkeit (»Pay-as-you-go«). Lokal installierte IT-Infrastruktur und ihre Kosten wachsen mit jedem Implementierungsschritt in fixen Größen. Anwendungen in der Cloud lassen sich dagegen beliebig und schnell hoch- und herunterfahren, ganz dem tatsächlichen Bedarf entsprechend. Immer vorausgesetzt, bei der Migration der Daten sind einige Best Practices beachtet worden, wie sie beispielsweise in Projekten des INFORM DataLab gängige Praxis sind. Konkret hat sich ein Prozess in drei klar unterschiedenen Schritten etabliert (siehe Abbildung).
Bei der Migration der Daten in die Cloud hat sich ein Prozess in drei Schritten bewährt: Migration, Konsolidierung und Transformation.
Errfolgreiche Cloud-Migration in drei Schritten. In der Regel sind analytische Anwendungen auf viele Datenquellen angewiesen. Diese können sowohl aus on-premises installierten oder in Cloud liegenden Datenbanken, Systemen und Anwendungen stammen, strukturiert oder unstrukturiert vorliegen. Häufig sind auch geographisch unterschiedliche Rechenzentren im Spiel, etwa wenn ein Unternehmen Standorte im Ausland zugekauft hat, wo vielleicht andere Systeme als im Rest der Gruppe im Einsatz sind. Aus all diesen Datensilos sollen die Daten in die Cloud gelangen, denn es ist viel einfacher die vorgefertigten Migrationspfade in die Cloud zu nutzen als neue Pfade aus der ganzen Welt zu einem lokalen Rechenzentrum zu ersinnen.
1. Migration
Würden die analytischen Systeme wie Power BI, Qlik Sense oder Tableau ihre Daten direkt aus den Quellsystemen ziehen, würden sie deren operativen Betrieb massiv stören, da diese Systeme nicht für große Aggregationsabfragen ausgelegt sind. Daher wurden Daten lange Zeit nach dem ETL-Paradigma (»Extract, Transform, Load«) in eine speziell für analytische Anwendungen ausgelegte OLAP-Datenbank in der Cloud migriert. Inzwischen empfiehlt es sich, das Paradigma umzudrehen: in »ELT«. Würden die Daten in der Cloud direkt transformiert, stünden sie dort nur in einer sehr Use-Case-spezifischen Form zur Verfügung. Stattdessen zielt die Best Practice darauf ab, zunächst einen identischen Abzug der Quelldaten in einer Raw Data Landing Zone zu speichern. Um die Daten aktuell zu halten, haben sich Change-Data-Capture-(CDC)-Verfahren etabliert, durch die immer nur dann neue Daten – zunächst in einen temporären Speicher und dann in die Landing Zone – geladen werden, wenn sich diese im Quellsystem verändern. Dieses gut automatisierbare Verfahren ist für die Quellsysteme besonders schonend.
2. Konsolidierung
Anschließend sollten die Daten aus allen Quellsystemen konsolidiert und erneut in einer eigenen Zone gespeichert werden, der Trusted Data Zone. Hierzu bietet sich zum Beispiel die einfach erweiterbare und skalierbare Datenmodellierungsform des Data Vaults an. Die unterschiedlichen Quellen werden hier jedoch zueinander in Bezug gesetzt. So lässt sich der gesamte Datenstamm mit seinen Referenzen weiterhin leicht aktualisieren und überblicken (Data Lineage). Schließlich ist Speicherplatz in der Cloud wesentlich günstiger als die Verarbeitung von Daten, die ohne diesen Konsolidierungsschritt immer neu erfolgen müsste, wenn die Zielanwendung später einmal verändert werden soll.
3. Transformation
Erst im letzten Schritt sollten die Daten in einem weiteren Bereich, der Service Data Zone, transformiert werden. Hier eignet sich die dimensionale Modellierung der Data Marts, bei der die Daten denormalisiert zur Verfügung gestellt werden, so dass BI-Systeme sie mit wenig Rechenleistung auslesen können. Dies ist auch der Bereich, in dem die Daten anwendungsspezifisch mit Business-Logiken versehen werden. Hätte man auf den vorherigen Konsolidierungsschritt verzichtet, würden sich spätere Updates im denormalisierten Datenstamm äußerst schwierig gestalten.
Tipps und Tricks zusammengefasst. Mit anderen Worten: Die häufigsten und gravierendsten Fehler, die Unternehmen begehen können, sind:
- Daten in der Cloud nicht zu konsolidieren,
- Daten nach der Migration zu früh zu transformieren,
- Daten nicht für die Analytics-Software auslesbar zu gestalten,
- Daten nicht in klar voneinander abgegrenzten Zonen zu speichern und zu verarbeiten.
Sie alle führen dazu, dass Transparenz und Ladezeiten leiden, bis dahin, dass die wachsende Datensammlung und ihre Verknüpfungen irgendwann nicht mehr nachvollziehbar sind. Am Ende stehen erhöhte Kosten und Aufwand, die sich mit einer gut strukturierten Migration hätten vermeiden lassen. Auf der anderen Seite ermöglichen das CDC-Verfahren sowie das konsequente Einhalten der verschiedenen Zonen reibungslose, globale analytische Anwendungen in der Cloud.
Philipp Ziemer,
Data Management Lead,
INFORM DataLab