So gelingt die Migration bestehender Systeme auf Big Data

Big Data TrichterMigrationsprojekte von relationalen Datenbanken zu BigData-Lösungen sind vielschichtig und oftmals durch die komplexe heterogene Systemlandschaft gekennzeichnet. 

Sie können mit sorgfältiger Planung und Risikomanagement zu Meilensteinen in der Entwicklung eines Unternehmens werden und Sprünge in der Informationsverarbeitung initiieren, sofern der Mehrwert des Vorhabens klar umrissen und aus der hohen Anzahl der technologischen Möglichkeiten die optimale Lösung für den jeweiligen Anwendungsfall gewählt wird. BigData bringt nicht nur technologischen Wandel, im Sinne von Austausch eines Bausteines der IT-Landschaft, sondern auch den exponentiellen Anstieg der Lösungswege mit sich.

Anzeige

Wann führe ich die Migration durch?

Bei börsennotierten Unternehmen sind die Informationspflichten zu beachten und eine Verzögerung dieser Berichte aus dem zu migrierenden Datenpool zu vermeiden. Finanzdaten lassen sich am saubersten nach einem Jahresabschluss und der darin enthaltenen Trennung der Zeiträume migrieren. Naheliegend sind Feier- und Brückentage. Doch stören Urlaubsplanungen der Projektbeteiligten und gerade zu Jahresende laufende Prozesse diese Planung. Saisonale Schwankungen in der Auslastung der gesamten IT sind bevorzugte Zeiträume, die jedoch in sich wieder das Problem einer gewissen Deadline bergen. Zu berücksichtigen ist hierbei auch die Dokumentationspflicht gegenüber Wirtschaftsprüfern, die gerade Systemwechsel zum Anlass nehmen, genauer hin zu schauen. Systeme, die diese migrierten Daten weiter verarbeiten, sollten getestet und einsatzbereit sein und nicht durch einen Mix der Datenquellen aus Alt- und Neusystemen unübersichtlich und fehleranfällig gestaltet werden. Durch die Trennung der zu übernehmenden Zeiträume lassen sich in diesem Punkt aber auch zu große Migrationsläufe aufteilen.

Datenvolumina und Zeitplanung stellen hohe Anforderungen an die Projektleitung.

Bild 1: Datenvolumina und Zeitplanung stellen hohe Anforderungen an die Projektleitung.

Wie groß ist die zu verarbeitende Datenmenge?

Überschreiten Datenvolumina bestimmte Grenzen der bestehenden, meist relationalen Datenbanken, initiiert dies das Projekt BigData. Welches Werkzeug ist in der Lage, die großen Datenmengen in einem gesetzten Zeitrahmen zu überführen? Die Migrationsjobs sollten mit einem möglichst einzuplanenden Zeitpuffer, innerhalb des gegebenen Rahmens, alle Daten verarbeiten. Die Struktur der Migration ist meist: Stamm- vor Bewegungs- vor historischen Daten.

BigData darf nicht als Deponie aller möglichen Daten betrachtet werden, sonst torpediert man die Struktur und damit das Projektziel. Master-Data-Management und sorgsame Auswahl der zu übernehmenden Daten sorgen für Ordnung und entschlacken den Prozess.

Parallelisierung und Skalierbarkeit sind der Schlüssel zu einer hohen Geschwindigkeit.

Bild 2: Parallelisierung und Skalierbarkeit sind der Schlüssel zu einer hohen Geschwindigkeit.

Tools, die Parallelisierung und Skalierbarkeit erlauben, sind sehr hilfreich. Im Vorfeld muss geprüft werden, ob die Quellen die angegebene Leseleistung bereit stellen und die Zwischen- und Zielsysteme die benötigte Verarbeitungsgeschwindigkeit leisten. In der Praxis gibt es oftmals böse Überraschungen, wenn Übernahmeprogramme nicht nur kurzfristig, also im Sekunden- oder Minutenbereich hohe Datenmengen schreiben möchten, sondern über längere Zeiträume und als Konsequenz in der Performance einbrechen. Die für das Zielsystem geplante Eingangsschleuse und alle Zwischenstufen müssen getestet werden. Die technischen Gegebenheiten sind ebenfalls ein Erfolgs-kriterium. Quellen oder Ziele in der Cloud werden über IP-Verbindungen angesprochen, Netzwerkverbindungen sollten im Vorfeld optimiert sein. Backup – Systeme können bei einer Migration, durch die redundante Verarbeitung der Daten, völlig überfordert werden. In der Praxis haben unbedacht aufgesetzte Migrationen durch die Rückkoppelung über diese Backup – Systeme ganze Produktionssysteme lahm gelegt.

Wir sprechen hier abstrakt über Gigabyte und Terabyte. Doch was bedeuten diese mittlerweile doch gängigen Abkürzungen genau? Wenn uns der Berater einen „Durchsatz“ der Jobs von 40.000 Sätzen pro Sekunde verspricht, habe ich dann genügend „Luft nach oben“ in meiner Zeitplanung? Lassen Sie mich das kurz ausführen: Es könnte eng werden. Beispiele gibt es viele. Abfüllanlagen in Raffinerien, die die Entnahmen aus dem Lager speichern. Oder Onlineplattformen, die die Klicks der potentiellen Kunden registrieren, ganz zu schweigen von „Customer-Experience-Stories“, die noch viel größere Datenmengen erzeugen. Nehmen wir also eine Tabelle aus einem dieser Beispiele mit einer Datensatzbreite von 1024 Bytes. Unterstellen wir nun, dass dieses System laufend Datensätze initiiert und die Gesamtzahl je Tag 3.000.000 erreicht. Pro Jahr sind das 1 Milliarde Datensätze, also eine Billion Bytes = 1 Terabyte. Bei einem oben angenommenen Durchsatz von 40.000 Datensätzen je Sekunde läuft dieser Job also locker 7 Stunden. 1 TB ist aber noch lange kein Grund auf eine BigData Plattform zu migrieren, oft handelt es sich um wesentlich größere Datenmengen, gerade im sensorischen Bereich der Datenerfassung. Kalkuliert man nun noch die weiter unten beschriebene Multi-Ebenen-Verarbeitung mit ein, müssen diese Systeme diese Daten auch noch zwischenspeichern, erneut lesen und an das endgültige Ziel transportieren.

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

Heterogene Systemlandschaften

Müssen Daten aus heterogenen Systemlandschaften migriert werden, sollte man an die diffizilen Abhängigkeiten der Daten und an die Priorisierung der federführenden Systeme denken. Hier ist auf jeden Fall der Ansatz der Multi-Ebenen-Verarbeitung (Staging Area) zu bedenken, der gewährleistet, dass die Daten auf dieser Ebene konsolidiert und im Fehlerfall von den sauberen Daten separiert werden können, um sie gegebenenfalls in einem nachgelagerten Prozess zu korrigieren und erneut zu laden oder endgültig zu verwerfen. Innerhalb von heterogenen Systemen stellt sich oftmals das Problem von überalterten Anwendungen und deren Datenbanken, die entweder schlecht dokumentiert oder deren nicht mehr zeitgemäßer Programmcode für die Entwickler unlesbar ist, manchmal ist auch beides gleichzeitig anzutreffen. Die Analysephase dauert umso länger und die Migration muss wesentlich sorgfältiger geprüft werden. Semantische Änderungen bis zur Unkenntlichkeit der Daten und deren spätere Nutzlosigkeit treten hierbei in der Praxis leider auf. Schlecht oder gar nicht dokumentierte Programmcodes und Datenbanken sind die Grundlage für Show-Stopper im Projekt. Im konkreten Fall einer Erweiterung der Business-Logik und einer Optimierung der Übernahme hatte ein Sammelsurium von ETL-Jobs in Verbindung mit nicht vorhandener Dokumentation dazu geführt, dass am Ende der gesamte Data-Warehouse – Cube einschließlich der ETL-Jobs neu erstellt werden musste.

Tücken der Technik

Hat man sich beispielsweise für eine sehr naheliegende In-Memory-Lösung entschieden, sollte man bedenken, dass die Arbeitsweise dieser Systeme oft auf „anhängen“ (Append) der Daten, statt auf „einfügen“ (Insert) oder gar „ändern“ (Update) basiert. Die eingangs beschriebenen heterogenen Systemlandschaften schaffen unter Umständen die Notwendigkeit, die Daten auf einer weiteren Staging-Area zu konsolidieren um sie letztendlich in einem geschlossenen Prozess in das Zielsystem laden zu können. Es gibt verschiedene Anbieter, die zwar von ihren professionellen Lösungen leben, aber auch Open-Source-Versionen anbieten, um in den Markt zu kommen und Verbreitung zu finden. Gerade beim Import der Daten in diese Systeme liegt aber oftmals der Unterschied zur kostenpflichtigen Version. In der Praxis darf man sich dann mit csv-Dateien begnügen, während die professionelle Variante eigene Daten-Lade-Prozessoren mit hoher Leistung in der Größenordnung von 10TB / Stunde anbietet.

Bei den Staging-Areas ist zu beachten, dass wenn diese auf relationalen Datenbanken basieren, die Indexierung entfernt und lediglich mit puren Insert-Statements gearbeitet wird. Die erforderlichen Indices sollten später wieder angelegt werden. Auf exzessives Journaling kann zugunsten der Geschwindigkeit zwar verzichtet, dafür muss aber ein Backup angefertigt werden.

Konsistenz der Daten

Die Bedeutung der Datenkonsistenz kann gar nicht genug betont werden. Hierbei geht es nicht nur um die Abwesenheit von offensichtlichen Fehlern. Es geht auch um semantische Veränderungen, die nicht durchgehend dokumentiert sind. Der Controller, der verschiedene Berichte aufgesetzt hat, wusste um diesen Umstand. Der Programmierer, der schon lange nicht mehr im Hause ist, auch. Aber der Leiter des Migrationsprojektes läuft gegen die Wand. Er hat Entwickler an der Hand, die genau ihren Job machen, die aktuelle Datenbank lesen können und alles scheinbar richtig codieren, aber trotzdem durchläuft der endgültige Test der Daten die Prüfungen nicht fehlerfrei.

Stellen Sie sich vor, das Berichtswesen in einer Firma basiert auf einem BI Werkzeug, das die Umstellung, also die semantische Veränderung einer Kennzahl historisch durch verschiedene Berichte abgebildet hat. Wenn hier nicht wirklich auf unterschiedliche Felder ausgewichen wird, mischen sich die Informationen bis zur Unbrauchbarkeit. Mögliche Änderungen im Datenbank-Format können eine zusätzliche Fehlerquelle darstellen. Ein Fall aus der Praxis beschrieb im Datenfluss ein mit <null> belegtes Feld mit „nicht verarbeitet“. Nach der Migration, die mit Java durchgeführt und dieses Feld als Integer (Ganzzahl) verarbeitet wurde, belegte der Migrationsjob das Feld als „default“ mit 0. Was als Migration, also der Überführung der Daten von einem zum anderen System begann, endete als echte Änderung der Information.

Die Wahl des Migrationszeitpunkts ist entscheidend.

Bild 3: Die Wahl des Migrationszeitpunkts ist entscheidend.

Es gibt auch Beispiele, die dazu führten, dass übernommene Daten nochmals aufwändig verarbeitet werden mussten, weil Schlüsselinformationen und Bezüge untereinander verloren gingen. Trackingdaten von Onlineportalen unterschiedlicher Quellen wurden nicht markiert, da sich diese Systeme historisch aufbauten. Zum Entstehungszeitpunkt wurde durch das ansteuern eines anderen Systems unterschieden, woher diese Informationen stammten, aber zum Migrationszeitpunkt wurden lediglich die vorhandenen Datensätze gespeichert, zusammen geführt und damit vermischt. Kennzahlen wurden somit verwässert und unbrauchbar. Da hilft auch eine hochperformante BigData Lösung nicht mehr. Möglicherweise ist hier auch eine komplexe bidirektionale Synchronisation hilfreich.

Auf keinen Fall sollten Live- und Migrationsdaten gemischt verarbeitet werden. Bitte für eine klare Abgrenzung sorgen, damit im Fehlerfall reagiert werden kann.

Früher war nicht immer alles besser

Gerade die Vielfalt an technologischen Lösungen lässt uns manches Mal verzweifeln und an frühere Zeiten denken, in denen alles „einfacher“ und „übersichtlicher“ war. Mitnichten hatte dieser Umstand nur Vorteile. Vieles ging nur sehr umständlich und langsam, musste durch mehrere Ebenen transportiert und Verbindungen zu anderen Systemen oft individuell erstellt werden. Die BigData Zeit hat auch viele Quasi-Standardisierungen hervor gebracht, die sich als Segen herausstellten. Doch ist auch die Vielfalt und Komplexität eine Herausforderung, die sich am besten mit den fünf „V“ meistern lässt: volume, velocity, variety, value, validity. Menge, Geschwindigkeit, Vielfalt an Datentypen und -quellen, Mehrwert, Datenqualität.

Jan BreitkreutzJan Breitkreutz, Senior Data Architect, Ancud IT-Beratung GmbH

 

Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.