Architektur von Plattformen für Daten und maschinelles Lernen

Kapitel 4. Ein Migrationsrahmen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Wenn du nicht gerade in einem Start-up arbeitest, ist es selten, dass du eine Datenplattform von Grund auf neu aufbaust. Stattdessen baust du eine neue Datenplattform auf, indem du Dinge aus Altsystemen in sie migrierst. In diesem Kapitel wollen wir uns den Migrationsprozess ansehen- all die Dinge, die du tun solltest, wenn du dich auf den Weg zu einer neuen Datenplattform machst. Zunächst stellen wir ein konzeptionelles Modell und einen möglichen Rahmen vor, dem du bei der Modernisierung der Datenplattform folgen solltest. Dann gehen wir darauf ein, wie ein Unternehmen die Gesamtkosten der Lösung abschätzen kann. Wir werden erörtern, wie sichergestellt werden kann, dass Sicherheit und Data Governance auch während der Migration gewährleistet sind. Schließlich werden wir die Schema-, Daten- und Pipeline-Migration besprechen. Außerdem erfährst du, welche Möglichkeiten es gibt, um regionale Kapazitäts-, Netzwerk- und Datentransferbeschränkungen zu umgehen.

Daten-Workflows modernisieren

Bevor du mit der Erstellung eines Migrationsplans beginnst, solltest du eine umfassende Vorstellung davon haben, warum du die Migration durchführst und in welche Richtung du migrierst.

Ganzheitliche Sicht

Die Transformation der Datenmodernisierung sollte ganzheitlich betrachtet werden. Aus der Vogelperspektive betrachtet, können wir drei Hauptpfeiler erkennen:

Geschäftsergebnisse

Konzentriere dich auf die Arbeitsabläufe, die du modernisierst, und ermittle die Geschäftsergebnisse, die diese Arbeitsabläufe bewirken. Das ist wichtig, um zu erkennen, wo die Lücken sind und wo die Chancen liegen. Bevor du technologische Entscheidungen triffst, solltest du die Migration auf Anwendungsfälle beschränken, die mit den von der Unternehmensleitung festgelegten Geschäftszielen übereinstimmen (in der Regel über einen Zeithorizont von zwei bis drei Jahren).

Stakeholder

Bestimme die Personen oder Rollen (einige dieser Teams gibt es vielleicht noch nicht), die potenziell Zugang zu den Daten erhalten werden. Dein Ziel bei der Datenmodernisierung ist es, den Zugang zu den Daten zu demokratisieren. Deshalb müssen sich diese Teams mit den Daten vertraut machen und die Tools (SQL, Python, Dashboards) beherrschen, die sie im Rahmen der Datenmodernisierung verwenden sollen.

Technologie

Du musst Datenarchitektur, -modellierung, -speicherung, -sicherheit, -integration, -bedienbarkeit, -dokumentation, -referenzdaten, -qualität und -governance in Abstimmung mit der Geschäftsstrategie und den Fähigkeiten des Teams definieren, implementieren und einsetzen.

Achte darauf, dass du die Migration nicht als reines IT- oder Data-Science-Projekt betrachtest, sondern als eines, bei dem der technologische Aspekt nur eine Teilmenge einer größeren organisatorischen Veränderung ist.

Arbeitsabläufe modernisieren

Wenn du über ein Modernisierungsprogramm nachdenkst, denkst du natürlich an die Probleme, die du mit den vorhandenen Tools hast. Du beschließt, dass du deine Datenbank aktualisieren und sie global konsistent und skalierbar machen willst, also modernisierst du sie auf Spanner oder CockroachDB. Du entscheidest, dass du deine Streaming-Engine aufrüsten willst, um sie stabiler und einfacher zu machen, und entscheidest dich für Flink oder Dataflow. Du beschließt, dass du keine Lust mehr hast, Cluster und Abfragen auf deinem DWH zu optimieren, und modernisierst auf BigQuery oder Snowflake.

Das sind alles großartige Schritte. Du solltest auf jeden Fall auf benutzerfreundlichere, leichter zu bedienende, skalierbarere und widerstandsfähigere Tools umsteigen, wann immer du kannst. Wenn du jedoch nur die gleichen Tools wechselst, wirst du am Ende nur schrittweise Verbesserungen erzielen. Solche Upgrades führen nicht zu grundlegenden Veränderungen.

Um diese Falle zu vermeiden, solltest du dich zu Beginn deiner Datenmodernisierungsreise dazu zwingen, an Workflows und nicht an Technologien zu denken. Was bedeutet es, einen Daten-Workflow zu modernisieren? Denke an die allgemeine Aufgabe, die der Endnutzer erledigen will. Vielleicht will er besonders wertvolle Kunden identifizieren. Vielleicht will er eine Marketingkampagne durchführen. Vielleicht will er Betrug aufdecken. Überlege dir nun, wie du diesen Arbeitsablauf als Ganzes und so kostengünstig und einfach wie möglich umsetzen kannst.

Als Nächstes gehst du den Arbeitsablauf von Grund auf an. Um hochwertige Kunden zu identifizieren, musst du die Gesamteinkäufe eines jeden Nutzers aus den bisherigen Transaktionen berechnen. Finde heraus, wie du einen solchen Arbeitsablauf mit deinen modernen Tools umsetzen kannst. Setze dabei stark auf Automatisierung:

Automatisierte Datenübernahme

Schreiben Sie keine maßgeschneiderten ELT-Pipelines . Verwende Standard-ELT-Tools wie Datastream oder Fivetran, um die Daten in einem DWH zu landen. Es ist viel einfacher, die Daten im laufenden Betrieb umzuwandeln und gemeinsame Umwandlungen in materialisierten Ansichten zu erfassen, als ETL-Pipelines für jede mögliche nachgelagerte Aufgabe zu schreiben. Außerdem exportieren viele SaaS-Systeme automatisch nach S3, Snowflake, BigQuery usw.

Streaming standardmäßig

Lege deine Daten in einem System ab, das Batch- und Streaming-Speicherung kombiniert, damit alle SQL-Abfragen die aktuellsten Daten widerspiegeln (mit einer gewissen Latenz). Das Gleiche gilt für alle Analysen - suche nach Datenverarbeitungsprogrammen, die sowohl Streaming als auch Batch mit demselben Framework verarbeiten. In unserem Beispiel kann die Berechnung des Lebenszeitwerts eine SQL-Abfrage sein. Um sie wiederzuverwenden, solltest du sie in eine materialisierte Ansicht umwandeln. Auf diese Weise erfolgen alle Berechnungen automatisch und die Daten sind immer auf dem neuesten Stand.

Automatische Skalierung

Jedes System, das von dir erwartet, dass du die Anzahl der Maschinen, Lagergrößen usw. vorgibst, ist ein System, bei dem du dich auf das System konzentrieren musst und nicht auf die zu erledigende Arbeit. Du möchtest, dass die Skalierung automatisch erfolgt, damit du dich auf den Arbeitsablauf und nicht auf das Werkzeug konzentrieren kannst.

Umformulierung von Abfragen, verschmolzene Phasen, etc.

Du willst dich auf die zu erledigende Aufgabe konzentrieren und sie in verständliche Schritte zerlegen können. Du willst keine Abfragen optimieren, neu schreiben, Transformationen verschmelzen, usw. Lass die modernen, in den Data Stack integrierten Optimierer diese Dinge erledigen.

Bewertung

Du willst keine maßgeschneiderten Datenverarbeitungspipelines schreiben, um die Leistung von ML-Modellen zu bewerten. Du möchtest lediglich in der Lage sein, Abtastraten und Auswertungsabfragen festzulegen und über Feature-Drift, Daten-Drift und Modell-Drift informiert zu werden. All diese Funktionen sollten in die bereitgestellten Endpunkte integriert sein.

Umschulung

Wenn du eine Modellabweichung feststellst, solltest du das Modell in 9 von 10 Fällen neu trainieren. Auch das sollte automatisiert werden. Moderne ML-Pipelines bieten einen aufrufbaren Hook, den du direkt mit deiner automatisierten Auswertungspipeline verknüpfen kannst, um auch das Retraining zu automatisieren.

Kontinuierliche Ausbildung

Die Modelldrift ist nicht der einzige Grund, warum du ein neues Training durchführen musst. Du willst das Modell neu trainieren, wenn du viel mehr Daten hast. Zum Beispiel, wenn neue Daten in einer Speicherung landen. Oder wenn du einen Code-Check-in hast. Auch das kann automatisiert werden.

Wenn du einen vollautomatisierten Daten-Workflow brauchst, hast du es mit einem ziemlich templated Setup zu tun, das aus einem Connector, einem DWH und ML-Pipelines besteht. All diese Komponenten können serverlos betrieben werden, sodass du dich im Grunde nur um die Konfiguration und nicht um das Cluster-Management kümmern musst.

Natürlich wirst du ein paar spezielle Codes schreiben:

• Datenaufbereitung in SQL

• ML-Modelle in einem Framework wie TensorFlow, PyTorch oder Langchain

• Bewertungsabfrage für kontinuierliche Bewertung

Die Tatsache, dass wir uns auf eine so einfache Einrichtung für jeden Workflow beschränken können, erklärt, warum eine integrierte Daten- und KI-Plattform so wichtig ist.

Den Arbeitsablauf selbst verändern

Du kannst den Workflow selbst viel effizienter gestalten, indem du ihn mit dem modernen Data Stack automatisierst. Doch bevor du das tust, solltest du dir eine wichtige Frage stellen: "Muss dieser Workflow von einem Data Engineer vorberechnet werden?"

Denn das ist es, was du tust, wenn du eine Datenpipeline aufbaust - du rechnest vor. Es ist eine Optimierung, nichts weiter.

Wenn du den Workflow so gestalten kannst, dass er sich selbst bedient und ad hoc abläuft, musst du ihn in vielen Fällen nicht mit Ressourcen aus der Datentechnik aufbauen. Weil so viel automatisiert ist, kannst du jede beliebige Aggregation (nicht nur den Lebenszeitwert) für den gesamten historischen Transaktionsdatensatz durchführen. Verschiebe die Berechnung des Lebenszeitwerts in eine deklarative semantische Schicht, in die deine Nutzer/innen ihre eigenen Berechnungen einfügen können. Das kannst du z. B. mit einem Tool wie Looker tun. Wenn du das geschafft hast, profitierst du von einheitlichen KPIs in der gesamten Organisation und von Nutzern, die in der Lage sind, eine Bibliothek mit gemeinsamen Kennzahlen zu erstellen. Die Fähigkeit, neue Kennzahlen zu erstellen, liegt nun bei den Geschäftsteams, wo diese Fähigkeit in erster Linie hingehört.

Ein vierstufiger Migrationsrahmen

Du kannst den standardisierten Ansatz auf viele Situationen anwenden, auf die du beim Aufbau deiner Datenplattform stoßen könntest. Dieser Ansatz ist größtenteils unabhängig von der Größe und Tiefe der Datenplattform - wir haben ihn sowohl bei der Modernisierung des DWH eines kleinen Unternehmens als auch bei der Entwicklung einer brandneuen Datenarchitektur für ein multinationales Unternehmen angewendet.

Dieser Ansatz basiert auf den vier Hauptschritten, die in Abbildung 4-1 dargestellt sind:

1. Vorbereiten und entdecken.

Alle Beteiligten sollten eine erste Analyse durchführen, um die Liste der zu migrierenden Arbeitslasten und die aktuellen Probleme zu ermitteln (z. B. mangelnde Skalierbarkeit, nicht aktualisierbare Prozess-Engine, unerwünschte Abhängigkeiten usw.).

2. Beurteile und plane.

Bewerte die in der vorherigen Phase gesammelten Informationen, lege die wichtigsten Erfolgsmaßstäbe fest und plane die Migration der einzelnen Komponenten.

3. Ausführen.

Entscheide für jeden identifizierten Anwendungsfall, ob er stillgelegt, vollständig migriert (Daten, Schema, nachgelagerte und vorgelagerte Anwendungen) oder ausgelagert werden soll (indem nachgelagerte Anwendungen auf eine andere Quelle migriert werden). Teste und validiere anschließend jede durchgeführte Migration.

4. Optimieren.

Wenn der Prozess einmal begonnen hat, kann er durch kontinuierliche Iterationen erweitert und verbessert werden. Ein erster Modernisierungsschritt könnte sich nur auf die Kernfunktionen konzentrieren.

Abbildung 4-1. Vierstufiger Migrationsrahmen

Gehen wir jeden dieser Schritte der Reihe nach durch.

Vorbereiten und entdecken

Der erste Schritt ist die Vorbereitung von und discover. Dazu gehört es, den Umfang der Migration festzulegen und alle Informationen über die zu migrierenden Arbeitslasten/Nutzungsfälle zu sammeln. Dazu gehört auch die Analyse einer Vielzahl von Informationen, die von verschiedenen Interessengruppen aus dem gesamten Unternehmen stammen, z. B. aus den Bereichen Wirtschaft, Finanzen und IT. Bitte diese Interessengruppen um:

• Listen Sie alle Anwendungsfälle und Arbeitslasten mit den entsprechenden Prioritäten auf, die für die Migration relevant sind. Achte darauf, dass sie Compliance-Anforderungen, empfindliche Latenzzeiten und andere relevante Informationen enthalten.

• Erkläre die erwarteten Vorteile, die du mit dem neuen System erzielen kannst (z. B. Abfrageleistung, Datenmenge, Streaming-Funktionen usw.).

• Schlage auf dem Markt verfügbare Lösungen vor, die den Bedürfnissen des Unternehmens entsprechen könnten.

• Führe eine erste TCO-Analyse durch, um den Wert der Migration abzuschätzen.

• Ermitteln Sie den Bedarf an Ausbildung und Rekrutierung, um eine fähige Belegschaft aufzubauen.

Du kannst Fragebögen verwenden, um diese Erkenntnisse von Anwendungseignern, Dateneignern und ausgewählten Endnutzern zu sammeln.

Bewerten und planen

Der zweite Schritt besteht darin, die gesammelten Daten zu bewerten und alle Aktivitäten zu planen, die zur Erreichung der festgelegten Ziele durchgeführt werden müssen. Dies beinhaltet:

1. Bewertung des aktuellen Zustands

Analysiere den aktuellen Technologie-Footprint für jede Anwendung, jeden Workflow oder jedes Tool, indem du Serverkonfigurationen, Protokolle, Job-Aktivitäten, Datenfluss-Mapping, Volumetrics, Abfragen und Cluster sammelst und analysierst. Je größer der Legacy-Footprint ist, desto zeitaufwändiger und fehleranfälliger kann diese Aufgabe werden. Deshalb solltest du dich nach Tools umsehen (z. B. SnowConvert, CompilerWorks, AWS Schema Conversion Tool, Azure Database Migration Service, Datametica Raven usw.), die den gesamten Prozess von der Datenerfassung bis zur Analyse und Empfehlung automatisieren können. Diese Tools können eine Aufschlüsselung der Arbeitslast, ein Mapping der Abhängigkeiten, eine Komplexitätsanalyse, eine Ressourcenauslastung, eine Kapazitätsanalyse, eine SLA-Analyse, eine durchgängige Datenkette und verschiedene Optimierungsempfehlungen liefern.

2. Kategorisierung der Arbeitsbelastung

Nutze die Informationen, die mithilfe des Fragebogens im Schritt "Vorbereiten und Entdecken" gesammelt hat, zusammen mit den detaillierten Erkenntnissen aus der Bewertungsphase, um den Ansatz für alle identifizierten Arbeitsbelastungen in eine der folgenden Optionen einzuordnen und auszuwählen:

In Rente gehen

Das Arbeitspensum wird zunächst auf dem Gelände verbleiben und schließlich stillgelegt werden.

Behalte

Aus technischen Gründen (z. B. weil er auf dedizierter Hardware läuft) oder aus geschäftlichen Gründen wird der Workload vor Ort bleiben. Dies kann vorübergehend sein, bis der Arbeitsaufwand neu strukturiert werden kann, oder er wird in eine Colocation-Einrichtung verlagert, wenn die Rechenzentren geschlossen werden müssen und die Dienste nicht verlagert werden können.

Rehost

Der Arbeitsaufwand wird in die Cloud-Umgebung verlagert, wobei die Infrastruktur als Service (IaaS) genutzt wird. Dies wird oft als "Lift and Shift" bezeichnet.

Replatform

Die Arbeitslast (oder ein Teil davon) wird teilweise verändert, um die Leistung zu verbessern oder die Kosten zu senken, und dann in das IaaS verschoben; dies wird oft als "move and improve" bezeichnet. Optimiere nach einer Lift-and-Shift-Erfahrung, die in der Regel mit der Containerisierung beginnt.

Refactor

Die Arbeitslast (oder ein Teil davon) wird auf eine oder mehrere vollständig verwaltete Plattform-as-a-Service (PaaS)-Lösungen (z. B. BigQuery, Redshift, Synapse) in der Cloud verlagert.

Ersetze

Die Arbeitslast wird vollständig durch eine Standard- oder SaaS-Lösung eines Drittanbieters ersetzt.

Rebuild

Der Workload wird mithilfe von vollständig verwalteten Cloud-Lösungen komplett neu aufgebaut und von Grund auf neu implementiert. Hier überdenkst du deine Anwendung und planst, wie du das Beste aus den nativen Cloud-Diensten herausholen kannst.

3. Clustering der Arbeitslast

Cluster die Arbeitslasten, die nicht stillgelegt/neu aufgebaut werden, in eine Reihe von Gruppen auf der Grundlage ihres relativen Geschäftswerts und des für die Migration erforderlichen Aufwands. So kannst du eine Prioritätenliste erstellen, die du während der Migration befolgen kannst. Zum Beispiel:

• Gruppe 1: hoher Geschäftswert, geringer Aufwand für die Migration (Priorität 0 - schnelle Erfolge)

• Gruppe 2: hoher Geschäftswert, hoher Migrationsaufwand (Priorität 1)

• Gruppe 3: geringer Geschäftswert, geringer Aufwand für die Migration (Priorität 2)

• Gruppe 4: geringer Geschäftswert, hoher Migrationsaufwand (Priorität 3)

In Abbildung 4-2 siehst du ein Beispiel für eine Clusterisierung, bei der die Arbeitslasten anhand der beschriebenen Priorisierungskriterien in Gruppen eingeteilt wurden. In jeder Gruppe können die Arbeitslasten unterschiedliche Migrationsansätze haben.

Abbildung 4-2. Beispiel für die Kategorisierung und Clusterung von Workloads

Während dieses Prozesses empfehlen wir dir, dich an die folgenden Praktiken zu halten:

Mache den Prozess messbar.

Stelle sicher, dass die Stakeholder sich einig sind und die Ergebnisse der Modernisierung anhand einiger geschäftlicher KPIs bewerten können.

Beginne mit einem Minimum Viable Product (MVP) oder einem Proof of Concept (PoC).

Zerlege große Aufträge in kleinere Aufgaben und vergewissere dich, dass es für alle anstehenden Arbeiten Standardvorlagen gibt. Ist dies nicht der Fall, führe einen PoC durch und verwende ihn als Vorlage für die Zukunft. Halte Ausschau nach Quick Wins (Priority 0 Workloads), die nicht nur als Beispiel für andere Umstellungen genutzt werden können, sondern auch, um der Leitung zu zeigen, welche Auswirkungen eine solche Modernisierung haben kann.

Schätze die Gesamtzeit, die du für die Durchführung aller Aktivitäten brauchst.

Erstelle einen ganzheitlichen Projektplan (ggf. in Zusammenarbeit mit Anbietern oder Beratern), um den Zeit-, Kosten- und Personalbedarf für die Umstellung der Arbeitsbelastung festzulegen.

Kommuniziere zu viel an Meilensteinen.

Vergewissere dich, dass die Beteiligten den Plan verstehen, wie lange er dauern wird und welches die wichtigsten Komponenten sind. Achte darauf, dass du mit abgeschlossenen Cloud-Projekten, die die Menschen im Unternehmen tatsächlich nutzen können, einen Mehrwert lieferst und Vertrauen schaffst. Versuche, Meilensteine festzulegen und versende eine Ad-hoc-Mitteilung, in der du die Details der geleisteten Arbeit zusammenfasst.

Nachdem du nun weißt, welche Aufgaben du zur Vorbereitung deiner nächsten Migration erledigen musst, schauen wir uns an, wie du dabei vorgehen solltest .

Ausführen

Für jede Arbeitslast hast du jetzt einen Plan. Du weißt, was migriert werden soll (der gesamte Workload oder nur ein Teil davon), wohin er migriert werden soll (IaaS, PaaS oder SaaS), wie du migrieren willst (Rehosting, Replatform, Rebuild usw.), wie du den Erfolg messen willst, welche Templates du verwenden willst, wie viel Zeit du dafür brauchst und welche Meilensteine du erreichen willst. Um den Plan in die Tat umzusetzen, empfehlen wir dir, eine Landing Zone einzurichten, dorthin zu migrieren und die migrierten Aufgaben zu validieren.

Landezone

Als Erstes musst du die sogenannte Landing Zone erstellen , also dieZielumgebung, in der alle Arbeitslasten untergebracht werden sollen. Dieser Vorgang kann je nach deiner aktuellen Konfiguration unterschiedlich komplex sein, aber das Mindeste, was du tun musst, ist:

• Definiere das Zielprojekt und die zugehörige Organisation (z. B. die Google Cloud-Organisationshierarchie)

• eine neue Identitätsmanagementlösung einrichten oder eine bestehende Lösung oder die eines Drittanbieters integrieren (z. B. Azure Active Directory oder Okta)

• Konfiguriere die Autorisierungs- (z.B. AWS IAM) und Auditing-Systeme (z.B. Azure Security Logging und Auditing)

• Definieren und Einrichten der Netzwerktopologie und der zugehörigen Konfiguration

Sobald die Landezone fertig ist, ist es Zeit, mit der Migration zu beginnen.

Migrieren

Im Allgemeinen es ratsam, eine Migration in mehrere Phasen oder Iterationen aufzuteilen, es sei denn, die Zahl der zu migrierenden Workloads ist sehr gering. Auf diese Weise kannst du Erfahrung und Vertrauen in die Vorgehensweise und den Umgang mit Herausforderungen und Fehlern gewinnen, während du jeweils eine Teilmenge der Arbeitslasten migrierst.

Für jedes Arbeitspensum musst du eventuell etwas beachten:

Schema- und Datenmigration

Je nach Anwendungsfall musst du vielleicht das Datenmodell übersetzen oder die Daten einfach übertragen.

Transpile abfragen

In manchen Fällen musst du Abfragen von deinem Quellsystem in das Zielsystem übersetzen. Wenn das Zielsystem nicht alle Erweiterungen unterstützt, musst du die Abfragen eventuell umstrukturieren. Du kannst Tools wie Datametica Raven oder generative KI nutzen, um den manuellen Aufwand zu reduzieren.

Migration von Datenpipelines

Datenpipelines bilden den zentralen Teil eines Daten-Workloads, der die Daten für die Analyse vorbereitet. In "Schema-, Pipeline- und Datenmigration" werden wir uns mögliche Ansätze für solche Migrationen ansehen .

Migration von Geschäftsanwendungen

Sobald du die Daten migriert hast, musst du die Anwendungen migrieren, mit denen die Benutzer mit den Daten interagieren können.

Leistungsoptimierung

Wenn der migrierte Workload nicht die erwartete Leistung erbringt, musst du eine Fehlersuche durchführen und das Problem beheben. Vielleicht wurde die Ziellösung nicht richtig konfiguriert, das von dir definierte Datenmodell erlaubt es dir nicht, alle Möglichkeiten der Zielplattform zu nutzen, oder es gibt ein Problem beim Transpilierungsprozess.

Es ist wichtig, Infrastruktur-als-Code-Tools wie Ansible oder Terraform zu verwenden, da sie die Verwaltung der Verteilungsinfrastruktur so weit wie möglich automatisieren und die Tests und die Ausführung jeder Iteration beschleunigen können.

Validiere

Sobald die Arbeitslast migriert wurde, musst du überprüfen, ob alles erfolgreich abgeschlossen wurde. Überprüfe, ob die Leistung deines Workloads, die laufenden Kosten, die Zeit für den Datenzugriff usw. mit den von dir festgelegten KPIs übereinstimmen. Überprüfe, ob alle Ergebnisse, die du erhältst, deinen Erwartungen entsprechen (z. B. ob die Abfrageergebnisse dieselben sind wie in der alten Umgebung). Wenn du sicher bist, dass die Ergebnisse mit deinen Anforderungen übereinstimmen, ist es an der Zeit, zum zweiten Anwendungsfall überzugehen, und dann zum dritten, bis du alles migriert hast. Wenn möglich, parallelisiere spätere Iterationen, um den Gesamtprozess zu beschleunigen.

Es ist immer eine gute Idee, am Ende jedes Arbeitsaufwands eventuelle Probleme zu notieren und die Zeit zu notieren, die benötigt wurde, um alle Aktivitäten und die damit verbundenen Lektionen zu erledigen, um den Prozess in den nachfolgenden Arbeitsaufwänden zu verbessern.

Optimiere

Der letzte Schritt des Frameworks ist die Optimierung. Hier konzentrierst du dich nicht auf die Leistung jeder einzelnen migrierten Komponente. Stattdessen betrachtest du das neue System als Ganzes und identifizierst mögliche neue Anwendungsfälle, die du einführen kannst, um es noch flexibler und leistungsfähiger zu machen. Du solltest darüber nachdenken, was dir die Migration gebracht hat (z. B. unbegrenzte Skalierbarkeit, verbesserte Sicherheit, mehr Transparenz usw.) und was du als nächsten Schritt tun könntest (z. B. die Datenerfassung auf die Kanten ausweiten, bessere Synergien mit Zulieferern entwickeln, mit der Monetarisierung der Daten beginnen usw.). Du kannst von den Informationen ausgehen, die du im Schritt "Vorbereiten und Entdecken" gesammelt hast, herausfinden, wo du dich auf deiner idealen Reise befindest, und über weitere nächste Schritte nachdenken. Es ist eine unendliche Geschichte, denn Innovation schläft nicht, genau wie die Wirtschaft, und sie wird Organisationen helfen, ihre Daten immer besser zu verstehen und zu nutzen.

Jetzt, da du besser verstehst, wie du eine Migration mithilfe des vierstufigen Migrationsrahmens angehen kannst, wollen wir uns damit beschäftigen, wie du die Gesamtkosten der Lösung abschätzen kannst.

Schätzung der Gesamtkosten der Lösung

Du hast soeben einen allgemeinen Migrationsrahmen gesehen, der Unternehmen dabei helfen kann, die Aktivitäten zu definieren, die sie zur Modernisierung einer Datenplattform durchführen müssen. Die erste Frage, die der CTO, der CEO oder der CFO vielleicht stellt, ist: "Wie hoch sind die Gesamtkosten, die wir einplanen müssen?" In diesem Abschnitt gehen wir darauf ein, wie Unternehmen im Allgemeinen an diese Herausforderung herangehen und wie sie ihre Arbeit strukturieren, um Angebote von Anbietern und Drittanbietern einzuholen. Behalte immer im Hinterkopf, dass es nicht nur um die Kosten der Technologie geht - es gibt auch immer Personal- und Prozesskosten, die berücksichtigt werden müssen.

Prüfung der bestehenden Infrastruktur

Wie du gesehen hast, beginnt alles mit einer Bewertung der bestehenden Umgebung. Wenn du keinen klaren Überblick über die derzeitige Umgebung hast, wird es dir schwer fallen, die Preise für deine nächste moderne Datenplattform richtig einzuschätzen. Diese Aktivität kann auf drei Arten durchgeführt werden:

Manuell durch das interne IT/Infrastrukturteam

Viele Unternehmen unterhalten eine Konfigurationsmanagement-Datenbank (CMDB), bei der es sich um eine Datei oder eine Standarddatenbank handeln kann, die alle wichtigen Informationen über die im Unternehmen verwendeten Hardware- und Softwarekomponenten enthält. Sie ist eine Art Momentaufnahme dessen, was derzeit im Unternehmen läuft, sowie der zugrundeliegenden Infrastruktur und zeigt sogar die Beziehungen zwischen den Komponenten auf. CMDBs können einen besseren Überblick über die Betriebskosten aller Anwendungen geben und dabei helfen, unnötige oder überflüssige Ressourcen abzuschalten.

Automatisch durch das interne IT/Infrastrukturteam

Das Ziel ist genau dasselbe wie im vorherigen Punkt beschrieben, aber mit dem Ziel, Software zu nutzen, die dabei hilft, automatisch Informationen zu sammeln (Daten über die Hardware, die auf den Servern laufenden Anwendungen, die Beziehungen zwischen den Systemen usw.). Solche Tools (z. B. StratoZone, Cloudamize, CloudPhysics usw.) machen in der Regel Vorschläge für die gängigsten Ziel-Cloud-Hyperscaler (z. B. AWS, Google Cloud und Azure), wie z. B. die Größe der Maschinen und Optimierungsoptionen (z. B. wie viele Stunden pro Tag ein System in Betrieb sein sollte, um seine Aufgabe zu erfüllen).

Einsatz eines Drittanbieters

Beratungsunternehmen und Cloud-Anbieter verfügen über erfahrene Mitarbeiter und Automatisierungstools, um alle Aktivitäten zur Erstellung der CMDB und der in den ersten beiden Optionen beschriebenen detaillierten Berichte durchzuführen. Das empfehlen wir, wenn dein Unternehmen IT-Projekte normalerweise an Beratungsunternehmen auslagert.

Anforderung von Informationen/Vorschlag und Angebot

Das ist zwar die einzige Migration, die du durchführen darfst, und du musst es daher nach und nach lernen, aber Beratungsunternehmen verdienen damit ihren Lebensunterhalt und sind in der Regel viel effizienter bei der Abwicklung von Migrationsprojekten. Vergewissere dich natürlich, dass das Team, das dir zugewiesen wird, über die nötige Erfahrung verfügt. Manche SIs führen sogar Bewertungen durch und erstellen Kostenvoranschläge als Investition, wenn sie eine zukünftige Chance sehen.

Den besten Partner oder Anbieter für die Modernisierung zu finden, kann eine entmutigende Aufgabe sein. Es gibt viele Variablen zu berücksichtigen (das Wissen, die Fähigkeiten, die Kosten, die Erfahrung), und es kann unglaublich kompliziert werden, wenn es nicht rigoros durchgeführt wird. Aus diesem Grund nutzen Unternehmen in der Regel drei Arten von Fragebögen, um Informationen von potenziellen SIs zu sammeln:

Anfrage nach Informationen (RFI)

Der Fragebogen dient dazu, detaillierte Informationen über die Lösungen und Dienstleistungen von Anbietern/möglichen Partnern zu sammeln. Er hat einen pädagogischen Zweck.

Angebotsanfrage (RFP)

Fragebogen verwendet, um detaillierte Informationen darüber zu sammeln, wie Anbieter/Partner ihre Produkte und Dienstleistungen einsetzen, um ein bestimmtes Unternehmensproblem zu lösen (in diesem Fall die Implementierung der modernen Datenplattform). Er dient dazu, die Ergebnisse zu vergleichen.

Angebotsanforderung (RFQ)

Fragebogen wird verwendet, um detaillierte Informationen über die Preise verschiedener Anbieter/ möglicher Partner auf der Grundlage spezifischer Anforderungen zu sammeln. Er dient dazu, die Preise zu quantifizieren und zu standardisieren, um zukünftige Vergleiche zu erleichtern.

Wahrscheinlich gibt es in deinem Unternehmen Richtlinien und Templates, wie man das macht. Sprich mit deiner Rechts- oder Beschaffungsabteilung. Andernfalls kannst du einen Anbieter bitten, dir zu zeigen, was er üblicherweise verwendet.

Sobald du alle Antworten von allen Anbietern/potentiellen Partnern erhalten hast, solltest du alle Informationen haben, um den besten Weg zu wählen. In manchen Fällen, vor allem wenn das zu lösende Problem sehr unscharf sein kann (z.B. bei Echtzeitanalysen, die selbst an einem einzigen Tag mehrere Spitzen aufweisen können), ist es selbst für die Anbieter/potenziellen Partner schwierig, klare Angaben zu den Kosten zu machen. Deshalb bitten die Anbieter manchmal darum, an einem PoC oder MVP zu arbeiten, um ein besseres Verständnis dafür zu bekommen, wie die Lösung in einem realen Anwendungsszenario funktioniert, und um die Festlegung der endgültigen Preisgestaltung zu erleichtern.

Proof of Concept/Minimum Viable Product

Das Design und die Entwicklung einer neuen Datenplattform kann eine Herausforderung sein, denn die meisten Unternehmen wollen mit der Migration auf eine neue Datenplattform mehr erreichen als eine einfache Umstellung - sie wollen neue Funktionen und Möglichkeiten hinzufügen, die in der alten Welt nicht verfügbar waren. Da dies für sie neu ist, haben die Unternehmen (und damit auch die Anbieter) möglicherweise kein vollständiges Verständnis für das endgültige Verhalten und vor allem für die endgültigen Kosten, die die Plattform verursachen wird.

Um diese Herausforderung zu meistern, bitten Organisationen die ausgewählten Anbieter oder potenziellen Partner in der Regel, als ersten Schritt nach der Analyse der RFP-Antwort ein erstes Mock-up der endgültigen Lösung (oder eine echte funktionierende Lösung mit eingeschränkter Funktionalität) zu implementieren. Mit diesem Mock-up können die Interessengruppen erfahren, wie sich die endgültige Lösung verhalten wird, damit sie feststellen können, ob Änderungen am Rahmenplan erforderlich sind. Das Mock-up macht auch die Kostenschätzung viel einfacher, obwohl es wichtig ist zu beachten, dass wir immer von Schätzungen und nicht von konkreten Preisen sprechen. Es ist praktisch unmöglich, eine klare und endgültige Preisgestaltung zu haben, wenn du ein Cloud-Modell einführst, vor allem wenn du die Elastizität nutzen willst. Elastizität, einer der Hauptvorteile der Cloud, kann nur in der Produktion erlebt werden.

Es gibt drei Möglichkeiten, sich der Idee des Mock-ups zu nähern:

Proof of Concept

Baue einen kleinen Teil der Lösung, um die Machbarkeit, Integrierbarkeit, Nutzbarkeit und mögliche Schwachstellen zu überprüfen. Das kann helfen, den endgültigen Preis abzuschätzen. Das Ziel ist es nicht, jede einzelne Funktion der Plattform anzufassen, sondern Dinge zu überprüfen, die möglicherweise neu entwickelt werden müssen. Bei der Arbeit mit Streaming-Pipelines ist es z. B. eine gute Praxis, einen PoC zu erstellen, indem du die zu verarbeitende Datenmenge zufällig variierst. So kannst du sehen, wie sich das System skalieren lässt, und du erhältst bessere Daten, um die endgültigen Produktionskosten abzuschätzen.

Minimum Viable Product

Das Ziel eines MVP ist es, ein Produkt mit einem sehr gut definierten Umfang zu entwickeln, bei dem alle Funktionen implementiert sind und das wie ein echtes, vollständiges Produkt funktioniert, das in einer Produktionsumgebung eingesetzt werden kann (z. B. ein Data Mart, der auf einem neuen DWH implementiert und mit einem neuen Business Intelligence-Tool verbunden ist, um einen sehr spezifischen Anwendungsfall zu lösen). Der Hauptvorteil von MVPs besteht darin, schnell Feedback von echten Nutzern zu erhalten, was dem Team hilft, das Produkt zu verbessern und bessere Schätzungen abzugeben.

Hybrid

Zunächst wird das Team einen allgemeinen PoC mit einem breiteren Umfang, aber einer begrenzten Tiefe entwickeln (z. B. eine End-to-End-Datenpipeline, um Daten zu sammeln, die zum Trainieren eines ML-Algorithmus für die Bildklassifizierung benötigt werden), und dann, basierend auf den ersten Ergebnissen und der Kostenbewertung, wird sich der Schwerpunkt auf die Entwicklung eines MVP verlagern, das als erster Schritt zur Implementierung der vollständigen Lösung angesehen werden kann.

Nachdem du nun weißt, wie du die Kosten abschätzen kannst, wollen wir uns dem ersten Teil jeder Migration widmen - der Einrichtung von Sicherheit und Data Governance.

Sicherheit und Data Governance einrichten

Auch wenn das Eigentum und die Kontrolle über die Daten auf die Geschäftseinheiten übergehen, bleiben die Sicherheit und die Governance in den meisten Unternehmen ein zentrales Anliegen. Das liegt daran, dass die Definition von Rollen, die Sicherung von Daten und die Protokollierung von Aktivitäten einheitlich sein müssen. Ohne eine solche Einheitlichkeit ist es sehr schwierig, Vorschriften wie das "Recht auf Vergessenwerden" einzuhalten, nach dem ein Kunde verlangen kann, dass alle ihn betreffenden Daten gelöscht werden.

In diesem Abschnitt gehen wir darauf ein, welche Fähigkeiten in einem solchen zentralisierten Data Governance Framework vorhanden sein müssen. Dann gehen wir auf die Artefakte ein, die das zentrale Team pflegen muss und wie sie im Laufe des Lebenszyklus der Daten zusammenkommen.

Rahmenwerk

Es gibt drei Risikofaktoren, auf die Sicherheit und Governance abzielen:

Unbefugter Datenzugriff

Wenn du die Daten von in einer öffentlichen Cloud-Infrastruktur speicherst, musst du dich vor unbefugtem Zugriff auf sensible Daten schützen, egal ob es sich um vertrauliche Unternehmensdaten oder gesetzlich geschützte personenbezogene Daten handelt.

Einhaltung von Vorschriften

Gesetze wie die General Data Protection Regulation (GDPR) und Legal Entity Identifier (LEI) schränken den Ort, die Art und die Methoden der Datenanalyse ein.

Sichtbarkeit

Die Personen, die deine Organisation mit Daten versorgen, müssen wissen, welche Arten von Daten in der Organisation vorhanden sind, wer die Daten derzeit nutzt und wie sie genutzt werden. Das erfordert aktuelle Daten und einen funktionalen Katalog.

Angesichts dieser Risikofaktoren ist es notwendig, ein umfassendes Data-Governance-Rahmenwerk einzurichten, das den gesamten Lebenszyklus der Daten abdeckt: Dateneingabe, Katalogisierung, Speicherung, Aufbewahrung, gemeinsame Nutzung, Archivierung, Sicherung, Wiederherstellung, Verlustvermeidung und Löschung. Ein solcher Rahmen muss die folgenden Fähigkeiten haben:

Datenherkunft

Die Organisation muss in der Lage sein, Datenbestände zu identifizieren und die Transformationen aufzuzeichnen, die zur Erstellung der einzelnen Datenbestände angewendet wurden.

Datenklassifizierung

Wir müssen in der Lage sein, ein Profil von sensiblen Daten zu erstellen und sie zu klassifizieren, damit wir bestimmen können, welche Governance-Richtlinien und -Verfahren für jedes Datengut oder jeden Teil davon gelten müssen.

Datenkatalog

Wir müssen einen Datenkatalog pflegen, der strukturelle Metadaten, Abstammung und Klassifizierung enthält und das Suchen und Finden ermöglicht.

Datenqualitätsmanagement

Es muss einen Prozess zur Dokumentation, Überwachung und Berichterstattung der Datenqualität geben, damit vertrauenswürdige Daten für die Analyse zur Verfügung stehen.

Zugangsverwaltung

Dies funktioniert in der Regel mit Cloud IAM, um Rollen zu definieren, Zugriffsrechte festzulegen und Zugriffsschlüssel zu verwalten.

Rechnungsprüfung

Organisationen und autorisierte Personen aus anderen Organisationen, wie z.B. Aufsichtsbehörden, müssen in der Lage sein, Aktivitäten auf der gesetzlich vorgeschriebenen oder branchenüblichen granularen Ebene zu überwachen, zu prüfen und zu verfolgen.

Datenschutz

Es muss die Möglichkeit geben, Daten zu verschlüsseln, zu maskieren oder dauerhaft zu löschen.

Um Data Governance zu operationalisieren, musst du einen Rahmen schaffen, in dem diese Aktivitäten stattfinden können. Cloud-Tools wie Dataplex auf Google Cloud und Purview auf Azure bieten einheitliche Data-Governance-Lösungen zur Verwaltung von Datenbeständen, unabhängig davon, wo sich die Daten befinden (d.h. Single Cloud, Hybrid Cloud oder Multi-Cloud). Collibra und Informatica sind Cloud-agnostische Lösungen, die die Möglichkeit bieten, die Abstammung aufzuzeichnen, Daten zu klassifizieren usw.

Unserer Erfahrung nach kann jedes dieser Tools funktionieren, aber die harte Arbeit der Data Governance liegt nicht in dem Tool selbst, sondern in seiner Umsetzung. Es ist wichtig, ein Betriebsmodell - die Prozesse und Verfahren für Data Governance - sowie einen Rat einzurichten, der die verschiedenen Geschäftsteams für die Einhaltung dieser Prozesse verantwortlich macht. Der Rat muss auch für die Entwicklung von Taxonomien und Ontologien verantwortlich sein, damit im gesamten Unternehmen Konsistenz herrscht. Im Idealfall beteiligt sich dein Unternehmen an den Gremien für Industriestandards und hält sich an diese. In den besten Organisationen finden außerdem regelmäßig Schulungen und Trainings statt, um sicherzustellen, dass die Data-Governance-Praktiken befolgt werden.

Nachdem wir nun erörtert haben, welche Fähigkeiten in einem zentralisierten Data-Governance-Rahmen vorhanden sein müssen, wollen wir nun die Artefakte aufzählen, die das zentrale Team pflegen muss.

Artefakte

Um der Organisation die oben genannten Fähigkeiten zur Verfügung zu stellen, muss ein zentrales Data-Governance-Team die folgenden Artefakte pflegen:

Unternehmens-Wörterbuch

Das kann von einem einfachen Papierdokument bis hin zu einem Tool reichen, das bestimmte Richtlinien automatisiert (und durchsetzt). Das Unternehmenslexikon ist ein Repository für die von der Organisation verwendeten Informationstypen. Zum Beispiel ist der Code, der mit verschiedenen medizinischen Verfahren verbunden ist, oder die notwendigen Informationen, die zu jeder finanziellen Transaktion erfasst werden müssen, Teil des Unternehmenslexikons. Das zentrale Team könnte einen Validierungsdienst bereitstellen, um sicherzustellen, dass diese Bedingungen erfüllt sind. Ein einfaches Beispiel für ein Unternehmenslexikon, mit dem viele Leser/innen vertraut sind, sind die APIs zur Adressvalidierung und -standardisierung, die vom US Postal Service bereitgestellt werden. Diese APIs werden häufig von Unternehmen genutzt, um sicherzustellen, dass jede Adresse, die in einer Datenbank des Unternehmens gespeichert ist, in einer Standardform vorliegt.

Datenklassen

Die verschiedenen Informationstypen im Unternehmenslexikon können in Datenklassen gruppiert werden, und für jede Datenklasse können einheitliche Richtlinien festgelegt werden. So kann die Datenrichtlinie für Kundenadressen zum Beispiel vorsehen, dass die Postleitzahl für eine bestimmte Gruppe von Mitarbeitern sichtbar ist, während detailliertere Informationen nur für Mitarbeiter des Kundensupports sichtbar sind, die aktiv an einem Ticket für diesen Kunden arbeiten.

Politikbuch

Ein Richtlinienbuch listet die Datenklassen auf, die in der Organisation verwendet werden, wie jede Datenklasse verarbeitet wird, wie lange die Daten aufbewahrt werden, wo sie gespeichert werden dürfen, wie der Zugriff auf die Daten kontrolliert werden muss usw.

Richtlinien für Anwendungsfälle

Oft hängt die Richtlinie für eine Datenklasse vom Anwendungsfall ab. Ein einfaches Beispiel: Die Adresse eines Kunden kann von der Versandabteilung verwendet werden, die die Bestellung des Kunden ausführt, nicht aber von der Verkaufsabteilung. Die Anwendungsfälle können viel differenzierter sein: Die Adresse eines Kunden kann verwendet werden, um die Anzahl der Kunden in der Nähe eines bestimmten Geschäfts zu ermitteln, aber nicht, um festzustellen, ob ein bestimmter Kunde in der Nähe eines bestimmten Geschäfts ist.

Datenkatalog

Dies ist ein Werkzeug zur Verwaltung der strukturellen Metadaten, der Abstammung, der Datenqualität usw., die mit den Daten verbunden sind. Der Datenkatalog fungiert als effizientes Such- und Auffindungswerkzeug.

Neben den oben aufgeführten datenbezogenen Artefakten muss die zentrale Organisation auch eine SSO -Funktion unterhalten, um einen eindeutigen Authentifizierungsmechanismus für die gesamte Organisation bereitzustellen. Da der Zugang zu vielen automatisierten Diensten und APIs über Schlüssel erfolgt und diese Schlüssel nicht im Klartext gespeichert werden sollten, ist ein Schlüsselverwaltungsdienst oft eine zusätzliche Aufgabe des zentralen Teams.

Als Teil deiner Modernisierungsreise ist es wichtig, dass du mit diesen Artefakten anfängst und sie einführst, damit die Daten, wenn sie in die Cloud verschoben werden, Teil eines robusten Data Governance Frameworks werden. Verschiebe die Data Governance nicht bis nach der Cloud-Migration - Organisationen, die das tun, verlieren schnell die Kontrolle über ihre Daten.

Schauen wir uns nun an, wie die Fähigkeiten und Artefakte des Frameworks im Laufe des Lebens der Daten zusammenhängen.

Governance über die Lebensdauer der Daten

Data Governance bedeutet, Menschen, Prozesse und Technologien über die gesamte Lebensdauer der Daten zusammenzubringen.

Der Datenlebenszyklus besteht aus den folgenden Phasen:

1. Datenerstellung

Dies ist die Phase, in der du die Daten erstellst/erfasst. In dieser Phase solltest du sicherstellen, dass auch die Metadaten erfasst werden. Wenn du zum Beispiel Bilder aufnimmst, ist es wichtig, dass du auch die Zeiten und Orte der Fotos festhältst. Ähnlich wichtig ist es, bei der Erfassung eines Clickstreams die Sitzungs-ID des Nutzers, die Seite, auf der er sich befindet, das Layout der Seite (wenn sie für den Nutzer personalisiert ist) usw. zu notieren.

2. Datenverarbeitung

Wenn du die Daten erfasst hast, musst du sie normalerweise bereinigen, anreichern und in ein DWH laden. Es ist wichtig, diese Schritte als Teil einer Datenabfolge zu erfassen. Zusammen mit der Datenkette müssen auch die Qualitätsmerkmale der Daten erfasst werden.

3. Speicherung von Daten

In der Regel speicherst du sowohl Daten als auch Metadaten in einem persistenten Speicher wie einer Blob-Speicherung (S3, GCS, etc.), einer Datenbank (Postgres, Aurora, AlloyDB, etc.), einer Dokumenten-DB (DynamoDB, Spanner, Cosmos DB, etc.) oder einem DWH (BigQuery, Redshift, Snowflake, etc.). An diesem Punkt musst du die Sicherheitsanforderungen für Zeilen und Spalten festlegen und bestimmen, ob Felder vor dem Speichern verschlüsselt werden müssen. Dies ist die Phase, in der der Datenschutz im Mittelpunkt der Überlegungen eines Data Governance Teams steht.

4. Datenkatalog

Du musst die persistierten Daten in allen Phasen der Transformation in den Unternehmensdatenkatalog eingeben und Discovery-APIs für die Suche nach ihnen aktivieren. Es ist wichtig, die Daten zu dokumentieren und zu zeigen, wie sie genutzt werden können.

5. Datenarchiv

Du kannst ältere Daten aus Produktionsumgebungen veralten lassen. Wenn das der Fall ist, erinnere dich daran, den Katalog zu aktualisieren. Du musst beachten, ob eine solche Archivierung gesetzlich vorgeschrieben ist. Idealerweise solltest du die Archivierungsmethoden in Übereinstimmung mit den Richtlinien, die für die gesamte Datenklasse gelten, automatisieren.

6. Datenvernichtung

Du kannst alle Daten löschen, die die gesetzlich vorgeschriebene Aufbewahrungsfrist überschritten haben. Auch dies muss in den Unternehmensrichtlinien verankert sein.

Für jede dieser Phasen musst du Richtlinien zur Data Governance erstellen.

Diese Phasen werden von Menschen ausgeführt, die dafür bestimmte Zugriffsrechte benötigen. Ein und dieselbe Person kann an verschiedenen Stellen des Datenlebenszyklus unterschiedliche Aufgaben und Zuständigkeiten haben, daher ist es hilfreich, in "Hüten" statt in Rollen zu denken:

Legal

Stellt sicher, dass die Datennutzung mit den vertraglichen Anforderungen und den staatlichen/industriellen Vorschriften übereinstimmt.

Datenverwalter

Der Eigentümer der Daten, der die Richtlinien für ein bestimmtes Element der Daten festlegt

Daten Gouverneur

Legt Richtlinien für Datenklassen fest und identifiziert, zu welcher Klasse ein bestimmtes Datenelement gehört

Datenschutz-Zar

stellt sicher, dass die Anwendungsfälle keine personenbezogenen Daten preisgeben

Daten Benutzer

Typischerweise ein Datenanalyst oder Datenwissenschaftler, der die Daten nutzt, um Geschäftsentscheidungen zu treffen

Nachdem wir nun ein mögliches Migrations-, Sicherheits- und Governance-Rahmenwerk gesehen haben, wollen wir uns genauer ansehen, wie wir mit der Durchführung der Migration beginnen .

Schema, Pipeline und Datenmigration

In diesem Abschnitt werfen wir einen genaueren Blick auf die Muster, die du für Schema- und Pipeline-Migrationen nutzen kannst, und auf die Herausforderungen, die du bei der Übertragung der Daten bewältigen musst.

Schema-Migration

Wenn du damit beginnst, deine alte Anwendung in das neue Zielsystem zu übertragen, musst du möglicherweise dein Schema weiterentwickeln, um alle Funktionen des Zielsystems nutzen zu können. Es ist eine bewährte Methode, das Modell zunächst im Ist-Zustand in das Zielsystem zu migrieren und dabei die vorgelagerten (Datenquellen und Pipelines, die das System speisen) und nachgelagerten (die Skripte, Prozeduren und Geschäftsanwendungen, die zur Verarbeitung, Abfrage und Visualisierung der Daten verwendet werden) Prozesse zu verbinden und dann die Verarbeitungs-Engine der Zielumgebung zu nutzen, um alle Änderungen vorzunehmen. Dieser Ansatz stellt sicher, dass deine Lösung in der neuen Umgebung funktioniert, minimiert das Risiko von Ausfallzeiten und ermöglicht es dir, in einer zweiten Phase Änderungen vorzunehmen.

In der Regel kannst du hier das Fassadenmuster anwenden - eine Methode, um den nachgelagerten Prozessen eine Reihe von Ansichten zur Verfügung zu stellen, die die zugrunde liegenden Tabellen maskieren, um die Komplexität der eventuell erforderlichen Änderungen zu verbergen. Die Sichten können dann ein neues Schema beschreiben, das die Nutzung von Ad-hoc-Funktionen des Zielsystems erleichtert, ohne die vor- und nachgelagerten Prozesse zu stören, die dann durch diese Abstraktionsschicht "geschützt" sind. Kann dieser Ansatz nicht verfolgt werden, müssen die Daten übersetzt und konvertiert werden, bevor sie in das neue System übernommen werden. Diese Aktivitäten werden in der Regel von Datenumwandlungspipelines durchgeführt, die sich im Rahmen der Migration befinden.

Pipeline-Migration

Es gibt zwei verschiedene Strategien, die du bei der Migration von einem Altsystem in die Cloud verfolgen kannst:

Du verteilst die Arbeitslast.

In diesem Fall behältst du die vorgelagerten Datenpipelines bei, die dein Quellsystem füttern, und du legst eine inkrementelle Kopie der Daten im Zielsystem an. Schließlich aktualisierst du deine nachgelagerten Prozesse, um vom Zielsystem zu lesen . Dann kannst du den Offload mit dem nächsten Workload fortsetzen, bis du das Ende erreichst. Sobald die Migration abgeschlossen ist, kannst du mit der vollständigen Migration der Datenpipeline beginnen.

Du migrierst die Arbeitslast vollständig.

In diesem Fall musst du alles in das neue System migrieren (alles zusammen mit der Datenpipeline) und dann die entsprechenden Legacy-Tabellen verwerfen.

Die Daten, die den Workload speisen, müssen migriert werden. Sie können aus verschiedenen Datenquellen stammen und bestimmte Transformationen oder Joins erfordern, um sie nutzbar zu machen. Im Allgemeinen gibt es vier verschiedene Muster für Datenpipelines:

ETL

Alle Aktivitäten zur Umwandlung sowie die Datenerfassung und -eingabe werden von einem Ad-hoc-System durchgeführt, das über eine geeignete Infrastruktur und eine geeignete Programmiersprache verfügt (das Tool kann Schnittstellen mit den ohnehin verfügbaren Standardprogrammiersprachen programmierbar machen).

ELT

Ähnlich wie ETL, jedoch mit dem Vorbehalt, dass alle Transformationen von der Prozess-Engine durchgeführt werden, in die die Daten eingespeist werden (wie wir in den vorherigen Kapiteln gesehen haben, ist dies der bevorzugte Ansatz, wenn es um moderne Cloud-Lösungen geht).

Extrahieren und Laden (EL)

Dies ist der einfachste Fall, bei dem die Daten bereits vorbereitet sind und keine weiteren Transformationen erforderlich sind.

Datenerfassung ändern (CDC)

Dies ist ein Muster, das verwendet wird, um Datenänderungen im Quellsystem zu verfolgen und im Zielsystem widerzuspiegeln. Es arbeitet in der Regel mit einer ETL-Lösung zusammen, weil es den ursprünglichen Datensatz speichert, bevor es Änderungen im nachgelagerten Prozess vornimmt.

Wie du im vorherigen Abschnitt gesehen hast, kannst du für die Migration verschiedener Workloads unterschiedliche Ansätze wählen. Dieselbe Methodik kann auf die Datenpipelines angewendet werden:

In den Ruhestand gehen

Die Datenpipeline-Lösung wird nicht mehr verwendet, weil sie sich auf einen alten Anwendungsfall bezieht oder weil sie durch einen neuen ersetzt wurde.

Behalte

Die Datenpipelinelösung verbleibt im Altsystem, weil es möglicherweise bald ausgemustert wird, so dass es sich finanziell nicht lohnt, ein Migrationsprojekt in Angriff zu nehmen. Es kann auch sein, dass es Vorschriften gibt, die die Datenverschiebung außerhalb der Unternehmensgrenzen verhindern.

Rehost

Die Datenpipeline-Lösung wird aufgehoben und in die Cloud-Umgebung verlagert, indem das IaaS-Paradigma genutzt wird. In diesem Szenario werden keine großen Änderungen vorgenommen, außer auf der Verbindungsebene, wo möglicherweise eine Ad-hoc-Netzwerkkonfiguration (normalerweise ein virtuelles privates Netzwerk oder VPN) eingerichtet werden muss, um die Kommunikation zwischen der Cloud-Umgebung und der lokalen Welt zu ermöglichen. Wenn sich die vorgelagerten Prozesse außerhalb der Unternehmensgrenzen befinden (z. B. bei Drittanbietern, anderen Cloud-Umgebungen usw.), ist ein VPN möglicherweise nicht erforderlich, da die Kommunikation auf sichere Weise über andere Technologien, wie z. B. authentifizierte REST-APIs, erfolgen kann. Bevor du fortfährst, musst du dich beim Cloud-Anbieter vergewissern, dass das zugrunde liegende System keine technologischen Einschränkungen aufweist, die die korrekte Ausführung der Lösung verhindern, und eventuelle Lizenzbeschränkungen überprüfen.

Replatform

In diesem Szenario wird ein Teil der Datenpipeline-Lösung vor der Migration umgewandelt, um von den Funktionen der Cloud zu profitieren, wie z. B. einer PaaS-Datenbank oder Containertechnologie. Die Überlegungen zur Konnektivität, die in der Beschreibung des "Rehosting" hervorgehoben wurden, sind weiterhin gültig.

Refactor

Die Pipeline-Lösung wird auf eine oder mehrere vollständig verwaltete PaaS-Lösungen in der Cloud migriert (z. B. Amazon EMR, Azure HDInsight, Google Cloud Dataproc, Databricks). Bei diesem Ansatz ist es eine bewährte Methode, denselben iterativen Ansatz zu wählen, den du auch für die gesamte Migration anwendest:

• Bereite die Aufträge vor, entdecke sie und organisiere sie eventuell nach Komplexität.

• Planen und bewerten Sie das zu migrierende MVP.

• Führe die Migration durch und bewerte das Ergebnis anhand deiner festgelegten KPIs.

• Iteriere mit allen anderen Aufträgen bis zum Ende.

Die Überlegungen zur Konnektivität, die in der vorangegangenen Beschreibung des "rehost" hervorgehoben wurden, sind weiterhin gültig.

Ersetze

Die Pipeline-Lösung wird vollständig durch eine Standard- oder SaaS-Lösung eines Drittanbieters (z. B. Fivetran, Xplenty, Informatica usw.) ersetzt. Die Überlegungen zur Konnektivität, die im Abschnitt "Rehost" beschrieben sind, gelten weiterhin.

Rebuild

Die Pipeline-Lösung ist komplett neu aufgebaut und nutzt vollständig verwaltete Cloud-Lösungen (z. B. AWS Glue, Azure Data Factory, Google Cloud Dataflow). Die Überlegungen zur Konnektivität, die im Abschnitt "Rehost" beschrieben sind, gelten weiterhin.

Während der Migrationsphase, insbesondere bei der Integration mit dem Zielsystem, kann es vorkommen, dass deine Data-Pipeline-Lösung nicht sofort mit der identifizierten Ziel-Cloud-Lösung kompatibel ist. Du könntest einen Konnektor benötigen, in der Regel eine Senke, die die Kommunikation zwischen der Datenpipeline-Lösung (z. B. dem ETL-System) und der Zielumgebung ermöglicht. Wenn die Senke für diese Lösung nicht vorhanden ist, kannst du vielleicht eine Datei als Ausgabe des Prozesses erzeugen und die Daten dann im folgenden Schritt einlesen. Dieser Ansatz erhöht die Komplexität des Prozesses, ist aber eine praktikable Übergangslösung für den Notfall (während des Wartens auf einen Konnektor vom Anbieter).

Datenmigration

Jetzt, wo du dein neues Schema und deine Pipelines fertig hast, kannst du mit der Migration all deiner Daten beginnen. Du solltest dir vor allem Gedanken darüber machen, wie du mit der Datenübertragung umgehst. Vielleicht möchtest du all deine Daten in die Cloud migrieren, auch die verstaubten alten Bänder (vielleicht braucht ja eines Tages jemand diese Daten). Vielleicht musst du feststellen, dass eine einzige FTP-Verbindung über das Wochenende nicht ausreicht, um deine Aufgabe zu erfüllen.

Planung

Die Datenübertragung erfordert Planung. Du musst sie identifizieren und einbeziehen:

Technische Eigentümer

Personen, die dir Zugang zu den Ressourcen verschaffen können, die du für die Migration brauchst (z. B. Speicherung, IT, Netzwerk usw.).

Genehmiger

Personen, die dir alle Genehmigungen erteilen können, die du brauchst, um Zugang zu den Daten zu erhalten und mit der Migration zu beginnen (z. B. Dateneigentümer/innen, Rechtsberater/innen, Sicherheitsbeauftragte usw.).

Lieferung

Das Migrationsteam. Dabei kann es sich um interne Mitarbeiter handeln, falls vorhanden, oder um Mitarbeiter von externen Systemintegratoren.

Dann musst du so viele Informationen wie möglich sammeln, um genau zu wissen, was du tun musst, in welcher Reihenfolge (z.B. muss dein Migrationsteam auf eine bestimmte Netzwerkspeicherung zugreifen dürfen, die die zu migrierenden Daten enthält) und auf welche möglichen Hindernisse du stoßen könntest. Im Folgenden findest du eine Reihe von Fragen (ohne Anspruch auf Vollständigkeit), die du beantworten können solltest, bevor du fortfährst:

• Welche Datensätze musst du verschieben?

• Wo befinden sich die zugrunde liegenden Daten innerhalb der Organisation?

• Welche Datensätze darfst du verschieben?

• Gibt es eine bestimmte Vorschrift, die du beachten musst?

• Wo werden die Daten gespeichert (z. B. Objektspeicher oder DWH-Speicherung)?

• Was ist die Zielregion (z. B. Europa, Naher Osten und Afrika, Großbritannien, USA usw.)?

• Musst du vor der Übertragung eine Umwandlung vornehmen?

• Welche Datenzugriffsrichtlinien willst du anwenden?

• Handelt es sich um eine einmalige Übertragung, oder musst du regelmäßig Daten übertragen?

• Welche Ressourcen stehen für die Datenübertragung zur Verfügung?

• Wie hoch ist das zugewiesene Budget?

• Hast du die nötige Bandbreite, um die Übertragung durchzuführen, und zwar für einen angemessenen Zeitraum?

• Müssen Sie Offline-Lösungen nutzen (z. B. Amazon Snowball, Azure Data Box, Google Transfer Appliance)?

• Wie viel Zeit wird für die gesamte Datenmigration benötigt?

Sobald du die Eigenschaften der zu migrierenden Daten kennst, musst du zwei Schlüsselfaktoren berücksichtigen, die die Zuverlässigkeit und Leistung der Migration beeinflussen: Kapazität und Netzwerk.

Regionale Kapazität und Netzwerk zur Cloud

Bei der Migration von Daten in die Cloud gibt es in der Regel zwei Elemente, die sorgfältig bedacht werden müssen: die regionale Kapazität und die Qualität der Netzwerkanbindung an die Cloud.

Eine Cloud-Umgebung ist nicht unbegrenzt skalierbar. Die Realität ist, dass die Hardware von den Cloud-Providern am regionalen Standort gekauft, vorbereitet und konfiguriert werden muss. Sobald du die Zielarchitektur und die Ressourcen, die für die Datenplattform benötigt werden, festgelegt hast, solltest du auch einen regionalen Kapazitätsplan bei deinem ausgewählten Hyperscaler einreichen, um sicherzustellen, dass die Datenplattform über die gesamte Hardware verfügt, die für die Nutzung und das zukünftige Wachstum der Plattform erforderlich ist. Der Hyperscaler wird in der Regel wissen wollen, wie groß das Volumen der zu migrierenden und der in der Cloud anfallenden Daten ist, wie viel Rechenleistung du für die Verarbeitung der Daten benötigst und wie viele Interaktionen du mit anderen Systemen haben wirst. All diese Komponenten dienen als Input für deine Hyperscaler, damit sie sicher sein können, dass die zugrunde liegende Infrastruktur vom ersten Tag an bereit ist, all deine Workloads zu bedienen. Falls es zu Engpässen kommt (was bei GPUs häufig der Fall ist), musst du möglicherweise denselben Dienst in einer anderen Region nutzen (wenn es keine Auswirkungen auf die Einhaltung von Vorschriften oder auf die Technologie gibt) oder auf andere rechnergestützte Dienste zurückgreifen (z. B. IaaS gegenüber PaaS).

Das Netzwerk spielt in jeder Cloud-Infrastruktur eine wichtige Rolle, auch wenn es heutzutage als Gebrauchsgegenstand gilt: Wenn das Netzwerk langsam oder nicht erreichbar ist, können Teile deines Unternehmens komplett von ihren Geschäftsdaten abgeschnitten sein (das gilt auch, wenn du eine On-Premises-Umgebung nutzt). Bei der Planung der Cloud-Plattform sind einige der ersten Fragen, über die du nachdenken musst: Wie wird mein Unternehmen mit der Cloud verbunden sein? Welchen Partner werde ich mit der Einrichtung der Verbindung beauftragen? Nutze ich eine Standard-Internetverbindung (eventuell mit einem VPN darüber), oder möchte ich für eine zusätzliche dedizierte Verbindung bezahlen, die eine höhere Zuverlässigkeit gewährleistet? All diese Themen werden in der Regel in den Fragebögen für die Ausschreibung besprochen, aber sie sollten auch Teil eines der ersten Workshops sein, die du mit dem Anbieter/Partner veranstaltest, den du für die Entwicklung und Umsetzung der Plattform ausgewählt hast.

Es gibt drei Hauptwege, um sich mit der Cloud zu verbinden:

Öffentliche Internetverbindung

Nutzung öffentlicher Internetnetzwerke. In diesem Fall nutzen die Unternehmen in der Regel ein VPN über das öffentliche Internetprotokoll, um ihre Daten zu schützen und ein angemessenes Maß an Zuverlässigkeit zu gewährleisten. Die Leistung hängt stark davon ab, ob das Unternehmen in der Nähe des nächstgelegenen Standortes des ausgewählten Cloud-Hyperscalers ist.

Partner-Verbindung

Dies ist eine der typischen Verbindungen, die Unternehmen für ihre Produktions-Workloads nutzen können, insbesondere wenn sie eine garantierte Leistung mit hohem Durchsatz benötigen. Diese Verbindung besteht zwischen dem Unternehmen und dem ausgewählten Partner, der sich dann um die Verbindung mit den ausgewählten Hyperscalern kümmert. Dank der weiten Verbreitung von Telekommunikationsanbietern können Unternehmen Hochleistungsverbindungen zu einem erschwinglichen Preis einrichten.

Direkte Zusammenschaltung

Dies ist die bestmögliche Verbindung, bei der die Organisation direkt (und physisch) mit dem Netzwerk des Cloud-Providers verbunden ist. (Das kann möglich sein, wenn beide Parteien über Router am selben Standort verfügen.) Die Zuverlässigkeit, der Durchsatz und die allgemeine Leistung sind am besten, und die Preise können direkt mit den ausgewählten Hypervisoren besprochen werden.

Weitere Details zur Konfiguration dieser drei Konnektivitätsoptionen findest du in der Dokumentation von Azure, AWS und Google Cloud.

In der Regel wird in der PoC/MVP-Phase die öffentliche Internetverbindung gewählt, weil sie schneller einzurichten ist. In der Produktion wird meist die Partnerverbindung gewählt, vor allem, wenn das Unternehmen einen Multi-Cloud-Ansatz verfolgen will.

Optionen übertragen

Bei der Wahl der Art und Weise, wie du Daten in die Cloud überträgst, solltest du die folgenden Faktoren berücksichtigen:

Kosten

Bedenke die folgenden potenziellen Kosten, die mit der Übertragung von Daten verbunden sind:

Networking

Möglicherweise musst du deine Konnektivität verbessern, bevor du mit der Datenübertragung fortfahren kannst. Vielleicht hast du keine ausreichende Bandbreite, um die Migration zu unterstützen, und du musst mit deinem Anbieter über zusätzliche Leitungen verhandeln.

Cloud-Provider

Das Hochladen von Daten zu einem Cloud-Provider ist in der Regel kostenlos, aber wenn du Daten nicht nur aus deiner lokalen Umgebung, sondern auch aus einem anderen Hyperscaler exportierst, fallen möglicherweise Egress-Kosten (die in der Regel für jedes exportierte GB anfallen) und möglicherweise auch Lesekosten an.

Produkte

Möglicherweise musst du Speichergeräte kaufen oder mieten, um die Datenübertragung zu beschleunigen.

Menschen

Das Team, das die Migration durchführen wird.

Zeit

Es ist wichtig zu wissen, wie viele Daten du übertragen musst und welche Bandbreite dir zur Verfügung steht. Wenn du das weißt, kannst du die Zeit ermitteln, die du für die Übertragung der Daten brauchst. Wenn du zum Beispiel 200 TB Daten übertragen musst und nur eine Bandbreite von 10 Gbit/s zur Verfügung hast, brauchst du ungefähr zwei Tage, um deine Daten zu übertragen.¹ Dabei wird davon ausgegangen, dass die Bandbreite für die Datenübertragung vollständig zur Verfügung steht, was nicht unbedingt der Fall ist. Wenn du während deiner Analyse feststellst, dass du mehr Bandbreite brauchst, musst du eventuell mit deinem Internetdienstanbieter (ISP) zusammenarbeiten, um eine Erhöhung zu beantragen oder die Tageszeit zu bestimmen, zu der diese Bandbreite verfügbar ist. Vielleicht ist es auch der richtige Zeitpunkt, mit deinem Cloud-Anbieter zusammenzuarbeiten, um eine direkte Verbindung herzustellen. Dadurch wird verhindert, dass deine Daten über das öffentliche Internet übertragen werden, und es kann ein gleichmäßigerer Durchsatz für große Datenübertragungen erzielt werden (z. B. AWS Direct Connect, Azure ExpressRoute, Google Cloud Direct Interconnect).

Offline- versus Online-Übertragung

In manchen Fällen ist eine Online-Übertragung nicht durchführbar, weil sie zu lange dauern würde. In solchen Fällen solltest du eine Offline-Übertragung mit Hilfe von Speicherhardware wählen. Cloud-Anbieter bieten diese Art von Service an (z. B. Amazon Snowball Datentransfer, Azure Data Box, Google Transfer Appliance), der besonders für Datentransfers von Hunderten von Terabytes bis hin zu Petabytes geeignet ist. Du bestellst bei deinem Cloud-Anbieter eine physische Appliance, die mit deinem Netzwerk verbunden werden muss. Dann kopierst du die Daten, die standardmäßig verschlüsselt sind, und forderst eine Lieferung an die nächstgelegene Einrichtung des Anbieters an. Nach der Lieferung werden die Daten in den entsprechenden Dienst in der Cloud kopiert (z. B. AWS S3, Azure Blob Storage, Google Cloud Storage) und sind dann einsatzbereit.

Verfügbare Tools

Sobald du alle Netzwerkdynamiken geklärt hast, solltest du entscheiden, wie du den Datenupload handhaben willst. Je nachdem, auf welches System du zugreifen möchtest (z. B. Blob Speicherung, DWH-Lösung, Datenbank, Drittanbieteranwendung usw.), stehen dir in der Regel die folgenden Optionen zur Verfügung:

Befehlszeilen-Tools

Tools (z. B. AWS CLI, Azure Cloud Shell oder Google Cloud SDK), mit denen du mit allen Diensten des Cloud-Providers interagieren kannst. Du kannst alle Prozesse automatisieren und orchestrieren, die nötig sind, um die Daten an das gewünschte Ziel hochzuladen. Je nach Tool musst du eventuell Zwischensysteme passieren, bevor du die Daten in das endgültige Ziel hochladen kannst (z.B. zuerst die Blob Speicherung, bevor du die Daten in das DWH einspeisen kannst), aber dank der Flexibilität der verschiedenen Tools solltest du in der Lage sein, deine Workflows einfach zu implementieren - z.B. mit Hilfe von Bash- oder PowerShell-Skripten.

REST-APIs

Diese ermöglichen es dir, Dienste in alle Anwendungen zu integrieren, die du entwickeln möchtest - zum Beispiel in interne Migrationstools, die du bereits implementiert und genutzt hast, oder in brandneue Anwendungen, die du für diesen Zweck entwickeln möchtest.

Physikalische Lösungen

Tools für die Offline-Migration, wie in der vorangegangenen Beschreibung der Offline- und Online-Übertragung beschrieben.

Kommerzielle Standardlösungen (COTS) von Drittanbietern

Diese könnten weitere Funktionen wie Netzwerkdrosselung, benutzerdefinierte fortschrittliche Datenübertragungsprotokolle, erweiterte Orchestrierungs- und Verwaltungsfunktionen sowie Datenintegritätsprüfungen bieten .

Phasen der Migration

Deine Migration besteht aus sechs Phasen (siehe Abbildung 4-3):

1. Die vorgelagerten Prozesse, die die derzeitigen Datenlösungen speisen, werden an die Zielumgebung angepasst.

2. Nachgelagerte Prozesse, die aus der alten Umgebung lesen, werden geändert, um aus der Zielumgebung zu lesen.

3. Historische Daten werden in großen Mengen in die Zielumgebung migriert. Zu diesem Zeitpunkt werden die vorgelagerten Prozesse so migriert, dass sie ebenfalls in die Zielumgebung schreiben.

4. Nachgelagerte Prozesse sind jetzt mit der Zielumgebung verbunden.

5. Die Daten können zwischen der alten und der Zielumgebung synchron gehalten werden, indem CDC-Pipelines genutzt werden, bis die alte Umgebung vollständig aufgegeben wird.

6. Nachgelagerte Prozesse werden voll funktionsfähig und nutzen die Zielumgebung.

Abbildung 4-3. Strategie der Datenmigration

Es gibt einige abschließende Prüfungen, die du durchführen solltest, um sicherzustellen, dass du keine Engpässe oder Probleme bei der Datenübertragung bekommst:

Führe einen Funktionstest durch.

Du musst einen Test durchführen, um zu überprüfen, ob deine gesamte Datenübernahme korrekt funktioniert. Idealerweise führst du diesen Test während der Ausführung deines MVP durch, indem du eine große Menge an Daten auswählst und möglicherweise alle Tools einsetzt, die du während der gesamten Migration verwenden möchtest. Ziel dieses Schritts ist es vor allem, zu überprüfen, ob der Datentransfer korrekt funktioniert, und gleichzeitig potenzielle Probleme aufzudecken, die das Projekt aufhalten könnten, z. B. die Unfähigkeit, die Tools zu nutzen (z. B. wenn deine Mitarbeiter nicht geschult sind oder du keine angemessene Unterstützung von deinem Systemintegrator erhältst) oder Netzwerkprobleme (z. B. Netzwerkrouten).

Führe einen Leistungstest durch.

Du musst überprüfen, ob deine aktuelle Infrastruktur die Migration im großen Maßstab bewältigen kann. Dazu solltest du eine große Stichprobe deiner zu migrierenden Daten (in der Regel zwischen 3 und 5 %) auswählen, um zu bestätigen, dass deine Migrationsinfrastruktur und -lösung entsprechend den Migrationsanforderungen skaliert und du keine besonderen Engpässe feststellst (z. B. ein langsames Quellspeichersystem).

Führe eine Datenintegritätsprüfung durch.

Eines der kritischsten Probleme, auf die du bei einer Datenmigration stoßen kannst, ist, dass die ins Zielsystem migrierten Daten aufgrund eines Fehlers gelöscht werden oder beschädigt und unbrauchbar sind. Es gibt einige Möglichkeiten, deine Daten vor solchen Risiken zu schützen:

• Aktiviere die Versionskontrolle und das Backup an deinem Zielort, um den Schaden eines versehentlichen Löschens zu begrenzen.

• Überprüfe deine Daten, bevor du die Quelldaten entfernst.

Wenn du Standardwerkzeuge für die Migration verwendest (z. B. CLIs oder REST-APIs), musst du all diese Aktivitäten selbst durchführen. Wenn du jedoch eine Anwendung eines Drittanbieters wie Signiant Media Shuttle oder IBM Aspera on Cloud einsetzt, ist es wahrscheinlich, dass bereits mehrere Arten von Prüfungen standardmäßig implementiert sind. (Wir empfehlen, die verfügbaren Funktionen im Anwendungsblatt sorgfältig zu lesen, bevor du die Lösung auswählst).

Zusammenfassung

In diesem Kapitel hast du einen praktischen Ansatz für die Datenmodernisierung kennengelernt und ein allgemeines technologisches Migrationskonzept vorgestellt, das auf jede Migration von einer Legacy-Umgebung zu einer modernen Cloud-Architektur angewendet werden kann. Die wichtigsten Erkenntnisse sind die folgenden:

• Konzentriere dich auf die Modernisierung deines Daten-Workflows, nicht nur auf die Aufrüstung einzelner Tools. Die Wahl des richtigen Werkzeugs für die richtige Aufgabe hilft dir, Kosten zu senken, deine Werkzeuge optimal zu nutzen und effizienter zu arbeiten.

• Ein möglicher Rahmen für die Datenmigration kann in vier Schritten umgesetzt werden: vorbereiten und entdecken, bewerten und planen, ausführen und optimieren.

• Vorbereiten und Entdecken ist ein zentraler Schritt, bei dem du dich darauf konzentrierst, den Umfang der Migration festzulegen und dann alle Informationen zu den verschiedenen Arbeitslasten/Nutzungsfällen zu sammeln, die du für die Migration identifiziert hast.

• Bewerten und Planen ist der Schritt, in dem du alle Aktivitäten definierst und planst, die zum Erreichen des festgelegten Ziels erforderlich sind (z. B. Kategorisierung und Clusterung der zu migrierenden Arbeitslasten, Definition von KPIs, Definition eines möglichen MVP und Definition des Migrationsplans mit entsprechenden Meilensteinen).

• Ausführen ist der Schritt, bei dem du die Migration iterativ durchführst und den Gesamtprozess bei jeder Iteration verbesserst.

• Optimieren ist der Schritt, bei dem du das neue System als Ganzes betrachtest und mögliche neue Anwendungsfälle identifizierst, die du einführen kannst, um es noch flexibler und leistungsfähiger zu machen.

• Die Ermittlung des aktuellen Bedarfs und der Gesamtkosten der endgültigen Lösung ist ein komplexer Schritt, an dem mehrere Akteure beteiligt sein können. Unternehmen nutzen in der Regel RFI, RFP und RFQ, um mehr Informationen von Anbietern/potentiellen Partnern zu erhalten.

• Governance und Sicherheit bleiben in den meisten Unternehmen ein zentrales Anliegen. Das liegt daran, dass die Art und Weise, wie Rollen definiert, Daten gesichert und Aktivitäten protokolliert werden, einheitlich sein muss.

• Der Migrationsrahmen muss in Übereinstimmung mit einem sehr gut definierten Governance-Rahmen funktionieren, der während der gesamten Lebensdauer der Daten von zentraler Bedeutung ist.

• Wenn du das Schema deiner Daten migrierst, kann es sinnvoll sein, ein Muster wie das Fassadenmuster zu nutzen, um die Übernahme der Funktionen der Ziellösung zu erleichtern.

• Die Konnektivität und die Sicherung der regionalen Kapazität sind bei der Nutzung von Cloud-Lösungen entscheidend. Netzwerkkonfiguration, Bandbreitenverfügbarkeit, Kosten, Mitarbeiter, Tools, Leistung und Datenintegrität sind die wichtigsten Punkte, die für jeden Workload geklärt werden müssen.

In den bisherigen vier Kapiteln hast du gelernt, warum du eine Datenplattform aufbauen solltest, wie du eine Strategie für den Weg dorthin findest, wie du deine Mitarbeiter qualifizierst und wie du eine Migration durchführst. In den nächsten Kapiteln werden wir uns mit den architektonischen Details befassen und damit beginnen, wie man moderne Data Lakes aufbaut.

¹ Im Internet gibt es mehrere kostenlose Dienste, die dir bei dieser Schätzung helfen können, zum Beispiel der Bandbreitenrechner von Calculator.net.