Como migrar dados do HDFS do local para o Google Cloud Platform

Neste guia, descreveremos o processo de movimentação de dados do HDFS (Hadoop Distributed File System) para o Google Cloud Platform (GCP).

Este é o segundo dos três guias que descrevem como migrar do Hadoop local:

Como planejar a migração dos dados

Nas seções a seguir, descrevemos as práticas recomendadas para planejar a migração de dados do HDFS local para o GCP. Recomendamos que você planeje migrar de modo incremental, deixando tempo para migrar jobs e fazer experiências e testar depois de mover cada corpo de dados.

Decidir como mover os dados

Há dois modelos de migração diferentes que você pode considerar para transferir dados do HDFS para a nuvem: push e pull. Ambos os modelos usam o Hadoop DistCp para copiar dados dos seus clusters HDFS locais para o Cloud Storage, mas usam abordagens diferentes.

O modelo de push é o mais simples: o cluster de origem executa os jobs distcp nos nodes de dados e envia os arquivos diretamente para o Cloud Storage, conforme mostrado aqui:

Migrar dados do HDFS usando o modelo de push

O modelo de pull é mais complexo, mas tem algumas vantagens. Um cluster efêmero do Cloud Dataproc executa os jobs distcp nos nodes de dados, extrai arquivos do cluster de origem e os copia para o Cloud Storage, conforme mostrado aqui:

Migrar dados do HDFS usando o modelo de pull

O modelo de push é o mais simples porque o cluster de origem pode enviar dados diretamente para o Cloud Storage e você não precisa criar recursos de computação extra para realizar a cópia. No entanto, se você pretende continuar usando o cluster de origem durante a migração para outros jobs comuns de processamento de dados, verifique se há recursos suficientes, como CPU, RAM e largura de banda de rede, disponíveis no cluster de origem para executar também os jobs de cópia.

Se o cluster de origem já estiver sendo executado na capacidade de computação máxima e você não puder aumentar os recursos no cluster de origem para realizar a cópia, considere o uso do modelo de pull.

Embora seja mais complexo que o modelo de push, o modelo de pull tem várias vantagens:

  • O impacto nos recursos de CPU e RAM do cluster de origem é minimizado, porque os nodes de origem são usados apenas para enviar blocos para fora do cluster. Também é possível ajustar as especificações dos recursos do cluster de pull no GCP para manipular os jobs de cópia e desmontar o cluster de pull quando a migração estiver concluída.
  • O tráfego na rede do cluster de origem é reduzido, o que permite maiores larguras de banda de saída e transferências mais rápidas.
  • Não há necessidade de instalar o conector do Cloud Storage connector no cluster de origem, porque o cluster efêmero do Cloud Dataproc, que já tem o conector instalado, lida com a transferência de dados para o Cloud Storage.

Para entender as implicações para o uso da rede nos dois modelos, considere como o Hadoop lida com a replicação de dados no HDFS. O Hadoop divide cada arquivo em vários blocos, geralmente com tamanho de 128 a 256 megabytes. O Hadoop replica esses blocos em vários nodes de dados e em vários racks para evitar a perda de dados no caso de uma falha no node de dados ou uma falha no rack. A configuração padrão é armazenar três réplicas de cada bloco.

O Hadoop também usa o "reconhecimento de rack", que garante que duas cópias de cada bloco estejam em nodes de dados diferentes dentro do mesmo rack para reduzir a latência e uma terceira cópia em um rack diferente para maior redundância e disponibilidade. Essa lógica de replicação é resumida no diagrama a seguir:

Replicação de blocos HDFS com reconhecimento de rack

Ao copiar um arquivo usando o modelo de push, ou seja, quando a tarefa de mapeamento distcp é executada em um node de dados do cluster de origem, todos os blocos do arquivo são coletados primeiro a partir dos vários nodes de dados. Depois, os blocos do arquivo são enviados do cluster de origem para o Cloud Storage. O tráfego na rede pode levar quase o dobro do tamanho total do arquivo, conforme ilustrado no diagrama a seguir:

Uso de rede ao usar o modelo de push

Ao copiar um arquivo usando o modelo de pull, ou seja, quando a tarefa de mapeamento distcp é executada em um node de dados do cluster de pull no GCP, cada bloco viaja pela rede apenas uma vez, saindo do cluster de origem diretamente. O tráfego geral da rede é limitado ao tamanho total do arquivo, conforme ilustrado no diagrama a seguir:

Uso de rede ao usar o modelo de pull

Ao modelo de pull, é preciso monitorar o número de tarefas de mapeamento distcp e a largura de banda usada para evitar sobrecarregar o cluster de origem com muitas conexões paralelas.

Como decidir para onde mover os dados

O resultado final da migração do Hadoop pode ser uma solução nativa da nuvem ou uma solução híbrida. A diferença entre elas é se seu sistema reterá quaisquer componentes no local. Em uma solução nativa da nuvem, você armazena os dados na nuvem e executa jobs nela. Em uma solução híbrida, alguns dos dados permanecem no local. Você também pode executar jobs nesses dados no local ou executar jobs na nuvem que funcionam com dados locais.

Uma solução nativa da nuvem é mais fácil de manter, mas você pode ter requisitos comerciais ou técnicos que mantenham alguns dados ou processamento no local. Cada solução híbrida é altamente dependente de maiúsculas e minúsculas, incluindo a próprio mistura de tecnologias e serviços para atender às necessidades da carga de trabalho.

Como mover dados para produtos diferentes do Cloud Storage

Recomendamos mover a maioria dos seus dados para o Cloud Storage. No entanto, há alguns casos em que você pode pensar na transferência de dados para um produto do GCP diferente:

  • Se você estiver migrando dados do Apache HBase, pense em transferi-los para o Cloud Bigtable, que fornece recursos equivalentes.

  • Se você estiver migrando dados do Apache Impala, pense em transferi-los para o BigQuery, que fornece recursos equivalentes.

Você pode ter dados no HBase ou no Impala que podem ser usados sem armazená-los no Cloud Bigtable ou no BigQuery. Se seu job não exigir os recursos do Cloud Bigtable ou BigQuery, armazene os dados no Cloud Storage.

Como planejar locais de dados com permissões em mente

O GCP não usa as mesmas permissões refinadas para arquivos que você pode acessar com o HDFS local. A abordagem menos complicada para permissões de arquivo é configurá-las no nível de cada intervalo do Cloud Storage. Se você tiver definido permissões diferentes para conjuntos diferentes de dados do HDFS, pense em criar intervalos distintos no Cloud Storage para que cada um deles tenha permissões próprias. Em seguida, coloque os dados do HDFS no intervalo que tem as permissões adequadas para esses dados.

Se você mover arquivos para uma estrutura que é diferente no Cloud Storage em relação ao HDFS, lembre-se de acompanhar todas as alterações. Ao migrar os jobs para o Cloud Dataproc, você precisará fornecer os caminhos certos para os dados nos novos locais.

Como planejar uma migração incremental

Planeje mover seus dados em partes distintas ao longo do tempo. Programe bastante tempo para mover os jobs correspondentes para a nuvem entre as movimentações de dados. Inicie sua migração movendo dados de baixa prioridade, como backups e arquivos.

Como dividir seus dados

Se você planeja mover os dados incrementalmente, será necessário dividi-los em várias partes. Nas seções a seguir, descreveremos as estratégias mais comuns para dividir conjuntos de dados.

Como dividir dados por carimbos de data/hora

Uma abordagem comum para dividir dados para uma migração incremental é armazenar dados mais antigos na nuvem, mantendo os novos no HDFS no seu sistema local. Isso permite testar jobs novos e migrados em dados mais antigos e menos críticos. Dividir seus dados dessa maneira permite que você inicie a migração com pequenas quantidades.

Considerações importantes:

  • É possível dividir os dados usando outro método além da divisão por tempo? Você pode conseguir um conjunto de dados mais segmentado dividindo-os pelos jobs que ele aceita ou pela organização a que pertencem, e depois dividindo-os ainda mais por tempo.
  • É preciso usar uma data/hora absoluta ou uma data/hora relativa? Às vezes, faz sentido dividir os dados em um momento específico, como arquivar todos os dados gerados antes de uma alteração importante no sistema. O uso de uma data/hora absoluta geralmente é apropriado se você quiser fazer jobs de preenchimento para testar seu sistema na nuvem a fim de processar dados antigos para adequá-los aos padrões atuais. Em outros casos, você pode querer mover dados para a nuvem com base em um carimbo de data/hora relativo à data atual. Por exemplo, você pode mover todos os dados que foram criados há mais de um ano ou todos os dados que não foram editados nos últimos três meses.
  • Qual valor de data/hora você está usando para tomar a decisão? Os arquivos geralmente têm vários valores de data/hora. Às vezes, a data de criação do arquivo é a mais importante. Outras vezes, você pode querer usar o último horário editado ou outro registro de data e hora dos metadados do arquivo.
  • Todos os dados têm o mesmo formato de carimbo de data/hora? Há muitas maneiras de lidar com carimbos de data/hora. Se os dados vierem de mais de uma fonte, é possível que os carimbos de data/hora sejam armazenados em formatos diferentes. Certifique-se de ter carimbos de data/hora consistentes antes de usá-los para dividir seus dados.

Como dividir dados por jobs

Em alguns casos você pode dividir seus dados observando os jobs que os usam. Isso pode ser especialmente útil se você estiver migrando jobs de modo incremental. Você pode mover apenas os dados usados pelos jobs que você move.

Considerações importantes:

  • Os jobs que você está migrando para a nuvem são independentes? A divisão por jobs é uma ótima opção para jobs que trabalham com unidades de dados independentes, mas pode se tornar difícil de gerenciar se os jobs trabalharem com dados espalhados pelo sistema.
  • É provável que os dados tenham os mesmos usos no futuro? Pense cuidadosamente antes de isolar os dados caso haja a possibilidade de usá-los de maneiras diferentes.
  • A migração dos jobs é limitada adequadamente para resultar em partes de dados gerenciáveis?

Você também pode usar critérios funcionais mais amplos para dividir os dados em vez de apenas conjuntos específicos de jobs. Por exemplo, você pode executar todo seu trabalho de ETL na nuvem e, em seguida, executar jobs de análise e geração de relatórios no local.

Como dividir dados por propriedade

Em alguns casos, você pode dividir os dados por áreas de propriedade. Uma vantagem de adotar essa abordagem é que sua organização de dados se alinha à organização da sua empresa. Outra vantagem é que ela permite aproveitar o gerenciamento de acesso baseado em papéis do GCP. Por exemplo, a migração de dados usados por um papel comercial específico para um intervalo do Cloud Storage isolado facilita a configuração de permissões.

Considerações importantes:

  • Os limites entre os proprietários são claros? Geralmente, fica claro quem é o proprietário principal de um determinado item de dados. Às vezes, as pessoas que acessam com mais frequência os dados não são os proprietários.
  • Há outros critérios de divisão que possam ser combinados com a propriedade? Você pode acabar com conjuntos de dados muito grandes após a divisão por propriedade. Pode ser útil restringir ainda mais as coisas dividindo os dados novamente por tarefa ou por hora.

Como manter os dados sincronizados em uma solução híbrida

Um dos desafios de usar uma solução híbrida é que às vezes um job precisa acessar dados do GCP e dos sistemas locais. Se um conjunto de dados precisar ser acessado em ambos os ambientes, você precisará estabelecer um local de armazenamento principal para ele em um ambiente e manter uma cópia sincronizada no outro.

Os desafios da sincronização de dados são semelhantes, independentemente da localização principal escolhida. Você precisa de uma maneira de identificar quando os dados foram alterados e um mecanismo para propagar as alterações nas cópias correspondentes. Se houver um potencial para alterações conflitantes, você também precisará desenvolver uma estratégia para resolvê-las.

Considerações importantes:

  • Sempre faça cópias de dados somente leitura, se possível. Sua estratégia de sincronização se torna mais complexa com cada possível fonte de novas edições.
  • Em uma solução híbrida, evite manter mais de duas cópias de dados. Mantenha somente uma cópia no local e somente uma no GCP.

Você pode usar tecnologias como o Apache Airflow para ajudar a gerenciar a sincronização de dados.

Como migrar os dados

Nas seções a seguir, descreveremos considerações sobre a migração de dados para o GCP.

Como configurar o acesso aos dados

As permissões de arquivo funcionam de maneira diferente no Cloud Storage e no HDFS. Antes de mover os dados para o Cloud Storage, você precisa se familiarizar com o Cloud Identity and Access Management (Cloud IAM).

A maneira mais fácil de lidar com o controle de acesso é classificar os dados em intervalos do Cloud Storage com base nos requisitos de acesso e configurar sua política de autorização no nível do intervalo. Você pode atribuir papéis que concedam acesso a usuários individuais ou a grupos. Recomendamos conceder acesso por grupos e, em seguida, atribuir usuários a grupos conforme necessário. É preciso tomar decisões de acesso a dados à medida que você importa e estrutura os dados no Cloud Storage.

Todo produto do GCP tem os próprios papéis e permissões. Certifique-se de compreender os relacionamentos entre os controles de acesso do Cloud Storage e os do Cloud Dataproc. Avalie as políticas para cada produto separadamente. Não presuma que os papéis e as permissões sejam mapeados diretamente entre os produtos.

Familiarize-se com a documentação a seguir para se preparar para tomar decisões sobre políticas no sistema Hadoop baseado em nuvem:

Se você precisar atribuir permissões mais refinadas a arquivos individuais, o Cloud Storage é compatível com listas de controle de acesso (ACLs, na sigla em inglês). No entanto, o IAM é a opção preferida. Use ACLs somente se suas permissões forem particularmente complexas.

Como usar o DistCp para copiar dados para o Cloud Storage

Como o Cloud Storage é um sistema de arquivos compatível com Hadoop, você pode usar o Hadoop DistCp para mover seus dados do HDFS local para o Cloud Storage. É possível mover dados de várias maneiras usando o DistCp. Recomendamos desta forma:

  1. Use o Cloud VPN para estabelecer um túnel de rede privada virtual entre seu projeto do GCP e sua rede local.
  2. Crie um cluster do Cloud Dataproc para usar na transferência de dados.
  3. Use a ferramenta de linha de comando gcloud para se conectar à instância mestre do cluster. Por exemplo:

    gcloud compute ssh [CLUSTER_NAME]-m
    

    Em que CLUSTER_NAME é o nome do cluster do Cloud Dataproc que você criou para o job. O sufixo -m identifica a instância mestre.

  4. Na instância mestre do cluster, execute os comandos DistCp para mover os dados.

Os comandos DistCp reais que você precisa para mover os dados são semelhantes aos que aparecem a seguir:

hadoop distcp hdfs://nn1:9820/20170202/ gs://bucket/20170202/

Neste exemplo, nn1 e 9820 são o namenode e a porta em que os dados de origem estão armazenados, e bucket é o nome do intervalo do Cloud Storage para onde você está copiando o arquivo.

Como melhorar a velocidade de migração de dados

A maneira mais simples de transferir dados dos clusters locais para o GCP é usar um túnel de VPN na Internet pública. Se um único túnel VPN não oferecer a capacidade necessário, vários túneis de VPN poderão ser criados e o GCP distribuirá automaticamente o tráfego por eles para fornecer mais largura de banda.

Às vezes, mesmo utilizando vários túneis de VPN, a largura de banda fornecida não será suficiente ou a não haverá estabilidade de conexão para atender às necessidades da migração. Pense nas abordagens a seguir para melhorar a capacidade:

Como trabalhar com parceiros do GCP

O GCP trabalha com diversos parceiros que podem ajudar você a migrar dados. Confira os parceiros que trabalham com o Cloud Storage para conseguir mais informações sobre os serviços disponíveis para ajudá-lo na migração de dados. Os serviços e termos disponíveis variam de acordo com o fornecedor, portanto, trabalhe diretamente com eles para receber detalhes.

Próximas etapas

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

Enviar comentários sobre…

Como migrar o Hadoop para o GCP