Umzug eines DWH auf eine Snowflake - Teil 1

Das war ein großes Unterfangen und alle Beteiligten haben dabei viel gelernt. In diesem Zusammenhang haben wir bei ITGAIN unser neues Produkt ITGAIN JobManipulator entwickelt. Ein Team kann damit wesentliche Arbeitsschritte bei der Umstellung der DataStage ETL-Abläufe effizient mittels einfacher Parametrisierung automatisieren. 

Die Umstellung mit dem JobManipulator hat sehr gut funktioniert. Der Kunde hat seine Anwendungen eigenständig auf die Snowflake DB umgestellt. Die JobManipulator-Nutzung hat dafür gesorgt, dass die Teams von manuellen, langweiligen und fehlerträchtigen Tätigkeiten entlastet wurden. 

Sie konnten sich auf die wirklich wichtigen und entscheidenden Aspekte des Umzuges konzentrieren. Und von diesen Aspekten gibt es einige! Wir wollen hier euch in dieser mehrteiligen Blog-Serie davon berichten und natürlich auch von der JobManipulator-Anwendung.

Zunächst wollen wir uns in diesem Teil anschauen, warum ein Kunde so eine Reise überhaupt gehen möchte. Dann ist es nötig, ein paar Begriffe festzulegen. Am Ende dieses Teils geben wir einen Ausblick auf den Rest der Reihe. 

Analytics in der Cloud 

Analytische Datenbanken bieten viele Vorteile gegenüber den „klassischen“ Datenbanksystemen wie eine Db2 oder Oracle oder andere. Natürlich entwickeln sich die Platzhirsche, die ursprünglich für OLTP-Anwendungen konzipiert wurden, weiter, um auch dedizierten analytischen Workload abzuarbeiten. Db2 Blu oder Oracle Exadata sind ein Schritt in diese Richtung. Eine analytische Datenbank aber, die speziell für den typischen Workload eines BI/DWH-Systems erdacht und gebaut wurde, kann besser dafür optimiert werden. Es hat Gründe, warum sich Produkte wie Teradata, Exasol und andere in diesem Umfeld mehrfach bewährt haben und Newcomer wie Snowflake & Co. für Cloud-Infrastrukturen im Aufwind sind. 

Für diese Newcomer im analytischen Umfeld gilt, dass sie nicht auch in der Cloud, sondern zum Teil ausschließlich in der Cloud betrieben werden können. Sie sind explizit für den Einsatz in der Cloud konzipiert, um die Vorteile auf diesen Plattformen konsequent nutzen zu können. Das macht sie noch mal besonders interessant. 

Was erhoffen wir uns von „DWH in der Cloud“, insbesondere wenn wir Software-as-a-Service oder Platform-as-a-Service betrachten? 

• Weniger Abhängigkeit von Hardware: Eine einfache, dynamische Skalierung, eine geringere Abhängigkeit von Hardware-Release-Zyklen. Wie viel Nutzen oder besser wie viele Einschränkungen bietet eine Warehouse-Appliance, die alle Jahre wieder aktualisiert werden muss, die nur definierte Größenklasse aufweist und die uns Anwender über mehrere Jahre im Zweifel limitiert? 
• Weniger bis kein Wartungsaufwand der Software für uns Anwender: Der Service-Lieferant hat die Aufgabe, die Software auf dem aktuell Stand zu halten. 
• Weniger Kosten für Infrastruktur: Wir möchten Hard- und Software nicht auf Spitzenzeiten ausrichten und bezahlen. „Pay for Use“ oder „Pay as You Go“ versprechen uns, nur das zu bezahlen, was wir zu einem beliebigen Zeitpunkt an Ressourcen wirklich benötigen.

Fazit

• Es gibt einige gute Gründe, mit einer analytischen Lösung in die Cloud zu gehen. 
• Aber wie gehen wir die Migration an? Es geht nicht immer als Big Bang. Ein schrittweises Vorgehen bietet sich da an. 
• Eine empfehlenswerte Variante: Als Erstes verschiebe die Daten in die Cloud, sammle dort Erfahrung mit dem neuen RDBMS und baue später dann die ETL-Abläufe zu einer Cloud-Native-Anwendung um. Erst dann können die oben beschriebenen Vorteile des BI/DWH-Systems in der Cloud vollumfänglich genutzt werden.

Umzugskonzepte 

Bei so einem Umzug, vor allem wenn er auch noch in die Cloud geht, werden gerne unterschiedliche Begriffe für das Vorgehen verwendet. Allerdings sind diese Begriffe nicht streng definiert und werden auch unterschiedlich genutzt. 

• Lift & Shift / Rehosting – Die relevanten Komponenten werden (weitestgehend) ohne Änderungen umgezogen.  
• Lift & Adjust / Replatforming – Dieser Fall tritt auf, wenn doch größere Änderungen in den Komponenten der Anwendung nötig sind. 
• Refactoring – Hier handelt es sich um einen größeren Umbau, der nach der eigentlichen Migration kommt. 
• Rebuild / (Full) Rebuild – Das klassische „Wegwerfen“ und „Neu bauen“. 

Und natürlich gibt es noch Varianten davon, je nachdem wie umfangreich die Änderungen sein mögen. 

Die Frage, ob ein Umzug der Daten von Oracle auf Snowflake bei unverändertem (on-premise) ETL-Kern als ein Lift & Shift oder ein Lift & Adjust bezeichnet wird, ist unerheblich. Durch den Austausch der zugrundeliegenden Datenbanktechnologie wird es auf jeden Fall mehr Änderungen geben als nur ein paar Stages in den ETL-Jobs auszutauschen. Mit dem ITGAIN JobManipulator können wir viel automatisieren, er ist aber nur ein Baustein in so einem Projekt. 

Fazit 

Der Umzug auf eine Snowflake von einer anderen Datenbanktechnologie ist immer mit erheblichen Anpassungen verbinden und entspricht konzeptionell eher einem Lift & Adjust-Vorgehen! 

Wer macht den Umzug? 

Es ist verführerisch, den Umzug in fremde Hände zu geben: 

• „Die“ haben das schon häufiger gemacht. 
• „Die“ werden sich doch damit auskennen.  

Aber 

• „Die“ haben aber nicht die bestehende Anwendung gebaut. 
• „Die“ können nicht beurteilen, was die Anwendung tatsächlich leisten soll. 

Vor allem, wenn du noch nicht produktiv mit einer Snowflake gearbeitet hast, ist die Job-Umstellung die erste Möglichkeit wirklich mit einer Snowflake zu arbeiten. Diese Erfahrungen sammelst du nicht, wenn du die Migration komplett an einen Dienstleister auslagerst. Nur einfach umgestellte Jobs entgegenzunehmen, ist nicht ausreichend! Direkt nach der Umstellung wirst du mit den Prozessen arbeiten müssen! Mit diesen Abläufen willst du die nächsten Jahre leben, bis ein Redesign/Refactoring der ETL-Anwendung erfolgt.  

Zudem muss die Job-Umstellung in enger Abstimmung mit den anderen Migrationsschritten im Zuge des Umzugs erfolgen. Dazu gehören ganz besonders die eigentliche Datenmigration und auch das Reporting, das auf die Snowflake umgestellt werden muss. 

Unsere Empfehlung: dieser Prozess kann nur inhouse und agil erfolgen!  

• Plant Zeit für fachliche (Daten-)Tests ein. Nur summarische Tests zu machen, reicht nicht. Die Daten müssen satzweise miteinander verglichen werden, um sicher zu sein, dass die Daten- und ETL-Migration erfolgreich war. 
• Rechnet damit, dass euer erster Migrationsansatz angepasst werden muss! In den Daten oder Abläufen können sich kleine Stolpersteine verstecken, die eine Anpassung der Migration notwendig machen.

Fazit 

• Die Migration von ETL-Abläufen ist eine der Kernaufgaben für das Team, dem die Abläufe gehören! 
• Nutze die Kompetenz von externen Beratern – so wie wir unserem Kunden bei seiner Migration geholfen. Aber behalte den Überblick und arbeite selbst intensiv an der Umstellung mit. 

Wie geht es mit unserem Blog weiter? 

Wir legen zwar den Fokus auf die Migration der DataStage ETL-Abläufe, ETL-Prozesse sind aber nicht losgelöst von dem verwendeten Datenbanksystem oder den Daten. Deswegen machen wir kleine Abstecher nach links und rechts und schauen uns an, welche Auswirkungen sich durch die unterschiedlichen SQL-Dialekte beider Datenbanksysteme (Oracle und Snowflake) ergeben haben. 

In den nächsten drei Blogs werden wir uns mit den Grundlagen und Grundzügen der Umstellung beschäftigen. Wir werden untersuchen, was bei der Zusammenarbeit eines klassichen ETL-Tool mit einer analytischen Datenbank zu beachten ist und dann anschauen, welche Erfahrungen wir euch bei der Umstellung der ETL Jobs euch mitgeben können. 

Am Ende haben wir noch zwei Blogs zu bieten, noch einen Deep Dive für all jene, die es gerne genau wissen möchten und an speziellen Eigenarten von DataStage und Snowflake interessiert sind. 

Teil 2: Was ist zu tun – Lasst uns ein paar Grundlagen festziehen und beschreiben, die in dieser Artikelreihe relevant sind: 

• Was ist eigentlich bei einer Cloud-Migration im ETL zu tun? 
• Worin unterscheidet sich eine Snowflake von einem klassischen RDBMS wie Oracle? 

Teil 3: DataStage und Snowflake – Wie passen ein klassisches ETL-Tool und eine neue analytische Datenbank zusammen: 

• Welches DataStage Release ist geeignet bzw. erforderlich? 
• Wie ist die Verbindung von DataStage zur Snowflake? 
• Welche Auswirkung hat der Einsatz der Snowflake ConnectorStage? 

Teil 4: Migration der ETL-Jobs – Wir schauen uns an, wie komplette DataStage Projekte mit dem ITGAIN JobManipulator umgestellt werden: 

• Wie solltest du deine DataStage Projekte organisieren? 
• Wie wird ein Job an sich umgestellt? 
• Wie kannst du eine DataStage ConnectorStage von Oracle nach Snowflake umstellen?
• Wie kannst du die Migration mit dem JobManipulator durchführen?