Informazioni sull'affidabilità

Questo documento illustra le funzionalità di affidabilità di BigQuery, come disponibilità, durabilità, coerenza dei dati, coerenza delle prestazioni, recupero dei dati e una revisione delle considerazioni relative alla gestione degli errori.

Questa introduzione ti aiuta a prendere in considerazione tre aspetti principali:

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

Seleziona BigQuery

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

In genere, BigQuery è molto adatto per i carichi di lavoro in cui vengono importate e analizzate grandi quantità di dati. Nello specifico, può essere impiegato efficacemente per casi d'uso come l'analisi predittiva e in tempo reale dei dati (con l'importazione in streaming 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), ti consigliamo di prendere in considerazione altri servizi Google Cloud 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 di scrivere dati al suo interno. BigQuery è progettato per rendere entrambi ad alta disponibilità 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. Consulta la sezione Informazioni sugli slot per saperne di più sull'unità di calcolo di base di BigQuery e sulla conseguente ottimizzazione delle risorse degli slot.

Durabilità

La durabilità è descritta nel capitolo sull'implementazione degli SLO del foglio di lavoro SRE ed è definita come la "proporzione di dati che può essere letta correttamente".

Coerenza dei dati

La coerenza definisce le aspettative degli utenti in merito al modo in cui è possibile eseguire query sui dati dopo che sono stati scritti o modificati. Un aspetto della coerenza dei dati è garantire la semantica "esattamente una volta" per l'importazione dati. Per saperne di più, consulta Riprovare le inserzioni di job non riuscite.

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. La tasso di throughput è una misura della quantità di dati che BigQuery può elaborare durante un determinato periodo di tempo. Grazie al design multi-tenant e scalabile orizzontalmente di BigQuery, il throughput può essere scalato 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:

  • RTO (Recovery Time Objective). Il periodo di tempo per cui i dati possono non essere disponibili dopo un incidente.
  • Recovery Point Objective (RPO). La quantità di dati raccolti prima dell'incidente che può essere accettabilmente persa.

Queste considerazioni sono particolarmente pertinenti nell'improbabile caso in cui una zona o una regione subisca un'interruzione di servizio distruttiva o prolungata.

Pianificazione in caso di emergenza

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

BigQuery offre un 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 prevede una capacità di calcolo ridondante. È importante tenere presente che l'accordo sul livello del servizio di BigQuery è lo stesso per le regioni, ad esempio us-central1, e per le regioni con più regioni, ad esempio gli Stati Uniti.

Gestione automatica degli scenari

Poiché BigQuery è un servizio regionale, è compito di BigQuery gestire automaticamente la perdita di un computer o addirittura di un'intera zona. Il fatto che BigQuery sia basato su zone è astratto dagli utenti.

Perdita di una macchina

Gli arresti anomali delle macchine sono all'ordine del giorno alle dimensioni su cui opera Google. BigQuery è progettato per gestire automaticamente gli errori delle macchine senza alcun impatto sulla zona contenente.
Dietro le quinte, l'esecuzione di una query è suddivisa in piccole attività che possono essere inviate in parallelo a molte macchine. La perdita o il degrado improvviso del rendimento della macchina viene gestito automaticamente riassegnando il lavoro a un'altra macchina. Questo approccio è fondamentale per ridurre la latenza in coda.

BigQuery utilizza la codifica Reed-Solomon per archiviare in modo efficiente e duraturo una copia zonale dei dati. Nell'improbabile caso in cui più guasti del computer causino la perdita di una copia zonale, i dati vengono archiviati nello stesso modo anche in almeno un'altra zona. In questo caso, BigQuery rileverà il problema e creerà 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 tempo di attività del 99,99% di BigQuery. Di conseguenza, BigQuery fornisce ridondanza zonale automatica sia per gli slot di dati sia per quelli di calcolo. Anche se le interruzioni zonali di breve durata non sono comuni, possono verificarsi. L'automazione di BigQuery, tuttavia, eseguirà il failover delle query su un'altra zona entro un paio di minuti da qualsiasi interruzione grave. Le query già inviate potrebbero non essere recuperate immediatamente, ma quelle appena emesse sì. Ciò si manifesterebbe con un tempo di elaborazione lungo delle query in corso, mentre le query appena emesse si completerebbero rapidamente.

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

Tipi di errori

Esistono due tipi di errori: errori soft ed errori hard.

Un errore soft è un malfunzionamento operativo in cui l'hardware non viene distrutto. Alcuni esempi sono interruzione dell'alimentazione, partizione di rete o arresto anomalo del computer. In genere, BigQuery non dovrebbe mai perdere dati in caso di errore soft.

Un guasto hardware è un malfunzionamento in cui l'hardware viene distrutto. I fallimenti gravi sono più gravi di quelli soft. Alcuni esempi di guasti gravi sono i danni causati da inondazioni, attacchi terroristici, terremoti e uragani.

Disponibilità e durabilità

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

  • Una regione: una posizione geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
  • Più regioni: una vasta 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 le copie dei dati in due diverse zone Google Cloud all'interno di un'unica regione nella località selezionata.

Oltre alla ridondanza dello spazio di archiviazione, BigQuery mantiene anche la capacità di calcolo ridondante in più zone. Combinando spazio di archiviazione e 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 eseguire con un ritardo massimo di alcuni millisecondi. L'elaborazione di tutte le query attualmente in esecuzione continuerà. In caso di guasto zonale temporaneo o permanente, non è prevista alcuna perdita di dati. Tuttavia, le query in esecuzione potrebbero non riuscire e dover essere inviate di nuovo. Un guasto zonale blando, ad esempio derivante da un'interruzione di corrente, da un trasformatore distrutto o da una partizione di rete, è un percorso ben testato e viene mitigato automaticamente entro pochi minuti.

Un errore regionale blando, ad esempio una perdita di connettività di rete a livello di regione, comporta una perdita di disponibilità fino a quando la regione non viene ripristinata online, ma non comporta la perdita di dati. Un errore grave a livello di regione, 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 creare copie di set di dati tra regioni per migliorare la tua strategia di ripristino di emergenza.

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 della perdita di una regione fisica. Questo vale sia per le configurazioni "regioni e multiregione". Di conseguenza, mantenere la durabilità e la disponibilità in questo tipo di scenario richiede la pianificazione del cliente. In caso di perdita temporanea, ad esempio un'interruzione della rete, è necessario prendere in considerazione la disponibilità ridondante se lo SLA del 99,99% di BigQuery non è considerato sufficiente.

Per evitare la perdita di dati in caso di perdita regionale distruttiva, devi eseguire il backup degli stessi in un'altra posizione geografica. Ad esempio, potresti esportare periodicamente un'istantanea dei tuoi dati in Google Cloud Storage in un'altra regione geograficamente distinta. Questo può essere fatto come descritto nel caso d'uso di elaborazione batch dei dati.
Nel caso di più regioni BigQuery, devi evitare di eseguire il backup nelle regioni che rientrano nell'ambito della regione multipla. Ad esempio, non eseguire il backup degli tuoi dati negli Stati Uniti nella regione us-central1. La regione e la località a più regioni possono condividere domini in errore e avere lo stesso destino in caso di emergenza. Esegui invece il backup dei dati in una regione non statunitense, ad esempio northamerica-northeast1. Se i requisiti di residenza dei dati richiedono che i backup vengano archiviati negli Stati Uniti, ti consigliamo di accoppiare due regioni come us-central1 e us-east1.

Per evitare un'indisponibilità prolungata, devi avere sia i dati replicati sia gli slot di cui è stato eseguito il provisioning in due località BigQuery geograficamente separate. Come sopra, evita di combinare regioni e località con più regioni, in quanto potrebbero avere lo stesso destino in caso di disastro.

L'architettura più affidabile per una configurazione ridondante a livello di regione è l'esecuzione di hot-hot, chiamata anche active-active. Ciò significa che il carico di lavoro viene eseguito in parallelo sia nella regione principale che in quella secondaria. Sebbene più costoso, questo metodo garantisce che la regione secondaria venga sottoposta a verifica continua e funzioni se è necessario eseguire il failover. Se la disponibilità durante un'interruzione a livello di regione non è un problema, il backup dei dati in un'altra regione garantisce la durabilità.

Scenario: eliminazione accidentale o danneggiamento dei dati

In virtù dell'architettura di controllo della concorrenza multiversione di BigQuery, BigQuery supporta lo spostamento cronologico. Con questa funzionalità puoi eseguire query sui dati di qualsiasi momento negli ultimi sette giorni. In questo modo è possibile eseguire il ripristino self-service di qualsiasi dato eliminato, modificato o danneggiato per errore entro un periodo di 7 giorni. Il viaggio nel tempo funziona anche sulle tabelle che sono state eliminate.

BigQuery supporta anche la possibilità di eseguire snapshot delle tabelle. Con questa funzionalità puoi eseguire il backup esplicito dei dati all'interno della stessa regione per un periodo di tempo superiore a quello della finestra di viaggio nel tempo di 7 giorni. Uno snapshot è un'operazione puramente di metadati e non comporta l'utilizzo di byte di spazio di archiviazione aggiuntivi. Sebbene questa operazione possa offrire una 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 in streaming vengono importati continuamente da BigQuery ai log degli endpoint. Per proteggerti da un periodo prolungato di mancata disponibilità di BigQuery per l'intera regione, devi replicare continuamente i dati e eseguire il provisioning degli slot in un'altra regione. Poiché l'architettura è resiliente all'indisponibilità di BigQuery grazie all'utilizzo di Pub/Sub e Dataflow nel percorso di importazione, questo elevato livello di ridondanza probabilmente non vale il costo.

Supponiamo che l'utente abbia configurato l'esportazione giornaliera dei dati BigQuery in us-east4 utilizzando i job di esportazione in Cloud Storage per la classe di Archive Storage 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, poiché l'ultimo backup esportato può risalire fino a 24 ore nel peggiore dei casi. L'obiettivo di tempo di recupero (RTO) può essere di diversi 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 si trovano i backup, i dati devono prima essere trasferiti in questa regione. Tieni inoltre presente che, a meno che tu non abbia acquistato in anticipo gli slot ridondanti nella regione di recupero, potrebbe verificarsi un ulteriore ritardo nel provisioning della capacità BigQuery richiesta, a seconda della quantità richiesta.

Caso d'uso: elaborazione dei dati in batch

Per questo caso d'uso è fondamentale per l'attività completare un report giornaliero entro una scadenza fissa per inviarlo a un ente regolatore. L'implementazione della ridondanza mediante l'esecuzione di due istanze separate dell'intera pipeline di elaborazione probabilmente vale il costo. L'utilizzo di due regioni distinte, 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 nell'improbabile evento di una perdita permanente della regione.

Supponendo che il report debba essere inviato esattamente una volta, dobbiamo riconciliare la situazione prevista in cui entrambe le pipeline terminano correttamente. Una strategia ragionevole è semplicemente scegliere il risultato della pipeline che termina per primo, ad esempio inviando una notifica a un argomento Pub/Sub al termine dell'operazione. In alternativa, sovrascrive il risultato e esegui nuovamente la versione dell'oggetto Cloud Storage. Se la pipeline termina in un secondo momento scrivendo dati corrotti, puoi recuperare 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 dei 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 fino a un determinato numero di volte, ma con un intervallo di backoff casuale e crescente.

L'utilizzo di questo metodo di ripetizione rende l'applicazione molto più solida in caso di errori. Anche in condizioni di funzionamento 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 i più gravi.

Se riscontri uno scenario in cui una richiesta non va a buon fine in modo persistente con un errore 5XX, devi riassegnarla all'assistenza Google Cloud. Assicurati di comunicare chiaramente l'impatto del malfunzionamento sulla tua attività in modo che il problema possa essere valutato correttamente. Se, invece, una richiesta non va a buon fine in modo persistente con un errore 4XX, il problema dovrebbe essere risolvibile apportando modifiche all'applicazione. Per maggiori dettagli, leggi 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 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.

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

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

  5. E così via fino a un intervallo di (maximum_backoff).

  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 minore o uguale a 1000. Questa randomizzazione consente di evitare situazioni in cui molti client sono sincronizzati e tutti riprovano contemporaneamente, inviando richieste in ondate sincronizzate. Il valore di random_number_milliseconds viene ricalcolato 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 caso d'uso.

Il client può continuare a riprovare dopo aver raggiunto il tempo di backoff massimo. I tentativi successivi a 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, ai client deve essere impedito di riprovare a tempo indeterminato.

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 le inserzioni di job non riuscite

Se la semantica di inserimento esattamente una volta è importante per la tua applicazione, esistono considerazioni aggiuntive per quanto riguarda l'inserimento dei job. La modalità di ottenimento della semantica almeno una volta dipende da quale WriteDisposition specifichi. L'impostazione di destinazione della scrittura indica a BigQuery cosa deve fare quando rileva dati esistenti in una tabella: non riuscire, sovrascrivere o accodare.

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

Con una disposizione WRITE_APPEND, il cliente deve specificare l'ID job per difendersi da un nuovo tentativo di accodamento degli 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 viene raggiunta la semantica al massimo una volta per qualsiasi ID job. Puoi quindi ottenere l'esecuzione esattamente una volta riprovando con un nuovo ID job prevedibile dopo aver verificato con BigQuery che tutti i tentativi precedenti non sono riusciti.

In alcuni casi, il client API o il client HTTP potrebbe non ricevere la conferma dell'inserimento del job a causa di problemi temporanei o interruzioni della rete. Quando si tenta di nuovo l'inserimento, la richiesta non va a buon fine con status=ALREADY_EXISTS (code=409 e reason="duplicate"). Lo stato del job esistente può essere recuperato con una chiamata a jobs.get. Quando 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 una serie di 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 altra affidabilità. Ai fini di questa guida, selezioniamo due casi d'uso e due architetture principali da esaminare in dettaglio.

Analisi in tempo reale

Il primo esempio è una pipeline di elaborazione dei dati sugli eventi. In questo esempio, gli eventi dei log provenienti dagli endpoint vengono importati utilizzando Pub/Sub. Da qui, una pipeline Dataflow in streaming esegue alcune operazioni sui dati prima di scriverli in BigQuery utilizzando l'API Storage Write. I dati vengono poi utilizzati sia per eseguire query ad hoc, ad esempio per ricreare sequenze di eventi che potrebbero aver generato risultati specifici per gli endpoint, sia per alimentare dashboard quasi in tempo reale al fine di rilevare tendenze e schemi 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 procedura di importazione è fondamentale. Una volta scritti i dati in BigQuery, la affidabilità è percepita come la capacità degli utenti di emettere query ad hoc con una latenza coerente e prevedibile e di garantire che le 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 è inviare report giornalieri alle autorità di regolamentazione entro una scadenza notturna fissa. Se la procedura batch notturna che genera i report viene completata entro questa scadenza, è considerata sufficientemente rapida.

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