Minimizar problemas de SQL para migrações Netezza

Este artigo é a quinta 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 minimizar problemas de SQL.

Visão geral

Características dos ambientes Netezza

Em 2003, a Netezza lançou inicialmente seu produto de appliance de armazém de dados. Ele reduziu o custo de entrada e melhorou a facilidade de uso de técnicas de processamento paralelo maciço (MPP) para permitir o processamento de dados em escala de forma mais eficiente do que o mainframe existente ou outras tecnologias MPP disponíveis no momento. Desde então, o produto evoluiu e tem muitas instalações entre grandes instituições financeiras, telecomunicações e empresas de varejo. A implementação original usava hardware proprietário, incluindo matrizes de porta programáveis de campo — ou FPGAs — e era acessível via conexão de rede ODBC ou JDBC via TCP/IP.

A maioria das instalações Netezza existentes são locais, então muitos usuários estão considerando migrar alguns ou todos os seus dados Netezza para o Azure Synapse Analytics para obter os benefícios de uma mudança para um ambiente de nuvem moderno.

A tecnologia Netezza é frequentemente usada para implementar um armazém de dados, suportando consultas analíticas complexas em grandes volumes de dados usando SQL. Modelos de dados dimensionais — esquemas de estrelas ou flocos de neve — são comuns, assim como a implementação de data marts para departamentos individuais.

Essa combinação de SQL e modelos de dados dimensionais simplifica a migração para o Azure Synapse, uma vez que os conceitos básicos e as habilidades SQL são transferíveis. A abordagem recomendada é migrar o modelo de dados existente as-is para reduzir o risco e o tempo despendido. Mesmo que a intenção final seja fazer alterações no modelo de dados (por exemplo, mudar para um modelo de cofre de dados), execute uma migração inicial de as-is e, em seguida, faça alterações no ambiente de nuvem do Azure, aproveitando o desempenho, a escalabilidade elástica e as vantagens de custo.

Embora a linguagem SQL tenha sido padronizada, fornecedores individuais implementaram, em alguns casos, extensões proprietárias. Este documento destaca possíveis diferenças SQL que você pode encontrar ao migrar de um ambiente Netezza herdado e fornece soluções alternativas.

Usar o Azure Data Factory para implementar uma migração orientada por metadados

Automatize e orquestre o processo de migração usando os recursos no ambiente do Azure. Essa abordagem também minimiza o impacto da migração no ambiente Netezza existente, que já pode estar funcionando perto da capacidade total.

O Azure Data Factory é um serviço de integração de dados baseado na nuvem que permite a criação de fluxos de trabalho orientados por dados na nuvem para orquestrar e automatizar a movimentação e a transformação de dados. Usando o Data Factory, você pode criar e agendar fluxos de trabalho controlados por dados, chamados pipelines, que podem ingerir dados de armazenamentos de dados diferentes. Ele pode processar e transformar dados usando serviços de computação como Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

Ao criar metadados para listar as tabelas de dados a serem migradas e sua localização, você pode usar os recursos do Data Factory para gerenciar e automatizar partes do processo de migração. Você também pode usar o Azure Synapse Pipelines.

Diferenças de DDL SQL entre Netezza e Azure Synapse

Linguagem de definição de dados SQL (DDL)

O padrão ANSI SQL define a sintaxe básica para comandos DDL, como CREATE TABLE e CREATE VIEW. Esses comandos são usados no Netezza e no Azure Synapse, mas também foram estendidos para permitir a definição de recursos específicos da implementação, como indexação, distribuição de tabela e opções de particionamento.

As seções a seguir discutem as opções específicas do Netezza a serem consideradas durante uma migração para o Azure Synapse.

Considerações sobre a tabela

Ao migrar tabelas entre tecnologias diferentes, apenas os dados brutos e seus metadados descritivos são movidos fisicamente entre os dois ambientes. Outros elementos de banco de dados do sistema de origem, como índices e arquivos de log, não são migrados diretamente, pois podem não ser necessários ou podem ser implementados de forma diferente no novo ambiente de destino. Por exemplo, a opção TEMPORARY dentro da sintaxe do Netezza CREATE TABLE é equivalente a prefixar o nome da tabela com um caractere "#" no Azure Synapse.

É importante entender onde as otimizações de desempenho, como índices, foram usadas no ambiente de origem. Isso indica onde a otimização de desempenho pode ser adicionada no novo ambiente de destino. Por exemplo, se os mapas de zona foram criados no ambiente Netezza de origem, isso pode indicar que um índice não clusterizado deve ser criado no banco de dados migrado do Azure Synapse. Outras técnicas nativas de otimização de desempenho, como a replicação de tabelas, podem ser mais aplicáveis do que a criação direta de um índice equivalente.

Tipos de objeto de banco de dados Netezza não suportados

O Netezza implementa alguns objetos de banco de dados que não são diretamente suportados no Azure Synapse, mas há métodos para obter a mesma funcionalidade dentro do novo ambiente:

• Mapas de zona: no Netezza, os mapas de zona são criados e mantidos automaticamente para alguns tipos de coluna e são usados no momento da consulta para restringir a quantidade de dados a serem digitalizados. Os mapas de zona são criados nos seguintes tipos de coluna:

  • INTEGER colunas de comprimento igual ou inferior a 8 bytes.
  • Colunas temporais. Por exemplo, DATE, TIME, e TIMESTAMP.
  • CHAR colunas, se estas fizerem parte de uma visão materializada e estiverem mencionadas na ORDER BY cláusula.

  Você pode descobrir quais colunas têm mapas de zona usando o nz_zonemap utilitário, que faz parte do NZ Toolkit. O Azure Synapse não inclui mapas de zona, mas você pode obter resultados semelhantes usando outros tipos de índice definidos pelo usuário e/ou particionamento.

• Tabelas de base agrupadas (CBT): em Netezza, as CBTs são comumente usadas para tabelas de fatos, que podem ter bilhões de registros. A digitalização de uma tabela tão grande requer muito tempo de processamento, uma vez que uma verificação completa da tabela pode ser necessária para obter registros relevantes. A organização de registos em CBT restritivo permite que o Netezza agrupe registos em extensões próximas ou iguais. Esse processo também cria mapas de zona que melhoram o desempenho, reduzindo a quantidade de dados a serem digitalizados.

  No Azure Synapse, você pode obter um efeito semelhante usando particionamento e/ou uso de outros índices.

• Visualizações materializadas: O Netezza suporta visualizações materializadas e recomenda a criação de uma ou mais delas em tabelas grandes com muitas colunas onde apenas algumas dessas colunas são usadas regularmente em consultas. O sistema mantém automaticamente visualizações materializadas quando os dados na tabela base são atualizados.

  O Azure Synapse suporta vistas materializadas, com a mesma funcionalidade do Netezza.

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.

Geração de linguagem de definição de dados (DDL)

Edite Netezza CREATE TABLE e CREATE VIEW scripts existentes para criar as definições equivalentes com tipos de dados modificados, conforme descrito anteriormente, se necessário. Normalmente, isso envolve remover ou modificar quaisquer cláusulas adicionais específicas do Netezza, como ORGANIZE ON.

No entanto, todas as informações que especificam as definições atuais de tabelas e exibições dentro do ambiente Netezza existente são mantidas dentro das tabelas de catálogo do sistema. Esta é a melhor fonte desta informação, uma vez que é garantida de estar atualizada e completa. Lembre-se de que a documentação mantida pelo usuário pode não estar em sincronia com as definições de tabela atuais.

Acesse essas informações usando utilitários como nz_ddl_table e gere as CREATE TABLE instruções DDL. Edite essas declarações para as tabelas equivalentes no Azure Synapse.

Existem parceiros da Microsoft que oferecem ferramentas e serviços para automatizar a migração, incluindo mapeamento de tipo de dados. Além disso, se uma ferramenta ETL de terceiros, como Informatica ou Talend, já estiver em uso no ambiente Netezza, essa ferramenta poderá implementar quaisquer transformações de dados necessárias.

Diferenças do SQL DML entre Netezza e Azure Synapse

Linguagem de manipulação de dados SQL (DML)

O padrão ANSI SQL define a sintaxe básica para comandos DML, como SELECT, INSERT, UPDATEe DELETE. Tanto o Netezza quanto o Azure Synapse usam esses comandos, mas em alguns casos há diferenças de implementação.

As seções a seguir discutem os comandos DML específicos do Netezza que você deve considerar durante uma migração para o Azure Synapse.

Diferenças de sintaxe do SQL DML

Esteja ciente dessas diferenças na sintaxe DML (SQL Data Manipulation Language) entre o Netezza SQL e o Azure Synapse ao migrar:

• STRPOS: em Netezza, a STRPOS função retorna a posição de uma substring dentro de uma string. A função equivalente no Azure Synapse é CHARINDEX, com a ordem dos argumentos invertida. Por exemplo, SELECT STRPOS('abcdef','def')... no Netezza é equivalente ao SELECT CHARINDEX('def','abcdef')... no Azure Synapse.

• AGE: Netezza suporta o operador AGE para calcular o intervalo entre dois valores temporais, como carimbos de data/hora ou datas. Por exemplo, SELECT AGE('23-03-1956','01-01-2019') FROM.... No Azure Synapse, DATEDIFF dá o intervalo. Por exemplo, SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM.... Observe a sequência de representação de data.

• NOW(): Netezza usa NOW() para representar CURRENT_TIMESTAMP no Azure Synapse.

Funções, procedimentos armazenados e sequências

Ao migrar de um ambiente de data warehouse herdado maduro, como o Netezza, geralmente há elementos além de tabelas e exibições simples que precisam ser migrados para o novo ambiente de destino. Exemplos disso incluem funções, procedimentos armazenados e sequências.

Como parte da fase de preparação, crie um inventário dos objetos que precisam ser migrados e defina os métodos para manipulá-los. Em seguida, atribua uma alocação apropriada de recursos no plano do projeto.

Pode haver recursos no ambiente do Azure que substituam a funcionalidade implementada como funções ou procedimentos armazenados no ambiente Netezza. Nesse caso, geralmente é mais eficiente usar os recursos internos do Azure em vez de recodificar as funções do Netezza.

Os parceiros da Microsoft oferecem ferramentas e serviços que podem automatizar a migração, incluindo o mapeamento de tipos de dados. Além disso, ferramentas ETL de terceiros, como Informatica ou Talend, que já estão em uso no ambiente IBM Netezza podem implementar quaisquer transformações de dados necessárias.

Consulte as seções a seguir para obter mais informações sobre cada um desses elementos.

Funções

Tal como acontece com a maioria dos produtos de banco de dados, Netezza suporta funções do sistema e funções definidas pelo usuário dentro da implementação SQL. Ao migrar para outra plataforma de banco de dados, como o Azure Synapse, as funções comuns do sistema estão disponíveis e podem ser migradas sem alterações. Algumas funções do sistema podem ter sintaxe ligeiramente diferente, mas as alterações necessárias podem ser automatizadas. As funções do sistema onde não há equivalente, como funções arbitrárias definidas pelo usuário, podem precisar ser recodificadas usando os idiomas disponíveis no ambiente de destino. O Azure Synapse usa a linguagem Transact-SQL popular para implementar funções definidas pelo usuário. As funções definidas pelo usuário Netezza são codificadas em linguagens nzlua ou C++.

Procedimentos armazenados

A maioria dos produtos de banco de dados modernos permite que os procedimentos sejam armazenados no banco de dados. Netezza fornece a linguagem NZPLSQL, que é baseada em Postgres PL / pgSQL. Um procedimento armazenado normalmente contém instruções SQL e alguma lógica processual e pode retornar dados ou um status.

O Azure Synapse Analytics também dá suporte a procedimentos armazenados usando T-SQL, portanto, se você precisar migrar procedimentos armazenados, recodifice-os adequadamente.

Sequências

Em Netezza, uma sequência é um objeto de banco de dados nomeado criado por meio de CREATE SEQUENCE, que pode fornecer o valor exclusivo através do método NEXT VALUE FOR. Use-os para gerar números exclusivos para uso como valores de chave substituta para valores de chave primária.

No Azure Synapse, não há CREATE SEQUENCE. As sequências são manipuladas usando IDENTITY para criar chaves substitutas ou identidade gerenciada usando código SQL para criar o próximo número de sequência em uma série.

Use EXPLAIN para validar SQL herdado

Capture algumas instruções SQL representativas dos logs de histórico de consultas herdados para avaliar a compatibilidade do Netezza SQL herdado com o Azure Synapse. Em seguida, prefixe essas consultas com EXPLAIN e, assumindo um modelo de dados migrado equivalente no Azure Synapse com os mesmos nomes de tabela e coluna, execute essas EXPLAIN instruções no Azure Synapse. Qualquer SQL incompatível retornará um erro. Use essas informações para determinar a escala da tarefa de recodificação. Essa abordagem não exige que os dados sejam carregados no ambiente do Azure, apenas que as tabelas e exibições relevantes tenham sido criadas.

Mapeamento de IBM Netezza para T-SQL

O mapeamento de tipo de dados IBM Netezza para T-SQL compatível com o Azure Synapse SQL está nesta tabela:

Resumo

As instalações herdadas típicas do Netezza são implementadas de uma forma que facilita a migração para o Azure Synapse. Eles usam SQL para consultas analíticas em grandes volumes de dados e estão em alguma forma de modelo de dados dimensionais. Esses fatores os tornam bons candidatos para a migração para o Azure Synapse.

Para minimizar a tarefa de migrar o código SQL real, siga estas recomendações:

• A migração inicial do data warehouse deve ser as-is para minimizar o risco e o tempo necessário, mesmo que o ambiente final eventual incorpore um modelo de dados diferente, como o data vault.

• Entenda as diferenças entre a implementação do Netezza SQL e o Azure Synapse.

• Use metadados e logs de consulta da implementação Netezza existente para avaliar o impacto das diferenças e planejar uma abordagem para mitigar.

• Automatize o processo sempre que possível para minimizar erros, riscos e tempo para a migração.

• Considere o uso de parceiros e serviços especializados da Microsoft para simplificar a migração.

Próximos passos

Para saber mais sobre a Microsoft e ferramentas de terceiros, consulte o próximo artigo desta série: Ferramentas para migração de data warehouse Netezza para o Azure Synapse Analytics.