Entenda a confiabilidade

Neste guia, apresentamos uma noção básica dos recursos de confiabilidade do BigQuery, como disponibilidade, durabilidade, consistência de dados, consistência de desempenho, recuperação de dados e uma análise das considerações sobre tratamento de erros.

Esta introdução ajuda a abordar três considerações principais:

determine se o BigQuery é a ferramenta certa para seu trabalho;
entenda as dimensões de confiabilidade do BigQuery;
identifique requisitos de confiabilidade específicos para casos de uso específicos.

Selecione BigQuery

O BigQuery é um armazenamento de dados empresarial totalmente gerenciado criado para armazenar e analisar conjuntos de dados grandes. Ele oferece uma maneira de ingerir, armazenar, ler e consultar de megabytes a petabytes de dados com desempenho consistente sem precisar gerenciar nenhuma infraestrutura subjacente. Devido à capacidade e ao desempenho, o BigQuery é adequado para uso em várias soluções. Algumas delas estão documentadas em detalhes como padrões de referência.

Geralmente, o BigQuery é muito adequado para cargas de trabalho em que grandes quantidades de dados estão sendo ingeridas e analisadas. Especificamente, ele pode ser implantado de maneira eficaz em casos de uso como análise de dados preditiva e em tempo real (com ingestão de streaming e BigQuery ML), detecção de anomalias e outros casos de uso em que é fundamental analisar grandes volumes de dados com desempenho previsível. No entanto, se você estiver buscando um banco de dados que suporte aplicativos de estilo de processamento de transações on-line (OLTP, na sigla em inglês), considere outros serviços do Google Cloud, como o Spanner, Cloud SQL ou Bigtable, que podem ser mais adequados para esses casos de uso.

Dimensões de confiabilidade no BigQuery

Disponibilidade

A disponibilidade define a capacidade do usuário de ler dados do BigQuery ou de gravar dados nele. O BigQuery foi criado para tornar esses dois recursos altamente disponíveis com um SLA de 99,99%. 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 sendo usada para recuperar os dados. A disponibilidade de recursos de computação depende da capacidade disponível para o usuário no momento em que a consulta é executada Consulte Noções básicas sobre slots para mais informações sobre a unidade fundamental de computação do BigQuery e a economia de recursos do slot resultante.

Durabilidade

A durabilidade é discutida no capítulo "Como implementar SLOs" da pasta de trabalho de SRE e é descrita como a "proporção de dados que podem ser lidos".

Consistência de dados

A consistência define as expectativas que os usuários têm sobre como os dados podem ser consultados depois de 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 "Confiabilidade da solução" em Exemplos de casos de uso no carregamento de dados e Repetir inserções de jobs 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. A importância relativa da latência e da capacidade é determinada pelo caso de uso específico.

Recuperação de dados

Veja as duas maneiras de medir a capacidade de recuperar dados após uma interrupção:

Objetivo de tempo de recuperação (RTO, na sigla em inglês). Por quanto tempo os dados podem ficar indisponíveis após um incidente.
Objetivo de ponto de recuperação (RPO). Quanto dos dados coletados antes do incidente podem ser perdidos de forma aceitável.

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

Embora o termo "desastre" possa invocar visões de desastres naturais, o escopo desta seção aborda falhas específicas da perda de uma máquina individual até a perda catastrófica de uma região. O primeiro é uma ocorrência cotidiana que é processada automaticamente pelo BigQuery. Já o segundo é algo que os clientes podem precisar projetar para processar a arquitetura que é necessária. É importante entender em qual escopo o planejamento de desastres passa para a responsabilidade do cliente.

O BigQuery oferece um SLA de 99,99% de tempo de atividade líder do setor. Isso é possível com a arquitetura regional do BigQuery que grava dados em duas zonas diferentes e provisiona capacidade de computação redundante. É importante lembrar que o SLA do BigQuery é o mesmo para regiões, como us-central1, e multirregiões, como EUA.

Tratamento automático de cenários

Como o BigQuery é um serviço regional, é de responsabilidade do BigQuery lidar com a perda automática de uma máquina ou mesmo de uma zona inteira. O fato de o BigQuery ser criado com base em zonas é abstraído dos usuários.

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 qualquer impacto na zona contida.
Internamente, a execução de uma consulta é dividida em pequenas tarefas que podem ser enviadas em paralelo para várias máquinas. A perda ou degradação repentina do desempenho da máquina é processada automaticamente pelo reenvio de trabalho para uma máquina diferente. Esse tipo de abordagem é crucial para reduzir a latência de cauda.

O BigQuery utiliza a codificação Reed–Solomon para armazenar uma cópia de seus dados de maneira eficiente e durável. No caso improvável de que várias falhas de máquina causem a perda de uma cópia zonal, os dados também são armazenados da mesma maneira em pelo menos uma outra zona. Nesse caso, o BigQuery detectará o problema e fará uma nova cópia zonal dos dados para restaurar a redundância.

Perda de uma zona

A disponibilidade subjacente de recursos de computação em qualquer zona não é suficiente para atender ao SLA de tempo de atividade de 99,99% do BigQuery. Portanto, o BigQuery fornece redundância zonal automática para slots de dados e computação. Embora as interrupções zonais de curta duração não sejam comuns, elas acontecem. No entanto, a automação do BigQuery faz o failover das consultas para outra zona em um ou dois minutos de qualquer interrupção grave. As consultas já em andamento podem não ser recuperadas imediatamente, mas as consultas recém-emitidas serão. As consultas em andamento demorariam muito para serem concluídas enquanto as consultas recém-enviadas seriam concluídas com rapidez.

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. Portanto, mesmo em caso de perda zonal, os clientes não terão interrupções no serviço.

Tipos de falhas

Há dois tipos de falhas: falhas leves e falhas graves.

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. Em geral, o BigQuery nunca perde dados no caso de uma falha leve.

Falha grave é uma deficiência operacional em que o hardware é destruído. As falhas graves são mais fortes que as leves. Alguns exemplos são danos causados por enchentes, ataques terroristas, terremotos e furacões.

Disponibilidade e durabilidade

Ao criar um conjunto de dados do BigQuery, você seleciona um local para armazenar seus 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 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.

No caso de uma falha no nível da máquina, o BigQuery continua sendo executado com alguns milissegundos de atraso. Todas as consultas em execução no momento continuam sendo processadas. Caso haja uma falha de zona leve ou grave, nenhuma perda de dados é esperada. No entanto, as consultas em execução podem falhar e precisar ser reenviadas. Uma falha leve na zona, como resultado de uma falta de energia, transformador destruído ou partição de rede, é um caminho bem testado e será mitigada automaticamente em alguns minutos.

Uma falha regional leve, como perda de conectividade de rede em toda a região, resulta na perda de disponibilidade até que a região fique on-line novamente. No entanto, isso não resulta em perda de dados. Uma falha regional grave, por exemplo, caso um desastre destrua toda a região, poderá resultar na perda de dados armazenados nessa região. O BigQuery não fornece automaticamente um backup ou uma réplica dos dados em outra região geográfica. É possível criar cópias do conjunto de dados entre regiões para aprimorar a estratégia de recuperação de desastres.

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 no evento extraordinariamente improvável e sem precedentes de perda física da região. Isso é válido para configurações de "regiões e multirregiões". Portanto, manter a durabilidade e a disponibilidade nesse cenário requer o planejamento do cliente. No caso de perda temporária, como uma interrupção de rede, considere a disponibilidade redundante se o SLA de 99,99% do BigQuery não for considerado suficiente.

Para evitar a perda de dados diante de uma perda regional destrutiva, é necessário fazer backup dos dados em outra localização geográfica. Por exemplo, é possível periodicamente exportar um snapshot dos seus dados para o Google Cloud Storage em outra região geograficamente distinta. Isso pode ser feito conforme descrito no caso de uso de processamento de dados em lote.
No caso de multirregiões do BigQuery, evite fazer backup nas regiões dentro do escopo da multirregião. Por exemplo, não faça backup dos dados nos EUA para a região us-central1. A região e a multirregião podem compartilhar domínios de falha e ter um destino compartilhado em desastre. Em vez disso, faça backup dos dados em uma região fora dos EUA, como northamerica-northeast1. Se os requisitos de residência de dados exigirem que os backups sejam armazenados nos EUA, é melhor desativar o pareamento de duas regiões, como us-central1 e us-east1.

Para evitar a indisponibilidade estendida, é necessário que os dados sejam replicados e os slots sejam provisionados em dois locais geograficamente separados do BigQuery. Assim como antes, evite misturar regiões e multirregiões, já que elas podem ter compartilhado o destino em um desastre.

A arquitetura mais confiável para uma configuração redundante da região é executar a quente-quente, também conhecido como ativo-ativo. Isso significa que a carga de trabalho é executada em paralelo na região principal e secundária. Embora ela seja mais cara, essa região garante a verificação contínua e funcionará se for preciso fazer failover para ela. Se a disponibilidade durante uma interrupção regional não for um problema, faça backup de dados em outra região para garantir a durabilidade.

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 esse recurso, é possível consultar dados de qualquer ponto nos últimos sete dias. Isso permite a restauração de todos os 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 tabelas de snapshots. Com esse recurso, é possível fazer backup explicitamente de dados na mesma região por mais de sete dias na janela de viagem. Um snapshot é simplesmente uma operação de metadados e não resulta em nenhum byte de armazenamento extra. Isso pode aumentar a proteção contra exclusão acidental, mas não aumenta a durabilidade dos dados.

Caso de uso: análise em tempo real

Nesse caso de uso, os dados de streaming estão sendo ingeridos continuamente dos registros de endpoints no BigQuery. Proteger contra indisponibilidade estendida do BigQuery para toda a região requer replicar continuamente dados e slots de provisionamento em uma região diferente. Como a arquitetura é resiliente à indisponibilidade do BigQuery devido ao uso do Pub/Sub e do Dataflow no caminho de ingestão, esse alto nível de redundância provavelmente gerará gastos desnecessários.

Supondo que o usuário tenha configurado os dados do BigQuery em us-east4 para serem exportados todas as noites usando jobs de exportação para o Cloud Storage na classe Archive Storage em us-central1. Isso proporciona um backup durável em caso de perda de dados catastrófica na região us-east4. Nesse caso, o objetivo de ponto de recuperação (RPO) é de 24 horas, já que o último backup exportado pode ter até 24 horas de idade no pior dos casos. O objetivo de tempo de recuperação (RTO) é, potencialmente, dias, porque os dados precisam ser restaurados do backup do Cloud Storage para o BigQuery em us-central1. Se o BigQuery for provisionado em uma região diferente de onde os backups são colocados, os dados precisarão ser transferidos para essa região primeiro. Observe também que, a menos que você tenha comprado slots redundantes na região de recuperação com antecedência, pode haver um atraso extra ao receber a capacidade necessária do BigQuery provisionada de acordo com a quantidade solicitada.

Caso de uso: processamento de dados em lote

Para esse caso de uso, é essencial para os negócios que um relatório diário seja concluído em um prazo fixo a ser enviado para um regulador. A implementação da redundância executando duas instâncias separadas de todo o pipeline de processamento provavelmente é um gasto necessário. 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 estendida de uma região ou até mesmo o evento improvável de perda permanente de região.

Supondo que o relatório seja entregue exatamente uma vez, precisamos reconciliar o caso esperado de ambos os pipelines com êxito. Uma estratégia razoável é simplesmente escolher o resultado do pipeline terminar primeiro, por exemplo, notificando um tópico do Pub/Sub sobre a conclusão bem-sucedida. Como alternativa, substitua o resultado e reverta o objeto do Cloud Storage. Se o pipeline terminar de gravar dados corrompidos, será possível recuperar restaurando a versão gravada pelo pipeline com conclusão primeiro no Cloud Storage.

Tratamento de erros

Veja a seguir as práticas recomendadas para resolver erros que afetam a confiabilidade.

Repetir solicitações de API com falha

Os clientes do BigQuery, incluindo bibliotecas de cliente e ferramentas do parceiro, precisam usar a espera exponencial truncada ao emitir solicitações de API. Isso significa que, se um cliente receber um erro de sistema ou de cota, ele deverá repetir a solicitação até um determinado número de vezes, mas com um intervalo de espera aleatório e crescente.

O uso desse método de novas tentativas torna seu aplicativo muito mais robusto contra erros. Mesmo sob condições operacionais normais, a expectativa é de que uma entre dez mil 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 estratégia de espera exponencial poderá mitigar todos os casos, exceto os mais graves.

Se você encontrar um cenário em que uma solicitação falha persistentemente com um erro 5XX, encaminhe-a para o suporte do Google Cloud. Não deixe de comunicar claramente o impacto da falha nos seus negócios para que o problema seja avaliado corretamente. Por outro lado, se uma solicitação persistentemente falhar com um erro 4XX, o problema deverá ser resolvido com alterações no aplicativo. Leia 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. Por exemplo:

Faça uma solicitação ao BigQuery.
Se a solicitação falhar, aguarde 1 + random_number_milliseconds segundos e tente novamente.
Se a solicitação falhar, aguarde 2 + random_number_milliseconds segundos e tente novamente.
Se a solicitação falhar, aguarde 4 + random_number_milliseconds segundos e tente novamente.
E assim por diante, até um tempo maximum_backoff.
Continue aguardando e tente novamente até um número máximo de tentativas, mas não aumente o período de espera entre elas.

Observações:

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 e todos tentam novamente simultaneamente, enviando solicitações em ondas sincronizadas. O valor de random_number_milliseconds é recalculado 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. Em algum momento, os clientes são impedidos de tentar novamente infinitas vezes.

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 a semântica de inserção exatamente uma vez for importante para o aplicativo, há outras considerações em relação à inserção de jobs. A forma de atingir no máximo uma vez a semântica depende do WriteDisposition especificado. A disposição de gravação informa ao BigQuery o que ele precisa fazer ao encontrar dados atuais em uma tabela: falhar, substituir ou anexar.

Com uma disposição WRITE_EMPTY ou WRITE_TRUNCATE, isso é conseguido facilmente apenas com a nova tentativa de inserção ou execução do job com falha. Isso ocorre porque todas as linhas ingeridas por um job são gravadas atomicamente na tabela.

Com uma disposição WRITE_APPEND, o cliente precisa especificar o ID do job para se proteger contra novas tentativas de anexação dos mesmos dados novamente. Isso funciona porque o BigQuery rejeita solicitações de criação de jobs que tentam usar um ID de um job anterior. Isso alcança a semântica no máximo uma vez para qualquer ID de job. Para alcançar exatamente uma vez, use um novo ID de job previsível depois de confirmar com o BigQuery que todas as tentativas anteriores falharam.

Em alguns casos, o cliente da API ou o cliente HTTP pode não receber a confirmação de que o job foi inserido, devido a problemas transitórios ou interrupções da rede. Quando a inserção for repetida, essa solicitação vai falhar com status=ALREADY_EXISTS (code=409 e reason="duplicate"). O status do job atual pode ser recuperado com uma chamada para jobs.get. Depois que o status do job atual é retrieved, o autor da chamada pode determinar se um novo job com um novo ID do job precisa ser criado.

Casos de uso e requisitos de confiabilidade

O BigQuery pode ser um componente essencial de várias arquiteturas. Dependendo do caso de uso e da arquitetura implantada, vários requisitos de disponibilidade, desempenho ou outros requisitos de confiabilidade talvez precisem ser atendidos. Para a finalidade deste guia, vamos selecionar dois casos de uso e arquiteturas principais para discutir em detalhes.

Análise em tempo real

O primeiro exemplo é um pipeline de processamento de dados de eventos. Neste exemplo, os eventos de registro dos endpoints são ingeridos usando o Pub/Sub. A partir daí, um pipeline do Dataflow de streaming realiza algumas operações nos dados antes de gravá-los no BigQuery usando a API Storage Write. Os dados são usados para consultas ad-hoc, por exemplo, para recriar sequências de eventos que podem ter resultado em resultados de endpoint específicos e para alimentar painéis quase em tempo real para permitir a detecção de tendências e padrões nos dados pela visualização.

Neste exemplo, precisamos considerar vários aspectos da confiabilidade. Como os requisitos de atualização de dados completos são bastante altos, a latência do processo de ingestão é fundamental. Depois que os dados são gravados no BigQuery, a confiabilidade é percebida como a capacidade de os usuários emitirem consultas ad-hoc com latência consistente e previsível, além de garantir que os painéis que usam os dados reflitam as informações absolutas mais recentes disponíveis.

Processamento de dados em lote

O segundo exemplo é uma arquitetura de processamento em lote com base na 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 será considerado suficientemente rápido.

Os dados precisam ser disponibilizados no BigQuery e associados a outras fontes de dados para painéis, análises e, por fim, geração de um relatório em PDF. Ter esses relatórios em tempo hábil e sem erros é um requisito essencial para os negócios. Desse modo, é fundamental garantir a confiabilidade da ingestão de dados e produzir o relatório corretamente e em um período consistente para cumprir os prazos exigidos.