Share via

Usar o Azure Data Factory para migrar dados de um cluster Hadoop local para o Armazenamento do Azure

  • Artigo

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Dica

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!

O Azure Data Factory fornece um mecanismo de alto desempenho, robusto e econômico para migrar dados em escala do HDFS local para o Armazenamento de Blobs do Azure ou o Azure Data Lake Storage Gen2.

O Data Factory oferece duas abordagens básicas para migrar dados do HDFS local para o Azure. Escolha a abordagem conforme seu cenário.

  • Modo DistCp do Data Factory (recomendado): no Data Factory, você pode usar o DistCp (cópia distribuída) para copiar os arquivos no estado em que se encontram para o Armazenamento de Blobs do Azure (incluindo a cópia em etapas) ou o Azure Data Lake Storage Gen2. Use o Data Factory integrado ao DistCp para aproveitar um cluster avançado existente e obter a melhor taxa de transferência de cópia. Você também obtém o benefício do agendamento flexível e de uma experiência de monitoramento unificada do Data Factory. Dependendo da sua configuração do Data Factory, a atividade Copy constrói automaticamente um comando DistCp, envia os dados para o cluster Hadoop e monitora o status da cópia. Recomendamos o modo do DistCp do Data Factory para migrar dados de um cluster Hadoop local para o Azure.
  • Modo do runtime de integração nativa do Data Factory: o DistCp não é uma opção em todos os cenários. Por exemplo, em um ambiente de Redes Virtuais do Azure, a ferramenta DistCp não dá suporte ao emparelhamento privado do Azure ExpressRoute com um ponto de extremidade de rede virtual do Armazenamento do Azure. Além disso, em alguns casos, não é conveniente usar o cluster Hadoop existente como um mecanismo para migrar dados, de modo a não colocar cargas pesadas no cluster, o que pode afetar o desempenho dos trabalhos ETL existentes. Em vez disso, você pode usar a funcionalidade nativa do runtime de integração do Data Factory como o mecanismo que copia dados do HDFS local para o Azure.

Este artigo fornece as seguintes informações sobre as duas abordagens:

  • Desempenho
  • Resiliência de cópia
  • Segurança de rede
  • Arquitetura da solução de alto nível
  • Melhores práticas de implementação

Desempenho

No modo do DistCp do Data Factory, a taxa de transferência será a mesma obtida se você usar a ferramenta DistCp de maneira independente. O modo do DistCp do Data Factory maximiza a capacidade do cluster Hadoop existente. Use o DistCp para cópias grandes entre clusters ou dentro do cluster.

O DistCp usa o MapReduce para realizar a distribuição, o tratamento e a recuperação de erros, bem como relatórios. Ele expande uma lista de arquivos e diretórios em uma entrada para o mapeamento de tarefas. Cada tarefa copia uma partição de arquivo que é especificada na lista de origem. Use o Data Factory integrado ao DistCp para criar pipelines e utilizar por completo a largura de banda da rede, a IOPS de armazenamento e a largura de banda, a fim de maximizar a taxa de transferência da movimentação de dados do seu ambiente.

O modo do runtime de integração nativa do Data Factory também permite o paralelismo em diferentes níveis. Use o paralelismo para utilizar por completo a largura de banda de rede, a IOPS de armazenamento e a largura de banda a fim de maximizar a taxa de transferência da movimentação de dados:

  • Uma atividade Copy individual pode aproveitar os recursos de computação escalonáveis. Com um runtime de integração auto-hospedada, você pode escalar verticalmente o computador de modo manual ou escalar horizontalmente em vários computadores (até quatro nós). Uma atividade Copy individual particiona o conjunto de arquivos entre todos os nós.
  • Uma atividade Copy individual faz leituras e gravações no armazenamento de dados usando vários threads.
  • O fluxo de controle do Data Factory pode iniciar várias atividades de cópia em paralelo. Por exemplo, você pode usar um loop For Each.

Para obter mais informações, confira o guia de desempenho da atividade Copy.

Resiliência

No modo do DistCp do Data Factory, você pode usar diferentes parâmetros de linha de comando do DistCp (por exemplo, -i para ignorar falhas ou -update para gravar dados quando o arquivo de origem e o arquivo de destino têm tamanhos diferentes) para diferentes níveis de resiliência.

No modo do runtime de integração nativa do Data Factory, em uma execução de atividade Copy individual, o Data Factory conta com um mecanismo de repetição interno. Ele pode lidar com um certo nível de falhas transitórias nos armazenamentos de dados ou na rede subjacente.

Durante a cópia binária do HDFS local para o Armazenamento de Blobs e do HDFS local para o Data Lake Storage Gen2, o Data Factory executa, em grande parte, a definição de ponto de verificação automaticamente. Se uma execução de atividade Copy falhar ou atingir o tempo limite, em uma nova tentativa (verifique se a contagem de repetição é > 1), a cópia será retomada do último ponto de falha em vez de voltar ao início.

Segurança de rede

Por padrão, o Data Factory transfere dados do HDFS local para o Armazenamento de Blobs ou o Azure Data Lake Storage Gen2 usando uma conexão criptografada via protocolo HTTPS. O HTTPS fornece a criptografia de dados em trânsito e impede ataques de interceptação e man-in-the-middle.

Como alternativa, se você não quiser que os dados sejam transferidos pela Internet pública, para maior segurança, transfira-os por um link de emparelhamento privado por meio do ExpressRoute.

Arquitetura da solução

Esta imagem ilustra a migração de dados pela Internet pública:

Diagram that shows the solution architecture for migrating data over a public network

  • Nessa arquitetura, os dados são transferidos com segurança via HTTPS pela Internet pública.
  • Recomendamos usar o modo do DistCp do Data Factory em um ambiente de rede pública. Aproveite um cluster avançado existente para obter a melhor taxa de transferência de cópia. Você também obtém o benefício do agendamento flexível e de uma experiência de monitoramento unificada do Data Factory.
  • Para essa arquitetura, você precisará instalar o runtime de integração auto-hospedada do Data Factory em um computador Windows protegido por um firewall corporativo para enviar o comando DistCp para o cluster Hadoop e monitorar o status da cópia. Como o computador não é o mecanismo que moverá os dados (apenas para fins de controle), a capacidade do computador não afeta a taxa de transferência da movimentação de dados.
  • Há suporte para os parâmetros existentes no comando DistCp.

Esta imagem ilustra a migração de dados por um link privado:

Diagram that shows the solution architecture for migrating data over a private network

  • Nessa arquitetura, os dados são migrados por um link de emparelhamento privado por meio do Azure ExpressRoute. Os dados nunca percorrem a Internet pública.
  • A ferramenta DistCp não dá suporte ao emparelhamento privado do ExpressRoute com um ponto de extremidade de rede virtual do Armazenamento do Azure. Recomendamos que você use a funcionalidade nativa do Data Factory por meio do runtime de integração para migrar os dados.
  • Para essa arquitetura, você precisará instalar o runtime de integração auto-hospedada do Data Factory em uma VM do Windows na sua rede virtual do Azure. Escale verticalmente sua VM de modo manual ou escale horizontalmente em várias VMs para utilizar por completo a rede e a IOPS ou a largura de banda de armazenamento.
  • A configuração inicial recomendada para cada VM do Azure (com o runtime de integração auto-hospedada do Data Factory instalado) é Standard_D32s_v3 com 32 vCPUs e 128 GB de memória. Você pode monitorar o uso de CPU e de memória da VM durante a migração de dados para ver se precisa escalar verticalmente a VM para melhor desempenho ou reduzi-la verticalmente para diminuir os custos.
  • Escale-a também horizontalmente associando até quatro nós de VM a um só runtime de integração auto-hospedada. Um trabalho de cópia individual em execução em um runtime de integração auto-hospedada particiona automaticamente o conjunto de arquivos e utiliza todos os nós da VM para copiar os arquivos em paralelo. Para alta disponibilidade, recomendamos que você comece com dois nós de VM para evitar um cenário de ponto único de falha durante a migração de dados.
  • Quando você usa essa arquitetura, a migração de dados de instantâneo inicial e a migração de dados delta ficam disponíveis.

Melhores práticas de implementação

Recomendamos que você siga estas melhores práticas ao implementar a migração de dados.

Autenticação e gerenciamento de credenciais

Migração de dados de instantâneo inicial

No modo do DistCp do Data Factory, você pode criar uma atividade Copy para enviar o comando DistCp e usar parâmetros diferentes para controlar o comportamento inicial da migração de dados.

No modo do runtime de integração nativa do Data Factory, recomendaremos usar a partição de dados, especialmente, quando mais de 10 TB de dados forem migrados. Para particionar os dados, use os nomes de pastas no HDFS. Em seguida, cada trabalho de cópia do Data Factory poderá copiar uma partição de pasta por vez. Você pode executar vários trabalhos de cópia do Data Factory simultaneamente para obter uma melhor taxa de transferência.

Se um dos trabalhos de cópia falhar devido a problemas transitório de rede ou de armazenamento de dados, você poderá executar novamente o trabalho de cópia com falha para recarregar essa partição específica do HDFS. Outros trabalhos de cópia que carregam outras partições não são afetados.

Migração de dados delta

No modo do DistCp do Data Factory, você pode usar o parâmetro de linha de comando -update do DistCp para gravar dados quando o arquivo de origem e o arquivo de destino têm tamanhos diferentes para a migração de dados delta.

No modo de integração nativa do Data Factory, a maneira mais eficaz de identificar arquivos novos ou alterados do HDFS é usando uma convenção de nomenclatura particionada por tempo. Quando os dados do HDFS forem particionados por tempo com informações de fração de tempo no nome do arquivo ou da pasta (por exemplo, /aaaa/mm/dd/arquivo.csv), o pipeline poderá identificar com facilidade quais pastas e arquivos devem ser copiados de modo incremental.

Como alternativa, se os dados do HDFS não forem particionados por tempo, o Data Factory poderá identificar arquivos novos ou alterados usando o valor LastModifiedDate. O Data Factory examina todos os arquivos do HDFS e copia somente os arquivos novos e atualizados que têm um carimbo de data/hora de última modificação que seja maior que um valor definido.

Se você tiver um número grande de arquivos no HDFS, a verificação de arquivo inicial poderá levar muito tempo, independentemente de quantos arquivos corresponderem à condição de filtro. Nesse cenário, recomendamos que você, primeiro, particione os dados usando a mesma partição da migração de instantâneo inicial. Em seguida, a verificação de arquivo poderá ocorrer em paralelo.

Estimar o preço

Considere o seguinte pipeline para migração de dados do HDFS para o Armazenamento de Blobs do Azure:

Diagram that shows the pricing pipeline

Vamos supor as seguintes informações:

  • O volume de dados total é de 1 PB.
  • Você migra os dados usando o modo do runtime de integração nativa do Data Factory.
  • O 1 PB é dividido em mil partições, e cada cópia move uma partição.
  • Cada atividade Copy é configurada com um runtime de integração auto-hospedada associado a quatro computadores e que atinge a taxa de transferência de 500 MBps.
  • A simultaneidade de ForEach está definida como 4 e a taxa de transferência de agregação é de 2 GBps.
  • No total, são necessárias 146 horas para concluir a migração.

Este é o preço estimado com base em nossas suposições:

Table that shows pricing calculations

Observação

Este é um exemplo de preço hipotético. O preço real depende da taxa de transferência real no ambiente. O preço de uma VM do Windows do Azure (com o runtime de integração auto-hospedada instalado) não está incluído.

Referências adicionais

Conteúdo relacionado