Como migrar dados do HDFS do local para o Google Cloud

Last reviewed 2024-04-17 UTC

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

Este é o segundo de quatro 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 Google Cloud. Planeje a migração de forma incremental, separando tempo para migrar jobs, experimentos e testes após mover cada corpo 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 arquivos diretamente para o Cloud Storage, como mostrado no diagrama a seguir:

Como migrar dados do HDFS usando o modelo de push

O modelo de pull é mais complexo, mas tem algumas vantagens. Um cluster temporário do 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:

Como 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. Também é possível ajustar as especificações dos recursos do cluster de pull no Google Cloud para manipular os jobs de cópia e eliminar o cluster de pull quando a migração for 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, porque o cluster temporário do Dataproc, que já tem o conector instalado, manipula a transferência de dados para o Cloud Storage.

Para entender as implicações de uso de rede nos dois modelos, considere como o Hadoop manipula a replicação de dados no HDFS. O Hadoop divide cada arquivo em vários blocos. Geralmente, o tamanho do bloco é de 128 a 256 megabytes. O Hadoop replica esses blocos em vários nós de dados e em vários racks para evitar a perda de dados no caso de uma falha no nó 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 do HDFS com reconhecimento de rack

Quando você copia um arquivo usando o modelo de push (ou seja, quando a tarefa de mapeamento distcp é executada em um nó de dados do cluster de origem), todos os blocos do arquivo são coletados primeiro entre os vários nós 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 adotar o modelo de push

Quando você copia 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 Google Cloud), cada bloco percorre a rede apenas uma vez ao sair 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 adotar o modelo de pull

Ao usar o modelo de pull, monitore o número de tarefas de mapeamento distcp e a largura de banda usada para evitar sobrecarregar o cluster de origem com excesso de 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, convém considerar a migração dos dados para outro produto do Google Cloud:

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

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

Talvez haja dados no HBase ou no Impala que possam ser usados sem a necessidade de armazená-los no Bigtable ou no BigQuery. Se o job não exigir os recursos do Bigtable ou do BigQuery, armazene os dados no Cloud Storage.

Como planejar locais de dados considerando permissões

O Google Cloud não usa as mesmas permissões refinadas para arquivos que você consegue no HDFS local. A abordagem mais simples para permissões de arquivo é configurá-las no nível de cada bucket do Cloud Storage. Se você tiver definido permissões distintas para diferentes conjuntos de dados do HDFS, crie outros buckets no Cloud Storage para que cada um deles tenha permissões próprias. Em seguida, coloque os dados do HDFS no bucket 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 mover seus jobs para o Dataproc, você precisará fornecer os caminhos certos para seus 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 o trabalho de ETL (em inglês) na nuvem e, em seguida, executar jobs de análise e relatório 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 é a possibilidade de aproveitar o gerenciamento de acesso baseado em papéis do Google Cloud. Por exemplo, a migração de dados usados por um papel comercial específico para um bucket 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 Google Cloud e de 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 apenas uma cópia no local e apenas uma no Google Cloud.

Use tecnologias como o Apache Airflow para ajudar a gerenciar a sincronização de dados.

Como migrar os dados

As seções a seguir descrevem as considerações para mover seus dados para o Google Cloud.

Como configurar o acesso aos dados

As permissões de arquivo funcionam de maneira diferente no Cloud Storage e no HDFS. Antes de mover seus dados para o Cloud Storage, você precisa se familiarizar com o gerenciamento de identidade e acesso (IAM).

A maneira mais fácil de lidar com o controle de acesso é classificar os dados em buckets do Cloud Storage com base nos requisitos de acesso e configurar sua política de autorização no nível do bucket. 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.

Cada produto do Google Cloud tem permissões e papéis próprios. Entenda as relações entre os controles de acesso do Cloud Storage e os do 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). No entanto, o 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 desta forma:

  1. Estabeleça um link privado entre sua rede local e a do Google usando o Cloud Interconnect ou o Cloud VPN.

  2. Crie um cluster do Dataproc para usar na transferência de dados.

  3. Use a Google Cloud CLI para se conectar à instância mestre do cluster. Exemplo:

    gcloud compute ssh [CLUSTER_NAME]-m

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

  4. Na instância mestre do cluster, execute 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 nome do nó e a porta em que os dados de origem estão armazenados, e bucket é o nome do bucket do Cloud Storage para onde você está copiando o arquivo.

O tráfego do Cloud Storage é criptografado por padrão com o Transport Layer Security (TLS).

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 bucket 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 em um bucket. Se você adicionar e excluir objetos das chaves contidas em uma pequena faixa do índice, aumentará naturalmente as chances de contenção.

O Cloud Storage detecta essa contenção e redistribui automaticamente a carga da faixa do índice afetada. Essa redistribuição é feita por 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 Google Cloud é usar um túnel de VPN pela Internet pública. Se um único túnel de VPN não fornecer a capacidade necessária, vários túneis de VPN poderão ser criados. Neste caso, o Google Cloud distribuirá automaticamente o tráfego entre os túneis 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 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 Google Cloud.

  • 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 direto com um provedor de serviços para saber mais.

Como trabalhar com Google Cloud Partners

O Google Cloud trabalha com vários parceiros que podem ajudar você a migrar seus dados. Confira os parceiros que trabalham com o Cloud Storage para 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