Exemplos de utilização de recuperação de desastres: aplicações de estatísticas de dados restritas à localidade

Last reviewed 2024-07-20 UTC

Este documento faz parte de uma série que aborda a recuperação de desastres (RD) no Google Cloud. Este documento descreve como aplicar as restrições de localidade do documento, Arquitetar a recuperação de desastres para cargas de trabalho com restrições de localidade, a aplicações de estatísticas de dados. Especificamente, este documento descreve como os componentes que usa numa plataforma de estatísticas de dados se enquadram numa arquitetura de DR que cumpre as restrições de localidade às quais as suas aplicações ou dados podem estar sujeitos.

A série é composta pelas seguintes partes:

Este documento destina-se a arquitetos de sistemas e gestores de TI. Pressupõe que tem os seguintes conhecimentos e competências:

Requisitos de localidade para uma plataforma de estatísticas de dados

As plataformas de estatísticas de dados são normalmente aplicações complexas de vários níveis que armazenam dados em repouso. Estas aplicações geram eventos que são processados e armazenados no seu sistema de estatísticas. Tanto a própria aplicação como os dados armazenados no sistema podem estar sujeitos a regulamentos de localidade. Estes regulamentos variam não só entre países, mas também entre verticais da indústria. Por conseguinte, deve ter uma compreensão clara dos requisitos de localidade dos dados antes de começar a criar a sua arquitetura de RD.

Pode determinar se a sua plataforma de estatísticas de dados tem requisitos de localidade respondendo às duas seguintes perguntas:

  • A sua aplicação tem de ser implementada numa região específica?
  • Os seus dados em repouso estão restritos a uma região específica?

Se responder "não" a ambas as perguntas, a sua plataforma de estatísticas de dados não tem requisitos específicos da localidade. Uma vez que a sua plataforma não tem requisitos de localidade, siga as orientações de recuperação de desastres para serviços e produtos em conformidade descritos no guia de planeamento de recuperação de desastres.

No entanto, se responder "sim" a qualquer uma das perguntas, a sua candidatura fica restrita à localidade. Uma vez que a sua plataforma de estatísticas está restrita à localidade, tem de fazer a seguinte pergunta: Pode usar técnicas de encriptação para mitigar os requisitos de dados em repouso?

Se conseguir usar técnicas de encriptação, pode usar os serviços multirregionais e birregionais do Cloud External Key Manager e do Cloud Key Management Service. Em seguida, também pode seguir as técnicas padrão de alta disponibilidade e recuperação de desastres (AD/RD) descritas em Cenários de recuperação de desastres para dados.

Se não conseguir usar técnicas de encriptação, tem de usar soluções personalizadas ou ofertas de parceiros para o planeamento de recuperação de desastres. Para mais informações sobre técnicas para resolver restrições de localidade para cenários de recuperação de desastres, consulte o artigo Arquitetar a recuperação de desastres para cargas de trabalho com restrições de localidade.

Componentes numa plataforma de estatísticas de dados

Quando compreender os requisitos de localidade, o passo seguinte é compreender os componentes que a sua plataforma de estatísticas de dados usa. Alguns componentes comuns de uma plataforma de estatísticas de dados são bases de dados, data lakes, pipelines de processamento e data warehouses, conforme descrito na lista seguinte:

  • Google Cloud tem um conjunto de serviços de base de dados que se adequam a diferentes exemplos de utilização.

  • Os data lakes, os data warehouses e os pipelines de processamento podem ter definições ligeiramente diferentes. Este documento usa um conjunto de definições que fazem referência Google Cloud a serviços:

    • Um lago de dados é uma plataforma escalável e segura para carregar e armazenar dados de vários sistemas. Um lago de dados típico pode usar o Cloud Storage como o repositório de armazenamento central.
    • Um pipeline de processamento é um processo completo que recebe dados ou eventos de um ou mais sistemas, transforma esses dados ou eventos e carrega-os noutro sistema. O pipeline pode seguir um processo de extração, transformação e carregamento (ETL) ou de extração, carregamento e transformação (ELT). Normalmente, o sistema no qual os dados processados são carregados é um armazém de dados. O Pub/Sub, o Dataflow e o Dataproc são componentes usados frequentemente num pipeline de processamento.
    • Um armazém de dados é um sistema empresarial usado para a análise e a criação de relatórios de dados, que normalmente provêm de uma base de dados operacional. O BigQuery é um sistema de armazém de dados usado com frequência que é executado no Google Cloud.

A implementação real da DR varia consoante os requisitos de localidade e os componentes de estatísticas de dados que está a usar. As secções seguintes demonstram esta variação com dois exemplos de utilização.

Exemplo de utilização em lote: uma tarefa de ETL periódica

O primeiro exemplo de utilização descreve um processo em lote no qual uma plataforma de retalho recolhe periodicamente eventos de vendas como ficheiros de várias lojas e, em seguida, escreve os ficheiros num contentor do Cloud Storage. O diagrama seguinte ilustra a arquitetura de estatísticas de dados para a tarefa em lote deste retalhista.

Diagrama de arquitetura de um exemplo de utilização em lote que envolve dados de pontos de venda.

A arquitetura inclui as seguintes fases e componentes:

  • A fase de carregamento consiste no envio dos dados do ponto de venda (PDV) das lojas para o Cloud Storage. Estes dados carregados estão a aguardar processamento.
  • A fase de orquestração usa o Cloud Composer para orquestrar o pipeline de processamento em lote ponto a ponto.
  • A fase de processamento envolve uma tarefa do Apache Spark em execução num cluster do Dataproc. A tarefa do Apache Spark executa um processo de ETL nos dados carregados. Este processo de ETL fornece métricas empresariais.
  • A fase do lago de dados usa os dados processados e armazena informações nos seguintes componentes:
    • Os dados processados são normalmente armazenados em formatos de colunas do Cloud Storage, como Parquet e ORC, porque estes formatos permitem um armazenamento eficiente e um acesso mais rápido para cargas de trabalho analíticas.
    • Os metadados sobre os dados do processo (como bases de dados, tabelas, colunas e partições) são armazenados no serviço Hive metastore fornecido pelo Dataproc Metastore.

Em cenários restritos à localidade, pode ser difícil fornecer capacidade de processamento e orquestração redundante para manter a disponibilidade. Uma vez que os dados são processados em lotes, é possível recriar os pipelines de processamento e orquestração, e reiniciar as tarefas em lote após a resolução de um cenário de desastre. Por conseguinte, para a recuperação de desastres, o foco principal é a recuperação dos dados reais: os dados de PDV carregados, os dados processados armazenados no lago de dados e os metadados armazenados no lago de dados.

Carregamento para o Cloud Storage

A sua primeira consideração deve ser os requisitos de localidade para o contentor do Cloud Storage usado para carregar os dados do sistema de PDV. Use estas informações de localidade quando considerar as seguintes opções:

  • Se os requisitos de localidade permitirem que os dados em repouso residam numa das localizações de várias regiões ou de duas regiões, escolha o tipo de localização correspondente quando criar o contentor do Cloud Storage. O tipo de localização que escolher define as Google Cloud regiões usadas para replicar os seus dados em repouso. Se ocorrer uma interrupção numa das regiões, os dados que residem em contentores multirregionais ou de duas regiões continuam acessíveis.
  • O Cloud Storage também suporta chaves de encriptação geridas pelo cliente (CMEK) e chaves de encriptação fornecidas pelo cliente (CSEK). Algumas regras de localidade permitem que os dados em repouso sejam armazenados em várias localizações quando usa CMEK ou CSEK para a gestão de chaves. Se as suas regras de localidade permitirem a utilização de CMEK ou CSEK, pode conceber a sua arquitetura de DR para usar regiões do Cloud Storage.
  • Os seus requisitos de localidade podem não lhe permitir usar tipos de localização nem gestão de chaves de encriptação. Quando não pode usar tipos de localização nem a gestão de chaves de encriptação, pode usar o comando gcloud storage rsync para sincronizar dados com outra localização, como o armazenamento no local ou soluções de armazenamento de outro fornecedor de nuvem.

Se ocorrer um desastre, os dados de PDV carregados no contentor do Cloud Storage podem ter dados que ainda não foram processados e importados para o lago de dados. Em alternativa, pode não ser possível carregar os dados de PDV para o contentor do Cloud Storage. Para estes casos, tem as seguintes opções de recuperação após desastre:

  • Permita que o sistema de PDV tente novamente. Caso o sistema não consiga escrever os dados do PDV no Cloud Storage, o processo de carregamento de dados falha. Para mitigar esta situação, pode implementar uma estratégia de repetição para permitir que o sistema de PDV repita a operação de carregamento de dados. Uma vez que o Cloud Storage oferece uma durabilidade elevada, o carregamento de dados e o pipeline de processamento subsequente são retomados com pouca ou nenhuma perda de dados após a retoma do serviço Cloud Storage.

  • Crie cópias dos dados carregados. O Cloud Storage suporta tipos de localização multirregionais e em duas regiões. Consoante os seus requisitos de localidade dos dados, pode configurar um contentor do Cloud Storage de várias regiões ou de duas regiões para aumentar a disponibilidade dos dados. Também pode usar ferramentas como o comando da gcloud storageCLI do Google Cloud para sincronizar dados entre o Cloud Storage e outra localização.

Organização e processamento de dados de PDV carregados

No diagrama de arquitetura para o exemplo de utilização em lote, o Cloud Composer executa os seguintes passos:

  • Valida se foram carregados novos ficheiros para o contentor de carregamento do Cloud Storage.
  • Inicia um cluster do Dataproc efémero.
  • Inicia uma tarefa do Apache Spark para processar os dados.
  • Elimina o cluster do Dataproc no final da tarefa.

O Cloud Composer usa ficheiros de grafos acíclicos dirigidos (DAG) que definem estas séries de passos. Estes ficheiros DAG são armazenados num contentor do Cloud Storage que não é apresentado no diagrama de arquitetura. Em termos de localidade de região dupla e multirregião, as considerações de recuperação de desastres para o contentor de ficheiros DAG são as mesmas que as abordadas para o contentor de carregamento.

Os clusters do Dataproc são temporários. Ou seja, os clusters só existem enquanto a fase de processamento é executada. Esta natureza efémera significa que não tem de fazer nada explicitamente para a recuperação de desastres no que diz respeito aos clusters do Dataproc.

Armazenamento de lagos de dados com o Cloud Storage

O contentor do Cloud Storage que usa para o lago de dados tem as mesmas considerações de localidade que as abordadas para o contentor de carregamento: considerações de região dupla e multirregião, a utilização da encriptação e a utilização do comando gcloud storage rsync gcloud CLI.

Ao criar o plano de RD para o seu data lake, pense nos seguintes aspetos:

  • Tamanho dos dados. O volume de dados num data lake pode ser grande. A restauração de um grande volume de dados demora tempo. Num cenário de recuperação de desastres, tem de considerar o impacto que o volume do data lake tem no tempo necessário para restaurar os dados até um ponto que cumpra os seguintes critérios:

    Para o exemplo de utilização de lote atual, o Cloud Storage é usado para a localização do lago de dados e oferece uma elevada durabilidade. No entanto, os ataques de ransomware têm aumentado. Para garantir que tem a capacidade de recuperar de tais ataques, é prudente seguir as práticas recomendadas descritas em Como o Cloud Storage oferece 11 noves de durabilidade.

  • Dependência de dados. Normalmente, os dados nos data lakes são consumidos por outros componentes de um sistema de estatísticas de dados, como um pipeline de processamento. Num cenário de DR, o pipeline de processamento e os dados dos quais depende devem partilhar o mesmo RTO. Neste contexto, concentre-se no tempo durante o qual o sistema pode estar indisponível.

  • Idade dos dados. Os dados do histórico podem permitir um RPO mais elevado. Este tipo de dados pode já ter sido analisado ou processado por outros componentes de estatísticas de dados e pode ter sido mantido noutro componente com as suas próprias estratégias de recuperação de desastres. Por exemplo, os registos 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 registos de vendas históricos que foram importados para o BigQuery podem ter objetivos de recuperação inferiores aos que não foram importados.

Armazenamento de metadados do lago de dados com o Dataproc Metastore

O Dataproc Metastore é um metastore do Apache Hive totalmente gerido, de elevada disponibilidade, com autorreparação e sem servidor. O metastore oferece funcionalidades de abstração e descoberta de dados. A metastore pode ser copiada de segurança e restaurada em caso de desastre. O serviço Dataproc Metastore também permite exportar e importar metadados. Pode adicionar uma tarefa para exportar o metastore e manter uma cópia de segurança externa juntamente com a tarefa de ETL.

Se encontrar uma situação em que existe uma incompatibilidade de metadados, pode recriar o metastore a partir dos próprios dados através do comando MSCK.

Exemplo de utilização de streaming: captura de dados de alterações através de ELT

O segundo exemplo de utilização descreve uma plataforma de retalho que usa a captura de dados de alterações (CDC) para atualizar os sistemas de inventário de back-end e acompanhar as métricas de vendas em tempo real. O diagrama seguinte mostra uma arquitetura em que os eventos de uma base de dados transacional, como o Cloud SQL, são processados e, em seguida, armazenados num armazém de dados.

Diagrama de arquitetura de um exemplo de utilização de streaming que envolve a captura de dados de alterações de dados de retalho.

A arquitetura inclui as seguintes fases e componentes:

  • A fase de carregamento consiste no envio dos eventos de alteração recebidos para o Pub/Sub. Como serviço de entrega de mensagens, o Pub/Sub é usado para carregar e distribuir de forma fiável dados de análise de streaming. O Pub/Sub tem as vantagens adicionais de ser escalável e sem servidor.
  • A fase de processamento envolve a utilização do Dataflow para executar um processo ELT nos eventos carregados.
  • A fase do armazém de dados usa o BigQuery para armazenar os eventos processados. A operação de união insere ou atualiza um registo no BigQuery. Esta operação permite que as informações armazenadas no BigQuery se mantenham atualizadas com a base de dados transacional.

Embora esta arquitetura de CDC não dependa do Cloud Composer, algumas arquiteturas de CDC requerem o Cloud Composer para orquestrar a integração do fluxo em cargas de trabalho em lote. Nestes casos, o fluxo de trabalho do Cloud Composer implementa verificações de integridade, preenchimentos e projeções que não podem ser feitos em tempo real devido a restrições de latência. As técnicas de recuperação de desastres para o Cloud Composer são abordadas no exemplo de utilização de processamento em lote abordado anteriormente no documento.

Para um pipeline de dados de streaming, deve considerar o seguinte ao planear a sua arquitetura de recuperação de desastres:

  • Dependências de pipeline. Os pipelines de processamento recebem dados de um ou mais sistemas (as origens). Em seguida, os pipelines processam, transformam e armazenam estas entradas noutros sistemas (os destinos). É importante conceber a arquitetura de recuperação de desastres para alcançar o RTO ponto a ponto. Tem de garantir que o RPO das origens de dados e dos destinos permite cumprir o RTO. Além de criar a sua arquitetura na nuvem de forma a cumprir os requisitos de localidade, também tem de criar as suas origens de CDC de forma a permitir o cumprimento do RTO de extremo a extremo.
  • Encriptação e localidade. Se a encriptação lhe permitir mitigar as restrições de localidade, pode usar o Cloud KMS para atingir os seguintes objetivos:
    • Faça a gestão das suas próprias chaves de encriptação.
    • Tire partido da capacidade de encriptação de serviços individuais.
    • Implementar serviços em regiões que, de outra forma, não estariam disponíveis para utilização devido a restrições de localidade.
  • Regras de localidade sobre dados em movimento. Algumas regras de localidade podem aplicar-se apenas a dados em repouso, mas não a dados em movimento. Se as suas regras de localidade não se aplicarem aos dados em movimento, crie a sua arquitetura de DR para usar recursos noutras regiões de modo a melhorar os objetivos de recuperação. Pode complementar a abordagem regional integrando técnicas de encriptação.

Carregamento no Pub/Sub

Se não tiver restrições de localidade, pode publicar mensagens no ponto final global do Pub/Sub. Os pontos finais globais do Pub/Sub são visíveis e acessíveis a partir de qualquerGoogle Cloud localização.

Se os seus requisitos de localidade permitirem a utilização da encriptação, é possível configurar o Pub/Sub para alcançar um nível semelhante de elevada disponibilidade aos pontos finais globais. Embora as mensagens do Pub/Sub sejam encriptadas com Google-owned and Google-managed encryption keys por predefinição, pode configurar o Pub/Sub para usar CMEK em alternativa. Ao usar o Pub/Sub com CMEK, pode cumprir as regras de localidade sobre a encriptação, mantendo a elevada disponibilidade.

Algumas regras de localidade exigem que as mensagens permaneçam numa localização específica, mesmo após a encriptação. Se as suas regras de localidade tiverem esta restrição, pode especificar a política de armazenamento de mensagens de um tópico do Pub/Sub e restringi-la a uma região. Se usar esta abordagem de armazenamento de mensagens, as mensagens publicadas num tópico nunca são persistidas fora do conjunto de regiões que especificar. Google Cloud Se as regras de localidade permitirem a utilização de mais do que uma região, pode aumentar a disponibilidade do serviço ativando essas regiões no tópico do Pub/Sub. Google Cloud Tem de ter em atenção que a implementação de uma política de armazenamento de mensagens para restringir as localizações de recursos do Pub/Sub tem compromissos em relação à disponibilidade.

Uma subscrição do Pub/Sub permite-lhe armazenar mensagens não reconhecidas durante um período máximo de 7 dias sem restrições no número de mensagens. Se o seu contrato de nível de serviço permitir dados atrasados, pode armazenar os dados em buffer na sua subscrição do Pub/Sub se os pipelines pararem de ser executados. Quando os pipelines estiverem novamente em execução, pode processar os eventos de cópia de segurança. Este design tem a vantagem de ter um RPO baixo. Para mais informações sobre os limites de recursos do Pub/Sub, consulte os limites de recursos para as quotas do Pub/Sub.

Processamento de eventos com o Dataflow

O Dataflow é um serviço gerido para executar uma grande variedade de padrões de processamento de dados. O SDK Apache Beam é um modelo de programação de código aberto que lhe permite desenvolver pipelines de processamento em lote e em fluxo contínuo. Crie os seus pipelines com um programa Apache Beam e, em seguida, execute-os no serviço Dataflow.

Ao criar designs para restrições de localidade, tem de considerar a localização das suas origens, destinos e ficheiros temporários. Se estas localizações de ficheiros estiverem fora da região do seu trabalho, os seus dados podem ser enviados entre regiões. Se as suas regras de localidade permitirem o tratamento de dados numa localização diferente, crie a sua arquitetura de DR para implementar trabalhadores noutras regiões, de modo a oferecer uma elevada disponibilidade. Google Cloud

Se as restrições de localidade limitarem o processamento a uma única localização, pode criar uma tarefa do Dataflow que esteja restrita a uma região ou uma zona específica. Quando envia uma tarefa do Dataflow, pode especificar os parâmetros ponto final regional, região do trabalhador e zona do trabalhador. Estes parâmetros controlam onde os trabalhadores são implementados e onde os metadados das tarefas são armazenados.

O Apache Beam fornece uma framework que permite a execução de pipelines em vários executores. Pode conceber a sua arquitetura de recuperação de desastres para tirar partido desta capacidade. Por exemplo, pode criar uma arquitetura de recuperação de desastres para ter um pipeline de cópia de segurança executado no cluster Spark local nas instalações através do Apache Spark Runner. Para saber se um executor específico é capaz de realizar uma determinada operação de pipeline, consulte a matriz de capacidades do Beam.

Se a encriptação lhe permitir mitigar as restrições de localidade, pode usar a CMEK no Dataflow para encriptar artefactos de estado de pipeline e aceder a origens e destinos que estão protegidos com chaves do Cloud KMS. Com a encriptação, pode criar uma arquitetura de DR que use regiões que, de outra forma, não estariam disponíveis devido a restrições de localidade.

Armazém de dados criado no BigQuery

Os armazéns de dados suportam as estatísticas e a tomada de decisões. Além de conter uma base de dados analítica, os armazéns de dados contêm vários componentes e procedimentos analíticos.

Ao criar o plano de recuperação de desastres para o seu data warehouse, pense nas seguintes características:

  • Tamanho. Os armazéns de dados são muito maiores do que os sistemas de processamento de transações online (OLTP). Não é invulgar que os armazéns de dados tenham terabytes a petabytes de dados. Tem de considerar quanto tempo demoraria a restaurar estes dados para atingir os valores de RPO e RTO. Ao planear a sua estratégia de recuperação de desastres, também tem de ter em conta o custo associado à recuperação de terabytes de dados. Para mais informações sobre técnicas de mitigação de DR para o BigQuery, consulte as informações do BigQuery na secção sobre mecanismos de cópia de segurança e recuperação para os serviços de base de dados geridos no Google Cloud.

  • Disponibilidade. Quando cria um conjunto de dados do BigQuery, seleciona uma localização onde armazenar os dados: regional ou multirregional. Uma localização regional é uma localização geográfica única e específica, como Iowa (us-central1). Uma localização multirregional é uma grande área geográfica, como os Estados Unidos (EUA) ou a Europa (UE), que contém dois ou mais locais geográficos.

    Ao conceber o seu plano de DR para cumprir as restrições de localidade, o domínio de falha (ou seja, se a falha ocorre ao nível da máquina, da zona ou da região) tem um impacto direto no cumprimento do RTO definido. Para mais informações acerca destes domínios de falhas e como afetam a disponibilidade, consulte Disponibilidade e durabilidade do BigQuery.

  • Natureza dos dados. Os armazéns de dados contêm informações históricas e, muitas vezes, a maioria dos dados mais antigos é estática. Muitos armazéns de dados são concebidos para serem apenas de anexação. Se o seu armazém de dados for apenas de anexação, pode conseguir o seu RTO restaurando apenas os dados que estão a ser anexados. Nesta abordagem, faz uma cópia de segurança apenas destes dados anexados. Se ocorrer um desastre, pode restaurar os dados anexados e ter o armazém de dados disponível para utilização, mas com um subconjunto dos dados.

  • Padrão de adição e atualização de dados. Normalmente, os armazéns de dados são atualizados através de padrões ETL ou ELT. Quando tem caminhos de atualização controlados, pode reproduzir eventos de atualização recentes a partir de fontes alternativas.

Os seus requisitos de localidade podem limitar se pode usar uma única região ou várias regiões para o seu armazém de dados. Embora os conjuntos de dados do BigQuery possam ser regionais, o armazenamento em várias regiões é a forma mais simples e económica de garantir a disponibilidade dos seus dados em caso de desastre. Se o armazenamento em várias regiões não estiver disponível na sua região, mas puder usar uma região diferente, use o Serviço de transferência de dados do BigQuery para copiar o seu conjunto de dados para uma região diferente. Se puder usar a encriptação para mitigar os requisitos de localidade, pode gerir as suas próprias chaves de encriptação com o Cloud KMS e o BigQuery.

Se só puder usar uma região, pondere fazer uma cópia de segurança das tabelas do BigQuery. A solução mais rentável para fazer cópias de segurança de tabelas é usar as exportações do BigQuery. Use o Cloud Scheduler ou o Cloud Composer para agendar periodicamente uma tarefa de exportação para escrever no Cloud Storage. Pode usar formatos, como Avro com compressão SNAPPY ou JSON com compressão GZIP. Ao criar as suas estratégias de exportação, tenha em atenção os limites de exportação.

Também pode querer armazenar cópias de segurança do BigQuery em formatos colunares, como Parquet e ORC. Estes oferecem uma compressão elevada e também permitem a interoperabilidade com muitos motores de código aberto, como o Hive e o Presto, que pode ter nos seus sistemas no local. O diagrama seguinte descreve o processo de exportação de dados do BigQuery para um formato de colunas para armazenamento numa localização no local.

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

Especificamente, este processo de exportação de dados do BigQuery para uma localização de armazenamento nas instalações envolve os seguintes passos:

  • Os dados do BigQuery são enviados para uma tarefa do Apache Spark no Dataproc. A utilização da tarefa do Apache Spark permite a evolução do esquema.
  • Depois de o trabalho do Dataproc processar os ficheiros do BigQuery, os ficheiros processados são escritos no Cloud Storage e, em seguida, transferidos para uma localização de recuperação de desastres no local.
  • O Cloud Interconnect é usado para ligar a sua rede de nuvem virtual privada à sua rede no local.
  • A transferência para a localização de recuperação de desastres no local pode ocorrer através da tarefa do Spark.

Se o design do seu armazém for apenas de anexação e estiver particionado por data, tem de criar uma cópia das partições necessárias numa nova tabela antes de executar uma tarefa de exportação do BigQuery na nova tabela. Em seguida, pode usar uma ferramenta como o comando gcloud storagegcloud CLI para transferir os ficheiros atualizados para a sua localização de cópia de segurança no local ou noutra nuvem. (Podem aplicar-se custos de saída quando transfere dados para fora de Google Cloud.)

Por exemplo, tem um armazém de dados de vendas que consiste numa tabela de apenas anexação orders na qual as novas encomendas são anexadas à partição que representa a data atual. No entanto, uma política de devolução pode permitir a devolução de artigos no prazo de 7 dias. Por conseguinte, os registos na tabela orders dos últimos 7 dias podem ser atualizados. As suas estratégias de exportação têm de ter em conta a política de devolução. Neste exemplo, qualquer tarefa de exportação para fazer uma cópia de segurança da tabela orders também tem de exportar as partições que representam encomendas nos últimos 7 dias para evitar a falta de atualizações devido a devoluções.

O que se segue?

Colaboradores

Autores: