Informazioni sull'affidabilità

BigQuery ti consente di eseguire workload di analisi con interruzioni minime gestendo automaticamente gli errori delle macchine e delle zone all'interno di una regione. Per una maggiore resilienza, puoi configurare il ripristino di emergenza tra regioni, ripristinare i dati eliminati o danneggiati e implementare i nuovi tentativi di errore lato client per soddisfare i tuoi requisiti di affidabilità.

Queste funzionalità supportano workload che acquisiscono e analizzano grandi volumi di dati con prestazioni costanti, tra cui il rilevamento di anomalie, l'analisi in tempo reale con l'acquisizione di flussi di dati e l'analisi predittiva con BigQuery ML. Per esempi dettagliati di queste soluzioni, consulta Pattern di riferimento di BigQuery.

Dimensioni dell'affidabilità in BigQuery

Per determinare se BigQuery soddisfa i requisiti del tuo workload, puoi valutarne l'affidabilità in base a cinque dimensioni chiave: disponibilità, durabilità, coerenza dei dati, coerenza delle prestazioni e recupero dati.

Disponibilità

La disponibilità definisce la tua capacità di leggere dati da BigQuery o di scriverli. BigQuery è progettato per rendere le operazioni di lettura e scrittura a elevata affidabilità con uno SLA con uptime del 99,99%. Entrambe le operazioni coinvolgono due componenti:

  • Il servizio BigQuery
  • Risorse di computing necessarie per eseguire la query specifica

L'affidabilità del servizio dipende dall'API BigQuery specifica che utilizzi per recuperare i dati. La disponibilità delle risorse di computing dipende dalla capacità a tua disposizione quando esegui la query. Per saperne di più sull'unità di calcolo fondamentale per BigQuery e sull'economia delle risorse degli slot, consulta Informazioni sugli slot.

Durabilità

La durabilità misura la percentuale di dati che puoi leggere correttamente, come definito nel capitolo Implementazione degli SLO del Site Reliability Workbook. Per garantire un'elevata durabilità, BigQuery archivia automaticamente copie ridondanti dei tuoi dati in due zone all'interno della località selezionata.

Coerenza dei dati

La coerenza dei dati definisce come e quando puoi eseguire query sui dati dopo che sono stati scritti o modificati. Un aspetto della coerenza dei dati è garantire la semantica "exactly-once" per l'importazione dati. Per saperne di più, consulta Riprova gli inserimenti di job non riusciti.

Coerenza delle prestazioni

In generale, il rendimento può essere espresso in due dimensioni. La latenza è una misura del tempo di esecuzione di operazioni di recupero dati lunghe, come le query. La velocità effettiva è una misura della quantità di dati che BigQuery può elaborare in un periodo di tempo specifico. Grazie al design multi-tenant e scalabile orizzontalmente di BigQuery, la velocità effettiva può essere scalata fino a dimensioni dei dati arbitrarie. Il tuo caso d'uso specifico determina l'importanza relativa della latenza e del throughput.

Recupero dati

Puoi misurare la capacità di recuperare i dati dopo un'interruzione utilizzando le seguenti metriche:

  • Recovery Time Objective (RTO): il periodo di tempo massimo durante il quale i dati possono non essere disponibili dopo un incidente.
  • Recovery Point Objective (RPO): la quantità massima di dati raccolti prima dell'incidente che la tua organizzazione può tollerare di perdere.

Queste considerazioni sono particolarmente rilevanti nell'improbabile caso in cui una zona o una regione subisca un'interruzione di più giorni o distruttiva.

Pianificazione in caso di emergenza

In questa sezione, la pianificazione di emergenza copre gli errori che vanno dalla perdita di una singola macchina alla perdita catastrofica di un'intera regione. BigQuery gestisce automaticamente gli errori di singole macchine e zone, mentre gli errori di regione richiedono la progettazione dell'architettura per il ripristino, se il workload lo richiede. Capire dove termina il recupero automatico e dove inizia la tua responsabilità è essenziale per la pianificazione del ripristino di emergenza.

BigQuery offre uno SLA con uptime del 99,99%. Questa disponibilità è supportata dall'architettura regionale di BigQuery, che scrive i dati in due zone diverse ed esegue il provisioning della capacità di calcolo ridondante. Lo SLA di BigQuery è lo stesso per le regioni (come us-central1) e le multi-regioni (come US).

Gestione automatica degli errori

Poiché BigQuery è un servizio a livello di regione, gestisce automaticamente la perdita di una singola macchina o di un'intera zona. BigQuery astrae l'infrastruttura a livello di zona sottostante.

Perdita di una macchina

I guasti alle macchine sono un evento quotidiano alla scala in cui opera Google. BigQuery è progettato per gestire automaticamente gli errori delle macchine senza influire sulla zona di contenimento.

BigQuery suddivide ogni query in piccole attività e le invia in parallelo a più macchine. Se una macchina si guasta o si degrada, BigQuery riassegna automaticamente le attività interessate a un'altra macchina. Questo approccio è fondamentale per ridurre la latenza di coda.

BigQuery utilizza la codifica Reed-Solomon per archiviare in modo durevole una copia dei dati a livello di zona e archivia almeno un'altra copia a livello di zona in un'altra zona. Se più errori della macchina causano la perdita di una copia di zona, BigQuery rileva la perdita e crea una nuova copia di zona per ripristinare la ridondanza.

Perdita di una zona

Per soddisfare lo SLA con uptime del 99,99%, BigQuery fornisce la ridondanza automatica a livello di zona sia per i dati che per gli slot di computing. Poiché la disponibilità di computing in una singola zona non può soddisfare questo SLA da sola, BigQuery instrada automaticamente le nuove query a un'altra zona entro un minuto da un'interruzione grave della zona. Le query in corso potrebbero richiedere più tempo per essere completate, mentre le query appena eseguite vengono completate normalmente in un'altra zona.

Anche se una zona rimane non disponibile per un periodo prolungato, non si verifica alcuna perdita di dati perché BigQuery scrive i dati in modo sincrono in due zone. Di conseguenza, un'interruzione di zona non interrompe il servizio.

Tipi di errori

Esistono due tipi di errori: errori non irreversibili ed errori irreversibili.

Un errore non irreversibile è una carenza operativa in cui l'hardware non viene distrutto. Alcuni esempi sono un'interruzione di corrente, una partizione di rete o un arresto anomalo della macchina. BigQuery è progettato per prevenire la perdita di dati durante un errore non irreversibile.

Un guasto grave è un guasto operativo in cui l'hardware viene distrutto, ad esempio a causa di inondazioni, terremoti o uragani. La capacità di BigQuery di prevenire la perdita di dati durante un errore grave dipende dal fatto che l'errore interessi una singola zona o un'intera regione.

Ridondanza della località e comportamento in caso di errore

Quando crei un set di dati BigQuery, selezioni una località in cui archiviare i dati. Questa località è una delle seguenti:

  • Una regione: una posizione geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
  • Una località multiregionale: un'ampia area geografica che contiene due o più luoghi geografici, ad esempio gli Stati Uniti (US) o l'Europa (EU).

In entrambi i casi, BigQuery archivia automaticamente copie dei tuoi dati in due diverse zone Google Cloudall'interno di una singola regione nella località selezionata.

Oltre alla ridondanza dello spazio di archiviazione, BigQuery mantiene anche una capacità di calcolo ridondante in più zone. Combinando l'archiviazione e il computing ridondanti in più zone di disponibilità, BigQuery offre sia un'alta affidabilità che una durabilità elevata.

In caso di errore a livello di macchina, BigQuery continua a funzionare con un ritardo di pochi millisecondi e tutte le query attualmente in esecuzione continuano l'elaborazione. Durante un errore di zona lieve o grave, non si verifica alcuna perdita di dati, anche se potrebbe essere necessario inviare nuovamente le query attualmente in esecuzione. BigQuery mitiga automaticamente gli errori di zona lievi, come interruzioni di corrente, guasti ai trasformatori o partizioni di rete, nel giro di pochi minuti.

Un errore regionale lieve, come una perdita di connessione di rete a livello di regione, comporta una perdita di disponibilità fino a quando la regione non torna online, ma non comporta la perdita di dati. Un errore grave a livello di regione, ad esempio un disastro che distrugge un'intera regione, può comportare la perdita dei dati archiviati in quella regione. BigQuery non fornisce automaticamente un backup o una replica dei tuoi dati in un'altra regione geografica. Puoi utilizzare la replica dei set di dati tra regioni o il disaster recovery gestito per migliorare la resilienza agli errori regionali gravi.

Per saperne di più sulle località dei set di dati BigQuery, consulta Considerazioni sulla località.

Scenario: perdita della regione

BigQuery non fornisce durabilità o disponibilità se una regione fisica viene distrutta. Questa limitazione si applica sia alle regioni che alle multiregioni, pertanto per mantenere la durabilità e la disponibilità durante un'interruzione a livello di regione è necessario pianificare in anticipo. Se lo SLA del 99,99% di BigQuery non soddisfa i tuoi requisiti di disponibilità durante un'interruzione temporanea del servizio a livello di regione, valuta la possibilità di configurare la disponibilità ridondante tra le regioni.

Per evitare la perdita di dati in caso di distruzione di una regione, esegui il backup dei dati in un'altra posizione geografica. Ad esempio, puoi utilizzare la replica dei set di dati tra regioni per replicare continuamente i dati in una regione geograficamente distinta.

Se utilizzi una località multiregionale di BigQuery, non eseguire il backup dei dati in una singola regione all'interno dell'ambito geografico di quella località multiregionale. Ad esempio, se esegui il backup dei dati dalla multiregione US, evita di scegliere una regione sovrapposta come us-central1 per evitare il rischio di errori correlati durante un disastro. Per saperne di più sull'ambito geografico delle multi-regioni, consulta Multi-regioni.

Per evitare un'indisponibilità prolungata, replica i dati ed esegui il provisioning degli slot in due località BigQuery geograficamente separate. Puoi utilizzare il disaster recovery gestito per eseguire automaticamente il provisioning degli slot in una regione secondaria e controllare il failover dei workload da una regione all'altra.

Scenario: eliminazione accidentale o danneggiamento dei dati

Grazie all'architettura di controllo della concorrenza multiversione di BigQuery, BigQuery supporta i viaggi nel tempo. Con il viaggio nel tempo, puoi eseguire query sui dati di qualsiasi momento degli ultimi 7 giorni. Questa funzionalità ti consente di ripristinare i dati che sono stati eliminati, modificati o danneggiati per errore entro la finestra di 7 giorni. Il viaggio nel tempo funziona anche sulle tabelle che sono state eliminate.

BigQuery ti consente anche di creare snapshot delle tabelle per eseguire il backup dei dati all'interno della stessa regione per un periodo di tempo superiore alla finestra di viaggio nel tempo di 7 giorni. La creazione di uno snapshot è un'operazione di soli metadati che non comporta costi di archiviazione aggiuntivi. Sebbene gli snapshot delle tabelle contribuiscano a proteggere dall'eliminazione accidentale, non aumentano la durabilità dei dati.

Disaster recovery per l'analisi in tempo reale

Per una pipeline di analisi in tempo reale che importa continuamente i log degli endpoint di streaming in BigQuery, la protezione contro l'indisponibilità regionale estesa richiede la replica continua dei dati e il provisioning degli slot in una regione secondaria. Tuttavia, poiché l'architettura di importazione è già resiliente alla temporanea indisponibilità di BigQuery quando utilizza Pub/Sub e Dataflow come uno dei suoi metodi di caricamento dei dati, questo elevato livello di ridondanza potrebbe non valere il costo.

Ad esempio, supponiamo che tu configuri job di estrazione notturni per esportare i dati BigQuery da us-east4 nello spazio di archiviazione Archive di Cloud Storage in us-central1. Questa esportazione fornisce un backup durevole in caso di perdita catastrofica dei dati in us-east4. In questa configurazione, il Recovery Point Objective (RPO) è di 24 ore, perché il backup più recente può risalire a 24 ore prima. Il Recovery Time Objective (RTO) può essere di diversi giorni perché devi ripristinare i dati dal backup di Cloud Storage in BigQuery in us-central1. Se esegui il provisioning di BigQuery in una regione diversa da quella dei backup, devi prima trasferire i dati in quella regione. A meno che tu non acquisti in anticipo slot ridondanti nella regione di recovery, il provisioning della capacità BigQuery richiesta potrebbe richiedere più tempo a seconda della quantità richiesta.

Disaster recovery per il trattamento dati in batch

Per un workload di trattamento dati in batch in cui devi consegnare un report giornaliero fondamentale per l'attività a un ente regolatore entro una scadenza fissa, l'implementazione della ridondanza eseguendo due istanze separate dell'intera pipeline di trattamento dati spesso vale il costo. L'utilizzo di due regioni separate, ad esempio us-west1 e us-east4, fornisce una separazione geografica e due domini in errore indipendenti in caso di indisponibilità regionale estesa o perdita permanente della regione.

Se devi inviare il report esattamente una volta, devi riconciliare l'output quando entrambe le pipeline vengono completate correttamente. Un approccio consiste nel selezionare il risultato della pipeline che termina per prima, ad esempio pubblicando una notifica in un argomento Pub/Sub al termine. In alternativa, puoi consentire alla seconda pipeline di sovrascrivere il risultato e utilizzare il controllo delle versioni degli oggetti in Cloud Storage. Se la pipeline che termina per ultima scrive dati danneggiati, puoi ripristinare la versione scritta dalla prima pipeline da Cloud Storage.

Gestione degli errori

Le sezioni seguenti descrivono le best practice per la gestione degli errori che influiscono sull'affidabilità.

Ritenta le richieste API non riuscite

Quando le tue applicazioni client, librerie client o strumenti partner inviano richieste API a BigQuery, utilizza il backoff esponenziale troncato. Con questa strategia di ripetizione, se un client riceve un errore di sistema o di quota, riprova a inviare la richiesta fino a un numero massimo di volte utilizzando un intervallo di attesa casuale e crescente.

L'utilizzo del backoff esponenziale troncato rende l'applicazione più resiliente agli errori temporanei. Anche in condizioni operative normali, puoi aspettarti che circa una richiesta su 10.000 non vada a buon fine,come descritto nello SLA con disponibilità del 99, 99% di BigQuery. In condizioni anomale, questo tasso di errore potrebbe aumentare, ma se gli errori sono distribuiti in modo casuale, il backoff esponenziale può mitigare la maggior parte degli errori.

Se una richiesta non va a buon fine ripetutamente con un errore 5xx, contatta l'assistenza clienti Google Cloud e comunica chiaramente l'impatto sull'attività quando imposti la priorità della richiesta di assistenza, in modo che l'assistenza possa valutare il problema con precisione. Al contrario, se una richiesta non va a buon fine ripetutamente con un errore 4xx, puoi risolvere il problema modificando l'applicazione. Per maggiori dettagli, controlla il messaggio di errore.

Esempio di logica di backoff esponenziale

La logica di backoff esponenziale riprova una query o una richiesta aumentando il tempo di attesa tra i nuovi tentativi fino a un tempo di backoff massimo. I seguenti passaggi illustrano in che modo un client implementa il backoff esponenziale troncato:

  1. Invia una richiesta a BigQuery.

  2. Se la richiesta non va a buon fine, attendi 1 + random_number_milliseconds secondi e riprova.

  3. Se la richiesta non va a buon fine, attendi 2 + random_number_milliseconds secondi e riprova.

  4. Se la richiesta non va a buon fine, attendi 4 + random_number_milliseconds secondi e riprova.

  5. Ripeti questo schema, raddoppiando il tempo di attesa di base a ogni nuovo tentativo fino al maximum_backoff° tentativo.

  6. Continua ad attendere e riprovare fino al numero massimo di nuovi tentativi, senza aumentare il periodo di attesa oltre maximum_backoff.

Tieni presente i seguenti dettagli per questo calcolo del backoff:

  • Il tempo di attesa è min(((2^n)+random_number_milliseconds), maximum_backoff), con n incrementato di 1 per ogni iterazione (richiesta).

  • random_number_milliseconds è un numero casuale di millisecondi inferiore o uguale a 1000. Questa randomizzazione aiuta a evitare situazioni in cui molti client si sincronizzano per caso e riprovano contemporaneamente, inviando richieste in ondate sincronizzate. Ricalcola random_number_milliseconds dopo ogni richiesta di nuovo tentativo.

  • L'intervallo di backoff massimo (maximum_backoff) è in genere di 32 o 64 secondi. Il valore appropriato per maximum_backoff dipende dal tuo caso d'uso.

Il client può continuare a riprovare dopo aver raggiunto il tempo di backoff massimo. I nuovi tentativi dopo questo punto non devono continuare ad aumentare il tempo di backoff. Ad esempio, se il client utilizza un tempo di backoff massimo di 64 secondi, dopo aver raggiunto questo valore, può continuare a riprovare ogni 64 secondi. Per evitare loop di tentativi ripetuti all'infinito, configura un numero massimo di tentativi in modo che il client interrompa i tentativi dopo un limite impostato.

Il tempo di attesa tra i nuovi tentativi e il numero di nuovi tentativi dipendono dal caso d'uso e dalle condizioni della rete.

Riprova gli inserimenti di job non riusciti

Se l'applicazione richiede una semantica di inserimento exactly-once, valuta in che modo WriteDisposition del job gestisce i dati esistenti in una tabella (errore, sovrascrittura o aggiunta).

Con una disposizione WRITE_EMPTY o WRITE_TRUNCATE, puoi ottenere una semantica at-most-once riprovando l'inserimento o l'esecuzione di un job non riuscito, perché BigQuery scrive in modo atomico nella tabella tutte le righe importate da un job.

Con una disposizione WRITE_APPEND, specifica un ID job personalizzato in modo che un nuovo tentativo non aggiunga dati duplicati. Poiché BigQuery rifiuta qualsiasi richiesta di creazione di job che riutilizza un ID job precedente, la specifica di un ID job fornisce una semantica at-most-once per quell'ID. Puoi quindi ottenere la semantica "exactly-once" confermando che tutti i tentativi precedenti non sono riusciti prima di riprovare con un nuovo ID job prevedibile.

Se un problema di rete temporaneo impedisce al client di ricevere la conferma dell'inserimento di un job, un nuovo tentativo con lo stesso ID job non va a buon fine con status=ALREADY_EXISTS (code=409 e reason="duplicate"). Chiama jobs.get per recuperare lo stato del job esistente e determinare se creare un nuovo job con un nuovo ID job.

Casi d'uso e requisiti di affidabilità

BigQuery può fungere da componente fondamentale in una varietà di architetture. A seconda del caso d'uso e dell'architettura di cui esegui il deployment, potresti dover soddisfare requisiti di disponibilità, prestazioni e affidabilità diversi. Le sezioni seguenti esaminano due architetture comuni e i relativi requisiti di affidabilità.

Analisi in tempo reale

Il primo esempio è una pipeline di trattamento dati sugli eventi. In questa architettura, Pub/Sub importa gli eventi di log dagli endpoint e una pipeline Dataflow in modalità flusso elabora e scrive i dati in BigQuery utilizzando l'API BigQuery Storage Write. Gli analisti eseguono quindi query ad hoc sui dati per ricreare le sequenze di eventi e le dashboard quasi in tempo reale visualizzano i dati per rilevare tendenze e pattern.

Poiché questo workload richiede un'elevata aggiornamento dei dati end-to-end, una bassa latenza di importazione è fondamentale. Dopo che i dati sono stati scritti in BigQuery, l'affidabilità dipende da due fattori: se gli utenti possono eseguire query ad hoc con una latenza coerente e prevedibile e se le dashboard che utilizzano i dati riflettono le informazioni più recenti.

Trattamento dati in batch

Il secondo esempio è un'architettura di elaborazione batch per la conformità legale nel settore dei servizi finanziari. Un requisito fondamentale è fornire report giornalieri alle autorità di regolamentazione entro una scadenza fissa ogni notte. Se il processo di elaborazione batch notturno che genera i report viene completato entro questa scadenza, il requisito di prestazioni è soddisfatto.

La pipeline carica i dati in BigQuery e li unisce ad altre origini dati per la creazione di dashboard, l'analisi e la generazione di report in formato PDF. La generazione di questi report in tempo e senza errori è un requisito aziendale fondamentale. Pertanto, devi garantire l'affidabilità durante l'importazione dati e generare report accurati entro un periodo di tempo coerente per rispettare le scadenze normative.