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 riepilogo delle considerazioni sulla gestione degli errori.

Questa introduzione ti aiuta a tenere conto di tre considerazioni principali:

  • Scopri se BigQuery è lo strumento giusto per il tuo job.
  • Comprendere 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, creato per archiviare e analizzare set di dati di grandi dimensioni. Offre un modo per importare, archiviare, leggere ed eseguire query da megabyte a petabyte di dati con prestazioni coerenti senza dover gestire alcuna infrastruttura sottostante. Grazie alla sua potenza e alle sue prestazioni, BigQuery è ideale per essere utilizzato in una vasta gamma di soluzioni. Alcuni di questi sono documentati in dettaglio come pattern di riferimento.

In genere, BigQuery è ideale per carichi di lavoro in cui vengono importate e analizzate grandi quantità di dati. In particolare, può essere efficace per il deployment di casi d'uso come l'analisi dei dati in tempo reale e predittiva (con importazione di flussi e BigQuery ML), il rilevamento di anomalie e altri casi d'uso in cui l'analisi di grandi volumi di dati con prestazioni prevedibili è fondamentale. Tuttavia, se stai cercando un database che supporti le applicazioni in stile OLTP (Online Transaction Processing), 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 di affidabilità in BigQuery

Disponibilità

La disponibilità definisce la capacità dell'utente di leggere i dati da BigQuery o di scrivere dati in BigQuery. BigQuery è progettato per rendere entrambi altamente disponibili con uno SLA del 99,99%. Le operazioni sono due:

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

L'affidabilità del servizio è una funzione dell'API BigQuery specifica utilizzata per recuperare i dati. La disponibilità delle risorse di computing dipende dalla capacità disponibile per l'utente al momento dell'esecuzione della query. Consulta Informazioni sugli slot per ulteriori informazioni sull'unità di calcolo fondamentale per BigQuery e sull'economia delle risorse di slot risultante.

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 sul 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 "Affidabilità della soluzione" in Esempi di casi d'uso durante il caricamento dei dati e Ripetere gli inserimento di job non riusciti.

Costanza del rendimento

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

Recupero dati

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

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

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

Pianificazione in caso di emergenza

Sebbene il termine "disastro" possa riferirsi a visioni di calamità naturali, l'ambito di questa sezione affronta errori specifici dalla perdita di una singola macchina fino alla perdita catastrofica di una regione. Le prime sono occorrenze quotidiane che BigQuery gestisce automaticamente, mentre le seconda è qualcosa che i clienti possono aver bisogno di progettare la propria architettura da gestire in caso di necessità. È importante capire in che ambito la pianificazione in caso di emergenza passa alla responsabilità del cliente.

BigQuery offre uno SLA (accordo sul livello del servizio) 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 esegue il provisioning di capacità di calcolo ridondante. È importante tenere presente che lo SLA (accordo sul livello del servizio) di BigQuery è lo stesso per le regioni, ad esempio us-central1, e per più regioni, ad esempio US.

Gestione automatica degli scenari

Poiché BigQuery è un servizio a livello di regione, è sua responsabilità gestire automaticamente la perdita di una macchina o anche di un'intera zona. Il fatto che BigQuery sia costruito su zone non viene preso in considerazione dagli utenti.

Perdita di una macchina

Gli errori delle macchine sono un evento quotidiano nella scala utilizzata da Google. BigQuery è progettato per gestire automaticamente gli errori delle macchine senza alcun impatto sulla zona contenitore.
In background, l'esecuzione di una query è suddivisa in piccole attività che possono essere inviate in parallelo su molte macchine. La perdita o il degrado improvviso delle prestazioni della macchina viene gestito automaticamente inviando il lavoro a un'altra macchina. Un approccio di questo tipo è 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 gli errori di più macchine causino la perdita di una copia a livello di zona, i dati vengono archiviati allo stesso modo in almeno un'altra zona. In questo caso, BigQuery rileverà il problema e creerà una nuova copia a livello di zona dei dati 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. BigQuery offre quindi la ridondanza automatica a livello di zona per gli slot di dati e di calcolo. Sebbene le interruzioni a livello di zona di breve durata non siano comuni, si verificano. Tuttavia, l'automazione BigQuery esegue il failover delle query in un'altra zona entro uno o due minuti da eventuali interruzioni gravi. Le query già in corso potrebbero non essere ripristinate immediatamente, ma lo saranno quelle appena inviate. Ciò si manifesterebbe come query in corso che richiedono molto tempo per essere completate mentre quelle appena inviate 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 i dati in modo sincrono in due zone. Quindi, anche di fronte a una perdita a livello di zona, i clienti non subiranno interruzioni del servizio.

Tipi di errori

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

Un guasto soft è un difetto operativo in cui l'hardware non viene distrutto. Alcuni esempi sono: interruzione di corrente, partizione di rete o arresto anomalo della macchina. In generale, BigQuery non dovrebbe mai perdere dati in caso di errore leggero.

Un guasto rigido è un difetto operativo in cui l'hardware viene distrutto. Gli errori gravi sono più gravi di quelli non obbligatori. Esempi di danni gravi includono inondazioni, attacchi terroristici, terremoti e uragani.

Disponibilità e durabilità

Quando crei un set di dati BigQuery, devi selezionare 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).
  • Più regioni: una vasta area geografica che contiene due o più luoghi geografici, ad esempio gli Stati Uniti (US) o l'Europa (EU).

In ogni caso, 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 su più zone. Combinando archiviazione ridondante e computing in più zone di disponibilità, BigQuery offre disponibilità elevata e durabilità.

In caso di errore a livello di macchina, BigQuery continua a essere eseguito con un ritardo non superiore a qualche secondo. Tutte le query attualmente in esecuzione continuano a essere elaborate. In caso di errore leggero o difficile a livello di zona, non è prevista alcuna perdita di dati. Tuttavia, le query attualmente in esecuzione potrebbero non riuscire e dovranno essere inviate nuovamente. Un errore soft a livello di zona, ad esempio a seguito di un'interruzione di corrente, di un trasformatore o di una partizione di rete, è un percorso ben testato e viene ridotto automaticamente in pochi minuti.

Un errore temporaneo di regione, ad esempio una perdita della 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 rigido a livello di regione, ad esempio, se un'emergenza 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 posizioni dei set di dati BigQuery, consulta Considerazioni sulla località.

Scenario: perdita di regione

BigQuery non offre durabilità o disponibilità in un evento estremamente improbabile e senza precedenti di perdita di regione fisica. Questo vale per le configurazioni "regioni e multiregionali". Per questo, mantenere durabilità e disponibilità in uno scenario di questo tipo richiede la pianificazione del cliente. In caso di perdita temporanea, come un'interruzione della rete, la disponibilità ridondante deve essere considerata 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 del trattamento dati in batch.
Nel caso di più regioni BigQuery, dovresti evitare di eseguire il backup in regioni che rientrano nell'ambito di questa multiregione. Ad esempio, non eseguire il backup dei dati negli Stati Uniti nella regione us-central1. Una o più regioni potrebbero condividere domini in errore e avere un destino condiviso in caso di emergenza. Esegui 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 all'interno degli Stati Uniti, è preferibile accoppiare due regioni come us-central1 e us-east1.

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

L'architettura più affidabile per una configurazione con ridondanza a livello di regione è l'esecuzione a caldo, anche noto come active-active. Ciò significa che il carico di lavoro viene eseguito in parallelo sia nella regione principale che in quella secondaria. Sebbene sia più costoso, ciò garantisce che la regione secondaria riceva una verifica continua e funzionerà se hai bisogno di eseguire il failover. Se la disponibilità durante un'interruzione di regione è meno problematica, il backup dei dati in un'altra regione garantisce la durabilità.

Scenario: eliminazione 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 in 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. Il viaggio nel tempo funziona anche sulle tabelle che sono state eliminate.

BigQuery supporta anche la possibilità di snapshot delle tabelle. Con questa funzionalità puoi eseguire esplicitamente il backup dei dati all'interno della stessa regione per un periodo più lungo rispetto alla finestra di spostamento cronologico di 7 giorni. Uno snapshot è solo un'operazione di metadati e non comporta byte di archiviazione aggiuntivi. Anche se ciò può aumentare la protezione da eliminazione 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. La protezione contro la mancata disponibilità estesa di BigQuery per l'intera regione richiede la replica continua dei dati e degli slot di provisioning in un'altra regione. Considerato che l'architettura è resiliente all'indisponibilità di BigQuery a causa dell'utilizzo di Pub/Sub e Dataflow nel percorso di importazione, questo elevato livello di ridondanza probabilmente non valga la pena.

Supponendo che l'utente abbia configurato i dati BigQuery in us-east4 per l'esportazione notturna utilizzando i job di esportazione in Cloud Storage nella classe Archive Storage in us-central1. Questo fornisce un backup durevole in caso di perdita catastrofica di dati in us-east4. In questo caso, l'RPO (Recovery Point Objective) è di 24 ore e, nel peggiore dei casi, l'ultimo backup esportato può risalire fino a 24 ore prima. L'RTO (Recovery Time Objective) è 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 effettuati i backup, i dati devono essere prima trasferiti in questa regione. Tieni inoltre presente che, se non hai acquistato in anticipo 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à che un report giornaliero sia completato entro una scadenza fissa da inviare a un regolatore. L'implementazione della ridondanza mediante l'esecuzione di due istanze separate dell'intera pipeline di elaborazione vale probabilmente il costo. L'utilizzo di due regioni separate, ad esempio us-west1 e us-east4, fornisce una separazione geografica e due domini di errore indipendenti in caso di indisponibilità estesa di una regione o persino dell'improbabile evento di una perdita permanente della regione.

Supponendo che il report venga inviato esattamente una volta, dobbiamo riconciliare il caso previsto per il completamento corretto di entrambe le pipeline. Una strategia ragionevole consiste semplicemente nel scegliere il risultato dalla pipeline completa, ad esempio avvisando un argomento Pub/Sub se l'operazione ha esito positivo. In alternativa, sovrascrivi il risultato ed esegui nuovamente 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 che termina per prima da Cloud Storage.

Gestione degli errori

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

Riprova le richieste API non riuscite

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

L'utilizzo di questo metodo di nuovi tentativi rende la tua applicazione molto più solida di fronte agli errori. Anche in condizioni operative normali, è normale che una richiesta su diecimila non vada a buon fine, come descritto nello SLA (accordo sul livello del servizio) con disponibilità del 99,99% di BigQuery. In condizioni anomale, questo tasso di errore può aumentare, ma se gli errori vengono distribuiti in modo casuale, la strategia di backoff esponenziale può mitigare tutti i casi tranne i casi più gravi.

Se si verifica uno scenario in cui una richiesta continua a non riuscire con un errore 5XX, è necessario riassegnare la richiesta all'Assistenza Google Cloud. Assicurati di comunicare chiaramente l'impatto dell'errore sulla tua attività, in modo che il problema possa essere valutato correttamente. Se, invece, una richiesta non va a buon fine di continuo e viene generato un errore 4XX, il problema dovrebbe essere risolvibile modificando l'applicazione. Leggi il messaggio di errore per maggiori 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 i nuovi tentativi fino a un tempo massimo di backoff. Ad esempio:

  1. Fai una richiesta a BigQuery.

  2. Se la richiesta non va a buon fine, attendi 1 + numero_casuale_di_millisecondi 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 + numero_casuale_di_millisecondi e riprova.

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

  6. Continua ad attendere e riprovare 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 aumentato 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 le richieste in wave sincronizzate. Il valore di random_number_milliseconds viene ricalcolato dopo ogni richiesta di nuovo tentativo.

  • L'intervallo di backoff massimo (maximum_backoff) è in genere 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. 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 il client può 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 dipende dal caso d'uso e dalle condizioni della rete.

Nuovo tentativo di inserimento di job non riuscito

Se la semantica dell'inserimento "exactly-once" è importante per l'applicazione, è necessario considerare ulteriori considerazioni in merito all'inserimento dei job. Il modo in cui raggiungere la semantica dipende da ciò che è WriteDisposition specificato. La disposizione di scrittura indica a BigQuery cosa deve fare quando si incontrano dati esistenti in una tabella: errore, sovrascrittura o aggiunta.

Con una disposizione WRITE_EMPTY o WRITE_TRUNCATE, è sufficiente riprovare a eseguire l'inserimento o l'esecuzione del job non riusciti. Questo perché tutte le righe importate da un job vengono scritte a livello atomico nella tabella.

Con una disposizione WRITE_APPEND, il client deve specificare l'ID job per evitare un nuovo tentativo di aggiungere gli stessi dati una seconda volta. 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 più una volta" per ogni ID job. Puoi ottenere esattamente una volta riprovando con un nuovo ID job prevedibile, dopo aver confermato 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. Quando l'inserimento viene ripetuto, la richiesta non riesce con status=ALREADY_EXISTS (code=409 e reason="duplicate"). Lo stato esistente del job 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 può essere un componente fondamentale per varie architetture. A seconda del caso d'uso e dell'architettura di cui è stato eseguito il deployment, potrebbe essere necessario soddisfare una varietà di requisiti di disponibilità, prestazioni o altri requisiti di affidabilità. Ai fini di questa guida, selezioniamo due architetture e casi d'uso principali da 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 Storage Write. I dati vengono quindi utilizzati sia per query ad hoc, ad esempio per ricreare sequenze di eventi che potrebbero aver dato origine a risultati specifici degli endpoint, sia per fornire dashboard quasi in tempo reale al fine di 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à viene percepita come la capacità degli utenti di eseguire query ad hoc con una latenza coerente e prevedibile, nonché di garantire che le dashboard che utilizzano i dati riflettono le informazioni più recenti disponibili in assoluto.

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 è inviare report giornalieri alle autorità di regolamentazione 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 PDF. Pubblicazione 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 correttamente e in un periodo di tempo coerente per rispettare le scadenze richieste.

Passaggi successivi