Compreenda a fiabilidade

Este documento explica as funcionalidades de fiabilidade do BigQuery, como a disponibilidade, a durabilidade, a consistência dos dados, a consistência do desempenho, a recuperação de dados e uma revisão das considerações sobre o processamento de erros.

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

• Determine se o BigQuery é a ferramenta certa para o seu trabalho.
• Compreenda as dimensões da fiabilidade do BigQuery.
• Identifique requisitos de fiabilidade específicos para exemplos de utilização específicos.

Selecione o BigQuery

O BigQuery é um armazém de dados empresarial totalmente gerido criado para armazenar e analisar grandes conjuntos de dados. Oferece uma forma de carregar, armazenar, ler e consultar megabytes a petabytes de dados com um desempenho consistente sem ter de gerir nenhuma das infraestruturas subjacentes. Devido à sua potência e desempenho, o BigQuery é adequado para utilização numa variedade de soluções. Alguns destes são documentados detalhadamente como padrões de referência.

Geralmente, o BigQuery é muito adequado para cargas de trabalho em que são carregadas e analisadas grandes quantidades de dados. Em concreto, pode ser implementado de forma eficaz para exemplos de utilização, como estatísticas de dados preditivos e em tempo real (com carregamento por streaming e BigQuery ML), deteção de anomalias e outros exemplos de utilização em que a análise de grandes volumes de dados com um desempenho previsível é fundamental. No entanto, se procura uma base de dados para suportar aplicações no estilo de processamento de transações online (OLTP), deve considerar outros Google Cloud serviços, como o Spanner, o Cloud SQL ou o Bigtable, que podem ser mais adequados para estes exemplos de utilização.

Dimensões da fiabilidade no BigQuery

Disponibilidade

A disponibilidade define a capacidade do utilizador de ler dados do BigQuery ou escrever dados no mesmo. O BigQuery foi criado para tornar ambos os aspetos altamente disponíveis com um SLA de 99,99%. Existem dois componentes envolvidos em ambas as operações:

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

A fiabilidade do serviço é uma função da API BigQuery específica que está a ser usada para obter os dados. A disponibilidade de recursos de computação depende da capacidade disponível para o utilizador no momento em que a consulta é executada. Consulte o artigo Compreender os slots para mais informações acerca da unidade fundamental de computação do BigQuery e da economia de recursos de slots resultante.

Durabilidade

A durabilidade é abordada no capítulo Implementar SLOs do livro de EFS e é descrita como a "proporção de dados que podem ser lidos com êxito".

Consistência dos dados

A consistência define as expetativas que os utilizadores têm sobre a forma como os dados podem ser consultados assim que são escritos ou modificados. Um aspeto da consistência dos dados é garantir a semântica "exatamente uma vez" para a ingestão de dados. Para mais informações, consulte o artigo Volte a tentar inserções de trabalhos falhadas.

Consistência do desempenho

Em geral, o desempenho pode ser expresso em duas dimensões. A latência é uma medida do tempo de execução de operações de obtenção de dados longas, como consultas. A taxa de débito é uma medida da quantidade de dados que o BigQuery pode processar durante um período específico. Devido ao design de vários inquilinos e horizontalmente escalável do BigQuery, a respetiva taxa de transferência pode ser dimensionada até tamanhos de dados arbitrários. A importância relativa da latência e da taxa de transferência é determinada pelo exemplo de utilização específico.

Recuperação de dados

Existem duas formas de medir a capacidade de recuperar dados após uma indisponibilidade:

• Objetivo de tempo de recuperação (OTR). Durante quanto tempo os dados podem estar indisponíveis após um incidente.
• Objetivo de ponto de recuperação (OPR). Que percentagem dos dados recolhidos antes do incidente pode ser aceitavelmente perdida.

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

Planeamento de desastres

Embora o termo "desastre" possa evocar imagens de desastres naturais, o âmbito desta secção aborda falhas específicas, desde a perda de uma máquina individual até à perda catastrófica de uma região. Os primeiros são ocorrências diárias que o BigQuery processa automaticamente, enquanto os últimos são algo que os clientes podem ter de conceber a respetiva arquitetura para processar, se necessário. É importante compreender em que âmbito o planeamento de desastres se cruza com a responsabilidade do cliente.

O BigQuery oferece um SLA de tempo de atividade de 99,99% líder na indústria. Isto é possível graças à arquitetura regional do BigQuery que escreve dados em duas zonas diferentes e aprovisiona capacidade de computação redundante. É importante ter em atenção que o SLA do BigQuery é o mesmo para regiões, por exemplo, us-central1, e multirregiões, por exemplo, US.

Processamento automático de cenários

Uma vez que o BigQuery é um serviço regional, é da responsabilidade do BigQuery processar automaticamente a perda de uma máquina ou até mesmo de uma zona inteira. O facto de o BigQuery ser criado com base em zonas é abstraído dos utilizadores.

Perda de uma máquina

As falhas de máquinas são uma ocorrência diária à escala em que a Google opera. O BigQuery foi concebido para processar automaticamente falhas de máquinas sem qualquer impacto na zona que as contém.
Nos bastidores, a execução de uma consulta é dividida em pequenas tarefas que podem ser enviadas em paralelo para várias máquinas. A perda ou a degradação súbita do desempenho da máquina é processada automaticamente através da reexpedição do trabalho para uma máquina diferente. Esta abordagem é fundamental para reduzir a latência de cauda.

O BigQuery usa a codificação Reed-Solomon para armazenar de forma eficiente e duradoura uma cópia zonal dos seus dados. Na altamente improvável eventualidade de várias falhas de máquinas causarem a perda de uma cópia zonal, os dados também são armazenados da mesma forma, pelo menos, noutra zona. Nesses casos, o BigQuery deteta o problema e faz uma nova cópia zonal dos dados para restaurar a redundância.

Perda de uma zona

A disponibilidade subjacente de recursos de computação numa determinada zona não é suficiente para cumprir o SLA de tempo de atividade de 99,99% do BigQuery. Assim, o BigQuery oferece redundância zonal automática para os dados e os slots de computação. Embora as interrupções zonais de curta duração não sejam comuns, acontecem. No entanto, a automatização do BigQuery transfere as consultas para outra zona no prazo de um ou dois minutos após qualquer interrupção grave. As consultas já em curso podem não ser recuperadas imediatamente, mas as consultas emitidas recentemente vão ser. Isto manifesta-se como consultas em curso que demoram muito tempo a terminar, enquanto as consultas emitidas recentemente são concluídas rapidamente.

Mesmo que uma zona fique indisponível durante um período mais longo, não ocorre perda de dados, uma vez que o BigQuery escreve dados de forma síncrona em duas zonas. Assim, mesmo perante uma perda zonal, os clientes não vão sofrer uma interrupção do serviço.

Tipos de falhas

Existem dois tipos de falhas: falhas temporárias e falhas permanentes.

Uma falha parcial é uma deficiência operacional em que o hardware não é destruído. Os exemplos incluem falha de energia, partição de rede ou falha de uma máquina. Em geral, o BigQuery nunca deve perder dados em caso de falha temporária.

A falha grave é uma deficiência operacional em que o hardware é destruído. As falhas graves são mais graves do que as falhas ligeiras. Os exemplos de falhas graves incluem danos causados por cheias, ataques terroristas, terramotos e furacões.

Disponibilidade e durabilidade

Quando cria um conjunto de dados do BigQuery, seleciona uma localização onde armazenar os seus dados. Esta localização é uma das seguintes:

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

Em qualquer dos casos, o BigQuery armazena automaticamente cópias dos seus dados em duas Google Cloud zonas diferentes numa única região na localização selecionada.

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

Nota: a seleção de uma localização em várias regiões não oferece replicação entre regiões nem redundância regional. Os dados são armazenados numa única região na localização geográfica.

Em caso de falha ao nível da máquina, o BigQuery continua a ser executado com um atraso de, no máximo, alguns milissegundos. Todas as consultas em execução continuam a ser processadas. No caso de uma falha zonal parcial ou total, não é esperada perda de dados. No entanto, as consultas em execução podem falhar e ter de ser reenviadas. Uma falha zonal simples, como a que resulta de uma falha de energia, um transformador destruído ou uma partição de rede, é um caminho bem testado e é mitigada automaticamente em poucos minutos.

Uma falha regional não crítica, como uma perda de conetividade de rede ao nível de uma região, resulta na perda de disponibilidade até que a região seja reposta online, mas não resulta na perda de dados. Uma falha regional grave, por exemplo, se um desastre destruir toda a região, pode resultar na perda de dados armazenados nessa região. O BigQuery não fornece automaticamente uma cópia de segurança nem uma réplica dos seus dados noutra região geográfica. Pode criar cópias do conjunto de dados entre regiões para melhorar a sua estratégia de recuperação de desastres.

Para saber mais acerca das localizações dos conjuntos de dados do BigQuery, consulte as Considerações sobre a localização.

Cenário: perda da região

O BigQuery não oferece durabilidade nem disponibilidade no caso extraordinariamente improvável e sem precedentes de perda física da região. Isto aplica-se às configurações de "regiões e multirregiões". Por conseguinte, a manutenção da durabilidade e da disponibilidade num cenário deste tipo requer planeamento por parte do cliente. No caso de perda temporária, como uma interrupção da rede, deve considerar a disponibilidade redundante se o SLA de 99,99% do BigQuery não for considerado suficiente.

Para evitar a perda de dados em caso de perda regional destrutiva, tem de fazer uma cópia de segurança dos dados noutra localização geográfica. Por exemplo, pode exportar periodicamente uma captura instantânea dos seus dados para o Google Cloud Storage noutra região geograficamente distinta. Isto pode ser feito conforme descrito no Exemplo de utilização do tratamento de dados em lote.
No caso das multirregiões do BigQuery, deve evitar fazer cópias de segurança para regiões no âmbito da multirregião. Por exemplo, não faça uma cópia de segurança dos seus dados nos EUA para a região us-central1. A região e a multirregião podem partilhar domínios de falhas e ter um destino comum em caso de desastre. Em alternativa, faça uma cópia de segurança dos seus dados numa região fora dos EUA, como northamerica-northeast1. Se os requisitos de residência de dados exigirem que as cópias de segurança sejam armazenadas nos EUA, é melhor associar duas regiões, como us-central1 e us-east1.

Para evitar uma indisponibilidade prolongada, tem de ter os dados replicados e os intervalos aprovisionados em duas localizações do BigQuery geograficamente separadas. Tal como acima, evite misturar regiões e várias regiões, uma vez que podem partilhar o mesmo destino num desastre.

A arquitetura mais fiável para uma configuração com redundância regional é a execução hot-hot, também denominada ativa-ativa. Isto significa que a sua carga de trabalho é executada em paralelo na região principal e secundária. Embora seja mais caro, isto garante que a região secundária recebe uma validação contínua e funciona se precisar de fazer failover para a mesma. Se a disponibilidade durante uma indisponibilidade regional for menos preocupante, a cópia de segurança dos dados noutra região garante a durabilidade.

Cenário: eliminação acidental ou corrupção de dados

Em virtude da arquitetura de controlo de simultaneidade de várias versões do BigQuery, o BigQuery suporta a viagem no tempo. Com esta funcionalidade, pode consultar dados de qualquer momento nos últimos sete dias. Isto permite a reposição self-service de quaisquer dados que tenham sido eliminados, modificados ou danificados por engano num período de 7 dias. A viagem no tempo funciona mesmo em tabelas que foram eliminadas.

O BigQuery também suporta a capacidade de criar instantâneos de tabelas. Com esta funcionalidade, pode fazer uma cópia de segurança explícita dos dados na mesma região durante mais tempo do que o período de 7 dias da funcionalidade de viagem no tempo. Uma captura instantânea é puramente uma operação de metadados e não resulta em bytes de armazenamento adicionais. Embora isto possa adicionar proteção contra a eliminação acidental, não aumenta a durabilidade dos dados.

Exemplo de utilização: análise em tempo real

Neste exemplo de utilização, os dados de streaming estão a ser carregados continuamente a partir dos registos de pontos finais para o BigQuery. A proteção contra a indisponibilidade prolongada do BigQuery para toda a região requer a replicação contínua de dados e o aprovisionamento de slots numa região diferente. Uma vez que a arquitetura é resiliente à indisponibilidade do BigQuery devido à utilização do Pub/Sub e do Dataflow no caminho de carregamento, este elevado nível de redundância provavelmente não compensa o custo.

Partindo do princípio de que o utilizador configurou os dados do BigQuery em us-east4 para serem exportados todas as noites através de tarefas de exportação para o Cloud Storage na classe de armazenamento de arquivo em us-central1. Isto oferece uma cópia de segurança duradoura em caso de perda de dados catastrófica em us-east4. Neste caso, o objetivo de ponto de recuperação (OPR) é de 24 horas, uma vez que a última cópia de segurança exportada pode ter até 24 horas no pior cenário. O objetivo de tempo de recuperação (OTR) é potencialmente de dias, uma vez que os dados têm de ser restaurados a partir da cópia de segurança do Cloud Storage para o BigQuery em us-central1. Se o BigQuery for aprovisionado numa região diferente daquela onde são colocados os backups, os dados têm de ser transferidos primeiro para esta região. Tenha também em atenção que, a menos que tenha comprado slots redundantes na região de recuperação antecipadamente, pode haver um atraso adicional no aprovisionamento da capacidade do BigQuery necessária consoante a quantidade pedida.

Exemplo de utilização: processamento de dados em lote

Para este exemplo de utilização, é fundamental para a empresa que um relatório diário seja concluído até um prazo fixo para ser enviado a um regulador. A implementação da redundância através da execução de duas instâncias separadas de todo o pipeline de processamento provavelmente compensa o custo. A utilização de duas regiões separadas, por exemplo, us-west1 e us-east4, oferece separação geográfica e dois domínios de falhas independentes em caso de indisponibilidade prolongada de uma região ou mesmo no caso improvável de perda permanente de uma região.

Partindo do princípio de que precisamos que o relatório seja entregue exatamente uma vez, temos de conciliar o caso esperado de ambas as pipelines terminarem com êxito. Uma estratégia razoável consiste simplesmente em escolher o resultado do pipeline que terminar primeiro, por exemplo, enviando uma notificação para um tópico do Pub/Sub quando a conclusão for bem-sucedida. Em alternativa, substitua o resultado e volte a criar uma versão do objeto do Cloud Storage. Se o pipeline que termina mais tarde escrever dados corrompidos, pode recuperar restaurando a versão escrita pelo pipeline que termina primeiro a partir do Cloud Storage.

Processamento de erros

Seguem-se as práticas recomendadas para resolver erros que afetam a fiabilidade.

Repita os pedidos de API com falha

Os clientes do BigQuery, incluindo bibliotecas cliente e ferramentas de parceiros, devem usar o recuo exponencial truncado ao emitir pedidos de API. Isto significa que, se um cliente receber um erro do sistema ou um erro de quota, deve tentar novamente o pedido até um determinado número de vezes, mas com um intervalo de recuo aleatório e crescente.

A utilização deste método de novas tentativas torna a sua aplicação muito mais robusta perante erros. Mesmo em condições normais de funcionamento, pode esperar que cerca de um em dez mil pedidos falhe, conforme descrito no contrato de nível de serviço de disponibilidade de 99,99% do BigQuery. Em condições anormais, esta taxa de erro pode aumentar, mas se os erros forem distribuídos aleatoriamente, a estratégia de recuo exponencial pode mitigar todos os casos, exceto os mais graves.

Se se deparar com um cenário em que um pedido falha persistentemente com um erro 5XX, deve encaminhar o problema para o Google Cloud apoio técnico. Certifique-se de que comunica claramente o impacto que a falha está a ter na sua empresa para que o problema possa ser triado corretamente. Por outro lado, se um pedido falhar persistentemente com um erro 4XX, o problema deve ser resolvido com alterações à sua aplicação. Leia a mensagem de erro para ver detalhes.

Exemplo de lógica de retirada exponencial

A lógica de retirada exponencial repete uma consulta ou um pedido aumentando o tempo de espera entre as repetições até um tempo de retirada máximo. Por exemplo:

1. Faça um pedido ao BigQuery.

2. Se o pedido falhar, aguarde 1 + random_number_milliseconds segundos e repita o pedido.

3. Se o pedido falhar, aguarde 2 + random_number_milliseconds segundos e repita o pedido.

4. Se o pedido falhar, aguarde 4 + random_number_milliseconds segundos e repita o pedido.

5. E assim sucessivamente, até (maximum_backoff) vezes.

6. Continue a aguardar e a tentar novamente até atingir um número máximo de tentativas, mas não aumente o período de espera entre tentativas.

Tenha em conta o seguinte:

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

• random_number_milliseconds é um número aleatório de milissegundos inferior ou igual a 1000. Esta aleatorização ajuda a evitar situações em que muitos clientes estão sincronizados e tentam novamente em simultâneo, enviando pedidos em ondas sincronizadas. O valor de random_number_milliseconds é recalculado após cada pedido de repetição.

• O intervalo de recuo máximo (maximum_backoff) é normalmente de 32 ou 64 segundos. O valor adequado para maximum_backoff depende do exemplo de utilização.

O cliente pode continuar a tentar novamente depois de atingir o tempo de recuo máximo. As novas tentativas após este ponto não precisam de continuar a aumentar o tempo de recuo. Por exemplo, se o cliente usar um tempo de recuo máximo de 64 segundos, depois de atingir este valor, o cliente pode continuar a tentar novamente a cada 64 segundos. Em algum momento, os clientes devem ser impedidos de repetir indefinidamente.

O tempo de espera entre novas tentativas e o número de novas tentativas dependem do seu exemplo de utilização e das condições da rede.

Repetir inserções de tarefas com falha

Se a semântica de inserção exatamente uma vez for importante para a sua aplicação, existem considerações adicionais no que diz respeito à inserção de tarefas. A forma de alcançar a semântica de, no máximo, uma vez depende da WriteDisposition que especificar. A disposição de escrita indica ao BigQuery o que deve fazer quando encontra dados existentes numa tabela: falhar, substituir ou acrescentar.

Com uma disposição WRITE_EMPTY ou WRITE_TRUNCATE, isto é conseguido através de uma nova tentativa de inserção ou execução de qualquer tarefa com falha. Isto acontece porque todas as linhas carregadas por uma tarefa são escritas de forma atómica na tabela.

Com uma disposição WRITE_APPEND, o cliente tem de especificar o ID da tarefa para se proteger contra uma nova tentativa de anexação dos mesmos dados uma segunda vez. Isto funciona porque o BigQuery rejeita pedidos de criação de tarefas que tentam usar um ID de uma tarefa anterior. Isto alcança a semântica no máximo uma vez para qualquer ID de tarefa específico. Em seguida, pode alcançar a execução exatamente uma vez repetindo a operação com um novo ID de tarefa 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 podem não receber a confirmação de que a tarefa foi inserida devido a problemas transitórios ou interrupções de rede. Quando a inserção é repetida, esse pedido falha com status=ALREADY_EXISTS (code=409 e reason="duplicate"). O estado da tarefa existente pode ser obtido com uma chamada para jobs.get. Depois de o estado da tarefa existente ser retrieved, o autor da chamada pode determinar se deve ser criada uma nova tarefa com um novo ID DA TAREFA.

Exemplos de utilização e requisitos de fiabilidade

O BigQuery pode ser um componente essencial de várias arquiteturas. Consoante o exemplo de utilização e a arquitetura implementada, podem ter de ser cumpridos vários requisitos de disponibilidade, desempenho ou outros requisitos de fiabilidade. Para os efeitos deste guia, vamos selecionar dois exemplos de utilização e arquiteturas principais para debater em detalhe.

Análise em tempo real

O primeiro exemplo é um pipeline de processamento de dados de eventos. Neste exemplo, os eventos de registo dos pontos finais são carregados através do Pub/Sub. A partir daí, um pipeline de streaming do Dataflow realiza algumas operações nos dados antes de os escrever no BigQuery através da API Storage Write. Os dados são, em seguida, usados para consultas ad hoc, por exemplo, para recriar sequências de eventos que podem ter resultado em resultados específicos dos pontos finais, e para alimentar painéis de controlo quase em tempo real, de modo a permitir a deteção de tendências e padrões nos dados através da visualização.

Este exemplo requer que considere vários aspetos da fiabilidade. Uma vez que os requisitos de atualização dos dados ponto a ponto são bastante elevados, a latência do processo de carregamento é fundamental. Assim que os dados são escritos no BigQuery, a fiabilidade é vista como a capacidade dos utilizadores de emitir consultas ad hoc com uma latência consistente e previsível, e garantir que os painéis de controlo que usam os dados refletem as informações mais recentes disponíveis.

Tratamento de dados em lote

O segundo exemplo é uma arquitetura de processamento em lote baseada na conformidade regulamentar no setor de serviços financeiros. Um requisito fundamental é enviar relatórios diários aos reguladores até um prazo fixo todas as noites. Desde que o processo em lote noturno que gera os relatórios seja concluído até este prazo, é considerado suficientemente rápido.

Os dados têm de ser disponibilizados no BigQuery e associados a outras origens de dados para a criação de painéis de controlo, a análise e, por último, a geração de um relatório em PDF. A receção destes relatórios atempadamente e sem erros é um requisito empresarial crítico. Como tal, é fundamental garantir a fiabilidade da ingestão de dados e a produção correta do relatório num período consistente para cumprir os prazos necessários.