Informazioni sull'affidabilità

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

Questa introduzione ti aiuta ad affrontare tre considerazioni principali:

  • Determina se BigQuery è lo strumento giusto per il tuo job.
  • Comprendere le dimensioni dell'affidabilità di BigQuery.
  • Identificare i 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 da megabyte a petabyte di dati con prestazioni coerenti senza dover gestire nessuna infrastruttura sottostante. Grazie alla sua potenza e alle sue prestazioni, BigQuery è adatto per essere utilizzato in una vasta gamma di soluzioni. Alcuni di questi sono documentati in dettaglio come pattern di riferimento.

In generale, BigQuery è ideale per 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 le applicazioni in stile Online Transaction Processing (OLTP), dovresti 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 o scrivere dati da BigQuery BigQuery è progettato per rendere entrambe queste funzionalità ad alta disponibilità con uno SLA del 99,99%. Entrambe le operazioni hanno due componenti:

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

L'affidabilità del servizio è una funzione della specifica API BigQuery 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 Informazioni sugli slot per ulteriori informazioni sull'unità fondamentale di computing per BigQuery e sulla conseguente economia delle risorse degli slot.

Durabilità

La durabilità è discussa 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 al modo in cui è possibile eseguire query sui dati dopo essere stati scritti o modificati. Un aspetto della coerenza dei dati è garantire la semantica "exactly-once" per l'importazione dati. Per maggiori informazioni, consulta "Affidabilità della soluzione" in Casi d'uso di esempio per il caricamento dei dati e Ripetere gli inserimenti di job non riusciti.

Coerenza del rendimento

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

Recupero dati

Due modi per misurare la capacità di recuperare i dati dopo un'interruzione sono:

  • RTO (Recovery Time Objective). Per quanto tempo i dati possono non essere disponibili dopo un incidente.
  • RPO (Recovery Point Objective). La quantità di dati raccolti prima dell'incidente può andare persa in modo accettabile.

Queste considerazioni sono particolarmente rilevanti nel caso improbabile che una zona o una regione subiscano un'interruzione di più giorni o distruttiva.

Pianificazione in caso di emergenza

Sebbene il termine "calamità" possa richiamare visione di disastri naturali, l'ambito di questa sezione risolve gli errori specifici derivanti dalla perdita di una singola macchina fino alla perdita catastrofica di una regione. Le prime sono occorrenze quotidiane che BigQuery gestisce automaticamente, mentre la seconda è qualcosa che i clienti potrebbero avere bisogno di progettare la propria architettura da gestire se necessario. Capire a quale ambito la pianificazione in caso di emergenza si estende alla responsabilità del cliente è importante.

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 ed esegue il provisioning di capacità di calcolo ridondante. È importante tenere presente che lo SLA di BigQuery è lo stesso per le regioni, ad esempio us-central1, e multiregionali, come gli Stati Uniti.

Gestione automatica dello scenario

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

Perdita di una macchina

Gli errori dei computer si verificano tutti i giorni nella scala in cui opera Google. BigQuery è progettato per gestire automaticamente gli errori delle macchine senza alcun impatto sulla zona che la contiene.
Di base, l'esecuzione di una query è suddivisa in piccole attività che possono essere inviate in parallelo a molte macchine. La perdita o il peggioramento improvviso delle prestazioni delle macchine vengono gestiti in modo automatico inviando il lavoro a un'altra macchina. Questo approccio è fondamentale per ridurre la latenza di coda.

BigQuery utilizza la codifica Reed-Solomon per archiviare una copia dei dati a livello di zona in modo efficiente e duraturo. Nell'improbabile eventualità che più errori delle macchine causino la perdita di una copia a livello di zona, anche i dati vengono archiviati allo stesso modo in almeno un'altra zona. In questo caso, BigQuery rileverà il problema e creerà una nuova copia dei dati a livello di zona per ripristinare la ridondanza.

Perdita di una zona

La disponibilità di base delle risorse di computing in una determinata zona non è sufficiente per soddisfare lo SLA (accordo sul livello del servizio) con uptime del 99,99% di BigQuery. Pertanto, BigQuery offre ridondanza automatica a livello di zona per slot di dati e di computing. Sebbene le interruzioni di zona di breve durata non siano comuni, si verificano. L'automazione BigQuery, tuttavia, eseguirà il failover delle query in un'altra zona entro uno o due minuti. Le query già in corso potrebbero non recuperarsi immediatamente, a differenza delle nuove query. Ciò si manifesta in quanto il completamento delle query in corso richiede molto tempo mentre le nuove query vengono completate rapidamente.

Anche se una zona dovesse rimanere non disponibile per un periodo di tempo più lungo, non si verificherebbe alcuna perdita di dati a causa del fatto che BigQuery scrive in modo sincrono i dati in due zone. Quindi, anche di fronte a una perdita a livello locale, i clienti non subiranno interruzioni del servizio.

Tipi di errori

Esistono due tipi di errori: errori temporanei e errori rigidi.

L'errore soft è un deficit operativo in cui l'hardware non viene distrutto. Alcuni esempi sono un'interruzione dell'alimentazione, una partizione di rete o un arresto anomalo della macchina. In generale, BigQuery non dovrebbe mai perdere dati in caso di errore soft.

Un errore hardware è un difetto operativo che comporta la distruzione dell'hardware. Gli errori rigidi sono più gravi di quelli flessibili. Alcuni esempi di guasti evidenti sono i 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 località è una delle seguenti:

  • Una regione: una località geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
  • Più regioni: una grande area geografica contenente due o più luoghi geografici, come gli Stati Uniti (US) o l'Europa (EU).

In entrambi i casi, BigQuery archivia automaticamente copie dei tuoi dati in due diverse zone di Google Cloud all'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 archiviazione e computing ridondanti in più zone di disponibilità, BigQuery offre alta disponibilità e durabilità.

In caso di errore a livello di macchina, BigQuery continua a essere eseguito con un ritardo massimo di alcuni millisecondi. Tutte le query attualmente in esecuzione continuano a essere elaborate. In caso di errore di zona (soft o hard) non è prevista alcuna perdita di dati. Tuttavia, le query attualmente in esecuzione potrebbero non riuscire e dovranno essere inviate nuovamente. Un errore a livello di zona, ad esempio derivante da un'interruzione di corrente, da un'interruzione del trasformatore o da una partizione di rete, è un percorso ben collaudato e mitigato automaticamente in pochi minuti.

Un errore soft a livello di regione, ad esempio una perdita della connettività di rete a livello di regione, comporta la perdita della disponibilità fino a quando la regione non viene riportata di nuovo online, ma non comporta la perdita di dati. Un errore a livello di regione rigida, ad esempio, se un'emergenza elimina l'intera regione, potrebbe causare 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 creare copie di set di dati tra regioni per migliorare la tua strategia di ripristino di emergenza.

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

Scenario: perdita di area geografica

BigQuery non offre durabilità o disponibilità nell'evento straordinariamente improbabile e senza precedenti di perdita di regioni fisiche. Questo vale sia per le configurazioni "regioni sia per più regioni". Il mantenimento di durabilità e disponibilità in uno scenario di questo tipo richiede quindi 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 (accordo sul livello del servizio) del 99,99% di BigQuery non è considerato sufficiente.

Per evitare perdite di dati a causa di perdite distruttive a livello di regione, devi eseguire il backup dei dati in un'altra posizione geografica. Ad esempio, potresti esportare periodicamente uno snapshot dei tuoi dati in Google Cloud Storage in un'altra regione geograficamente distinta. Questa operazione può essere eseguita come descritto nel Caso d'uso dell'elaborazione dei dati in batch.
Nel caso di BigQuery con più regioni, devi evitare di eseguire il backup in regioni che rientrano nell'ambito di più regioni. Ad esempio, non eseguire il backup dei dati negli Stati Uniti nella regione us-central1. La regione e la multiregione potrebbero condividere domini in errore e hanno condiviso il destino in caso di emergenza. Esegui invece il backup dei dati in un'area geografica non statunitense, ad esempio northamerica-northeast1. Se i requisiti di residenza dei dati richiedono l'archiviazione dei backup negli Stati Uniti, è meglio associare due regioni come us-central1 e us-east1.

Per evitare un'indisponibilità estesa, devi eseguire il provisioning dei dati e degli slot in due località BigQuery separate geograficamente. Come sopra, evita di mescolare regioni e regioni multiple, perché potrebbero aver condiviso il destino in un disastro.

L'architettura più affidabile per una configurazione ridondante per regione è l'esecuzione hot-hot, chiamato anche attivo-attivo. Ciò significa che il carico di lavoro viene eseguito in parallelo sia nella regione principale che in quella secondaria. Anche se più costoso, assicura che la regione secondaria riceva una verifica continua e funzionerà 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: cancellazione accidentale o danneggiamento dei dati

Grazie all'architettura di controllo della contemporaneità multiversione di BigQuery, BigQuery supporta i viaggi nel tempo. Con questa funzionalità puoi eseguire query sui dati da qualsiasi momento negli ultimi sette giorni. Ciò consente il ripristino self-service di tutti i dati che sono stati eliminati, modificati o danneggiati per errore in un periodo di 7 giorni. Lo spostamento cronologico funziona anche sulle tabelle eliminate.

BigQuery supporta anche la possibilità di eseguire snapshot delle tabelle. Con questa funzionalità puoi eseguire il backup dei dati all'interno della stessa regione per un periodo superiore alla finestra di spostamento temporale di 7 giorni. Uno snapshot è solo un'operazione sui metadati e non genera byte di archiviazione aggiuntivi. Anche se questo può migliorare la protezione da cancellazione accidentale, non aumenta la durabilità dei dati.

Caso d'uso: analisi in tempo reale

In questo caso d'uso, i flussi di dati vengono importati continuamente dai log degli endpoint in BigQuery. Per proteggersi dall'indisponibilità estesa di BigQuery per l'intera regione, è necessario replicare continuamente i dati e eseguire il provisioning degli slot in un'altra regione. Dato che l'architettura è resiliente all'indisponibilità di BigQuery dovuta all'uso di Pub/Sub e Dataflow nel percorso di importazione, è probabile che questo alto livello di ridondanza non vale il costo.

Supponendo che l'utente abbia configurato i dati BigQuery in us-east4 per l'esportazione di notte utilizzando i job di esportazione in Cloud Storage nella classe Archive Storage in us-central1. Questo fornisce un backup durevole in caso di perdita di dati catastrofica in us-east4. In questo caso, il Recovery Point Objective (RPO) è di 24 ore, poiché nel peggiore dei casi l'ultimo backup esportato può risalire fino a 24 ore prima. Il Recovery Time Objective (RTO) è potenzialmente in giorni, poiché i dati devono essere ripristinati dal backup di Cloud Storage a BigQuery in us-central1. Se devi eseguire il provisioning di BigQuery in una regione diversa da quella in cui vengono inseriti i backup, i dati devono essere prima trasferiti in questa regione. Tieni inoltre presente che, a meno che tu non abbia acquistato slot ridondanti nella regione di recupero in anticipo, 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à che un report giornaliero venga completato entro una scadenza fissa per l'invio a un ente regolatore. È probabile che l'implementazione della ridondanza eseguendo due istanze separate dell'intera pipeline di elaborazione ne valga il costo. L'utilizzo di due regioni distinte, ad esempio us-west1 e us-east4, offre una separazione geografica e due domini in errore indipendenti in caso di indisponibilità estesa di una regione o persino nell'improbabile caso di perdita permanente di una regione.

Supponendo di aver bisogno che il report venga consegnato esattamente una volta, dobbiamo riconciliare il caso previsto di entrambe le pipeline. Una strategia ragionevole è semplicemente scegliere il risultato della pipeline che termina per primo, ad esempio inviando una notifica a un argomento Pub/Sub al completamento dell'operazione. In alternativa, sovrascrivi il risultato e rivedi la versione 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 terminando prima da Cloud Storage.

Gestione degli errori

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

Riprova le richieste API non riuscite

I client di BigQuery, inclusi gli strumenti dei partner e le librerie client, devono utilizzare il backoff esponenziale troncato durante l'emissione delle richieste API. Ciò significa che se un client riceve un errore di sistema o di quota, deve riprovare la richiesta fino a un determinato numero di volte, ma con un intervallo di backoff casuale e crescente.

L'impiego di questo metodo di nuovi tentativi rende la tua applicazione molto più solida a fronte di errori. Anche in condizioni operative normali, è normale che nell'ordine di una richiesta su diecimila richieste non vadano a buon fine, come descritto nello SLA di BigQuery con disponibilità del 99,99%. In condizioni anomale, questo tasso di errore può aumentare, ma se gli errori vengono distribuiti casualmente, la strategia di backoff esponenziale può mitigare tutti i casi tranne i più gravi.

Se si verifica uno scenario in cui una richiesta non riesce in modo permanente con un errore 5XX, devi riassegnare la richiesta all'assistenza Google Cloud. 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 non va a buon fine e restituisce un errore 4XX, il problema dovrebbe essere risolvibile apportando modifiche all'applicazione. Leggi il messaggio di errore per i dettagli.

Esempio di logica di backoff esponenziale

La logica di backoff esponenziale tenta di nuovo una query o una richiesta aumentando il tempo di attesa tra un nuovo tentativo e l'altro fino al tempo di backoff massimo. Ad esempio:

  1. Effettua 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 secondi + random_number_milliseconds secondi e riprova.

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

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

  6. Continua ad attendere e riprova fino al numero massimo di nuovi tentativi, ma non aumentare il periodo di attesa tra un nuovo tentativo e l'altro.

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 consente di evitare situazioni in cui molti client sono sincronizzati e tutti riprovano contemporaneamente, inviando richieste in ondate sincronizzate. Il valore 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 una volta raggiunto il tempo di backoff massimo. Non è necessario continuare ad aumentare il tempo di backoff per i nuovi tentativi successivi a questo punto. Ad esempio, se il client utilizza un tempo di backoff massimo di 64 secondi, dopo aver raggiunto questo valore potrà continuare a riprovare ogni 64 secondi. A un certo punto, ai client dovrebbe 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 di rete.

Riprova gli inserimenti di job non riusciti

Se la semantica dell'inserimento "exactly-once" è importante per la tua applicazione, ci sono considerazioni aggiuntive quando si tratta di inserire i job. Il modo per ottenere al massimo una volta che la semantica dipende dal WriteDisposition specificato. L'istruzione di scrittura indica a BigQuery cosa deve fare quando si incontrano dati esistenti in una tabella: errore, sovrascrittura o aggiunta.

Con un'istruzione WRITE_EMPTY o WRITE_TRUNCATE, questo si ottiene semplicemente riprovando a eseguire un inserimento o un job non riuscito. Questo perché tutte le righe importate da un job vengono scritte atomicamente nella tabella.

Con un'istruzione WRITE_APPEND, il client deve specificare l'ID job per evitare un nuovo tentativo di aggiungere gli stessi dati una seconda volta. Questo funziona perché BigQuery rifiuta le richieste di creazione dei job che tentano di utilizzare un ID di un job precedente. Questo ottiene la semantica "at-most-once" per ogni ID job. Puoi quindi farlo 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 di rete. Se si tenta di nuovo l'inserimento, la richiesta non va a buon fine e 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 è necessario creare un nuovo job con un nuovo ID JOB.

Casi d'uso e requisiti di affidabilità

BigQuery può essere un componente critico di varie architetture. A seconda del caso d'uso e dell'architettura di cui è stato eseguito il deployment, potrebbe essere necessario soddisfare una varietà di disponibilità, prestazioni o altri requisiti di affidabilità. Ai fini di questa guida, selezioniamo due casi d'uso e architetture principali di cui discutere 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 in modalità flusso esegue alcune operazioni sui dati prima di scriverli in BigQuery utilizzando l'API StorageWrite. I dati vengono quindi utilizzati sia per le query ad hoc, ad esempio per ricreare sequenze di eventi che potrebbero aver portato a risultati specifici dell'endpoint, sia per alimentare dashboard quasi in tempo reale per consentire il rilevamento di tendenze e pattern dei dati attraverso la visualizzazione.

Questo esempio richiede di considerare diversi 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à viene percepita come la capacità degli utenti di eseguire query ad hoc con una latenza coerente e prevedibile e la garanzia che le dashboard che utilizzano i dati riflettano le informazioni disponibili e più recenti assolute.

Elaborazione dei dati in batch

Il secondo esempio è un'architettura di elaborazione batch basata sulla conformità alle normative nel settore dei servizi finanziari. Un requisito fondamentale è 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, è 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. Fare in modo che questi report vengano pubblicati puntualmente e senza errori è un requisito aziendale fondamentale. Di conseguenza, è fondamentale garantire l'affidabilità dell'importazione dati e della produzione dei report in modo corretto e in un periodo di tempo coerente per rispettare le scadenze richieste.

Passaggi successivi