Neste guia, fornecemos uma visão geral de como mover o sistema Apache Hadoop no local para o Google Cloud. Nele, descrevemos um processo de migração que não apenas move seu trabalho do Hadoop para o Google Cloud, mas também permite que você adapte seu trabalho para aproveitar os benefícios de um sistema Hadoop otimizado para computação em nuvem. Neste documento, apresentamos alguns conceitos fundamentais que você precisa entender para converter sua configuração do Hadoop para o Google Cloud.
Este é o primeiro de vários guias que descrevem como migrar do Hadoop no local:
- Este guia fornece conselhos de contexto e planejamento para sua migração.
- Como migrar dados do HDFS no local para o Google Cloud fornece mais contexto para mover seus dados de maneira incremental para o Google Cloud.
- Como migrar dados do HBase para o Bigtable
- Como migrar jobs do Hadoop no local para o Dataproc descreve o processo de execução de seus jobs no Dataproc e em outros produtos do Google Cloud.
Os benefícios da migração para o Google Cloud
Há muitas maneiras de usar o Google Cloud para economizar tempo, dinheiro e esforço em comparação com o uso de uma solução Hadoop no 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 Google Cloud inclui o Dataproc, que é um ambiente gerenciado do Hadoop e do Spark. É possível usar o Dataproc para executar a maioria dos jobs atuais com o mínimo de alterações. Assim, você não precisa sair de todas as ferramentas do Hadoop que já conhece.
Configuração e hardware gerenciado
Você nunca precisa se preocupar com hardware físico ao executar o Hadoop no Google Cloud. Você especifica a configuração do cluster e o Dataproc aloca recursos para você. É possível 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. Quando você usa o Dataproc, grande parte desse trabalho é gerenciada pelo controle de versões do Dataproc.
Configuração de job flexível
Uma configuração típica do Hadoop no local usa um cluster que atende a vários propósitos. Ao mover para o Google Cloud, é possível se concentrar em tarefas individuais, criando quantos clusters precisar. Isso elimina grande parte da complexidade da manutenção de um cluster com dependências crescentes e interações de configuração de software.
Como planejar a migração
A migração de uma solução Hadoop no local para o Google Cloud requer uma mudança de abordagem. Um típico sistema Hadoop no local 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 Google Cloud, a complexidade administrativa é reduzida. No entanto, para conseguir essa simplificação e tornar o processamento mais eficiente no Google Cloud com o custo mínimo, é necessário repensar como estruturar seus dados e jobs.
Como o Dataproc executa o Hadoop no Google Cloud, usar um cluster permanente do Dataproc para replicar sua configuração no local pode parecer a solução mais fácil. No entanto, há algumas limitações nessa abordagem:
- Manter seus dados em um cluster HDFS permanente usando o Dataproc é mais caro do que armazenar os dados no Cloud Storage, o que recomendamos, conforme explicado mais adiante. Manter os dados em um cluster HDFS também limita sua capacidade de usar seus dados com outros produtos do Google Cloud.
- Aumentar ou substituir algumas das suas ferramentas de código aberto por outros serviços relacionados do Google Cloud pode ser mais eficiente ou econômico para casos de uso específicos.
- Usar um cluster permanente do Dataproc para os jobs é mais difícil de gerenciar do que mudar para clusters segmentados que atendem a jobs individuais ou áreas de jobs.
A maneira mais econômica e flexível de migrar seu sistema Hadoop para o Google Cloud é deixar de pensar em termos de clusters grandes, multiuso e permanentes e, em vez disso, pensar em clusters pequenos e de curta duração 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 temporário, 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 no local para um modelo temporário no Google Cloud.
O exemplo move quatro jobs executados em dois clusters locais para o Dataproc. Os clusters temporários usados para executar os jobs no Google Cloud 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, é possível personalizar e otimizar clusters para jobs individuais ou para grupos de jobs de modo que faça sentido para seu trabalho específico. O Dataproc ajuda você a definir rapidamente vários clusters, colocá-los on-line e escaloná-los de acordo com suas necessidades.
Os dados no exemplo são movidos de dois clusters do HDFS no local para buckets do Cloud Storage. Os dados no primeiro cluster são divididos em vários buckets, e o segundo cluster é movido para um único bucket. É possível personalizar a estrutura dos dados no Cloud Storage para atender às necessidades dos seus aplicativos e da sua empresa.
O exemplo de migração captura os estados inicial e final de uma migração completa para o Google Cloud. Isso é uma etapa, mas você terá os melhores resultados se não pensar na migração para o Google Cloud como um processo único e completo. 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.
Sequência recomendada para migrar para o Google Cloud
Veja os passos recomendados para migrar seus fluxos de trabalho para o Google Cloud:
Mova os dados primeiro
- Mova os dados para os buckets do Cloud Storage.
- Vá aos poucos. Use dados de backup ou arquivados para minimizar o impacto no sistema Hadoop atual.
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 para o Google Cloud e os conceitos de computação em nuvem.
Pense em termos de clusters especializados e temporários.
- 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.
Use as ferramentas do Google Cloud sempre que for adequado.
Como migrar para um modelo temporário
A maior mudança na abordagem entre executar um fluxo de trabalho do Hadoop no local e executá-lo no Google Cloud é a mudança dos clusters monolíticos e permanentes para os especializados e temporários. 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:
- Ficou mais fácil gerenciar as permissões de acesso.
- É 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.
- É mais fácil migrar dados do que o HDFS.
- Permite que você use facilmente seus dados com toda a gama de produtos do Google Cloud.
- É consideravelmente mais barato do que manter seus dados no HDFS em um cluster permanente do Dataproc.
Com os dados armazenados de maneira permanente no Cloud Storage, é possível executar os jobs em clusters temporários do Hadoop gerenciados pelo Dataproc.
Em alguns casos, pode fazer mais sentido mover dados para outra tecnologia do Google Cloud, como o BigQuery ou o Bigtable. Mas é necessário que a maioria dos dados de uso geral permaneça no Cloud Storage. Mais adiante neste guia, você verá detalhes sobre essas opções alternativas de armazenamento.
Executar jobs em clusters temporários
O Dataproc facilita a criação e a exclusão de clusters. Assim, é possível usar muitos clusters temporários em vez de um monolítico. Essa abordagem tem várias vantagens:
- Evite pontos únicos de falha e aumente a confiabilidade do pipeline de dados. Quando um cluster compartilhado de longa duração é executado em um estado de erro, todo o pipeline de dados pode ser bloqueado. O reparo de um cluster de longa duração com estado pode levar muito tempo, causando violações do objetivo de nível de serviço (SLO, na sigla em inglês). Por outro lado, um cluster temporário sem estado problemático pode ser facilmente excluído e recriado com novas tentativas de job.
- É possível ter desempenhos de job mais previsíveis e evitar violações de SLO ao eliminar as contenções de recursos entre os jobs.
- É possível otimizar as configurações de cluster e as políticas de escalonamento automático para jobs individuais.
- Receba os patches de segurança, as correções de bugs e as otimizações mais recentes ao criar um cluster temporário para um job.
- É possível evitar problemas comuns com clusters de longa duração, como discos cheios de registros e arquivos temporários, ou falha no escalonamento do cluster devido ao estoque esgotado na zona.
- Você não precisa manter clusters ao longo do tempo porque eles são configurados sempre que você os usa. A não necessidade de manter clusters elimina o trabalho administrativo de gerenciar ferramentas entre jobs.
- 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.
- É possível solucionar problemas mais rapidamente com o cluster isolado de job único.
- Você paga pelos recursos somente quando eles forem usados pelos jobs.
Use as ações de inicialização do 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. Os exemplos demonstram como fazer suas 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:
Crie um cluster configurado corretamente.
Execute o job enviando a saída para o Cloud Storage ou outro local persistente.
Exclua o cluster.
Use a saída do job como for necessário.
Veja os registros no Cloud Logging ou no Cloud Storage.
Esse processo é mostrado no diagrama a seguir:
Usar clusters permanentes 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:
Mova uma parte dos dados para o Google Cloud.
Teste esses dados:
Replique seus jobs existentes que usam os dados.
Faça novos protótipos que funcionem com os dados.
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. Configure jobs que preencham lacunas no processamento de dados que existiam antes de seus jobs atuais estarem em vigor. Começar com jobs em sequência geralmente oferece experiência com escalonamento no Google Cloud no início do plano de migração. Isso pode ajudar no momento da migração de jobs mais importantes.
Veja no diagrama a seguir um exemplo de uma arquitetura híbrida de preenchimento típica.
O exemplo tem dois componentes principais. Primeiro, os jobs programados em execução no cluster no local enviam dados para o Cloud Storage por meio de um gateway da Internet. Depois, os jobs de preenchimento são executados em clusters temporários do Dataproc. Além do preenchimento, é possível usar clusters temporários no Google Cloud em testes e na criação de provas de conceito para trabalhos futuros.
Como planejar com a migração completa em mente
Até agora, foi considerado neste guia que sua meta é mover todo o sistema Hadoop no local para o Google Cloud. Um sistema do Hadoop em execução no Google Cloud é mais fácil de gerenciar do que um 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 executados no local, e esses sistemas não podem interagir com o Google Cloud devido a restrições técnicas ou comerciais.
Uma solução híbrida típica tem quatro partes principais:
Um cluster do Hadoop no local
Uma conexão do cluster no local com o Google Cloud
Armazenamento de dados centralizado no Google Cloud
Componentes nativos da nuvem que funcionam em dados no Google Cloud
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ê tem uma solução híbrida em que apenas os dados arquivados são armazenados no Google Cloud. É possível configurar jobs programados para mover os dados do cluster no local para o Google Cloud quando os dados atingirem uma idade especificada. Em seguida, configure todos os jobs que funcionam nos dados arquivados no Google Cloud para que você nunca precise sincronizar alterações nos clusters no local.
Outra maneira de dividir seu sistema é mover todos os dados e trabalhar para um projeto ou grupo de trabalho específico ao Google Cloud, mantendo outros trabalhos no local. Assim, você se concentra nos seus jobs em vez de criar sistemas complexos de sincronização de dados.
Talvez você se preocupe com a segurança ou a logística que dificultam a forma como seu cluster no local é conectado ao Google Cloud. Uma solução é usar uma nuvem privada virtual conectada à sua rede local usando o Cloud VPN.
O diagrama a seguir mostra um exemplo de configuração de nuvem híbrida:
A configuração de exemplo usa o Cloud VPN para conectar uma VPC do Google Cloud a um cluster no local. O sistema usa o Dataproc dentro da VPC para gerenciar clusters permanentes que processam dados provenientes do sistema no local. Isso pode envolver a sincronização de dados entre os sistemas. Esses clusters permanentes do Dataproc também transferem dados do sistema no local para os serviços de armazenamento adequados no Google Cloud. Para fins de ilustração, o exemplo usa o Cloud Storage, o BigQuery e o Bigtable para armazenamento. Esses são os destinos mais comuns para dados processados por cargas de trabalho do Hadoop no Google Cloud.
A outra metade da solução de exemplo mostra vários clusters temporários 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 você executa todos os jobs no Google Cloud usando dados armazenados no Cloud Storage, evita a complexidade da sincronização de dados, embora ainda seja preciso ter cuidado com o uso dos mesmos jobs.
Veja no diagrama a seguir um exemplo de um sistema nativo da nuvem:
O sistema de exemplo tem alguns clusters persistentes e alguns efêmeros. Os dois tipos de clusters compartilham ferramentas e recursos de nuvem, incluindo armazenamento e monitoramento. O Dataproc usa imagens de máquina padronizadas para definir configurações de software em VMs em 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 temporários.
Como trabalhar com os serviços do Google Cloud
Nesta seção, discutimos algumas considerações sobre a migração do Hadoop para o Google Cloud.
Como substituir ferramentas de código aberto por serviços do Google Cloud
O Google Cloud oferece muitos produtos que podem ser usados com seu sistema Hadoop. O uso de um produto do Google Cloud geralmente oferece benefícios em relação à execução do produto de código aberto equivalente no Google Cloud. Saiba mais sobre os produtos e serviços do Google Cloud para descobrir tudo o que a plataforma tem a oferecer.
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 Google Cloud exigem que você especifique regiões ou zonas para alocar recursos. 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 permanentes estiverem localizados em diferentes regiões, algumas chamadas para os serviços do Google Cloud 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 Google Cloud provavelmente será menos refinado do que você está acostumado no ambiente Hadoop no local. Entenda como o gerenciamento de acesso funciona no Google Cloud antes de iniciar a migração.
O gerenciamento de identidade e acesso (IAM) 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 Google Cloud fornece o próprio conjunto de papéis para que você ajuste as permissões. Como parte do processo de planejamento da migração, você precisa saber como o IAM interage com o Cloud Storage e com o Dataproc. Saiba mais sobre os modelos de permissões de cada serviço extra do Google Cloud à medida que você o adiciona ao seu sistema e pense em como definir papéis que funcionem nos serviços que você usa.
Como monitorar jobs com o Cloud Logging
Os jobs do Google Cloud enviam registros para o Cloud Logging, onde os registros podem ser acessados com facilidade. Você consegue registros das maneiras a seguir:
- Com uma interface gráfica baseada em navegador usando o visualizador de registros no Console do Google Cloud
- A partir de uma janela de terminal local usando a Google Cloud CLI.
- Com scripts ou aplicativos que usam as bibliotecas de cliente do Cloud para a API Cloud Logging
- Chamando a API REST do Cloud Logging
Como gerenciar nós de borda com o Compute Engine
Use o Compute Engine para acessar um nó perimetral em um cluster do Hadoop do Dataproc. Como na maioria dos produtos do Google Cloud, você tem várias opções de gerenciamento: por meio do console baseado na Web, da linha de comando e das APIs da Web.
Como usar os serviços de Big Data do Google Cloud
O Cloud Storage é a principal maneira de armazenar dados não estruturados no Google Cloud, 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 Bigtable para armazenar grandes quantidades de dados esparsos. O Bigtable é uma API compatível com 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
Confira as outras partes do guia de migração do Hadoop:
Confira a documentação do Dataproc.
Tenha uma visão geral do Google Cloud.
Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.