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

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

Este é o segundo de quatro guias que descrevem como migrar do Hadoop local:

Como planejar a migração dos dados

As seções a seguir descrevem as práticas recomendadas para planejar a migração de dados do HDFS local para o GCP. Programe-se para mover dados de maneira incremental e dedique um tempo para migrar jobs e fazer testes depois de mover cada conjunto de dados.

Como decidir a forma de 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 utilizam abordagens diferentes.

O modelo de push é o mais simples: o cluster de origem executa os jobs distcp nos nós de dados e envia os arquivos diretamente para o Cloud Storage, conforme mostrado no diagrama a seguir:

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 nós de dados, extrai arquivos do cluster de origem e os copia para o Cloud Storage, conforme mostrado no diagrama a seguir:

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 outros recursos de computação para fazer 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.

Apesar de ser 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 nós de origem são usados apenas para enviar blocos para fora do cluster. É possível também ajustar as especificações dos recursos do cluster de pull no GCP para processar 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 é necessário instalar o conector do Cloud Storage no cluster de origem como o cluster efêmero do Cloud Dataproc, que já tem o conector instalado e processa a transferência de dados para o Cloud Storage.

Para entender as implicações para o uso da rede nos dois modelos, analise como o Hadoop faz a replicação de dados no HDFS. Ele 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. É possível que o tráfego na rede seja 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 nó de dados do cluster de pull no GCP), cada bloco é transmitido pela rede apenas uma vez, saindo diretamente do cluster de origem. 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 usar o 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

Mova a maioria dos seus dados para o Cloud Storage. No entanto, em alguns casos, é recomendável fazer a transferência de dados para outro produto do GCP:

  • Se você estiver migrando dados do Apache HBase, transfira-os para o Cloud Bigtable, que oferece recursos equivalentes.

  • Se você estiver migrando dados do Apache Impala, transfira-os para o BigQuery, que oferece recursos equivalentes.

É possível ter dados no HBase ou no Impala e usá-los sem precisar 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 mais simples para permissões de arquivo é configurá-las no nível de cada intervalo do Cloud Storage. Se você tiver definido permissões distintas para diferentes conjuntos de dados do HDFS, crie outros intervalos 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 eles.

Se você mover arquivos para uma estrutura no Cloud Storage que é diferente em relação à do HDFS, lembre-se de registrar 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. Reserve bastante tempo para mover os jobs correspondentes para a nuvem entre as movimentações de dados. Inicie a migração movendo dados de baixa prioridade, como backups e arquivos.

Como dividir os 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.

Observações importantes:

  • É possível dividir os dados usando outro método além da divisão por tempo? Para ter um conjunto de dados mais segmentado, divida-os pelos jobs que eles aceitam ou pela organização a que pertencem e, em seguida, divida-os pelo tempo.
  • É preciso usar uma data/hora absoluta ou relativa? Às vezes, faz sentido dividir os dados em um momento específico, como ao arquivar todas as informações geradas antes de uma alteração importante no sistema. Geralmente, é apropriado usar uma data e hora absoluta se você quer criar jobs de preenchimento para testar o sistema na nuvem e saber se é possível processar dados antigos com o objetivo de adequá-los aos padrões atuais. Em outros casos, talvez você queira mover dados para a nuvem com base em um carimbo de data/hora relativo à data atual. Por exemplo, é possível mover todos os dados que foram criados há mais de um ano ou todos aqueles 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. Em outras circunstâncias, talvez você queira usar o último horário editado ou outro carimbo de data/hora dos metadados do arquivo.
  • Todos os dados têm o mesmo formato de carimbo de data/hora? Há muitas maneiras de usar carimbos de data/hora. Se os dados vierem de mais de uma fonte, é possível que os carimbos sejam armazenados em formatos diferentes. Verifique se os carimbos de data/hora são 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 funcionam em unidades de dados independentes, mas pode ser de difícil gerenciamento se eles funcionarem com dados espalhados pelo sistema.
  • É provável que os dados tenham os mesmos usos no futuro? Pense bem antes de isolar os dados caso haja a possibilidade de usá-los de maneiras diferentes.
  • O escopo da migração dos jobs é definido adequadamente de modo a resultar em partes de dados gerenciáveis?

Você também tem a opção de usar critérios funcionais mais amplos para dividir dados em vez de apenas conjuntos de jobs. Por exemplo, é possível 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? A divisão por propriedade pode resultar em conjuntos de dados muito grandes. Pode ser útil dividir os dados novamente por tarefa ou por hora para restringir ainda mais o escopo deles.

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, será necessário estabelecer um local de armazenamento principal em um ambiente e manter uma cópia sincronizada no outro.

Os desafios da sincronização de dados são semelhantes, independentemente do local principal escolhido. É preciso ter 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 uma no GCP.

Use 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. Atribua papéis que concedam acesso a usuários individuais ou a grupos. Conceda acesso por grupos e, em seguida, atribua os usuários aos grupos conforme necessário. É preciso tomar decisões de acesso a dados à medida que você os importa e estrutura 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.

Conheça melhor 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). No entanto, o Cloud IAM é a opção preferida. Use ACLs somente se as permissões forem muito 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 fazer isso desta forma:

  1. Use o Cloud VPN para estabelecer um túnel de rede privada virtual entre o projeto do GCP e a 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:8020/20170202/ gs://bucket/20170202/

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

Como validar transferências de dados

Ao copiar ou mover dados entre sistemas de armazenamento distintos, como vários clusters HDFS ou entre o HDFS e o Cloud Storage, é recomendável realizar algum tipo de validação para garantir a integridade dos dados. Essa validação é essencial para garantir que eles não sejam alterados durante a transferência. Para mais detalhes, consulte o guia sobre Como validar transferências de dados.

Como aumentar a taxa de solicitação

O Cloud Storage mantém um índice de chaves de objeto para cada intervalo para fornecer uma listagem de objetos consistente. Esse índice é armazenado em ordem lexicográfica e é atualizado sempre que os objetos são gravados ou excluídos de um intervalo. Adicionar e excluir objetos que tenham chaves contidas em um pequeno intervalo do índice aumentará as chances de contenção.

O Cloud Storage detecta essa contenção e redistribui automaticamente a carga do intervalo do índice afetado em vários servidores. Se você estiver gravando objetos com um novo prefixo e antecipar que atingirá uma taxa maior que 1.000 solicitações de gravação por segundo, será necessário aumentar a taxa de solicitação gradualmente, conforme descrito na documentação do Cloud Storage. Se você não fizer isso, as taxas de latência e erro poderão ser temporariamente maiores.

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 não fornecer o rendimento necessário, vários túneis VPN poderão ser criados e o GCP distribuirá automaticamente o tráfego por eles para disponibilizar 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:

  • Use peering direto entre a rede e os pontos de extremidade de presença (PoPs, na sigla em inglês) do Google. Essa opção reduz o número de saltos entre sua rede e o GCP.

  • Use um provedor de serviços do Cloud Interconnect para estabelecer uma conexão direta com a rede do Google. Os detalhes do serviço variam de acordo com o parceiro. A maioria oferece um SLA para disponibilidade e desempenho da rede. Entre em contato com um provedor de serviços para saber mais.

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