Migre entre regiões do Google Cloud: prepare os dados e as cargas de trabalho em lote para a migração entre regiões

Last reviewed 2024-12-02 UTC

Este documento descreve como criar uma plataforma de dados para Google Cloud minimizar o impacto de uma expansão futura para outras regiões ou de uma migração de uma região para outra. Este documento faz parte de uma série que ajuda a compreender o impacto da expansão da sua plataforma de dados para outra região. Ajuda a saber como fazer o seguinte:

  • Prepare-se para mover dados e pipelines de dados.
  • Configure verificações durante as fases de migração.
  • Crie uma estratégia de migração flexível separando o armazenamento de dados e o cálculo de dados.

As orientações desta série também são úteis se não tiver planeado uma migração entre regiões ou uma expansão para várias regiões antecipadamente. Neste caso, pode ter de despender mais esforços para preparar a sua infraestrutura, cargas de trabalho e dados para a migração entre regiões e para a expansão para várias regiões.

Este documento faz parte de uma série:

Esta série pressupõe que leu e conhece os seguintes documentos:

O diagrama seguinte ilustra o caminho do seu percurso de migração.

Caminho de migração com quatro fases.

Durante cada passo da migração, segue as fases definidas no artigo Migração para Google Cloud: Começar:

  1. Avalie e descubra as suas cargas de trabalho.
  2. Planeie e construa uma base.
  3. Implemente as suas cargas de trabalho.
  4. Otimize o seu ambiente.

A plataforma de dados moderna no Google Cloud

Esta secção descreve as diferentes partes de uma plataforma de dados moderna e como são normalmente construídas no Google Cloud. As plataformas de dados, como conceito geral, podem ser divididas em duas secções:

  • A camada de armazenamento de dados é onde os dados são guardados. Os dados que está a guardar podem estar sob a forma de ficheiros nos quais gere bytes reais num sistema de ficheiros, como o Hadoop Distributed File System (HDFS) ou o Cloud Storage, ou pode usar uma linguagem específica do domínio (DSL) para gerir os dados num sistema de gestão de bases de dados.
  • A camada de cálculo de dados é qualquer processamento de dados que possa ativar sobre o sistema de armazenamento. Tal como na camada de armazenamento, existem muitas implementações possíveis, e algumas ferramentas de armazenamento de dados também processam os dados. A função da camada de cálculo de dados na plataforma é carregar dados da camada de armazenamento, processar os dados e, em seguida, guardar os resultados num sistema de destino. O sistema de destino pode ser a camada de armazenamento de origem.

Algumas plataformas de dados usam vários sistemas de armazenamento para a respetiva camada de armazenamento de dados e vários sistemas de computação de dados para a respetiva camada de processamento de dados. Na maioria dos casos, a camada de armazenamento de dados e a camada de cálculo de dados estão separadas. Por exemplo, pode ter implementado a camada de armazenamento de dados através dos seguintesGoogle Cloud serviços:

Pode ter implementado a camada de cálculo de dados através de outrosGoogle Cloud serviços como estes:

Para reduzir o tempo e a latência da comunicação, o custo da transferência de dados de saída e o número de operações de E/S entre a camada de armazenamento e a camada de computação, recomendamos que armazene os dados na mesma zona em que os processa.

Também recomendamos que mantenha a camada de armazenamento de dados separada da camada de cálculo de dados. Manter estas camadas separadas melhora a sua flexibilidade na alteração das camadas de cálculo e na migração de dados. Manter as camadas separadas também reduz a utilização de recursos, uma vez que não tem de manter a camada de computação em execução em todos os momentos. Por conseguinte, recomendamos que implemente o armazenamento de dados e o cálculo de dados em plataformas separadas na mesma zona e região. Por exemplo, pode mover o seu armazenamento de dados do HDFS para o Cloud Storage e usar um cluster do Dataproc para o cálculo.

Avalie o seu ambiente

Na fase de avaliação, determina os requisitos e as dependências para migrar os pipelines de dados em lote que implementou:

  1. Crie um inventário abrangente dos seus pipelines de dados.
  2. Catalogue os seus pipelines de acordo com as respetivas propriedades e dependências.
  3. Forme e eduque as suas equipas sobre Google Cloud.
  4. Crie uma experiência e uma prova de conceito na Google Cloud.
  5. Calcular o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha as cargas de trabalho que quer migrar primeiro.

Para mais informações sobre a fase de avaliação e estas tarefas, consulte o artigo Migração para Google Cloud: avalie e descubra as suas cargas de trabalho. As secções seguintes baseiam-se nas informações desse documento.

Crie os seus inventários

Para definir o âmbito da migração, tem de compreender o ambiente da plataforma de dados onde os seus pipelines de dados estão implementados:

  1. Crie um inventário da sua infraestrutura de dados: as diferentes camadas de armazenamento e as diferentes camadas de computação que está a usar para o armazenamento de dados e o processamento de dados em lote.
  2. Crie um inventário dos pipelines de dados agendados para migração.
  3. Crie um inventário dos conjuntos de dados que estão a ser lidos pelos pipelines de dados e que precisam de ser migrados.

Para criar um inventário da sua plataforma de dados, considere o seguinte para cada parte da infraestrutura de dados:

  • Camadas de armazenamento. Juntamente com as plataformas de armazenamento padrão, como o Cloud Storage, considere outras camadas de armazenamento, como bases de dados, como o Firebase, o BigQuery, o Bigtable e o Postgres, ou outros clusters, como o Apache Kafka. Cada plataforma de armazenamento tem a sua própria estratégia e método para concluir a migração. Por exemplo, o Cloud Storage tem serviços de migração de dados e uma base de dados pode ter uma ferramenta de migração incorporada. Certifique-se de que cada produto que está a usar para o armazenamento de dados está disponível no seu ambiente de destino ou que tem uma substituição compatível. Pratique e valide o processo técnico de transferência de dados para cada uma das plataformas de armazenamento envolvidas.
  • Camadas de cálculo. Para cada plataforma de computação, valide o plano de implementação e valide todas as alterações de configuração que possa ter feito às diferentes plataformas.
  • Latência de rede. Teste e valide a latência da rede entre o ambiente de origem e o ambiente de destino. É importante que compreenda quanto tempo vai demorar a copiar os dados. Também tem de testar a latência da rede dos clientes e dos ambientes externos (como um ambiente no local) para o ambiente de destino em comparação com o ambiente de origem.

  • Configurações e implementação. Cada produto de infraestrutura de dados tem os seus próprios métodos de configuração. Faça um inventário das configurações personalizadas que fez para cada componente e de que componentes está a usar as versões predefinidas para cada plataforma (por exemplo, que versão do Dataproc ou do Apache Kafka está a usar). Certifique-se de que essas configurações são implementáveis como parte do seu processo de implementação automatizado.

    Tem de saber como cada componente está configurado, porque os motores de cálculo podem comportar-se de forma diferente quando estão configurados de forma diferente, especialmente se a framework da camada de processamento mudar durante a migração. Por exemplo, se o ambiente de destino estiver a executar uma versão diferente do Apache Spark, algumas configurações da framework do Spark podem ter sido alteradas entre as versões. Este tipo de alteração de configuração pode causar alterações nas saídas, serializações e cálculos.

    Durante a migração, recomendamos que use implementações automáticas para garantir que as versões e as configurações permanecem iguais. Se não conseguir manter as versões e as configurações iguais, certifique-se de que tem testes que validam os resultados dos dados que a framework calcula.

  • Tamanhos dos clusters. Para clusters autogeridos, como um cluster do Dataproc de longa duração ou um cluster do Apache Kafka em execução no Compute Engine, tenha em atenção o número de nós e CPUs, bem como a memória de cada nó nos clusters. A migração para outra região pode resultar numa alteração ao processador que a sua implementação usa. Por isso, recomendamos que crie perfis e otimize as suas cargas de trabalho depois de implementar a infraestrutura migrada na produção. Se um componente for totalmente gerido ou sem servidor (por exemplo, o Dataflow), o dimensionamento fará parte de cada tarefa individual e não do próprio cluster.

Os seguintes itens que avalia no seu inventário focam-se nos pipelines de dados:

  • Origens e destinos de dados. Certifique-se de que tem em conta as origens e os destinos que cada pipeline de dados usa para ler e escrever dados.
  • Contratos de nível de serviço (SLAs) e objetivos ao nível do serviço (SLOs). Os SLAs e os SLOs dos pipelines de dados em lote são normalmente medidos em tempo de conclusão, mas também podem ser medidos de outras formas, como a capacidade de computação usada. Estes metadados da empresa são importantes para impulsionar os processos do plano de continuidade da empresa e recuperação de desastres (BCDR), como a comutação por falha de um subconjunto dos seus pipelines mais críticos para outra região no caso de uma falha zonal ou regional.
  • Relações de dependência de data pipelines. Alguns pipelines de dados baseiam-se em dados gerados por outro pipeline de dados. Quando divide os pipelines em sprints de migração, certifique-se de que tem em conta as dependências de dados.
  • Conjuntos de dados gerados e consumidos. Para cada pipeline de dados, identifique os conjuntos de dados que o pipeline consome e os conjuntos de dados que gera. Isto pode ajudar a identificar dependências entre pipelines e entre outros sistemas ou componentes na sua arquitetura geral.

Os seguintes itens que avalia no seu inventário focam-se nos conjuntos de dados a migrar:

  • Conjuntos de dados. Identifique os conjuntos de dados que têm de ser migrados para o ambiente de destino. Pode considerar que alguns dados do histórico não são necessários para a migração ou que devem ser migrados num momento diferente se os dados estiverem arquivados e não forem usados ativamente. Ao definir o âmbito do processo de migração e os sprints de migração, pode reduzir os riscos na migração.
  • Tamanhos dos dados. Se planeia comprimir ficheiros antes de os transferir, certifique-se de que regista o tamanho do ficheiro antes e depois da compressão. A dimensão dos seus dados afeta o tempo e o custo necessários para copiar os dados da origem para o destino. A consideração destes fatores ajuda a escolher entre as estratégias de tempo de inatividade, conforme descrito mais adiante neste documento.
  • Estrutura de dados. Classifique cada conjunto de dados a migrar e certifique-se de que compreende se os dados são estruturados, semiestruturados ou não estruturados. A compreensão da estrutura de dados pode fundamentar a sua estratégia sobre como verificar se os dados são migrados de forma correta e completa.

Conclua a avaliação

Depois de criar os inventários relacionados com os seus clusters e cargas de trabalho do Kubernetes, conclua o resto das atividades da fase de avaliação em Migração para Google Cloud: avalie e descubra as suas cargas de trabalho.

Planeie e crie a sua base

A fase de planeamento e criação da migração para o Google Cloud consiste nas seguintes tarefas:

  1. Crie uma hierarquia de recursos.
  2. Configure a gestão de identidade e de acesso (IAM).
  3. Configure a faturação
  4. Configure a conetividade de rede.
  5. Reforce a sua segurança.
  6. Configure o registo, a monitorização e os alertas.

Para mais informações sobre cada uma destas tarefas, consulte o artigo Migre para o Google Cloud: planeie e crie a sua base.

Migre dados e data pipelines

As secções seguintes descrevem alguns dos aspetos do plano de migração de dados e pipelines de dados em lote. Define alguns conceitos sobre as características dos pipelines de dados que são importantes compreender quando cria o plano de migração. Também aborda alguns conceitos de testes de dados que podem ajudar a aumentar a sua confiança na migração de dados.

Plano de migração

No seu plano de migração, tem de incluir tempo para concluir a transferência de dados. O seu plano deve ter em conta a latência da rede, o tempo para testar a integridade dos dados e obter todos os dados que não foram migrados, bem como todos os custos de rede. Uma vez que os dados vão ser copiados de uma região para outra, o seu plano de custos de rede deve incluir custos de rede entre regiões.

Recomendamos que divida os diferentes pipelines e conjuntos de dados em sprints e os migre separadamente. Esta abordagem ajuda a reduzir os riscos de cada sprint de migração e permite melhorias em cada sprint. Para melhorar a sua estratégia de migração e detetar problemas antecipadamente, recomendamos que dê prioridade a cargas de trabalho mais pequenas e não críticas antes de migrar cargas de trabalho maiores e mais críticas.

Outra parte importante de um plano de migração é descrever a estratégia, as dependências e a natureza dos diferentes pipelines de dados da camada de computação. Se a camada de armazenamento de dados e a camada de computação de dados forem criadas no mesmo sistema, recomendamos que monitorize o desempenho do sistema enquanto os dados são copiados. Normalmente, a ação de copiar grandes quantidades de dados pode causar sobrecarga de E/S no sistema e degradar o desempenho na camada de computação. Por exemplo, se executar uma carga de trabalho para extrair dados de um cluster do Kafka em modo de lote, as operações de E/S adicionais para ler grandes quantidades de dados podem provocar uma degradação do desempenho em quaisquer pipelines de dados ativos que ainda estejam em execução no ambiente de origem. Nesse tipo de cenário, deve monitorizar o desempenho do sistema através de métricas incorporadas ou personalizadas. Para evitar sobrecarregar o sistema, recomendamos que tenha um plano para desativar algumas cargas de trabalho durante o processo de cópia de dados ou para reduzir a fase de cópia.

Uma vez que a cópia de dados torna a migração um processo de longa duração, recomendamos que tenha planos de contingência para resolver qualquer problema que possa ocorrer durante a migração. Por exemplo, se a movimentação de dados demorar mais do que o esperado ou se os testes de integridade falharem antes de colocar o novo sistema online, pondere se quer reverter ou tentar corrigir e repetir as operações falhadas. Embora uma reversão possa ser uma solução mais limpa, pode demorar muito tempo e ser dispendioso copiar grandes conjuntos de dados várias vezes. Recomendamos que tenha uma compreensão clara e testes predefinidos para determinar que ação tomar em que condições, quanto tempo permitir para tentar criar patches e quando fazer uma reversão completa.

É importante distinguir entre as ferramentas e os scripts que está a usar para a migração e os dados que está a copiar. A reversão do movimento de dados significa que tem de copiar novamente os dados e substituir ou eliminar os dados que já copiou. A reversão das alterações às ferramentas e aos scripts é potencialmente mais fácil e menos dispendiosa, mas as alterações às ferramentas podem obrigá-lo a copiar novamente os dados. Por exemplo, pode ter de copiar novamente os dados se criar um novo caminho de destino num script que gera dinamicamente uma localização do Cloud Storage. Para ajudar a evitar a recópia de dados, crie os seus scripts para permitir a retomabilidade e a idempotência.

Características da data pipeline

Para criar um plano de migração ideal, tem de compreender as características dos diferentes pipelines de dados. É importante lembrar que os pipelines em lote que escrevem dados são diferentes dos pipelines em lote que leem dados:

  • Pipelines de dados que escrevem dados: uma vez que altera o estado do sistema de origem, pode ser difícil escrever dados no ambiente de origem ao mesmo tempo que os dados estão a ser copiados para o ambiente de destino. Considere os tempos de execução dos pipelines que escrevem dados e tente dar prioridade à respetiva migração no início do processo geral. Desta forma, tem os dados prontos no ambiente de destino antes de migrar os pipelines que leem os dados.
  • Pipelines de dados que leem dados: as pipelines que leem dados podem ter requisitos diferentes para a atualidade dos dados. Se os pipelines que geram dados forem parados no sistema de origem, os pipelines que leem dados podem ser executados enquanto os dados são copiados para o ambiente de destino.

Os dados são estatais e a cópia de dados entre regiões não é uma operação atómica. Por conseguinte, tem de estar atento às alterações de estado enquanto os dados estão a ser copiados.

Também é importante, no plano de migração, distinguir os sistemas. Os seus sistemas podem ter requisitos funcionais e não funcionais diferentes (por exemplo, um sistema para processamento em lote e outro para streaming). Por isso, o seu plano deve incluir diferentes estratégias para migrar cada sistema. Certifique-se de que especifica as dependências entre os sistemas e especifica como vai reduzir o tempo de inatividade de cada sistema durante cada fase da migração.

Um plano típico para um sprint de migração deve incluir o seguinte:

  • Estratégia geral. Descreva a estratégia para processar a migração neste sprint. Para ver estratégias comuns, consulte o artigo Implemente as suas cargas de trabalho.
  • Lista de ferramentas e métodos para a cópia de dados e a implementação de recursos. Especifique qualquer ferramenta que planeia usar para copiar dados ou implementar recursos no ambiente de destino. Esta lista deve incluir scripts personalizados que são usados para copiar recursos do Cloud Storage, ferramentas padrão, como a CLI Google Cloud, e ferramentas Google Cloud , como os serviços de migração.
  • Lista de recursos a implementar no ambiente de destino. Indique todos os recursos que têm de ser implementados no ambiente de destino. Esta lista deve incluir todos os componentes da infraestrutura de dados, como contentores do Cloud Storage, conjuntos de dados do BigQuery e clusters do Dataproc. Em alguns casos, os sprints de migração antecipada incluem a implementação de um cluster dimensionado (como um cluster do Dataproc) com uma capacidade mais pequena, enquanto os sprints posteriores incluem a alteração do tamanho para se ajustar às novas cargas de trabalho. Certifique-se de que o seu plano inclui o potencial redimensionamento.
  • Lista de conjuntos de dados a copiar. Para cada conjunto de dados, certifique-se de que especifica as seguintes informações:
    • Ordem na cópia (se aplicável): para a maioria das estratégias, a ordem de operação pode ser importante. A estratégia de manutenção programada, descrita mais adiante neste documento, é uma exceção.
    • Tamanho
    • Estatísticas principais: represente graficamente as estatísticas principais, como o número de linhas, que podem ajudar a verificar se o conjunto de dados foi copiado com êxito.
    • Tempo estimado para copiar: o tempo necessário para concluir a transferência de dados, com base no plano de migração.
    • Método para copiar: consulte a lista de ferramentas e métodos descritos anteriormente neste documento.
    • Testes de validação: liste explicitamente os testes que planeia concluir para validar que os dados foram copiados na íntegra.
    • Plano de contingência: descreva o que fazer se algum dos testes de validação falhar. O seu plano de contingência deve especificar quando tentar novamente e retomar a cópia ou preencher a lacuna, e quando fazer uma reversão completa e copiar novamente o conjunto de dados completo.

Testes

Esta secção descreve alguns tipos típicos de testes que pode planear. Os testes podem ajudar a garantir a integridade e a completude dos dados. Também podem ajudar a garantir que a camada computacional está a funcionar conforme esperado e está pronta para executar os seus pipelines de dados.

  • Comparação de resumo ou hash: para validar a integridade dos dados após a cópia dos dados, tem de comparar o conjunto de dados original com a nova cópia no ambiente de destino. Se os dados estiverem estruturados em tabelas do BigQuery, não pode juntar as duas tabelas numa consulta para ver se todos os dados existem, porque as tabelas residem em regiões diferentes. Devido ao custo e à latência, o BigQuery não permite que as consultas juntem dados em várias regiões. Em alternativa, o método de comparação tem de resumir cada conjunto de dados e comparar os resultados. Dependendo da estrutura do conjunto de dados, o método de resumo pode ser diferente. Por exemplo, uma tabela do BigQuery pode usar uma consulta de agregação, mas um conjunto de ficheiros no Cloud Storage pode usar um pipeline do Spark para calcular um hash de cada ficheiro e, em seguida, agregar os hashes.

  • Fluxos de teste: os fluxos de teste ativam tarefas criadas para validar a integridade e a completude dos dados. Antes de continuar para exemplos de utilização empresarial, como a análise de dados, pode ser útil executar tarefas de fluxo de canários para garantir que os dados de entrada estão em conformidade com um conjunto de pré-requisitos. Pode implementar fluxos de teste como pipelines de dados personalizados ou como fluxos num DAG com base no Cloud Composer. Os fluxos de canários podem ajudar a concluir tarefas como verificar se existem valores em falta para determinados campos ou validar se a contagem de linhas de conjuntos de dados específicos corresponde à contagem esperada.

    Também pode usar fluxos de canários para criar resumos ou outras agregações de uma coluna ou um subconjunto dos dados. Em seguida, pode usar o fluxo de teste para comparar os dados com um resumo ou uma agregação semelhante extraídos da cópia dos dados.

    Os métodos de fluxo canário são valiosos quando precisa de avaliar a precisão dos dados armazenados e copiados em formatos de ficheiros, como ficheiros Avro, além do Cloud Storage. Normalmente, os fluxos canários não geram novos dados, mas falham se um conjunto de regras não for cumprido nos dados de entrada.

  • Ambiente de teste: depois de concluir o plano de migração, deve testá-lo num ambiente de teste. O ambiente de teste deve incluir a cópia de dados de amostra ou dados de preparação para outra região, para estimar o tempo necessário para copiar dados através da rede. Este teste ajuda a identificar problemas com o plano de migração e a verificar se os dados podem ser migrados com êxito. Os testes devem incluir testes funcionais e não funcionais. Os testes funcionais verificam se os dados são migrados corretamente. Os testes não funcionais verificam se a migração cumpre os requisitos de desempenho, segurança e outros requisitos não funcionais. Cada passo de migração no seu plano deve incluir critérios de validação que detalham quando o passo pode ser considerado concluído.

Para ajudar com a validação de dados, pode usar a ferramenta de validação de dados (DVT). A ferramenta executa funções de validação de dados de vários níveis, desde o nível da tabela até ao nível da linha, e ajuda a comparar os resultados dos sistemas de origem e de destino.

Os seus testes devem validar a implementação da camada computacional e testar os conjuntos de dados que foram copiados. Uma abordagem para o fazer é construir um pipeline de testes que possa calcular algumas agregações dos conjuntos de dados copiados e garantir que os conjuntos de dados de origem e os conjuntos de dados de destino correspondem. Uma incompatibilidade entre os conjuntos de dados de origem e de destino é mais comum quando os ficheiros que copia entre regiões não são representações exatas de cópias de bytes entre os sistemas de origem e de destino (por exemplo, quando altera os formatos ou as compressões de ficheiros).

Por exemplo, considere um conjunto de dados composto por ficheiros JSON delimitados por newline. Os ficheiros são armazenados num contentor do Cloud Storage e são montados como uma tabela externa no BigQuery. Para reduzir a quantidade de dados movidos através da rede, pode fazer a compressão Avro como parte da migração, antes de copiar os ficheiros para o ambiente de destino. Esta conversão tem muitas vantagens, mas também tem alguns riscos, porque os ficheiros que estão a ser escritos no ambiente de destino não são uma representação de cópia de bytes dos ficheiros no ambiente de origem.

Para mitigar os riscos do cenário de conversão, pode criar uma tarefa do Dataflow ou usar o BigQuery para calcular algumas agregações e hashes de som de verificação do conjunto de dados (por exemplo, calculando somas, médias ou quantis para cada coluna numérica). Para colunas de strings, pode calcular agregações com base no comprimento da string ou no código hash dessa string. Para cada linha, pode calcular um hash agregado a partir de uma combinação de todas as outras colunas, o que permite verificar com elevada precisão que uma linha é igual à sua origem. Estes cálculos são feitos nos ambientes de origem e de destino e, em seguida, são comparados. Em alguns casos, como se o seu conjunto de dados estiver armazenado no BigQuery, não pode juntar tabelas dos ambientes de origem e de destino porque estão em regiões diferentes. Por isso, tem de usar um cliente que se possa ligar a ambos os ambientes.

Pode implementar os métodos de teste anteriores no BigQuery ou como uma tarefa em lote (por exemplo, no Dataflow). Em seguida, pode executar as tarefas de agregação e comparar os resultados calculados para o ambiente de origem com os resultados calculados para o ambiente de destino. Esta abordagem pode ajudar a garantir que os dados estão completos e precisos.

Outro aspeto importante dos testes da camada computacional é executar pipelines que incluam todas as variedades dos motores de processamento e métodos computacionais. Testar o pipeline é menos importante para motores computacionais geridos, como o BigQuery ou o Dataflow. No entanto, é importante testar o pipeline para motores computacionais não geridos, como o Dataproc. Por exemplo, se tiver um cluster do Dataproc que processa vários tipos diferentes de computação, como o Apache Spark, o Apache Hive, o Apache Flink ou o Apache MapReduce, deve testar cada tempo de execução para se certificar de que os diferentes tipos de carga de trabalho estão prontos para serem transferidos.

Estratégias de migração

Depois de validar o plano de migração com testes adequados, pode migrar os dados. Quando migra dados, pode usar diferentes estratégias para diferentes cargas de trabalho. Seguem-se exemplos de estratégias de migração que pode usar tal como estão ou personalizar de acordo com as suas necessidades:

  • Manutenção agendada: planeia quando ocorre o período de transição. Esta estratégia é adequada quando os dados são alterados com frequência, mas os SLOs e os SLAs podem suportar algum tempo de inatividade. Esta estratégia oferece uma elevada confiança nos dados transferidos, uma vez que os dados estão completamente desatualizados enquanto estão a ser copiados. Para mais informações, consulte a secção Manutenção agendada em "Migração para Google Cloud: transferir os seus grandes conjuntos de dados".
  • Transição só de leitura: uma ligeira variação da estratégia de manutenção agendada, em que a plataforma de dados do sistema de origem permite que os pipelines de dados só de leitura continuem a ler dados enquanto os dados estão a ser copiados. Esta estratégia é útil porque alguns pipelines de dados podem continuar a funcionar e fornecer estatísticas aos sistemas finais. A desvantagem desta estratégia é que os dados produzidos ficam desatualizados durante a migração, porque os dados de origem não são atualizados. Por isso, pode ter de usar uma estratégia de recuperação após a migração para ter em conta os dados desatualizados nos sistemas finais.
  • Totalmente ativo: copia os dados numa data/hora específica, enquanto o ambiente de origem continua ativo para pipelines de dados de leitura e escrita. Depois de copiar os dados e mudar para a nova implementação, executa uma fase de cópia delta para obter os dados gerados após a data/hora da migração no ambiente de origem. Esta abordagem requer mais coordenação e ponderação em comparação com outras estratégias. Por isso, o seu plano de migração tem de incluir a forma como vai processar as operações de atualização e eliminação nos dados de origem.
  • Gravações duplas: os pipelines de dados podem ser executados nos ambientes de origem e de destino enquanto os dados estão a ser copiados. Esta estratégia evita a fase de cópia delta necessária para preencher dados se usar as estratégias totalmente ativas ou só de leitura. No entanto, para ajudar a garantir que os pipelines de dados estão a produzir resultados idênticos, uma estratégia de gravação dupla requer mais testes antes da migração. Se não realizar testes avançados, vai ter problemas ao tentar consolidar um cenário de cérebro dividido. A estratégia de gravação dupla também introduz potenciais custos de execução das mesmas cargas de trabalho duas vezes em regiões diferentes. Esta estratégia tem o potencial de migrar a sua plataforma sem tempo de inatividade, mas requer muito mais coordenação para a executar corretamente.

Testes pós-migração

Após a conclusão da migração, deve testar a integridade dos dados e testar os pipelines de dados quanto à validade. Se concluir a migração em sprints, tem de fazer estes testes após cada sprint. Os testes que realiza nesta fase são semelhantes aos testes de integração: testa a validade de um pipeline de dados que está a executar exemplos de utilização empresarial com dados de nível de produção completos como entrada e, em seguida, inspeciona a saída para verificar a validade. Pode comparar o resultado do teste de integração com o resultado do ambiente de origem executando o mesmo pipeline de dados no ambiente de origem e no ambiente de destino. Este tipo de teste só funciona se o pipeline de dados for determinístico e se puder garantir que a entrada em ambos os ambientes é idêntica.

Pode confirmar que os dados estão completos quando cumprem um conjunto de critérios predefinidos, em que os dados no ambiente de origem são iguais (ou suficientemente semelhantes) aos dados no ambiente de destino. Consoante a estratégia que usou na secção anterior, os dados podem não corresponder exatamente. Por conseguinte, tem de predefinir critérios para descrever a integridade dos dados para o seu exemplo de utilização. Por exemplo, para dados de séries cronológicas, pode considerar que os dados estão completos quando o registo mais atualizado não tiver mais de cinco minutos de atraso em relação à data/hora atual.

Migração

Depois de validar e testar os dados e os pipelines de dados no ambiente de destino, pode iniciar a fase de transição. O início desta fase significa que os clientes podem ter de alterar a respetiva configuração para fazer referência aos novos sistemas. Em alguns casos, a configuração não pode ser igual à configuração que está a apontar para o sistema de origem. Por exemplo, se um serviço precisar de ler dados de um contentor do Cloud Storage, os clientes têm de alterar a configuração para indicar que contentor usar. Os nomes dos contentores do Cloud Storage são únicos a nível global, pelo que o contentor do Cloud Storage do ambiente de destino é diferente do ambiente de origem.

Durante a fase de transição, deve desativar e anular a programação das cargas de trabalho do ambiente de origem. Recomendamos que mantenha os dados do ambiente de origem durante algum tempo, caso precise de reverter.

A fase de testes pré-migração não é tão completa como uma execução de produção de um pipeline de dados. Por conseguinte, após a conclusão da mudança e a entrada em funcionamento do sistema de destino, tem de monitorizar as métricas, os tempos de execução e os resultados semânticos dos seus pipelines de dados. Esta monitorização ajuda a detetar erros que a fase de testes pode não ter detetado e ajuda a garantir o sucesso da migração.

Otimize o seu ambiente

A otimização é a última fase da migração. Nesta fase, torna o seu ambiente mais eficiente executando várias iterações de um ciclo repetível até que o ambiente cumpra os requisitos de otimização:

  1. Avalie o seu ambiente, equipas e ciclo de otimização atuais.
  2. Estabeleça os seus requisitos e objetivos de otimização.
  3. Otimize o seu ambiente e as suas equipas.
  4. Ajuste o ciclo de otimização.

Para mais informações sobre como otimizar o seu Google Cloud ambiente, consulte Migração para Google Cloud: otimize o seu ambiente.

Prepare os seus Google Cloud dados e recursos de computação para uma migração entre regiões

Esta secção fornece uma vista geral dos dados e dos recursos de computação no Google Cloud e dos princípios de design para se preparar para uma migração entre regiões.

BigQuery

Uma vez que o BigQuery é um armazém de dados SQL sem servidor, não tem de implementar a camada de computação. Se alguns dos seus clientes do BigQuery especificarem regiões para processamento, tem de ajustar esses clientes. Caso contrário, o BigQuery é igual no ambiente de origem e no ambiente de destino. Os dados do BigQuery são armazenados em dois tipos de tabelas:

  • Tabelas do BigQuery: tabelas no formato do BigQuery. O BigQuery gere os ficheiros de dados por si. Para mais informações sobre a migração de dados no formato do BigQuery, consulte o artigo Gerir conjuntos de dados.
  • Tabelas externas do BigQuery: tabelas para as quais os dados são armazenados fora do BigQuery. Depois de mover os dados, tem de recriar as tabelas externas no novo destino. Para mais informações sobre a migração de tabelas externas, consulte o artigo Introdução às tabelas externas.

Cloud Storage

O Cloud Storage oferece um Serviço de transferência de armazenamento que pode ajudar a migrar os seus dados.

Dataflow (em lote)

O Dataflow é um motor de processamento de dados gerido pela Google. Para ajudar a simplificar a migração do Dataflow e garantir que os seus trabalhos podem ser implementados em qualquer região, deve injetar todas as entradas e saídas como parâmetros no seu trabalho. Em vez de escrever localizações de dados de entrada e saída no código fonte, recomendamos que transmita caminhos do Cloud Storage e strings de ligação à base de dados como argumentos ou parâmetros.

Dataproc

O Dataproc é um ambiente Apache Hadoop gerido que pode executar qualquer carga de trabalho compatível com a framework Apache Hadoop. É compatível com frameworks como o Apache Spark, o Apache Flink e o Apache Hive.

Pode usar o Dataproc das seguintes formas, que afetam a forma como deve migrar o seu ambiente do Dataproc entre regiões:

  • Clusters efémeros com dados no Cloud Storage: os clusters são criados para executar tarefas específicas e são destruídos após a conclusão das tarefas. Isto significa que a camada HDFS ou qualquer outro estado do cluster também é destruído. Se a sua configuração cumprir os seguintes critérios, este tipo de utilização é mais fácil de migrar em comparação com outros tipos de utilização:
    • As entradas e as saídas dos seus trabalhos não estão codificadas no código-fonte. Em alternativa, as suas tarefas recebem entradas e saídas como argumentos.
    • O aprovisionamento do ambiente do Dataproc é automático, incluindo as configurações para as frameworks individuais que o seu ambiente está a usar.
  • Clusters de longa duração com dados externos: tem um ou mais clusters, mas são clusters de longa duração. Mesmo que não existam tarefas em execução no cluster, o cluster continua a funcionar. Os dados e a computação estão separados porque os dados são guardados fora do cluster em soluções como o Cloud Storage ou o BigQuery.Google Cloud Este modelo é normalmente eficaz quando existem sempre tarefas em execução no cluster, pelo que não faz sentido desativar e configurar clusters como no modelo efémero. Uma vez que os dados e a computação estão separados, a migração é semelhante à migração do modelo efémero.
  • Clusters de longa duração com dados no cluster: o cluster é de longa duração, mas também mantém o estado, os dados ou ambos no cluster, mais frequentemente como dados no HDFS. Este tipo de utilização complica os esforços de migração porque os dados e os cálculos não estão separados. Se migrar um sem o outro, existe um elevado risco de criar inconsistências. Neste cenário, pondere mover os dados e o estado para fora do cluster antes da migração para os separar. Se não for possível fazê-lo, recomendamos que use a estratégia de manutenção programada para reduzir o risco de criar inconsistências nos seus dados.

Uma vez que existem muitas estruturas potenciais e muitas versões e configurações dessas estruturas, tem de testar exaustivamente antes de executar o seu plano de migração.

Cloud Composer

O Cloud Composer é a versão gerida do Apache Airflow para orquestração e agendamento de fluxos. Google CloudOs DAGs, as configurações e os registos são geridos num contentor do Cloud Storage que deve ser migrado com a sua implementação do Cloud Composer. Para migrar o estado da sua implementação do Cloud Composer, pode guardar e carregar instantâneos do ambiente.

Se implementou plug-ins personalizados na sua instância do Cloud Composer, recomendamos que aplique uma metodologia de infraestrutura como código para recriar o ambiente de forma totalmente automática.

O Cloud Composer não gere dados, mas ativa outras plataformas e frameworks de processamento de dados. Por conseguinte, a migração do Cloud Composer pode ser completamente isolada dos dados. O Cloud Composer também não processa dados, pelo que a sua implementação não tem de estar na mesma região que os dados. Por conseguinte, pode criar uma implementação do Cloud Composer no ambiente de destino e continuar a executar pipelines no ambiente de origem. Em alguns casos, isto pode ser útil para operar diferentes pipelines em diferentes regiões enquanto toda a plataforma está a ser migrada.

Cloud Data Fusion

O Cloud Data Fusion é uma ferramenta de integração visual que ajuda a criar pipelines de dados através de um editor visual. O Cloud Data Fusion baseia-se no projeto de código aberto CDAP. Tal como o Cloud Composer, o Cloud Data Fusion não gere os dados em si, mas ativa outras plataformas e frameworks de processamento de dados. Os pipelines do Cloud Data Fusion devem ser exportados do ambiente de origem e importados para o ambiente de destino de uma das seguintes formas:

Consoante a quantidade de fluxos que precisa de migrar, pode preferir um método em detrimento do outro. A utilização da API CDAP para criar um script de migração pode ser difícil e requer mais competências de engenharia de software. No entanto, se tiver muitos fluxos ou se os fluxos mudarem com relativa frequência, um processo automatizado pode ser a melhor abordagem.

O que se segue

Colaboradores

Autor: Eyal Ben Ivri | Arquiteto de soluções na nuvem

Outro colaborador: Marco Ferrari | Cloud Solutions Architect