Datenpipelines migrieren

In diesem Dokument wird beschrieben, wie Sie Ihre vorgelagerten Datenpipelines migrieren, die Daten in Ihr Data Warehouse laden. In diesem Dokument wird erläutert, was eine Datenpipeline ist, welche Verfahren und Muster eine Pipeline verwenden kann und welche Optionen und Technologien für eine Data-Warehouse-Migration verfügbar sind.

Was ist eine Datenpipeline?

Im Computing ist eine Datenpipeline eine Art von Anwendung, die Daten in einer Abfolge von verbundenen Verarbeitungsschritten verarbeitet. Als allgemeines Konzept können Datenpipelines beispielsweise auf die Datenübertragung zwischen Informationssystemen, den ETL-Prozess (Extrahieren, Transformieren und Laden), die Datenanreicherung und die Echtzeitdatenanalyse angewendet werden. In der Regel werden Datenpipelines als Batchprozess oder Streamingprozess implementiert. Im ersten Fall erfolgt die Ausführung und Verarbeitung von Daten nur dann, wenn der Prozess gestartet wird. Im zweiten Fall wird der Prozess kontinuierlich ausgeführt und die Daten werden verarbeitet, sobald sie der Pipeline zur Verfügung stehen.

Im Kontext des Data-Warehouse-Prozesses werden Datenpipelines häufig verwendet, um Daten aus Transaktionssystemen zu lesen, Transformationen anzuwenden und dann Daten in das Data Warehouse zu schreiben. Jede Transformation wird durch eine Funktion beschrieben, und die Eingabe für eine bestimmte Funktion ist die Ausgabe der vorherigen Funktion oder Funktionen. Diese verbundenen Funktionen werden als Graph beschrieben. Dieser Graph wird oft als Directed Acyclic Graph (DAG) bezeichnet. Das bedeutet, dass der Graph eine Richtung (von der Quelle zum Ziel) hat und azyklisch ist. Die Eingabe für eine Funktion darf nicht von der Ausgabe einer anderen Funktion weiter unten im DAG abhängen. Mit anderen Worten: Schleifen sind nicht zulässig. Jeder Knoten des Graphen ist eine Funktion und jede Kante stellt die Daten dar, die von einer Funktion zur nächsten fließen. Die anfänglichen Funktionen sind Quellen oder Verbindungen zu Quelldatensystemen. Die abschließenden Funktionen sind Senken oder Verbindungen zu Zieldatensystemen.

Im Kontext von Datenpipelines sind Quellen meist Transaktionssysteme wie ein RDBMS und Senken sind mit einem Data Warehouse verbunden. Diese Art von Grafik wird als Datenfluss-DAG bezeichnet. Sie können mit DAG auch Datenverschiebungen zwischen Datenpipelines und anderen Systemen orchestrieren. In diesem Fall wird von einem Orchestrierungs- oder Kontrollfluss-DAG gesprochen.

Migrationszeitpunkt von Datenpipelines

Wenn Sie einen Anwendungsfall zu BigQuery migrieren, können Sie diesen auslagern oder vollständig migrieren.

Falls Sie sich für das Auslagern eines Anwendungsfalls entscheiden, müssen Sie seine vorgelagerten Datenpipelines nicht im Voraus migrieren. Vielmehr migrieren Sie zuerst das Schema und die Daten des Anwendungsfalls aus dem vorhandenen Data Warehouse zu BigQuery. Anschließend richten Sie eine inkrementelle Kopie vom alten zum neuen Data Warehouse ein, um die Daten zu synchronisieren. Schließlich migrieren und validieren Sie nachgelagerte Prozesse wie Skripts, Abfragen, Dashboards und Geschäftsanwendungen.

Zu diesem Zeitpunkt sind die vorgelagerten Datenpipelines unverändert und schreiben weiterhin Daten in das vorhandene Data Warehouse. Sie können die ausgelagerten Anwendungsfälle wieder in den Migrationsrückstand aufnehmen, um sie in einer nachfolgenden Iteration vollständig zu migrieren.

Falls Sie sich für die vollständige Migration eines Anwendungsfalls entscheiden, werden die für den Anwendungsfall erforderlichen vorgelagerten Datenpipelines zu Google Cloud migriert. Bei der vollständigen Migration müssen Sie zuerst den Anwendungsfall auslagern. Nach der vollständigen Migration können Sie die entsprechenden Legacy-Tabellen im lokalen Data Warehouse verwerfen, da die Daten direkt in BigQuery aufgenommen werden.

Während einer Iteration können Sie eine der folgenden Optionen auswählen:

• Nur den Anwendungsfall auslagern
• Einen Anwendungsfall, der zuvor ausgelagert wurde, vollständig migrieren
• Einen komplett neuen Anwendungsfall vollständig migrieren, indem Sie ihn zuerst in derselben Iteration auslagern

Wenn alle Anwendungsfälle vollständig migriert sind, können Sie das alte Data Warehouse deaktivieren. Dies ist ein wichtiger Schritt, um Aufwände und Kosten zu reduzieren.

Datenpipelines migrieren

Im weiteren Verlauf dieses Dokuments wird beschrieben, wie Sie beim Migrieren Ihrer Datenpipelines vorgehen. Sie erfahren Sie, welche Ansätze und Verfahren verwendet und welche Technologien eingesetzt werden können. Die Optionen reichen von der Wiederverwendung vorhandener Datenpipelines (d. h. deren Weiterleitung, um Daten in BigQuery zu laden) bis zum Umschreiben der Datenpipelines, um die Vorteile der von Google Cloud verwalteten Dienste zu nutzen.

Verfahren und Muster für Datenpipelines

Mit Datenpipelines können Sie eine Reihe von Verfahren und Mustern ausführen. Diese Pipelines werden am häufigsten im Data-Warehouse-Prozess verwendet. Dabei kann es sich um Batch-Datenpipelines oder Streaming-Datenpipelines handeln. Batch-Datenpipelines werden für Daten ausgeführt, die über einen bestimmten Zeitraum erfasst wurden, zum Beispiel einmal täglich. Streaming-Datenpipelines verarbeiten Echtzeitereignisse, die von Ihren Betriebssystemen generiert werden. Im CDC (Change Data Capture) sind dies beispielsweise Zeilenänderungen, die von OLTP-Datenbanken (Online Transaction Processing) generiert werden.

Extrahieren, Transformieren und Laden (ETL)

Im Kontext des Data-Warehouse-Prozesses führen Datenpipelines häufig ein ETL-Verfahren (Extrahieren, Transformieren und Laden) aus. ETL-Technologien werden außerhalb des Data Warehouse ausgeführt. Dies bedeutet, dass die Ressourcen des Data Warehouse in erster Linie für gleichzeitige Abfragen verwendet werden können anstatt zum Vorbereiten und Transformieren von Daten. Das Ausführen der Transformation außerhalb des Data Warehouse hat allerdings den Nachteil, dass Sie zusätzliche Tools und Sprachen (außer SQL) lernen müssen, um die Transformationen auszudrücken.

Das folgende Diagramm zeigt ein typisches ETL-Verfahren.

Abbildung 1. Typisches ETL-Verfahren.

Hinweis: Die Pfeile zeigen die Richtung des Datenflusses an. Die Quellen innerhalb des DAG rufen ihre Daten normalerweise aus den Quellsystemen ab.

Bei einer typischen ETL-Datenpipeline werden Daten aus einem oder mehreren Quellsystemen abgerufen. Die Anzahl sollte möglichst gering sein, um Fehler zu vermeiden, die durch Probleme wie nicht verfügbare Systeme verursacht werden. Die Pipeline führt dann eine Reihe von Transformationen aus, darunter das Bereinigen von Daten, Anwenden von Geschäftsregeln, Prüfen der Datenintegrität und Erstellen von Aggregaten oder Disaggregaten. Weitere Informationen finden Sie unter Real-life ETL cycle.

Üblicherweise werden mehrere Datenpipelines verwendet. Die erste Pipeline ist für das Kopieren von Daten aus dem Quellsystem in das Data Warehouse vorgesehen. Die nachfolgenden Pipelines wenden Geschäftslogiken an und transformieren die Daten zur Verwendung in verschiedenen Data-Marts. Dabei handelt es sich um Untergruppen des Data Warehouse mit Schwerpunkt auf einer bestimmten Geschäftseinheit oder geschäftlichen Ausrichtung.

Wenn Sie mehrere Datenpipelines haben, müssen Sie diese orchestrieren. Das folgende Diagramm zeigt, wie dieser Orchestrierungsprozess aussehen könnte.

Abbildung 2. Orchestrierungsprozess für mehrere Datenpipelines

Im Diagramm wird jede Datenpipeline als Unter-DAG des Orchestrierungs-DAG betrachtet. Jeder Orchestrierungs-DAG umfasst mehrere Datenpipelines, die auf das größere Ziel ausgerichtet sind, beispielsweise die Vorbereitung von Daten für eine Geschäftseinheit, sodass Business-Analysten ihre Dashboards oder Berichte ausführen können.

Extrahieren, Laden und Transformieren (ELT)

ELT ist eine Alternative zu ETL. Beim ELT-Verfahren gliedert sich die Datenpipeline in zwei Teile. Zuerst extrahiert eine ELT-Technologie die Daten aus dem Quellsystem und lädt sie in das Data Warehouse. Dann führen SQL-Skripts im Data Warehouse die Transformationen aus. Der Vorteil dieses Ansatzes besteht darin, dass Sie die Transformationen mit SQL ausdrücken können. Der Nachteil ist, dass damit Data-Warehouse-Ressourcen verbraucht werden könnten, die für gleichzeitige Abfragen erforderlich sind. Aus diesem Grund werden ELT-Batches oft nachts (oder außerhalb der Spitzenzeiten) ausgeführt, wenn die Systemressourcen des Data Warehouse weniger stark beansprucht werden.

Das folgende Diagramm zeigt ein typisches ELT-Verfahren.

Abbildung 3. Typisches ELT-Verfahren.

Bei Verwendung eines ELT-Ansatzes werden die Vorgänge zum Extrahieren und Laden üblicherweise in einen DAG eingeteilt und die Transformationen in ihre eigenen DAGs. Daten werden einmal in das Data Warehouse geladen und dann mehrfach transformiert, um die verschiedenen Tabellen zu erstellen, die nachgelagert in der Berichterstellung und so weiter verwendet werden. Diese DAGs werden wiederum zu Unter-DAGs in einem größeren Orchestrierungs-DAG, wie im ETL-Abschnitt gezeigt.

Wenn Sie Datenpipelines aus einem überlasteten lokalen Data Warehouse in die Cloud migrieren, sollten Sie daran denken, dass Cloud-Data-Warehouse-Systeme wie BigQuery massiv parallele Datenverarbeitungstechnologien sind. Tatsächlich können Sie im Fall von BigQuery zusätzliche Ressourcen erwerben, um steigende Anforderungen für den ELT-Prozess und gleichzeitige Abfragen zu erfüllen. Weitere Informationen finden Sie in der Einführung in die Optimierung der Abfrageleistung.

Extrahieren und Laden (EL)

Sie können das EL-Verfahren (Extrahieren und Laden) für sich allein verwenden oder gefolgt von Transformationen. In diesem Fall wird es zum ELT-Verfahren. EL wird hier separat erwähnt, weil mehrere automatisierte Dienste verfügbar sind, die diese Aufgabe ausführen, damit Sie keine eigene Datenpipelines für die Datenaufnahme erstellen müssen. Weitere Informationen finden Sie unter BigQuery Data Transfer Service.

Change Data Capture (CDC)

Change Data Capture (CDC) ist eines von mehreren Softwaredesignmustern zum Verfolgen von Datenänderungen. Es wird häufig im Data-Warehouse-Prozess verwendet, da mit dem Data Warehouse Daten und deren Änderungen aus verschiedenen Quellsystemen über einen bestimmten Zeitraum sortiert und verfolgt werden.

Das folgende Diagramm zeigt ein Beispiel für die Funktionsweise von CDC mit ELT.

Abbildung 4. Funktionsweise von CDC mit ELT.

CDC funktioniert gut mit ELT, da der ursprünglichen Datensatz gespeichert werden sollte, bevor später Änderungen daran vorgenommen werden.

Für den EL-Teil können Sie Datenbanklogs mit CDC-Software wie Datastream oder Open-Source-Tools wie Debezium verarbeiten und die Datensätze mit Dataflow in BigQuery schreiben. Anschließend können Sie mithilfe einer SQL-Abfrage die neueste Version ermitteln, bevor Sie weitere Transformationen anwenden. Beispiel:

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY RECORD KEY
      ORDER BY EVENT TIMESTAMP DESC
    ) AS rank
  FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1

Verwenden Sie beim Refaktorieren oder Erstellen neuer Datenpipelines möglichst das CDC-Muster, angewendet als ELT-Verfahren. Dieser Ansatz gewährleistet, dass Ihnen der gesamte Verlauf der vorgelagerten Datenänderungen vorliegt und eine gute Trennung der Verantwortlichkeiten gegeben ist. Beispiel:

• Quellsystemteams sorgen für die Verfügbarkeit ihrer Logs und die Veröffentlichung ihrer Datenereignisse
• Das Datenplattformteam sorgt dafür, dass die Datenaufnahmesortierung der ursprünglichen Datensätze Zeitstempel im Data Warehouse enthält
• Das Data Engineering- und das Analyseteam plant eine Reihe von Transformationen zum Füllen ihrer Data-Marts

Feedback-Loops mit Betriebsdatenpipelines

Betriebsdatenpipelines sind Datenverarbeitungspipelines, die Daten aus dem Data Warehouse aufnehmen, bei Bedarf transformieren und das Ergebnis in Betriebssysteme schreiben.

Betriebssysteme beziehen sich auf Systeme, die die täglichen Transaktionen der Organisation verarbeiten, darunter OLTP-Datenbanken, CRM-Systeme (Customer-Relationship-Management) und PCM-Systeme (Product Catalog Management). Da diese Systeme häufig als Datenquelle agieren, implementieren die Betriebsdatenpipelines ein Feedback-Loop-Muster.

Das Muster für eine Betriebsdatenpipeline wird im folgenden Diagramm gezeigt.

Abbildung 5. Muster für eine Betriebsdatenpipeline.

Das folgende Beispiel beschreibt eine Betriebsdatenpipeline, die Produktpreise in ein PCM-System schreibt. Ein PCM-System ist das maßgebliche System für vertriebsbezogene Produktinformationen wie Farben, Vertriebskanäle, Preise und Saisonabhängigkeit. Hier der End-to-End-Datenfluss:

• Preisbezogene Daten stehen aus mehreren Quellen zur Verfügung. Diese Daten können unter anderem den aktuellen Preis pro Region aus dem PCM-System, die Preise eines Mitbewerbers aus einem Drittanbieter-Dienst sowie Bedarfsprognosen und Lieferantenzuverlässigkeitsdaten aus internen Systemen umfassen.
• Eine ETL-Pipeline ruft die Daten aus den Quellen ab, transformiert sie und schreibt das Ergebnis in das Data Warehouse. Die Transformation ist in diesem Fall eine komplexe Berechnung, bei der alle Quellen einbezogen werden, um einen optimalen Grundpreis für jedes Produkt im PCM-System zu generieren.
• Die Betriebspipeline ruft schließlich die Grundpreise aus dem Data Warehouse ab, führt geringfügige Transformationen durch, um die Preise an saisonale Ereignisse anzupassen, und schreibt die endgültigen Preise zurück in das PCM-System.

Abbildung 6. Betriebsdatenpipeline, die Produktpreise in ein PCM-System schreibt.

Eine Betriebsdatenpipeline ist eine Art von nachgelagertem Prozess, während Datenpipelines, die ETL, ELT oder CDC implementieren, vorgelagerte Prozesse sind. Trotzdem können sich die Tools, die jeweils zum Implementieren der beiden Prozesse verwendet werden, überschneiden. Beispielsweise können Sie Dataflow zum Definieren und Ausführen aller Datenverarbeitungs-DAGs verwenden, GoogleSQL zum Definieren der in BigQuery auszuführenden Transformationen und Cloud Composer zum Orchestrieren des End-to-End-Datenflusses.

Migrationsansatz wählen

In diesem Abschnitt werden verschiedene Ansätze beschrieben, mit denen Sie Ihre Datenpipelines migrieren können.

Datenpipelines zum Schreiben von Daten in BigQuery weiterleiten

Unter den folgenden Bedingungen sollten Sie prüfen, ob eine von Ihnen verwendete Technologie eine integrierte BigQuery-Senke (Schreib-Connector) bietet:

• Das Legacy-Data Warehouse wird von Datenpipelines gespeist, die ein ETL ausführen.
• Die Transformationslogik wird ausgeführt, bevor die Daten im Data Warehouse gespeichert werden.

ISVs (Independent Software Vendors) stellen Datenverarbeitungstechnologien mit BigQuery-Connectors bereit, darunter:

• Informatica: Google BigQuery Connector Guide
• Talend: Writing data in BigQuery

Hinweis: Sie sollten unbedingt prüfen, ob die Datenverarbeitungssoftware die umfassenden Datenaufnahmemechanismen von BigQuery wie Streaming-Insert-Anweisungen oder Batchladevorgänge aus Cloud Storage nutzt. Ein Ansatz, bei dem BigQuery-Treiber für Magnitude Simba, JDBC oder ODBC verwendet werden, ist für umfangreiche Datenaufnahmevorgänge nicht geeignet, da diese Treiber die Abfrageschnittstelle implementieren. Obwohl die Treiber Insert-Anweisungen ausführen können, ist diese Schnittstelle für Abfragen und DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) für BigQuery gedacht, nicht für umfangreiche Insert- oder Update-Anweisungen.

Wenn die Datenpipelinetechnologie die Datenaufnahme in BigQuery nicht unterstützt, sollten Sie eine Variante dieses Ansatzes in Betracht ziehen, bei der die Daten vorübergehend in Dateien geschrieben werden, die BigQuery anschließend aufnimmt.

Abbildung 7. Umschreiben oder Neukonfigurieren der letzten Funktion einer Datenpipeline, um Daten in BigQuery zu schreiben.

Vereinfacht ausgedrückt, muss die letzte Funktion der Datenpipeline umgeschrieben oder neu konfiguriert werden, um Daten in BigQuery zu schreiben. Allerdings müssen Sie eine Reihe von Optionen berücksichtigen, die zusätzliche Änderungen oder neue Arbeitsschritte erfordern können. Beispiele:

Funktionale Ebene

• Datenzuordnungen: Da sich das Schema der Zieldatenbanktabelle ändern kann, müssen Sie diese Zuordnungen möglicherweise neu konfigurieren.
• Messwertvalidierung: Sie müssen die alten und neuen Berichte validieren, da sich sowohl das Schema als auch die Abfragen ändern können.

Nicht funktionale Ebene

• Firewalls müssen unter Umständen so konfiguriert werden, dass ausgehende Datenübertragungen von lokalen Systemen zu BigQuery möglich sind.
• Eventuell sind Netzwerkänderungen erforderlich, um zusätzliche Bandbreite für ausgehende Datenübertragungen zu schaffen.

Datenpipelines mithilfe von Dateien als Zwischenmedium weiterleiten

Wenn die vorhandene lokale Datenpipelinetechnologie Google APIs nicht unterstützt oder die Verwendung von Google APIs eingeschränkt ist, können Sie Dateien als Zwischenmedium verwenden, damit Ihre Daten BigQuery erreichen.

Dieser Ansatz ist dem Weiterleitungsansatz ähnlich, allerdings verwenden Sie keine native Senke, die in BigQuery schreiben kann, sondern eine Senke, die in ein lokales Dateisystem schreiben kann. Wenn sich die Daten in Ihrem Dateisystem befinden, kopieren Sie die Dateien in Cloud Storage. Weitere Informationen finden Sie in der Übersicht zu den Datenaufnahmeoptionen für Cloud Storage und den Kriterien für die Auswahl einer Datenaufnahmeoption.

Der letzte Schritt besteht darin, die Daten aus Cloud Storage gemäß den Richtlinien unter Daten im Batch laden in BigQuery zu laden.

Das folgende Diagramm zeigt den in diesem Abschnitt beschriebenen Ansatz.

Abbildung 8. Weiterleiten von Datenpipelines mithilfe von Dateien als Zwischenmedium.

Im Hinblick auf die Orchestrierung der ETL-Pipeline müssen Sie zwei separate Schritte ausführen:

1. Greifen Sie auf Ihre vorhandene lokale Pipelineorchestrierung zurück, um die transformierten Daten in das Dateisystem zu schreiben. Erweitern Sie diese Orchestrierung, um die Dateien aus dem lokalen Dateisystem in Cloud Storage zu kopieren. Sie können auch ein zusätzliches Skript erstellen, das regelmäßig zur Ausführung des Kopierschritts ausgeführt wird.
2. Wenn sich die Daten in Cloud Storage befinden, verwenden Sie eine Cloud Storage-Übertragung, um wiederkehrende Ladevorgänge von Cloud Storage in BigQuery zu planen. Alternativen zu Cloud Storage-Übertragungen sind Cloud Storage-Trigger und Cloud Composer.

Abbildung 8 zeigt außerdem, dass die Orchestrierung in Google Cloud auch ein Pull-Modell verwenden kann, bei dem die Dateien über ein Protokoll wie SFTP abgerufen werden.

Vorhandene ELT-Pipelines zu BigQuery migrieren

ELT-Pipelines bestehen aus zwei Teilen: Ein Teil lädt die Daten in Ihr Data Warehouse und der andere Teil transformiert die Daten mithilfe von SQL für die nachgelagerte Verarbeitung. Wenn Sie ELT-Pipelines migrieren, wird in jedem dieser Teile ein eigener Ansatz zur Migration verfolgt.

Für den Teil, der Daten in Ihr Data Warehouse lädt (den EL-Teil), können Sie den Richtlinien im Abschnitt zum Weiterleiten von Datenpipelines folgen. Ignorieren Sie dabei den Hinweis zu Transformationen, da diese nicht Teil einer EL-Pipeline sind.

Wenn Ihre Datenquellen von BigQuery Data Transfer Service (DTS) entweder direkt oder über die Einbindung von Drittanbieter-Lösungen unterstützt werden, können Sie die EL-Pipeline durch DTS ersetzen.

Vorhandene OSS-Datenpipelines zu Dataproc migrieren

Bei der Migration Ihrer Datenpipeline zu Google Cloud müssen vielleicht auch einige Legacy-Jobs migriert werden, die mit einem Open-Source-Software-Framework wie Apache Hadoop, Apache Spark oder Apache Flink geschrieben wurden.

Mit Dataproc stellen Sie schnelle, benutzerfreundliche und vollständig verwaltete Hadoop- und Spark-Cluster einfach und kostengünstig bereit. Dataproc ist in den BigQuery-Connector eingebunden. Dieser ist eine Java-Bibliothek, über die Sie Daten aus Hadoop und Spark mithilfe abstrahierter Versionen der Apache Hadoop-Klassen InputFormat und OutputFormat direkt in BigQuery schreiben können.

Dataproc vereinfacht das Erstellen und Löschen von Clustern, sodass Sie anstelle eines monolithischen Clusters viele sitzungsspezifische Cluster verwenden können. Dieser Ansatz bietet verschiedene Vorteile:

• Sie können für einzelne Jobs unterschiedliche Cluster-Konfigurationen verwenden, sodass Ihnen der Administrationsaufwand für die Verwaltung von Tools für alle Jobs erspart bleibt.
• Sie können Cluster für die Anforderungen einzelner Jobs oder Gruppen von Jobs skalieren.
• Sie zahlen nur dann für Ressourcen, wenn diese von Ihren Jobs verwendet werden.
• Sie müssen Cluster nicht kontinuierlich betreuen, da sie bei jeder Verwendung neu konfiguriert werden.
• Sie müssen keine separate Infrastruktur für Entwicklung, Testen und Produktion vorhalten. Sie können bei Bedarf mit denselben Definitionen so viele verschiedene Cluster erstellen, wie Sie benötigen.

Zum Migrieren Ihrer Jobs empfehlen wir einen inkrementellen Ansatz. Bei der inkrementellen Migration können Sie folgende Schritte ausführen:

• Einzelne Jobs in Ihrer vorhandenen Hadoop-Infrastruktur von der Komplexität isolieren, die mit einer lange bestehenden Systemumgebung einhergeht
• Jeden isolierten Jobs zur Ermittlung der jeweiligen Anforderungen und der besten Methode für die Migration untersuchen
• Unerwartete Probleme unmittelbar bei Auftreten ohne Verzögerung abhängiger Aufgaben beheben
• Proof-of-Concept für jeden komplexen Prozess ohne Beeinträchtigung Ihrer Produktionsumgebung erstellen
• Jobs auf das empfohlene sitzungsspezifische Modell umstellen – wohldurchdacht und effektiv

Wenn Sie Ihre vorhandenen Hadoop- und Spark-Jobs zu Dataproc migrieren, können Sie prüfen, ob die Abhängigkeiten Ihrer Jobs von den unterstützten Dataproc-Versionen abgedeckt werden. Falls Sie benutzerdefinierte Software installieren müssen, können Sie ein eigenes Dataproc-Image erstellen, einige der verfügbaren Initialisierungsaktionen verwenden (z. B. für Apache Flink), eigene Initialisierungsaktionen schreiben oder benutzerdefinierte Python-Paketanforderungen angeben.

Sehen Sie sich als Erstes die Dataproc-Kurzanleitungen und die Codebeispiele für den BigQuery-Connector an. Weitere Informationen finden Sie auch unter Lokale Hadoop-Jobs zu Dataproc migrieren.

Datenpipelines von Drittanbietern zur Ausführung in Google Cloud neu hosten

Beim Erstellen lokaler Datenpipelines wird häufig Drittanbieter-Software verwendet, um die Ausführung der Pipeline und die Zuweisung von Computing-Ressourcen zu verwalten.

Zum Verschieben dieser Pipelines in die Cloud stehen Ihnen je nach Funktionsumfang der von Ihnen verwendeten Software und Ihren Lizenzierungs-, Support- und Wartungsbedingungen verschiedene Alternativen zur Verfügung.

In den folgenden Abschnitten werden einige dieser Alternativen vorgestellt.

Im Wesentlichen haben Sie folgende Alternativen zur Ausführung Ihrer Drittanbieter-Software in Google Cloud, beginnend mit der am wenigsten komplexen Alternative bis zur komplexesten:

• Ihr Softwareanbieter arbeitet mit Google Cloud zusammen, um seine Software im Google Cloud Marketplace anzubieten.
• Ihre Drittanbieter-Software kann auf Kubernetes ausgeführt werden.
• Ihre Drittanbieter-Software wird auf einer oder mehreren virtuellen Maschinen (VMs) ausgeführt.

Wenn Ihre Drittanbieter-Software eine Cloud Marketplace-Lösung bereitstellt, müssen Sie folgende Arbeitsschritte ausführen:

• Stellen Sie Ihre Drittanbieter-Software über die Cloud Marketplace-Konsole bereit.
• Wählen Sie Ihre Anwendungsfälle aus und migrieren Sie sie gemäß dem iterativen Ansatz, der unter Mithilfe eines iterativen Ansatzes migrieren erläutert wird.

Diese Alternative ist die einfachste, weil Sie die Datenpipelines mithilfe der vertrauten Plattform Ihres Anbieters in der Cloud bereitstellen. Unter Umständen können Sie auch proprietäre Tools Ihres Anbieters verwenden, um die Migration zwischen der ursprünglichen Umgebung und der neuen Umgebung in Google Cloud zu erleichtern.

Wenn Ihr Anbieter keine Cloud Marketplace-Lösung anbietet, sein Produkt aber auf Kubernetes ausgeführt werden kann, ist es möglich, Ihre Pipelines mit Google Kubernetes Engine (GKE) zu hosten. Dazu müssen Sie folgende Arbeitsschritte ausführen:

• Erstellen Sie einen GKE-Cluster. Folgen Sie den Empfehlungen Ihres Anbieters, damit das Drittanbieter-Produkt die Vorteile der von Kubernetes bereitgestellten Aufgabenparallelisierung nutzt.
• Installieren Sie die Drittanbieter-Software auf Ihrem GKE-Cluster. Folgen Sie dabei den Empfehlungen des Anbieters.
• Wählen Sie Ihre Anwendungsfälle aus und migrieren Sie diese anhand des iterativen Ansatzes, der unter Data Warehouses zu BigQuery migrieren: Übersicht erläutert wird.

Diese Alternative stellt einen Mittelweg in Bezug auf die Komplexität dar. Dabei wird die anbieternative Unterstützung für Kubernetes genutzt, um die Ausführung Ihrer Pipelines zu skalieren und zu parallelisieren. Allerdings müssen Sie dazu einen GKE-Cluster erstellen und verwalten.

Wenn Ihr Anbieter Kubernetes nicht unterstützt, müssen Sie seine Software auf einem Pool von VMs installieren, um das Skalieren und Parallelisieren der Arbeit zu ermöglichen. Falls die Software Ihres Anbieters die Verteilung der Arbeit auf mehrere VMs nativ unterstützt, fassen Sie mit diesen bereitgestellten Funktionen die VM-Instanzen möglichst zu einer verwalteten Instanzgruppe (Managed Instance Group, MIG) zusammen, um Ressourcen bedarfsgesteuert herunter- und hochzuskalieren.

Die Parallelisierung der Arbeit ist keine triviale Aufgabe. Wenn Ihr Anbieter keine Funktionen zum Verteilen von Aufgaben auf verschiedene VMs bereitstellt, empfehlen wir die Verwendung eines Musters für Aufgabenfarmen, um die Arbeit auf VMs in einer MIG zu verteilen. Das folgende Diagramm veranschaulicht diesen Ansatz.

Abbildung 9. Verwaltete Instanzgruppe (MIG) mit drei VMs.

In diesem Diagramm führt jede VM in der MIG die Pipelinesoftware des Drittanbieters aus. Sie können eine Pipelineausführung auf verschiedene Arten auslösen:

• Automatisch mithilfe von Cloud Scheduler, Cloud Composer oder einem Cloud Storage-Trigger, wenn neue Daten in einem Cloud Storage-Bucket ankommen
• Programmgesteuert durch Aufrufen eines Cloud Endpoints bzw. einer Cloud Function oder mithilfe der Pub/Sub API
• Manuell durch Platzieren einer neuen Nachricht in einem Pub/Sub-Thema mit der Google Cloud CLI

Im Grunde senden diese Methoden alle eine Nachricht an ein vordefiniertes Pub/Sub-Thema. Sie erstellen einen einfachen Agent, der in jeder VM installiert wird. Der Agent überwacht ein oder mehrere Pub/Sub-Themen. Jedes Mal, wenn eine Nachricht im Thema ankommt, ruft der Agent die Nachricht aus dem Thema ab, startet eine Pipeline in der Drittanbieter-Software und wartet auf deren Abschluss. Wenn die Pipeline abgeschlossen ist, ruft der Agent die nächste Nachricht aus den Themen ab, die er überwacht.

In allen Fällen empfehlen wir Ihnen, gemeinsam mit Ihrem Anbieter dafür zu sorgen, dass die jeweiligen Lizenzbedingungen eingehalten werden und Ihre Pipelines in Google Cloud funktionieren.

Datenpipelines zur Verwendung von Google Cloud-verwalteten Diensten umschreiben

Sie könnten in einigen Fällen auch einen Teil Ihrer vorhandenen Datenpipelines umschreiben, um neue Frameworks und Dienste zu nutzen, die vollständig in Google Cloud verwaltet werden. Diese Möglichkeit eignet sich gut, wenn Ihre vorhandenen Pipelines ursprünglich mit Technologien implementiert wurden, die jetzt verworfen sind, oder wenn absehbar ist, dass die Portierung und weitere Pflege dieser Pipelines im unveränderten Zustand in der Cloud zu unpraktisch oder zu teuer wäre.

In den folgenden Abschnitten werden vollständig verwaltete Google Cloud-Dienste vorgestellt, mit denen Sie erweiterte Datentransformationen in großem Maßstab ausführen können: Cloud Data Fusion und Dataflow.

Cloud Data Fusion

Cloud Data Fusion basiert auf dem CDAP und ist ein vollständig verwalteter Datenintegrationsdienst zum Erstellen und Verwalten von Datenpipelines über eine grafische Benutzeroberfläche.

Zum Entwickeln der Datenpipelines in der Cloud Data Fusion-UI verbinden Sie Quellen mit Transformationen, Senken und anderen Knoten, um einen DAG zu erstellen. Wenn Sie die Datenpipeline bereitstellen, wandelt der Cloud Data Fusion-Planer diesen DAG in eine Reihe paralleler Berechnungen um, die als Apache Spark-Job in Dataproc ausgeführt werden.

Bei Verwendung von Cloud Data Fusion können Sie mithilfe der JDBC-Treiber (Java Database Connectivity) eine Verbindung zur Datenbank eines Quellsystems herstellen, um Daten zu lesen, zu transformieren und in ein Ziel Ihrer Wahl wie BigQuery zu laden, ohne Code schreiben zu müssen. Dazu laden Sie einen JDBC-Treiber in Ihre Cloud Data Fusion-Instanz hoch und konfigurieren ihn so, dass Sie ihn in Ihren Datenpipelines verwenden können. Weitere Informationen finden Sie in der Anleitung JDBC-Treiber mit Cloud Data Fusion verwenden.

Cloud Data Fusion stellt Plug-ins für Quellen, Transformationen, Aggregate, Senken, Fehlererfassung, Benachrichtigungsveröffentlichung, Aktionen sowie Aktionen nach der Ausführung als anpassbare Komponenten bereit. Vordefinierte Plug-ins bieten Zugriff auf eine Vielzahl von Datenquellen. Wenn kein Plug-in vorhanden ist, können Sie mithilfe der Plug-in APIs von Cloud Data Fusion ein eigenes Plug-in erstellen. Weitere Informationen finden Sie unter Plug-in-Übersicht.

Mit Cloud Data Fusion-Pipelines lassen sich sowohl Batch- als auch Streaming-Datenpipelines erstellen. Da Datenpipelines Zugriff auf Logs und Messwerte bereitstellen, haben Administratoren außerdem die Möglichkeit, ihre Datenverarbeitungs-Workflows ohne Zuhilfenahme von benutzerdefinierten Tools zu operationalisieren.

Lesen Sie zuerst die Cloud Data Fusion-Konzepte im "Überblick". Praktische Beispiele finden Sie in der Kurzanleitung und in der Anleitung zum Erstellen einer Pipeline für Targeting-Kampagnen.

Dataflow

Dataflow ist ein vollständig verwalteter Dienst zum Ausführen umfangreicher Apache Beam-Jobs. Apache Beam ist ein Open Source Framework, das zahlreiche Windowing- und Sitzungsanalyse-Primitive sowie ein Connector-System für Quellen und Senken bietet, einschließlich eines Connectors für BigQuery. Mit Apache Beam können Sie Daten sowohl im Streamingmodus (Echtzeitdaten) als auch im Batchmodus (Verlaufsdaten) mit gleicher Zuverlässigkeit und Ausdruckskraft transformieren und anreichern.

Dank des serverlosen Ansatzes von Dataflow entfällt der operative Aufwand, da Aspekte wie Leistung, Skalierung, Verfügbarkeit, Sicherheit und Compliance automatisch behandelt werden. So können Sie sich auf das Programmieren konzentrieren und müssen sich nicht um die Verwaltung von Serverclustern kümmern.

Sie können Cloud Dataflow-Jobs entweder über die Befehlszeile, das Java SDK oder das Python SDK senden. Außerdem entwickeln wir ein Portabilitäts-Framework, um vollständige Interoperabilität zwischen allen SDKs und Runnern bereitzustellen.

Wenn Sie Ihre Datenabfragen und Pipelines von anderen Frameworks zu Apache Beam und Dataflow migrieren möchten, lesen Sie die Informationen zum Programmiermodell für Apache Beam und die offizielle Dataflow-Dokumentation.

Praktische Beispiele finden Sie in den Kurzanleitungen und Anleitungen für Dataflow.

Orchestrierung und Planung

Im Allgemeinen ist Orchestrierung die automatisierte Koordination mehrerer Systeme, während sich Planung auf die automatisierte Auslösung der Orchestrierungsarbeit bezieht.

• Verkleinert: Eine Datenpipeline ist selbst eine Orchestrierung von Datentransformationen, die durch einen DAG beschrieben werden. Dieser ist ein Datenverarbeitungs-DAG.
• Vergrößert: Wenn eine Datenpipeline von der Ausgabe anderer Datenpipelines abhängt, müssen mehrerer Pipelines orchestriert werden. Jede Pipeline stellt einen Unter-DAG in einem größeren DAG dar. Dieser ist ein Orchestrierungs-DAG.

Diese Konfiguration ist für den Data-Warehouse-Prozess typisch. Abbildung 1 im ETL-Abschnitt zeigt eine Beispielkonfiguration. In den folgenden Abschnitten steht die Orchestrierung mehrerer Datenpipelines im Mittelpunkt.

Abhängigkeiten

Abhängigkeiten können Fan-in-Abhängigkeiten sein, wobei mehrere Datenpipelines am Scheitelpunkt eines Orchestrierungs-DAG zusammengeführt werden, oder Fan-out-Abhängigkeiten, wobei eine einzelne Datenpipeline mehrere andere auslöst. Oft sind diese auch kombiniert, wie im folgenden Diagramm gezeigt.

Abbildung 10. Kombinierte Fan-In- und Fan-Out-Abhängigkeiten.

In suboptimalen Umgebungen gehen einige Abhängigkeiten auf Einschränkungen zurück, die sich aus der Menge der verfügbaren Ressourcen ergeben. Beispiel: Eine Datenpipeline wird ausgeführt und generiert einige allgemeine Daten als Nebenprodukt. Andere Datenpipelines hängen von diesen allgemeinen Daten ab, um eine Neuberechnung zu vermeiden. Allerdings sind diese nicht mit der Datenpipeline verbunden, die die Daten erstellt hat. Wenn bei dieser ersten Pipeline funktionale oder nicht funktionale Probleme auftreten, werden Fehler auf ihre abhängigen Datenpipelines übertragen. Dort erzwingen diese im besten Fall, dass die abhängigen Datenpipelines warten, oder verhindern im schlimmsten Fall, dass sie überhaupt ausgeführt werden. Dies wird im folgenden Diagramm gezeigt.

Abbildung 11. Fehler, die von einer Datenpipeline übertragen werden und die Ausführung abhängiger Pipelines verhindern

In Google Cloud steht Ihnen eine Fülle von Computing-Ressourcen und speziellen Tools zur Verfügung, mit denen Sie die Ausführung Ihrer Pipelines und deren Orchestrierung optimieren können. In den verbleibenden Abschnitten werden diese Ressourcen und Tools beschrieben.

Arbeitsschritte bei der Migration

Es empfiehlt sich, die Orchestrierungsanforderungen zu vereinfachen. Die Komplexität Ihrer Orchestrierung steigt mit der Anzahl der Abhängigkeiten zwischen den Datenpipelines. Die Migration zu Google Cloud ist eine gute Gelegenheit, um Ihre Orchestrierungs-DAG zu untersuchen, Abhängigkeiten zu ermitteln und Möglichkeiten zum Optimieren dieser Abhängigkeiten zu bestimmen.

Zum Optimieren der Abhängigkeiten empfehlen wir eine schrittweise Vorgehensweise:

1. Verschieben Sie in der ersten Iteration die Orchestrierung unverändert zu Google Cloud.
2. Analysieren Sie in späteren Iterationen die Abhängigkeiten und parallelisieren Sie sie, sofern möglich.
3. Organisieren Sie schließlich die Orchestrierung neu, indem Sie häufige Aufgaben in deren eigene DAGs extrahieren.

Im nächsten Abschnitt wird diese Methode anhand eines praktischen Beispiels erläutert.

Praxisbeispiel

Angenommen, eine Organisation hat zwei zusammengehörige Pipelines:

• Die erste Pipeline berechnet die Gewinne und Verluste (GuV) für die gesamte Organisation. Die Pipeline ist komplex und umfasst viele Transformationen. Ein Teil der Pipeline besteht aus der Berechnung der monatlichen Umsatzzahlen, die in nachfolgenden Transformationsschritten verwendet und schließlich in eine Tabelle geschrieben werden.
• Die zweite Pipeline berechnet das Umsatzwachstum für verschiedene Produkte im Vergleich zum Vorjahr und zum Vormonat, damit die Marketingabteilung ihre Werbekampagnen optimieren kann. Diese Pipeline benötigt die monatlichen Umsatzdaten, die zuvor von der GuV-Datenpipeline berechnet wurden.

Die Organisation misst der GuV-Datenpipeline eine höhere Priorität bei als der Marketingpipeline. Da die GuV-Datenpipeline komplex ist, beansprucht sie sehr viele Ressourcen, sodass andere Pipelines nicht gleichzeitig ausgeführt werden können. Außerdem können die Marketingpipeline und andere abhängige Pipelines bei einem Fehler in der GuV-Datenpipeline nicht ausgeführt werden, da ihnen die benötigten Daten fehlen. Sie müssen warten, bis die GuV-Datenpipeline neu ausgeführt wird. Das folgende Diagramm veranschaulicht diese Situation.

Abbildung 12. Komplexe Datenpipelines können die Ausführung von Pipelines mit niedrigerer Priorität verhindern.

Die Organisation führt eine Migration zu BigQuery aus. Sie hat die zwei Anwendungsfälle identifiziert – GuV und Marketing-Umsatzwachstum – und in den Migrationsrückstand aufgenommen. Bei der Planung der nächsten Iteration priorisiert die Organisation den GuV-Anwendungsfall und nimmt ihn in den Iterationsrückstand auf, da er stark durch die aktuellen lokalen Ressourcen eingeschränkt wird und regelmäßig Verzögerungen verursacht. Einige der davon abhängigen Anwendungsfälle werden ebenfalls aufgenommen, darunter der Marketinganwendungsfall.

Das Migrationsteam führt die erste Iteration aus. Es entscheidet sich für einen Weiterleitungsansatz, um sowohl den GuV- als auch den Marketinganwendungsfall zu Google Cloud zu verschieben. Das Team nimmt keine Änderungen an den Pipelineschritten oder der Orchestrierung vor. Ein wichtiger Unterschied besteht darin, dass der GuV-Pipeline jetzt nahezu unbegrenzte Rechenleistung zur Verfügung steht und sie daher viel schneller ausgeführt wird als in der lokalen Umgebung. Die Pipeline schreibt die monatlichen Umsatzdaten in eine BigQuery-Tabelle, die von der Marketingpipeline für Umsatzwachstum verwendet wird. Das folgende Diagramm veranschaulicht diese Änderungen.

Abbildung 13. Beschleunigen einer komplexen Datenpipeline mithilfe eines Weiterleitungsansatzes

Obwohl Google Cloud bei den nicht funktionalen GuV-Problemen hilfreich war, bleiben die funktionalen Probleme bestehen. Einige unabhängige Aufgaben, die der Berechnung der monatlichen Umsatzzahlen vorausgehen, verursachen häufig Fehler. Diese verhindern wiederum, dass die Berechnung ausgeführt wird, und bewirken damit, dass die abhängigen Pipelines nicht gestartet werden können.

In einer zweiten Iteration versucht das Team, eine Leistungssteigerung zu erzielen. Dazu werden beide Anwendungsfälle in den Iterationsrückstand aufgenommen. Das Team identifiziert die Pipelineschritte zum Berechnen der monatlichen Umsatzzahlen in der GuV-Pipeline. Die Schritte stellen einen Unter-DAG dar, wie im nächsten Diagramm gezeigt. Das Migrationsteam kopiert den Unter-DAG in die Marketingpipeline, sodass diese Pipeline unabhängig von der GuV-Pipeline ausgeführt werden kann. Wenn in Google Cloud ausreichend Rechenleistung zur Verfügung steht, können beide Pipelines gleichzeitig ausgeführt werden.

Abbildung 14. Pipelines, die gleichzeitig mithilfe eines Unter-DAG ausgeführt werden.

Der Nachteil ist, dass das Duplizieren der Unter-DAG-Logik einen zusätzlichen Aufwand bei der Codeverwaltung verursacht, da das Team nun beide Exemplare der Unter-DAG-Logik synchronisieren muss.

In einer dritten Iteration prüft das Team die Anwendungsfälle noch einmal und extrahiert den Unter-DAG für die monatlichen Umsatzzahlen in eine unabhängige Pipeline. Wenn die neue Pipeline für die monatlichen Umsatzzahlen fertig ist, löst sie per Fan-out die Pipelines für die GuV, das Marketing-Umsatzwachstum und andere abhängige Pipelines aus. Durch diese Konfiguration wird ein neuer DAG für die gesamte Orchestrierung erstellt, wobei jede der Pipelines einen der zugehörigen Unter-DAG darstellt.

Abbildung 15. DAG für die gesamte Orchestrierung mit jeder Pipeline in einem eigenen Unter-DAG

In den folgenden Iterationen kann das Migrationsteam alle verbleibenden funktionalen Probleme lösen und die Pipelines migrieren, um unter anderem die folgenden Google Cloud-verwalteten Dienste zu nutzen:

• Dataflow: Ermöglicht, jede Datenpipeline mithilfe des Beam-Modells als eigenständigen DAG zu definieren.
• Cloud Composer: Ermöglicht, die gesamte Orchestrierung als einen oder mehrere Airflow-DAG zu definieren.

Auch wenn Airflow Unter-DAG nativ unterstützt, kann diese Funktionalität die Leistung beeinträchtigen. Daher wird davon abgeraten. Verwenden Sie stattdessen unabhängige DAGs mit dem Operator TriggerDagRunOperator.

Nächste Schritte

Mehr über die folgenden Schritte bei der Data Warehouse-Migration erfahren:

• Übersicht über die Migration
• Migrationsbewertung
• Schema- und Datenübertragung
• Batch-SQL-Übersetzung
• Interaktive SQL-Übersetzung
• Datensicherheit und Governance
• Datenvalidierungstool

Außerdem erfahren Sie, wie Sie von bestimmten Data Warehouse-Technologien zu BigQuery wechseln:

• Von Netezza migrieren
• Migration von Oracle
• Von Amazon Redshift migrieren
• Von Teradata migrieren
• Von Snowflake migrieren