Informazioni sull'affidabilità

Questo documento fornisce una panoramica delle funzionalità di affidabilità di BigQuery, come disponibilità, durabilità, coerenza dei dati, coerenza delle prestazioni, recupero dei dati e una revisione delle considerazioni sulla gestione degli errori.

Questa introduzione ti aiuta ad affrontare tre considerazioni principali:

  • Determina se BigQuery è lo strumento giusto per il tuo lavoro.
  • Comprendere le dimensioni dell'affidabilità di BigQuery.
  • Identifica requisiti di affidabilità specifici per casi d'uso specifici.

Seleziona BigQuery

BigQuery è un data warehouse aziendale completamente gestito creato per archiviare e analizzare set di dati di grandi dimensioni. Fornisce un modo per importare, archiviare, leggere ed eseguire query su dati da megabyte a petabyte con prestazioni costanti senza dover gestire l'infrastruttura sottostante. Grazie alla sua potenza e alle sue prestazioni, BigQuery è adatto a essere utilizzato in una vasta gamma di soluzioni. Alcuni di questi sono documentati in dettaglio come pattern di riferimento.

In generale, BigQuery è molto adatto ai carichi di lavoro in cui vengono importate e analizzate grandi quantità di dati. In particolare, può essere implementato in modo efficace per casi d'uso come l'analisi dei dati predittiva e in tempo reale (con l'importazione di flussi e BigQuery ML), il rilevamento di anomalie e altri casi d'uso in cui è fondamentale analizzare grandi volumi di dati con prestazioni prevedibili. Tuttavia, se stai cercando un database per supportare applicazioni di tipo Online Transaction Processing (OLTP), devi prendere in considerazione altri Google Cloud servizi come Spanner, Cloud SQL o Bigtable che potrebbero essere più adatti a questi casi d'uso.

Dimensioni dell'affidabilità in BigQuery

Disponibilità

La disponibilità definisce la capacità dell'utente di leggere i dati da BigQuery o scriverli. BigQuery è progettato per rendere entrambi altamente disponibili con uno SLA del 99,99%. Entrambe le operazioni coinvolgono due componenti:

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

L'affidabilità del servizio dipende dall'API BigQuery specifica utilizzata per recuperare i dati. La disponibilità delle risorse di calcolo dipende dalla capacità disponibile per l'utente al momento dell'esecuzione della query. Per saperne di più sull'unità di calcolo fondamentale per BigQuery e sull'economia delle risorse di slot risultante, consulta la sezione Informazioni sugli slot.

Durabilità

La durabilità è trattata nel capitolo sull'implementazione degli SLO del foglio di lavoro SRE ed è descritta come la "proporzione di dati che possono essere letti correttamente".

Coerenza dei dati

La coerenza definisce le aspettative degli utenti in merito alla modalità di query dei dati una volta scritti o modificati. Un aspetto della coerenza dei dati è garantire la semantica "esattamente una volta" per l&#39importazione datii. Per saperne di più, vedi Riprovare gli inserimenti di lavori non riusciti.

Coerenza del rendimento

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

Recupero dati

Esistono due modi per misurare la capacità di recuperare i dati dopo un'interruzione:

  • Recovery Time Objective (RTO). Per quanto tempo i dati possono non essere disponibili dopo un incidente.
  • Recovery Point Objective (RPO). Quanti dati raccolti prima dell'incidente possono essere persi in modo accettabile.

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

Pianificazione in caso di emergenza

Sebbene il termine "disastro" possa evocare immagini di calamità naturali, l'ambito di questa sezione riguarda guasti specifici, dalla perdita di una singola macchina fino alla perdita catastrofica di una regione. I primi sono eventi quotidiani che BigQuery gestisce automaticamente, mentre i secondi sono qualcosa che i clienti potrebbero dover progettare la propria architettura per gestire, se necessario. È importante capire in quale ambito la pianificazione di emergenza si sovrappone alla responsabilità del cliente.

BigQuery offre uno SLA con uptime del 99,99% leader del settore. Ciò è reso possibile dall'architettura regionale di BigQuery che scrive i dati in due zone diverse e fornisce capacità di calcolo ridondante. È importante tenere presente che lo SLA di BigQuery è lo stesso per le regioni, ad esempio us-central1, e per le regioni multiple, ad esempio US.

Gestione automatica degli scenari

Poiché BigQuery è un servizio regionale, è responsabilità di BigQuery gestire automaticamente la perdita di una macchina o anche di un'intera zona. Il fatto che BigQuery sia basato sulle zone è astratto per gli utenti.

Perdita di una macchina

I guasti alle macchine sono un evento quotidiano alla scala operativa di Google. BigQuery è progettato per gestire automaticamente i guasti delle macchine senza alcun impatto sulla zona contenente.
Dietro le quinte, l'esecuzione di una query viene suddivisa in piccole attività che possono essere distribuite in parallelo a più macchine. La perdita o il degrado improvviso delle prestazioni della macchina viene gestito automaticamente ridistribuendo il lavoro a una macchina diversa. Questo approccio è fondamentale per ridurre la latenza di coda.

BigQuery utilizza la codifica Reed-Solomon per archiviare in modo efficiente e duraturo una copia zonale dei tuoi dati. Nell'improbabile caso in cui più guasti alle macchine causino la perdita di una copia zonale, i dati vengono archiviati nello stesso modo in almeno un'altra zona. In questo caso, BigQuery rileva il problema e crea una nuova copia zonale dei dati per ripristinare la ridondanza.

Perdita di una zona

La disponibilità sottostante delle risorse di calcolo in una determinata zona non è sufficiente per soddisfare lo SLA di uptime del 99,99% di BigQuery. Pertanto, BigQuery fornisce una ridondanza di zona automatica sia per i dati sia per gli slot di calcolo. Anche se le interruzioni zonali di breve durata non sono comuni, possono verificarsi. L'automazione di BigQuery, tuttavia, indirizzerà le nuove query a un'altra zona entro un minuto da qualsiasi interruzione grave. Le query già in corso potrebbero non essere recuperate immediatamente, ma le query appena emesse sì. Ciò si manifesterebbe con query in corso che impiegano molto tempo per essere completate, mentre le query appena emesse vengono completate rapidamente.

Anche se una zona non fosse disponibile per un periodo di tempo più lungo, non si verificherebbe alcuna perdita di dati perché BigQuery scrive in modo sincrono i dati in due zone. In questo modo, anche in caso di perdita di zona, i clienti non subiranno un'interruzione del servizio.

Tipi di errori

Esistono due tipi di errori: soft failure e hard failure.

Il guasto soft è una carenza operativa in cui l'hardware non viene distrutto. Alcuni esempi sono interruzione dell'alimentazione, partizione di rete o arresto anomalo di una macchina. In generale, BigQuery non dovrebbe mai perdere dati in caso di errore soft.

Un guasto grave è una carenza operativa in cui l'hardware viene distrutto. Gli errori hard sono più gravi di quelli soft. Esempi di guasto grave includono danni causati da inondazioni, attacchi terroristici, terremoti e uragani.

Disponibilità e durabilità

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

  • Una regione: una posizione geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
  • Una località a più regioni: una realtà geografica di grandi dimensioni 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 dati in due Google Cloud zone diverse all'interno di una singola regione nella località selezionata.

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

In caso di errore a livello di macchina, BigQuery continua a funzionare con un ritardo di pochi millisecondi. Tutte le query attualmente in esecuzione continuano l'elaborazione. In caso di errore della zona temporaneo o permanente, non è prevista alcuna perdita di dati. Tuttavia, le query attualmente in esecuzione potrebbero non riuscire e devono essere inviate di nuovo. Un errore zonale soft, ad esempio causato da un'interruzione di corrente, da un trasformatore distrutto o da una partizione di rete, è un percorso ben testato e viene mitigato automaticamente in pochi minuti.

Un errore regionale temporaneo, ad esempio una perdita di connettività di rete a livello regionale, comporta la perdita di disponibilità finché la regione non viene ripristinata, ma non comporta la perdita di dati. Un errore regionale grave, ad esempio, se un disastro distrugge l'intera regione, potrebbe comportare la perdita dei dati archiviati in quella regione. BigQuery non fornisce automaticamente un backup o una replica dei dati in un'altra regione geografica. Puoi utilizzare la replica dei set di dati tra regioni o il recupero di emergenza gestito per migliorare la resilienza in caso di gravi errori regionali.

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

Scenario: perdita della regione

BigQuery non offre durabilità o disponibilità nell'evento straordinariamente improbabile e senza precedenti di perdita della regione fisica. Ciò vale sia per le regioni che per le multi-regioni. Pertanto, il mantenimento della durabilità e della disponibilità in questo scenario richiede una pianificazione da parte del cliente. In caso di perdita temporanea, ad esempio un'interruzione di rete, è necessario considerare la disponibilità ridondante se lo SLA di BigQuery del 99,99% non è considerato sufficiente.

Per evitare la perdita di dati in caso di perdita regionale distruttiva, devi eseguire 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.

Nel caso delle multi-regioni BigQuery, devi evitare di eseguire il backup nelle regioni che rientrano nell'ambito della multi-regione. Per informazioni sull'ambito delle multi-regioni, vedi Località BigQuery. Ad esempio, se esegui il backup dei dati dalla multi-regione degli Stati Uniti, devi evitare di scegliere una delle regioni sovrapposte, ad esempio us-central1, data la possibilità di guasti correlati durante un disastro.

Per evitare un'indisponibilità prolungata, devi replicare i dati e provisionare gli slot in due località BigQuery separate geograficamente. Puoi utilizzare il recupero di emergenza gestito per eseguire il provisioning automatico degli slot in una regione secondaria e controllare il failover dei tuoi carichi di lavoro da una regione all'altra.

Scenario: eliminazione accidentale o danneggiamento dei dati

Grazie all'architettura di controllo della concorrenza multiversione di BigQuery, BigQuery supporta lo spostamento cronologico. Con questa funzionalità puoi eseguire query sui dati di qualsiasi momento degli ultimi sette giorni. Ciò consente il ripristino self-service di tutti i dati che sono stati eliminati, modificati o danneggiati per errore entro un periodo di 7 giorni. Il time travel funziona anche sulle tabelle eliminate.

BigQuery supporta anche la possibilità di creare snapshot delle tabelle. Con questa funzionalità puoi eseguire il backup esplicito dei dati all'interno della stessa regione per un periodo di tempo più lungo rispetto alla finestra di spostamento temporale di 7 giorni. Uno snapshot è puramente un'operazione sui metadati e non comporta byte di archiviazione aggiuntivi. Sebbene ciò possa aggiungere protezione contro l'eliminazione accidentale, non aumenta la durabilità dei dati.

Caso d'uso: analisi in tempo reale

In questo caso d'uso, i dati di streaming vengono importati continuamente dai log degli endpoint in BigQuery. La protezione da un'indisponibilità prolungata di BigQuery per l'intera regione richiede la replica continua dei dati e il provisioning degli slot in un'altra regione. Poiché l'architettura è resiliente alla mancata disponibilità di BigQuery grazie all'utilizzo di Pub/Sub e Dataflow nel percorso di importazione, questo elevato livello di ridondanza probabilmente non vale il costo.

Supponendo che l'utente abbia configurato i dati BigQuery in us-east4 da esportare ogni notte utilizzando i job di estrazione in Cloud Storage nella classe di archiviazione Archive Storage in us-central1. In questo modo, viene fornito un backup duraturo in caso di perdita catastrofica di dati in us-east4. In questo caso, il Recovery Point Objective (RPO) è di 24 ore, in quanto il backup esportato più recente può avere fino a 24 ore nel caso peggiore. Il Recovery Time Objective (RTO) è potenzialmente di giorni, poiché i dati devono essere ripristinati dal backup di Cloud Storage a BigQuery in us-central1. Se BigQuery deve essere provisionato in una regione diversa da quella in cui vengono inseriti i backup, i dati devono essere trasferiti prima in questa regione. Tieni inoltre presente che, a meno che tu non abbia acquistato slot ridondanti nella regione di ripristino in anticipo, potrebbe verificarsi un ulteriore ritardo nell'approvvigionamento della capacità BigQuery richiesta a seconda della quantità richiesta.

Caso d'uso: elaborazione dei dati in batch

Per questo caso d'uso è fondamentale che un report giornaliero venga completato entro una scadenza fissa per essere inviato a un ente regolatore. L'implementazione della ridondanza eseguendo due istanze separate dell'intera pipeline di elaborazione probabilmente vale il costo. L'utilizzo di due regioni separate, ad esempio us-west1 e us-east4, offre una separazione geografica e due domini di errore indipendenti in caso di mancata disponibilità prolungata di una regione o anche l'improbabile evento di perdita permanente di una regione.

Supponendo che il report debba essere inviato esattamente una volta, dobbiamo riconciliare il caso previsto in cui entrambe le pipeline vengono completate correttamente. Una strategia ragionevole è semplicemente scegliere il risultato della pipeline che termina per prima, ad esempio inviando una notifica a un argomento Pub/Sub al termine dell'operazione. In alternativa, sovrascrivi il risultato e ripristina la versione precedente dell'oggetto Cloud Storage. Se la pipeline che termina in un secondo momento scrive dati danneggiati, puoi eseguire il ripristino ripristinando la versione scritta dalla pipeline che termina per prima da Cloud Storage.

Gestione degli errori

Di seguito sono riportate le best practice per risolvere gli errori che influiscono sull'affidabilità.

Riprovare le richieste API non riuscite

I client di BigQuery, incluse le librerie client e gli strumenti partner, devono utilizzare il backoff esponenziale troncato quando inviano richieste API. Ciò significa che se un client riceve un errore di sistema o un errore di quota, deve riprovare a inviare la richiesta un certo numero di volte, ma con un intervallo di backoff casuale e crescente.

L'utilizzo di questo metodo di nuovi tentativi rende l'applicazione molto più solida in caso di errori. Anche in condizioni operative normali, puoi prevedere che circa una richiesta su diecimila non vada a buon fine, come descritto nell'SLA con disponibilità del 99,99% di BigQuery. In condizioni anomale, questo tasso di errore può aumentare, ma se gli errori sono distribuiti in modo casuale, la strategia di backoff esponenziale può mitigare tutti i casi tranne quelli più gravi.

Se riscontri uno scenario in cui una richiesta non va a buon fine in modo persistente con un errore 5XX, devi riassegnare il problema all' Google Cloud assistenza. Assicurati di comunicare chiaramente l'impatto che l'errore sta avendo sulla tua attività in modo che il problema possa essere valutato correttamente. Se, d'altra parte, una richiesta ha esito negativo in modo persistente con un errore 4XX, il problema può essere risolto apportando modifiche all'applicazione. Per maggiori dettagli, leggi il messaggio di errore.

Esempio di logica di backoff esponenziale

La logica di backoff esponenziale ritenta una query o una richiesta aumentando il tempo di attesa tra i tentativi fino a un tempo di backoff massimo. Ad esempio:

  1. Invia una richiesta a BigQuery.

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

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

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

  5. E così via, fino a un massimo di (maximum_backoff) volte.

  6. Continua ad attendere e riprovare fino a un numero massimo di tentativi, ma non aumentare il periodo di attesa tra i tentativi.

Tieni presente quanto segue:

  • 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 sono sincronizzati e tutti riprovano contemporaneamente, inviando richieste in onde sincronizzate. Il valore di random_number_milliseconds viene ricalcolato dopo ogni richiesta di riprova.

  • L'intervallo di backoff massimo (maximum_backoff) è in genere di 32 o 64 secondi. Il valore appropriato per maximum_backoff dipende dal 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. A un certo punto, è necessario impedire ai client di effettuare ulteriori tentativi indefinitamente.

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

Riprova gli inserimenti di job non riusciti

Se la semantica di inserimento esattamente una volta è importante per la tua applicazione, ci sono ulteriori considerazioni da fare quando si tratta di inserire job. Il modo in cui ottenere la semantica di al massimo una volta dipende dalla WriteDisposition che specifichi. La disposizione di scrittura indica a BigQuery cosa deve fare quando rileva dati esistenti in una tabella: non riuscire, sovrascrivere o aggiungere.

Con una disposizione WRITE_EMPTY o WRITE_TRUNCATE, questo risultato si ottiene semplicemente riprovando l'inserimento o l'esecuzione di qualsiasi job non riuscito. Questo perché tutte le righe inserite da un job vengono scritte in modo atomico nella tabella.

Con una disposizione WRITE_APPEND, il client deve specificare l'ID job per evitare che un nuovo tentativo aggiunga gli stessi dati una seconda volta. Questo funziona perché BigQuery rifiuta le richieste di creazione di job che tentano di utilizzare un ID di un job precedente. In questo modo si ottiene la semantica di esecuzione al massimo una volta per qualsiasi ID lavoro. Puoi quindi ottenere l'elaborazione esatta una sola volta riprovando con un nuovo ID job prevedibile dopo aver confermato con BigQuery che tutti i tentativi precedenti non sono andati a buon fine.

In alcuni casi, il client API o HTTP potrebbe non ricevere la conferma dell'inserimento del job a causa di problemi temporanei o interruzioni di rete. Quando viene eseguito un nuovo tentativo di inserimento, la richiesta non va a buon fine e viene restituito l'errore status=ALREADY_EXISTS (code=409 e reason="duplicate"). Lo stato del job esistente può essere recuperato con una chiamata a jobs.get. Dopo che lo stato del job esistente è retrieved, il chiamante può determinare se deve essere creato un nuovo job con un nuovo ID JOB.

Casi d'uso e requisiti di affidabilità

BigQuery potrebbe essere un componente fondamentale di varie architetture. A seconda del caso d'uso e dell'architettura di cui è stato eseguito il deployment, potrebbe essere necessario soddisfare una serie di requisiti di disponibilità, prestazioni o affidabilità. Ai fini di questa guida, selezioniamo due casi d'uso e architetture principali da analizzare in dettaglio.

Analisi in tempo reale

Il primo esempio è una pipeline di elaborazione dei dati sugli eventi. In questo esempio, gli eventi di log degli endpoint vengono importati utilizzando Pub/Sub. Da qui, una pipeline Dataflow di streaming esegue alcune operazioni sui dati prima di scriverli in BigQuery utilizzando l'API Storage Write. I dati vengono poi utilizzati sia per le query ad hoc per, ad esempio, ricreare sequenze di eventi che potrebbero aver generato risultati specifici degli endpoint, sia per alimentare dashboard quasi in tempo reale per consentire il rilevamento di tendenze e pattern nei dati tramite la visualizzazione.

Questo esempio richiede di considerare più aspetti dell'affidabilità. Poiché i requisiti di aggiornamento dei dati end-to-end sono piuttosto elevati, la latenza del processo di importazione è fondamentale. Una volta scritti i dati in BigQuery, l'affidabilità è percepita come la capacità degli utenti di eseguire query ad hoc con latenza coerente e prevedibile e di garantire che i dashboard che utilizzano i dati riflettano le informazioni più recenti disponibili.

Elaborazione dei dati in batch

Il secondo esempio è un'architettura di elaborazione batch basata sulla conformità normativa nel settore dei servizi finanziari. Un requisito fondamentale è quello di fornire report giornalieri agli enti regolatori entro una scadenza notturna fissa. Se il processo batch notturno che genera i report viene completato entro questa scadenza, viene considerato sufficientemente veloce.

I dati devono essere resi disponibili in BigQuery e uniti ad altre origini dati per la creazione di dashboard, l'analisi e, infine, la generazione di un report in formato PDF. La ricezione puntuale e senza errori di questi report è un requisito aziendale fondamentale. Pertanto, è fondamentale garantire l'affidabilità sia dell'importazione dati sia della produzione del report in modo corretto e in un periodo di tempo coerente per rispettare le scadenze richieste.