Zuverlässigkeiten

Dieses Dokument bietet ein Verständnis der Zuverlässigkeitsfeatures von BigQuery, z. B. Verfügbarkeit, Langlebigkeit, Datenkonsistenz, Konsistenz von Leistung, Datenwiederherstellung sowie eine Erläuterung der Fehlerbehandlung.

Diese Einführung bietet drei grundlegende Überlegungen:

  • Ermitteln, ob BigQuery das richtige Tool für Ihren Job ist.
  • Informationen zu den Dimensionen der BigQuery-Zuverlässigkeit.
  • Zuverlässigkeitsanforderungen für bestimmte Anwendungsfälle identifizieren.

BigQuery auswählen

BigQuery ist ein vollständig verwaltetes Data Warehouse, das zum Speichern und Analysieren großer Datasets entwickelt wurde. Die Lösung bietet die Möglichkeit, Megabyte an Daten im Petabytebereich mit konsistenter Leistung aufzunehmen, zu speichern, zu lesen und abzufragen, ohne die zugrunde liegende Infrastruktur verwalten zu müssen. Aufgrund der Leistungsfähigkeit und Leistung eignet sich BigQuery gut für eine Reihe von Lösungen. Einige davon sind als Referenzmuster ausführlich dokumentiert.

Im Allgemeinen eignet sich BigQuery gut für Arbeitslasten, bei denen große Datenmengen aufgenommen und analysiert werden. Insbesondere kann es für Anwendungsfälle wie Echtzeit- und Vorhersagedatenanalysen (mit Streamingaufnahme und BigQuery ML), die Anomalieerkennung und andere Anwendungsfälle eingesetzt werden, bei denen die Analyse großer Datenmengen mit vorhersehbarer Leistung wichtig ist. Wenn Sie jedoch eine Datenbank suchen, die OLTP-Anwendungen (Online Transaction Processing) unterstützt, sollten Sie andere Google Cloud-Dienste in Betracht ziehen, wie z. B. Cloud Spanner, Cloud SQL oder Bigtable, die für diese Anwendungsfälle besser geeignet sein können.

Dimensionen der Zuverlässigkeit in BigQuery

Verfügbarkeit

Die Verfügbarkeit definiert die Fähigkeit des Nutzers, Daten aus BigQuery zu lesen oder in ihn zu schreiben. BigQuery ist darauf ausgelegt, beide Funktionen mit einem SLA von 99,99 % hochverfügbar zu machen. An beiden Vorgängen sind zwei Komponenten beteiligt:

  • Der BigQuery-Dienst
  • Zum Ausführen der spezifischen Abfrage erforderliche Rechenressourcen

Die Zuverlässigkeit des Dienstes ist eine Funktion der jeweiligen BigQuery API, die zum Abrufen der Daten verwendet wird. Die Verfügbarkeit von Computing-Ressourcen hängt von der Kapazität ab, die dem Nutzer zum Zeitpunkt der Ausführung der Abfrage zur Verfügung steht. Weitere Informationen zur grundlegenden Recheneinheit für BigQuery und zur daraus resultierenden Slot-Ressourcen finden Sie unter Slots verstehen.

Langlebigkeit

Die Langlebigkeit wird im Kapitel zur Implementierung von SLOs des SRE-Workbooks erläutert und als „Anteil der Daten, die erfolgreich gelesen werden können” beschrieben.

Datenkonsistenz

Die Konsistenz definiert die Erwartungen, die Nutzer haben, nachdem die Daten geschrieben oder geändert wurden, wie sie abgefragt werden können. Ein Aspekt der Datenkonsistenz ist die Sicherstellung einer genau einmaligen Semantik für die Datenaufnahme. Weitere Informationen finden Sie unter "Zuverlässigkeit der Lösung" in Beispielanwendungsfälle beim Laden von Daten und Fehlgeschlagene Jobeinfügungen wiederholen.

Leistungskonsistenz

Im Allgemeinen kann die Leistung in zwei Dimensionen ausgedrückt werden. Die Latenz ist ein Maß für die Ausführungszeit langer Vorgänge zum Abrufen von Daten wie Abfragen. Der Durchsatz ist ein Maß dafür, wie viele Daten BigQuery in einem bestimmten Zeitraum verarbeiten kann. Aufgrund des mehrmandantenfähigen, horizontal skalierbaren Designs von BigQuery kann sein Durchsatz auf beliebige Datengrößen hochskaliert werden. Die relative Wichtigkeit von Latenz und Durchsatz wird durch den spezifischen Anwendungsfall bestimmt.

Datenwiederherstellung

Es gibt zwei Wege, die Möglichkeit zur Wiederherstellung von Daten nach einem Ausfall zu messen:

  • Recovery Time Objective (RTO). Wie lange Daten nach einem Vorfall nicht verfügbar sein können.
  • Recovery Point Objective (RPO) Der akzeptable Umfang der vor dem Vorfall erfassten Daten, der verloren gehen kann.

Diese Überlegungen sind insbesondere im unwahrscheinlichen Fall relevant, dass eine Zone oder Region einen mehrtägigen oder destruktiven Ausfall verursacht.

Katastrophenplanung

Auch wenn der Begriff „Katastrophe“ Vorstellungen von Naturkatastrophen hervorrufen kann, behandelt dieser Abschnitt spezifische Fehler vom Verlust einer einzelnen Maschine bis hin zu einem Totalausfall einer Region. Erstere sind tägliche Vorkommen, die BigQuery automatisch ausführt, während Letztere etwas ist, bei dem Kunden gegebenenfalls ihre Architektur so entwickeln müssen, dass sie bei Bedarf ausgeführt wird. Es ist wichtig, zu verstehen, in welchem Umfang die Notfallwiederherstellung auf den Kunden übertragen wird.

BigQuery bietet ein branchenführendes SLA mit einer Verfügbarkeit von 99,99 %. Dies wird durch die regionale Architektur von BigQuery ermöglicht, die Daten in zwei verschiedenen Zonen schreibt und redundante Rechenkapazität bereitstellt. Beachten Sie, dass das BigQuery-SLA für Regionen (z. B. us-central1) und mehrere Regionen (z. B. USA) identisch ist.

Automatische Szenarioverarbeitung

Da BigQuery ein regionaler Dienst ist, liegt es in der Verantwortung von BigQuery, den Verlust einer Maschine oder sogar einer ganzen Zone automatisch zu bewältigen. Die Tatsache, dass BigQuery auf Zonen basiert, ist von Nutzern abstrahiert.

Verlust einer Maschine

Maschinenausfälle sind ein tägliches Auftreten in dem Umfang, in dem Google arbeitet. BigQuery ist so konzipiert, dass Maschinenausfälle automatisch ohne Auswirkungen auf die enthaltende Zone verarbeitet werden.
Die Ausführung einer Abfrage wird in kleine Aufgaben aufgeteilt, die parallel an viele Maschinen weitergeleitet werden können. Der plötzliche Verlust oder die Beeinträchtigung der Maschinenleistung erfolgt automatisch durch Umverteilung der Arbeit auf eine andere Maschine. Ein solcher Ansatz ist entscheidend, um die Extremwertlatenz zu reduzieren.

BigQuery verwendet die Reed-Solomon-Codierung, um eine zonale Kopie Ihrer Daten effizient und dauerhaft zu speichern. Im sehr unwahrscheinlichen Fall, dass mehrere Maschinenfehler zum Verlust einer zonalen Kopie führen, werden die Daten auf die gleiche Weise in mindestens einer anderen Zone gespeichert. In einem solchen Fall erkennt BigQuery das Problem und erstellt eine neue zonale Kopie der Daten, um Redundanz wiederherzustellen.

Verlust einer Zone

Die zugrunde liegende Verfügbarkeit von Computing-Ressourcen in einer bestimmten Zone reicht nicht aus, um das SLA für eine Verfügbarkeit von 99,99 % von BigQuery zu erfüllen. Daher bietet BigQuery eine automatische zonale Redundanz für Daten- und Computing-Slots. Obwohl kurzlebige zonale Störungen nicht üblich sind, treten sie auf. Die BigQuery-Automatisierung führt jedoch innerhalb einer oder zwei Minuten nach schwerwiegenden Störungen ein Failover in eine andere Zone durch. Bereits ausgeführte Abfragen werden möglicherweise nicht sofort wiederhergestellt, neu ausgeführte Abfragen jedoch schon. Dies würde zum Ausdruck bringen, dass Inflight-Abfragen sehr lange dauern, während neu ausgegebene Abfragen schnell abgeschlossen werden.

Auch wenn eine Zone über einen längeren Zeitraum nicht verfügbar sein würde, würde es zu einem Datenverlust kommen, da BigQuery Daten synchron in zwei Zonen schreibt. Selbst wenn eine Zone ausfällt, kommt es bei Kunden zu keiner Dienstunterbrechung.

Arten von Ausfällen

Es gibt zwei Arten von Ausfällen: weiche und harte Ausfälle.

Ein weicher Ausfall ist ein Betriebsfehler, bei dem keine Hardware zerstört wird. Beispiele hierfür sind Stromausfall, Ausfall einer Netzwerkpartition oder der Absturz einer Maschine. Im Allgemeinen sollte BigQuery niemals auf Grund eines weichen Ausfalls Daten verlieren.

Ein harter Ausfall ist ein Betriebsfehler, bei dem Hardware zerstört wird. Harte Ausfälle sind schwerwiegender als weiche. Beispiele für harte Ausfälle sind Schäden durch Überschwemmungen, Terroranschläge, Erdbeben und Hurrikane.

Verfügbarkeit und Langlebigkeit

Beim Erstellen eines BigQuery-Datasets wählen Sie einen Speicherort für Ihre Daten aus. Dieser Speicherort ist einer der folgenden:

  • Eine Region: ein bestimmter geografischer Standort, z. B. Iowa (us-central1) oder Montreal (northamerica-northeast1).
  • Mehrere Regionen: ein großes geografisches Gebiet, das zwei oder mehr geografische Orte enthält, z. B. die USA (US) oder Europa (EU).

In beiden Fällen speichert BigQuery automatisch Kopien Ihrer Daten in zwei verschiedenen Google Cloud-Zonen innerhalb einer einzelnen Region am ausgewählten Standort.

Zusätzlich zur Speicherredundanz bietet BigQuery auch redundante Rechenkapazität über mehrere Zonen hinweg. Durch die Kombination redundanter Speicher- und Computing-Ressourcen über mehrere Verfügbarkeitszonen hinweg bietet BigQuery sowohl eine hohe Verfügbarkeit als auch eine Langlebigkeit.

Bei einem Ausfall auf Maschinenebene wird BigQuery mit einer Verzögerung von nur wenigen Millisekunden weiter ausgeführt. Alle aktuell ausgeführten Abfragen werden weiterhin verarbeitet. Bei einem weichen oder harten zonalen Ausfall wird kein Datenverlust erwartet. Derzeit ausgeführte Abfragen können jedoch fehlschlagen und noch einmal gesendet werden. Ein weicher Ausfall einer Zone, z. B. durch einen Stromausfall, einen zerstörten Transformator oder den Ausfall einer Netzwerkpartition, ist ein gut getesteter Vorfall, der automatisch innerhalb weniger Minuten behoben wird.

Ein weicher regionaler Ausfall, z. B. ein regionaler Ausfall der Netzwerkverbindung, führt zu einem Verlust der Verfügbarkeit, bis die Region wieder online ist, nicht aber zu Datenverlust. Ein harter regionaler Ausfall, wenn beispielsweise eine Katastrophe die gesamte Region zerstört, kann zum Verlust von Daten führen, die in dieser Region gespeichert sind. BigQuery stellt nicht automatisch eine Sicherung oder ein Replikat Ihrer Daten in einer anderen geografischen Region bereit. Sie können regionenübergreifende Dataset-Kopien erstellen, um Ihre Strategie zur Notfallwiederherstellung zu verbessern.

Weitere Informationen zu BigQuery-Dataset-Standorten finden Sie unter Überlegungen zum Standort.

Szenario: Verlust der Region

BigQuery bietet keine Langlebigkeit oder Verfügbarkeit im außergewöhnlich unwahrscheinlichen und nie dagewesenen Fall eines physischen Regionsverlusts. Dies gilt sowohl für "Regionen als auch für multiregionale Konfigurationen". Daher erfordert die Aufrechterhaltung der Langlebigkeit und Verfügbarkeit eines solchen Szenarios eine Kundenplanung. Bei einem vorübergehenden Verlust, z. B. bei einem Netzwerkausfall, sollte die redundante Verfügbarkeit berücksichtigt werden, wenn das SLA von 99,99 % für BigQuery nicht als ausreichend gilt.

Damit Datenverluste bei schädlichen Ausfällen vermieden werden, müssen Sie Daten an einem anderen geografischen Standort sichern. Sie können beispielsweise regelmäßig einen Snapshot Ihrer Daten in Google Cloud Storage in eine andere geografisch unterschiedliche Region exportieren. Dies kann wie im Anwendungsfall für die Batchdatenverarbeitung beschrieben erfolgen.
Bei BigQuery-Multiregionen sollten Sie keine Sicherung in Regionen erstellen, die sich im Bereich der Multiregionen befinden. Sichern Sie Ihre Daten beispielsweise in den USA nicht in der Region us-central1. Die Region und der multiregionale Standort können gemeinsame Ausfalldomains haben und das Katastrophenfall im Notfall gemeinsam haben. Sichern Sie Ihre Daten stattdessen in einer Region außerhalb der USA, z. B. northamerica-northeast1. Wenn für die Datenstandorte Sicherungen erforderlich sind, die innerhalb der USA gespeichert werden, sollten Sie zwei Regionen wie us-central1 und us-east1 besser koppeln.

Um eine erweiterte Nichtverfügbarkeit zu vermeiden, müssen Daten sowohl repliziert als auch Slots an zwei geografisch getrennten BigQuery-Standorten bereitgestellt werden. Ähnlich wie oben sollten Sie es vermeiden, Regionen und Multiregionen zu mischen, da diese möglicherweise in einer Katastrophe gemeinsame Folgen haben.

Die zuverlässigste Architektur für eine regionsredundante Einrichtung ist die Ausführung von Hot-Hot, auch als Aktiv-Aktiv bezeichnet. Dies bedeutet, dass Ihre Arbeitslast sowohl in Ihrer primären als auch in der sekundären Region parallel ausgeführt wird. Dies ist zwar teurer, aber die sekundäre Region wird kontinuierlich überprüft und funktioniert, wenn Sie ein Failover darauf ausführen müssen. Wenn die Verfügbarkeit während eines regionalen Ausfalls weniger wichtig ist, gewährleistet die Sicherung von Daten in einer anderen Region Langlebigkeit.

Szenario: Versehentliches Löschen oder Datenbeschädigungen

Aufgrund der Multiversions-Gleichzeitigkeitsarchitektur von BigQuery unterstützt BigQuery Zeitreisen. Mit diesem Feature können Sie Daten für jeden Zeitpunkt in den letzten sieben Tagen abfragen. Dies ermöglicht die Self-Service-Wiederherstellung aller Daten, die innerhalb eines siebentägigen Zeitraums versehentlich gelöscht, geändert oder beschädigt wurden. Zeitreisen funktionieren auch bei Tabellen, die gelöscht wurden.

BigQuery unterstützt auch die Möglichkeit, Tabellen zu erstellen. Mit diesem Feature können Sie Daten in derselben Region explizit für einen längeren Zeitraum als sieben Tage sichern. Ein Snapshot ist ein Metadatenvorgang und führt zu keinen zusätzlichen Speicherbyte. Dies kann zwar einen Schutz vor versehentlichem Löschen erhöhen, die Langlebigkeit der Daten wird jedoch nicht erhöht.

Anwendungsfall: Echtzeitanalysen

In diesem Anwendungsfall werden Streaming-Daten kontinuierlich aus Endpunktlogs in BigQuery aufgenommen. Zum Schutz vor erweiterter Nichtverfügbarkeit von BigQuery für die gesamte Region müssen Daten kontinuierlich bereitgestellt und Slots in einer anderen Region bereitgestellt werden. Da die Architektur aufgrund der Verwendung von Pub/Sub und Dataflow im Aufnahmepfad stabil für BigQuery ist, lohnt sich diese Redundanzstufe in Bezug auf die Kosten nicht.

Angenommen, der Nutzer hat BigQuery-Daten in us-east4 konfiguriert, um nachts mithilfe von Exportjobs in Cloud Storage unter der Klasse Archive Storage in us-central1 zu exportieren. Dies bietet eine dauerhafte Sicherung bei einem katastrophalen Datenverlust in us-east4. In diesem Fall beträgt das Recovery Point Objective (RPO) 24 Stunden, da die letzte exportierte Sicherung im schlimmsten Fall bis zu 24 Stunden alt sein kann. Das Recovery Time Objective (RTO) beträgt möglicherweise Tage, da Daten aus der Cloud Storage-Sicherung in BigQuery in us-central1 wiederhergestellt werden müssen. Wenn BigQuery in einer anderen Region bereitgestellt werden soll, in der Sicherungen gespeichert werden, müssen die Daten zuerst in diese Region übertragen werden. Beachten Sie außerdem, dass eine zusätzliche Verzögerung bei der Bereitstellung der erforderlichen BigQuery-Kapazität in Abhängigkeit von der angeforderten Menge entstehen kann, wenn Sie im Voraus keine redundanten Slots in der Wiederherstellungsregion erworben haben.

Anwendungsfall: Batchdatenverarbeitung

Für diesen Anwendungsfall ist es geschäftskritisch, dass ein täglicher Bericht mit einer festen Frist abgeschlossen wird, die an eine Aufsichtsbehörde gesendet werden muss. Die Implementierung von Redundanz durch die Ausführung von zwei separaten Instanzen der gesamten Verarbeitungspipeline lohnt sich wahrscheinlich. Die Verwendung von zwei separaten Regionen, z. B. us-west1 und us-east4, ermöglicht eine geografische Trennung und zwei unabhängige Ausfalldomains für den Fall einer längeren Nichtverfügbarkeit einer Region oder sogar eines unwahrscheinlichen Ereignisses bei einem dauerhaften Regionsverlust.

Angenommen, der Bericht muss genau einmal zugestellt werden, müssen wir den erwarteten Fall beider Pipelines abgleichen. Eine vernünftige Strategie ist es, einfach das Ergebnis der Pipeline, die zuerst beendet ist, auszuwählen, indem ein Pub/Sub-Thema nach erfolgreichem Abschluss benachrichtigt wird. Alternativ können Sie das Ergebnis überschreiben und das Cloud Storage-Objekt neu versionieren. Wenn die Pipeline, die später abgeschlossen wird, später beschädigte Daten schreibt, können Sie die Version wiederherstellen, die von der Pipeline geschrieben wurde, die zuerst in Cloud Storage geschrieben wurde.

Fehlerbehandlung

Im Folgenden finden Sie Best Practices zur Behebung von Fehlern, die sich auf die Zuverlässigkeit auswirken.

Fehlgeschlagene API-Anfragen wiederholen

Clients von BigQuery, einschließlich Clientbibliotheken und Partnertools, sollten beim Senden von API-Anfragen den abgeschnittenen exponentiellen Backoff verwenden. Dies bedeutet, dass ein Client, wenn er einen Systemfehler oder einen Kontingentfehler erhält, die Anfrage bis zu einem bestimmten Zeitpunkt wiederholt, jedoch mit einem zufälligen und steigenden Backoff-Intervall.

Der Einsatz dieser Methode von Wiederholungsversuchen macht Ihre Anwendung im Hinblick auf Fehler wesentlich robuster. Auch unter normalen Betriebsbedingungen können Sie davon ausgehen, dass ein Mal pro zehntausend Anfragen fehlschlagen wird, wie im SLA zur Verfügbarkeit von 99,99 % in BigQuery beschrieben. Unter abnormalen Bedingungen kann sich die Fehlerrate erhöhen. Wenn Fehler jedoch zufällig verteilt werden, kann die Strategie des exponentiellen Backoffs alle bis auf die schwerwiegenden Fälle alle minimieren.

Wenn ein Szenario auftritt, bei dem eine Anfrage dauerhaft mit einem 5XX-Fehler fehlschlägt, sollten Sie an den Google Cloud-Support eskalieren. Achten Sie darauf, die Auswirkungen, die der Fehler auf Ihr Unternehmen hat, eindeutig zu kommunizieren, damit das Problem korrekt gesichtet werden kann. Wenn dagegen eine Anfrage dauerhaft mit einem 4XX-Fehler fehlschlägt, sollte das Problem durch Änderungen an Ihrer Anwendung behoben werden. Weitere Informationen finden Sie in der Fehlermeldung.

Beispiel für exponentielle Backoff-Logik

Die exponentielle Backoff-Logik wiederholt eine Abfrage oder Anfrage. Dazu wird die Wartezeit zwischen Wiederholungen bis zur maximalen Backoff-Zeit erhöht. Beispiel:

  1. Stellen Sie eine Anfrage an BigQuery.

  2. Wenn die Anfrage fehlschlägt, wartet das System 1 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.

  3. Wenn die Anfrage fehlschlägt, wartet das System 2 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.

  4. Wenn die Anfrage fehlschlägt, wartet das System 4 + random_number_milliseconds Sekunden und wiederholt dann die Anfrage.

  5. Und so weiter bis zur maximum_backoff-Zeit.

  6. Setzen Sie die Wartezeit fort und wiederholen Sie den Vorgang bis zu einer maximalen Anzahl an Wiederholungsversuchen. Erhöhen Sie jedoch nicht die Wartezeit zwischen den Wiederholungsversuchen.

Bitte beachten Sie dabei Folgendes:

  • Die Wartezeit beträgt min(((2^n)+random_number_milliseconds), maximum_backoff), wobei n bei jeder Ausführung (Anfrage) um 1 erhöht wird.

  • random_number_milliseconds steht für eine zufällige Anzahl von Millisekunden, deren Wert größer oder gleich 1.000 ist. Durch diese Randomisierung lassen sich Situationen vermeiden, in denen viele Clients synchronisiert werden und alle gleichzeitig Anfragen wiederholen und diese in synchronisierten Wellen senden. Der Wert von random_number_milliseconds wird nach jeder Anfragewiederholung neu berechnet.

  • Das maximale Backoff-Intervall (maximum_backoff) beträgt in der Regel 32 oder 64 Sekunden. Der geeignete Wert für maximum_backoff hängt vom jeweiligen Anwendungsfall ab.

Der Client kann den Vorgang wiederholen, nachdem er die maximale Backoff-Zeit erreicht hat. Die Backoff-Zeit muss dabei nicht mehr verlängert werden. Wenn der Client beispielsweise eine maximale Backoff-Zeit von 64 Sekunden verwendet, kann er den Vorgang nach Erreichen dieses Werts alle 64 Sekunden noch einmal versuchen. Sie sollten jedoch dafür sorgen, dass er dies nicht unbegrenzt tut.

Die Wartezeit zwischen den Wiederholungen und der Anzahl der Wiederholungen hängt von Ihrem Anwendungsfall und den Netzwerkbedingungen ab.

Fehlgeschlagene Jobeinfügungen wiederholen

Wenn die Semantik für das genau einmalige Einfügen für Ihre Anwendung wichtig ist, müssen Sie beim Einfügen von Jobs zusätzliche Überlegungen beachten. Wie die Semantik höchstens einmal erreicht werden soll, hängt davon ab, welche WriteDisposition Sie angeben. Die Schreibanordnung gibt für BigQuery an, was mit vorhandenen Daten in einer Tabelle geschehen soll: fehlschlagen, überschreiben oder anfügen.

Mit einer WRITE_EMPTY- oder WRITE_TRUNCATE-Konfiguration kann dies erreicht werden, indem einfach fehlgeschlagene Jobeinfügungen oder -ausführungen wiederholt werden. Dies liegt daran, dass alle von einem Job aufgenommenen Zeilen in kleinstmöglichen Schritten in die Tabelle geschrieben werden.

Mit einer WRITE_APPEND-Disposition muss der Client die Job-ID angeben, die vor einem erneuten Versuch, dieselben Daten ein zweites Mal anzuhängen, geschützt werden soll. Dies funktioniert, da BigQuery Anfragen zur Joberstellung ablehnt, die versuchen, eine ID aus einem vorherigen Job zu verwenden. Dadurch wird die Semantik höchstens für eine bestimmte Job-ID erreicht. Wiederholen Sie den Vorgang unter einer neuen vorhersehbaren Job-ID, sobald Sie mit BigQuery bestätigt haben, dass alle vorherigen Versuche fehlgeschlagen sind.

In einigen Fällen erhält der API-Client oder HTTP-Client aufgrund von vorübergehenden Problemen oder Netzwerkunterbrechungen möglicherweise nicht die Bestätigung, dass der Job eingefügt wird. Wenn die Einfügung wiederholt wird, schlägt diese Anfrage mit status=ALREADY_EXISTS (code=409 und reason="duplicate") fehl. Der vorhandene Jobstatus kann mit einem Aufruf von jobs.get abgerufen werden. Nachdem der Status des vorhandenen Jobs retrieved lautet, kann der Aufrufer bestimmen, ob ein neuer Job mit einer neuen JOB-ID erstellt werden soll.

Anwendungsfälle und Zuverlässigkeitsanforderungen

BigQuery kann eine kritische Komponente einer Vielzahl von Architekturen sein. Je nach Anwendungsfall und Architektur werden möglicherweise verschiedene Anforderungen an Verfügbarkeit, Leistung oder andere Zuverlässigkeit erfüllt. Für diese Anleitung wählen wir zwei primäre Anwendungsfälle und Architekturen aus, die ausführlich erläutert werden sollen.

Echtzeitanalysen

Das erste Beispiel ist eine Pipeline zur Ereignisdatenverarbeitung. In diesem Beispiel werden Logereignisse von Endpunkten über Pub/Sub aufgenommen. Von dort aus führt eine Streaming-Dataflow-Pipeline einige Vorgänge an den Daten aus, bevor sie mithilfe der Storage Write API in BigQuery geschrieben werden. Die Daten werden dann für Ad-hoc-Abfragen verwendet, um beispielsweise Ereignissequenzen neu zu erstellen, die zu bestimmten Endpunktergebnissen geführt haben können, und um Dashboards nahezu in Echtzeit zu übergeben, um Trends und Muster in den Daten durch Visualisierung erfassen zu können.

In diesem Beispiel müssen Sie mehrere Aspekte der Zuverlässigkeit berücksichtigen. Da die Anforderungen an die End-to-End-Datenaktualität relativ hoch sind, ist die Latenz des Aufnahmeprozesses von entscheidender Bedeutung. Nachdem Daten in BigQuery geschrieben wurden, wird Zuverlässigkeit als die Fähigkeit der Nutzer betrachtet, Ad-hoc-Abfragen mit konsistenter und vorhersehbarer Latenz durchzuführen und sicherzustellen, dass Dashboards, die die Daten nutzen, die absolut neuesten verfügbaren Informationen widerspiegeln.

Batchdatenverarbeitung

Das zweite Beispiel ist eine Batchverarbeitungsarchitektur, die auf der Einhaltung gesetzlicher Vorschriften in der Finanzdienstleistungsbranche basiert. Eine wichtige Anforderung ist es, täglich Berichte an Aufsichtsbehörden innerhalb einer festen nächtlichen Frist zu senden. Solange der nächtliche Batchprozess die Berichte innerhalb dieser Frist generiert, ist dies ausreichend schnell.

Daten müssen in BigQuery verfügbar gemacht und mit anderen Datenquellen verknüpft werden, um Dashboards erstellen, analysieren und letztendlich einen PDF-Bericht erstellen zu können. Es ist von entscheidender Bedeutung, diese Berichte rechtzeitig und ohne Fehler zu senden. Daher ist die Zuverlässigkeit sowohl bei der Dateneingabe als auch bei der korrekten Erstellung des Berichts in einem konsistenten Zeitrahmen zur Einhaltung der erforderlichen Fristen von entscheidender Bedeutung.

Nächste Schritte