Skalierbare BigQuery-Sicherungsautomatisierung

Diese Architektur bietet ein Framework und eine Referenzbereitstellung, die Sie bei der Entwicklung einer BigQuery-Sicherungsstrategie unterstützen. Das empfohlene Framework und die zugehörige Automatisierung können Ihrer Organisation bei Folgendem helfen:

  • Halten Sie die Ziele Ihrer Organisation zur Notfallwiederherstellung ein.
  • Daten wiederherstellen, die aufgrund menschlicher Fehler verloren gegangen sind
  • Vorschriften einhalten.
  • Betriebseffizienz steigern

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

Dieses Dokument richtet sich an Cloud Architects, Engineers und Data Governance-Mitarbeiter, die Datenrichtlinien in ihren Organisationen definieren und automatisieren möchten.

Architektur

Das folgende Diagramm zeigt die Architektur für automatische Sicherungen:

Architektur für die Lösung zur automatischen Sicherung

Der im vorherigen Diagramm gezeigte Workflow umfasst die folgenden Phasen:

  1. Cloud Scheduler löst eine Ausführung an den Dispatcher-Dienst über eine Pub/Sub-Nachricht aus, die den Bereich der ein- und ausgeschlossenen BigQuery-Daten enthält. Ausführungen werden mithilfe eines Cron-Ausdrucks geplant.
  2. Der Dispatcher-Dienst, der auf Cloud Run basiert, verwendet die BigQuery API, um die Tabellen aufzulisten, die sich im BigQuery-Bereich befinden.
  3. Der Dispatcher-Dienst sendet über eine Pub/Sub-Nachricht eine Anfrage für jede Tabelle an den Konfigurationsdienst.

  4. Der Cloud Run-Konfiguratordienst berechnet die Sicherungsrichtlinie der Tabelle anhand einer der folgenden definierten Optionen:

    1. Die Richtlinie auf Tabellenebene, die von Dateninhabern definiert wird.
    2. Die vom Data Governance-Beauftragte definierte Fallback-Richtlinie für Tabellen, für die keine Richtlinien festgelegt sind.

    Weitere Informationen zu Sicherungsrichtlinien finden Sie unter Sicherungsrichtlinien.

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

  6. Abhängig von der 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 nach Cloud Storage.

  7. Wenn die Sicherungsmethode ein Tabellendatenexport ist, wartet eine Cloud Logging-Logsenke auf die Abschlussereignisse des 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 Tagger-Dienst aus.

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

Verwendete Produkte

Diese Referenzarchitektur verwendet die folgenden Google Cloud Produkte:

  • 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 aus Gründen der Redundanz standortübergreifend repliziert.
  • Cloud Scheduler: Ein vollständig verwalteter Cronjob-Planer für Unternehmen, mit dem Sie geplante Arbeitseinheiten einrichten können, die zu bestimmten Zeiten oder in regelmäßigen Intervallen ausgeführt werden.
  • Datenspeicher: Eine hoch skalierbare NoSQL-Datenbank für Ihre Webanwendungen und mobilen Apps

Anwendungsfälle

Dieser Abschnitt enthält Beispiele für Anwendungsfälle, für die Sie diese Architektur verwenden können.

Back-up-Automatisierung

Beispiel: Ihr Unternehmen ist in einer regulierten Branche tätig und verwendet BigQuery als Haupt-Data-Warehouse. Selbst wenn Ihr Unternehmen Best Practices in den Bereichen Softwareentwicklung, Codeüberprüfung und Release-Engineering einhält, besteht weiterhin das Risiko eines Datenverlusts oder einer Datenbeschädigung durch menschliche Fehler. In einer regulierten Branche müssen Sie dieses Risiko so weit wie möglich minimieren.

Beispiele für menschliche Fehler:

  • Versehentliches Löschen von Tabellen.
  • Datenbeschädigung durch fehlerhafte Datenpipeline-Logik.

Diese Art von menschlichen Fehlern können in der Regel mit der Zeitreise-Funktion behoben werden, mit der Sie Daten wiederherstellen können, die bis zu sieben Tage zurückliegen. Darüber hinaus bietet BigQuery einen Fehlersicheren Zeitraum, in dem gelöschte Daten nach dem Zeitstempelfenster weitere sieben Tage lang im fehlersicheren Speicher aufbewahrt werden. Diese Daten stehen für die Notfallwiederherstellung über Cloud Customer Care zur Verfügung. Wenn Ihr Unternehmen solche Fehler jedoch nicht innerhalb dieses kombinierten Zeitraums findet und behebt, können die gelöschten Daten nicht mehr aus ihrem letzten stabilen Zustand wiederhergestellt werden.

Um dies zu vermeiden, empfehlen wir, regelmäßige Sicherungen für alle BigQuery-Tabellen auszuführen, die nicht aus Quelldaten rekonstruiert werden können (z. B. historische Datensätze oder KPIs mit neuer Geschäftslogik).

Ihr Unternehmen könnte mit einfachen Skripts Dutzende von Tabellen sichern. Wenn Sie jedoch regelmäßig Hunderte oder Tausende von Tabellen im gesamten Unternehmen sichern müssen, benötigen Sie eine skalierbare Automatisierungslösung, die folgende Aufgaben erfüllt:

  • Behandeln Sie verschiedene Google Cloud API-Limits.
  • Bereitstellung eines standardisierten Frameworks zum Definieren von Sicherungsrichtlinien
  • Transparenz und Monitoring-Funktionen für die Sicherungsvorgänge bereitstellen

Sicherungsrichtlinien

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

  • Dateninhaber, die mit den Tabellen am besten vertraut sind und die entsprechenden Sicherungsrichtlinien auf Tabellenebene festlegen können.
  • Data-Governance-Team, das dafür sorgt, dass eine Fallback-Richtlinie vorhanden ist, um Tabellen abzudecken, die keine Richtlinie auf Tabellenebene haben. Die Fallback-Richtlinie sorgt dafür, dass bestimmte Datasets, Projekte und Ordner gemäß den Aufbewahrungsbestimmungen Ihres Unternehmens gesichert werden.

In der Bereitstellung für diese Referenzarchitektur gibt es zwei Möglichkeiten, die Sicherungsrichtlinien für Tabellen zu definieren, und sie können zusammen verwendet werden:

  • Dateninhaberkonfiguration (dezentral): 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, an die keine manuell angehängten Richtlinien gesendet wurden.

    • Ein Data-Governance-Team definiert als Teil der Lösung eine zentrale JSON-Datei in Terraform.
    • Die Fallback-Richtlinie bietet Standardsicherungsstrategien auf Ordner-, Projekt-, Dataset- und Tabellenebene.
    • Weitere Informationen zur Bereitstellung finden Sie unter Richtlinien für Fallback-Sicherungen definieren.

Sicherung und Replikation

Bei einem Sicherungsprozess wird eine Kopie der Tabellendaten von einem bestimmten Zeitpunkt erstellt, damit sie bei Verlust oder Beschädigung wiederhergestellt werden kann. Sicherungen können einmalig oder wiederholt (über eine geplante Abfrage oder einen geplanten Workflow) ausgeführt werden. In BigQuery können Sicherungen zu einem bestimmten Zeitpunkt mithilfe von Snapshots erstellt werden. Sie können Snapshots verwenden, um Kopien der Daten über einen Zeitraum von sieben Tagen hinaus am selben Speicherort wie die Quelldaten zu speichern. BigQuery-Snapshots sind besonders hilfreich für die Wiederherstellung von Daten nach menschlichen Fehlern, die zu Datenverlust oder -beschädigung führen, als für die Wiederherstellung nach regionalen Ausfällen. BigQuery bietet je nach Version ein Service Level Objective (SLO) von 99,9% bis 99,99%.

Im Gegensatz dazu ist die Replikation der kontinuierliche Prozess, bei dem Datenbankänderungen in eine sekundäre (oder Replikat-)Datenbank an einem anderen Standort kopiert werden. In BigQuery kann die regionenübergreifende Replikation zur Georedundanz beitragen, indem schreibgeschützte Kopien der Daten in sekundären Google Cloud Regionen erstellt werden, die sich von der Quelldatenregion unterscheiden. Die regionsübergreifende BigQuery-Replikation ist jedoch nicht als Notfallwiederherstellungsplan für Ausfallszenarien insgesamt in der Region gedacht. Ziehen Sie die von BigQuery verwaltete Notfallwiederherstellung in Betracht, um Robustheit gegen regionale Notfälle zu erhöhen.

Die regionsübergreifende BigQuery-Replikation bietet eine synchronisierte schreibgeschützte Kopie der Daten in einer Region, die sich in der Nähe der Datennutzer befindet. Diese Datenkopien ermöglichen gemeinsame Joins und vermeiden regionsübergreifende Zugriffe und Kosten. Bei Datenbeschädigungen aufgrund menschlicher Fehler kann die Replikation allein jedoch nicht bei der Wiederherstellung helfen, da die beschädigten Daten automatisch in das Replikat kopiert werden. In solchen Fällen sind Sicherungen zu einem bestimmten Zeitpunkt (Snapshots) die bessere Wahl.

Die folgende Tabelle zeigt einen zusammengefassten Vergleich von Sicherungsmethoden und Replikation:

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

(Snapshots oder Cloud Storage-Export)		 Einmalig oder wiederkehrend Identisch mit den Daten der Quelltabelle Wiederherstellen der Originaldaten über Zeitreise Für Snapshots fallen Speichergebühren nur für Datenänderungen im Snapshot an

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

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

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

Es fallen Kosten für die Datenreplikation an

Designaspekte

Dieser Abschnitt enthält Hinweise, die Sie berücksichtigen sollten, wenn Sie mit dieser Referenzarchitektur eine Topologie entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, Kostenoptimierung, Betriebseffizienz und Leistung entspricht.

Sicherheit, Datenschutz und Compliance

Bei der Entwicklung und Implementierung werden die folgenden Sicherheitsmaßnahmen berücksichtigt:

  • Die Einstellung Eingehender Netzwerktraffic für Cloud Run akzeptiert nur internen Traffic, um den Zugriff aus dem Internet einzuschränken. Außerdem können nur authentifizierte Nutzer und Dienstkonten die Dienste aufrufen.
  • Jeder Cloud Run-Dienst und jedes Pub/Sub-Abo verwendet ein separates Dienstkonto, dem nur die erforderlichen Berechtigungen zugewiesen sind. Dies mindert die Risiken, die mit der Verwendung eines einzigen Dienstkontos für das System verbunden sind, und folgt dem Prinzip der geringsten Berechtigung.

Aus Datenschutzgründen werden von der Lösung keine personenidentifizierbaren Informationen erfasst oder verarbeitet. Wenn die Quelltabellen jedoch personenidentifizierbare Informationen offengelegt haben, enthalten die Sicherungen dieser Tabellen diese bereitgestellten Daten ebenfalls. Der Inhaber der Quelldaten ist für den Schutz aller personenidentifizierbaren Informationen in den Quelltabellen verantwortlich (z. B. durch Sicherheit auf Spaltenebene, Datenmaskierung oder Entfernen). Die Sicherungen sind nur dann sicher, wenn die Quelldaten gesichert sind. Ein weiterer Ansatz besteht darin, dafür zu sorgen, dass Projekte, Datasets oder Buckets, die Sicherungsdaten mit offengelegten personenidentifizierbaren Informationen enthalten, die erforderlichen IAM-Richtlinien (Identity and Access Management) haben, die den Zugriff auf autorisierte Nutzer beschränken.

Da es sich um eine Allzwecklösung handelt, entspricht die Referenzbereitstellung nicht unbedingt den spezifischen Anforderungen einer bestimmten Branche.

Zuverlässigkeit

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

Detaillierte Fehlerbewältigung

Wenn Sie Sicherungen Tausender Tabellen erstellen möchten, ist es wahrscheinlich, dass Sie die API-Limits für die zugrunde liegenden Google Cloud -Produkte erreichen (z. B. Limits für Snapshots und Exportvorgänge für jedes Projekt). Wenn die Sicherung einer Tabelle jedoch aufgrund von Fehlkonfigurationen oder anderen vorübergehenden Problemen fehlschlägt, sollte dies die gesamte Ausführung und die Fähigkeit, andere Tabellen zu sichern, nicht beeinträchtigen.

Um potenzielle Fehler zu minimieren, entkoppelt die Referenzbereitstellung die Verarbeitungsschritte. Dazu werden detaillierte Cloud Run-Dienste verwendet und sie werden über Pub/Sub verbunden. Wenn eine Anfrage zur Tabellensicherung beim letzten Tagger-Dienstschritt fehlschlägt, wiederholt Pub/Sub nur diesen Schritt und nicht den gesamten Prozess.

Die Aufteilung des Ablaufs in mehrere Cloud Run-Dienste anstatt in mehrere Endpunkte, die unter einem Cloud Run-Dienst gehostet werden, ermöglicht eine detaillierte Kontrolle über jede Dienstkonfiguration. 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, erfordert jedoch sehr viel Zeit, um alle Tabellen im BigQuery-Sicherungsbereich aufzulisten. Daher erfordert der Dispatcher-Dienst höhere Zeitüberschreitungs- und Arbeitsspeichereinstellungen. Der Cloud Run-Dienst für BigQuery-Snapshots werden jedoch einmal pro Tabelle bei einem einzelnen Durchlauf ausgeführt und sind in kürzerer Zeit abgeschlossen als der Dispatcher-Dienst. Daher erfordert der Cloud Run-Dienst einen anderen Satz von Konfigurationen auf Dienstebene.

Datenkonsistenz

Datenkonsistenz über Tabellen und Ansichten hinweg ist für die Aufrechterhaltung einer zuverlässigen Sicherungsstrategie entscheidend. Da die Daten kontinuierlich aktualisiert und geändert werden, können Sicherungen, die zu unterschiedlichen Zeiten erstellt werden, verschiedene Status Ihres Datasets 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 von der entsprechenden Inventartabelle abweicht, kann dies zu einer Abweichung der verfügbaren Bestände führen. Ebenso können Datenbankansichten, in denen Daten aus mehreren Tabellen aggregiert werden, besonders anfällig für Inkonsistenzen sein. Wenn Sie diese Ansichten wiederherstellen, ohne sicherzustellen, dass sich die zugrunde liegenden Tabellen in einem konsistenten Zustand befinden, kann dies zu ungenauen oder irreführenden Ergebnissen führen. Daher ist es wichtig, beim Entwerfen Ihrer BigQuery-Sicherungsrichtlinien und -häufigkeiten diese Konsistenz zu berücksichtigen und sicherzustellen, dass die wiederhergestellten Daten den realen Status Ihres Datasets zu einem bestimmten Zeitpunkt genau widerspiegeln.

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

  • backup_cron: Steuert die Häufigkeit, mit der eine Tabelle gesichert wird. Der Startzeitstempel einer Ausführung wird als Bezugspunkt für die Berechnung der Zeitreise für alle Tabellen verwendet, die bei dieser Ausführung gesichert werden.
  • backup_time_travel_offset_days: Steuert, wie viele Tage in der Vergangenheit vom Referenzzeitpunkt (Ausführungsbeginn) subtrahiert werden sollen, um die genaue Zeitreiseversion der Tabelle zu berechnen.

Automatische Wiederherstellung von Sicherungen

Obwohl sich diese Referenzarchitektur auf die Automatisierung von Sicherungen im großen Maßstab konzentriert, können Sie diese Sicherungen auch automatisch wiederherstellen. Diese zusätzliche Automatisierung bietet ähnliche Vorteile wie die Sicherungsautomatisierung, einschließlich einer verbesserten Effizienz und Geschwindigkeit der Wiederherstellung bei geringerer Ausfallzeit. Da die Lösung alle Sicherungsparameter und -ergebnisse über den Tagger-Dienst verfolgt, können Sie eine ähnliche Architektur entwickeln, um die Wiederherstellung in großem Maßstab anzuwenden.

Sie können beispielsweise eine Lösung auf Basis eines On-Demand-Triggers erstellen, der einen Bereich von BigQuery-Daten an einen Dispatcher-Dienst sendet, der eine Anfrage pro Tabelle an einen Konfiguratordienst sendet. Der Konfiguratordienst könnte den gewünschten Sicherungsverlauf für eine bestimmte Tabelle abrufen. Der Konfiguratordienst könnte sie dann entweder an einen BigQuery-Dienst für die Snapshot-Wiederherstellung oder einen Cloud Storage-Wiederherstellungsdienst übergeben, um die Wiederherstellung entsprechend anzuwenden. Außerdem könnte ein Tagger-Dienst die Ergebnisse dieser Vorgänge in einem Zustandsspeicher speichern. Auf diese Weise kann das automatisierte Wiederherstellungs-Framework von denselben Designzielen profitieren wie das Sicherungs-Framework, das in diesem Dokument erläutert wird.

Kostenoptimierung

Das Framework dieser Architektur stellt Sicherungsrichtlinien bereit, die die folgenden Parameter für die Optimierung der Gesamtkosten festlegen:

  • Sicherungsmethode: Das Framework bietet die folgenden zwei Sicherungsmethoden:
    • BigQuery-Snapshots, bei denen Speicherkosten auf Basis der aktualisierten und gelöschten Daten im Vergleich zur Basistabelle anfallen. Daher sind Snapshots kostengünstiger für Tabellen, an die nur Anfügungen zulässig sind oder die nur begrenzt aktualisiert werden.
    • BigQuery-Exporte nach Cloud Storage, wobei die Standardspeichergebühren anfallen. Große Tabellen, die einem Ansatz zum Abschneiden und Laden folgen, ist jedoch kostengünstiger als Exporte in kostengünstigere Speicherklassen.
  • Snapshot-Ablauf: Die Gültigkeitsdauer (TTL) wird für einen einzelnen Tabellen-Snapshot festgelegt, um zu vermeiden, dass Speicherkosten für den Snapshot unbegrenzt anfallen. Die Speicherkosten können mit der Zeit steigen, wenn Tabellen kein Ablaufdatum haben.

Operative Effizienz

In diesem Abschnitt werden Features und Überlegungen zur betrieblichen Effizienz beschrieben.

Detaillierte und skalierbare Sicherungsrichtlinien

Eines der Ziele dieses Frameworks ist die operative Effizienz, indem die Geschäftsleistung skaliert wird, während der geschäftliche Aufwand relativ gering und überschaubar bleibt. Die Ausgabe ist beispielsweise eine große Anzahl regelmäßig gesicherter Tabellen, während die Eingabe eine geringe Anzahl von beibehaltenen Sicherungsrichtlinien und -konfigurationen ist.

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

Beobachtbarkeit

Bei einem Automatisierungs-Framework ist es wichtig, dass Sie den Status der Prozesse kennen. Beispielsweise sollten Sie die Informationen für die folgenden häufigen Abfragen finden können:

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

Dazu schreibt das Deployment bei jedem Ausführungsschritt, der einen Cloud Run-Dienst verwendet, strukturierte Logs in Cloud Logging. Die Logs enthalten Eingabe-, Ausgabe- und Fehler sowie andere Fortschrittsprüfpunkte. Eine Logsenke leitet diese Logs an eine BigQuery-Tabelle weiter. Sie können eine Reihe von Abfragen ausführen, um Ausführungen zu beobachten und Berichte für gängige Anwendungsfälle der Beobachtbarkeit zu erhalten. Weitere Informationen zu Logs und Abfragen in BigQuery finden Sie unter An BigQuery weitergeleitete Logs ansehen.

Leistungsoptimierung

Die Lösung verarbeitet die Sicherungsanfragen parallel, um bei jeder Ausführung Tausende von Tabellen zu verarbeiten. Der Dispatcher-Dienst listet alle Tabellen auf, die im BigQuery-Sicherungsbereich enthalten sind, und generiert bei jeder Ausführung eine Sicherungsanfrage pro Tabelle. Dadurch kann die Anwendung Tausende von Anfragen und Tabellen parallel und nicht sequenziell verarbeiten.

Einige dieser Anfragen schlagen anfangs möglicherweise aus vorübergehenden Gründen fehl, z. B. wenn die Limits der zugrunde liegenden Google Cloud APIs erreicht werden oder Netzwerkprobleme auftreten. Bis die Anfragen abgeschlossen sind, wiederholt Pub/Sub die Anfragen automatisch mit der Richtlinie für Wiederholungen mit exponentiellem Backoff. Schwerwiegende Fehler wie ungültige Sicherungsziele oder fehlende Berechtigungen werden protokolliert und die Ausführung der entsprechenden Tabellenanfrage wird beendet, ohne dass sich dies auf die Gesamtausführung 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 den Sicherungsvorgang Folgendes:

  • In einem Projekt können bis zu 100 Tabellen-Snapshot-Jobs gleichzeitig ausgeführt werden.
  • Für ein Projekt können pro Tag bis zu 50.000 Tabellen-Snapshot-Jobs ausgeführt werden.
  • 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 gemeinsamen Slot-Pool können Sie kostenlos bis zu 50 TiB Daten pro Tag aus einem Projekt exportieren.
  • Für ein Projekt können pro Tag bis zu 100.000 Exporte ausgeführt werden. Wenn Sie dieses Limit erweitern möchten, erstellen Sie eine Slotreservierung.

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

In Bezug auf die Limits für die Gleichzeitigkeit verwendet diese Architektur Pub/Sub, um Anfragen, die aufgrund dieser Limits fehlschlagen, automatisch noch einmal zu senden, bis sie von der API verarbeitet werden. Bei anderen Limits für die Anzahl der Vorgänge pro Projekt und Tag können diese jedoch entweder durch eine Anfrage zur Kontingenterhöhung oder durch das Verteilen der Sicherungsvorgänge (Snapshots oder Exporte) auf mehrere Projekte gemindert werden. Konfigurieren Sie die Sicherungsrichtlinien wie in den folgenden Bereitstellungsabschnitten beschrieben, um Vorgänge auf Projekte zu verteilen:

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: