Migração de dados, ETL e carga para migrações Netezza

Este artigo é a segunda parte de uma série de sete partes que fornece orientação sobre como migrar do Netezza para o Azure Synapse Analytics. O foco deste artigo são as práticas recomendadas para ETL e migração de carga.

Considerações sobre migração de dados

Decisões iniciais para migração de dados da Netezza

Ao migrar um data warehouse Netezza, você precisa fazer algumas perguntas básicas relacionadas a dados. Por exemplo:

• As estruturas de tabela não utilizadas devem ser migradas?

• Qual é a melhor abordagem de migração para minimizar o risco e o impacto no usuário?

• Ao migrar data marts: deve manter-se físico ou tornar-se virtual?

As próximas seções discutem esses pontos no contexto da migração de Netezza.

Migrar tabelas não utilizadas?

Faz sentido migrar apenas as tabelas que estão em uso no sistema existente. As tabelas que não estão ativas podem ser arquivadas em vez de migradas, para que os dados estejam disponíveis, se necessário, no futuro. É melhor usar metadados do sistema e arquivos de log em vez de documentação para determinar quais tabelas estão em uso, porque a documentação pode estar desatualizada.

Se habilitada, as tabelas de histórico de consultas Netezza contêm informações que podem determinar quando uma determinada tabela foi acessada pela última vez, o que, por sua vez, pode ser usado para decidir se uma tabela é candidata à migração.

Aqui está um exemplo de consulta que procura o uso de uma tabela específica dentro de uma determinada janela de tempo:

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

Esta consulta utiliza a função auxiliar FORMAT_TABLE_ACCESS e o dígito no final da vista $v_hist_table_access_3 para corresponder à versão instalada do histórico de consultas.

Qual é a melhor abordagem de migração para minimizar o risco e o impacto nos usuários?

Essa pergunta surge com frequência porque as empresas podem querer diminuir o impacto das mudanças no modelo de dados do data warehouse para melhorar a agilidade. As empresas geralmente veem uma oportunidade de modernizar ou transformar ainda mais seus dados durante uma migração de ETL. Esta abordagem acarreta um risco mais elevado porque altera múltiplos fatores em simultâneo, dificultando a comparação dos resultados do sistema antigo com o novo. Fazer alterações no modelo de dados aqui também pode afetar trabalhos de ETL upstream ou downstream para outros sistemas. Devido a esse risco, é melhor redesenhar nessa escala após a migração do data warehouse.

Mesmo que um modelo de dados seja intencionalmente alterado como parte da migração geral, é uma boa prática migrar o modelo existente como está para o Azure Synapse, em vez de fazer qualquer reengenharia na nova plataforma. Esta abordagem minimiza o efeito nos sistemas de produção existentes, ao mesmo tempo que beneficia do desempenho e da escalabilidade elástica da plataforma Azure para tarefas pontuais de reengenharia.

Ao migrar do Netezza, muitas vezes o modelo de dados existente já é adequado para as-is migração para o Azure Synapse.

Migrar data marts: mantenha-se físico ou virtual?

Em ambientes de data warehouse Netezza legados, é prática comum criar vários data marts estruturados para fornecer um bom desempenho para consultas e relatórios de autoatendimento ad hoc para um determinado departamento ou função de negócios dentro de uma organização. Como tal, um data mart normalmente consiste em um subconjunto do data warehouse e contém versões agregadas dos dados em um formato que permite aos usuários consultar facilmente esses dados com tempos de resposta rápidos por meio de ferramentas de consulta fáceis de usar, como Microsoft Power BI, Tableau ou MicroStrategy. Este formulário é normalmente um modelo de dados dimensionais. Um uso dos data marts é expor os dados em um formato utilizável, mesmo que o modelo de dados de armazém subjacente seja algo diferente, como um cofre de dados.

Você pode usar data marts separados para unidades de negócios individuais dentro de uma organização para implementar regimes robustos de segurança de dados, permitindo apenas que os usuários acessem data marts específicos que são relevantes para eles e eliminando, ofuscando ou anonimizando dados confidenciais.

Se esses data marts forem implementados como tabelas físicas, eles exigirão recursos de armazenamento adicionais para armazená-los e processamento adicional para criá-los e atualizá-los regularmente. Além disso, os dados no mart estarão tão atuais quanto a última operação de atualização e, portanto, podem ser inadequados para dashboards que lidam com dados altamente voláteis.

Com o advento de arquiteturas MPP escaláveis de custo relativamente baixo, como o Azure Synapse, e as características de desempenho inerentes a essas arquiteturas, pode ser que você possa fornecer funcionalidade de data mart sem ter que instanciar o mart como um conjunto de tabelas físicas. Isso é conseguido virtualizando efetivamente os data marts por meio de exibições SQL no data warehouse principal ou por meio de uma camada de virtualização usando recursos como exibições no Azure ou os produtos de visualização de parceiros da Microsoft. Essa abordagem simplifica ou elimina a necessidade de armazenamento adicional e processamento de agregação e reduz o número total de objetos de banco de dados a serem migrados.

Há outro benefício potencial nessa abordagem. Ao implementar a lógica de agregação e junção dentro de uma camada de virtualização e apresentar ferramentas de relatórios externos por meio de uma exibição virtualizada, o processamento necessário para criar essas exibições é "empurrado para baixo" no data warehouse, que geralmente é o melhor lugar para executar junções, agregações e outras operações relacionadas em grandes volumes de dados.

Os principais drivers para escolher uma implementação de data mart virtual em vez de um data mart físico são:

• Mais agilidade: um data mart virtual é mais fácil de alterar do que as tabelas físicas e os processos ETL associados.

• Menor custo total de propriedade: uma implementação virtualizada requer menos armazenamentos de dados e cópias de dados.

• Eliminação de trabalhos de ETL para migrar e simplificar a arquitetura de data warehouse em um ambiente virtualizado.

• Desempenho: embora os data marts físicos tenham sido historicamente mais eficientes, os produtos de virtualização agora implementam técnicas inteligentes de cache para mitigar.

Migração de dados do Netezza

Compreender os seus dados

Parte do planejamento da migração é entender em detalhes o volume de dados que precisa ser migrado, pois isso pode afetar as decisões sobre a abordagem de migração. Use metadados do sistema para determinar o espaço físico ocupado pelos "dados brutos" dentro das tabelas a serem migradas. Neste contexto, "dados brutos" significa a quantidade de espaço utilizada pelas linhas de dados dentro de uma tabela, excluindo despesas gerais como índices e compressão. Isto é especialmente verdadeiro para as maiores tabelas de fatos, uma vez que estas normalmente compreendem mais de 95% dos dados.

Você pode obter um número preciso para o volume de dados a ser migrado para uma determinada tabela extraindo uma amostra representativa dos dados — por exemplo, um milhão de linhas — para um arquivo de dados ASCII simples delimitado não compactado. Em seguida, use o tamanho desse arquivo para obter um tamanho médio de dados brutos por linha dessa tabela. Por fim, multiplique esse tamanho médio pelo número total de linhas na tabela completa para fornecer um tamanho de dados brutos para a tabela. Use esse tamanho de dados brutos em seu planejamento.

Mapeamento de tipo de dados Netezza

A maioria dos tipos de dados Netezza tem um equivalente direto no Azure Synapse. A tabela a seguir mostra esses tipos de dados, juntamente com a abordagem recomendada para mapeá-los.

Use os metadados das tabelas do catálogo Netezza para determinar se algum desses tipos de dados precisa ser migrado e permitir isso em seu plano de migração. As visualizações de metadados importantes no Netezza para este tipo de consulta são:

• _V_USER: a visualização do usuário fornece informações sobre os usuários no sistema Netezza.

• _V_TABLE: a visualização de tabela contém a lista de tabelas criadas no sistema de desempenho Netezza.

• _V_RELATION_COLUMN: A vista do Catálogo do Sistema de Colunas de Relação contém as colunas disponíveis numa tabela.

• _V_OBJECTS: a visualização de objetos lista os diferentes objetos como tabelas, exibição, funções e assim por diante, que estão disponíveis no Netezza.

Por exemplo, esta consulta Netezza SQL mostra colunas e tipos de coluna:

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

A consulta pode ser modificada para procurar em todas as tabelas quaisquer ocorrências de tipos de dados não suportados.

O Azure Data Factory pode ser usado para mover dados de um ambiente Netezza herdado. Para obter mais informações, consulte IBM Netezza connector.

Fornecedores terceirizados oferecem ferramentas e serviços para automatizar a migração, incluindo o mapeamento de tipos de dados, conforme descrito anteriormente. Além disso, ferramentas ETL de terceiros, como Informatica ou Talend, já em uso no ambiente Netezza podem implementar todas as transformações de dados necessárias. A próxima seção explora a migração de processos ETL de terceiros existentes.

Considerações sobre migração de ETL

Decisões iniciais sobre a migração do Netezza ETL

Para processamento ETL/ELT, os armazéns de dados Netezza herdados podem usar scripts personalizados usando utilitários Netezza, como nzsql e nzload, ou ferramentas ETL de terceiros, como Informatica ou Ab Initio. Às vezes, os data warehouses Netezza usam uma combinação de abordagens ETL e ELT que evoluiu ao longo do tempo. Ao planejar uma migração para o Azure Synapse, você precisa determinar a melhor maneira de implementar o processamento ETL/ELT necessário no novo ambiente, minimizando o custo e o risco envolvidos. Para saber mais sobre o processamento de ETL e ELT, consulte Abordagem de design ELT vs ETL.

As seções a seguir discutem as opções de migração e fazem recomendações para vários casos de uso. Este fluxograma resume uma abordagem:

O primeiro passo é sempre construir um inventário dos processos ETL/ELT que precisam ser migrados. Tal como acontece com outras etapas, é possível que os recursos padrão "internos" do Azure tornem desnecessária a migração de alguns processos existentes. Para fins de planejamento, é importante entender a escala da migração a ser realizada.

No fluxograma anterior, a decisão 1 está relacionada a uma decisão de alto nível sobre migrar para um ambiente totalmente nativo do Azure. Se você estiver migrando para um ambiente totalmente nativo do Azure, recomendamos que reprojete o processamento de ETL usando Pipelines e atividades no Azure Data Factory ou Azure Synapse Pipelines. Se você não estiver migrando para um ambiente totalmente nativo do Azure, a decisão 2 será se uma ferramenta ETL de terceiros existente já está em uso.

Se uma ferramenta ETL de terceiros já estiver em uso, e especialmente se houver um grande investimento em habilidades ou vários fluxos de trabalho e agendas existentes usarem essa ferramenta, a decisão 3 será se a ferramenta pode dar suporte eficiente ao Azure Synapse como um ambiente de destino. Idealmente, a ferramenta incluirá conectores "nativos" que podem aproveitar recursos do Azure, como PolyBase ou COPY INTO, para o carregamento de dados mais eficiente. Há uma maneira de chamar um processo externo, como PolyBase ou COPY INTO, e passar os parâmetros apropriados. Nesse caso, aproveite as habilidades e fluxos de trabalho existentes, com o Azure Synapse como o novo ambiente de destino.

Se você decidir manter uma ferramenta ETL de terceiros existente, pode haver benefícios em executar essa ferramenta no ambiente do Azure (em vez de em um servidor ETL local existente) e fazer com que o Azure Data Factory lide com a orquestração geral dos fluxos de trabalho existentes. Um benefício específico é que menos dados precisam ser baixados do Azure, processados e, em seguida, carregados de volta no Azure. Portanto, a decisão 4 é deixar a ferramenta existente em execução as-is ou movê-la para o ambiente do Azure para obter benefícios de custo, desempenho e escalabilidade.

Reengenharia de scripts específicos do Netezza existentes

Se parte ou todo o processamento ETL/ELT existente do armazém Netezza for manipulado por scripts personalizados que utilizam utilitários específicos do Netezza, como nzsql ou nzload, esses scripts precisarão ser recodificados para o novo ambiente do Azure Synapse. Da mesma forma, se os processos ETL foram implementados usando procedimentos armazenados no Netezza, então estes também terão que ser recodificados.

Alguns elementos do processo ETL são fáceis de migrar, por exemplo, por meio de uma simples carga de dados em massa em uma tabela de preparo a partir de um arquivo externo. Pode até ser possível automatizar essas partes do processo, por exemplo, usando PolyBase em vez de nzload. Outras partes do processo que contêm SQL complexo arbitrário e/ou procedimentos armazenados levarão mais tempo para serem reformuladas.

Uma maneira de testar a compatibilidade do Netezza SQL com o Azure Synapse é capturar algumas instruções SQL representativas do histórico de consultas do Netezza, prefixar essas consultas com EXPLAINo e, em seguida, assumindo um modelo de dados migrado semelhante no Azure Synapse, executar essas EXPLAIN instruções no Azure Synapse. Qualquer SQL incompatível gerará um erro e as informações de erro podem determinar a escala da tarefa de recodificação.

Os parceiros da Microsoft oferecem ferramentas e serviços para migrar o Netezza SQL e os procedimentos armazenados para o Azure Synapse.

Usar ferramentas de ETL de terceiros

Conforme descrito na seção anterior, em muitos casos, o sistema de data warehouse herdado existente já será preenchido e mantido por produtos ETL de terceiros. Para obter uma lista de parceiros de integração de dados da Microsoft para o Azure Synapse, consulte Parceiros de integração de dados.

Carregamento de dados do Netezza

Opções disponíveis ao carregar dados do Netezza

Quando se trata de migrar dados de um data warehouse Netezza, existem algumas questões básicas associadas ao carregamento de dados que precisam ser resolvidas. Você precisará decidir como os dados serão movidos fisicamente do ambiente Netezza local existente para o Azure Synapse na nuvem e quais ferramentas serão usadas para executar a transferência e o carregamento. Considere as seguintes perguntas, que serão discutidas nas próximas seções.

• Você vai extrair os dados para arquivos, ou movê-los diretamente através de uma conexão de rede?

• Você orquestrará o processo a partir do sistema de origem ou do ambiente de destino do Azure?

• Quais ferramentas você usará para automatizar e gerenciar o processo?

Transferir dados através de ficheiros ou ligação de rede?

Depois que as tabelas de banco de dados a serem migradas tiverem sido criadas no Azure Synapse, você poderá mover os dados para preencher essas tabelas do sistema Netezza herdado e para o novo ambiente. Existem duas abordagens básicas:

• Extração de arquivo: extraia os dados das tabelas Netezza para arquivos simples, normalmente em formato CSV, via nzsql com a opção -o ou através da CREATE EXTERNAL TABLE instrução. Use uma tabela externa sempre que possível, pois é a mais eficiente em termos de taxa de transferência de dados. O exemplo SQL a seguir cria um arquivo CSV por meio de uma tabela externa:

  CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
  AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;
  

  Use uma tabela externa se estiver exportando dados para um sistema de arquivos montado em um host Netezza local. Se você estiver exportando dados para uma máquina remota que tenha JDBC, ODBC ou OLEDB instalado, sua opção "remotesource odbc" será a USING cláusula.

  Essa abordagem requer espaço para pousar os arquivos de dados extraídos. O espaço pode ser local para o banco de dados de origem Netezza (se houver armazenamento suficiente disponível) ou remoto no Armazenamento de Blob do Azure. O melhor desempenho é alcançado quando um arquivo é gravado localmente, uma vez que isso evita a sobrecarga da rede.

  Para minimizar os requisitos de armazenamento e transferência de rede, é uma boa prática compactar os arquivos de dados extraídos usando um utilitário como o gzip.

  Depois de extraídos, os ficheiros planos podem ser movidos para o Armazenamento de Blobs do Azure (co-localizados com a instância de destino do Azure Synapse), ou carregados diretamente no Azure Synapse usando PolyBase ou COPY INTO. O método para mover fisicamente dados do armazenamento local local para o ambiente de nuvem do Azure depende da quantidade de dados e da largura de banda de rede disponível.

  A Microsoft fornece várias opções para mover grandes volumes de dados, incluindo o AzCopy para mover arquivos pela rede para o Armazenamento do Azure, o Azure ExpressRoute para mover dados em massa por uma conexão de rede privada e o Azure Data Box para arquivos que são movidos para um dispositivo de armazenamento físico que é enviado para um data center do Azure para carregamento. Para obter mais informações, consulte transferência de dados.

• Extração direta e carregamento através da rede: o ambiente do Azure de destino envia uma solicitação de extração de dados, normalmente por meio de um comando SQL, para o sistema Netezza herdado para extrair os dados. Os resultados são enviados pela rede e carregados diretamente no Azure Synapse, sem a necessidade de colocar os dados em arquivos intermediários. O fator limitante neste cenário é normalmente a largura de banda da conexão de rede entre o banco de dados Netezza e o ambiente do Azure. Para volumes de dados muito grandes, essa abordagem pode não ser prática.

Há também uma abordagem híbrida que usa ambos os métodos. Por exemplo, você pode usar a abordagem de extração direta de rede para tabelas de dimensão menor e amostras das tabelas de fatos maiores para fornecer rapidamente um ambiente de teste no Azure Synapse. Para tabelas de fatos históricos de grande volume, você pode usar a abordagem de extração e transferência de arquivos usando o Azure Data Box.

Orquestrar a partir do Netezza ou do Azure?

A abordagem recomendada ao mover para o Azure Synapse é orquestrar a extração e o carregamento de dados do ambiente do Azure usando o Azure Synapse Pipelines ou o Azure Data Factory, bem como utilitários associados, como PolyBase ou COPY INTO, para o carregamento de dados mais eficiente. Essa abordagem aproveita os recursos do Azure e fornece um método fácil para criar pipelines de carregamento de dados reutilizáveis.

Outros benefícios dessa abordagem incluem impacto reduzido no sistema Netezza durante o processo de carregamento de dados, uma vez que o processo de gerenciamento e carregamento está sendo executado no Azure, e a capacidade de automatizar o processo usando pipelines de carga de dados orientados por metadados.

Que ferramentas podem ser utilizadas?

A tarefa de transformação e movimentação de dados é a função básica de todos os produtos ETL. Se um desses produtos já estiver em uso no ambiente Netezza existente, o uso da ferramenta ETL existente pode simplificar a migração de dados do Netezza para o Azure Synapse. Essa abordagem pressupõe que a ferramenta ETL dê suporte ao Azure Synapse como um ambiente de destino. Para obter mais informações sobre ferramentas que dão suporte ao Azure Synapse, consulte Parceiros de integração de dados.

Se você estiver usando uma ferramenta ETL, considere executar essa ferramenta no ambiente do Azure para se beneficiar do desempenho, escalabilidade e custo da nuvem do Azure e liberar recursos no data center Netezza. Outro benefício é a redução da movimentação de dados entre a nuvem e os ambientes locais.

Resumo

Para resumir, nossas recomendações para migrar dados e processos ETL associados do Netezza para o Azure Synapse são:

• Planeie com antecedência para garantir um exercício de migração bem-sucedido.

• Crie um inventário detalhado de dados e processos a serem migrados o mais rápido possível.

• Use metadados do sistema e arquivos de log para obter uma compreensão precisa dos dados e do uso do processo. Não confie na documentação, pois ela pode estar desatualizada.

• Entenda os volumes de dados a serem migrados e a largura de banda de rede entre o data center local e os ambientes de nuvem do Azure.

• Aproveite os recursos padrão "internos" do Azure para minimizar a carga de trabalho de migração.

• Identifique e compreenda as ferramentas mais eficientes para extração e carregamento de dados em ambientes Netezza e Azure. Utilize as ferramentas adequadas em cada fase do processo.

• Use os recursos do Azure, como o Azure Synapse Pipelines ou o Azure Data Factory, para orquestrar e automatizar o processo de migração, minimizando o impacto no sistema Netezza.

Próximos passos

Para saber mais sobre operações de acesso de segurança, consulte o próximo artigo desta série: Segurança, acesso e operações para migrações Netezza.