Casos de uso da recuperação de desastres: aplicativos de análise de dados com restrição de localidade

Last reviewed 2022-01-07 UTC

Este documento faz parte de uma série sobre a recuperação de desastres (DR) no Google Cloud. Neste documento, descrevemos como aplicar as restrições de localidade do documento Como arquitetar a recuperação de desastres para cargas de trabalho com restrição de localidade a aplicativos de análise de dados. Especificamente, este documento descreve como os componentes que você usa em uma plataforma de análise de dados se encaixam em uma arquitetura de DR que atenda às restrições de localidade a que aplicativos ou dados possam estar sujeitos.

A série consiste nas partes a seguir:

Este documento é destinado a arquitetos de sistemas e gerentes de TI. Ele pressupõe que você tem os seguintes conhecimentos e habilidades:

Requisitos de localidade para uma plataforma de análise de dados

As plataformas de análise de dados normalmente são aplicativos complexos e de várias camadas que armazenam dados em repouso. Esses aplicativos produzem eventos processados e armazenados no sistema de análise. O próprio aplicativo e os dados armazenados no sistema podem estar sujeitos aos regulamentos de localidade. Essas regulamentações variam não só entre os países, mas também entre as indústrias. Portanto, é necessário compreender claramente os requisitos de localidade dos dados antes de começar a projetar sua arquitetura de DR.

É possível determinar se a plataforma de análise de dados tem requisitos de localidade respondendo às duas perguntas a seguir:

  • Seu aplicativo precisa ser implantado em uma região específica?
  • Seus dados em repouso estão restritos a uma região específica?

Se você respondeu "não" às duas perguntas, sua plataforma de análise de dados não terá requisitos específicos de localidade. Como sua plataforma não tem requisitos de localidade, siga a orientação de DR para serviços e produtos em conformidade descritos no Guia de planejamento da recuperação de desastres.

No entanto, se você respondeu "sim" a qualquer uma das perguntas, seu aplicativo ficará restrito à localidade. Como sua plataforma de análise é restrita à localidade, faça a seguinte pergunta: É possível usar técnicas de criptografia para reduzir os requisitos de dados em repouso?

Se você souber usar técnicas de criptografia, use os serviços multirregionais e birregionais do Cloud External Key Manager e Cloud Key Management Service. Também é possível seguir as técnicas padrão de alta disponibilidade e recuperação de desastres (HA/DR, na sigla em inglês) descritas em Cenários de recuperação de desastres para dados.

Se não for possível usar técnicas de criptografia, use soluções personalizadas ou ofertas de parceiros para o planejamento de DR. Para mais informações sobre técnicas para resolver restrições de localidade para cenários de DR, consulte Como arquitetar a recuperação de desastres para cargas de trabalho com restrição de localidade.

Componentes em uma plataforma de análise de dados

Depois de entender os requisitos de localidade, a próxima etapa é entender os componentes que sua plataforma de análise de dados usa. Alguns componentes comuns da plataforma de análise de dados são bancos de dados, data lakes, pipelines de processamento e data warehouses, conforme descrito na lista a seguir:

  • O Google Cloud tem um conjunto de serviços de banco de dados que se encaixam em casos de uso diferentes.
  • Data lakes, data warehouses e pipelines de processamento podem ter definições um pouco diferentes. Neste documento, usamos um conjunto de definições que fazem referência aos serviços do Google Cloud:
    • Um data lake é uma plataforma escalonável e segura para ingerir e armazenar dados de vários sistemas. Um data lake típico pode usar o Cloud Storage como repositório de armazenamento central.
    • Um pipeline de processamento é um processo completo que utiliza dados ou eventos de um ou mais sistemas, transforma esses dados ou eventos e os carrega em um outro sistema. O pipeline pode seguir um processo de extração, transformação e carregamento (ETL, na sigla em inglês) ou extração, carregamento e transformação (ELT, na sigla em inglês). Normalmente, o sistema no qual os dados processados são carregados é um data warehouse. O Pub/Sub, o Dataflow e o Dataproc são componentes comumente usados de um pipeline de processamento.
    • O data warehouse é um sistema corporativo usado para análise e geração de relatórios de dados, que geralmente vem de um banco de dados operacional. O BigQuery é um sistema de data warehouse comumente usado em execução no Google Cloud.

Dependendo dos requisitos de localidade e dos componentes de análise de dados que você está usando, a implementação real de DR varia. As seções a seguir demonstram essa variação em dois casos de uso.

Caso de uso em lote: um job ETL periódico

O primeiro caso de uso descreve um processo em lote em que uma plataforma de varejo coleta periodicamente eventos de vendas como arquivos de várias lojas e os grava em um bucket do Cloud Storage. No diagrama a seguir, ilustramos a arquitetura de análise de dados do job em lote desse varejista.

Diagrama da arquitetura de um caso de uso em lote que envolve dados de ponto de venda.

A arquitetura inclui as seguintes fases e componentes:

  • A fase de ingestão consiste no envio pela loja dos dados do ponto de venda (PDV) ao Cloud Storage. Esses dados ingeridos aguardam o processamento.
  • A fase de orquestração usa o Cloud Composer para orquestrar o pipeline em lote de ponta a ponta.
  • A fase de processamento envolve um job do Apache Spark em execução em um cluster do Dataproc. O job do Apache Spark executa um processo de ETL nos dados ingeridos. Esse processo de ETL fornece métricas de negócios.
  • A fase de data lake usa os dados processados e armazena informações nos seguintes componentes:
    • Os dados processados normalmente são armazenados em formatos de coluna do Cloud Storage, como Parquete e ORC porque esses formatos permitem armazenamento eficiente e acesso mais rápido para cargas de trabalho analíticas.
    • Os metadados sobre os dados do processo (como bancos de dados, tabelas, colunas e partições) são armazenados no serviço metastore Hive fornecido pelo Metastore Dataproc.

Em cenários com restrição de localidade, pode ser difícil fornecer capacidade redundante de processamento e orquestração para manter a disponibilidade. Como os dados são processados em lotes, os pipelines de processamento e orquestração podem ser recriados, e os jobs em lote podem ser reiniciados depois que um cenário de desastre é resolvido. Portanto, para recuperação de desastres, o foco principal é recuperar os dados reais: os dados do PDV ingeridos, os dados processados armazenados no data lake e os metadados armazenados no data lake.

Ingestão no Cloud Storage

Tenha como a primeira consideração os requisitos de localidade para o bucket do Cloud Storage usado para ingerir os dados do sistema PDV. Use essas informações de localidade ao considerar as seguintes opções:

  • Se os requisitos de localidade permitirem que os dados em repouso residam em um dos locais multirregionais ou birregionais, escolha o tipo de local correspondente ao criar o bucket do Cloud Storage. O tipo de local que você escolhe define quais regiões do Google Cloud são usadas para replicar seus dados em repouso. Se houver uma interrupção em uma das regiões, os dados que estiverem em buckets multirregionais ou birregionais continuarão acessíveis.
  • O Cloud Storage também oferece suporte a chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) e chaves de criptografia fornecidas pelo cliente (CSEK). Algumas regras de localidade permitem que dados em repouso sejam armazenados em vários locais quando você usa CMEK ou CSEK para o gerenciamento de chaves. Se as regras de localidade permitirem o uso de CMEK ou CSEK, será possível projetar sua arquitetura de DR para usar regiões do Cloud Storage.
  • Os requisitos de localidade podem não permitir o uso de tipos de local ou gerenciamento de chaves de criptografia. Quando não for possível usar os tipos de local ou o gerenciamento de chaves de criptografia, use o comando gsutil rsync para sincronizar dados com outro local, como soluções de armazenamento no local ou de outro provedor de nuvem.

Se ocorrer um desastre, alguns dados do PDV ingeridos no bucket do Cloud Storage talvez não sejam processados e importados para o data lake. Como alternativa, os dados do PDV podem não ser ingeridos no bucket do Cloud Storage. Para esses casos, você tem as seguintes opções de recuperação de desastres:

  • Deixe o sistema do PDV tentar novamente. Se o sistema não conseguir gravar os dados do PDV no Cloud Storage, o processo de ingestão de dados falhará. Para atenuar essa situação, implemente um algoritmo de espera exponencial truncada para permitir que o sistema do PDV possa repetir a operação de ingestão de dados. Como o Cloud Storage fornece uma durabilidade de 11 noves, a ingestão de dados e o pipeline de processamento subsequente serão retomados com pouca ou nenhuma perda de dados depois que o serviço do Cloud Storage for retomado.

  • Faça cópias de dados ingeridos. O Cloud Storage aceita tipos de local multirregionais e birregionais. Dependendo dos requisitos de localidade dos dados, é possível configurar um bucket do Cloud Storage birregional ou multirregional para aumentar a disponibilidade de dados. Também é possível usar ferramentas como a gsutil para sincronizar dados entre o Cloud Storage e outro local.

Orquestração e processamento de dados ingeridos no PDV

No diagrama de arquitetura do caso de uso em lote, o Cloud Composer executa as seguintes etapas:

  • Valida se novos arquivos foram enviados para o bucket de ingestão do Cloud Storage.
  • Inicia um cluster temporário do Dataproc.
  • Inicia um job do Apache Spark para processar os dados.
  • Exclui o cluster do Dataproc no final do job.

O Cloud Composer usa arquivos de gráfico acíclico dirigido (DAG) que definem essas séries de etapas. Esses arquivos DAG são armazenados em um bucket do Cloud Storage que não é mostrado no diagrama da arquitetura. Em termos de localidade birregional e multirregional, as considerações de DR do bucket de arquivos DAG são as mesmas discutidas no bucket de ingestão.

Os clusters do Dataproc são temporários. Ou seja, os clusters só existem enquanto o estágio de processamento é executado. Essa natureza temporária significa que você não precisa fazer nada explicitamente para DR em relação aos clusters do Dataproc.

Armazenamento de data lake com o Cloud Storage

O bucket do Cloud Storage usado para o data lake tem as mesmas considerações de localidade que as discutidas para o bucket de ingestão: considerações birregionais e multirregionais, o uso de criptografia e o uso de gsutil rsync.

Ao projetar o plano de DR para o data lake, pense nos seguintes aspectos:

  • Tamanho dos dados. O volume de dados em um data lake pode ser grande. A restauração de um grande volume de dados leva tempo. Em um cenário de DR, você precisa considerar o impacto que o volume do data lake tem sobre o tempo necessário para
    restaurar dados até um ponto que atenda aos seguintes critérios:

    Para o caso de uso em lote atual, o Cloud Storage é usado para o local do data lake e fornece durabilidade de 11 noves. No entanto, os ataques de ransomware estão em alta. Para garantir que você possa se recuperar desses ataques, seria prudente seguir as práticas recomendadas descritas em Como o Cloud Storage oferece 11 noves de durabilidade

  • Dependência de dados. Os dados nos data lakes geralmente são consumidos por outros componentes de um sistema de análise de dados, como um pipeline de processamento. Em um cenário de DR, o pipeline de processamento e os dados de que ele depende precisam compartilhar o mesmo RTO. Nesse contexto, concentre-se em quanto tempo o sistema pode ficar indisponível.

  • Idade dos dados. Dados históricos podem permitir um RPO maior. Esse tipo de dados pode já ter sido analisado ou processado por outros componentes de análise de dados e pode ter sido mantido em outro componente que tenha as próprias estratégias de DR. Por exemplo, os registros de vendas exportados para o Cloud Storage são importados diariamente para o BigQuery para análise. Com as estratégias de DR adequadas para o BigQuery, os registros históricos de vendas que foram importados para o BigQuery podem ter objetivos de recuperação menores do que aqueles que não foram importados.

Armazenamento de metadados do data lake com o metastore do Dataproc

O metastore do Dataproc é um metastore do Apache Hive totalmente gerenciado, altamente disponível, com recuperação automática e sem servidor. O metastore fornece recursos de abstração e descoberta de dados. É possível fazer backup e restauração do metastore no caso de um desastre. O serviço Metastore do Dataproc também permite exportar e importar metadados. É possível adicionar uma tarefa para exportar o metastore e manter um backup externo junto do job de ETL.

Se você encontrar uma situação em que haja uma incompatibilidade de metadados, recrie o metastore a partir dos próprios dados usando o comando MSCK.

Caso de uso de streaming: alterar a captura de dados usando ELT

O segundo caso de uso descreve uma plataforma de varejo que usa captura de dados de alteração (CDC, na sigla em inglês) para atualizar sistemas de inventário de back-end e rastrear métricas de vendas em tempo real. O diagrama a seguir mostra uma arquitetura em que os eventos de um banco de dados transacional, como o Cloud SQL, são processados e armazenados em um data warehouse.

Diagrama da arquitetura de um caso de uso de streaming que envolve a captura de dados alterados de dados de varejo.

A arquitetura inclui as seguintes fases e componentes:

  • A fase de ingestão consiste nos eventos de alteração recebidos sendo enviados ao Pub/Sub. Como um serviço de entrega de mensagens, o Pub/Sub é usado para ingerir e distribuir de maneira confiável dados de análise de streaming. O Pub/Sub também tem benefícios de ser escalonável e sem servidor.
  • A fase de processamento envolve o uso do Dataflow para executar um processo ELT nos eventos ingeridos.
  • A fase de data warehouse usa o BigQuery para armazenar os eventos processados. A operação de mesclagem insere ou atualiza um registro no BigQuery. Essa operação permite que as informações armazenadas no BigQuery fiquem atualizadas com o banco de dados transacional.

Embora essa arquitetura de CDC não dependa do Cloud Composer, algumas arquiteturas de CDC exigem que o Cloud Composer orquestre a integração do streaming em cargas de trabalho em lote. Nesses casos, o fluxo de trabalho do Cloud Composer implementa verificações de integridade, preenchimentos e projeções que não podem ser feitas em tempo real devido a restrições de latência. As técnicas de DR para o Cloud Composer são discutidas no caso de uso de processamento em lote abordado anteriormente neste documento.

Para um pipeline de dados de streaming, considere o seguinte ao planejar sua arquitetura de DR:

  • Dependências de pipeline. Os pipelines de processamento usam entradas de um ou mais sistemas (as origens). Em seguida, os pipelines processam, transformam e armazenam essas entradas em alguns outros sistemas (os coletores). É importante projetar a arquitetura de DR para atingir o RTO de ponta a ponta. Você precisa garantir que o RPO das origens de dados e dos coletores permita atender ao RTO. Além de projetar a arquitetura de nuvem para atender às necessidades de localidade, você também precisará projetar as origens do CDC original para permitir que o RTO completo seja atendido.
  • Criptografia e localidade. Se a criptografia permitir que você reduza as restrições de localidade, use o Cloud KMS para atingir as seguintes metas:
    • Gerenciar suas próprias chaves de criptografia.
    • Aproveitar o recurso de criptografia de serviços individuais.
    • Implantar serviços em regiões que, de outra forma, não estariam disponíveis devido a restrições de localidade.
  • Regras de localidade nos dados em movimento. Algumas regras de localidade podem ser aplicadas apenas aos dados em repouso, mas não aos dados em movimento. Se as regras de localidade não se aplicarem aos dados em movimento, crie a arquitetura de DR para aproveitar recursos em outras regiões e melhorar os objetivos de recuperação. É possível complementar a abordagem regional integrando técnicas de criptografia.

Ingestão no Pub/Sub

Se você não tiver restrições de localidade, publique mensagens no endpoint global do Pub/Sub. Os endpoints globais do Pub/Sub são visíveis e acessíveis em qualquer local do Google Cloud.

Se os requisitos de localidade permitirem o uso de criptografia, é possível configurar o Pub/Sub para atingir um nível semelhante de alta disponibilidade como endpoints globais. Embora as mensagens do Pub/Sub sejam criptografadas com chaves de propriedade e gerenciadas pelo Google por padrão, é possível configurar o Pub/Sub para usar a CMEK. Ao usar o Pub/Sub com a CMEK, você atende às regras de localidade sobre criptografia enquanto mantém a alta disponibilidade.

Algumas regras de localidade exigem que as mensagens permaneçam em um local específico mesmo após a criptografia. Se as regras de localidade tiverem essa restrição, especifique a política de armazenamento de mensagens de um tópico do Pub/Sub e restrinja-a a uma região. Se você usar essa abordagem de armazenamento de mensagens, as mensagens publicadas em um tópico nunca serão mantidas fora do conjunto de regiões especificadas do Google Cloud. Caso seja possível usar mais de uma região do Google Cloud nas regras de localidade, é possível aumentar a disponibilidade do serviço ativando essas regiões no tópico do Pub/Sub. É necessário estar ciente de que a implementação de uma política de armazenamento de mensagens para restringir locais de recursos do Pub/Sub vem com concessões sobre disponibilidade.

Uma assinatura do Pub/Sub permite armazenar mensagens não confirmadas por até sete dias sem restrições no número de mensagens. Se o contrato de nível de serviço permitir dados atrasados, é possível armazenar os dados em buffer na assinatura do Pub/Sub se os pipelines pararem de ser executados. Quando os pipelines estiverem em execução novamente, é possível processar os eventos armazenados em backup. Esse design tem a vantagem de ter um RPO baixo. Para mais informações sobre os limites de recursos para o Pub/Sub, consulte Limites de recursos para cotas do Pub/Sub.

Processamento de eventos com o Dataflow

O Dataflow é um serviço gerenciado para executar uma ampla variedade de padrões de processamento de dados. O SDK do Apache Beam é um modelo de programação de código aberto que permite desenvolver pipelines de lote e de streaming. Você cria pipelines com um programa do Apache Beam e os executa no serviço do Dataflow.

Ao criar restrições de localidade, é necessário considerar onde as fontes, os coletores e os arquivos temporários estão localizados. Se esses locais de arquivo estiverem fora da região do job, os dados poderão ser enviados entre regiões. Se as regras de localidade permitirem que os dados sejam processados em um local diferente, crie a arquitetura de DR para implantar workers em outras regiões do Google Cloud, o que fornece alta disponibilidade.

Se as restrições de localidade limitarem o processamento a um único local, crie um job do Dataflow restrito a uma região ou zona específica. Ao enviar um job do Dataflow, é possível especificar os parâmetros do endpoint regional, da região e da zona do worker. Esses parâmetros controlam onde os workers são implantados e onde os metadados do job são armazenados.

O Apache Beam fornece um framework que permite que os pipelines sejam executados em vários executores. Projete sua arquitetura de DR para aproveitar esse recurso. Por exemplo, é possível projetar uma arquitetura de DR para ter um pipeline de backup executado no cluster local do Spark usando o Apache Spark Runner. Para informações sobre se um executor específico é capaz de realizar uma determinada operação de pipeline, consulte Matriz de capacidade do Beam (em inglês).

Se a criptografia permitir mitigar restrições de localidade, use o CMEK no Dataflow para criptografar artefatos de estado do pipeline e acessar origens e coletores protegidos com chaves do Cloud KMS. Com a criptografia, é possível projetar uma arquitetura de DR que use regiões que, de outra forma, não estariam disponíveis devido a restrições de localidade.

Data warehouse criado no BigQuery

Os data warehouse oferecem suporte a análise e tomada de decisões. Além de conter um banco de dados analítico, os data warehouses contêm vários componentes e procedimentos analíticos.

Ao projetar o plano de DR para o data warehouse, pense nas seguintes características:

  • Tamanho. Os data warehouses são muito maiores do que os sistemas de processamento de transações on-line (OLTP, na sigla em inglês). Não é incomum que os data warehouse tenham de terabytes a petabytes de dados. Considere quanto tempo levaria para restaurar esses dados para atingir os valores de RPO e RTO. Ao planejar sua estratégia de DR, você também precisa considerar o custo associado à recuperação de terabytes de dados. Para mais informações sobre as técnicas de mitigação de DR do BigQuery, consulte as informações do BigQuery na seção sobre mecanismos de backup e recuperação para os serviços de banco de dados gerenciado no Google Cloud.

  • Disponibilidade. Ao criar um conjunto de dados do BigQuery, você seleciona um local para armazenar os dados: regional ou multirregional. Um local regional é um local geográfico único, específico, como Iowa (us-central1) ou Montreal (northamerica-northeast1). Um local multirregional é uma área geográfica grande, como Estados Unidos (EUA) ou Europa (EU), que contém dois ou mais lugares geográficos.

    Ao projetar o plano de DR para atender às restrições de localidade, o domínio de falha (ou seja, se a falha ocorre no nível da máquina, da zona ou da região) terá um impacto direto quando você atingir o RTO. Para mais informações sobre esses domínios de falha e como eles afetam a disponibilidade, consulte Disponibilidade e durabilidade do BigQuery.

  • Natureza dos dados. Os data warehouse contêm informações históricas, e a maioria dos dados mais antigos costuma ser estática. Muitos data warehouse são projetados como exclusivos para anexos (em inglês). Se o data warehouse for somente para anexação, é possível alcançar o RTO restaurando apenas os dados que estão sendo anexados. Nessa abordagem, você faz backup apenas desses dados anexados. Se houver um desastre, será possível restaurar os dados anexados e disponibilizar o data warehouse para uso, mas com um subconjunto dos dados.

  • Padrão de adição e atualização de dados. Os data warehouses normalmente são atualizados usando padrões ETL ou ELT. Quando você tem caminhos de atualização controlados, é possível reproduzir eventos de atualização recentes de fontes alternativas.

Os requisitos de localidade podem limitar o uso de uma ou várias regiões para o data warehouse. Os conjuntos de dados do BigQuery podem ser regionais, mas o armazenamento multirregional é a maneira mais simples e econômica de garantir a disponibilidade dos dados em caso de desastres. Se o armazenamento multirregional não estiver disponível na sua região, mas for possível usar uma região diferente, use o serviço de transferência de dados do BigQuery para copiar o conjunto de dados para uma região diferente. Se você puder usar criptografia para reduzir os requisitos de localidade, gerencie suas próprias chaves de criptografia com o Cloud KMS e o BigQuery.

Se você só puder usar uma região, faça backup das tabelas do BigQuery. A solução mais econômica para fazer backup de tabelas é usar exportações do BigQuery. Use o Cloud Scheduler ou o Cloud Composer para programar periodicamente um job de exportação para gravar no Cloud Storage. É possível usar formatos como Avro com compactação SNAPPY ou JSON com GZIP. Ao criar estratégias de exportação, observe os limites das exportações.

Também é possível armazenar backups do BigQuery em formatos de colunas, como Parquet e ORC. Eles fornecem alta compactação e também permitem a interoperabilidade com muitos mecanismos de código aberto, como Hive e Presto, que você talvez tenha nos sistemas locais. O diagrama a seguir descreve o processo de exportação de dados do BigQuery para um formato de coluna, para armazenamento no local.

Diagrama da arquitetura que mostra a exportação de dados do BigQuery para o armazenamento em colunas, para recuperação de desastres.

Especificamente, esse processo de exportação de dados do BigQuery para um ambiente de armazenamento no local envolve as seguintes etapas:

  • Os dados do BigQuery são enviados para um job do Apache Spark no Dataproc. Usar o job do Apache Spark permite a evolução do esquema (em inglês).
  • Após o job do Dataproc processar os arquivos do BigQuery, eles são gravados no Cloud Storage e transferidos para um ambiente de DR no local.
  • O Cloud Interconnect é usado para conectar a rede de nuvem privada virtual à rede local.
  • A transferência para o ambiente de DR no local pode ocorrer pelo job do Spark.

Se o projeto do warehouse for somente para anexação e for particionado por data, será necessário criar uma cópia das partições necessárias em uma nova tabela antes de executar um job de exportação do BigQuery na nova tabela. Em seguida, use uma ferramenta como a gsutil para transferir os arquivos atualizados para o ambiente de backup no local ou para outra nuvem. As cobranças de saída podem ser aplicadas quando você transfere dados do Google Cloud.

Por exemplo, você tem um data warehouse de vendas que consiste em uma tabela orders somente de anexação em que os novos pedidos são anexados à partição que representa a data atual. No entanto, uma política de devolução pode permitir que os itens sejam devolvidos dentro de sete dias. Portanto, os registros na tabela orders dos últimos sete dias podem ser atualizados. Suas estratégias de exportação precisam considerar a política de devolução. Neste exemplo, qualquer job de exportação para fazer backup da tabela orders também precisa exportar as partições que representam pedidos nos últimos sete dias, a fim de evitar atualizações ausentes devido a devoluções.

A seguir