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 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 enormi e set di dati. Offre un modo per importare, archiviare, leggere ed eseguire query da megabyte a petabyte di dati in modo coerente senza dover gestire nessuna infrastruttura sottostante. Per via della sua potenza e delle sue prestazioni, BigQuery è adatto a essere utilizzati in una serie di soluzioni. Alcuni di questi sono documentati in dettaglio pattern di riferimento.

In genere, BigQuery è ideale per carichi di lavoro in cui di dati vengono importati e analizzati. 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. Se però stai cercando un database per supportare le applicazioni in stile Online Transaction Processing (OLTP), devi prendi in considerazione altri servizi Google Cloud come Spanner, Cloud SQL o Bigtable più adatti per 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 hanno 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 Informazioni sugli slot per ulteriori informazioni sull'unità fondamentale di computing BigQuery e la 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 dei dati che possono essere lettura completata."

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 ulteriori informazioni, consulta "Affidabilità della soluzione" in Casi d'uso di esempio per il caricamento dei dati. e Riprovare a inserire i 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 è in grado di elaborare durante un periodo di tempo specifico. Grazie alla tecnologia multi-tenant di BigQuery, scalabile orizzontalmente, la velocità effettiva può essere scalata fino a raggiungere dati arbitrari dimensioni. L'importanza relativa della latenza e della velocità effettiva è determinata 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 più disponibili dopo il giorno di un incidente.
  • RPO (Recovery Point Objective). Quanti dei dati raccolti prima di che l'incidente possa andare perduto.

Queste considerazioni sono particolarmente rilevanti nell'improbabile caso che una zona o regione sia sottoposta a un'interruzione di più giorni o distruttiva.

Pianificazione in caso di emergenza

Mentre termine "calamità" possono richiamare visioni di calamità naturali, l'ambito di questa sezione risolve gli errori specifici dovuti alla perdita di una singola macchina attraverso la catastrofica perdita di una 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 Stati Uniti.

Gestione automatica dello scenario

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

Perdita di una macchina

Gli errori dei computer si verificano tutti i giorni nella scala in cui Google dell'IA. BigQuery è progettato per gestire gli errori delle macchine automaticamente senza alcun impatto sulla zona che la contiene.
Di base, l'esecuzione di una query è suddivisa in attività di piccole dimensioni che possono essere vengono inviati 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 di coda.

BigQuery utilizza Reed - Salomone per archiviare una copia dei dati a livello di zona in modo efficiente e duraturo. Nella è molto improbabile che più errori delle macchine causino la perdita di un'infrastruttura i dati vengono archiviati allo stesso modo in almeno un'altra zona. Nel in questo caso, BigQuery rileverà il problema e creerà una nuova 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 per soddisfare lo SLA con uptime del 99,99% di BigQuery. Pertanto, BigQuery offre la ridondanza automatica a livello di zona sia per i dati di calcolo slot machine. Sebbene le interruzioni di zona di breve durata non siano comuni, che accadrà. Tuttavia, l'automazione di BigQuery eseguirà il failover delle query un'altra zona entro uno o due 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 dovesse rimanere non disponibile per un periodo di tempo più lungo, nessuna perdita di dati perché BigQuery scrive in modo sincrono 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 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. Nel in generale, BigQuery non dovrebbe mai perdere dati in caso di errore.

Un errore hardware è un difetto operativo che comporta la distruzione dell'hardware. Difficile sono più gravi di quelli software. Ecco alcuni esempi di errori rigidi: danni da inondazioni, attacchi terroristici, terremoti e uragani.

Disponibilità e durabilità

Quando crei un set di dati BigQuery, selezioni una località in cui per archiviare 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 copie dei tuoi dati in due diverse zone Google Cloud all'interno di una singola regione nella località selezionata.

Oltre alla ridondanza dello spazio di archiviazione, BigQuery mantiene anche con capacità di calcolo ridondante in più zone. Combinando lo spazio di archiviazione ridondante e computing in più zone di disponibilità, BigQuery fornisce sia alta disponibilità che durabilità.

In caso di errore a livello di macchina, BigQuery continua vengono eseguiti con un ritardo non superiore a qualche secondo. Tutti attualmente in esecuzione continuano l'elaborazione. Nel caso di problemi 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 regionale hard, ad esempio se una catastrofe distrugge l'intera regione, potrebbe comportare la perdita dei dati archiviati in quella regione. BigQuery non fornirà automaticamente un backup o una replica dei tuoi dati in un'altra regione geografica. Puoi creare un set di dati interregionale copie per migliorare le funzionalità di ripristino di emergenza strategia.

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

Scenario: perdita di area geografica

BigQuery non offre durabilità o disponibilità nel evento straordinariamente improbabile e senza precedenti di perdita di una regione fisica. Questo vale sia per le "regioni sia per più regioni" configurazioni. Il mantenimento di durabilità e disponibilità in un questo scenario richiede una 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 BigQuery multiregionali, dovresti evitare il backup regioni che rientrano nell'ambito di più regioni. Ad esempio, non eseguire il backup dai tuoi dati negli Stati Uniti alla 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 già detto, evita di combinare più regioni con più regioni, in quanto hanno condiviso il loro destino in un 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, assicura che la regione secondaria riceva la verifica continua e funzionerà se a cui devi eseguire il failover. Se la disponibilità durante un'interruzione a livello di regione è inferiore quindi il backup dei dati in un'altra regione garantisce la durabilità.

Scenario: cancellazione accidentale o danneggiamento dei dati

Grazie a BigQuery controllo contemporaneità multiversione , BigQuery supporta viaggio nel tempo. Con questa funzione puoi eseguire query sui dati in 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 questo puoi eseguire il backup esplicito dei dati all'interno della stessa regione per un periodo superiore a la finestra di spostamento cronologico di 7 giorni. Uno snapshot è solo un'operazione sui metadati non genera byte 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 flussi di dati vengono importati dai log degli endpoint BigQuery senza interruzioni. Protezione da estensioni La disponibilità di BigQuery per l'intera regione richiede la replica continua dei dati e il provisioning degli slot in una regione diversa. 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.

Supponendo che l'utente abbia configurato i dati BigQuery in us-east4 da esportare ogni 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 nella regione us-east4. In questo caso, il punto di ripristino L'obiettivo (RPO) è di 24 ore, poiché l'ultimo backup esportato può durare fino a 24 ore vecchi, 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 in una regione diversa da quella in cui vengono posizionati i backup, i dati devono verrà prima trasferito 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

In questo caso d'uso è fondamentale che un report giornaliero venga completato una scadenza fissa per essere inviata a un ente regolatore. Implementare la ridondanza eseguendo due istanze separate dell'intera pipeline di elaborazione dovrebbero valere il costo. Usare due regioni distinte, ad esempio us-west1 e us-east4, forniscono dati geografici e due domini di errore indipendenti in caso di estensione indisponibilità di una regione o persino nel caso improbabile di una regione permanente o una perdita di dati.

Supponendo di dover consegnare la segnalazione esattamente una volta, dobbiamo riconciliare il caso previsto di entrambe le pipeline. Un modo ragionevole strategia è semplicemente scegliere il risultato dalla pipeline che termina per primo, ad esempio di per inviare una notifica a un argomento Pub/Sub al completamento dell'operazione. In alternativa, sovrascrivere il risultato e reimpostare l'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 correggere errori che influiscono sull'affidabilità.

Riprova 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 normali condizioni di funzionamento, è possibile l'ordine di una richiesta su diecimila non riesce, come descritto SLA (accordo sul livello del servizio) con disponibilità del 99,99% di BigQuery. Sottopeso in condizioni anomale, il tasso di errore può aumentare, ma se gli errori vengono la strategia del backoff esponenziale può mitigare tutti tranne i maggiori casi 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 l'errore si trova sulla tua attività in modo che il problema possa essere valutato in modo corretto. Se, invece, una richiesta non va a buon fine in modo persistente e con un errore 4XX, il problema dovrebbe essere risolvibile modificando l'applicazione. Leggi per i dettagli.

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. Effettua una richiesta a BigQuery.

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

  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 secondi + numero_casuale_millisecondi di secondi e riprova la richiesta.

  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 aumentano il periodo di attesa tra un nuovo tentativo e l'altro.

Tieni presente quanto segue:

  • Il tempo di attesa è di 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 di 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 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. 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. In alcuni casi ai client non dovrebbe essere consentito 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 dell'inserimento "exactly-once" è importante per la tua applicazione, sono aspetti aggiuntivi da considerare per l'inserimento di job. Come raggiungere a una volta che la semantica dipende da quale WriteDisposition da te specificato. L'istruzione di scrittura indica a BigQuery cosa quando si incontrano dati esistenti in una tabella: errore, sovrascrittura o aggiunta.

Con un'istruzione WRITE_EMPTY o WRITE_TRUNCATE, questo si ottiene semplicemente ritentando l'inserimento o l'esecuzione di job non riusciti. Il motivo è che tutte le righe importati da un job vengono scritti atomicamente nella tabella.

Con un'istruzione WRITE_APPEND, il client deve specificare l'ID job da utilizzare evita un nuovo tentativo di aggiungere gli stessi dati una seconda volta. Questo funziona perché BigQuery rifiuta le richieste di creazione di job che tentano di utilizzare un ID di un job precedente. Questo raggiunge la semantica "at-most-once" per qualsiasi job ID. Puoi quindi ottenere il risultato "exactly-once" riprovando con un nuovo ID job prevedibile dopo aver confermato con BigQuery che tutti i tentativi precedenti non sono riuscite.

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 è necessario creare un nuovo job con un nuovo ID JOB.

Casi d'uso e requisiti di affidabilità

BigQuery potrebbe essere un componente fondamentale di una serie diverse architetture. A seconda del caso d'uso e dell'architettura di cui si esegue di disponibilità, prestazioni o altri requisiti di affidabilità. Ai fini di questa guida, selezioniamo due casi d'uso principali architetture di cui discutere 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, la pipeline Dataflow in modalità flusso esegue alcune operazioni sui dati di scriverlo in BigQuery utilizzando API Storage Scrivi. 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 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 elevati, 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. Garantire che questi report vengano forniti puntualmente e senza errori è un requisito aziendale critico. Pertanto, garantire l'affidabilità di entrambi importazione dati e la produzione del report in modo corretto e coerente il tempo necessario per rispettare le scadenze previste sono fondamentali.

Passaggi successivi