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
Gorjeta
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!
O Azure Data Factory fornece um mecanismo de desempenho, robusto e econômico para migrar dados em escala de um servidor Netezza local para sua conta de armazenamento do Azure ou banco de dados do Azure Synapse Analytics.
Este artigo fornece as seguintes informações para engenheiros de dados e desenvolvedores:
- Desempenho
- Resiliência de cópia
- Segurança da rede
- Arquitetura de solução de alto nível
- Melhores práticas de implementação
Desempenho
O Azure Data Factory oferece uma arquitetura sem servidor que permite paralelismo em vários níveis. Se você for um desenvolvedor, isso significa que pode criar pipelines para usar totalmente a largura de banda da rede e do banco de dados para maximizar a taxa de transferência de movimentação de dados para seu ambiente.
O diagrama anterior pode ser interpretado da seguinte forma:
Uma única atividade de cópia pode tirar proveito de recursos de computação escaláveis. Ao usar o Azure Integration Runtime, você pode especificar até 256 DIUs para cada atividade de cópia de maneira sem servidor. Com um tempo de execução de integração auto-hospedado (IR auto-hospedado), você pode dimensionar manualmente a máquina ou dimensionar para várias máquinas (até quatro nós), e uma única atividade de cópia distribui sua partição por todos os nós.
Uma única atividade de cópia lê e grava 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á-los usando um loop For Each.
Para obter mais informações, consulte Copiar guia de desempenho e escalabilidade da atividade.
Resiliência
Dentro de uma única execução de atividade de cópia, o Azure Data Factory tem um mecanismo de repetição interno, que permite lidar com um determinado nível de falhas transitórias nos armazenamentos de dados ou na rede subjacente.
Com a atividade de cópia do Azure Data Factory, quando você copia dados entre armazenamentos de dados de origem e coletor, você tem duas maneiras de lidar com linhas incompatíveis. Você pode anular e falhar a atividade de cópia ou continuar a copiar o restante dos dados ignorando as linhas de dados incompatíveis. Além disso, para saber a causa da falha, você pode registrar as linhas incompatíveis no armazenamento de Blob do Azure ou no Repositório Azure Data Lake, corrigir os dados na fonte de dados e repetir a atividade de cópia.
Segurança da rede
Por padrão, o Azure Data Factory transfere dados do servidor Netezza local para uma conta de armazenamento do Azure ou banco de dados do Azure Synapse Analytics usando uma conexão criptografada por HTTPS (Hypertext Transfer Protocol Secure). O HTTPS fornece criptografia de dados em trânsito e evita escutas e ataques man-in-the-middle.
Como alternativa, se não quiser que os dados sejam transferidos pela Internet pública, você pode ajudar a obter maior segurança transferindo dados por um link de emparelhamento privado por meio da Rota Expressa do Azure.
A próxima seção discute como obter maior segurança.
Arquitetura de soluções
Esta seção discute duas maneiras de migrar seus dados.
Migrar dados pela Internet pública
O diagrama anterior pode ser interpretado da seguinte forma:
Nessa arquitetura, você transfere dados com segurança usando HTTPS pela Internet pública.
Para obter essa arquitetura, você precisa instalar o tempo de execução de integração do Azure Data Factory (auto-hospedado) em uma máquina Windows atrás de um firewall corporativo. Certifique-se de que este tempo de execução de integração pode acessar diretamente o servidor Netezza. Para usar totalmente a largura de banda da rede e dos armazenamentos de dados para copiar dados, você pode dimensionar manualmente sua máquina ou expandir para várias máquinas.
Usando essa arquitetura, você pode migrar dados de instantâneo iniciais e dados delta.
Migrar dados através de uma rede privada
O diagrama anterior pode ser interpretado da seguinte forma:
Nessa arquitetura, você migra dados por meio de um link de emparelhamento privado por meio da Rota Expressa do Azure e os dados nunca passam pela Internet pública.
Para obter essa arquitetura, você precisa instalar o tempo de execução de integração do Azure Data Factory (auto-hospedado) em uma máquina virtual (VM) do Windows em sua rede virtual do Azure. Para usar totalmente a largura de banda da rede e dos armazenamentos de dados para copiar dados, você pode dimensionar manualmente sua VM ou expandir para várias VMs.
Usando essa arquitetura, você pode migrar dados de instantâneo iniciais e dados delta.
Implementar práticas recomendadas
Gerenciar autenticação e credenciais
Para autenticar no Netezza, você pode usar a autenticação ODBC via cadeia de conexão.
Para autenticar no armazenamento de Blob do Azure:
É altamente recomendável usar identidades gerenciadas para recursos do Azure. Criadas com base em uma identidade do Azure Data Factory gerenciada automaticamente na ID do Microsoft Entra, as identidades gerenciadas permitem configurar pipelines sem precisar fornecer credenciais na definição de Serviço Vinculado.
Como alternativa, você pode autenticar no armazenamento de Blob do Azure usando a entidade de serviço, uma assinatura de acesso compartilhado ou uma chave de conta de armazenamento.
Para autenticar no Azure Data Lake Storage Gen2:
É altamente recomendável usar identidades gerenciadas para recursos do Azure.
Você também pode usar a entidade de serviço ou uma chave de conta de armazenamento.
Para autenticar no Azure Synapse Analytics:
É altamente recomendável usar identidades gerenciadas para recursos do Azure.
Você também pode usar a entidade de serviço ou a autenticação SQL.
Quando você não estiver usando identidades gerenciadas para recursos do Azure, é altamente recomendável armazenar as credenciais no Cofre de Chaves do Azure para facilitar o gerenciamento centralizado e a rotação de chaves sem precisar modificar os serviços vinculados do Azure Data Factory. Esta é também uma das melhores práticas para CI/CD.
Migrar dados de snapshot iniciais
Para tabelas pequenas (ou seja, tabelas com um volume inferior a 100 GB ou que podem ser migradas para o Azure dentro de duas horas), você pode fazer com que cada tarefa de cópia carregue dados por tabela. Para obter maior taxa de transferência, você pode executar vários trabalhos de cópia do Azure Data Factory para carregar tabelas separadas simultaneamente.
Dentro de cada trabalho de cópia, para executar consultas paralelas e copiar dados por partições, você também pode alcançar algum nível de paralelismo usando a parallelCopies
configuração de propriedade com uma das seguintes opções de partição de dados:
Para ajudar a obter maior eficiência, recomendamos que você comece a partir de uma fatia de dados. Certifique-se de que o
parallelCopies
valor na configuração é menor do que o número total de partições de fatia de dados em sua tabela no servidor Netezza.Se o volume de cada partição de fatia de dados ainda for grande (por exemplo, 10 GB ou mais), recomendamos que você mude para uma partição de intervalo dinâmico. Esta opção dá-lhe 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 de 100 GB ou superior ou que não podem ser migradas para o Azure dentro de duas horas), recomendamos que particione os dados por consulta personalizada e, em seguida, faça com que cada cópia de trabalho de cópia seja uma partição de cada vez. Para uma melhor taxa de transferência, você pode executar vários trabalhos de cópia do Azure Data Factory simultaneamente. Para cada destino de trabalho de cópia de carregamento de uma partição por consulta personalizada, você pode aumentar a taxa de transferência habilitando o paralelismo por meio de fatia de dados ou intervalo dinâmico.
Se algum trabalho de cópia falhar devido a um problema transitório de rede ou 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ê carrega dados em um banco de dados do Azure Synapse Analytics, sugerimos que habilite o PolyBase no trabalho de cópia com o armazenamento de Blob do Azure como preparação.
Migrar dados delta
Para identificar as linhas novas ou atualizadas da tabela, use uma coluna de carimbo de data/hora ou uma chave de incremento dentro do esquema. Em seguida, você pode armazenar o valor mais recente como uma marca d'água alta em uma tabela externa e, em seguida, usá-lo para filtrar os dados delta na próxima vez que carregar dados.
Cada tabela pode usar uma coluna de marca d'água diferente para identificar suas linhas novas ou atualizadas. Sugerimos que você crie uma tabela de controle externo. Na tabela, cada linha representa uma tabela no servidor Netezza com seu nome de coluna de marca d'água específico e alto valor de marca d'água.
Configurar um tempo de execução de integração auto-hospedado
Se você estiver migrando dados do servidor Netezza para o Azure, quer o servidor esteja no local atrás do firewall da corporação ou em um ambiente de rede virtual, será necessário instalar um IR auto-hospedado em uma máquina Windows ou VM, que é o mecanismo usado para mover dados. À medida que você instala o IR auto-hospedado, recomendamos a seguinte abordagem:
Para cada máquina Windows ou VM, comece com uma configuração de 32 vCPU e 128 GB de memória. Você pode continuar monitorando o uso da CPU e da memória da máquina IR durante a migração de dados para ver se precisa aumentar ainda mais a escala da máquina para obter um melhor desempenho ou reduzir a escala da máquina para economizar custos.
Você também pode expandir associando até quatro nós a um único IR auto-hospedado. Um único trabalho de cópia em execução em um IR auto-hospedado aplica automaticamente todos os nós da VM para copiar os dados em paralelo. Para alta disponibilidade, comece com quatro nós de VM para evitar um único ponto de falha durante a migração de dados.
Limite as suas partições
Como prática recomendada, conduza uma prova de conceito de desempenho (POC) com um conjunto de dados de amostra representativo, para que você possa determinar um tamanho de partição apropriado para cada atividade de cópia. Sugerimos que carregue cada partição no Azure dentro de duas horas.
Para copiar uma tabela, comece com uma única atividade de cópia com uma única máquina de IR auto-hospedada. Aumente gradualmente a parallelCopies
configuração com base no número de partições de fatia de dados em sua tabela. Veja se a tabela inteira pode ser carregada no Azure dentro de duas horas, de acordo com a taxa de transferência resultante do trabalho de cópia.
Se não for possível carregá-lo no Azure dentro de duas horas e a capacidade do nó IR auto-hospedado e do armazenamento de dados não for totalmente usada, aumente gradualmente o número de atividades de cópia simultâneas até atingir o limite da sua rede ou o limite de largura de banda dos armazenamentos de dados.
Continue monitorando o uso da CPU e da memória na máquina IR auto-hospedada e esteja pronto para expandir a máquina ou expandir para várias máquinas quando perceber que a CPU e a memória estão totalmente usadas.
Quando você encontrar erros de limitação, conforme relatado pela atividade de cópia do Azure Data Factory, reduza a simultaneidade ou parallelCopies
a configuração no Azure Data Factory ou considere aumentar os limites de largura de banda ou operações de E/S por segundo (IOPS) da rede e dos armazenamentos de dados.
Estime os seus preços
Considere o seguinte pipeline, que é construído para migrar dados do servidor Netezza local para um banco de dados do Azure Synapse Analytics:
Vamos supor que as seguintes afirmações sejam verdadeiras:
O volume total de dados é de 50 terabytes (TB).
Estamos migrando dados usando a arquitetura de primeira solução (o servidor Netezza está no local, atrás do firewall).
O volume de 50 TB é dividido em 500 partições e cada atividade de cópia move uma partição.
Cada atividade de cópia é configurada com um IR auto-hospedado em quatro máquinas e atinge uma taxa de transferência de 20 megabytes por segundo (MBps). (Dentro da atividade de cópia,
parallelCopies
é definido como 4, e cada thread 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, aqui está o preço estimado:
Nota
O preço apresentado na tabela anterior é hipotético. Seu preço real depende da taxa de transferência real em seu ambiente. O preço para a máquina Windows (com o IR auto-hospedado instalado) não está incluído.
Referências adicionais
Para obter mais informações, consulte os seguintes artigos e guias:
- Conector Netezza
- Conector ODBC
- Conector de armazenamento de Blob do Azure
- Conector do Azure Data Lake Storage Gen2
- Conector do Azure Synapse Analytics
- Copiar guia de ajuste de desempenho da atividade
- Create and configure a self-hosted integration runtime (Criar e configurar um runtime de integração autoalojado)
- HA e escalabilidade de tempo de execução de integração auto-hospedada
- Considerações sobre segurança de movimentação de dados
- Armazenar credenciais no Cofre da Chave do Azure
- Copiar dados incrementalmente de uma tabela
- Copiar dados incrementalmente de várias tabelas
- Página de preços do Azure Data Factory