Entenda a confiabilidade

O BigQuery permite executar cargas de trabalho de análise com o mínimo de interrupção, lidando automaticamente com falhas de máquina e de zona em uma região. Para uma resiliência mais ampla, é possível configurar a recuperação de desastres entre regiões, restaurar dados excluídos ou corrompidos e implementar novas tentativas de erro do lado do cliente para atender aos requisitos de confiabilidade.

Esses recursos são compatíveis com cargas de trabalho que ingerem e analisam grandes volumes de dados com desempenho consistente, incluindo detecção de anomalias, análise em tempo real com ingestão de streaming e análise preditiva com BigQuery ML. Para ver exemplos detalhados dessas soluções, consulte Padrões de referência do BigQuery.

Dimensões de confiabilidade no BigQuery

Para determinar se o BigQuery atende aos requisitos da sua carga de trabalho, avalie a confiabilidade dele em cinco dimensões principais: disponibilidade, durabilidade, consistência de dados, consistência de desempenho e recuperação de dados.

Disponibilidade

A disponibilidade define sua capacidade de ler dados do BigQuery ou gravar dados nele. O BigQuery foi criado para tornar as operações de leitura e gravação altamente disponíveis com um SLA de 99,99% de tempo de atividade. Há dois componentes envolvidos nas duas operações:

• O serviço BigQuery
• Recursos de computação necessários para executar a consulta específica

A confiabilidade do serviço é uma função da API BigQuery específica que você usa para recuperar os dados. A disponibilidade de recursos de computação depende da capacidade disponível para você quando a consulta é executada. Para mais informações sobre a unidade fundamental de computação do BigQuery e a economia de recursos do slot, consulte Noções básicas sobre slots.

Durabilidade

A durabilidade mede a proporção de dados que podem ser lidos, conforme definido no capítulo Como implementar SLOs do Manual de confiabilidade do site. Para oferecer alta durabilidade, o BigQuery armazena automaticamente cópias redundantes dos seus dados em duas zonas no local selecionado.

Consistência de dados

A consistência de dados define como e quando é possível consultar dados depois que eles são gravados ou modificados. Um aspecto da consistência de dados é garantir a semântica "exatamente uma vez" para a ingestão de dados. Para mais informações, consulte Como repetir inserções de job com falha.

Consistência de desempenho

Em geral, o desempenho pode ser expresso em duas dimensões. Latência é uma medida do tempo de execução de operações longas de recuperação de dados, como consultas. Capacidade é uma medida da quantidade de dados que o BigQuery pode processar durante um período específico. Por causa do design multilocatário e escalonável horizontalmente do BigQuery, a capacidade dele pode ser escalonada para tamanhos de dados arbitrários. Seu caso de uso específico determina a importância relativa da latência e da capacidade de processamento.

Recuperação de dados

É possível medir a capacidade de recuperar dados após uma interrupção usando as seguintes métricas:

• Objetivo do tempo de recuperação (RTO): o período máximo em que os dados podem ficar indisponíveis após um incidente.
• Objetivo do ponto de recuperação (RPO): a quantidade máxima de dados coletados antes do incidente que sua organização pode tolerar perder.

Essas considerações são relevantes especificamente no caso improvável de uma zona ou região passar por uma interrupção de vários dias ou destrutiva.

planejamento para recuperação de desastres

Nesta seção, o planejamento de desastres abrange falhas que vão desde a perda de uma única máquina até a perda catastrófica de uma região inteira. O BigQuery lida com falhas zonais e de máquina única automaticamente, enquanto as falhas regionais exigem que você projete sua arquitetura para recuperação, se a carga de trabalho exigir. Entender onde termina a recuperação automática e onde começa sua responsabilidade é essencial para o planejamento de desastres.

O BigQuery oferece um SLA de 99,99% de tempo de atividade. Essa disponibilidade é garantida pela arquitetura regional do BigQuery, que grava dados em duas zonas diferentes e provisiona capacidade de computação redundante. O SLA do BigQuery é o mesmo para regiões (como us-central1) e multirregiões (como US).

Tratamento automático de falhas

Como o BigQuery é um serviço regional, ele lida automaticamente com a perda de uma máquina individual ou de uma zona inteira. O BigQuery abstrai a infraestrutura zonal subjacente.

Perda de uma máquina

As falhas de máquina são uma ocorrência diária em uma escala em que o Google opera. O BigQuery foi projetado para lidar com falhas de máquina automaticamente, sem afetar a zona contida.

O BigQuery divide cada consulta em pequenas tarefas e as envia em paralelo para várias máquinas. Se uma máquina falhar ou se degradar, o BigQuery vai reenviar automaticamente as tarefas afetadas para outra máquina. Esse tipo de abordagem é crucial para reduzir a latência de cauda.

O BigQuery usa a codificação Reed-Solomon para armazenar de maneira durável uma cópia zonal dos seus dados e armazena pelo menos uma cópia zonal adicional em outra zona. Se várias falhas de máquina causarem a perda de uma cópia zonal, o BigQuery detectará a perda e criará uma nova cópia zonal para restaurar a redundância.

Perda de uma zona

Para atender ao SLA de 99,99% de tempo de atividade, o BigQuery fornece redundância zonal automática para slots de dados e computação. Como a disponibilidade de computação de zona única não pode atender a esse SLA sozinha, o BigQuery encaminha automaticamente novas consultas para outra zona em até um minuto após uma interrupção zonal grave. As consultas em andamento podem levar mais tempo para serem concluídas, enquanto as consultas recém-emitidas são concluídas normalmente em outra zona.

Mesmo que uma zona fique indisponível por um período mais longo, não ocorrerá nenhuma perda de dados, porque o BigQuery grava dados de maneira síncrona em duas zonas. Como resultado, uma interrupção zonal não interrompe o serviço.

Tipos de falhas

Há dois tipos de falhas: leves e graves.

Uma falha leve é uma deficiência operacional em que o hardware não é destruído. Alguns exemplos são falha de energia, particionamento de rede ou falha da máquina. O BigQuery foi projetado para evitar a perda de dados durante uma falha leve.

Uma falha grave é uma falha operacional em que o hardware é destruído, como danos causados por inundações, terremotos ou furacões. A capacidade do BigQuery de evitar a perda de dados durante uma falha grave depende se a falha afeta uma única zona ou uma região inteira.

Redundância de local e comportamento de falha

Ao criar um conjunto de dados do BigQuery, você seleciona um local para armazenar os dados. Esse local pode ser:

• Uma região: uma localização geográfica específica, como Iowa (us-central1) ou Montreal (northamerica-northeast1).
• uma multirregião: uma área geográfica grande que contém dois ou mais lugares geográficos, como os Estados Unidos (US) ou a Europa (EU).

Em ambos os casos, o BigQuery armazena automaticamente cópias dos seus dados em duas Google Cloud zonas diferentes do Google Cloud em uma única região no local selecionado.

Além da redundância do armazenamento, o BigQuery também mantém capacidade de computação redundante em várias zonas. Ao combinar armazenamento redundante e computação em várias zonas de disponibilidade, o BigQuery oferece alta disponibilidade e durabilidade.

Observação : a seleção de um local multirregional não fornece replicação entre regiões nem redundância regional. O BigQuery armazena seus dados em uma única região dentro do local multirregional.

No caso de uma falha no nível da máquina, o BigQuery continua sendo executado com alguns milissegundos de atraso, e todas as consultas em execução continuam sendo processadas. Durante uma falha zonal leve ou grave, não ocorre perda de dados, mas talvez seja necessário reenviar as consultas em execução. O BigQuery mitiga automaticamente falhas zonais leves, como quedas de energia, falhas de transformador ou partições de rede, em poucos minutos.

Uma falha regional leve, como uma perda de conectividade de rede em toda a região, resulta em uma perda de disponibilidade até que a região volte a ficar on-line, mas não resulta em perda de dados. Uma falha regional grave, como um desastre que destrói uma região inteira, pode resultar na perda de dados armazenados nela. O BigQuery não fornece automaticamente um backup ou uma réplica dos dados em outra região geográfica. É possível usar a replicação de conjuntos de dados entre regiões ou a recuperação de desastres gerenciada para aumentar sua resiliência a falhas regionais graves.

Para saber mais sobre os locais dos conjuntos de dados do BigQuery, consulte Considerações sobre locais.

Cenário: perda da região

O BigQuery não oferece durabilidade ou disponibilidade se uma região física for destruída. Essa limitação se aplica a regiões e multirregiões. Portanto, para manter a durabilidade e a disponibilidade durante uma interrupção regional, é necessário planejar com antecedência. Se o SLA de 99,99% do BigQuery não atender aos seus requisitos de disponibilidade durante uma interrupção regional temporária, considere configurar a disponibilidade redundante entre regiões.

Para evitar a perda de dados se uma região for destruída, faça backup dos dados em outra localização geográfica. Por exemplo, é possível usar a replicação de conjuntos de dados entre regiões para replicar continuamente seus dados em uma região geograficamente distinta.

Se você usar uma multirregião do BigQuery, não faça backup de dados em uma única região dentro do escopo geográfico dessa multirregião. Por exemplo, se você fizer backup de dados da multirregião US, evite escolher uma região sobreposta, como us-central1, devido ao risco de falha correlacionada durante um desastre. Para mais informações sobre o escopo geográfico de multirregiões, consulte Multirregiões.

Para evitar a indisponibilidade estendida, replique os dados e provisione slots em dois locais geograficamente separados do BigQuery. É possível usar a recuperação de desastres gerenciada para provisionar slots automaticamente em uma região secundária e controlar o failover das cargas de trabalho de uma região para outra.

Situação: exclusão acidental ou corrupção de dados

Em virtude da arquitetura de controle de simultaneidade de várias versões do BigQuery, o BigQuery é compatível com viagens de tempo. Com a viagem no tempo, é possível consultar dados de qualquer ponto nos últimos sete dias. Esse recurso permite restaurar dados que foram excluídos, modificados ou corrompidos por engano em uma janela de sete dias. A viagem no tempo também funciona em tabelas excluídas.

O BigQuery também permite criar snapshots de tabela para fazer backup de dados na mesma região por mais tempo do que a janela de viagem no tempo de sete dias. A criação de um snapshot é uma operação somente de metadados que não gera cobranças extras de armazenamento. Embora os snapshots de tabela ajudem a proteger contra exclusão acidental, eles não aumentam a durabilidade dos dados.

Recuperação de desastres para análise em tempo real

Para um pipeline de análise em tempo real que ingere continuamente registros de endpoint de streaming no BigQuery, a proteção contra indisponibilidade regional estendida requer a replicação contínua de dados e o provisionamento de slots em uma região secundária. No entanto, como a arquitetura de ingestão já é resiliente à indisponibilidade temporária do BigQuery quando usa o Pub/Sub e o Dataflow como um dos métodos de carregamento de dados, esse alto nível de redundância pode não valer o custo.

Por exemplo, suponha que você configure jobs de extração noturnos para exportar dados do BigQuery de us-east4 para o armazenamento do Archive Storage do Cloud Storage em us-central1. Essa exportação fornece um backup durável se ocorrer uma perda de dados catastrófica em us-east4. Nessa configuração, o objetivo de ponto de recuperação (RPO) é de 24 horas, porque o backup mais recente pode ter até 24 horas de idade. O objetivo de tempo de recuperação (RTO) pode ser de vários dias, porque é preciso restaurar os dados do backup do Cloud Storage para o BigQuery em us-central1. Se você provisionar o BigQuery em uma região diferente dos backups, será necessário transferir os dados para essa região primeiro. A menos que você compre slots redundantes na região de recuperação com antecedência, o provisionamento da capacidade necessária do BigQuery pode levar mais tempo, dependendo da quantidade solicitada.

Recuperação de desastres para processamento de dados em lote

Para uma carga de trabalho de processamento de dados em lote em que você precisa entregar um relatório diário essencial para os negócios a um regulador em um prazo fixo, implementar a redundância executando duas instâncias separadas de todo o pipeline de processamento geralmente vale o custo. Usar duas regiões separadas, como us-west1 e us-east4, fornece separação geográfica e dois domínios de falha independentes em caso de indisponibilidade regional estendida ou perda permanente de região.

Se você precisar entregar o relatório exatamente uma vez, será necessário reconciliar a saída quando os dois pipelines forem concluídos com sucesso. Uma abordagem é selecionar o resultado do pipeline que termina primeiro, por exemplo, publicando uma notificação em um tópico do Pub/Sub após a conclusão. Como alternativa, é possível permitir que o segundo pipeline substitua o resultado e use o controle de versões de objetos no Cloud Storage. Se o pipeline que terminar depois gravar dados corrompidos, será possível restaurar a versão gravada pelo primeiro pipeline do Cloud Storage.

Tratamento de erros

As seções a seguir descrevem as práticas recomendadas para lidar com erros que afetam a confiabilidade.

Repetir solicitações de API com falha

Quando os aplicativos cliente, as bibliotecas de cliente ou as ferramentas de parceiros emitirem solicitações de API para o BigQuery, use a espera exponencial truncada. Com essa estratégia de repetição, se um cliente receber um erro de sistema ou de cota, ele vai repetir a solicitação até um número máximo de vezes usando um intervalo de espera aleatório e crescente.

O uso da espera exponencial truncada torna o aplicativo mais resiliente a erros temporários. Mesmo sob condições operacionais normais, a expectativa é de que aproximadamente uma entre 10.000 solicitações falhe,conforme descrito no SLA de 99, 99% de disponibilidade do BigQuery. Em condições anormais, essa taxa de erro pode aumentar. No entanto, se os erros forem distribuídos aleatoriamente, a espera exponencial poderá mitigar a maioria das falhas.

Se uma solicitação falhar de forma persistente com um erro 5xx, entre em contato com o Cloud Customer Care e comunique claramente o impacto nos negócios ao definir a prioridade do caso de suporte para que o suporte possa avaliar o problema com precisão. Por outro lado, se uma solicitação falhar persistentemente com um erro 4xx, será possível resolver o problema modificando o aplicativo. Verifique a mensagem de erro para mais detalhes.

Exemplo de lógica de espera exponencial

A lógica de espera exponencial repete uma consulta ou solicitação aumentando o tempo de espera entre novas tentativas até um tempo máximo de espera. As etapas a seguir ilustram como um cliente implementa a espera exponencial truncada:

1. Faça uma solicitação ao BigQuery.

2. Se a solicitação falhar, aguarde 1 + random_number_milliseconds segundos e tente novamente.

3. Se a solicitação falhar, aguarde 2 + random_number_milliseconds segundos e tente novamente.

4. Se a solicitação falhar, aguarde 4 + random_number_milliseconds segundos e tente novamente.

5. Repita esse padrão, dobrando o tempo de espera base em cada nova tentativa até o tempo maximum_backoff.

6. Continue aguardando e tentando até um número máximo de novas tentativas, sem aumentar o período de espera além de maximum_backoff.

Considere os seguintes detalhes para esse cálculo de espera:

• O tempo de espera é min(((2^n)+random_number_milliseconds), maximum_backoff), com n incrementado em 1 para cada iteração (solicitação).

• random_number_milliseconds é um número aleatório de milissegundos menor ou igual a 1.000. Essa ordem aleatória ajuda a evitar situações em que muitos clientes são sincronizados por acaso e tentam novamente simultaneamente, enviando solicitações em ondas sincronizadas. Recalcule random_number_milliseconds após cada nova tentativa de solicitação.

• O intervalo máximo de espera (maximum_backoff) normalmente é de 32 ou 64 segundos. O valor adequado de maximum_backoff depende do caso de uso.

O cliente pode continuar tentando novamente após atingir o tempo máximo de espera. As novas tentativas após esse ponto não precisam continuar aumentando o tempo de espera. Por exemplo, se o cliente usa um tempo máximo de espera de 64 segundos, depois de atingir esse valor, ele pode continuar a repetir a cada 64 segundos. Para evitar loops infinitos de novas tentativas, configure um número máximo de novas tentativas para que o cliente pare de tentar novamente após um limite definido.

O tempo de espera entre novas tentativas e o número de novas tentativas depende do seu caso de uso e das condições da rede.

Repetir inserções de jobs com falha

Se o aplicativo exigir a semântica de inserção exatamente uma vez, considere como o WriteDisposition do job processa os dados atuais em uma tabela (falha, substituição ou adição ao final).

Com uma disposição WRITE_EMPTY ou WRITE_TRUNCATE, é possível alcançar a semântica de no máximo uma vez ao repetir qualquer inserção ou execução de job com falha, porque o BigQuery grava atomicamente todas as linhas que um job ingere na tabela.

Com uma disposição WRITE_APPEND, especifique um ID de job personalizado para que uma nova tentativa não anexe dados duplicados. Como o BigQuery rejeita qualquer solicitação de criação de tarefa que reutilize um ID da tarefa anterior, especificar um ID da tarefa fornece semântica de no máximo uma vez para esse ID. Para alcançar a semântica exatamente uma vez, confirme que todas as tentativas anteriores falharam antes de tentar novamente com um novo ID da tarefa previsível.

Se um problema de rede temporário impedir que o cliente receba a confirmação de uma inserção de job, uma nova tentativa com o mesmo ID da tarefa vai falhar com status=ALREADY_EXISTS (code=409 e reason="duplicate"). Chame jobs.get para recuperar o status do job atual e determinar se é necessário criar um novo job com um novo ID da tarefa.

Casos de uso e requisitos de confiabilidade

O BigQuery pode ser um componente essencial em várias arquiteturas. Dependendo do caso de uso e da arquitetura que você implantar, talvez seja necessário atender a diferentes requisitos de disponibilidade, desempenho e confiabilidade. As seções a seguir examinam duas arquiteturas comuns e os requisitos de confiabilidade delas.

Análise em tempo real

O primeiro exemplo é um pipeline de processamento de dados de eventos. Nessa arquitetura, o Pub/Sub ingere eventos de registro de endpoints, e um pipeline de streaming do Dataflow processa e grava os dados no BigQuery usando a API BigQuery Storage Write. Em seguida, os analistas executam consultas ad hoc nos dados para recriar sequências de eventos, e os painéis quase em tempo real visualizam os dados para detectar tendências e padrões.

Como essa carga de trabalho requer alta atualização de dados de ponta a ponta, uma baixa latência de ingestão é fundamental. Depois que os dados são gravados no BigQuery, a confiabilidade depende de dois fatores: se os usuários podem executar consultas ad hoc com latência consistente e previsível e se os painéis que usam os dados refletem as informações mais recentes.

Processamento de dados em lote

O segundo exemplo é uma arquitetura de processamento em lote para conformidade regulatória no setor de serviços financeiros. Um requisito fundamental é fornecer relatórios diários aos reguladores até um prazo noturno fixo. Desde que o processo em lote noturno que gera os relatórios seja concluído até esse prazo, ele atenderá ao requisito de desempenho.

O pipeline carrega dados no BigQuery e os associa a outras fontes de dados para painéis, análises e geração de relatórios em PDF. Entregar esses relatórios em tempo hábil e sem erros é um requisito essencial para os negócios. Portanto, é preciso garantir a confiabilidade durante a ingestão de dados e gerar relatórios precisos em um período consistente para cumprir os prazos regulatórios.