Anwendungsfälle für die Notfallwiederherstellung: Datenanalyseanwendungen mit Standortbeschränkung

Last reviewed 2022-01-07 UTC

Dieses Dokument ist Teil einer Reihe zur Notfallwiederherstellung (Disaster Recovery, DR) in Google Cloud. In diesem Dokument wird beschrieben, wie Sie die Standorteinschränkungen aus dem Dokument Architektur der Notfallwiederherstellung von Arbeitslasten mit Standortbeschränkung entwickeln auf Datenanalyseanwendungen anwenden. In diesem Dokument wird insbesondere beschrieben, wie sich die Komponenten, die Sie in einer Datenanalyseplattform verwenden, in eine DR-Architektur einfügen, die den Standortbeschränkungen entspricht, denen Ihre Anwendungen oder Daten möglicherweise unterliegen.

Die Reihe besteht aus folgenden Teilen:

Dieses Dokument richtet sich an Systemarchitekten und IT-Manager. Dabei werden folgende Kenntnisse und Fähigkeiten vorausgesetzt:

Anforderungen an die Lokalität für eine Datenanalyseplattform

Datenanalyseplattformen sind in der Regel komplexe, mehrstufige Anwendungen, die inaktive Daten speichern. Diese Anwendungen erzeugen Ereignisse, die in Ihrem Analysesystem verarbeitet und gespeichert werden. Sowohl die Anwendung selbst als auch die im System gespeicherten Daten unterliegen möglicherweise Standortbestimmungen. Diese Vorschriften variieren nicht nur in verschiedenen Ländern, sondern auch in mehreren Branchen. Daher sollten Sie mit den Anforderungen an den Datenspeicherort vertraut sein, bevor Sie die Entwicklung Ihrer DR-Architektur beginnen.

Sie können feststellen, ob Ihre Datenanalyseplattform Standortanforderungen hat. Beantworten Sie dazu die beiden folgenden Fragen:

  • Muss Ihre Anwendung in einer bestimmten Region bereitgestellt werden?
  • Sind Ihre inaktiven Daten auf eine bestimmte Region beschränkt?

Wenn Sie beide Fragen mit "Nein" beantworten, hat Ihre Datenanalyseplattform keine standortspezifischen Anforderungen. Da Ihre Plattform keine Standortanforderungen hat, folgen Sie der DR-Anleitung für konforme Dienste und Produkte, die im Leitfaden zur Planung der Notfallwiederherstellung beschrieben sind.

Wenn Sie jedoch eine der Fragen mit "Ja" beantworten, gilt die Beschränkung für Ihre Anwendung. Da Ihre Analyseplattform lokal begrenzt ist, müssen Sie sich die folgende Frage stellen: Können Sie Verschlüsselungstechniken verwenden, um die Anforderungen inaktiver Daten zu minimieren?

Wenn Sie Verschlüsselungstechniken verwenden können, können Sie die multiregionalen und dual-regionalen Dienste von Cloud External Key Manager und Cloud Key Management Service verwenden. Sie können dann auch den Standardmethoden für Hochverfügbarkeit und Notfallwiederherstellung (HA/DR) folgen, die unter Szenarien der Notfallwiederherstellung für Daten beschrieben werden.

Wenn Sie keine Verschlüsselungstechniken verwenden können, müssen Sie benutzerdefinierte Lösungen oder Partnerangebote für die DR-Planung verwenden. Weitere Informationen zu Techniken zur Behebung von Standortbeschränkungen für DR-Szenarien finden Sie unter Architektur der Notfallwiederherstellung von Arbeitslasten mit Standortbeschränkung entwickeln.

Komponenten in einer Datenanalyseplattform

Wenn Sie die Anforderungen an den Standort verstehen, besteht der nächste Schritt darin, die Komponenten zu verstehen, die Ihre Datenanalyseplattform verwendet. Gängige Komponenten der Datenanalyseplattform sind Datenbanken, Data Lakes, Verarbeitungspipelines und Data Warehouses, wie in der folgenden Liste beschrieben:

  • Google Cloud bietet eine Reihe von Datenbankdiensten, die für unterschiedliche Anwendungsfälle geeignet sind.
  • Data Lakes, Data Warehouses und Verarbeitungspipelines können geringfügig unterschiedliche Definitionen haben. In diesem Dokument wird eine Reihe von Definitionen verwendet, die auf Google Cloud-Dienste verweisen:
    • Ein Data Lake ist eine skalierbare und sichere Plattform zum Aufnehmen und Speichern von Daten aus mehreren Systemen. Ein typischer Data Lake könnte Cloud Storage als zentrales Speicher-Repository verwenden.
    • Eine Verarbeitungspipeline ist ein durchgängiger Prozess, der Daten oder Ereignisse aus einem oder mehreren Systemen übernimmt, diese Daten oder dieses Ereignis transformiert und in ein anderes System lädt. Die Pipeline kann entweder einem ETL-Prozess (Extrahieren, Transformieren und Laden) oder einem ELT-Prozess (Extrahieren, Laden und Transformieren) folgen. In der Regel ist das System, in das die verarbeiteten Daten geladen werden, ein Data Warehouse. Pub/Sub, Dataflow und Dataproc sind häufig verwendete Komponenten einer Verarbeitungspipeline.
    • Ein Data Warehouse ist ein Unternehmenssystem zur Analyse und Berichterstellung von Daten, das in der Regel aus einer operativen Datenbank stammt. BigQuery ist ein häufig in der Google Cloud ausgeführtes Data Warehouse-System.

Je nach Standortanforderungen und den von Ihnen verwendeten Datenanalysekomponenten variiert die tatsächliche DR-Implementierung. In den folgenden Abschnitten wird diese Variante mit zwei Anwendungsfällen veranschaulicht.

Batch-Anwendungsfall: regelmäßiger ETL-Job

Der erste Anwendungsfall beschreibt einen Batchprozess, bei dem eine Handelsplattform regelmäßig Verkaufsereignisse als Dateien aus verschiedenen Geschäften erfasst und dann die Dateien in einen Cloud Storage-Bucket schreibt. Das folgende Diagramm veranschaulicht die Datenanalysearchitektur für den Batchjob dieses Einzelhändlers.

Architekturdiagramm eines Batch-Anwendungsfalls, der Point-of-Sale-Daten umfasst.

Die Architektur umfasst die folgenden Phasen und Komponenten:

  • Die Aufnahmephase besteht aus den Speichern, die ihre Point-of-Sale-Daten (POS-Daten) an Cloud Storage senden. Die aufgenommenen Daten müssen noch verarbeitet werden.
  • In der Orchestrierungsphase wird Cloud Composer verwendet, um die End-to-End-Batchpipeline zu orchestrieren.
  • Die Verarbeitungsphase umfasst einen Apache Spark-Job, der in einem Dataproc-Cluster ausgeführt wird. Der Apache Spark-Job führt einen ETL-Prozess für die aufgenommenen Daten aus. Dieser ETL-Prozess bietet Geschäftsmesswerte.
  • In der Data Lake-Phase werden die verarbeiteten Daten in den folgenden Komponenten gespeichert:
    • Die verarbeiteten Daten werden in der Regel in Cloud Storage-Spaltenformaten wie Parquet und ORC gespeichert, da diese Formate eine effiziente Speicherung und einen schnelleren Zugriff für analytische Workloads ermöglichen.
    • Die Metadaten zu den Prozessdaten (z. B. Datenbanken, Tabellen, Spalten und Partitionen) werden im Hive-Metastore-Dienst von Dataproc Metastore gespeichert.

In Szenarien mit Standortbeschränkung kann es schwierig sein, eine redundante Verarbeitungs- und Orchestrierungskapazität bereitzustellen, um die Verfügbarkeit aufrechtzuerhalten. Da die Daten in Batches verarbeitet werden, können die Verarbeitungs- und Orchestrierungspipelines neu erstellt und Batchjobs nach der Behebung eines Notfallszenarios neu gestartet werden. Bei der Notfallwiederherstellung liegt der Schwerpunkt daher auf der Wiederherstellung der tatsächlichen Daten: der aufgenommenen POS-Daten, der verarbeiteten Daten im Data Lake und den im Data Lake gespeicherten Metadaten.

In Cloud Storage aufnehmen

Ihre erste Überlegung sollte die Standortanforderungen für den Cloud Storage-Bucket sein, der zur Aufnahme der Daten aus dem POS-System verwendet wird. Verwenden Sie diese Informationen zum Ort, wenn Sie die folgenden Optionen in Betracht ziehen:

  • Wenn die Standortanforderungen zulassen, dass inaktive Daten an einem Multi- oder Dual-Region-Standort gespeichert werden, wählen Sie beim Erstellen des Cloud Storage-Buckets den entsprechenden Standorttyp aus. Der von Ihnen ausgewählte Standorttyp definiert, welche Google Cloud-Regionen zum Replizieren Ihrer inaktiven Daten verwendet werden. Wenn ein Ausfall in einer der Regionen auftritt, sind die Daten, die sich in Multi- oder Dual-Region-Buckets befinden, weiterhin zugänglich.
  • Cloud Storage unterstützt auch sowohl vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) als auch vom Kunden bereitgestellte Verschlüsselungsschlüssel (CSEK). Einige Ortsregeln ermöglichen das Speichern inaktiver Daten an mehreren Standorten, wenn Sie CMEK oder CSEK für die Schlüsselverwaltung verwenden. Wenn Ihre Standortregeln die Verwendung von CMEK oder CSEK zulassen, können Sie die DR-Architektur so entwerfen, dass Cloud Storage-Regionen verwendet werden.
  • Ihre Standortanforderungen erlauben möglicherweise keine Verwendung von Standorttypen oder die Verwaltung von Verschlüsselungsschlüsseln. Wenn Sie keine Standorttypen oder die Verwaltung von Verschlüsselungsschlüsseln verwenden können, können Sie mit dem Befehl gsutil rsync Daten mit einem anderen Standort synchronisieren. Beispiel: Lokale Speicher oder Speicherlösungen eines anderen Cloud-Anbieters.

Wenn ein Notfall eintritt, können die aufgenommenen POS-Daten im Cloud Storage-Bucket Daten enthalten, die noch nicht verarbeitet und in den Data Lake importiert wurden. Alternativ können die POS-Daten möglicherweise nicht in den Cloud Storage-Bucket aufgenommen werden. In diesen Fällen stehen Ihnen die folgenden Optionen zur Notfallwiederherstellung zur Verfügung:

  • Das POS-System wiederholen lassen. Für den Fall, dass das System die POS-Daten nicht in Cloud Storage schreiben kann, schlägt die Datenaufnahme fehl. Zur Behebung dieses Problems können Sie einen gekürzten exponentiellen Backoff-Algorithmus implementieren, damit das POS-System den Datenaufnahmevorgang wiederholen kann. Da der Cloud Storage eine Langlebigkeit von 11 Neunen bietet, werden die Datenaufnahme und die anschließende Verarbeitungspipeline nach der Wiederaufnahme des Cloud-Speicherdienstes mit geringem bis gar keinem Datenverlust fortgesetzt.

  • Kopien von aufgenommenen Daten erstellen. Cloud Storage unterstützt sowohl multi- als auch dualregionale Standorttypen. Abhängig von Ihren Datenlokalitätsanforderungen können Sie möglicherweise einen multi- oder dualregionalen Cloud Storage-Bucket einrichten, um die Datenverfügbarkeit zu erhöhen. Sie können auch Tools wie gsutil verwenden, um Daten zwischen Cloud Storage und einem anderen Speicherort zu synchronisieren.

Orchestrierte und verarbeitete POS-Daten orchestrieren

Im Architekturdiagramm für den Batch-Anwendungsfall führt Cloud Composer die folgenden Schritte aus:

  • Validiert, dass neue Dateien in den Cloud Storage-Aufnahme-Bucket hochgeladen wurden.
  • Startet einen sitzungsspezifischen Dataproc-Cluster.
  • Startet einen Apache Spark-Job zur Verarbeitung der Daten.
  • Löscht den Dataproc-Cluster am Ende des Jobs.

Cloud Composer verwendet Dateien für gerichtete azyklische Graphen (DAG), die diese Reihe von Schritten definieren. Diese DAG-Dateien werden in einem Cloud Storage-Bucket gespeichert, der nicht im Architekturdiagramm angezeigt wird. In Bezug auf multi- und dualregionale Standorte sind die DR-Überlegungen für den DAG-Datei-Bucket die gleichen wie für den Aufnahme-Bucket.

Dataproc-Cluster sind sitzungsspezifisch. Das heißt, die Cluster sind nur so lange vorhanden, wie die Verarbeitungsphase ausgeführt wird. Diese Kurzlebigkeit bedeutet, dass Sie für die Notfallwiederherstellung nicht explizit etwas in Bezug auf die Dataproc-Cluster tun müssen.

Data Lake-Speicher mit Cloud Storage

Der Cloud Storage-Bucket, den Sie für den Data Lake verwenden, hat die gleichen Standortüberlegungen wie die für den Aufnahme-Bucket beschriebenen: Dual- und multiregionale Überlegungen, Verwendung der Verschlüsselung und die Verwendung von gsutil rsync.

Berücksichtigen Sie bei der Entwicklung des DR-Plans für Ihren Data Lake die folgenden Aspekte:

  • Datengröße. Die Datenmenge in einem Data Lake kann sehr groß sein. Die Wiederherstellung eines großen Datenvolumens nimmt Zeit in Anspruch. In einem DR-Szenario müssen Sie berücksichtigen, wie sich das Volumen des Data Lakes auf die Zeit auswirkt, die für die Wiederherstellung
    der Daten bis zu einem Punkt benötigt wird, der die folgenden Kriterien erfüllt:

    Für den aktuellen Batch-Anwendungsfall wird Cloud Storage als Data Lake-Standort verwendet und bietet eine Langlebigkeit von 11 Neunen. Ransomware-Angriffe sind jedoch angestiegen. Damit Sie die Möglichkeit haben, eine Wiederherstellung nach solchen Angriffen zu ermöglichen, ist es sinnvoll, die unter Wie Cloud Storage eine Langlebigkeit von 11 Neunen liefert aufgeführten Best Practices zu beachten.

  • Datenabhängigkeit. Daten in Data Lakes werden in der Regel von anderen Komponenten eines Datenanalysesystems wie einer Verarbeitungspipeline genutzt. In einem DR-Szenario sollte die Verarbeitungspipeline und die Daten, von denen sie abhängig sind, das gleiche RTO haben. Konzentrieren Sie sich in diesem Zusammenhang darauf, wie lange das System nicht verfügbar sein kann.

  • Datenalter. Verlaufsdaten können einen höheren RPO zulassen. Diese Art von Daten wurde möglicherweise bereits von anderen Datenanalysekomponenten analysiert oder verarbeitet und ist möglicherweise in einer anderen Komponente mit eigenen DR-Strategien gespeichert. Beispielsweise werden die in Cloud Storage exportierten Verkaufsdatensätze täglich zur Analyse in BigQuery importiert. Mit den richtigen Strategien zur Notfallwiederherstellung für BigQuery können historische Verkaufsdatensätze, die in BigQuery importiert wurden, niedrigere Wiederherstellungsziele als diejenigen haben, die nicht importiert wurden.

Metadatenspeicher von Data Lakes mit Dataproc Metastore

Dataproc Metastore ist ein Apache Hive-Metastore, der vollständig verwaltet, hochverfügbar und serverlos ist sowie eine automatische Reparatur bietet. Der Metastore bietet Features für die Datenabstraktion und -erkennung. Der Metastore kann im Notfall gesichert und wiederhergestellt werden. Mit dem Dataproc Metastore-Dienst können Sie auch Metadaten exportieren und importieren. Sie können eine Aufgabe hinzufügen, um den Metastore zu exportieren und eine externe Sicherung zusammen mit Ihrem ETL-Job zu verwalten.

Wenn eine Metadatenabweichung auftritt, können Sie den Metastore aus den Daten selbst mit dem Befehl MSCK neu erstellen.

Streaming-Anwendungsfall: Change Data Capture mit ELT

Der zweite Anwendungsfall beschreibt eine Einzelhandelsplattform, die Change Data Capture (CDC) verwendet, um Backend-Inventarsysteme zu aktualisieren und Echtzeitmesswerte für den Vertrieb zu verfolgen. Das folgende Diagramm zeigt eine Architektur, in der Ereignisse aus einer Transaktionsdatenbank wie Cloud SQL verarbeitet und dann in einem Data Warehouse gespeichert werden.

Architekturaufbau eines Streaming-Anwendungsfalls, der die Erfassung von Änderungsdaten von Einzelhandelsdaten umfasst.

Die Architektur umfasst die folgenden Phasen und Komponenten:

  • Die Aufnahmephase besteht aus den eingehenden Änderungsereignissen, die per Push an Pub/Sub übertragen werden. Als Nachrichtenzustellungsdienst wird Pub/Sub verwendet, um Streaminganalysedaten zuverlässig aufzunehmen und zu verteilen. Pub/Sub hat den zusätzlichen Vorteil, dass es sowohl skalierbar als auch serverlos ist.
  • Die Verarbeitungsphase umfasst die Verwendung von Dataflow, um einen ELT-Prozess für die aufgenommenen Ereignisse durchzuführen.
  • In der Data Warehouse-Phase wird BigQuery zum Speichern der verarbeiteten Ereignisse verwendet. Durch die Zusammenführung wird ein Eintrag in BigQuery eingefügt oder aktualisiert. Durch diesen Vorgang können die in BigQuery gespeicherten Informationen mit der Transaktionsdatenbank auf dem neuesten Stand gehalten werden.

Diese CDC-Architektur basiert nicht auf Cloud Composer. Einige CDC-Architekturen erfordern jedoch, dass Cloud Composer die Einbindung des Streams in Batcharbeitslasten orchestriert. In diesen Fällen implementiert der Cloud Composer-Workflow Integritätsprüfungen, Backfills und Projektionen, die aufgrund von Latenzeinschränkungen nicht in Echtzeit durchgeführt werden können. Verfahren zur Notfallwiederherstellung für Cloud Composer werden im Anwendungsfall für Batchverarbeitung erläutert, der weiter oben im Dokument erläutert wurde.

Bei einer Streamingdaten-Pipeline sollten Sie bei der Planung Ihrer DR-Architektur Folgendes berücksichtigen:

  • Pipeline-Abhängigkeiten. Verarbeitungspipelines verwenden Eingaben von einem oder mehreren Systemen (den Quellen). Pipelines verarbeiten, transformieren und speichern diese Inputs dann in anderen Systemen (den Senken). Es ist wichtig, Ihre DR-Architektur so zu gestalten, dass Sie das End-to-End-RTO erreichen. Sie müssen dafür sorgen, dass das RPO der Datenquellen und -senken die Einhaltung des RTO ermöglicht. Sie müssen nicht nur Ihre Cloud-Architektur so gestalten, dass sie Ihren Standortanforderungen entspricht, sondern auch Ihre Ursprungs-CDC-Quellen so entwerfen, dass Ihre End-to-End-RTO erreicht werden kann.
  • Verschlüsselung und Standort. Wenn die Verschlüsselung es Ihnen ermöglicht, Standortbeschränkungen abzuschwächen, können Sie Cloud KMS verwenden, um die folgenden Ziele zu erreichen:
    • Sie können Ihre eigenen Verschlüsselungsschlüssel verwalten.
    • Verschlüsselungsfunktionen einzelner Dienste nutzen
    • Dienste in Regionen bereitstellen, die aufgrund von Standortbeschränkungen andernfalls nicht verfügbar wären.
  • Standortsregeln für Daten bei der Übertragung: Einige Ortsregeln gelten möglicherweise nur für inaktive Daten, nicht aber für Daten bei der Übertragung. Wenn Ihre Standortsregeln nicht auf Daten bei der Übertragung angewendet werden, entwerfen Sie Ihre DR-Architektur so, dass Ressourcen in anderen Regionen genutzt werden, um die Wiederherstellungsvorgaben zu verbessern. Sie können den regionalen Ansatz ergänzen. Binden Sie dazu die Verschlüsselungstechniken ein.

Aufnahme in Pub/Sub

Wenn keine Standortbeschränkungen gelten, können Sie Nachrichten im globalen Pub/Sub-Endpunkt veröffentlichen. Globale Pub/Sub-Endpunkte sind sichtbar und von jedem Google Cloud-Standort aus zugänglich.

Wenn Ihre Standortanforderungen die Verwendung von Verschlüsselung zulassen, ist es möglich, Pub/Sub so zu konfigurieren, dass ein ähnlicher Grad an Hochverfügbarkeit erreicht wird wie bei globalen Endpunkten. Obwohl Pub/Sub-Nachrichten standardmäßig mit von Google verwalteten Schlüsseln verschlüsselt werden, können Sie Pub/Sub so konfigurieren, dass stattdessen CMEK verwendet wird. Wenn Sie Pub/Sub mit CMEK verwenden, können Sie Standortregeln zur Verschlüsselung erfüllen und gleichzeitig hohe Verfügbarkeit aufrechterhalten.

Einige Ortsregeln erfordern, dass Nachrichten auch nach der Verschlüsselung an einem bestimmten Standort verbleiben. Wenn Ihre Standortsregeln diese Einschränkung haben, können Sie die Richtlinie für die Nachrichtenspeicherung eines Pub/Sub-Themas angeben und auf eine Region beschränken. Bei diesem Nachrichtenspeicheransatz werden Nachrichten, die zu einem Thema veröffentlicht werden, niemals außerhalb der von Ihnen angegebenen Google Cloud-Regionen gespeichert. Wenn Ihre Standortregeln die Verwendung von mehreren Google Cloud-Regionen zulassen, können Sie die Dienstverfügbarkeit erhöhen. Aktivieren Sie dazu diese Regionen im Pub/Sub-Thema. Beachten Sie, dass die Implementierung einer Nachrichtenspeicherrichtlinie zur Einschränkung von Pub/Sub-Ressourcenstandorten Kompromisse bei der Verfügbarkeit mit sich bringt.

Mit einem Pub/Sub-Abo können Sie unbestätigte Nachrichten bis zu sieben Tage lang ohne Einschränkungen der Anzahl der Nachrichten speichern. Wenn Ihr Service Level Agreement verzögerte Daten zulässt, können Sie die Daten in Ihrem Pub/Sub-Abo puffern, wenn die Pipelines nicht mehr ausgeführt werden. Wenn die Pipelines wieder ausgeführt werden, können Sie die gesicherten Ereignisse verarbeiten. Dieses Design hat den Vorteil eines niedrigen RPO-Werts. Weitere Informationen zu den Ressourcenlimits für Pub/Sub finden Sie unter Ressourcenlimits für Pub/Sub-Kontingente.

Ereignisverarbeitung mit Dataflow

Dataflow ist ein verwalteter Dienst zur Ausführung eines breiten Spektrums an Datenverarbeitungsmustern. Das Apache Beam SDK ist ein Open-Source-Programmiermodell, mit dem Sie sowohl Batch- als auch Streaming-Pipelines entwickeln können. Sie erstellen Ihre Pipelines mit einem Apache Beam-Programm und führen sie dann im Dataflow-Dienst aus.

Berücksichtigen Sie beim Entwerfen von Standorteinschränkungen, wo sich Ihre Quellen, Senken und temporären Dateien befinden. Wenn sich diese Dateispeicherorte außerhalb der Region Ihres Jobs befinden, werden Ihre Daten möglicherweise über Regionen hinweg gesendet. Wenn Ihre Standortregeln die Verarbeitung von Daten an einem anderen Standort zulassen, entwerfen Sie Ihre DR-Architektur so, dass Worker in anderen Google Cloud-Regionen für Hochverfügbarkeit bereitgestellt werden.

Wenn Ihre Standorteinschränkungen die Verarbeitung auf einen einzelnen Standort beschränken, können Sie einen Dataflow-Job erstellen, der auf eine bestimmte Region oder Zone beschränkt ist. Wenn Sie einen Dataflow-Job senden, können Sie die Parameter für den regionalen Endpunkt, die Arbeitsregion und die Arbeitszone angeben. Diese Parameter steuern, wo Worker bereitgestellt werden und wo Jobmetadaten gespeichert werden.

Apache Beam bietet ein Framework, das das Ausführen von Pipelines über verschiedene Runner hinweg ermöglicht. Sie können Ihre DR-Architektur so gestalten, dass Sie diese Funktion nutzen können. Sie könnten zum Beispiel eine DR-Architektur mit einer Sicherungspipeline entwerfen, die auf Ihrem lokalen Spark-Cluster unter Verwendung von Apache Spark Runner ausgeführt wird. Informationen dazu, ob ein bestimmter Runner einen bestimmten Pipelinevorgang ausführen kann, finden Sie in der Beam Capability Matrix.

Wenn die Verschlüsselung es Ihnen ermöglicht, Standortsbeschränkungen abzuschwächen, können Sie CMEK in Dataflow verwenden, um sowohl Pipeline-Zustandsartefakte zu verschlüsseln als auch auf Quellen und Senken zuzugreifen, die mit Cloud KMS-Schlüsseln geschützt sind. Mithilfe der Verschlüsselung können Sie eine Architektur zur Notfallwiederherstellung entwickeln, die Regionen verwendet, die aufgrund von Standortbeschränkungen ansonsten nicht verfügbar wären.

Auf BigQuery basierendes Data Warehouse

Data Warehouses unterstützen Analysen und Entscheidungsfindung. Neben einer analytischen Datenbank enthalten Data Warehouses mehrere analytische Komponenten und Verfahren.

Berücksichtigen Sie beim Entwerfen des DR-Plans für Ihr Data Warehouse die folgenden Eigenschaften:

  • Größe. Data Warehouses sind viel größer als OLTP-Systeme (Online Transaction Processing). Es ist nicht unüblich, dass Data Warehouses Terabyte oder Petabyte an Daten haben. Sie müssen berücksichtigen, wie lange es dauert, diese Daten wiederherzustellen, um Ihre RPO- und RTO-Werte zu erreichen. Bei der Planung Ihrer Notfallwiederherstellungsstrategie müssen Sie auch die Kosten berücksichtigen, die mit der Wiederherstellung von Terabyte von Daten verbunden sind. Weitere Informationen zu Schutzmaßnahmen zur Notfallwiederherstellung für BigQuery finden Sie in den BigQuery-Informationen im Abschnitt Sicherungs- und Wiederherstellungsverfahren für die verwalteten Datenbankdienste in Google Cloud.

  • Verfügbarkeit: Beim Erstellen eines BigQuery-Datasets wählen Sie einen Speicherort für Ihre Daten aus: regional oder multiregional. Ein regionaler Standort ist ein einzelner, geografischer Standort, z. B. Iowa (us-central1) oder Montreal (northamerica-northeast1). Ein multiregionaler Standort ist ein großes geografisches Gebiet wie die USA (USA) oder Europa (EU), das mindestens zwei geografische Bereiche enthält.

    Bei der Entwicklung Ihres DR-Plans zur Einhaltung von Standortbeschränkungen hat die fehlerhafte Domain (d. h. ob der Ausfall auf Rechnerebene, zonal oder regional auftritt) direkte Auswirkungen auf die Einhaltung Ihres definierten RTO. Weitere Informationen zu diesen fehlerhaften Domains und deren Auswirkung auf die Verfügbarkeit finden Sie unter Verfügbarkeit und Langlebigkeit von BigQuery.

  • Die Art der Daten. Data Warehouses enthalten Verlaufsdaten und die meisten älteren Daten sind häufig statisch. Viele Data Warehouses sind so konzipiert, dass sie nur mit Anhängen arbeiten. Wenn Ihr Data Warehouse nur mit Anhängen arbeitet, können Sie Ihr RTO möglicherweise dadurch erreichen, dass Sie nur die Daten wiederherstellen, die gerade angehängt werden. Bei diesem Ansatz sichern Sie nur diese angehängten Daten. Im Falle eines Notfalls können Sie dann die angehängten Daten wiederherstellen und Ihr Data Warehouse mit einer Teilmenge der Daten nutzen.

  • Datenmuster hinzufügen und aktualisieren. Data Warehouses werden in der Regel mit ETL- oder ELT-Mustern aktualisiert. Wenn Sie kontrollierte Updatepfade haben, können Sie die neuesten Aktualisierungsereignisse aus alternativen Quellen reproduzieren.

Ihre Standortanforderungen können einschränken, ob Sie eine einzelne Region oder mehrere Regionen für Ihr Data Warehouse verwenden können. BigQuery-Datasets können regional sein. Multiregionale Speicherung ist jedoch die einfachste und kostengünstigste Methode, um die Verfügbarkeit Ihrer Daten im Notfall zu gewährleisten. Wenn die Speicherung in mehreren Regionen in Ihrer Region nicht verfügbar ist, Sie aber eine andere Region verwenden können, verwenden Sie den BigQuery Data Transfer Service, um Ihr Dataset in eine andere Region zu kopieren. Wenn Sie Verschlüsselung verwenden können, um die Anforderungen an den Standort abzuschwächen, können Sie Ihre eigenen Verschlüsselungsschlüssel mit Cloud KMS und BigQuery verwalten.

Wenn Sie nur eine Region verwenden können, sollten Sie die BigQuery-Tabellen sichern. Die kostengünstigste Lösung für Sicherungstabellen ist die Verwendung von BigQuery-Exporten. Verwenden Sie Cloud Scheduler oder Cloud Composer, um regelmäßig einen Exportauftrag zum Schreiben in den Cloud Storage zu planen. Sie können Formate verwenden, z. B. Avro mit SNAPPY-Komprimierung oder JSON mit GZIP-Komprimierung. Beachten Sie beim Entwerfen Ihrer Exportstrategien die Limits für Exporte.

Möglicherweise möchten Sie BigQuery-Sicherungen auch in Spaltenformaten wie Parquet und ORC speichern. Diese bieten eine hohe Komprimierung und ermöglichen außerdem Interoperabilität mit vielen Open-Source-Engines wie Hive und Presto, die Sie möglicherweise in Ihren lokalen Systemen haben. Das folgende Diagramm zeigt, wie Sie BigQuery-Daten in ein Spaltenformat zum Speichern an einem lokalen Speicherort exportieren.

Architekturdiagramm, das den Export von BigQuery-Daten in einen spaltenorientierten Speicher für die Notfallwiederherstellung zeigt.

Dieser Export von BigQuery-Daten an einen lokalen Speicherort umfasst folgende Schritte:

  • Die BigQuery-Daten werden an einen Apache Spark-Job in Dataproc gesendet. Die Verwendung des Apache Spark-Jobs ermöglicht eine Schemaentwicklung.
  • Nachdem der Dataproc-Job die BigQuery-Dateien verarbeitet hat, werden die verarbeiteten Dateien in Cloud Storage geschrieben und dann an einen lokalen DR-Speicherort übertragen.
  • Cloud Interconnect wird verwendet, um Ihr Virtual Private Cloud-Netzwerk mit Ihrem lokalen Netzwerk zu verbinden.
  • Die Übertragung an den lokalen DR-Speicherort kann über den Spark-Job erfolgen.

Wenn Ihr Warehouse-Design nur mit Anhängen arbeitet und nach Datum partitioniert ist, müssen Sie eine Kopie der erforderlichen Partitionen in einer neuen Tabelle erstellen, bevor Sie einen BigQuery-Exportauftrag für die neue Tabelle ausführen. Sie können dann ein Tool wie gsutil verwenden, um die aktualisierten Dateien an Ihren lokalen Sicherungsort oder in eine andere Cloud zu übertragen. (Für die Datenübertragung aus Google Cloud können Gebühren für ausgehenden Traffic anfallen.)

Sie haben beispielsweise ein Data Warehouse für den Vertrieb, das aus einer Tabelle mit ausschließlich orders-Anhängen besteht, in der neue Bestellungen an die Partition angefügt werden, die das aktuelle Datum darstellt. Eine Rückgaberichtlinie kann jedoch die Rückgabe von Artikeln innerhalb von sieben Tagen ermöglichen. Daher können Datensätze in der orders-Tabelle aus den letzten sieben Tagen aktualisiert werden. Bei Ihren Exportstrategien muss die Rückgaberichtlinie berücksichtigt werden. In diesem Beispiel muss jeder Exportjob zum Sichern der orders-Tabelle auch die Partitionen innerhalb der letzten 7 Tage exportieren, um fehlende Aktualisierungen aufgrund von Rückgaben zu vermeiden.

Nächste Schritte