Skalierbare BigQuery-Sicherungsautomatisierung

Last reviewed 2024-09-17 UTC

Diese Architektur bietet ein Framework und eine Referenzbereitstellung, die Ihnen bei der Entwicklung Ihrer BigQuery-Sicherungsstrategie helfen. Dieses empfohlene Framework und seine Automatisierung können Ihrem Unternehmen Folgendes ermöglichen:

  • Beachten Sie die Notfallwiederherstellungsziele Ihrer Organisation.
  • Daten wiederherstellen, die aufgrund menschlicher Fehler verloren gegangen sind.
  • Vorschriften einhalten
  • Betriebseffizienz steigern

Der Umfang der BigQuery-Daten kann Ordner, Projekte, Datasets und Tabellen umfassen (oder ausschließen). Diese empfohlene Architektur zeigt, wie Sie die wiederkehrenden Sicherungsvorgänge im großen Maßstab automatisieren. Sie können für jede Tabelle zwei Sicherungsmethoden verwenden: BigQuery-Snapshots und BigQuery-Exporte in Cloud Storage.

Dieses Dokument richtet sich an Cloud-Architekten, Entwickler und Datengovernance-Beauftragte, die Datenrichtlinien in ihren Organisationen definieren und automatisieren möchten.

Architektur

Das folgende Diagramm zeigt die Architektur der automatischen Sicherung:

Architektur für die automatisierte Sicherungslösung.

Der im vorherigen Diagramm dargestellte Workflow umfasst die folgenden Phasen:

  1. Cloud Scheduler löst über eine Pub/Sub-Nachricht einen Ablauf für den Dispatcherdienst aus. Diese Nachricht enthält den Umfang der ein- und ausgeschlossenen BigQuery-Daten. Die Ausführung wird mithilfe eines Cron-Ausdrucks geplant.
  2. Der Dispatcherdienst, der auf Cloud Run basiert, verwendet die BigQuery API, um die Tabellen aufzulisten, die sich im BigQuery-Umfang befinden.
  3. Der Dispatcherdienst sendet über eine Pub/Sub-Nachricht eine Anfrage für jede Tabelle an den Konfiguratordienst.
  4. Der Cloud Run-Konfigurationsdienst berechnet die Sicherungsrichtlinie der Tabelle anhand einer der folgenden definierten Optionen:

    1. Die Richtlinie auf Tabellenebene, die von den Dateneigentümern definiert wird.
    2. Die vom Datengovernancebeauftragten definierte Fallback-Richtlinie für Tabellen, für die keine Richtlinien definiert sind.

    Weitere Informationen zu Sicherungsrichtlinien finden Sie unter Sicherungsrichtlinien.

  5. Der Konfigurationsservice sendet basierend auf der berechneten Sicherungsrichtlinie eine Anfrage für jede Tabelle an den nächsten Dienst.

  6. Je nach Sicherungsmethode sendet einer der folgenden benutzerdefinierten Cloud Run-Dienste eine Anfrage an die BigQuery API und führt den Sicherungsprozess aus:

    1. Der Dienst für BigQuery-Snapshots sichert die Tabelle als Snapshot.
    2. Der Dienst für Datenexporte sichert die Tabelle als Datenexport in Cloud Storage.
  7. Wenn die Sicherungsmethode ein Tabellendatenexport ist, überwacht eine Cloud Logging-Log-Senke die Ereignisse zum Abschluss der Exportjobs, um die asynchrone Ausführung des nächsten Schritts zu ermöglichen.

  8. Nachdem die Sicherungsdienste ihre Vorgänge abgeschlossen haben, löst Pub/Sub den Tagging-Dienst aus.

  9. Der Tagging-Dienst protokolliert für jede Tabelle die Ergebnisse der Sicherungsdienste und aktualisiert den Sicherungsstatus in der Cloud Storage-Metadatenebene.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud Produkte verwendet:

  • BigQuery: Ein Data Warehouse für Unternehmen, mit dem Sie Ihre Daten mit integrierten Features wie raumbezogenen Analysen für maschinelles Lernen und Business Intelligence verwalten und analysieren können.
  • Cloud Logging: Ein Echtzeit-Log-Verwaltungssystem mit Speicher, Suche, Analyse und Benachrichtigungen.
  • Pub/Sub: Ein asynchroner, skalierbarer Messaging-Dienst, der Dienste entkoppelt, die Nachrichten von Diensten erzeugen, die diese Nachrichten verarbeiten.
  • Cloud Run ist eine serverlose Computing-Plattform, mit der Sie Container direkt auf der skalierbaren Infrastruktur von Google ausführen können.
  • Cloud Storage: Ein kostengünstiger, unbegrenzter Objektspeicher für verschiedene Datentypen. Auf Daten kann von innerhalb und außerhalb von Google Cloudzugegriffen werden. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.
  • Cloud Scheduler: Ein vollständig verwalteter Cronjob-Planer für Unternehmen, mit dem Sie geplante Arbeitseinheiten einrichten können, die zu festgelegten Zeiten oder in regelmäßigen Abständen ausgeführt werden.
  • Datastore: Eine hoch skalierbare NoSQL-Datenbank für Ihre Webanwendungen und mobilen Apps.

Anwendungsfälle

In diesem Abschnitt finden Sie Beispiele für Anwendungsfälle, in denen Sie diese Architektur verwenden können.

Sicherungsautomatisierung

Angenommen, Ihr Unternehmen ist in einer regulierten Branche tätig und verwendet BigQuery als Haupt-Data Warehouse. Selbst wenn Ihr Unternehmen Best Practices in der Softwareentwicklung, Codeüberprüfung und Release-Entwicklung befolgt, besteht immer noch das Risiko von Datenverlust oder Datenbeschädigung aufgrund von menschlichen Fehlern. In einer regulierten Branche müssen Sie dieses Risiko so weit wie möglich minimieren.

Beispiele für solche Fehler:

  • Versehentliches Löschen von Tabellen
  • Datenbeschädigung aufgrund fehlerhafter Logik der Datenpipeline.

Diese Arten von menschlichen Fehlern können in der Regel mit der Zeitreisefunktion behoben werden, mit der Sie Daten von vor bis zu sieben Tagen wiederherstellen können. Darüber hinaus bietet BigQuery eine Fail-Safe-Periode, während der gelöschte Daten nach dem Zeitreisefenster noch sieben weitere Tage im Fail-Safe-Speicher aufbewahrt werden. Diese Daten sind über Cloud Customer Care für die Notfallwiederherstellung verfügbar. Wenn Ihr Unternehmen diese Fehler jedoch nicht innerhalb dieses Zeitraums erkennt und behebt, können die gelöschten Daten nicht mehr aus dem letzten stabilen Zustand wiederhergestellt werden.

Um dies zu vermeiden, empfehlen wir regelmäßige Sicherungen für alle BigQuery-Tabellen, die nicht aus Quelldaten rekonstruiert werden können, z. B. Verlaufsdaten oder KPIs mit sich ändernder Geschäftslogik.

Ihr Unternehmen könnte mithilfe einfacher Scripts Dutzende von Tabellen sichern. Wenn Sie jedoch regelmäßig Hunderte oder Tausende von Tabellen in der gesamten Organisation sichern müssen, benötigen Sie eine skalierbare Automatisierungslösung, die Folgendes bietet:

  • Mit verschiedenen Google Cloud API-Limits umgehen.
  • Bietet ein standardisiertes Framework zum Definieren von Sicherungsrichtlinien.
  • Transparenz und Monitoring-Funktionen für die Sicherungsvorgänge bieten.

Sicherungsrichtlinien

Möglicherweise verlangt Ihr Unternehmen auch, dass die Sicherungsrichtlinien von den folgenden Personengruppen definiert werden:

  • Dateneigentümer, die mit den Tabellen am besten vertraut sind und die entsprechenden Sicherungsrichtlinien auf Tabellenebene festlegen können.
  • Das Data Governance-Team sorgt dafür, dass eine Fallback-Richtlinie für alle Tabellen vorhanden ist, für die keine Richtlinie auf Tabellenebene gilt. Mit der Fallback-Richtlinie wird sichergestellt, dass bestimmte Datensätze, Projekte und Ordner gesichert werden, um die Datenaufbewahrungsvorschriften Ihres Unternehmens einzuhalten.

Bei der Bereitstellung dieser Referenzarchitektur gibt es zwei Möglichkeiten, die Sicherungsrichtlinien für Tabellen zu definieren. Sie können auch kombiniert werden:

  • Konfiguration des Dateneigentümers (dezentralisiert): Eine Sicherungsrichtlinie auf Tabellenebene, die manuell an eine Tabelle angehängt wird.

    • Der Dateninhaber definiert eine JSON-Datei auf Tabellenebene, die in einem gemeinsamen Bucket gespeichert wird.
    • Manuelle Richtlinien haben Vorrang vor Fallback-Richtlinien, wenn die Lösung die Sicherungsrichtlinie einer Tabelle bestimmt.
    • Weitere Informationen zur Bereitstellung finden Sie unter Sicherungsrichtlinien auf Tabellenebene festlegen.
  • Standardkonfiguration der Organisation (zentral): Eine Fallback-Richtlinie, die nur für Tabellen gilt, für die keine manuell angehängten Richtlinien vorhanden sind.

    • Ein Datengovernance-Team definiert im Rahmen der Lösung eine zentrale JSON-Datei in Terraform.
    • Die Fallback-Richtlinie bietet Standardsicherungsstrategien auf Ordner-, Projekt-, Datensatz- und Tabellenebene.
    • Weitere Informationen zur Bereitstellung finden Sie unter Fallback-Sicherungsrichtlinien definieren.

Sicherung im Vergleich zur Replikation

Bei einem Sicherungsprozess wird eine Kopie der Tabellendaten zu einem bestimmten Zeitpunkt erstellt, damit sie wiederhergestellt werden können, falls die Daten verloren gehen oder beschädigt werden. Sicherungen können einmalig oder wiederholt (über eine geplante Abfrage oder einen Workflow) ausgeführt werden. In BigQuery können mithilfe von Snapshots Sicherungen zu einem bestimmten Zeitpunkt erstellt werden. Mit Snapshots können Sie Kopien der Daten über den Zeitraum von sieben Tagen hinaus am selben Speicherort wie die Quelldaten aufbewahren. BigQuery-Snapshots sind besonders hilfreich, um Daten nach menschlichen Fehlern, die zu Datenverlusten oder Beschädigungen führen, wiederherzustellen. Sie eignen sich nicht für die Wiederherstellung nach regionalen Ausfällen. BigQuery bietet je nach Version ein Service Level Objective (SLO) von 99,9% bis 99,99%.

Bei der Replikation werden dagegen kontinuierlich Datenbankänderungen in eine sekundäre (oder Replik-)Datenbank an einem anderen Speicherort kopiert. In BigQuery kann die regionenübergreifende Replikation für Geo-Redundanz sorgen, indem schreibgeschützte Kopien der Daten in sekundären Google Cloud Regionen erstellt werden, die sich von der Region der Quelldaten unterscheiden. Die regionenübergreifende Replikation in BigQuery ist jedoch nicht als Notfallwiederherstellungsplan für Ausfallszenarien für die gesamte Region vorgesehen. Für eine erhöhte Ausfallsicherheit bei regionalen Katastrophen können Sie die von BigQuery verwaltete Notfallwiederherstellung verwenden.

Die regionenübergreifende Replikation in BigQuery bietet eine synchronisierte schreibgeschützte Kopie der Daten in einer Region, die sich in der Nähe der Datennutzer befindet. Diese Datenkopien ermöglichen zusammengeführte Joins und vermeiden regionenübergreifenden Traffic und Kosten. Bei Datenbeschädigungen aufgrund von menschlichem Versagen kann die Replikation jedoch nicht allein zur Wiederherstellung beitragen, da die beschädigten Daten automatisch in das Replikat kopiert werden. In solchen Fällen sind Zeitpunktsicherungen (Snapshots) die bessere Wahl.

In der folgenden Tabelle finden Sie einen zusammengefassten Vergleich der Sicherungsmethoden und der Replikation:

Methode Häufigkeit Storage-Speicherort Anwendungsfälle Kosten
Sicherung

(Snapshots oder Cloud Storage-Export)
Einmalig oder wiederholt Entspricht den Daten der Quelltabelle Ursprüngliche Daten über den Zeitraum der Zeitreise hinaus wiederherstellen Für Snapshots fallen nur Speicherkosten für Datenänderungen im Snapshot an.

Für Exporte können standardmäßige Speicherkosten anfallen.

Weitere Informationen finden Sie unter Kostenoptimierung.
Regionenübergreifende Replikation Kontinuierlich Remote Replikat in einer anderen Region erstellen

Einmalige Migrationen zwischen Regionen
Es fallen Gebühren für das Speichern von Daten im Replika an.

Es fallen Kosten für die Datenreplikation an.

Designaspekte

Dieser Abschnitt enthält eine Anleitung, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, Kostenoptimierung, operative Effizienz und Leistung entspricht.

Sicherheit, Datenschutz und Compliance

Die Bereitstellung umfasst die folgenden Sicherheitsmaßnahmen in ihrem Design und ihrer Implementierung:

  • Die Einstellung für den Netzwerk-Ingress für Cloud Run akzeptiert nur internen Traffic, um den Zugriff über das Internet einzuschränken. Außerdem können nur authentifizierte Nutzer und Dienstkonten die Dienste aufrufen.
  • Für jeden Cloud Run-Dienst und jedes Pub/Sub-Abo wird ein separates Dienstkonto verwendet, dem nur die erforderlichen Berechtigungen zugewiesen sind. So werden die Risiken minimiert, die mit der Verwendung eines Dienstkontos für das System verbunden sind, und der Grundsatz der geringsten Berechtigung wird befolgt.

Aus Datenschutzgründen werden mit der Lösung keine personenidentifizierbaren Informationen erhoben oder verarbeitet. Wenn die Quelltabellen jedoch personenbezogene Daten enthalten, sind diese Daten auch in den Sicherungen dieser Tabellen enthalten. Der Inhaber der Quelldaten ist für den Schutz aller personenidentifizierbaren Informationen in den Quelltabellen verantwortlich. Dazu kann er beispielsweise Sicherheit auf Spaltenebene, Datenmaskierung oder Entfernung von Daten anwenden. Die Sicherungen sind nur dann sicher, wenn die Quelldaten gesichert sind. Ein weiterer Ansatz besteht darin, dafür zu sorgen, dass Projekte, Datensätze oder Buckets, die Sicherungsdaten mit freigelegten personenidentifizierbaren Informationen enthalten, die erforderlichen IAM-Richtlinien (Identity and Access Management) haben, die den Zugriff auf autorisierte Nutzer beschränken.

Als Lösung für allgemeine Zwecke entspricht die Referenzimplementierung nicht unbedingt den spezifischen Anforderungen einer bestimmten Branche.

Zuverlässigkeit

In diesem Abschnitt werden Funktionen und Designüberlegungen für die Zuverlässigkeit beschrieben.

Fehlerbehebung mit Detaillierung

Wenn Sie Sicherungen von Tausenden von Tabellen erstellen, werden Sie wahrscheinlich die API-Limits für die zugrunde liegenden Google Cloud Produkte erreichen (z. B. die Limits für die Vorgänge Snapshot und Export für jedes Projekt). Wenn die Sicherung einer Tabelle jedoch aufgrund einer Fehlkonfiguration oder anderer vorübergehender Probleme fehlschlägt, sollte dies die Gesamtausführung und die Möglichkeit zur Sicherung anderer Tabellen nicht beeinträchtigen.

Um potenzielle Fehler zu vermeiden, werden bei der Referenzbereitstellung die Verarbeitungsschritte entkoppelt, indem detaillierte Cloud Run-Dienste verwendet und über Pub/Sub verbunden werden. Wenn eine Anfrage zum Sichern einer Tabelle im letzten Schritt des Tagging-Dienstes fehlschlägt, versucht Pub/Sub nur diesen Schritt noch einmal und nicht den gesamten Vorgang.

Wenn Sie den Ablauf in mehrere Cloud Run-Dienste unterteilen, anstatt mehrere Endpunkte in einem Cloud Run-Dienst zu hosten, können Sie die einzelnen Dienstkonfigurationen detaillierter steuern. Die Konfigurationsebene hängt von den Funktionen des Dienstes und den APIs ab, mit denen er kommuniziert. Der Dispatcher-Dienst wird beispielsweise einmal pro Ausführung ausgeführt, es dauert jedoch sehr lange, bis alle Tabellen im BigQuery-Sicherungsumfang aufgelistet sind. Daher sind für den Dispatcherdienst längere Zeitüberschreitungen und Speichereinstellungen erforderlich. Der Cloud Run-Dienst für BigQuery-Snapshots wird jedoch einmal pro Tabelle in einem einzigen Durchlauf ausgeführt und ist schneller als der Dispatcher-Dienst. Daher sind für den Cloud Run-Dienst andere Konfigurationen auf Dienstebene erforderlich.

Datenkonsistenz

Die Datenkonsistenz in Tabellen und Ansichten ist entscheidend für eine zuverlässige Sicherungsstrategie. Da Daten kontinuierlich aktualisiert und geändert werden, können Sicherungen, die zu unterschiedlichen Zeiten erstellt wurden, unterschiedliche Zustände Ihres Datensatzes erfassen. Diese Sicherungen in verschiedenen Status können zu Inkonsistenzen beim Wiederherstellen von Daten führen, insbesondere bei Tabellen, die zum selben funktionalen Dataset gehören. Wenn Sie beispielsweise eine Verkaufstabelle auf einen Zeitpunkt wiederherstellen, der sich von dem der entsprechenden Inventartabelle unterscheidet, kann es zu Abweichungen beim verfügbaren Bestand kommen. Ähnlich können Datenbankansichten, die Daten aus mehreren Tabellen zusammenfassen, besonders anfällig für Inkonsistenzen sein. Wenn Sie diese Ansichten wiederherstellen, ohne dafür zu sorgen, dass sich die zugrunde liegenden Tabellen in einem konsistenten Zustand befinden, kann dies zu ungenauen oder irreführenden Ergebnissen führen. Daher müssen Sie bei der Festlegung Ihrer BigQuery-Sicherungsrichtlinien und -häufigkeiten diese Konsistenz berücksichtigen und dafür sorgen, dass die wiederhergestellten Daten den tatsächlichen Status Ihres Datensatzes zu einem bestimmten Zeitpunkt genau widerspiegeln.

Bei der Bereitstellung für diese Referenzarchitektur wird die Datenkonsistenz beispielsweise über die folgenden beiden Konfigurationen in den Sicherungsrichtlinien gesteuert. Bei diesen Konfigurationen wird die genaue Zeit für den Tabellen-Snapshot durch Zeitreisen berechnet, ohne dass alle Tabellen unbedingt gleichzeitig gesichert werden.

  • backup_cron: Hiermit wird die Häufigkeit festgelegt, mit der eine Tabelle gesichert wird. Der Startzeitstempel eines Laufs wird als Referenzpunkt für die Berechnung der Zeitreise für alle Tabellen verwendet, die in diesem Lauf gesichert werden.
  • backup_time_travel_offset_days: Damit wird festgelegt, wie viele Tage in der Vergangenheit vom Referenzzeitpunkt (Ausführungsstartzeit) abgezogen werden sollen, um die genaue Zeitreiseversion der Tabelle zu berechnen.

Automatische Wiederherstellung von Sicherungen

In dieser Referenzarchitektur liegt der Schwerpunkt auf der Sicherungsautomatisierung im großen Maßstab. Sie können diese Sicherungen aber auch auf automatisierte Weise wiederherstellen. Diese zusätzliche Automatisierung kann ähnliche Vorteile wie die Sicherungsautomatisierung bieten, einschließlich verbesserter Effizienz und Geschwindigkeit bei der Wiederherstellung mit weniger Ausfallzeiten. Da die Lösung alle Sicherungsparameter und ‑ergebnisse über den Tagging-Dienst im Blick behält, könnten Sie eine ähnliche Architektur entwickeln, um die Wiederherstellungsvorgänge im großen Maßstab anzuwenden.

Sie können beispielsweise eine Lösung basierend auf einem On-Demand-Trigger erstellen, der einen Umfang von BigQuery-Daten an einen Dispatcherdienst sendet, der eine Anfrage pro Tabelle an einen Konfiguratordienst sendet. Der Konfigurationsservice kann den gewünschten Sicherungsverlauf für eine bestimmte Tabelle abrufen. Der Konfigurationsservice kann sie dann an einen BigQuery-Snapshot-Wiederherstellungsdienst oder einen Cloud Storage-Wiederherstellungsdienst weitergeben, um die Wiederherstellung entsprechend anzuwenden. Schließlich könnte ein Tagging-Dienst die Ergebnisse dieser Vorgänge in einem Statusspeicher speichern. So kann das Framework für die automatische Wiederherstellung von denselben Designzielen profitieren wie das in diesem Dokument beschriebene Sicherungsframework.

Kostenoptimierung

Das Framework dieser Architektur bietet Sicherungsrichtlinien, die die folgenden Parameter für die Gesamtkostenoptimierung festlegen:

  • Sicherungsmethode: Das Framework bietet die folgenden beiden Sicherungsmethoden:
    • BigQuery-Snapshots: Für aktualisierte und gelöschte Daten im Vergleich zur Basistabelle fallen Speicherkosten an. Daher sind Snapshots für Tabellen, die nur zum Anhängen von Daten verwendet werden oder nur begrenzt aktualisiert werden, kostengünstiger.
    • BigQuery-Exporte nach Cloud Storage, für die die standardmäßigen Speicherkosten anfallen. Bei großen Tabellen, die mit dem Ansatz „Zuschneiden und Laden“ erstellt werden, ist es jedoch kostengünstiger, sie als Exporte in weniger teuren Speicherklassen zu sichern.
  • Ablauf des Snapshots: Die Gültigkeitsdauer (TTL) wird für einen einzelnen Tabellen-Snapshot festgelegt, um Speicherkosten für den Snapshot auf unbestimmte Zeit zu vermeiden. Die Speicherkosten können mit der Zeit steigen, wenn Tabellen nicht ablaufen.

Betriebliche Effizienz

In diesem Abschnitt werden Funktionen und Überlegungen zur Betriebseffizienz beschrieben.

Detaillierte und skalierbare Sicherungsrichtlinien

Eines der Ziele dieses Frameworks ist die Betriebseffizienz durch eine Steigerung der Geschäftsleistung bei gleichzeitig relativ geringem und überschaubarem Geschäftsaufwand. Die Ausgabe ist beispielsweise eine große Anzahl regelmäßig gesicherter Tabellen, während die Eingabe eine kleine Anzahl von verwalteten Sicherungsrichtlinien und ‑konfigurationen ist.

Neben Sicherungsrichtlinien auf Tabellenebene ermöglicht das Framework auch Richtlinien auf Dataset-, Projekt-, Ordner- und globaler Ebene. Das bedeutet, dass mit wenigen Konfigurationen auf höheren Ebenen (z. B. auf Ordner- oder Projektebene) Hunderte oder Tausende von Tabellen regelmäßig und in großem Umfang gesichert werden können.

Beobachtbarkeit

Bei einem Automatisierungsframework ist es wichtig, dass Sie die Status der Prozesse kennen. Sie sollten beispielsweise die Informationen zu den folgenden häufig gestellten Fragen finden:

  • Die Sicherungsrichtlinie, die vom System für jede Tabelle verwendet wird.
  • Sicherungsverlauf und Sicherungsspeicherorte der einzelnen Tabellen.
  • Der Gesamtstatus einer einzelnen Ausführung (Anzahl der verarbeiteten und fehlgeschlagenen Tabellen).
  • Die bei einem einzelnen Durchlauf aufgetretenen fatalen Fehler und die Komponenten oder Schritte des Prozesses, in denen sie aufgetreten sind.

Um diese Informationen bereitzustellen, schreibt die Bereitstellung bei jedem Ausführungsschritt, bei dem ein Cloud Run-Dienst verwendet wird, strukturierte Protokolle in Cloud Logging. Die Protokolle enthalten die Eingabe, Ausgabe und Fehler sowie andere Fortschrittskontrollpunkte. Eine Logsenke leitet diese Logs an eine BigQuery-Tabelle weiter. Sie können eine Reihe von Abfragen ausführen, um Ausführungen zu überwachen und Berichte zu erhalten, die für gängige Anwendungsfälle der Observabilität geeignet sind. Weitere Informationen zu Logs und Abfragen in BigQuery finden Sie unter An BigQuery weitergeleitete Logs ansehen.

Leistungsoptimierung

Um bei jeder Ausführung Tausende von Tabellen zu verarbeiten, werden Sicherungsanfragen parallel verarbeitet. Der Dispatcher-Dienst listet alle Tabellen auf, die in den BigQuery-Sicherungsumfang fallen, und generiert bei jedem Lauf eine Sicherungsanfrage pro Tabelle. So kann die Anwendung Tausende von Anfragen und Tabellen parallel und nicht nacheinander verarbeiten.

Einige dieser Anfragen können aus vorübergehenden Gründen fehlschlagen, z. B. wenn die Limits der zugrunde liegenden Google Cloud APIs erreicht werden oder Netzwerkprobleme auftreten. Bis die Anfragen abgeschlossen sind, werden sie von Pub/Sub automatisch mit der exponentiellen Backoff-Wiederholrichtlinie wiederholt. Wenn es zu schwerwiegenden Fehlern wie ungültigen Sicherungszielen oder fehlenden Berechtigungen kommt, werden die Fehler protokolliert und die Ausführung der betreffenden Tabellenanfrage wird beendet, ohne dass sich dies auf den Gesamtlauf auswirkt.

Limits

Für diese Architektur gelten die folgenden Kontingente und Limits.

Für Tabellen-Snapshots gilt für jedes von Ihnen angegebene Projekt für Sicherungsvorgänge Folgendes:

  • In einem Projekt können bis zu 100 Tabellen-Snapshot-Jobs gleichzeitig ausgeführt werden.
  • Ein Projekt kann bis zu 50.000 Tabellen-Snapshot-Jobs pro Tag ausführen.
  • Ein Projekt kann bis zu 50 Tabellen-Snapshot-Jobs pro Tabelle und Tag ausführen.

Weitere Informationen finden Sie unter Tabellen-Snapshots.

Für Exportjobs (Exporte nach Cloud Storage) gilt Folgendes:

  • Mit dem freigegebenen Slot-Pool können Sie bis zu 50 TiB Daten pro Tag kostenlos aus einem Projekt exportieren.
  • Ein Projekt kann bis zu 100.000 Exporte pro Tag ausführen. Wenn Sie dieses Limit erhöhen möchten, erstellen Sie eine Slot-Reservierung.

Weitere Informationen zum Erhöhen dieser Limits finden Sie unter Exportjobs.

Bei den Einschränkungen für die Parallelität wird in dieser Architektur Pub/Sub verwendet, um Anfragen, die aufgrund dieser Einschränkungen fehlschlagen, automatisch so lange zu wiederholen, bis sie von der API verarbeitet werden. Andere Limits für die Anzahl der Vorgänge pro Projekt und Tag können jedoch entweder durch eine Anfrage zur Kontingenterhöhung oder durch die Verteilung der Sicherungsvorgänge (Snapshots oder Exporte) auf mehrere Projekte gemildert werden. Wenn Sie die Vorgänge auf mehrere Projekte verteilen möchten, konfigurieren Sie die Sicherungsrichtlinien wie in den folgenden Bereitstellungsabschnitten beschrieben:

Bereitstellung

Informationen zum Bereitstellen dieser Architektur finden Sie unter Skalierbare BigQuery-Sicherungsautomatisierung bereitstellen.

Nächste Schritte

Beitragende

Autor: Karim Wadie | Strategic Cloud Engineer

Weitere Beitragende: