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

Last reviewed 2023-12-08 UTC

Neste documento, descrevemos como projetar uma plataforma de dados no Google Cloud para minimizar o impacto de uma expansão futura para outras regiões ou de uma migração entre regiões. Este documento faz parte de uma série que ajuda você a entender o impacto da expansão da sua plataforma de dados para outra região. Ele ajuda você a aprender a fazer o seguinte:

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

A orientação desta série também é útil se você não planejou uma migração entre regiões ou uma expansão para várias regiões com antecedência. Nesse caso, talvez seja necessário gastar mais esforço para preparar a infraestrutura, as cargas de trabalho e os dados para a migração entre regiões e a expansão para várias regiões.

Este documento faz parte de uma série:

Esta série presume que você leu e está familiarizado com os seguintes documentos:

No diagrama a seguir, veja o caminho da sua jornada de migração.

Caminho de migração com quatro fases.

Durante cada etapa da migração, siga as fases definidas em Migrar para o Google Cloud: primeiros passos:

  1. Avaliar e descobrir as cargas de trabalho
  2. Planejar e construir uma base
  3. Implante suas cargas de trabalho.
  4. Otimizar o ambiente.

A plataforma moderna de dados no Google Cloud

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

  • A camada de armazenamento de dados é onde os dados são salvos. Os dados que você está salvando podem estar na forma de arquivos em que você gerencia bytes reais em um sistema de arquivos como o Hadoop Distributed File System (HDFS) ou o Cloud Storage. Também é possível usar um domínio. linguagem específica (DSL) para gerenciar os dados em um sistema de gerenciamento de banco de dados.
  • A camada de computação de dados é qualquer processamento de dados que possa ser ativado sobre o sistema de armazenamento. Assim como na camada de armazenamento, há muitas implementações possíveis, e algumas ferramentas de armazenamento de dados também processam a computação de dados. O papel da camada de computação de dados na plataforma é carregar dados da camada de armazenamento, processar e salvar os resultados em um 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 camada de armazenamento de dados e vários sistemas de computação de dados para a camada de processamento de dados. Na maioria dos casos, a camada de armazenamento de dados e a camada de computação de dados são separadas. Por exemplo, você pode ter implementado a camada de armazenamento de dados usando estes serviços do Google Cloud:

Talvez você tenha implementado a camada de computação de dados usando outros serviços do Google Cloud, 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 armazenar os dados na mesma zona. em que você processa os dados.

Também recomendamos manter a camada de armazenamento de dados separada da camada de computação de dados. Manter essas camadas separadas melhora a flexibilidade na alteração das camadas de computação e na migração de dados. Manter as camadas separadas também reduz o uso de recursos, porque você não precisa manter a camada de computação em execução o tempo todo. Portanto, recomendamos que você implante o armazenamento e a computação de dados em plataformas separadas na mesma zona e região. Por exemplo, é possível mover o armazenamento de dados do HDFS para o Cloud Storage e usar um cluster do Dataproc para computação.

Avaliar o ambiente

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

  1. Crie um inventário abrangente dos seus pipelines de dados.
  2. Catalogar seus pipelines de acordo com as propriedades e dependências delas.
  3. Treine e instrua suas equipes no Google Cloud.
  4. Crie um experimento e uma prova de conceito no Google Cloud.
  5. Calcule o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha as cargas de trabalho que você quer migrar primeiro.

Para mais informações sobre a fase de avaliação e essas tarefas, consulte Migrar para o Google Cloud: avaliar e descobrir cargas de trabalho. As seções a seguir são baseadas nas informações desse documento.

Criar seus inventários

Para definir o escopo da migração, é preciso entender o ambiente da plataforma de dados em que os pipelines de dados são implantados:

  1. Crie um inventário da sua infraestrutura de dados: as diferentes camadas de armazenamento e de computação usadas para armazenamento e processamento de dados em lote.
  2. Crie um inventário dos pipelines de dados programados para migração.
  3. Criar um inventário dos conjuntos de dados que estão sendo lidos pelos pipelines de dados e que precisam 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. Além das plataformas de armazenamento padrão, como o Cloud Storage, considere outras camadas de armazenamento, como bancos de dados, como Firebase, BigQuery, Bigtable e Postgres, ou outros clusters como o Apache Kafka. Cada plataforma de armazenamento tem a 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 um banco de dados pode ter uma ferramenta de migração integrada. Confira se cada produto usado para armazenamento de dados está disponível no seu ambiente de destino ou se você tem uma substituição compatível. Pratique e verifique o processo técnico de transferência de dados para cada uma das plataformas de armazenamento envolvidas.
  • Camadas de computação. Para cada plataforma de computação, verifique o plano de implantação e as alterações de configuração que você possa ter feito nas diferentes plataformas.
  • Latência de rede. Teste e verifique a latência da rede entre o ambiente de origem e o de destino. É importante que você entenda quanto tempo levará para que os dados sejam copiados. Você também precisa testar a latência da rede de clientes e ambientes externos (como um ambiente local) para o ambiente de destino em comparação com o ambiente de origem.

  • Configurações e implantação. Cada produto de infraestrutura de dados tem seus próprios métodos de configuração. Faça um inventário das configurações personalizadas que você fez para cada componente e de quais componentes você está usando as versões padrão de cada plataforma (por exemplo, qual versão do Dataproc ou do Apache Kafka você está usando). Verifique se essas configurações podem ser implantadas como parte do processo de implantação automatizada.

    É preciso saber como cada componente está configurado, porque os mecanismos computacionais podem se comportar de maneira diferente quando configurados de maneira diferente, especialmente se o framework da camada de processamento mudar durante a migração. Por exemplo, se o ambiente de destino estiver executando uma versão diferente do Apache Spark, algumas configurações dessa biblioteca poderão ter sido alteradas entre as versões. Esse tipo de mudança de configuração pode causar alterações nas saídas, serializações e computação.

    Durante a migração, recomendamos que você use implantações automatizadas para garantir que as versões e configurações permaneçam as mesmas. Se não for possível manter as versões e configurações iguais, faça testes que validem as saídas de dados calculadas pelo framework.

  • Tamanhos de cluster. Para clusters autogerenciados, como um cluster de longa duração do Dataproc ou do Apache Kafka em execução no Compute Engine, observe o número de nós e CPUs, bem como a memória de cada nó nos clusters de dois minutos. Migrar para outra região pode resultar em uma alteração no processador usado pela implantação. Portanto, recomendamos que você crie um perfil e otimize suas cargas de trabalho depois de implantar a infraestrutura migrada na produção. Se um componente for totalmente gerenciado ou sem servidor (por exemplo, Dataflow), o dimensionamento fará parte de cada job individual e não do cluster em si.

Os itens a seguir que você avalia no seu inventário se concentram nos pipelines de dados:

  • Origens e coletores de dados. Considere as origens e os coletores que cada pipeline de dados usa para ler e gravar dados.
  • Contratos de nível de serviço (SLAs) e objetivos de nível de serviço (SLOs). SLAs e SLOs de pipelines de dados em lote geralmente são medidos no tempo até a conclusão, mas também podem ser medidos de outras maneiras, como a potência de computação usada. Esses metadados comerciais são importantes para impulsionar os processos de plano de continuidade de negócios e recuperação de desastres (BCDR, na sigla em inglês), como o failover de um subconjunto dos pipelines mais importantes para outra região no caso de uma falha zonal ou regional. de dois minutos.
  • Dependências de pipelines de dados: Alguns pipelines de dados dependem de dados gerados por outro pipeline de dados. Ao dividir pipelines em sprints de migração, considere as dependências de dados.
  • Conjuntos de dados gerados e consumidos. Para cada pipeline de dados, identifique os conjuntos de dados que ele consome e quais conjuntos de dados ele gera. Isso pode ajudar você a identificar dependências entre pipelines e entre outros sistemas ou componentes na arquitetura geral.

Os seguintes itens avaliados no seu inventário se concentram nos conjuntos de dados a serem migrados:

  • Conjuntos de dados. Identifique os conjuntos de dados que precisam ser migrados para o ambiente de destino. Talvez alguns dados históricos não sejam necessários para a migração ou sejam migrados em um momento diferente, se eles estiverem arquivados e não forem usados ativamente. Ao definir o escopo do processo de migração e dos sprints de migração, é possível reduzir os riscos na migração.
  • Tamanhos de dados. Se você planeja compactar arquivos antes de transferi-los, anote o tamanho deles antes e depois da compactação. O tamanho dos dados afeta o tempo e o custo necessários para copiá-los da origem para o destino. Considerar esses fatores ajudará você a escolher entre estratégias de inatividade, conforme descrito mais adiante neste documento.
  • Estrutura de dados. Classifique cada conjunto de dados a ser migrado e verifique se ele é estruturado, semiestruturado ou não estruturado. Compreender a estrutura de dados pode informar sua estratégia sobre como verificar se os dados foram migrados de forma correta e completa.

Concluir a avaliação

Depois de criar os inventários relacionados aos clusters e às cargas de trabalho do Kubernetes, conclua as outras atividades da fase de avaliação em Migrar para o Google Cloud: avaliar e descobrir suas cargas de trabalho.

Planejar e criar sua base

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

  1. Criar uma hierarquia de recursos.
  2. Configurar o gerenciamento de identidade e acesso (IAM).
  3. configurar o faturamento
  4. Configurar a conectividade de rede.
  5. Aumentar sua segurança.
  6. Configurar a geração de registros, o monitoramento e os alertas.

Para mais informações sobre cada uma dessas tarefas, consulte Migrar para o Google Cloud: criar sua base.

Migrar dados e pipelines de dadoss

As seções a seguir descrevem alguns dos aspectos do plano de migração de dados e pipelines de dados em lote. Ele define alguns conceitos relacionados às características dos pipelines de dados que são importantes de entender quando você cria o plano de migração. Ele também discute alguns conceitos de teste de dados que podem ajudar a aumentar sua confiança na migração de dados.

Plano de migração

No plano de migração, você precisa incluir um tempo para concluir a transferência de dados. Seu plano precisa considerar a latência da rede, o tempo para testar a integridade dos dados e receber os dados que não foram migrados, além dos custos de rede. Como os dados são copiados de uma região para outra, seu plano de custos de rede precisa incluir os custos de rede inter-regional.

Recomendamos que você divida os diferentes pipelines e conjuntos de dados em sprints e migre-os separadamente. Essa abordagem ajuda a reduzir os riscos de cada sprint de migração e permite melhorias em cada sprint. Para melhorar sua estratégia de migração e descobrir problemas com antecedência, recomendamos que você priorize cargas de trabalho menores 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 as camadas de armazenamento e computação de dados forem criadas no mesmo sistema, recomendamos monitorar o desempenho do sistema enquanto os dados são copiados. Normalmente, copiar grandes quantidades de dados pode causar sobrecarga de E/S no sistema e prejudicar o desempenho na camada de computação. Por exemplo, se você executar uma carga de trabalho para extrair dados de um cluster do Kafka em lote, as operações extras de E/S para ler grandes quantidades de dados poderão causar uma degradação do desempenho em quaisquer pipelines de dados ativos que em execução no ambiente de origem. Nesse tipo de cenário, é preciso monitorar o desempenho do sistema usando qualquer métrica integrada ou personalizada. Para evitar sobrecarregar o sistema, recomendamos que você tenha um plano para desativar algumas cargas de trabalho durante o processo de cópia de dados ou para limitar a fase de cópia.

Como a cópia de dados torna a migração um processo de longa duração, recomendamos que você tenha planos de contingência para resolver qualquer problema que possa dar errado durante a migração. Por exemplo, se a movimentação de dados estiver demorando mais do que o esperado ou se os testes de integridade falharem antes de colocar o novo sistema on-line, considere se você quer reverter ou tentar corrigir e repetir as operações com falha. Uma reversão pode ser uma solução mais limpa, mas pode ser demorado e caro copiar grandes conjuntos de dados várias vezes. Recomendamos que você tenha um entendimento claro e testes predefinidos para determinar qual ação realizar em quais condições, quanto tempo permitir para tentar criar patches e quando executar uma reversão completa.

É importante diferenciar as ferramentas e os scripts que você está usando para a migração e os dados que está copiando. Reverter a movimentação de dados significa que é necessário recopiar os dados e substituir ou excluir os que já foram copiados. Reverter as alterações nas ferramentas e nos scripts é possivelmente mais fácil e menos dispendioso, mas as alterações nas ferramentas podem forçar você a recopiar os dados. Por exemplo, talvez seja necessário recopiar os dados se você criar um novo caminho de destino em um script que gere um local do Cloud Storage dinamicamente. Para evitar a recópia de dados, crie seus scripts para permitir a retomada e a idempotência.

Características do pipeline de dados

Para criar um plano de migração ideal, você precisa entender as características dos diferentes pipelines de dados. É importante lembrar que os pipelines em lote que gravam dados são diferentes dos que leem dados:

  • Pipelines de dados que gravam dados: como isso altera o estado do sistema de origem, pode ser difícil gravar dados no ambiente de origem ao mesmo tempo em que são copiados para o ambiente de destino. Considere os ambientes de execução de pipelines que gravam dados e tente priorizar a migração mais cedo no processo geral. Isso permitirá que você tenha dados no ambiente de destino antes de migrar os pipelines que leem os dados.
  • Pipelines de dados que leem dados: os pipelines que leem dados podem ter requisitos diferentes de atualização de dados. Se os pipelines que geram dados forem interrompidos no sistema de origem, os pipelines que leem os dados poderão ser executados enquanto os dados estiverem sendo copiados para o ambiente de destino.

Os dados são o estado, e a cópia de dados entre regiões não é uma operação atômica. Portanto, você precisa estar ciente das mudanças de estado enquanto os dados estão sendo copiados.

No plano de migração, também é importante diferenciar os sistemas. Os sistemas podem ter requisitos funcionais e não funcionais diferentes (por exemplo, um sistema para lote e outro para streaming). Portanto, seu plano precisa incluir estratégias diferentes para migrar cada sistema. Especifique as dependências entre os sistemas e como você 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 lidar com a migração neste sprint. Para estratégias comuns, consulte Implantar suas cargas de trabalho.
  • Lista de ferramentas e métodos para cópia de dados e implantação de recursos. Especifique qualquer ferramenta que você planeja usar para copiar dados ou implantar recursos no ambiente de destino. Essa lista precisa incluir scripts personalizados usados para copiar os recursos do Cloud Storage, ferramentas padrão, como gsutil, e ferramentas do Google Cloud, como os Serviços de migração.
  • Lista de recursos a serem implantados no ambiente de destino. Liste todos os recursos que precisam ser implantados no ambiente de destino. Essa lista precisa incluir todos os componentes de infraestrutura de dados, como buckets do Cloud Storage, conjuntos de dados do BigQuery e clusters do Dataproc. Em alguns casos, os sprints de migração iniciais incluem a implantação de um cluster dimensionado (como um cluster do Dataproc) em uma capacidade menor, enquanto os sprints posteriores incluem o redimensionamento para se adequar a novas cargas de trabalho. Verifique se o plano inclui um possível redimensionamento.
  • Lista de conjuntos de dados a serem copiados. Para cada conjunto, especifique as seguintes informações:
    • Ordem de cópia (se aplicável): na maioria das estratégias, a ordem de operação pode ser importante. Uma exceção é a estratégia de manutenção programada, descrita mais adiante neste documento.
    • Tamanho
    • Principais estatísticas: em gráficos das principais estatísticas, como número de linha, que podem ajudar a verificar se o conjunto de dados foi copiado com sucesso.
    • Tempo estimado para a cópia: o tempo para concluir a transferência de dados com base no plano de migração.
    • Método de cópia: consulte a lista de ferramentas e métodos descritas anteriormente neste documento.
    • Testes de verificação: liste explicitamente os testes que você planeja concluir para conferir se os dados foram copiados na íntegra.
    • Plano de contingência: descreva o que fazer se houver falha nos testes de verificação. Seu plano de contingência precisa especificar quando tentar novamente e retomar a cópia ou preencher a lacuna e quando fazer uma reversão completa e recopiar todo o conjunto de dados.

Testes

Esta seção descreve alguns tipos típicos de testes para os quais é possível se planejar. Os testes podem ajudar a garantir a integridade e integridade dos dados. Eles também podem garantir que a camada computacional esteja funcionando conforme o esperado e esteja pronta para executar os pipelines de dados.

  • Comparação de resumo ou hash: para validar a integridade dos dados depois de copiá-los, compare o conjunto de dados original com a nova cópia no ambiente de destino. Se os dados estiverem estruturados dentro de tabelas do BigQuery, não será possível mesclar as duas tabelas em uma consulta para ver se todos os dados existem, porque elas residem em regiões diferentes. Devido ao custo e à latência, o BigQuery não permite que consultas mesclam dados entre regiões. Em vez disso, o método de comparação precisa 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 arquivos no Cloud Storage pode usar um pipeline do Spark para calcular um hash de cada arquivo e, em seguida, agregar os hashes.

  • Fluxos canário: os fluxos canário ativam jobs criados para validar a integridade e a integridade dos dados. Antes de continuar a casos de uso de negócios, como análise de dados, pode ser útil executar jobs de fluxo canário para garantir que os dados de entrada estejam em conformidade com um conjunto de pré-requisitos. É possível implementar fluxos canário como pipelines de dados personalizados ou como fluxos em um DAG baseado no Cloud Composer. Os fluxos canário podem ajudar você a concluir tarefas, como verificar se não há valores ausentes em determinados campos ou validar se a contagem de linhas de conjuntos de dados específicos corresponde à contagem esperada.

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

    Os métodos de fluxo canário são valiosos quando você precisa avaliar a precisão dos dados armazenados e copiados em formatos de arquivo, como arquivos Avro no Cloud Storage. Os fluxos canário normalmente não geram novos dados. Em vez disso, eles falham se um conjunto de regras não é atendido nos dados de entrada.

  • Ambiente de teste: depois de concluir o plano de migração, teste o plano em um ambiente de teste. O ambiente de teste precisa incluir a cópia de dados de amostra ou a preparação de dados para outra região, a fim de estimar o tempo necessário para copiar dados na rede. Esse teste ajuda a identificar problemas com o plano de migração e a verificar se os dados podem ser migrados com sucesso. Os testes precisam incluir testes funcionais e não funcionais. O teste funcional verifica se os dados foram migrados corretamente. Os testes não funcionais verificam se a migração atende aos requisitos de desempenho, segurança e outros requisitos não funcionais. Cada etapa da migração no seu plano precisa incluir um critério de validação que detalhe quando a etapa pode ser considerada concluída.

Para ajudar na validação de dados, use a Ferramenta de validação de dados (DVT, na sigla em inglês). Essa ferramenta executa funções de validação de dados em vários níveis, desde o nível da tabela até o da linha, e ajuda a comparar os resultados dos sistemas de origem e de destino.

Seus testes precisam verificar a implantação da camada computacional e testar os conjuntos de dados que foram copiados. Uma abordagem para fazer isso é construir um pipeline de teste que possa calcular algumas agregações dos conjuntos de dados copiados e garantir que os conjuntos de dados de origem e de destino correspondam. Uma incompatibilidade entre conjuntos de dados de origem e de destino é mais comum quando os arquivos copiados entre as regiões não são representações exatas de cópia de bytes entre os sistemas de origem e de destino (como quando você altera formatos de arquivo ou compactações de arquivos).

Por exemplo, considere um conjunto de dados composto por arquivos JSON delimitados por nova linha. Os arquivos são armazenados em um bucket do Cloud Storage e montados como uma tabela externa no BigQuery. Para reduzir a quantidade de dados movidos pela rede, execute a compactação Avro como parte da migração antes de copiar os arquivos para o ambiente de destino. Essa conversão tem muitas vantagens, mas também tem alguns riscos, porque os arquivos que estão sendo gravados no ambiente de destino não são uma representação de cópia de bytes dos arquivos no ambiente de origem.

Para atenuar os riscos do cenário de conversão, é possível criar um job do Dataflow ou usar o BigQuery para calcular algumas agregações e hashes de soma de verificação do conjunto de dados (por exemplo, calculando somas, médias ou quantis para cada coluna numérica). Para colunas de string, é possível calcular agregações em cima do comprimento da string ou no código hash dessa string. Para cada linha, você pode calcular um hash agregado de uma combinação de todas as outras colunas, o que pode verificar com alta precisão que uma linha é igual à origem dela. Esses cálculos são feitos nos ambientes de origem e de destino e, em seguida, são comparados. Em alguns casos, por exemplo, se o conjunto de dados estiver armazenado no BigQuery, não será possível mesclar tabelas dos ambientes de origem e de destino porque eles estão em regiões diferentes. Portanto, você precisa usar um cliente que possa se conectar aos dois ambientes.

É possível implementar os métodos de teste anteriores no BigQuery ou como um job em lote (como no Dataflow). Em seguida, execute os jobs de agregação e compare os resultados calculados para o ambiente de origem com os calculados para o ambiente de destino. Essa abordagem pode ajudar você a garantir que os dados estejam completos e precisos.

Outro aspecto importante do teste da camada computacional é executar pipelines que incluam todas as variedades dos mecanismos de processamento e métodos computacionais. Testar o pipeline é menos importante para mecanismos computacionais gerenciados, como o BigQuery ou o Dataflow. No entanto, é importante testar o pipeline em mecanismos computacionais não gerenciados, como o Dataproc. Por exemplo, se você tiver um cluster do Dataproc que lida com vários tipos diferentes de computação, como Apache Spark, Apache Hive, Apache Flink ou Apache MapReduce, teste cada ambiente de execução para ter certeza de que os diferentes tipos de carga de trabalho estão prontos para serem transferidos.

Estratégias de migração

Depois de verificar o plano de migração com testes adequados, é possível migrar os dados. Ao migrar dados, é possível usar estratégias diferentes para cargas de trabalho diferentes. Veja a seguir exemplos de estratégias de migração que podem ser usadas no estado em que se encontram ou personalizadas de acordo com suas necessidades:

  • Manutenção programada: você planeja quando ocorre a janela de transição. Essa estratégia é boa quando os dados são alterados com frequência, mas os SLOs e SLAs podem suportar algum tempo de inatividade. Essa estratégia oferece alta confiança nos dados transferidos porque eles ficam completamente desatualizados enquanto são copiados. Para mais informações, consulte Manutenção programada em "Migração para o Google Cloud: como transferir seus conjuntos de dados grandes".
  • Transição somente leitura: uma pequena variação da estratégia de manutenção programada, em que a plataforma de dados do sistema de origem permite que pipelines de dados somente leitura continuem lendo dados enquanto eles são copiados. Essa estratégia é útil porque alguns pipelines de dados podem continuar funcionando e fornecer insights para sistemas finais. A desvantagem dessa estratégia é que os dados produzidos ficam desatualizados durante a migração, porque os dados de origem não são atualizados. Portanto, talvez seja necessário empregar uma estratégia de atualização após a migração para contabilizar os dados desatualizados nos sistemas finais.
  • Totalmente ativo: você copia os dados em um carimbo de data/hora específico, enquanto o ambiente de origem ainda está ativo para pipelines de dados de leitura e gravação. Depois de copiar os dados e mudar para a nova implantação, execute uma fase de cópia delta para receber os dados gerados após o carimbo de data/hora da migração no ambiente de origem. Essa abordagem requer mais coordenação e consideração em comparação com outras estratégias. Portanto, seu plano de migração precisa incluir como você lidará com as operações de atualização e exclusã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 sendo copiados. Essa estratégia evita a fase de cópia delta, que é necessária para preencher os dados se você usar as estratégias totalmente ativas ou somente leitura. No entanto, para ajudar a garantir que os pipelines de dados produzam resultados idênticos, uma estratégia de gravação dupla exige mais testes antes da migração. Se você não fizer testes avançados, terá problemas ao tentar consolidar um cenário de divisão cerebral. A estratégia de gravações duplas também apresenta possíveis custos de executar as mesmas cargas de trabalho duas vezes em regiões diferentes. Essa estratégia tem o potencial de migrar sua plataforma sem tempo de inatividade, mas requer muito mais coordenação para executá-la corretamente.

Testes pós-migração

Após a conclusão da migração, teste a integridade dos dados e a validade dos pipelines de dados. Se você concluir a migração em sprints, será necessário realizar esses testes após cada sprint. Os testes realizados neste estágio são semelhantes aos de integração: você testa a validade de um pipeline de dados que executa casos de uso de negócios com dados completos de nível de produção como entrada e, em seguida, inspeciona o saída para validade. É possível comparar a saída do teste de integração com a saída do ambiente de origem executando o mesmo pipeline de dados nos ambientes de origem e de destino. Esse tipo de teste só funcionará se o pipeline de dados for determinístico e se for possível garantir que a entrada para os dois ambientes seja idêntica.

Confirme que os dados estão completos quando atendem a um conjunto de critérios predefinidos, em que os dados no ambiente de origem são iguais (ou semelhantes o suficiente) aos dados no ambiente de destino. Dependendo da estratégia que você usou da seção anterior, os dados podem não corresponder a um para um. Portanto, é necessário predefinir critérios para descrever a completude dos dados para seu caso de uso. Por exemplo, no caso de dados de série temporal, considere que os dados estão completos quando o registro mais atualizado não tiver mais de cinco minutos de atraso no carimbo de data/hora atual.

Cutover (substituição)

Depois de verificar e testar os dados e os pipelines de dados no ambiente de destino, inicie a fase de transição. Iniciar essa fase significa que talvez os clientes precisem alterar a configuração para fazer referência aos novos sistemas. Em alguns casos, a configuração não pode ser igual à configuração que aponta para o sistema de origem. Por exemplo, se um serviço precisar ler dados de um bucket do Cloud Storage, os clientes precisarão alterar a configuração de qual bucket usar. Os nomes dos buckets do Cloud Storage são globalmente exclusivos. Portanto, o bucket do Cloud Storage no ambiente de destino será diferente do ambiente de origem.

Durante a fase de transição, desative e cancele a programação das cargas de trabalho do ambiente de origem. Recomendamos manter os dados do ambiente de origem por algum tempo, caso precise fazer reversão.

A fase de testes pré-migração não é tão completa quanto uma execução de produção de um pipeline de dados. Portanto, depois que a transição for concluída e o sistema de destino estiver operacional, você precisará monitorar as métricas, os ambientes de execução e as saídas semânticas dos pipelines de dados. Esse monitoramento ajudará você a detectar erros que pode ter passado despercebido na fase de testes, além de ajudar a garantir o sucesso da migração.

Otimizar o ambiente

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

  1. Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
  2. Estabeleça suas metas e requisitos de otimização.
  3. Otimize o ambiente e as equipes.
  4. Ajustar o loop de otimização.

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

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

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

O BigQuery

Como o BigQuery é um data warehouse SQL sem servidor, não é necessário implantar a camada de computação. Se alguns dos seus clientes do BigQuery especificarem regiões para processamento, você vai precisar ajustá-los. Caso contrário, o BigQuery é o mesmo nos ambientes de origem e de destino. Os dados do BigQuery são armazenados em dois tipos de tabelas:

  • Tabelas do BigQuery: tabelas no formato do BigQuery. O BigQuery gerencia a fonte de dados para você. Para mais informações sobre como migrar dados no formato do BigQuery, consulte Gerenciar conjuntos de dados.
  • Tabelas externas do BigQuery: tabelas em que os dados são armazenados fora do BigQuery. Depois que os dados forem movidos, você precisará recriar as tabelas externas no novo destino. Para mais informações sobre como migrar tabelas externas, consulte Introdução a tabelas externas.

Cloud Storage

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

Lote de dataflow

O Dataflow é um mecanismo de processamento de dados gerenciado pelo Google. Para ajudar a simplificar a migração do Dataflow e garantir que os jobs possam ser facilmente implantados em qualquer região, injete todas as entradas e saídas como parâmetros no job. Em vez de gravar locais de dados de entrada e saída no código-fonte, recomendamos transmitir caminhos do Cloud Storage e strings de conexão do banco de dados como argumentos ou parâmetros.

Dataproc

O Dataproc é um ambiente gerenciado do Apache Hadoop que pode executar qualquer carga de trabalho compatível com a estrutura do Apache Hadoop. Ele é compatível com frameworks como Apache Spark, Apache Flink e Apache Hive.

Use o Dataproc das seguintes maneiras, o que afeta como migrar seu ambiente do Dataproc entre regiões:

  • Clusters temporários com dados no Cloud Storage: os clusters são criados para executar jobs específicos e são destruídos após a conclusão dos jobs. Isso significa que a camada HDFS ou qualquer outro estado do cluster também será destruído. Se a configuração atender aos critérios a seguir, esse tipo de uso será mais fácil de migrar em comparação com outros:
    • As entradas e saídas dos jobs não estão fixadas no código-fonte. Em vez disso, os jobs recebem entradas e saídas como argumentos.
    • O provisionamento do ambiente do Dataproc é automatizado, incluindo as configurações dos frameworks individuais que seu ambiente está usando.
  • Clusters de longa duração com dados externos: você tem um ou mais clusters, mas eles são de longa duração. Isso acontece mesmo quando não há jobs em execução no cluster, o ainda esteja funcionando. Os dados e a computação são separados porque eles são salvos fora do cluster nas soluções do Google Cloud, como o Cloud Storage ou o BigQuery. Esse modelo geralmente é eficaz quando há sempre jobs em execução no cluster. Portanto, não faz sentido eliminar e configurar clusters como no modelo efêmero. Como os dados e a computação são separados, a migração é semelhante à do modelo temporário.
  • Clusters de longa duração com dados no cluster: o cluster dura muito, mas também mantém o estado, os dados ou ambos dentro dele, normalmente como dados no HDFS. Esse tipo de uso complica os esforços de migração porque dados e computação não são separados; se você migrar uma sem a outra, há um alto risco de criar inconsistências. Nesse cenário, considere mover os dados e o estado para fora do cluster antes da migração, para separar os dois. Se isso for impossível, recomendamos que você use a estratégia de manutenção programada para reduzir o risco de criar inconsistências nos seus dados.

Como há muitos frameworks em potencial e versões e configurações deles, é preciso fazer testes completos antes de executar o plano de migração.

Cloud Composer

O Cloud Composer é a versão gerenciada do Google Cloud do Apache Airflow para orquestração e programação de fluxos. DAGs, configurações e registros são gerenciados em um bucket do Cloud Storage que precisa ser migrado com a implantação do Cloud Composer. Para migrar o estado da implantação do Cloud Composer, é possível salvar e carregar snapshots do ambiente.

Se você tiver implantado plug-ins personalizados na instância do Cloud Composer, recomendamos aplicar uma metodologia de infraestrutura como código para recriar o ambiente de maneira totalmente automatizada.

O Cloud Composer não gerencia dados, mas ativa outros frameworks e plataformas de processamento de dados. Portanto, a migração do Cloud Composer pode ser completamente isolada dos dados. O Cloud Composer também não processa dados. Portanto, a implantação não precisa estar na mesma região que os dados. Portanto, é possível criar uma implantação do Cloud Composer no ambiente de destino e ainda executar pipelines no ambiente de origem. Em alguns casos, isso pode ser útil para operar pipelines diferentes em regiões distintas enquanto toda a plataforma está sendo migrada.

Cloud Data Fusion

O Cloud Data Fusion é uma ferramenta de integração visual que ajuda a criar pipelines de dados usando um editor visual. O Cloud Data Fusion é baseado no projeto de código aberto CDAP (em inglês). Assim como o Cloud Composer, o Cloud Data Fusion não gerencia dados em si, mas ativa outros frameworks e plataformas de processamento de dados. Os pipelines do Cloud Data Fusion precisam ser exportados do ambiente de origem e importados para o ambiente de destino de uma destas maneiras:

Dependendo da quantidade de fluxos que você precisa migrar, talvez você prefira um método em vez de outro. Usar a API do CDAP para criar um script de migração pode ser difícil e exigir mais habilidades de engenharia de software. No entanto, se você tiver muitos fluxos ou se eles mudarem com frequência, um processo automatizado poderá ser a melhor abordagem.

Próximas etapas

Colaboradores

Autores:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, faça login.