Informazioni sull'affidabilità

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

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

  • Determina se BigQuery è lo strumento giusto per il tuo lavoro.
  • 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 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 al suo rendimento, BigQuery è adatto per essere utilizzato in una serie di soluzioni. Alcuni di questi sono documentati in dettaglio 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, implementato in modo efficace per casi d'uso come dati predittivi e in tempo reale Analytics (con importazione di flussi di dati e BigQuery ML), rilevamento di anomalie e altri casi d'uso in cui l'analisi di grandi volumi di dati con prestazioni prevedibili è la chiave. 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 scrivere dati al suo interno. BigQuery è progettato per entrambi altamente disponibili con una percentuale del 99,99% SLA. Entrambe le operazioni prevedono due componenti:

  • Il servizio BigQuery
  • Risorse di calcolo 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 a disposizione dell'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 che gli utenti hanno in merito al modo in cui i dati possono essere l'esecuzione di query dopo la scrittura o la modifica. Un aspetto della coerenza dei dati è assicurando che la funzionalità "exactly-once" per l'importazione dati. Per saperne di più, consulta "Affidabilità della soluzione" in Casi d'uso di esempio per il caricamento dei dati e Riprova 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 lunghe operazioni di recupero di dati come le query. La tasso di trasmissione è 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 aumentato 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. Le prime sono occorrenze quotidiane BigQuery gestisce automaticamente, mentre la seconda che potrebbero servire ai clienti per progettare la propria architettura, se necessario. Capire a quale ambito la pianificazione in caso di emergenza interessa il cliente la responsabilità è importante.

BigQuery offre un'azienda leader del settore SLA con uptime del 99,99%. Ciò è reso possibile dall'architettura regionale di BigQuery che scrive i dati in due zone diverse e fornisce una capacità di calcolo ridondante. it è importante tenere presente che lo SLA (accordo sul livello del servizio) di BigQuery per le regioni, ad esempio us-central1 e multiregionali, come US.

Gestione automatica dello scenario

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 deterioramento improvviso della le prestazioni della macchina vengono gestite automaticamente macchina diversa. Questo approccio è fondamentale per ridurre la latenza finale.

BigQuery utilizza la codifica Reed-Solomon per archiviare in modo efficiente e duraturo una copia zonale dei dati. Nell'eventualit'e altamente improbabile che più guasti del macchinario 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. Pertanto, BigQuery offre la ridondanza automatica a livello di zona sia per i dati di calcolo slot machine. 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. Già in volo delle query potrebbero non essere recuperate immediatamente, a differenza delle query appena emesse. Questo potrebbe si manifesta quando il completamento delle query in corso richiede molto tempo dopo l'emissione le query vengono completate 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 in modo sincrono i dati in due zone. Quindi, anche di fronte a una perdita a livello di zona, i clienti o subire un'interruzione del servizio.

Tipi di errori

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

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. Nella in generale, BigQuery non dovrebbe mai perdere dati in caso di errore.

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 località geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
  • Una multiregione: una grande area geografica che contiene due o più aree geografiche località, come 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 posizione 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à. Nel caso di problemi a livello di zona non è prevista alcuna perdita di dati. Tuttavia, le query attualmente in esecuzione potrebbero non riuscire e dovranno essere inviati di nuovo. Un errore soft a livello di zona, ad esempio a seguito di un'interruzione di corrente, la distruzione di un trasformatore o una partizione di rete; è un percorso collaudato e mitigato automaticamente in pochi minuti.

Un errore regionale soft, ad esempio una perdita di connettività di rete a livello di regione comporta una perdita di disponibilità finché la regione non viene riportata di nuovo online, senza però perdere i 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 un set di dati interregionale copie per migliorare le funzionalità di ripristino di emergenza strategia.

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à nel evento straordinariamente improbabile e senza precedenti di 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, come di 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 una perdita distruttiva a livello di regione, devi eseguire il backup in un'altra posizione geografica. Ad esempio, potresti periodicamente puoi esportare uno snapshot dei tuoi dati in Google Cloud Storage in un una regione geograficamente distinta. Questa operazione può essere eseguita come descritto Caso d'uso dell'elaborazione dei dati in batch.
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à multiregionale possono condividono domini in errore e condividono il destino in caso di disastro. Esegui invece il backup in una regione al di fuori degli Stati Uniti, ad esempio northamerica-northeast1. Se la residenza dei dati richiedono l'archiviazione dei backup negli Stati Uniti, allora è meglio accoppiare due regioni, come us-central1 e us-east1.

Per evitare un'indisponibilità estesa, devi replicare i dati di slot di cui è stato eseguito il provisioning in due aree BigQuery separate luoghi. Come sopra, evita di combinare regioni e località multiregione, in quanto potrebbero avere lo stesso destino in caso di disastro.

L'architettura più affidabile per una configurazione ridondante per regione è l'esecuzione hot-hot, noto anche come attivo-attivo. 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 regionale non è un problema, il backup dei dati in un'altra regione garantisce la durabilità.

Scenario: cancellazione 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. Ciò consente il ripristino self-service di tutti i dati eliminati, modificati o danneggiati per errore in un periodo di 7 giorni. Viaggio nel tempo funziona anche su tabelle eliminate.

BigQuery supporta inoltre la possibilità di eseguire uno snapshot tabelle. Con questa funzionalità puoi eseguire il backup esplicito dei dati all'interno della stessa regione per più di la 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. Anche se questa impostazione può aumentare la protezione eliminazione accidentale, questo 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'interruzione prolungata della disponibilità di BigQuery per l'intera regione, devi replicare continuamente i dati e eseguire il provisioning degli slot in un'altra regione. Dato che l'architettura è resiliente a BigQuery indisponibilità a causa l'utilizzo di Pub/Sub e Dataflow nel percorso di importazione, questo alto 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 archiviazione in us-central1. Questo fornisce un backup durevole in caso di perdita di dati catastrofica nella regione 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. Il Recovery Time Objective (RTO) è potenzialmente giorni, poiché ripristinare i dati dal backup di Cloud Storage 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 di slot ridondanti nella regione di ripristino, potrebbe esserci 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. Implementare la ridondanza eseguendo due istanze separate dell'intera pipeline di elaborazione dovrebbero valere 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 se la pipeline termina in un secondo momento scrive dati corrotti, puoi recuperarlo 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

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

L'impiego di questo metodo di nuovi tentativi rende la tua domanda molto più efficace nel di fronte agli 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 del backoff esponenziale può mitigare tutti i casi tranne i più gravi.

Se si verifica 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 tenta di nuovo una query o una richiesta aumentando il valore di attesa tra un nuovo tentativo e l'altro, fino al 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 secondi + numero_casuale_millisecondi e riprova la richiesta.

  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 inferiore o uguale a 1000. Questa randomizzazione aiuta a evitare situazioni in cui molti client vengono sincronizzati e tutti riprovano contemporaneamente, inviando le richieste in tra le onde. Il valore di random_number_milliseconds viene ricalcolato dopo ogni riprova a eseguire la richiesta.

  • 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 dopo aver raggiunto il tempo di backoff massimo. Non è necessario continuare ad aumentare il tempo di backoff per i nuovi tentativi successivi a questo punto. Per Ad esempio, se il client utilizza un tempo di backoff massimo di 64 secondi, raggiungendo questo valore, il client 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 alle condizioni della rete.

Riprova gli inserimenti di job non riusciti

Se la semantica di inserimento esattamente una volta è importante per la tua applicazione, esistono considerazioni aggiuntive per 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 un'istruzione WRITE_EMPTY o WRITE_TRUNCATE, questo si ottiene semplicemente ritentando l'inserimento o l'esecuzione di job non riusciti. 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 almeno una volta per qualsiasi ID compito. 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 andati a buon fine.

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 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, registra gli eventi 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 quindi utilizzati sia per le query ad hoc, ad esempio per ricreare sequenze di eventi che potrebbero aver portato a risultati specifici dell'endpoint per l'inserimento di dashboard quasi in tempo reale per consentire il rilevamento di tendenze di pattern nei 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 alti, la latenza di importazione è fondamentale. Una volta scritti i dati in BigQuery, Per affidabilità si intende la capacità degli utenti di eseguire query ad hoc con una latenza coerente e prevedibile, assicurando inoltre che le dashboard che utilizzano i dati riflettono le informazioni disponibili in assoluto più recenti.

Elaborazione dei dati in batch

Il secondo esempio è un'architettura di elaborazione batch basata su nel settore dei servizi finanziari. Un requisito chiave è offrire report giornalieri agli enti regolatori entro una scadenza notturna fissa. Purché la notte dell'elaborazione batch che genera i report completati entro questa scadenza, considerata sufficientemente rapida.

I dati devono essere resi disponibili in BigQuery e uniti ad altri origini dati per la creazione di dashboard, l'analisi e la generazione di un PDF report. 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 dati sia della generazione del report in modo corretto e in un periodo di tempo coerente per rispettare le scadenze richieste.

Passaggi successivi