Como migrar a infraestrutura do Hadoop local para o Google Cloud Platform

Neste guia, fornecemos uma visão geral de como mover o sistema Apache Hadoop local para o Google Cloud Platform (GCP). Descrevemos um processo de migração que não apenas move o trabalho do Hadoop para o GCP, mas também permite que você adapte seu trabalho para aproveitar os benefícios de um sistema Hadoop otimizado para computação em nuvem. Também apresentamos alguns conceitos fundamentais que você precisa entender para traduzir sua configuração do Hadoop para o GCP.

Este é o primeiro de vários guias que descrevem como mover do Hadoop local:

Benefícios da migração para o GCP

Há muitas maneiras de usar o GCP para economizar tempo, dinheiro e esforço em comparação com o uso de uma solução do Hadoop local. Em muitos casos, a adoção de uma abordagem com base em nuvem pode tornar sua solução geral mais simples e fácil de gerenciar.

Suporte integrado para o Hadoop

O GCP inclui o Cloud Dataproc, que é um ambiente gerenciado do Hadoop e do Spark. Você pode usar o Cloud Dataproc para executar a maioria dos jobs existentes com o mínimo de alterações. Desse modo, não será necessário deixar de lado todas as ferramentas do Hadoop que já conhece.

Configuração e hardware gerenciado

Ao executar o Hadoop no GCP, jamais se preocupe com o hardware físico. Basta especificar a configuração do cluster. O Cloud Dataproc alocará os recursos para você. Você pode escalonar o cluster a qualquer momento.

Gerenciamento de versões simplificado

Manter as ferramentas de código aberto atualizadas e funcionando juntas é uma das partes mais complexas do gerenciamento de um cluster do Hadoop. Ao usar o Cloud Dataproc, muito desse trabalho é gerenciado para você pelo controle de versão do Cloud Dataproc.

Configuração de job flexível

Uma configuração típica do Hadoop local usa um único cluster que atende a vários propósitos. Ao mudar para o GCP, é possível se concentrar em tarefas individuais, criando quantos clusters precisar. Isso elimina grande parte da complexidade da manutenção de um único cluster com dependências crescentes e interações de configuração de software.

Como planejar a migração

Migrar de uma solução do Hadoop local para o GCP requer uma mudança de abordagem. Um sistema Hadoop local típico consiste em um cluster monolítico compatível com muitas cargas de trabalho, geralmente em várias áreas de negócios. Como resultado, o sistema se torna mais complexo com o tempo e pode exigir que os administradores se comprometam para que tudo funcione no cluster monolítico. Ao mover o sistema Hadoop para o GCP, é possível reduzir a complexidade administrativa. No entanto, para alcançar essa simplificação e conseguir o processamento mais eficiente no GCP com o custo mínimo, é necessário repensar como estruturar os dados e os jobs.

Como o Cloud Dataproc executa o Hadoop no GCP, usar um cluster persistente do Cloud Dataproc para replicar a configuração local pode parecer a solução mais fácil. No entanto, há algumas limitações nessa abordagem:

  • Manter os dados em um cluster persistente do HDFS usando o Cloud Dataproc é mais caro do que armazenar os dados no Cloud Storage, que é o que recomendamos conforme explicaremos adiante. Manter dados em um cluster do HDFS também limita a capacidade de usá-los com outros produtos do GCP.
  • Aumentar ou substituir algumas das suas ferramentas baseadas em código aberto por outros serviços do GCP relacionados é mais eficiente ou econômico em casos de uso específicos.
  • O uso de um cluster único e persistente do Cloud Dataproc nos jobs é mais difícil de gerenciar do que a mudança para clusters segmentados que disponibilizam jobs individuais ou áreas de jobs.

A maneira mais econômica e flexível de migrar o sistema Hadoop para o GCP é deixar de pensar em termos de clusters persistentes grandes e com vários propósitos. Em vez disso, pense em clusters pequenos e de vida curta, projetados para executar jobs específicos. Você armazena os dados no Cloud Storage para oferecer suporte a vários clusters de processamento temporário. Esse modelo é geralmente chamado de modelo efêmero, porque os clusters usados para processamento dos jobs são alocados conforme necessário e liberados quando eles são concluídos.

O diagrama a seguir mostra uma migração hipotética de um sistema local para um modelo efêmero no GCP.

Diagrama que ilustra como os clusters locais podem ser reorganizados ao migrar para o GCP.

No exemplo, quatro jobs executados em dois clusters locais são movidos para o Cloud Dataproc. Os clusters efêmeros usados para executar os jobs no GCP são definidos para maximizar a eficiência de jobs individuais. Os dois primeiros jobs usam o mesmo cluster, enquanto o terceiro e o quarto jobs são executados, cada um, nos próprios clusters. Ao migrar os próprios jobs, você pode personalizar e otimizar clusters para jobs individuais ou para grupos de jobs de modo que faça sentido para seu trabalho específico. O Cloud Dataproc ajuda você a definir vários clusters rapidamente, colocá-los on-line e escaloná-los para atender às suas necessidades.

Os dados no exemplo são movidos de dois clusters do HDFS no local para intervalos do Cloud Storage. Os dados no primeiro cluster são divididos em vários intervalos, e o segundo cluster é movido para um único intervalo. Você pode personalizar a estrutura dos dados no Cloud Storage para atender às necessidades dos seus aplicativos e da sua empresa.

A migração de exemplo captura os estados inicial e final de uma migração completa para o GCP. Isso implica em uma única etapa, mas você terá os melhores resultados se não pensar na mudança para o GCP como uma migração completa de uma só vez. Em vez disso, pense nela como uma refatoração das soluções para usar um novo conjunto de ferramentas de maneiras que não eram possíveis no local. Para fazer esse trabalho de refatoração, recomendamos migrar de modo incremental.

Veja as etapas recomendadas para migrar seus fluxos de trabalho para o GCP:

  1. Mova os dados primeiro

    • Mova os dados para os intervalos do Cloud Storage.
    • Vá aos poucos. Use dados de backup ou arquivados para minimizar o impacto no sistema Hadoop atual.
  2. Faça testes

    • Use um subconjunto de dados para testar e fazer experiências. Crie uma prova de conceito em pequena escala para cada um dos jobs.
    • Tente novas abordagens para trabalhar com os dados.
    • Ajuste aos paradigmas do GCP e da computação em nuvem.
  3. Pense em termos de clusters especializados e efêmeros

    • Use os menores clusters que puder. Limite-os em jobs individuais ou pequenos grupos de jobs com relações próximas.
    • Crie clusters sempre que precisar deles em um job e exclua-os quando terminar.
  4. Use as ferramentas do GCP sempre que for apropriado

Como migrar para um modelo efêmero

A maior mudança na abordagem entre a execução de um fluxo de trabalho do Hadoop no local e a execução do mesmo fluxo de trabalho no GCP é a mudança de clusters persistentes monolíticos para clusters efêmeros especializados. Você ativa um cluster quando precisa executar um job e, em seguida, o exclui quando o job é concluído. Os recursos exigidos pelos jobs estão ativos somente quando estão sendo usados. Portanto, você paga apenas pelo que usa. Essa abordagem permite que você adapte as configurações de cluster para jobs individuais. Como você não está mantendo e configurando um cluster persistente, os custos de uso de recursos e administração de cluster são reduzidos.

Nesta seção, descreveremos como mover a infraestrutura existente do Hadoop para um modelo efêmero.

Separar dados da computação

Usar o Cloud Storage como armazenamento persistente nos fluxos de trabalho tem as vantagens a seguir:

  • É um sistema de arquivos compatível com Hadoop (HCFS, na sigla em inglês), por isso é fácil de usar com os jobs atuais.
  • É mais rápido que o HDFS em muitos casos.
  • Requer menos manutenção que o HDFS.
  • Permite que você use os dados facilmente com toda a variedade de produtos do GCP.
  • É consideravelmente mais barato do que manter os dados no HDFS em um cluster persistente do Cloud Dataproc.

Com os dados armazenados de maneira persistente no Cloud Storage, é possível executar os jobs em clusters efêmeros do Hadoop gerenciados pelo Cloud Dataproc.

Em alguns casos, pode ser mais sensato mover dados para outra tecnologia do GCP, como o BigQuery ou o Cloud Bigtable. Mas é necessário que a maioria dos dados gerais permaneça no Cloud Storage. Mais adiante neste guia, você verá detalhes sobre essas opções alternativas de armazenamento.

Executar jobs em clusters efêmeros

O Cloud Dataproc facilita a criação e a exclusão de clusters para que você possa deixar de usar um cluster monolítico e passe a usar vários clusters efêmeros. Essa abordagem tem várias vantagens:

  • É possível usar configurações de cluster diferentes nos jobs individuais, eliminando a carga administrativa de gerenciar ferramentas em jobs.
  • É possível escalonar clusters para que se adaptem a jobs individuais ou a grupos de jobs.
  • Você paga pelos recursos somente quando eles forem usados pelos jobs.
  • Você não precisa manter clusters ao longo do tempo, porque eles são configurados novamente a cada uso.
  • Você não precisa manter uma infraestrutura separada para desenvolvimento, teste e produção. É possível usar as mesmas definições para criar quantas versões diferentes de um cluster forem necessárias quando precisar delas.

Use as ações de inicialização do Cloud Dataproc para definir a configuração de nós em um cluster. Isso facilita a manutenção das diferentes configurações de cluster necessárias para oferecer suporte a jobs individuais e grupos de jobs relacionados. Para começar, use as ações de inicialização de amostra fornecidas. Nos exemplos, é demonstrado como fazer as próprias ações de inicialização.

Minimizar a vida útil de clusters efêmeros

O propósito dos clusters efêmeros é usá-los apenas para a vida útil dos jobs. Quando for a hora de executar um job, siga este processo:

  1. Crie um cluster configurado corretamente.

  2. Execute o job enviando a saída para o Cloud Storage ou outro local persistente.

  3. Exclua o cluster.

  4. Use a saída do job como for necessário.

  5. Veja os registros no Stackdriver ou no Cloud Storage.

Esse processo é mostrado no diagrama a seguir:

Diagrama de um fluxo de job efêmero na nuvem.

Usar clusters persistentes pequenos somente quando absolutamente necessário

É possível criar um cluster persistente, caso não consiga realizar seu trabalho sem ele. Essa opção pode ser cara e não é recomendada se houver uma maneira de realizar seu job em clusters efêmeros.

Você pode minimizar o custo de um cluster persistente:

  • criando o menor cluster que você puder;
  • delimitando seu trabalho nesse cluster para o menor número possível de jobs;
  • escalonando o cluster para o número mínimo de nós viáveis, adicionando mais dinamicamente para atender à demanda.

Como migrar gradualmente

Há muitas vantagens em migrar incrementalmente. É possível:

  • isolar jobs individuais na infraestrutura atual do Hadoop a partir da complexidade inerente a um ambiente maduro;
  • examinar cada job isoladamente para avaliar as necessidades dele e determinar o melhor caminho para a migração;
  • lidar com problemas inesperados à medida que surgem sem atrasar tarefas dependentes;
  • criar uma prova de conceito para cada processo complexo sem afetar o ambiente de produção;
  • transferir as cargas de trabalho para o modelo efêmero recomendado estratégica e deliberadamente.

A migração é exclusiva para o ambiente do Hadoop. Portanto, não há um plano universal que se encaixe em todos os cenários de migração. Faça um plano para a migração que lhe dê a liberdade de converter cada parte para um paradigma de computação em nuvem.

Está é uma sequência típica de migração incremental:

  1. Mova uma parte dos seus dados para o GCP.

  2. Faça experiências com esses dados:

    1. Replique seus jobs existentes que usam os dados.

    2. Faça novos protótipos que funcionem com os dados.

  3. Repita com mais dados.

Comece com os dados menos críticos possíveis. Nos estágios iniciais, é recomendado usar dados e arquivos de backup.

Um tipo de job de baixo risco que serve como um bom teste inicial é o preenchimento por meio da execução de processamento de burst nos dados do arquivo. Você pode configurar jobs que preencham lacunas no processamento de dados que existiam antes de seus jobs atuais estarem em vigor. Geralmente, começar com jobs de burst pode proporcionar experiências com escalonamento no GCP no início do plano de migração. Isso pode ajudá-lo quando você começar a migrar jobs mais importantes.

Veja no diagrama a seguir um exemplo de uma arquitetura híbrida de preenchimento típica.

Diagrama de uma arquitetura típica para preenchimento na nuvem.

O exemplo tem dois componentes principais. Primeiro, os jobs programados em execução no cluster local enviam dados para o Cloud Storage por meio de um gateway da Internet. Depois, os jobs de preenchimento são executados em clusters efêmeros do Cloud Dataproc. Além do preenchimento, é possível usar clusters efêmeros no GCP para teste e para criar provas de conceito para trabalhos futuros.

Como fazer planos com a migração completa em mente

Até agora, este guia considera que seu objetivo seja mover todo o sistema Hadoop local para o GCP. Um sistema Hadoop executado inteiramente no GCP é mais fácil de gerenciar do que aquele que opera na nuvem e no local. No entanto, muitas vezes é necessária uma abordagem híbrida para atender às suas necessidades comerciais ou tecnológicas.

Como projetar uma solução híbrida

Talvez você precise de uma solução híbrida por conta destes motivos:

  • Você está no processo de desenvolver sistemas nativos da nuvem. Portanto, os sistemas atuais que dependem deles precisam continuar sendo executados no local até o processo terminar.
  • Você tem exigências comerciais para manter os dados no local.
  • Você precisa compartilhar dados com outros sistemas que são executados no local, e a interação deles com o GCP não é possível devido a restrições técnicas ou de negócios.

Uma solução híbrida típica tem quatro partes principais:

  1. um cluster do Hadoop local

  2. uma conexão do cluster local para o GCP

  3. armazenamento de dados centralizado no GCP

  4. componentes nativos da nuvem que funcionam em dados no GCP

Um problema que você precisa resolver com uma solução de nuvem híbrida é como manter seus sistemas em sincronia. Ou seja, como você garantirá que as alterações feitas nos dados em um lugar sejam refletidas no outro? É possível simplificar a sincronização fazendo distinções claras entre como seus dados são usados nos diferentes ambientes.

Por exemplo, você pode ter uma solução híbrida em que apenas os dados arquivados são armazenados no GCP. É possível configurar jobs programados para mover seus dados do cluster local para o GCP quando eles atingirem um tempo de existência especificado. Em seguida, você pode configurar todos os jobs que funcionem nos dados arquivados no GCP para que nunca seja necessário sincronizar as alterações nos clusters locais.

Outra maneira de dividir o sistema é mover todos os dados e trabalhos para um projeto ou grupo de trabalho específico para o GCP, mantendo outro trabalho no local. Assim, você se concentra nos seus jobs em vez de criar sistemas complexos de sincronização de dados.

Talvez você tenha preocupações em relação à segurança ou à logística que dificultam o modo como você conecta o cluster local ao GCP. Uma solução é usar uma nuvem privada virtual conectada à rede local por meio do Cloud VPN.

O diagrama a seguir mostra um exemplo de configuração de nuvem híbrida:

Diagrama de uma arquitetura híbrida típica do Hadoop.

A configuração de exemplo usa o Cloud VPN para conectar uma nuvem privada virtual (VPC, na sigla em inglês) do GCP a um cluster local. O sistema usa o Cloud Dataproc dentro da VPC para gerenciar clusters persistentes que processam dados provenientes do sistema local. Isso pode envolver a sincronização de dados entre os sistemas. Esses clusters persistentes do Cloud Dataproc também transferem dados provenientes do sistema local para os serviços de armazenamento apropriados no GCP. Para fins de ilustração, o exemplo usa o Cloud Storage, o BigQuery e o Cloud Bigtable para armazenamento. Esses são os destinos mais comuns para dados processados por cargas de trabalho do Hadoop no GCP.

A outra metade da solução de exemplo mostra vários clusters efêmeros que são criados conforme necessário na nuvem pública. Esses clusters podem ser usados para muitas tarefas, incluindo aquelas que coletam e transformam novos dados. Os resultados desses jobs são armazenados nos mesmos serviços de armazenamento usados pelos clusters em execução na VPC.

Como projetar uma solução nativa da nuvem

Por outro lado, uma solução nativa da nuvem vai direto ao ponto. Como todos os jobs no GCP são executados usando dados armazenados no Cloud Storage, você evita a complexidade da sincronização de dados, mas ainda precisa ser cauteloso sobre o modo como os diferentes jobs usam os mesmos dados.

Veja no diagrama a seguir um exemplo de um sistema nativo da nuvem:

Diagrama de uma arquitetura nativa da nuvem típica do Hadoop.

O sistema de exemplo tem alguns clusters persistentes e alguns efêmeros. Ambos os tipos de clusters compartilham ferramentas e recursos de nuvem, incluindo armazenamento e monitoramento. O Cloud Dataproc usa imagens de máquina padronizadas para definir configurações de software nas VMs de um cluster. É possível usar essas imagens predefinidas como base para a configuração de VM que você precisa. O exemplo mostra a maioria dos clusters persistentes em execução na versão 1.1, com um cluster em execução na versão 1.2. Você pode criar novos clusters com instâncias de VM personalizadas sempre que precisar. Isso permite isolar os ambientes de teste e desenvolvimento de jobs e dados de produção críticos.

Os clusters efêmeros no exemplo executam uma variedade de jobs. Neste exemplo, mostramos o Apache Airflow em execução no Compute Engine sendo usado para programar o trabalho com clusters efêmeros.

Como trabalhar com serviços do GCP

Esta seção aborda mais algumas considerações a respeito da migração do Hadoop para o GCP.

Como substituir ferramentas de código aberto por serviços do GCP

O GCP oferece muitos produtos que podem ser usados com o sistema Hadoop. Geralmente, usar um produto do GCP oferece benefícios em relação à execução do produto de código aberto equivalente no GCP. Saiba mais sobre os produtos e os serviços do GCP para descobrir o que a plataforma oferece.

Como usar regiões e zonas

É necessário compreender as repercussões de geografia e regiões antes de configurar os dados e os jobs. Muitos serviços do GCP exigem que você especifique regiões ou zonas em que os recursos serão alocados. A latência das solicitações pode aumentar quando elas forem feitas em uma região diferente daquela em que os recursos estão armazenados. Além disso, se os recursos do serviço e os dados persistentes estiverem localizados em regiões diferentes, algumas chamadas para os serviços do GCP poderão copiar todos os dados necessários de uma zona para outra antes do processamento. Isso pode causar um grande impacto no desempenho.

Como configurar autenticação e permissões

Seu controle sobre as permissões nos serviços do GCP provavelmente será menos refinado do que você está acostumado no ambiente do Hadoop local. Compreenda como o gerenciamento de acesso funciona no GCP antes de começar a migração.

Com o Cloud Identity and Access Management (Cloud IAM), você gerencia o acesso aos recursos da nuvem. Ele funciona com base em contas e papéis. As contas identificam um usuário ou solicitação (autenticação) e os papéis concedidos a uma conta determinam o nível de acesso (autorização). A maioria dos serviços do GCP fornece o próprio conjunto de papéis para você ajustar as permissões. Como parte do processo de planejamento da migração, você precisa aprender sobre como o Cloud IAM interage com o Cloud Storage e com o Cloud Dataproc. Saiba mais sobre os modelos de permissões de cada serviço do GCP adicional à medida que você os adiciona ao seu sistema. Pense em como definir papéis que funcionem nos serviços que você usa.

Como monitorar jobs com o Stackdriver Logging

Seus jobs do GCP enviam registros para o Logging, onde eles são facilmente acessíveis. Você consegue registros das maneiras a seguir:

Como gerenciar nós de borda com o Compute Engine

Você pode usar o Compute Engine para acessar um nó de borda em um cluster do Hadoop do Cloud Dataproc. Assim como na maioria dos produtos do GCP, você tem várias opções de gerenciamento: por meio do console baseado na Web, a partir da linha de comando e por meio de APIs da Web.

Como usar serviços de Big Data do GCP

O Cloud Storage é a principal forma de armazenar dados não estruturados no GCP, mas não é a única opção de armazenamento. É possível armazenar alguns dos seus dados de maneira mais adequada nos produtos projetados explicitamente para Big Data.

Use o Cloud Bigtable para armazenar grandes quantidades de dados esparsos. O Cloud Bigtable é uma API compatível com o HBase que oferece baixa latência e alta escalonabilidade para se adaptar aos seus jobs.

Para armazenamento de dados, você pode usr o BigQuery.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Como migrar o Hadoop para o GCP