Automatização de cópias de segurança do BigQuery escalável

Last reviewed 2024-09-17 UTC

Esta arquitetura fornece uma estrutura e uma implementação de referência para ajudar a desenvolver a sua estratégia de cópia de segurança do BigQuery. Esta estrutura recomendada e a respetiva automatização podem ajudar a sua organização a fazer o seguinte:

  • Aderir aos objetivos de recuperação de desastres da sua organização.
  • Recuperar dados perdidos devido a erros humanos.
  • Aja em conformidade com os regulamentos.
  • Melhorar a eficiência operacional.

O âmbito dos dados do BigQuery pode incluir (ou excluir) pastas, projetos, conjuntos de dados e tabelas. Esta arquitetura recomendada mostra como automatizar as operações de cópia de segurança recorrentes em grande escala. Pode usar dois métodos de cópia de segurança para cada tabela: instantâneos do BigQuery e exportações do BigQuery para o Cloud Storage.

Este documento destina-se a arquitetos, engenheiros e responsáveis de governação de dados na nuvem que pretendem definir e automatizar políticas de dados nas respetivas organizações.

Arquitetura

O diagrama seguinte mostra a arquitetura de cópia de segurança automática:

Arquitetura da solução de cópia de segurança automática.

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

  1. O Cloud Scheduler aciona uma execução para o serviço de expedição através de uma mensagem do Pub/Sub, que contém o âmbito dos dados do BigQuery incluídos e excluídos. As execuções são agendadas através de uma expressão cron.
  2. O serviço de expedição, que é criado no Cloud Run, usa a API BigQuery para listar as tabelas que estão no âmbito do BigQuery.
  3. O serviço de expedição envia um pedido para cada tabela ao serviço de configuração através de uma mensagem do Pub/Sub.

  4. O serviço de configuração do Cloud Run calcula a política de cópia de segurança da tabela a partir de uma das seguintes opções definidas:

    1. A política ao nível da tabela, que é definida pelos proprietários dos dados.
    2. A política alternativa, que é definida pelo responsável pela governação de dados, para tabelas que não têm políticas definidas.

    Para ver detalhes sobre as políticas de cópia de segurança, consulte o artigo Políticas de cópia de segurança.

  5. O serviço de configuração envia um pedido para cada tabela ao serviço seguinte, com base na política de cópia de segurança calculada.

  6. Consoante o método de cópia de segurança, um dos seguintes serviços personalizados do Cloud Run envia um pedido para a API BigQuery e executa o processo de cópia de segurança:

    1. O serviço de instantâneos do BigQuery faz uma cópia de segurança da tabela como um instantâneo.
    2. O serviço de exportações de dados faz uma cópia de segurança da tabela como uma exportação de dados para o Cloud Storage.

  7. Quando o método de cópia de segurança é uma exportação de dados de tabelas, um destinatário de registos do Cloud Logging ouve os eventos de conclusão de tarefas de exportação para permitir a execução assíncrona do passo seguinte.

  8. Depois de os serviços de cópia de segurança concluírem as respetivas operações, o Pub/Sub aciona o serviço de etiquetagem.

  9. Para cada tabela, o serviço de etiquetagem regista os resultados dos serviços de cópia de segurança e atualiza o estado da cópia de segurança na camada de metadados do Cloud Storage.

Produtos usados

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

  • BigQuery: um armazém de dados empresariais que ajuda a gerir e analisar os seus dados com funcionalidades integradas, como aprendizagem automática, análise geoespacial e Business Intelligence.
  • Cloud Logging: um sistema de gestão de registos em tempo real com armazenamento, pesquisa, análise e alertas.
  • Pub/Sub: um serviço de mensagens assíncrono e escalável que desassocia os serviços que produzem mensagens dos serviços que processam essas mensagens.
  • Cloud Run: uma plataforma de computação sem servidor que lhe permite executar contentores diretamente na infraestrutura escalável da Google.
  • Cloud Storage: um serviço de armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acedidos a partir do interior e do exterior Google Cloud, e são replicados em várias localizações para redundância.
  • Cloud Scheduler: um programador de tarefas cronológicas de nível empresarial totalmente gerido que lhe permite configurar unidades de tarefas agendadas para serem executadas em horários definidos ou intervalos regulares.
  • Datastore: uma base de dados NoSQL altamente escalável para as suas aplicações para dispositivos móveis e a Web.

Exemplos de utilização

Esta secção apresenta exemplos de utilização para os quais pode usar esta arquitetura.

Automatização da cópia de segurança

Por exemplo, a sua empresa pode operar numa indústria regulamentada e usar o BigQuery como o principal armazém de dados. Mesmo quando a sua empresa segue as práticas recomendadas no desenvolvimento de software, na revisão de código e na engenharia de lançamentos, continua a existir um risco de perda ou corrupção de dados devido a erros humanos. Num setor regulamentado, tem de minimizar este risco o máximo possível.

Seguem-se alguns exemplos destes erros humanos:

  • Eliminação acidental de tabelas.
  • Corrupção de dados devido a uma lógica de pipeline de dados errónea.

Normalmente, estes tipos de erros humanos podem ser resolvidos com a funcionalidade de viagem no tempo, que lhe permite recuperar dados de há até sete dias. Além disso, o BigQuery também oferece um período de segurança, durante o qual os dados eliminados são retidos no armazenamento de segurança durante mais sete dias após o período de viagem no tempo. Esses dados estão disponíveis para recuperação de emergência através do Cloud Customer Care. No entanto, se a sua empresa não descobrir e corrigir esses erros dentro deste período combinado, os dados eliminados deixam de ser recuperáveis a partir do último estado estável.

Para mitigar esta situação, recomendamos que execute cópias de segurança regulares de quaisquer tabelas do BigQuery que não possam ser reconstruídas a partir de dados de origem (por exemplo, registos do histórico ou KPIs com lógica empresarial em evolução).

A sua empresa pode usar scripts básicos para fazer cópias de segurança de dezenas de tabelas. No entanto, se precisar de fazer regularmente cópias de segurança de centenas ou milhares de tabelas em toda a organização, precisa de uma solução de automatização escalável que possa fazer o seguinte:

  • Lidar com diferentes Google Cloud limites da API.
  • Fornecer uma estrutura padronizada para definir políticas de cópia de segurança.
  • Oferecer capacidades de transparência e monitorização para as operações de cópia de segurança.

Políticas de cópia de segurança

A sua empresa também pode exigir que as políticas de cópia de segurança sejam definidas pelos seguintes grupos de pessoas:

  • Os proprietários dos dados, que estão mais familiarizados com as tabelas e podem definir as políticas de cópias de segurança ao nível da tabela adequadas.
  • A equipa de administração de dados, que garante que existe uma política alternativa para abranger todas as tabelas que não tenham uma política ao nível da tabela. A política alternativa garante que são feitas cópias de segurança de determinados conjuntos de dados, projetos e pastas para agir em conformidade com os regulamentos de retenção de dados da sua empresa.

Na implementação desta arquitetura de referência, existem duas formas de definir as políticas de cópia de segurança para tabelas, e podem ser usadas em conjunto:

  • Configuração do proprietário dos dados (descentralizada): uma política de cópia de segurança ao nível da tabela, que é anexada manualmente a uma tabela.

    • O proprietário dos dados define um ficheiro JSON ao nível da tabela que é armazenado num contentor comum.
    • As políticas manuais têm precedência sobre as políticas alternativas quando a solução determina a política de cópia de segurança de uma tabela.
    • Para ver detalhes na implementação, consulte o artigo Defina políticas de cópia de segurança ao nível da tabela.

  • Configuração predefinida da organização (centralizada): uma política alternativa que se aplica apenas a tabelas que não tenham políticas anexadas manualmente.

    • Uma equipa de governação de dados define um ficheiro JSON central no Terraform, como parte da solução.
    • A política de alternativa oferece estratégias de cópia de segurança predefinidas ao nível da pasta, do projeto, do conjunto de dados e da tabela.
    • Para ver detalhes sobre a implementação, consulte o artigo Defina políticas de cópia de segurança alternativas.

Cópia de segurança vs. replicação

Um processo de cópia de segurança cria uma cópia dos dados da tabela a partir de um determinado momento, para que possam ser restaurados se os dados forem perdidos ou ficarem corrompidos. As cópias de segurança podem ser executadas uma vez ou recorrentemente (através de uma consulta ou um fluxo de trabalho agendado). No BigQuery, as cópias de segurança num determinado momento podem ser alcançadas com instantâneos. Pode usar as capturas instantâneas para manter cópias dos dados para além do período de 7 dias da viagem no tempo na mesma localização de armazenamento que os dados de origem. As imagens instantâneas 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 de falhas regionais. O BigQuery oferece um objetivo de nível de serviço (SLO) de 99,9% a 99,99%, consoante a edição.

Por outro lado, a replicação é o processo contínuo de copiar alterações da base de dados para uma base de dados secundária (ou réplica) numa localização diferente. No BigQuery, a replicação entre regiões pode ajudar a oferecer georredundância através da criação de cópias só de leitura dos dados em Google Cloud regiões secundárias, que são diferentes da região de dados de origem. No entanto, a replicação entre regiões do BigQuery não se destina a ser usada como um plano de recuperação de desastres para cenários de indisponibilidade de regiões totais. Para garantir a resiliência contra desastres regionais, considere usar a recuperação de desastres gerida pelo BigQuery.

A replicação entre regiões do BigQuery oferece uma cópia sincronizada só de leitura dos dados numa região próxima dos consumidores de dados. Estas cópias de dados permitem associações localizadas e evitam o tráfego e os 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 ajuda na recuperação, porque os dados corrompidos são copiados automaticamente para a réplica. Nesses casos, as cópias de segurança num determinado momento (capturas instantâneas) são uma melhor opção.

A tabela seguinte mostra uma comparação resumida dos métodos de cópia de segurança e replicação:

Método Frequência Localização do armazenamento Exemplos de utilização Custos
Cópia de segurança

(Capturas rápidas ou exportação do armazenamento na nuvem)		 Uma vez ou recorrentemente Igual aos dados da tabela de origem Restaure os dados originais, para além do período de viagem no tempo As imagens instantâneas incorrem em custos de armazenamento para alterações de dados apenas na imagem instantânea

As exportações podem incorrer em custos de armazenamento padrão

Consulte Otimização de custos
Replicação entre regiões Continuamente Remota Crie uma réplica noutra região

Migrações únicas entre regiões		 Incorre em custos de armazenamento de dados na réplica

Incorre em custos de replicação de dados

Considerações de design

Esta secção fornece orientações a ter em conta quando usa esta arquitetura de referência para desenvolver uma topologia que satisfaça os seus requisitos específicos de segurança, fiabilidade, otimização de custos, eficiência operacional e desempenho.

Segurança, privacidade e conformidade

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

  • A definição de entrada de rede para o Cloud Run aceita apenas tráfego interno, para restringir o acesso a partir da Internet. Também permite que apenas utilizadores autenticados e contas de serviço chamem os serviços.
  • Cada serviço do Cloud Run e subscrição do Pub/Sub usa uma conta de serviço separada, que tem apenas as autorizações necessárias atribuídas. Isto mitiga os riscos associados à utilização 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 recolhe nem processa informações de identificação pessoal (IIP). No entanto, se as tabelas de origem tiverem EIP expostas, as cópias de segurança dessas tabelas também incluem estes dados expostos. O proprietário dos dados de origem é responsável por proteger quaisquer IPIs nas tabelas de origem (por exemplo, aplicando segurança ao nível da coluna, ocultação de dados ou ocultação). As cópias de segurança só são seguras quando os dados de origem estão protegidos. Outra abordagem consiste em garantir que os projetos, os conjuntos de dados ou os contentores que contêm dados de cópia de segurança com IIP expostas têm as políticas de gestão de identidade e de acesso (IAM) necessárias que restringem o acesso apenas a utilizadores autorizados.

Como solução de uso geral, a implementação de referência não cumpre necessariamente os requisitos específicos de um setor em particular.

Fiabilidade

Esta secção descreve as funcionalidades e as considerações de design para a fiabilidade.

Mitigação de falhas com granularidade

Para fazer cópias de segurança de milhares de tabelas, é provável que atinja os limites da API para os produtos subjacentes (por exemplo, os limites de operações de instantâneo e de exportação para cada projeto). Google Cloud No entanto, se a cópia de segurança de uma tabela falhar devido a uma configuração incorreta ou outros problemas temporários, isso não deve afetar a execução geral nem a capacidade de fazer uma cópia de segurança de outras tabelas.

Para mitigar potenciais falhas, a implementação de referência desacopla os passos de processamento através da utilização de serviços do Cloud Run detalhados e da respetiva ligação através do Pub/Sub. Se um pedido de cópia de segurança da tabela falhar no passo final do serviço de etiquetagem, o Pub/Sub tenta novamente apenas este passo e não tenta novamente todo o processo.

Dividir o fluxo em vários serviços do Cloud Run, em vez de vários pontos finais alojados num serviço do Cloud Run, ajuda a fornecer um controlo detalhado da configuração de cada serviço. O nível de configuração depende das capacidades do serviço e das APIs com as quais comunica. Por exemplo, o serviço de expedição é executado uma vez por execução, mas requer uma quantidade significativa de tempo para listar todas as tabelas no âmbito da cópia de segurança do BigQuery. Por conseguinte, o serviço de expedição requer definições de tempo limite e memória mais elevadas. No entanto, o serviço do Cloud Run para instantâneos do BigQuery é executado uma vez por tabela numa única execução e é concluído em menos tempo do que o serviço de expedição. Por conseguinte, o serviço Cloud Run requer um conjunto diferente de configurações ao nível do serviço.

Consistência dos dados

A consistência dos dados nas tabelas e nas vistas é fundamental para manter uma estratégia de cópia de segurança fiável. Uma vez que os dados são atualizados e modificados continuamente, as cópias de segurança feitas em momentos diferentes podem captar estados diferentes do seu conjunto de dados. Estas cópias de segurança em estados diferentes podem levar a inconsistências quando restaura dados, especialmente para tabelas que pertencem ao mesmo conjunto de dados funcional. Por exemplo, restaurar uma tabela de vendas para um ponto no tempo diferente da respetiva tabela de inventário pode criar uma incompatibilidade no stock disponível. Da mesma forma, as vistas da base de dados que agregam dados de várias tabelas podem ser particularmente sensíveis a inconsistências. A restauração destas vistas sem garantir que as tabelas subjacentes se encontram num estado consistente pode gerar resultados imprecisos ou enganadores. Por conseguinte, quando cria as políticas e as frequências de cópia de segurança do BigQuery, é imperativo ter em conta esta consistência e garantir que os dados restaurados refletem com precisão o estado real do conjunto de dados num determinado momento.

Por exemplo, na implementação desta arquitetura de referência, a consistência dos dados é controlada através das duas configurações seguintes nas políticas de cópia de segurança. Estas configurações calculam a hora exata da captura instantânea da tabela através da viagem no tempo, sem necessariamente fazer uma cópia de segurança de todas as tabelas ao mesmo tempo.

  • backup_cron: controla a frequência com que é feito uma cópia de segurança de uma tabela. A data/hora de início de uma execução é usada como ponto de referência para o cálculo de deslocamento no tempo para todas as tabelas das quais é feito uma cópia de segurança nesta execução.
  • backup_time_travel_offset_days: Controla quantos dias no passado devem ser subtraídos ao ponto de referência no tempo (hora de início da execução) para calcular a versão exata da tabela de viagem no tempo.

Restauro automático da cópia de segurança

Embora esta arquitetura de referência se foque na automatização das cópias de segurança em grande escala, também pode considerar restaurar estas cópias de segurança de forma automática. Esta automatização adicional pode oferecer vantagens semelhantes às da automatização de cópia de segurança, incluindo uma melhor eficiência e velocidade de recuperação, com menos tempo de inatividade. Uma vez que a solução monitoriza todos os parâmetros e resultados da cópia de segurança através do serviço de etiquetagem, pode desenvolver uma arquitetura semelhante para aplicar as operações de restauro em grande escala.

Por exemplo, pode criar uma solução baseada num acionador a pedido que envia um âmbito de dados do BigQuery para um serviço de expedição, que expede um pedido por tabela para um serviço de configuração. O serviço de configuração pode obter o histórico de cópias de segurança que quer para uma tabela específica. Em seguida, o serviço de configuração pode transmiti-lo a um serviço de restauro de instantâneos do BigQuery ou a um serviço de restauro do Cloud Storage para aplicar a operação de restauro em conformidade. Por último, um serviço de etiquetagem pode armazenar os resultados destas operações numa loja de estado. Ao fazê-lo, a estrutura de restauro automático pode beneficiar dos mesmos objetivos de design que a estrutura de cópia de segurança detalhada neste documento.

Otimização de custos

A estrutura desta arquitetura fornece políticas de cópia de segurança que definem os seguintes parâmetros para a otimização de custos geral:

  • Método de cópia de segurança: a framework oferece os dois seguintes métodos de cópia de segurança:
    • Instantâneos do BigQuery, que incorrem em custos de armazenamento com base nos dados atualizados e eliminados em comparação com a tabela base. Por conseguinte, as imagens instantâneas são mais rentáveis para tabelas que são apenas de anexação ou têm atualizações limitadas.
    • Exportações do BigQuery para o Cloud Storage, que incorrem em custos de armazenamento padrão. No entanto, para tabelas grandes que seguem uma abordagem de truncar e carregar, é mais rentável fazer uma cópia de segurança das mesmas como exportações em classes de armazenamento menos dispendiosas.
  • Expiração do instantâneo: o tempo de vida (TTL) é definido para um único instantâneo de tabela, para evitar incorrer em custos de armazenamento para o instantâneo indefinidamente. Os custos de armazenamento podem aumentar ao longo do tempo se as tabelas não tiverem uma data de validade.

Eficiência operacional

Esta secção descreve as funcionalidades e as considerações para a eficiência operacional.

Políticas de cópia de segurança detalhadas e escaláveis

Um dos objetivos desta estrutura é a eficiência operacional através da expansão da produção empresarial, mantendo o investimento empresarial relativamente baixo e gerível. Por exemplo, o resultado é um número elevado de tabelas com cópias de segurança regulares, enquanto a entrada é um número reduzido de políticas e configurações de cópias de segurança mantidas.

Além de permitir políticas de cópia de segurança ao nível da tabela, a estrutura também permite políticas ao nível do conjunto de dados, do projeto, da pasta e global. Isto significa que, com algumas configurações em níveis superiores (por exemplo, ao nível da pasta ou do projeto), é possível fazer cópias de segurança de centenas ou milhares de tabelas regularmente e em grande escala.

Observabilidade

Com uma framework de automatização, é fundamental compreender os estados dos processos. Por exemplo, deve conseguir encontrar as informações para as seguintes consultas comuns:

  • A política de cópia de segurança usada pelo sistema para cada tabela.
  • O histórico de cópias de segurança e as localizações das cópias de segurança de cada tabela.
  • O estado geral de uma única execução (o número de tabelas processadas e tabelas com falhas).
  • Os erros fatais que ocorreram numa única execução e os componentes ou passos do processo em que ocorreram.

Para fornecer estas informações, a implementação escreve registos estruturados no Cloud Logging em cada passo de execução que usa um serviço do Cloud Run. Os registos incluem a entrada, a saída e os erros, juntamente com outros pontos de verificação do progresso. Um destino de registos encaminha estes registos para uma tabela do BigQuery. Pode executar várias consultas para monitorizar execuções e obter relatórios para exemplos de utilização de observabilidade comuns. Para mais informações sobre registos e consultas no BigQuery, consulte o artigo Veja registos encaminhados para o BigQuery.

Otimização do desempenho

Para processar milhares de tabelas em cada execução, a solução processa pedidos de cópias de segurança em paralelo. O serviço de expedição apresenta todas as tabelas incluídas no âmbito da cópia de segurança do BigQuery e gera um pedido de cópia de segurança por tabela em cada execução. Isto permite à aplicação processar milhares de pedidos e tabelas em paralelo, e não sequencialmente.

Alguns destes pedidos podem falhar inicialmente por motivos temporários, como atingir os limites das APIs subjacentes Google Cloud ou ter problemas de rede. Até que os pedidos sejam concluídos, o Pub/Sub tenta novamente os pedidos automaticamente com a política de repetição de recuo exponencial. Se existirem erros fatais, como destinos de cópia de segurança inválidos ou autorizações em falta, os erros são registados e a execução desse pedido de tabela específico é terminada sem afetar a execução geral.

Limites

As seguintes quotas e limites aplicam-se a esta arquitetura.

Para as capturas instantâneas de tabelas, aplica-se o seguinte a cada projeto de operação de cópia de segurança que especificar:

  • Um projeto pode executar até 100 tarefas de instantâneo de tabela em simultâneo.
  • Um projeto pode executar até 50 000 tarefas de instantâneo de tabelas por dia.
  • Um projeto pode executar até 50 tarefas de instantâneo de tabelas por tabela por dia.

Para obter detalhes, consulte a secção Capturas instantâneas de tabelas.

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

  • Pode exportar até 50 TiB de dados por dia de um projeto gratuitamente através do conjunto de slots partilhados.
  • Um projeto pode executar até 100 000 exportações por dia. Para prolongar este limite, crie uma reserva de espaço.

Para mais informações sobre como expandir estes limites, consulte o artigo Tarefas de exportação.

Relativamente aos limites de concorrência, esta arquitetura usa o Pub/Sub para repetir automaticamente os pedidos que falham devido a estes limites, até serem publicados pela API. No entanto, para outros limites no número de operações por projeto por dia, estes podem ser mitigados através de um pedido de aumento da quota ou da distribuição das operações de cópia de segurança (cópias instantâneas ou exportações) por vários projetos. Para distribuir as operações por vários projetos, configure as políticas de cópia de segurança conforme descrito nas seguintes secções de implementação:

Implementação

Para implementar esta arquitetura, consulte o artigo Implemente a automatização de cópias de segurança do BigQuery escalável.

O que se segue?

Colaboradores

Autor: Karim Wadie | Strategic Cloud Engineer

Outros colaboradores: