Zuverlässigkeiten

Mit BigQuery können Sie Analysearbeitslasten mit minimalen Unterbrechungen ausführen, da Maschinen- und Zonenausfälle innerhalb einer Region automatisch verarbeitet werden. Für eine umfassendere Ausfallsicherheit können Sie eine regionenübergreifende Notfallwiederherstellung konfigurieren, gelöschte oder beschädigte Daten wiederherstellen und clientseitige Fehlerwiederholungen implementieren, um Ihre Zuverlässigkeitsanforderungen zu erfüllen.

Diese Funktionen unterstützen Arbeitslasten, die große Datenmengen mit konsistenter Leistung aufnehmen und analysieren, einschließlich Anomalieerkennung, Echtzeitanalysen mit Streamingaufnahme und prädiktive Analysen mit BigQuery ML. Detaillierte Beispiele für diese Lösungen finden Sie unter BigQuery-Referenzmuster.

Dimensionen der Zuverlässigkeit in BigQuery

Um festzustellen, ob BigQuery die Anforderungen Ihrer Arbeitslast erfüllt, können Sie die Zuverlässigkeit anhand von fünf wichtigen Dimensionen bewerten: Verfügbarkeit, Langlebigkeit, Datenkonsistenz, Leistungskonsistenz und Datenwiederherstellung.

Verfügbarkeit

Die Verfügbarkeit definiert Ihre Fähigkeit, Daten aus BigQuery zu lesen oder in BigQuery zu schreiben. BigQuery ist darauf ausgelegt, sowohl Lese- als auch Schreibvorgänge mit einem SLA mit einer Verfügbarkeit 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 Sie zum Abrufen der Daten verwenden. Die Verfügbarkeit von Computing-Ressourcen hängt von der Kapazität ab, die Ihnen zum Zeitpunkt der Ausführung der Abfrage zur Verfügung steht. Weitere Informationen zur grundlegenden Recheneinheit für BigQuery und zur Slot-Ressourcenwirtschaft finden Sie unter Slots verstehen.

Langlebigkeit

Die Langlebigkeit misst den Anteil der Daten, die Sie erfolgreich lesen können, wie im Kapitel Implementierung von SLOs des Site Reliability Workbooks definiert. Um eine hohe Langlebigkeit zu gewährleisten, speichert BigQuery automatisch redundante Kopien Ihrer Daten in zwei Zonen am ausgewählten Standort.

Datenkonsistenz

Die Datenkonsistenz definiert, wie und wann Sie Daten abfragen können, nachdem sie geschrieben oder geändert wurden. Ein Aspekt der Datenkonsistenz ist die Sicherstellung einer genau einmaligen Semantik für die Datenaufnahme. Weitere Informationen finden Sie unter 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. Ihr spezifischer Anwendungsfall bestimmt die relative Wichtigkeit von Latenz und Durchsatz.

Datenwiederherstellung

Sie können die Möglichkeit zur Wiederherstellung von Daten nach einem Ausfall mithilfe der folgenden Messwerte messen:

  • Recovery Time Objective (RTO): die maximale Zeit, die Daten nach einem Vorfall nicht verfügbar sein können.
  • Recovery Point Objective (RPO): Die maximale Menge an Daten, die vor dem Vorfall erfasst wurden und deren Verlust Ihr Unternehmen tolerieren kann.

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

Katastrophenplanung

In diesem Abschnitt umfasst die Notfallplanung Ausfälle, die vom Verlust einer einzelnen Maschine bis hin zum Totalausfall einer ganzen Region reichen. BigQuery verarbeitet Ausfälle einzelner Maschinen und zonaler Ausfälle automatisch. Bei regionalen Ausfällen müssen Sie Ihre Architektur für die Wiederherstellung entwerfen, wenn Ihre Arbeitslast dies erfordert. Für die Notfallplanung ist es wichtig, zu wissen, wo die automatische Wiederherstellung endet und Ihre Verantwortung beginnt.

BigQuery bietet ein SLA mit einer Verfügbarkeit von 99,99 %. Diese Verfügbarkeit wird durch die regionale Architektur von BigQuery unterstützt, die Daten in zwei verschiedene Zonen schreibt und redundante Rechenkapazität bereitstellt. Das BigQuery-SLA ist für Regionen (z. B. us-central1) und multiregionale Standorte (z. B. US) identisch.

Automatische Fehlerbehandlung

Da BigQuery ein regionaler Dienst ist, werden der Verlust einer einzelnen Maschine oder einer ganzen Zone automatisch bewältigt. BigQuery abstrahiert die zugrunde liegende zonale Infrastruktur.

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.

BigQuery teilt jede Abfrage in kleine Aufgaben auf und verteilt sie parallel auf viele Maschinen. Wenn eine Maschine ausfällt oder die Leistung nachlässt, verteilt BigQuery die betroffenen Aufgaben automatisch auf eine andere Maschine. Dieser Ansatz ist entscheidend, um die Extremwertlatenz zu reduzieren.

BigQuery verwendet die Reed-Solomon-Codierung, um eine zonale Kopie Ihrer Daten dauerhaft zu speichern, und speichert mindestens eine zusätzliche zonale Kopie in einer anderen Zone. Wenn mehrere Maschinenfehler zum Verlust einer zonalen Kopie führen, erkennt BigQuery den Verlust und erstellt eine neue zonale Kopie, um die Redundanz wiederherzustellen.

Verlust einer Zone

Um das SLA für eine Verfügbarkeit von 99,99 % zu erfüllen, bietet BigQuery eine automatische zonale Redundanz für Daten- und Computing-Slots. Da die Verfügbarkeit von Compute-Ressourcen in einer einzelnen Zone dieses SLA nicht allein erfüllen kann, leitet BigQuery neue Abfragen innerhalb einer Minute nach einer schwerwiegenden zonalen Störung automatisch an eine andere Zone weiter. Inflight-Abfragen können länger dauern, während neu ausgegebene Abfragen in einer anderen Zone normal abgeschlossen werden.

Auch wenn eine Zone über einen längeren Zeitraum nicht verfügbar ist, kommt es zu keinem Datenverlust, da BigQuery Daten synchron in zwei Zonen schreibt. Daher wird Ihr Dienst durch einen zonalen Ausfall nicht unterbrochen.

Arten von Ausfällen

Es gibt zwei Arten von Fehlern: weiche und harte Fehler.

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. BigQuery ist so konzipiert, dass Datenverluste bei einem Soft Failure verhindert werden.

Ein harter Ausfall ist ein Betriebsfehler, bei dem Hardware zerstört wird, z. B. durch Überschwemmungen, Erdbeben oder Hurrikane. Ob BigQuery Datenverluste bei einem schwerwiegenden Fehler verhindern kann, hängt davon ab, ob der Fehler eine einzelne Zone oder eine gesamte Region betrifft.

Standortredundanz und Fehlerverhalten

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).
  • Multiregional: 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 Hochverfügbarkeit als auch eine Langlebigkeit.

Bei einem Ausfall auf Maschinenebene wird BigQuery mit einer Verzögerung von nur wenigen Millisekunden weiter ausgeführt und alle aktuell ausgeführten Abfragen werden weiter verarbeitet. Bei einem weichen oder harten Zonenausfall kommt es zu keinem Datenverlust. Möglicherweise müssen Sie jedoch aktuell ausgeführte Abfragen noch einmal senden. BigQuery behebt innerhalb weniger Minuten automatisch weiche zonale Ausfälle wie Stromausfälle, Transformatorausfälle oder Netzwerkpartitionen.

Ein weicher regionaler Ausfall, z. B. ein regionenweiter Verlust der Netzwerkverbindung, führt zu einem Verlust der Verfügbarkeit, bis die Region wieder online ist. Es kommt jedoch nicht zu einem Datenverlust. Ein schwerwiegender regionaler Ausfall, z. B. eine Katastrophe, die eine ganze Region zerstört, kann zum Verlust der in dieser Region gespeicherten Daten führen. BigQuery stellt nicht automatisch eine Sicherung oder ein Replikat Ihrer Daten in einer anderen geografischen Region bereit. Sie können die regionenübergreifende Dataset-Replikation oder die verwaltete Notfallwiederherstellung verwenden, um die Ausfallsicherheit bei schwerwiegenden regionalen Ausfällen 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, wenn eine physische Region zerstört wird. Diese Einschränkung gilt sowohl für Regionen als auch für Multiregionen. Wenn Sie also die Langlebigkeit und Verfügbarkeit während eines regionalen Ausfalls aufrechterhalten möchten, müssen Sie im Voraus planen. Wenn das SLA von 99,99 % für BigQuery Ihre Verfügbarkeitsanforderungen während eines vorübergehenden regionalen Ausfalls nicht erfüllt, sollten Sie eine redundante Verfügbarkeit über Regionen hinweg konfigurieren.

Damit Datenverluste bei einem Ausfall einer Region vermieden werden, müssen Sie Daten an einem anderen geografischen Standort sichern. Sie können beispielsweise die regionsübergreifende Dataset-Replikation verwenden, um Ihre Daten kontinuierlich in eine geografisch unterschiedliche Region zu replizieren.

Wenn Sie eine BigQuery-Multiregion verwenden, sollten Sie keine Daten in einer einzelnen Region innerhalb des geografischen Bereichs dieser Multiregion sichern. Wenn Sie beispielsweise Daten aus der Multiregion US sichern, sollten Sie keine sich überschneidende Region wie us-central1 auswählen, da im Katastrophenfall das Risiko eines korrelierten Ausfalls besteht. Weitere Informationen zum geografischen Umfang von Multiregionen finden Sie unter Multiregionen.

Um eine erweiterte Nichtverfügbarkeit zu vermeiden, replizieren Sie Ihre Daten und stellen Sie Slots an zwei geografisch getrennten BigQuery-Standorten bereit. Mit der verwalteten Notfallwiederherstellung können Sie automatisch Slots in einer sekundären Region bereitstellen und das Failover Ihrer Arbeitslasten von einer Region in eine andere steuern.

Szenario: Versehentliches Löschen oder Datenbeschädigungen

Aufgrund der Multiversions-Gleichzeitigkeitsarchitektur von BigQuery unterstützt BigQuery Zeitreisen. Mit Zeitreisen können Sie Daten für jeden Zeitpunkt in den letzten sieben Tagen abfragen. Mit dieser Funktion können Sie Daten wiederherstellen, die innerhalb von 7 Tagen versehentlich gelöscht, geändert oder beschädigt wurden. Zeitreisen funktionieren auch bei Tabellen, die gelöscht wurden.

Mit BigQuery können Sie auch Tabellen-Snapshots erstellen, um Daten in derselben Region für einen längeren Zeitraum als sieben Tage zu sichern. Das Erstellen eines Snapshots ist ein reiner Metadatenvorgang, für den keine zusätzlichen Speichergebühren anfallen. Tabellen-Snapshots helfen zwar, versehentliches Löschen zu verhindern, erhöhen aber nicht die Langlebigkeit der Daten.

Notfallwiederherstellung für Echtzeitanalysen

Bei einer Echtzeit-Analysepipeline, die kontinuierlich Streaming-Endpunktlogs in BigQuery aufnimmt, ist zum Schutz vor längerer regionaler Nichtverfügbarkeit eine kontinuierliche Replikation von Daten und die Bereitstellung von Slots in einer sekundären Region erforderlich. Da die Aufnahmearchitektur jedoch bereits stabil gegenüber vorübergehender BigQuery-Nichtverfügbarkeit ist, wenn Pub/Sub und Dataflow als eine der Datenlademethoden verwendet werden, lohnt sich diese hohe Redundanzstufe möglicherweise nicht in Bezug auf die Kosten.

Angenommen, Sie konfigurieren nächtliche Extraktionsjobs, um BigQuery-Daten aus us-east4 in Cloud Storage Archive Storage in us-central1 zu exportieren. Dieser Export bietet eine dauerhafte Sicherung, falls in us-east4 ein katastrophaler Datenverlust auftritt. In dieser Konfiguration beträgt das Recovery Point Objective (RPO) 24 Stunden, da die letzte Sicherung bis zu 24 Stunden alt sein kann. Das Recovery Time Objective (RTO) kann mehrere Tage betragen, da Sie die Daten aus der Cloud Storage-Sicherung in BigQuery in us-central1 wiederherstellen müssen. Wenn Sie BigQuery in einer anderen Region als Ihre Sicherungen bereitstellen, müssen Sie die Daten zuerst in diese Region übertragen. Wenn Sie im Voraus keine redundanten Slots in der Wiederherstellungsregion erwerben, kann die Bereitstellung der erforderlichen BigQuery-Kapazität je nach angeforderter Menge zusätzliche Zeit in Anspruch nehmen.

Notfallwiederherstellung für die Batchdatenverarbeitung

Bei einer Batchdatenverarbeitungs-Workload, bei der Sie einer Regulierungsbehörde bis zu einer festen Frist einen geschäftskritischen täglichen Bericht liefern müssen, lohnt sich die Implementierung von Redundanz durch die Ausführung von zwei separaten Instanzen der gesamten Verarbeitungspipeline oft. 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 eines dauerhaften Regionsverlusts.

Wenn Sie den Bericht genau einmal zustellen müssen, müssen Sie die Ausgabe abgleichen, wenn beide Pipelines erfolgreich abgeschlossen wurden. Ein Ansatz besteht darin, das Ergebnis der Pipeline auszuwählen, die zuerst beendet wird, z. B. durch Veröffentlichen einer Benachrichtigung in einem Pub/Sub-Thema nach Abschluss. Alternativ können Sie das Ergebnis von der zweiten Pipeline überschreiben lassen und die Objektversionierung in Cloud Storage verwenden. Wenn die Pipeline, die später abgeschlossen wird, beschädigte Daten schreibt, können Sie die Version wiederherstellen, die von der ersten Pipeline in Cloud Storage geschrieben wurde.

Fehlerbehandlung

In den folgenden Abschnitten werden Best Practices für den Umgang mit Fehlern beschrieben, die sich auf die Zuverlässigkeit auswirken.

Fehlgeschlagene API-Anfragen wiederholen

Wenn Ihre Clientanwendungen, Clientbibliotheken oder Partnertools API-Anfragen an BigQuery senden, verwenden Sie den abgeschnittenen exponentiellen Backoff. Wenn ein Client bei dieser Wiederholungsstrategie einen System- oder Kontingentfehler erhält, wiederholt er die Anfrage bis zu einer maximalen Anzahl von Malen mit einem zufälligen, zunehmenden Warteintervall.

Durch die Verwendung des abgeschnittenen exponentiellen Backoffs wird Ihre Anwendung widerstandsfähiger gegen vorübergehende Fehler. Auch unter normalen Betriebsbedingungen können Sie davon ausgehen, dass etwa eine von 10.000 Anfragen fehlschlägt,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 die meisten Fehler minimieren.

Wenn eine Anfrage dauerhaft mit einem 5xx-Fehler fehlschlägt, wenden Sie sich an Cloud Customer Care und kommunizieren Sie die geschäftlichen Auswirkungen klar, wenn Sie die Priorität der Supportanfrage festlegen, damit der Support das Problem genau sichten kann. Wenn dagegen eine Anfrage dauerhaft mit einem 4xx-Fehler fehlschlägt, können Sie das Problem durch Ändern Ihrer Anwendung beheben. Weitere Informationen finden Sie in der Fehlermeldung.

Beispiel für exponentielle Backoff-Logik

Bei der exponentiellen Backoff-Logik wird eine Abfrage oder Anfrage wiederholt, wobei die Wartezeit zwischen den Wiederholungen bis zu einer maximalen Backoff-Zeit verlängert wird. In den folgenden Schritten wird veranschaulicht, wie ein Client den abgeschnittenen exponentiellen Backoff implementiert:

  1. Anfrage an BigQuery senden

  2. Wenn die Anfrage fehlschlägt, warten Sie 1 + random_number_milliseconds Sekunden und wiederholen Sie die Anfrage.

  3. Wenn die Anfrage fehlschlägt, warten Sie 2 + random_number_milliseconds Sekunden und wiederholen Sie die Anfrage.

  4. Wenn die Anfrage fehlschlägt, warten Sie 4 + random_number_milliseconds Sekunden und wiederholen Sie die Anfrage.

  5. Wiederholen Sie dieses Muster und verdoppeln Sie die Basiswartezeit bei jedem Wiederholungsversuch bis zur Zeit maximum_backoff.

  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 über maximum_backoff hinaus.

Beachten Sie die folgenden Details für diese Backoff-Berechnung:

  • 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 kleiner oder gleich 1.000 ist. Diese Randomisierung hilft, Situationen zu vermeiden, in denen viele Clients zufällig synchronisiert werden und gleichzeitig Wiederholungsversuche ausführen, wodurch Anfragen in synchronisierten Wellen gesendet werden. 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. Konfigurieren Sie eine maximale Anzahl von Wiederholungsversuchen, damit der Client nach einer festgelegten Anzahl von Versuchen aufhört, um Endlosschleifen zu vermeiden.

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

Fehlgeschlagene Jobeinfügungen wiederholen

Wenn Ihre Anwendung eine genau einmalige Semantik für das Einfügen erfordert, sollten Sie sich überlegen, wie die WriteDisposition Ihres Jobs mit vorhandenen Daten in einer Tabelle umgeht (Fehler, Überschreiben oder Anfügen).

Mit einer WRITE_EMPTY- oder WRITE_TRUNCATE-Konfiguration können Sie eine „Höchstens einmal“-Semantik erreichen, indem Sie fehlgeschlagene Jobeinfügungen oder -ausführungen wiederholen, da BigQuery alle Zeilen, die ein Job aufnimmt, in kleinstmöglichen Schritten in die Tabelle schreibt.

Geben Sie bei einer WRITE_APPEND-Disposition eine benutzerdefinierte Job-ID an, damit bei einem Wiederholungsversuch keine doppelten Daten angehängt werden. Da BigQuery alle Anfragen zur Joberstellung ablehnt, die eine vorherige Job-ID wiederverwenden, bietet die Angabe einer Job-ID eine Semantik, die höchstens einmal für diese ID gilt. Sie können dann die „Genau einmal“-Semantik erreichen, indem Sie bestätigen, dass alle vorherigen Versuche fehlgeschlagen sind, bevor Sie es mit einer neuen vorhersehbaren Job-ID noch einmal versuchen.

Wenn ein vorübergehendes Netzwerkproblem verhindert, dass Ihr Client eine Bestätigung für das Einfügen eines Jobs erhält, schlägt ein Wiederholungsversuch mit derselben Job-ID mit status=ALREADY_EXISTS (code=409 und reason="duplicate") fehl. Rufen Sie jobs.get auf, um den Status des vorhandenen Jobs abzurufen und zu 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, die Sie bereitstellen, müssen Sie möglicherweise unterschiedliche Anforderungen an Verfügbarkeit, Leistung und Zuverlässigkeit erfüllen. In den folgenden Abschnitten werden zwei gängige Architekturen und ihre Zuverlässigkeitsanforderungen untersucht.

Echtzeitanalysen

Das erste Beispiel ist eine Pipeline zur Ereignisdatenverarbeitung. In dieser Architektur nimmt Pub/Sub Logereignisse von Endpunkten auf und eine Streaming-Dataflow-Pipeline verarbeitet die Daten und schreibt sie mithilfe der BigQuery Storage Write API in BigQuery. Analysten führen dann Ad-hoc-Abfragen für die Daten aus, um Ereignissequenzen neu zu erstellen, und Dashboards nahezu in Echtzeit visualisieren die Daten, um Trends und Muster zu erkennen.

Da diese Arbeitslast eine hohe End-to-End-Datenaktualität erfordert, ist eine niedrige Aufnahmelatenz von entscheidender Bedeutung. Nachdem Daten in BigQuery geschrieben wurden, hängt die Zuverlässigkeit von zwei Faktoren ab: ob Nutzer Ad-hoc-Abfragen mit konsistenter, vorhersehbarer Latenz ausführen können und ob Dashboards, die die Daten verwenden, die neuesten Informationen widerspiegeln.

Batchdatenverarbeitung

Das zweite Beispiel ist eine Batchverarbeitungsarchitektur für die Einhaltung gesetzlicher Vorschriften in der Finanzdienstleistungsbranche. 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, erfüllt er die Leistungsanforderung.

Die Pipeline lädt Daten in BigQuery und verknüpft sie mit anderen Datenquellen, um Dashboards erstellen, analysieren und PDF-Berichte erstellen zu können. Es ist von entscheidender Bedeutung, diese Berichte rechtzeitig und ohne Fehler zu senden. Daher müssen Sie bei der Datenaufnahme für Zuverlässigkeit sorgen und genaue Berichte innerhalb eines konsistenten Zeitrahmens erstellen, um die gesetzlichen Fristen einzuhalten.