Compartilhar via

Migração de dados, ETL e carregamento para migração do Netezza

  • Artigo

Este artigo é a segunda parte de uma série de sete partes que oferece diretrizes para fazer a migração do Netezza para o Azure Synapse Analytics. O foco deste artigo são as melhores práticas para ETL e migração de carga.

Considerações sobre migração de dados

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

Ao migrar um data warehouse do 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 sobre os usuários?

  • Quando migrar data marts — continuar no físico ou usar o virtual?

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

Migrar tabelas não utilizadas?

Dica

Em sistemas herdados, não é incomum que as tabelas se tornem redundantes com o tempo.Na maioria dos casos, não é necessário migrá-las.

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, de modo que os dados fiquem disponíveis, para o caso de serem necessários no futuro. É melhor usar os metadados do sistema e os arquivos de log em vez da documentação para determinar quais tabelas estão em uso, pois a documentação pode estar desatualizada.

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

Confira 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)

Essa consulta usa a função FORMAT_TABLE_ACCESS auxiliar e o dígito no final do modo de exibição $v_hist_table_access_3 para corresponder à versão do histórico de consultas instalada.

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

Esta questão surge com frequência porque as empresas podem querer diminuir o impacto das mudanças no modelo de dados de data warehouse para melhorar a agilidade. As empresas frequentemente veem uma oportunidade de modernizar ou transformar ainda mais seus dados durante uma migração ETL. Esta abordagem carrega um risco maior porque muda múltiplos fatores simultaneamente, tornando difícil comparar os resultados do sistema antigo com o novo. Fazer alterações no modelo de dados aqui também pode afetar os trabalhos de ETL upstream ou downstream para outros sistemas. Devido a esse risco, é melhor redesenhar nesta escala após a migração do data warehouse.

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

Ao migrar do Netezza, o modelo de dados existente costuma ser adequado para a migração como está para Azure Synapse.

Dica

Inicialmente, migre o modelo existente como está, mesmo que haja um plano de alteração do modelo de dados no futuro.

Migrar data marts — continuar no físico ou usar o virtual?

Dica

A virtualização de data marts pode economizar recursos de armazenamento e de processamento.

Em ambientes herdados do data warehouse do Netezza, é 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 em uma organização. Dessa forma, um data mart normalmente é composto por um subconjunto do data warehouse e contém versões agregadas dos dados em um formulário que permite que os usuários consultem facilmente esses dados, com tempos de resposta rápidos e por meio de ferramentas de consulta simples de usar, como o Microsoft Power BI, o Tableau ou o MicroStrategy. Esse formulário costuma ser um modelo de dados dimensional. Uma das utilizações dos data marts é expor os dados em um formato utilizável, mesmo que o modelo de dados do warehouse subjacente seja um pouco diferente, como um cofre de dados.

É possível usar data marts separados para unidades de negócio individuais de uma organização a fim de implementar regimes robustos de segurança de dados, permitindo que os usuários acessem apenas os data marts específicos relevantes a eles e eliminando, ofuscando ou anonimizando dados confidenciais.

Se esses data marts forem implementados como tabelas físicas, exigirão recursos de armazenamento adicionais e mais processamento para compilá-los e atualizá-los regularmente. Além disso, o nível de atualização dos dados no mart corresponderá à última operação de atualização e, portanto, podem ser inadequados para painéis de dados altamente voláteis.

Dica

O desempenho e a escalabilidade do Azure Synapse permitem a virtualização sem sacrificar o desempenho.

Com o advento de arquiteturas MPP escalonáveis de custo relativamente baixo, como o Azure Synapse, e com as características inerentes de desempenho dessas arquiteturas, talvez você possa fornecer funcionalidade de data mart sem precisar instanciar o mart como um conjunto de tabelas físicas. Isso é feito 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 processamento adicional de armazenamento e agregação e reduz o número geral de objetos de banco de dados a serem migrados.

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

Os principais motivadores 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 mudar do que 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 historicamente mais desempenho, os produtos de virtualização agora implementam técnicas de armazenamento em cache inteligentes para mitigar.

Migração de dados do Netezza

Entender seus dados

Parte do planejamento de migração é entender detalhadamente o volume de dados que precisa ser migrado, pois isso pode afetar as decisões sobre a abordagem de migração. Use os metadados do sistema para determinar o espaço físico ocupado pelos "dados brutos" nas tabelas a serem migradas. Nesse contexto, "dados brutos" representam a quantidade de espaço usado pelas linhas de dados dentro de uma tabela, excluindo sobrecargas como índices e compactação. Isso é especialmente verdadeiro para as maiores tabelas de fatos, pois elas normalmente abrangem mais de 95% dos dados.

Você pode obter um número preciso do 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 dar um tamanho dados brutos para a tabela. Use esse tamanho de dados brutos em seu planejamento.

Mapeamento do tipo de dados do Netezza

Dica

Avalie o impacto dos tipos de dados sem suporte como parte da fase de preparação.

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

Tipo de dados do Netezza Tipo de dados do Azure Synapse
bigint bigint
BINARY VARYING(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) CHAR(n)
DATE DATE(data)
DECIMAL(p,s) DECIMAL(p,s)
DOUBLE PRECISION FLOAT
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL Atualmente, os tipos de dados INTERVAL não têm suporte direto no Azure Synapse Analytics, mas podem ser calculados usando funções temporais, como DATEDIFF.
MONEY MONEY
NATIONAL CHARACTER VARYING(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
real real
SMALLINT SMALLINT
ST_GEOMETRY(n) Atualmente, não há suporte para tipos de dados espaciais, como ST_GEOMETRY, no Azure Synapse Analytics, mas os dados podem ser armazenados como VARCHAR ou VARBINARY.
TIME TIME
TIME WITH TIME ZONE DATETIMEOFFSET
timestamp DATETIME

Use os metadados das tabelas do catálogo do Netezza para determinar se algum desses tipos de dados deve ser migrado e inclua isso no plano de migração. As exibições de metadados importantes no Netezza para esse tipo de consulta são:

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

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

  • _V_RELATION_COLUMN: a exibição do catálogo do sistema de colunas de relação contém as colunas disponíveis em uma tabela.

  • _V_OBJECTS: a exibiçã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 do 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 pesquisar todas as tabelas em busca de ocorrências de tipos de dados sem suporte.

O Azure Data Factory pode ser usado para mover dados de um ambiente herdado do Netezza. Para saber mais, confira Conector do IBM Netezza.

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

Considerações sobre a migração de ETL

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

Dica

Planeje a abordagem para a migração de ETL com antecedência e aproveite as instalações do Azure quando apropriado.

Para processamento de ETL/ELT, os data warehouses herdados do Netezza podem usar scripts personalizados usando utilitários do Netezza, como nzsql e nzload, ou ferramentas de ETL de terceiros, como Informatica ou Ab Initio. Às vezes, os data warehouses do Netezza usam uma combinação de abordagens ETL e ELT que evoluíram ao longo do tempo. Ao planejar uma migração para 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, confira a abordagem de design ELT versus ETL.

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

Fluxograma de opções de migração e recomendações.

A primeira etapa é sempre criar um inventário de processos ETL/ELT que precisam ser migrados. Assim como em 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 executada.

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

Dica

Aproveite o investimento em ferramentas de terceiros existentes para reduzir o custo e o risco.

Se uma ferramenta ETL de terceiros já estiver em uso e, principalmente, se houver um grande investimento em habilidades ou se vários fluxos de trabalho e agendamentos existentes usarem essa ferramenta, a decisão 3 será verificar se a ferramenta pode dar suporte eficiente ao Azure Synapse como um ambiente de destino. Idealmente, a ferramenta incluirá conectores "nativos" que podem aproveitar os 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 os fluxos de trabalho existentes, com o Azure Synapse como o novo ambiente de destino.

Se você decidir manter uma ferramenta de ETL de terceiros existente, talvez haja benefícios na execução dessa ferramenta dentro do ambiente do Azure (em vez de em um servidor ETL local existente) e fazer o Azure Data Factory lidar 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 carregados novamente no Azure. Portanto, a decisão 4 é se você vai deixar a ferramenta existente em execução como está ou se vai movê-la para o ambiente do Azure, a fim de obter benefícios de custo, desempenho e escalabilidade.

Reprojetar scripts específicos do Netezza existentes

Se parte ou todo o processamento existente de ETL/ELT do warehouse do Netezza for tratado por scripts personalizados que usam 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 de ETL foram implementados usando procedimentos armazenados no Netezza, eles também precisarão ser recodificados.

Dica

O inventário de tarefas de ETL a serem migradas deve incluir scripts e procedimentos armazenados.

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

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 EXPLAIN e, em seguida, assumindo um modelo de dados migrado semelhante no Azure Synapse, executar essas instruções EXPLAIN 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.

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

Usar ferramentas 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 Azure Synapse, confira Parceiros de integração de dados.

Carregamento de dados do Netezza

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

Dica

Ferramentas de terceiros podem simplificar e automatizar o processo de migração e, portanto, reduzir riscos.

Ao migrar dados de um data warehouse do Netezza, há algumas perguntas básicas associadas ao carregamento de dados que precisam ser resolvidas. Você precisará decidir como os dados serão movidos fisicamente do ambiente do 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 perguntas a seguir, que serão discutidas nas próximas seções.

  • Você extrairá os dados para arquivos ou os moverá diretamente por meio de uma conexão de rede?

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

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

Transferir dados por meio de arquivos ou conexão de rede?

Dica

Entenda os volumes de dados a serem migrados e a largura de banda de rede disponível, pois esses fatores influenciam a decisão sobre como conduzir a migração.

Após a criação das tabelas de banco de dados a serem migradas no Azure Synapse, você poderá mover os dados para preencher essas tabelas do sistema herdado do Netezza e carregá-las no novo ambiente. Há duas abordagens básicas:

  • Extração de arquivo: extraia os dados das tabelas do Netezza para arquivos simples, normalmente no formato CSV, via nzsql com a opção -o ou via CREATE EXTERNAL TABLEinstrução. Use uma tabela externa sempre que possível, pois é o mais eficiente em termos de taxa de transferência de dados. O exemplo de 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 local do Netezza. Se você estiver exportando dados para uma máquina remota que tenha JDBC, ODBC ou OLEDB instalado, sua opção "odbc de fonte remota" será a USINGcláusula.

    Essa abordagem exige espaço para guardar os arquivos de dados extraídos. O espaço pode ser local para o banco de dados de origem do Netezza (se houver armazenamento suficiente disponível) ou remoto no Armazenamento de Blobs do Azure. O melhor desempenho é obtido quando um arquivo é gravado localmente, pois isso evita a sobrecarga de 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 gzip.

    Depois de extraídos, os arquivos simples podem ser movidos para o Armazenamento de Blobs do Azure (colocados com a instância do Azure Synapse de destino) ou carregados diretamente no Azure Synapse usando PolyBase ou COPY INTO. O método para transferência física de dados do armazenamento local para o ambiente em nuvem do Azure depende da quantidade de dados e da largura de banda de rede disponível.

    A Microsoft fornece diversas 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 em uma conexão de rede privada e o Azure Data Box, para arquivos em transferência para um dispositivo de armazenamento físico, que, depois, é enviado para um data center do Azure para carregamento. Para saber mais, confira transferência de dados.

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

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

Orquestrar 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 Pipelines do Azure Synapse ou o Azure Data Factory, bem como utilitários associados, como PolyBase ou COPY INTO, para um 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 o impacto reduzido no sistema do Netezza durante o processo de carregamento de dados, já que o processo de gerenciamento e carregamento está em execução no Azure e a capacidade de automatizar o processo usando pipelines de carregamento de dados controlados por metadados.

Quais ferramentas podem ser usadas?

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

Se você estiver usando uma ferramenta de 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 do 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 de ETL associados do Netezza para o Azure Synapse são:

  • Planeje 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 de uso de dados e de 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 entenda as ferramentas mais eficientes para extração e carregamento de dados em ambientes do Teradata e do Azure. Use as ferramentas apropriadas em cada fase do processo.

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

Próximas etapas

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