Automação escalonável de backup do BigQuery

Last reviewed 2024-09-17 UTC

Essa arquitetura fornece uma estrutura e uma implantação de referência para ajudar você a desenvolver sua estratégia de backup do BigQuery. Essa estrutura recomendada e a automação dela podem ajudar sua organização a fazer o seguinte:

  • Adira aos objetivos de recuperação de desastres da sua organização.
  • Recuperar dados perdidos devido a erros humanos.
  • Cumpra as regulamentações.
  • Melhorar a eficiência operacional.

O escopo dos dados do BigQuery pode incluir (ou excluir) pastas, projetos, conjuntos de dados e tabelas. Esta arquitetura recomendada mostra como automatizar as operações recorrentes de backup em grande escala. É possível usar dois métodos de backup para cada tabela: snapshots do BigQuery e exportações do BigQuery para o Cloud Storage.

Este documento é destinado a arquitetos de nuvem, engenheiros e diretores de governança de dados que querem definir e automatizar políticas de dados nas organizações.

Arquitetura

O diagrama a seguir mostra a arquitetura de backup automatizado:

Arquitetura da solução de backup automatizado.

O fluxo de trabalho mostrado no diagrama anterior inclui as seguintes fases:

  1. O Cloud Scheduler aciona uma execução para o serviço de despachante por uma mensagem do Pub/Sub, que contém o escopo dos dados do BigQuery incluídos e excluídos. As execuções são programadas usando uma expressão cron.
  2. O serviço de despachante, que é criado no Cloud Run, usa a API BigQuery para listar as tabelas que estão dentro do escopo do BigQuery.
  3. O serviço de despachante envia uma solicitação para cada tabela ao serviço de configurador por uma mensagem do Pub/Sub.

  4. O serviço de configurador do Cloud Run calcula a política de backup da tabela com base em uma das seguintes opções definidas:

    1. A política no nível da tabela, que é definida pelos proprietários de dados.
    2. A política de substituição, que é definida pelo oficial de governança de dados, para tabelas que não têm políticas definidas.

    Para saber mais sobre as políticas de backup, consulte Políticas de backup.

  5. O serviço de configurador envia uma solicitação para cada tabela para o próximo serviço com base na política de backup computada.

  6. Dependendo do método de backup, um dos seguintes serviços personalizados do Cloud Run envia uma solicitação para a API BigQuery e executa o processo de backup:

    1. O serviço de snapshots do BigQuery faz backup da tabela como um snapshot.
    2. O serviço de exportações de dados faz backup da tabela como uma exportação de dados para o Cloud Storage.

  7. Quando o método de backup é uma exportação de dados de tabela, um coletor de registros do Cloud Logging detecta os eventos de conclusão dos jobs de exportação para permitir a execução assíncrona da próxima etapa.

  8. Depois que os serviços de backup concluem as operações, o Pub/Sub aciona o serviço de tag.

  9. Para cada tabela, o serviço de inclusão de tags registra os resultados dos serviços de backup e atualiza o estado do backup na camada de metadados do Cloud Storage.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos do Google Cloud:

  • BigQuery: um data warehouse corporativo que ajuda a gerenciar e analisar seus dados com recursos integrados, como análise geoespacial de machine learning e Business Intelligence.
  • Cloud Logging: um sistema de gerenciamento de registros em tempo real com armazenamento, pesquisa, análise e alertas.
  • Pub/Sub: um serviço de mensagens assíncrono e escalonável que separa os serviços que produzem mensagens daqueles que processam essas mensagens.
  • Cloud Run: uma plataforma de computação sem servidor que permite executar contêineres diretamente na infraestrutura escalonável do Google.
  • Cloud Storage: um armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e fora do Google Cloud e são replicados entre locais para redundância.
  • Cloud Scheduler: um programador de cron jobs totalmente gerenciado e de nível empresarial que permite configurar unidades de trabalho programadas para serem executadas em horários definidos ou intervalos regulares.
  • Um banco de dados: NoSQL altamente escalonável, para seus aplicativos da Web e dispositivos móveis.

Casos de uso

Esta seção apresenta exemplos de casos de uso em que é possível usar essa arquitetura.

Automação de backup

Por exemplo, sua empresa pode operar em um setor regulamentado e usar o BigQuery como o data warehouse principal. Mesmo quando sua empresa segue as práticas recomendadas em desenvolvimento de software, revisão de código e engenharia de lançamento, ainda há um risco de perda ou corrupção de dados devido a erros humanos. Em um setor regulamentado, é necessário minimizar esse risco o máximo possível.

Confira alguns exemplos desses erros humanos:

  • Exclusão acidental de tabelas.
  • Corrupção de dados devido a uma lógica incorreta do pipeline de dados.

Esses tipos de erros humanos geralmente podem ser resolvidos com o recurso de viagem de tempo, que permite recuperar dados de até sete dias atrás. Além disso, o BigQuery também oferece um período de segurança contra falhas, em que os dados excluídos são retidos no armazenamento por mais sete dias após a janela de viagem no tempo. Esses dados estão disponíveis para recuperação em caso de emergência pelo Cloud Customer Care. No entanto, se a empresa não descobrir e corrigir esses erros dentro desse período combinado, os dados excluídos não poderão mais ser recuperados do último estado estável.

Para evitar isso, recomendamos que você execute backups regulares de todas as tabelas do BigQuery que não podem ser reconstruídas a partir de dados de origem (por exemplo, registros históricos ou KPIs com lógica de negócios em evolução).

Sua empresa pode usar scripts básicos para fazer backup de dezenas de tabelas. No entanto, se você precisa fazer backup regularmente de centenas ou milhares de tabelas em toda a organização, é necessário ter uma solução de automação escalonável que possa fazer o seguinte:

  • Processar diferentes limites de APIs do Google Cloud.
  • Ofereça um framework padronizado para definir políticas de backup.
  • Ofereça recursos de transparência e monitoramento para as operações de backup.

Políticas de backup

Sua empresa também pode exigir que as políticas de backup sejam definidas pelos seguintes grupos de pessoas:

  • Proprietários de dados, que conhecem melhor as tabelas e podem definir as políticas de backup no nível da tabela adequadas.
  • Equipe de governança de dados, que garante que uma política de substituição esteja em vigor para cobrir todas as tabelas que não têm uma política no nível da tabela. A política de substituição garante que determinados conjuntos de dados, projetos e pastas sejam armazenados em backup para obedecer às regulamentações de retenção de dados da sua empresa.

Na implantação desta arquitetura de referência, há duas maneiras de definir as políticas de backup para tabelas, e elas podem ser usadas juntas:

  • Configuração do proprietário de dados (descentralizada): uma política de backup no nível da tabela, que é anexada manualmente a uma tabela.

    • O proprietário de dados define um arquivo JSON no nível da tabela que é armazenado em um bucket comum.
    • As políticas manuais têm precedência sobre as políticas de substituição quando a solução determina a política de backup de uma tabela.
    • Para detalhes sobre a implantação, consulte Definir políticas de backup no nível da tabela.

  • Configuração padrão da organização (centralizada): uma política de fallback, que se aplica apenas a tabelas que não têm políticas anexadas manualmente.

    • Uma equipe de governança de dados define um arquivo JSON central no Terraform como parte da solução.
    • A política de fallback oferece estratégias de backup padrão nos níveis de pasta, projeto, conjunto de dados e tabela.
    • Para saber mais sobre a implantação, consulte Definir políticas de backup substituto.

Backup e replicação

Um processo de backup faz uma cópia dos dados da tabela em um determinado momento, para que eles possam ser restaurados caso sejam perdidos ou corrompidos. Os backups podem ser executados como uma ocorrência única ou recorrente (por uma consulta ou um fluxo de trabalho programado). No BigQuery, os backups pontuais podem ser feitos com snapshots. É possível usar snapshots para manter cópias dos dados além do período de sete dias de viagem no tempo no mesmo local de armazenamento dos dados de origem. Os snapshots do BigQuery são particularmente úteis para recuperar dados após erros humanos que levam à perda ou corrupção de dados, em vez de recuperar falhas regionais. O BigQuery oferece um objetivo de nível de serviço (SLO) de 99,9% a 99,99%, dependendo da edição.

Por outro lado, a replicação é o processo contínuo de cópia de mudanças do banco de dados para um banco de dados secundário (ou réplica) em um local diferente. No BigQuery, a replicação entre regiões pode ajudar a fornecer redundância geográfica criando cópias de leitura somente dos dados em regiões secundárias do Google Cloud, que são diferentes da região de dados de origem. No entanto, a replicação entre regiões do BigQuery não é destinada ao uso como um plano de recuperação de desastres para cenários de interrupção total da região. Para resiliência contra desastres regionais, use a recuperação de desastres gerenciada do BigQuery.

A replicação entre regiões do BigQuery fornece uma cópia de leitura somente de dados sincronizada em uma região próxima aos consumidores de dados. Essas cópias de dados permitem combinações colcoadas e evitam tráfego e custos entre regiões. No entanto, em casos de corrupção de dados devido a erro humano, a replicação por si só não pode ajudar na recuperação, porque os dados corrompidos são copiados automaticamente para a réplica. Nesses casos, os backups de ponto no tempo (snapshots) são uma opção melhor.

A tabela a seguir mostra uma comparação resumida dos métodos de backup e replicação:

Método Frequência Local de armazenamento Casos de uso Custos
Backup

(exportação de snapshots ou do Cloud Storage)		 Único ou recorrente Igual aos dados da tabela de origem Restaurar dados originais, além do período de viagem no tempo Os snapshots geram custos de armazenamento apenas para as mudanças de dados no snapshot.

As exportações podem gerar custos de armazenamento padrão.

Consulte Otimização de custos.
Replicação entre regiões Continuamente Remoto Criar uma réplica em outra região

Migrações únicas entre regiões		 Geração de custos de armazenamento de dados na réplica

Geração de custos de replicação de dados

Considerações sobre o design

Esta seção fornece orientações para você considerar ao usar essa arquitetura de referência para desenvolver uma topologia que atenda aos seus requisitos específicos de segurança, confiabilidade, otimização de custos, eficiência operacional e desempenho.

segurança, privacidade e conformidade

A implantação incorpora as seguintes medidas de segurança no design e na implementação:

  • A configuração de entrada de rede do Cloud Run aceita apenas tráfego interno para restringir o acesso pela Internet. Ele também permite que apenas usuários autenticados e contas de serviço chamem os serviços.
  • Cada serviço do Cloud Run e assinatura do Pub/Sub usa uma conta de serviço separada, que tem apenas as permissões necessárias atribuídas. Isso mitiga os riscos associados ao uso de uma conta de serviço para o sistema e segue o princípio do menor privilégio.

Por motivos de privacidade, a solução não coleta nem processa informações de identificação pessoal (PII). No entanto, se as tabelas de origem tiverem exposto PII, os backups dessas tabelas também vão incluir esses dados expostos. O proprietário dos dados de origem é responsável por proteger qualquer PII nas tabelas de origem. Por exemplo, aplicando a segurança no nível da coluna, o mascaramento de dados ou a redução de dados. Os backups só são seguros quando os dados de origem também são. Outra abordagem é garantir que projetos, conjuntos de dados ou buckets que armazenam dados de backup com PII expostos tenham as políticas de IAM necessárias que restringem o acesso apenas a usuários autorizados.

Como uma solução de uso geral, a implantação de referência não precisa estar em conformidade com os requisitos específicos de um setor específico.

Confiabilidade

Esta seção descreve os recursos e as considerações de design para confiabilidade.

Mitigação de falhas com granularidade

Para fazer backups de milhares de tabelas, é provável que você atinja os limites de API dos produtos do Google Cloud subjacentes (por exemplo, os limites de operação de snapshot e exportação de cada projeto). No entanto, se o backup de uma tabela falhar devido a uma configuração incorreta ou outros problemas temporários, isso não afetará a execução geral e a capacidade de fazer backup de outras tabelas.

Para mitigar possíveis falhas, a implantação de referência separa as etapas de processamento usando serviços granulares do Cloud Run e os conectando pelo Pub/Sub. Se uma solicitação de backup de tabela falhar na etapa final do serviço de tag, o Pub/Sub vai tentar novamente apenas essa etapa e não todo o processo.

A divisão do fluxo em vários serviços do Cloud Run, em vez de vários endpoints hospedados em um serviço do Cloud Run, ajuda a fornecer controle granular de cada configuração de serviço. O nível de configuração depende dos recursos do serviço e das APIs com que ele se comunica. Por exemplo, o serviço de despachante é executado uma vez por execução, mas exige uma quantidade considerável de tempo para listar todas as tabelas no escopo de backup do BigQuery. Portanto, o serviço do despachante exige configurações de tempo limite e memória mais altas. No entanto, o serviço do Cloud Run para snapshots do BigQuery é executado uma vez por tabela em uma única execução e é concluído em menos tempo do que o serviço de despachante. Portanto, o serviço do Cloud Run requer um conjunto diferente de configurações no nível do serviço.

Consistência de dados

A consistência dos dados nas tabelas e visualizações é crucial para manter uma estratégia de backup confiável. Como os dados são atualizados e modificados continuamente, os backups feitos em momentos diferentes podem capturar estados diferentes do conjunto de dados. Esses backups em estados diferentes podem levar a inconsistências ao restaurar dados, principalmente para tabelas que pertencem ao mesmo conjunto de dados funcional. Por exemplo, restaurar uma tabela de vendas para um ponto no tempo diferente da tabela de inventário correspondente pode criar uma incompatibilidade no estoque disponível. Da mesma forma, as visualizações de banco de dados que agregam dados de várias tabelas podem ser particularmente sensíveis a inconsistências. Restaurar essas visualizações sem garantir que as tabelas subjacentes estejam em um estado consistente pode levar a resultados imprecisos ou enganosos. Portanto, ao projetar as políticas e frequências de backup do BigQuery, é fundamental considerar essa consistência e garantir que os dados restaurados reflitam com precisão o estado real do conjunto de dados em um determinado momento.

Por exemplo, na implantação desta arquitetura de referência, a consistência dos dados é controlada pelas duas configurações a seguir nas políticas de backup. Essas configurações calculam o tempo exato do snapshot da tabela usando a viagem no tempo, sem necessariamente fazer backup de todas as tabelas ao mesmo tempo.

  • backup_cron: controla a frequência com que uma tabela é armazenada em backup. O carimbo de data/hora de início de uma execução é usado como ponto de referência para o cálculo de viagem no tempo de todas as tabelas que são armazenadas em backup nessa execução.
  • backup_time_travel_offset_days: controla quantos dias no passado precisam ser subtraídos do ponto de referência no tempo (início da execução) para calcular a versão exata da viagem no tempo da tabela.

Restauração automática de backup

Embora essa arquitetura de referência se concentre na automação de backup em grande escala, você também pode restaurar esses backups de forma automatizada. Essa automação adicional pode oferecer benefícios semelhantes aos da automação de backup, incluindo maior eficiência e velocidade de recuperação, com menos tempo de inatividade. Como a solução rastreia todos os parâmetros e resultados de backup pelo serviço de inclusão de tags, é possível desenvolver uma arquitetura semelhante para aplicar as operações de restauração em escala.

Por exemplo, é possível criar uma solução com base em um acionador sob demanda que envia um escopo de dados do BigQuery para um serviço de despachante, que envia uma solicitação por tabela para um serviço de configurador. O serviço de configuração pode buscar o histórico de backup que você quer para uma tabela específica. O serviço de configuração pode transmiti-lo a um serviço de restauração de instantâneos do BigQuery ou do serviço de restauração do Cloud Storage para aplicar a operação de restauração. Por fim, um serviço de inclusão de tags pode armazenar os resultados dessas operações em um repositório de estados. Ao fazer isso, o framework de restauração automática pode se beneficiar dos mesmos objetivos de design do framework de backup detalhados neste documento.

Otimização de custos

O framework dessa arquitetura fornece políticas de backup que definem os seguintes parâmetros para a otimização geral de custos:

  • Método de backup: o framework oferece os dois métodos de backup a seguir:
    • Snapshots do BigQuery, que geram custos de armazenamento com base em dados atualizados e excluídos em comparação com a tabela base. Portanto, os snapshots são mais econômicos para tabelas somente de adição ou com atualizações limitadas.
    • Exportações do BigQuery para o Cloud Storage, que geram cobranças de armazenamento padrão. No entanto, para tabelas grandes que seguem uma abordagem de truncamento e carregamento, é mais econômico fazer backup delas como exportações em classes de armazenamento menos caras.
  • Expiração de snapshots: o time to live (TTL) é definido para um único snapshot de tabela, para evitar custos de armazenamento indefinidos. Os custos de armazenamento podem aumentar com o tempo se as tabelas não tiverem expiração.

Eficiência operacional

Esta seção descreve recursos e considerações para a eficiência operacional.

Políticas de backup granulares e escalonáveis

Um dos objetivos desse framework é a eficiência operacional, aumentando a produção e mantendo a entrada de negócios relativamente baixa e gerenciável. Por exemplo, a saída é um grande número de tabelas regularmente salvas em backup, enquanto a entrada é um pequeno número de políticas e configurações de backup mantidas.

Além de permitir políticas de backup no nível da tabela, o framework também permite políticas no nível do conjunto de dados, do projeto, da pasta e global. Isso significa que, com algumas configurações em níveis mais altos (por exemplo, no nível da pasta ou do projeto), centenas ou milhares de tabelas podem ser salvas em backup regularmente e em grande escala.

Observabilidade

Com uma estrutura de automação, é fundamental entender os status dos processos. Por exemplo, você pode encontrar as informações para as seguintes consultas comuns:

  • A política de backup usada pelo sistema para cada tabela.
  • O histórico de backup e os locais de backup de cada tabela.
  • O status geral de uma única execução (o número de tabelas processadas e com falhas).
  • Os erros fatais que ocorreram em uma única execução e os componentes ou etapas do processo em que eles ocorreram.

Para fornecer essas informações, a implantação grava logs estruturados no Cloud Logging em cada etapa de execução que usa um serviço do Cloud Run. Os registros incluem entrada, saída e erros, além de outros pontos de controle de progresso. Um coletor de registros encaminha esses registros para uma tabela do BigQuery. É possível executar várias consultas para monitorar execuções e gerar relatórios para casos de uso comuns de observabilidade. Para mais informações sobre registros e consultas no BigQuery, consulte Conferir registros roteados para o BigQuery.

Otimização de desempenho

Para processar milhares de tabelas em cada execução, a solução processa solicitações de backup em paralelo. O serviço de despachante lista todas as tabelas incluídas no escopo de backup do BigQuery e gera uma solicitação de backup por tabela em cada execução. Isso permite que o aplicativo processe milhares de solicitações e tabelas em paralelo, não sequencialmente.

Algumas dessas solicitações podem falhar inicialmente por motivos temporários, como atingir os limites das APIs do Google Cloud ou ter problemas de rede. Até que as solicitações sejam concluídas, o Pub/Sub as repete automaticamente com a política de repetição de espera exponencial. Se houver erros fatais, como destinos de backup inválidos ou permissões ausentes, eles serão registrados, e a execução dessa solicitação de tabela específica será encerrada sem afetar a execução geral.

Limites

As cotas e os limites a seguir se aplicam a essa arquitetura.

Para instantâneos de tabela, o seguinte se aplica a cada projeto de operação de backup especificado:

  • Um projeto pode executar até 100 jobs de snapshots de tabela simultâneos.
  • Um projeto pode executar até 50.000 jobs de snapshots de tabela por dia.
  • Um projeto pode executar até 50 jobs de snapshot de tabela por tabela por dia.

Para mais detalhes, consulte Snapshots de tabelas.

Para jobs de exportação (exportações para o Cloud Storage), o seguinte se aplica:

  • É possível exportar até 50 TB de dados por dia de um projeto gratuitamente usando o pool de slots compartilhado.
  • Um projeto pode executar até 100.000 exportações por dia. Para estender esse limite, crie uma reserva de slot.

Para mais informações sobre como estender esses limites, consulte Jobs de exportação.

Em relação aos limites de simultaneidade, essa arquitetura usa o Pub/Sub para tentar novamente automaticamente as solicitações que falham devido a esses limites, até que sejam atendidas pela API. No entanto, para outros limites no número de operações por projeto por dia, eles podem ser mitigados por uma solicitação de aumento de cota ou pela distribuição das operações de backup (snapshots ou exportações) em vários projetos. Para distribuir as operações entre projetos, configure as políticas de backup conforme descrito nas seções de implantação a seguir.

Implantação

Para implantar essa arquitetura, consulte Implantar a automação de backup escalonável do BigQuery.

A seguir

Colaboradores

Autor: Karim Wadie | Engenheiro estratégico do Cloud

Outros colaboradores: