Compartilhar via


Usar o Azure Data Factory para migrar dados de um servidor Netezza local para o Azure

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 de um servidor Netezza local para sua conta de armazenamento do Azure ou para um banco de dados do Azure Synapse Analytics.

Este artigo fornece as seguintes informações para desenvolvedores e engenheiros de dados:

  • 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

O Azure Data Factory oferece uma arquitetura sem servidor que permite o paralelismo em vários níveis. Se você é um desenvolvedor, isso significa que você pode criar pipelines para usar por completo a largura de banda de rede e de banco de dados a fim de maximizar a taxa de transferência da movimentação de dados do seu ambiente.

Diagrama de desempenho

O diagrama anterior pode ser interpretado da seguinte maneira:

  • Uma atividade Copy individual pode aproveitar os recursos de computação escalonáveis. Ao usar o Azure Integration Runtime, você pode especificar até 256 DIUs para cada atividade Copy no modelo sem servidor. Com um IR auto-hospedado (runtime de integração auto-hospedada), você pode escalar verticalmente o computador de modo manual ou usar escalar horizontalmente em vários computadores (até quatro nós), e uma atividade Copy individual distribui a partição 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 Azure Data Factory pode iniciar várias atividades de cópia em paralelo. Por exemplo, ele pode iniciá-las usando um loop For Each.

Para obter mais informações, confira Guia de desempenho e escalabilidade da atividade Copy.

Resiliência

Em uma execução de atividade Copy individual, o Azure Data Factory conta com um mecanismo de repetição interno para lidar com um certo nível de falhas transitórias nos armazenamentos de dados ou na rede subjacente.

Com a atividade Copy do Azure Data Factory, ao copiar dados entre armazenamentos de dados de origem e do coletor, você tem duas maneiras de lidar com linhas incompatíveis. Você pode anular e falhar a atividade Copy ou continuar para copiar o restante dos dados, ignorando as linhas de dados incompatíveis. Além disso, para descobrir a causa da falha, você pode registrar as linhas incompatíveis no Armazenamento de Blobs do Azure ou no Azure Data Lake Storage, corrigir os dados na fonte de dados e repetir a atividade Copy.

Segurança de rede

Por padrão, o Azure Data Factory transfere dados do servidor Netezza local para uma conta de armazenamento do Azure ou um banco de dados do Azure Synapse Analytics 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, caso não deseje que os dados sejam transferidos pela Internet pública, ajude a obter maior segurança transferindo-os por um link de emparelhamento privado pelo Azure ExpressRoute.

A próxima seção abordará como obter maior segurança.

Arquitetura da solução

Esta seção aborda duas maneiras de migrar seus dados.

Migrar dados pela Internet pública

Migrar dados pela Internet pública

O diagrama anterior pode ser interpretado da seguinte maneira:

  • Nessa arquitetura, você transfere os dados com segurança usando HTTPS pela Internet pública.

  • Para obter essa arquitetura, você precisará instalar o runtime de integração (auto-hospedada) do Azure Data Factory em um computador Windows protegido por um firewall corporativo. Verifique se esse runtime de integração pode acessar diretamente o servidor Netezza. Para usar por completo a largura de banda dos armazenamentos de dados e de rede para copiar os dados, você pode escalar verticalmente o computador ou escalar horizontalmente em vários computadores.

  • Usando essa arquitetura, você pode migrar dados de instantâneo inicial e dados delta.

Migrar dados por uma rede privada

Migrar dados por uma rede privada

O diagrama anterior pode ser interpretado da seguinte maneira:

  • Nessa arquitetura, você migra os dados por um link de emparelhamento privado pelo Azure ExpressRoute, e os dados nunca percorrem a Internet pública.

  • Para obter essa arquitetura, você precisará instalar o runtime de integração (auto-hospedada) do Azure Data Factory em uma VM (máquina virtual) do Windows na sua rede virtual do Azure. Para usar por completo a largura de banda dos armazenamentos de dados e de rede para copiar os dados, você pode escalar verticalmente a VM ou escalar horizontalmente em várias VMs.

  • Usando essa arquitetura, você pode migrar dados de instantâneo inicial e dados delta.

Implementar as melhores práticas

Gerenciar a autenticação e as credenciais

Migrar dados de instantâneo inicial

Para tabelas pequenas (ou seja, tabelas com um volume inferior a 100 GB ou que possam ser migradas para o Azure em até duas horas), você pode fazer com que cada trabalho de cópia carregue os dados por tabela. Para obter uma taxa de transferência mais alta, execute vários trabalhos de cópia do Azure Data Factory para carregar tabelas separadas simultaneamente.

Em cada trabalho de cópia, para executar consultas paralelas e copiar dados por partições, você também pode obter algum nível de paralelismo usando a configuração da propriedade parallelCopies com uma das seguintes opções de partição de dados:

  • Para obter ajuda a fim de atingir maior eficiência, recomendamos que você comece com uma fatia de dados. Verifique se o valor da configuração de parallelCopies é menor que o número total de partições de fatia de dados da tabela no servidor Netezza.

  • Se o volume de cada partição de fatia de dados ainda for grande (por exemplo, 10 GB ou mais), recomendaremos que você alterne para uma partição de intervalo dinâmico. Essa opção oferece maior flexibilidade para definir o número de partições e o volume de cada partição por coluna de partição, limite superior e limite inferior.

Para tabelas maiores (ou seja, tabelas com um volume igual a 100 GB ou mais ou que não possam ser migradas para o Azure em até duas horas), recomendaremos que você particione os dados por consulta personalizada e faça com que cada trabalho de cópia copie uma partição por vez. Para obter uma melhor taxa de transferência, execute vários trabalhos de cópia do Azure Data Factory simultaneamente. Para cada meta do trabalho de cópia de carregar uma partição por consulta personalizada, você pode aumentar a taxa de transferência habilitando o paralelismo por meio da fatia de dados ou do intervalo dinâmico.

Se um dos trabalhos de cópia falhar devido a um problema 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 da tabela. Outros trabalhos de cópia que carregam outras partições não são afetados.

Quando você carregar dados em um banco de dados do Azure Synapse Analytics, como sugestão, habilite o PolyBase no trabalho de cópia com o Armazenamento de Blobs do Azure como preparo.

Migrar os dados delta

Para identificar as linhas novas ou atualizadas da tabela, use uma coluna de carimbo de data/hora ou uma chave de incremento no esquema. Em seguida, você poderá armazenar o valor mais recente como uma marca-d'água alta em uma tabela externa e usá-lo para filtrar os dados delta na próxima vez que carregar os dados.

Cada tabela pode usar uma coluna de marca-d'água diferente para identificar as respectivas linhas novas ou atualizadas. Sugerimos que você crie uma tabela de controle externa. Na tabela, cada linha representa uma tabela no servidor Netezza com o respectivo nome de coluna de marca d'água e valor da marca-d'água alta específicos.

Configurar um runtime de integração auto-hospedada

Se você estiver migrando dados do servidor Netezza para o Azure, quer o servidor esteja no local protegido pelo firewall corporativo ou em um ambiente de rede virtual, você precisará instalar um IR auto-hospedado em uma ou VM ou um computador Windows, que é o mecanismo usado para mover os dados. Como você está instalando o IR auto-hospedado, recomendamos usar a seguinte abordagem:

  • Para cada VM ou computador Windows, comece com uma configuração de 32 vCPUs e 128 GB de memória. Você pode continuar monitorando o uso de CPU e de memória do computador do IR durante a migração de dados para ver se precisa escalar verticalmente o computador para melhor desempenho ou reduzi-lo verticalmente para diminuir os custos.

  • Escale-o horizontalmente também associando até quatro nós a um só IR auto-hospedado. Um só trabalho de cópia executado em um IR auto-hospedado aplica automaticamente todos os nós da VM para copiar os dados em paralelo. Para obter alta disponibilidade, comece com quatro nós de VM a fim de evitar um ponto único de falha durante a migração de dados.

Limitar as partições

Como melhor prática, realize um POC (prova de conceito) de desempenho com um conjunto de dados de exemplo representativo para determinar um tamanho de partição apropriado para cada atividade Copy. Sugerimos que você carregue cada partição no Azure em até duas horas.

Para copiar uma tabela, comece com uma atividade Copy individual com um computador do IR auto-hospedado. Aumente gradualmente a configuração de parallelCopies com base no número de partições de fatia de dados da tabela. Veja se a tabela inteira pode ser carregada no Azure em até duas horas, de acordo com a taxa de transferência resultante do trabalho de cópia.

Se ela não puder ser carregada no Azure em até duas horas e a capacidade do nó do IR auto-hospedado e o armazenamento de dados não forem totalmente usados, aumente gradualmente o número de atividades Copy simultâneas até alcançar o limite da sua rede ou o limite de largura de banda dos armazenamentos de dados.

Continue monitorando o uso de CPU e de memória no computador do IR auto-hospedado e esteja pronto para escalar verticalmente o computador ou escalar horizontalmente em vários computadores quando observar que a CPU e a memória foram totalmente usadas.

Quando encontrar erros de limitação, conforme relatado pela atividade Copy do Azure Data Factory, reduza a simultaneidade ou a configuração de parallelCopies no Azure Data Factory ou considere a possibilidade de aumentar os limites de largura de banda ou da IOPS (operações de E/S por segundo) da rede e dos armazenamentos de dados.

Estimar o preço

Considere o seguinte pipeline, que foi construído para migrar dados do servidor Netezza local para um banco de dados do Azure Synapse Analytics:

O pipeline de preço

Vamos supor que as seguintes afirmações sejam verdadeiras:

  • O volume de dados total é de 50 TB (terabytes).

  • Estamos migrando os dados com a arquitetura da primeira solução (o servidor Netezza é local, protegido pelo firewall).

  • O volume de 50 TB é dividido em 500 partições, e cada atividade Copy move uma partição.

  • Cada atividade Copy é configurada com um IR auto-hospedado em quatro computadores e atinge uma taxa de transferência de 20 MBps (megabytes por segundo). (Na atividade Copy, parallelCopies é definido como 4, e cada thread usado para carregar dados da tabela atinge uma taxa de transferência de 5 Mbps.)

  • A simultaneidade ForEach é definida como 3, e a taxa de transferência agregada é de 60 MBps.

  • No total, são necessárias 243 horas para concluir a migração.

Com base nas suposições anteriores, este é o preço estimado:

A tabela de preços

Observação

O preço mostrado na tabela anterior é hipotético. O preço real depende da taxa de transferência real no ambiente. O preço do computador Windows (com o IR auto-hospedado instalado) não está incluído.

Referências adicionais

Para obter mais informações, confira os seguintes artigos e guias: