Diese Architektur bietet ein Framework und eine Referenzbereitstellung, die Ihnen bei der Entwicklung Ihrer BigQuery-Sicherungsstrategie helfen. Dieses empfohlene Framework und die zugehörige Automatisierung können Ihrem Unternehmen helfen, Folgendes zu erreichen:
- Halten Sie sich an 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 ein- oder ausschließen. Diese empfohlene Architektur zeigt, wie Sie die wiederkehrenden Sicherungsvorgänge im großen Maßstab automatisieren können. 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 Data Governance-Beauftragte, die Datenrichtlinien in ihren Organisationen definieren und automatisieren möchten.
Architektur
Das folgende Diagramm zeigt die Architektur für automatisierte Back-ups:
Der im vorherigen Diagramm dargestellte Workflow umfasst die folgenden Phasen:
- Cloud Scheduler löst über eine Pub/Sub-Nachricht einen Lauf für den Dispatcher-Dienst aus. Diese Nachricht enthält den Umfang der BigQuery-Daten, die ein- und ausgeschlossen werden. Ausführungen werden mithilfe eines Cron-Ausdrucks geplant.
- Der Dispatcher-Dienst, der auf Cloud Run basiert, verwendet die BigQuery API, um die Tabellen aufzulisten, die sich im BigQuery-Bereich befinden.
- Der Dispatcher-Dienst sendet für jede Tabelle eine Anfrage an den Konfigurator-Dienst über eine Pub/Sub-Nachricht.
Der Cloud Run-Konfigurationsdienst berechnet die Sicherungsrichtlinie der Tabelle anhand einer der folgenden Optionen:
- Die Richtlinie auf Tabellenebene, die von Dateninhabern definiert wird.
- Die Fallback-Richtlinie, die vom Data Governance Officer für Tabellen ohne definierte Richtlinien definiert wird.
Weitere Informationen zu Sicherungsrichtlinien finden Sie unter Sicherungsrichtlinien.
Der Konfigurationsdienst sendet basierend auf der berechneten Sicherungsrichtlinie eine Anfrage für jede Tabelle an den nächsten Dienst.
Je nach Sicherungsmethode sendet einer der folgenden benutzerdefinierten Cloud Run-Dienste eine Anfrage an die BigQuery API und führt den Sicherungsvorgang aus:
- Mit dem Dienst für BigQuery-Snapshots wird die Tabelle als Snapshot gesichert.
- Der Dienst für Datenexporte sichert die Tabelle als Datenexport in Cloud Storage.
Wenn die Sicherungsmethode ein Tabellendatenexport ist, wartet eine Logs-Senke in Cloud Logging auf die Ereignisse zum Abschluss der Exportjobs, um die asynchrone Ausführung des nächsten Schritts zu ermöglichen.
Nachdem die Sicherungsdienste ihre Vorgänge abgeschlossen haben, löst Pub/Sub den Tagger-Dienst aus.
Für jede Tabelle protokolliert der Tagger-Dienst 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.
Automatisierte Sicherung
Ihr Unternehmen ist beispielsweise in einer regulierten Branche tätig und verwendet BigQuery als primäres Data Warehouse. Auch wenn Ihr Unternehmen Best Practices für Softwareentwicklung, Code-Review und Release-Engineering befolgt, besteht immer noch das Risiko von Datenverlust oder Datenbeschädigung aufgrund menschlicher Fehler. In einer regulierten Branche müssen Sie dieses Risiko so weit wie möglich minimieren.
Beispiele für diese menschlichen Fehler:
- Versehentliches Löschen von Tabellen
- Datenbeschädigung aufgrund fehlerhafter Logik in 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, in der gelöschte Daten nach dem Zeitreisefenster 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 solche Fehler jedoch nicht innerhalb dieses kombinierten Zeitrahmens erkennt und behebt, können die gelöschten Daten nicht mehr aus dem letzten stabilen Zustand wiederhergestellt werden.
Um dieses Problem zu vermeiden, empfehlen wir, regelmäßig Sicherungen für alle BigQuery-Tabellen auszuführen, die nicht aus Quelldaten rekonstruiert werden können, z. B. Verlaufsdaten oder KPIs mit sich entwickelnder Geschäftslogik.
Ihr Unternehmen könnte einfache Skripts verwenden, um Dutzende von Tabellen zu 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 leisten kann:
- Umgang mit verschiedenen Google Cloud API-Limits
- Ein standardisiertes Framework zum Definieren von Sicherungsrichtlinien bereitstellen.
- Transparenz und Überwachungsfunktionen für die Sicherungsvorgänge bieten.
Sicherungsrichtlinien
Möglicherweise muss Ihr Unternehmen auch festlegen, 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.
- Das Data Governance-Team sorgt dafür, dass eine Fallback-Richtlinie für alle Tabellen vorhanden ist, für die keine Richtlinie auf Tabellenebene festgelegt ist. Die Fallback-Richtlinie sorgt dafür, dass bestimmte Datasets, Projekte und Ordner gesichert werden, um die Aufbewahrungsrichtlinien Ihres Unternehmens einzuhalten.
In der Bereitstellung für diese Referenzarchitektur gibt es zwei Möglichkeiten, die Sicherungsrichtlinien für Tabellen zu definieren. Sie können auch zusammen verwendet werden:
Konfiguration durch Dateninhaber (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 (zentralisiert): Eine Fallback-Richtlinie, die nur auf Tabellen angewendet wird, denen keine Richtlinien manuell zugewiesen wurden.
- Ein Team für Data Governance definiert im Rahmen der Lösung eine zentrale JSON-Datei in Terraform.
- Die Fallback-Richtlinie bietet standardmäßige Sicherungsstrategien auf Ordner-, Projekt-, Dataset- und Tabellenebene.
- Weitere Informationen zur Bereitstellung finden Sie unter Fallback-Back-up-Richtlinien definieren.
Sicherung im Vergleich zur Replikation
Bei einem Backup wird eine Kopie der Tabellendaten zu einem bestimmten Zeitpunkt erstellt, damit sie wiederhergestellt werden können, wenn die Daten verloren gehen oder beschädigt werden. Sicherungen können einmalig oder wiederkehrend (über eine geplante Abfrage oder einen Workflow) ausgeführt werden. In BigQuery können Point-in-Time-Sicherungen mit Snapshots 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 wiederherzustellen, die zu Datenverlust oder ‑beschädigung führen, und nicht, um Daten nach regionalen Ausfällen wiederherzustellen. BigQuery bietet je nach Edition ein Service Level Objective (SLO) von 99,9% bis 99,99%.
Im Gegensatz dazu ist die Replikation ein kontinuierlicher Prozess, bei dem Datenbankänderungen in eine sekundäre Datenbank (oder Replik) an einem anderen Standort kopiert werden. In BigQuery kann die regionenübergreifende Replikation für geografische 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 von BigQuery ist jedoch nicht als Notfallwiederherstellungsplan für Szenarien mit regionalen Ausfällen vorgesehen. Um die Resilienz gegenüber regionalen Katastrophen zu erhöhen, sollten Sie die von BigQuery verwaltete Notfallwiederherstellung verwenden.
Die regionenübergreifende Replikation von BigQuery bietet eine synchronisierte schreibgeschützte Kopie der Daten in einer Region, die sich in der Nähe der Datenverbraucher befindet. Diese Datenkopien ermöglichen die gemeinsame Verarbeitung von Daten am selben Standort und vermeiden regionenübergreifenden Traffic und Kosten. Bei Datenbeschädigung aufgrund menschlicher Fehler kann die Replikation allein jedoch nicht zur Wiederherstellung beitragen, da die beschädigten Daten automatisch in das Replikat kopiert werden. In solchen Fällen sind Point-in-Time-Sicherungen (Snapshots) die bessere Wahl.
In der folgenden Tabelle finden Sie einen zusammenfassenden Vergleich der Sicherungsmethoden und der Replikation:
| Methode | Häufigkeit | Storage-Speicherort | Anwendungsfälle | Kosten |
|---|---|---|---|---|
| Sicherung (Snapshots oder Cloud Storage-Export) |
Einmalig oder wiederkehrend | Wie die Daten der Quelltabelle | Originaldaten über den Zeitraum der Zeitreise hinaus wiederherstellen | 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 |
| Regionsü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 Replikat 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
Bei der Bereitstellung werden die folgenden Sicherheitsmaßnahmen berücksichtigt:
- Die Einstellung Netzwerk-Ingress für Cloud Run akzeptiert nur internen Traffic, um den Zugriff über das Internet einzuschränken. Außerdem können die Dienste nur von authentifizierten Nutzern und Dienstkonten aufgerufen werden.
- Für jeden Cloud Run-Dienst und jedes Pub/Sub-Abo wird ein separates Dienstkonto verwendet, dem nur die erforderlichen Berechtigungen zugewiesen sind. Dadurch werden die Risiken, die mit der Verwendung eines Dienstkontos für das System verbunden sind, verringert und der Grundsatz der geringsten Berechtigung wird eingehalten.
Aus Datenschutzgründen werden in 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 dafür verantwortlich, alle personenidentifizierbaren Informationen in den Quelltabellen zu schützen, z. B. durch Anwendung von Sicherheit auf Spaltenebene, Datenmaskierung oder Schwärzung. Die Sicherungen sind nur sicher, wenn die Quelldaten sicher sind. Eine weitere Möglichkeit besteht darin, dafür zu sorgen, dass für Projekte, Datasets oder Buckets, die Sicherungsdaten mit offengelegten personenidentifizierbaren Informationen enthalten, die erforderlichen IAM-Richtlinien (Identity and Access Management) vorhanden sind, die den Zugriff auf autorisierte Nutzer beschränken.
Als allgemeine Lösung entspricht das Referenz-Deployment nicht unbedingt den spezifischen Anforderungen einer bestimmten Branche.
Zuverlässigkeit
In diesem Abschnitt werden Features und Designüberlegungen zur Zuverlässigkeit beschrieben.
Fehlerbehebung mit Granularität
Wenn Sie Back-ups von Tausenden von Tabellen erstellen möchten, erreichen Sie wahrscheinlich die API-Limits für die zugrunde liegenden Google Cloud Produkte, z. B. die Limits für die Vorgänge Snapshot und Export für jedes Projekt. Wenn die Sicherung einer Tabelle jedoch aufgrund einer fehlerhaften Konfiguration oder anderer vorübergehender Probleme fehlschlägt, sollte sich das nicht auf die Gesamtausführung und die Möglichkeit, andere Tabellen zu sichern, auswirken.
Um potenzielle Fehler zu minimieren, werden in der Referenzbereitstellung die Verarbeitungsschritte durch die Verwendung von granularen Cloud Run-Diensten entkoppelt und über Pub/Sub verbunden. Wenn eine Anfrage für die Tabellensicherung im letzten Schritt des Tagger-Dienstes fehlschlägt, wird nur dieser Schritt von Pub/Sub wiederholt. Der gesamte Prozess wird nicht wiederholt.
Wenn Sie den Ablauf in mehrere Cloud Run-Dienste aufteilen, anstatt mehrere Endpunkte in einem Cloud Run-Dienst zu hosten, können Sie die Konfiguration jedes Dienstes detailliert steuern. Der Konfigurationsaufwand 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 viel Zeit, alle Tabellen im BigQuery-Sicherungsbereich aufzulisten. Daher sind für den Dispatcher-Dienst höhere Zeitüberschreitungs- und Speichereinstellungen erforderlich. Der Cloud Run-Dienst für BigQuery-Snapshots wird jedoch einmal pro Tabelle in einem einzigen Lauf ausgeführt und ist schneller abgeschlossen als der Dispatcher-Dienst. Daher sind für den Cloud Run-Dienst auf Dienstebene andere Konfigurationen erforderlich.
Datenkonsistenz
Die Datenkonsistenz über Tabellen und Ansichten hinweg ist entscheidend für eine zuverlässige Sicherungsstrategie. Da Daten kontinuierlich aktualisiert und geändert werden, können Sicherungen, die zu unterschiedlichen Zeiten erstellt werden, unterschiedliche Zustände Ihres Datensatzes erfassen. Diese Sicherungen in unterschiedlichen Status können zu Inkonsistenzen führen, wenn Sie Daten wiederherstellen, insbesondere bei Tabellen, die zum selben funktionalen Dataset gehören. Wenn Sie beispielsweise eine Verkaufstabelle zu einem Zeitpunkt wiederherstellen, der sich von dem der entsprechenden Inventartabelle unterscheidet, kann es zu einer Diskrepanz beim verfügbaren Bestand kommen. Auch Datenbankansichten, in denen Daten aus mehreren Tabellen zusammengefasst werden, können 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. Wenn Sie Ihre BigQuery-Sicherungsrichtlinien und ‑häufigkeiten entwerfen, müssen Sie diese Konsistenz berücksichtigen und dafür sorgen, dass Ihre wiederhergestellten Daten den tatsächlichen Zustand 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. Bei diesen Konfigurationen wird die genaue Zeit für den Tabellen-Snapshot über Zeitreisen berechnet, ohne dass alle Tabellen gleichzeitig gesichert werden müssen.
backup_cron: Steuert die Häufigkeit, mit der eine Tabelle gesichert wird. Der Start-Zeitstempel eines Laufs wird als Referenzpunkt für die Zeitreiseberechnung für alle Tabellen verwendet, die in diesem Lauf gesichert werden.backup_time_travel_offset_days: Steuert, wie viele Tage in der Vergangenheit vom Referenzzeitpunkt (Startzeit des Laufs) subtrahiert werden sollen, um die genaue Zeitreiseversion der Tabelle zu berechnen.
Automatisierte Wiederherstellung von Sicherungen
Diese Referenzarchitektur konzentriert sich zwar auf die Automatisierung von Sicherungen im großen Maßstab, Sie können aber auch in Erwägung ziehen, diese Sicherungen automatisiert wiederherzustellen. Diese zusätzliche Automatisierung kann ähnliche Vorteile wie die Automatisierung von Sicherungen bieten, darunter eine verbesserte Effizienz und Geschwindigkeit bei der Wiederherstellung mit weniger Ausfallzeiten. Da die Lösung alle Sicherungsparameter und ‑ergebnisse über den Tagger-Dienst verfolgt, können Sie eine ähnliche Architektur entwickeln, um die Wiederherstellungsvorgänge im großen Maßstab anzuwenden.
Sie könnten beispielsweise eine Lösung auf Grundlage eines On-Demand-Triggers erstellen, der einen Bereich von BigQuery-Daten an einen Dispatcher-Dienst sendet. Dieser Dienst sendet dann eine Anfrage pro Tabelle an einen Konfigurator-Dienst. Der Konfigurationsdienst kann den Sicherungsverlauf abrufen, den Sie für eine bestimmte Tabelle benötigen. Der Konfigurationsdienst könnte sie dann entweder an einen BigQuery-Snapshot-Wiederherstellungsdienst oder einen Cloud Storage-Wiederherstellungsdienst weiterleiten, um den Wiederherstellungsvorgang entsprechend auszuführen. Schließlich könnte ein Tagger-Dienst die Ergebnisse dieser Vorgänge in einem Status-Speicher speichern. Dadurch kann das automatisierte Wiederherstellungs-Framework von denselben Designzielen profitieren wie das in diesem Dokument beschriebene Sicherungs-Framework.
Kostenoptimierung
Das Framework dieser Architektur bietet Sicherungsrichtlinien, mit denen die folgenden Parameter für die allgemeine Kostenoptimierung festgelegt werden:
- Sicherungsmethode: Das Framework bietet die folgenden zwei Sicherungsmethoden:
- BigQuery-Snapshots, für die Speicherkosten basierend auf aktualisierten und gelöschten Daten im Vergleich zur Basistabelle anfallen. Snapshots sind daher kostengünstiger für Tabellen, die nur angehängt werden oder nur begrenzt aktualisiert werden.
- BigQuery-Exporte nach Cloud Storage, für die die Standardgebühren für die Speicherung anfallen. Bei großen Tabellen, die dem Ansatz „Kürzen und Laden“ folgen, ist es jedoch kostengünstiger, sie als Exporte in kostengünstigeren Speicherklassen zu sichern.
- Ablauf von Snapshots: Die Gültigkeitsdauer (Time-to-Live, TTL) wird für einen einzelnen Tabellensnapshot festgelegt, um Speicherkosten für den Snapshot auf unbestimmte Zeit zu vermeiden. Die Speicherkosten können im Laufe der Zeit steigen, wenn Tabellen nicht ablaufen.
Operative Effizienz
In diesem Abschnitt werden Features und Überlegungen zur operativen Effizienz beschrieben.
Detaillierte und skalierbare Sicherungsrichtlinien
Eines der Ziele dieses Frameworks ist die operative Effizienz durch die Steigerung der Geschäftsergebnisse bei relativ geringem und überschaubarem Geschäftsaufwand. Die Ausgabe ist beispielsweise eine große Anzahl von regelmäßig gesicherten Tabellen, während die Eingabe eine kleine Anzahl von verwalteten Sicherungsrichtlinien und -konfigurationen ist.
Das Framework ermöglicht nicht nur die Festlegung von Sicherungsrichtlinien auf Tabellenebene, sondern auch 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 Automatisierungs-Framework ist es wichtig, dass Sie die Status der Prozesse kennen. Sie sollten beispielsweise die Informationen für die folgenden häufigen Anfragen finden können:
- Die Sicherungsrichtlinie, die vom System für jede Tabelle verwendet wird.
- Der Sicherungsverlauf und die Sicherungsspeicherorte der einzelnen Tabellen.
- Der Gesamtstatus eines einzelnen Laufs (Anzahl der verarbeiteten und fehlgeschlagenen Tabellen).
- Die schwerwiegenden Fehler, die bei einem einzelnen Lauf aufgetreten sind, und die Komponenten oder Schritte des Prozesses, in denen sie aufgetreten sind.
Dazu werden bei jedem Ausführungsschritt, in dem ein Cloud Run-Dienst verwendet wird, strukturierte Logs in Cloud Logging geschrieben. Die Logs enthalten die Ein- und Ausgabe sowie Fehler und 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 überwachen und Berichte zu erstellen. Weitere Informationen zu Logs und Abfragen in BigQuery finden Sie unter An BigQuery weitergeleitete Logs ansehen.
Leistungsoptimierung
Um Tausende von Tabellen bei jedem Lauf zu verarbeiten, werden Sicherungsanfragen parallel verarbeitet. Der Dispatcher-Dienst listet alle Tabellen auf, die im BigQuery-Sicherungsbereich enthalten sind, und generiert bei jedem Lauf eine Sicherungsanfrage pro Tabelle. So kann die Anwendung Tausende von Anfragen und Tabellen parallel und nicht sequenziell verarbeiten.
Einige dieser Anfragen können anfangs aus vorübergehenden Gründen fehlschlagen, z. B. weil die Grenzwerte der zugrunde liegenden Google Cloud APIs erreicht wurden oder Netzwerkprobleme auftreten. Bis die Anfragen abgeschlossen sind, werden sie von Pub/Sub automatisch mit der exponentiellen Backoff-Wiederholungsrichtlinie wiederholt. Bei schwerwiegenden Fehlern wie ungültigen Sicherungszielen oder fehlenden Berechtigungen werden die Fehler protokolliert und die Ausführung der entsprechenden Tabellenanfrage wird beendet, ohne dass sich dies auf den Gesamtlauf auswirkt.
Limits
Für diese Architektur gelten die folgenden Kontingente und Limits.
Für Tabellensnapshots gilt für jedes von Ihnen angegebene Sicherungsvorgangsprojekt Folgendes:
- In einem Projekt können bis zu 100 Tabellen-Snapshot-Jobs gleichzeitig ausgeführt werden.
- In einem Projekt können bis zu 50.000 Tabellen-Snapshot-Jobs pro Tag ausgeführt werden.
- In einem Projekt können pro Tabelle und Tag bis zu 50 Tabellen-Snapshot-Jobs ausgeführt werden.
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.
- In einem Projekt können bis zu 100.000 Exporte pro Tag ausgeführt werden. Wenn Sie dieses Limit überschreiten möchten, müssen Sie eine Slot-Reservierung erstellen.
Weitere Informationen zum Erhöhen dieser Limits finden Sie unter Exportjobs.
In Bezug auf die Parallelitätslimits werden in dieser Architektur fehlgeschlagene Anfragen aufgrund dieser Limits automatisch mit Pub/Sub wiederholt, bis sie von der API verarbeitet werden. Andere Beschränkungen für die Anzahl der Vorgänge pro Projekt und Tag können jedoch durch eine Kontingenterhöhung oder durch die Verteilung der Sicherungsvorgänge (Snapshots oder Exporte) auf mehrere Projekte umgangen werden. Wenn Sie Vorgänge auf mehrere Projekte verteilen möchten, konfigurieren Sie die Sicherungsrichtlinien wie in den folgenden Bereitstellungsabschnitten beschrieben:
- Fallback-Sicherungsrichtlinien definieren
- Zusätzliche Projekte für Sicherungsvorgänge konfigurieren
- Sicherungsrichtlinien auf Tabellenebene festlegen
Bereitstellung
Informationen zum Bereitstellen dieser Architektur finden Sie unter Skalierbare BigQuery-Sicherungsautomatisierung bereitstellen.
Nächste Schritte
- Weitere Informationen zu BigQuery:
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.
Beitragende
Autor: Karim Wadie | Strategic Cloud Engineer
Weitere Beitragende:
- Chris DeForeest | Site Reliability Engineer
- Eyal Ben Ivri | Cloud Solutions Architect
- Jason Davenport | Developer Advocate
- Jaliya Ekanayake | Engineering Manager
- Muhammad Zain | Strategic Cloud Engineer