Minimizar problemas de SQL para migrações Teradata

Este artigo é a quinta parte de uma série de sete partes que fornece orientação sobre como migrar do Teradata 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 Teradata

Em 1984, a Teradata lançou inicialmente seu produto de banco de dados. Ele introduziu técnicas de processamento paralelo maciço (MPP) para permitir o processamento de dados em uma escala mais eficiente do que as tecnologias de mainframe existentes disponíveis na época. 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 e estava ligada a mainframes — geralmente processadores IBM ou compatíveis com IBM.

Embora os anúncios mais recentes tenham incluído a conectividade de rede e a disponibilidade da pilha de tecnologia Teradata na nuvem (incluindo o Azure), a maioria das instalações existentes está no local, então muitos usuários estão considerando migrar alguns ou todos os seus dados Teradata para o Azure Synapse Analytics para obter os benefícios de uma mudança para um ambiente de nuvem moderno.

A tecnologia Teradata é frequentemente usada para implementar um data warehouse, 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 a duração. 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 Teradata herdado e fornece soluções alternativas.

Usar uma instância do Azure VM Teradata como parte de uma migração

Aproveite o ambiente do Azure ao executar uma migração de um ambiente Teradata local. O Azure fornece armazenamento em nuvem acessível e escalabilidade elástica para criar uma instância Teradata dentro de uma VM no Azure, colocada com o ambiente Synapse do Azure de destino.

Com essa abordagem, utilitários Teradata padrão, como o Teradata Parallel Data Transporter (ou ferramentas de replicação de dados de terceiros, como o Attunity Replicate), podem ser usados para mover com eficiência o subconjunto de tabelas Teradata que devem ser migradas para a instância da VM e, em seguida, todas as tarefas de migração podem ocorrer no ambiente do Azure. Esta abordagem tem várias vantagens:

• Após a replicação inicial dos dados, o sistema de origem não é afetado pelas tarefas de migração.

• As interfaces, ferramentas e utilitários familiares do Teradata estão disponíveis no ambiente do Azure.

• Uma vez no ambiente do Azure, não há problemas potenciais com a disponibilidade de largura de banda de rede entre o sistema de origem local e o sistema de destino na nuvem.

• Ferramentas como o Azure Data Factory podem chamar utilitários como o Teradata Parallel Transporter de forma eficiente para migrar dados de forma rápida e fácil.

• O processo de migração é orquestrado e controlado inteiramente no ambiente do Azure.

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 Teradata existente, que pode já estar sendo executado 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 Teradata 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 Teradata 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 Teradata 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, não há equivalente da MULTISET opção na sintaxe do CREATE TABLE Teradata.

É 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 um índice secundário não exclusivo (NUSI) tiver sido criado no ambiente Teradata 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 uma criação de índices "semelhante a semelhante".

Tipos de tabela Teradata não suportados

O Teradata inclui suporte para tipos de tabela especiais para séries temporais e dados temporais. A sintaxe e algumas das funções para esses tipos de tabela não têm suporte direto no Azure Synapse, mas os dados podem ser migrados para uma tabela padrão com tipos de dados apropriados e indexação ou particionamento na coluna de data/hora.

O Teradata implementa a funcionalidade de consulta temporal por meio da regravação de consultas para adicionar filtros adicionais dentro de uma consulta temporal para limitar o intervalo de datas aplicável. Se essa funcionalidade estiver atualmente em uso no ambiente Teradata de origem e for migrada, essa filtragem adicional precisará ser adicionada às consultas temporais relevantes.

O ambiente do Azure também inclui recursos específicos para análises complexas em dados de séries temporais em escala, conhecidos como insights de séries temporais — que são destinados a aplicativos de análise de dados IoT e podem ser mais apropriados para este caso de uso.

Tipos de dados Teradata não suportados

A maioria dos tipos de dados Teradata tem um equivalente direto no Azure Synapse. A tabela a seguir mostra os tipos de dados Teradata sem suporte no Azure Synapse juntamente com o mapeamento recomendado. Na tabela, o tipo de coluna Teradata é o tipo armazenado no catálogo do sistema — por exemplo, em DBC.ColumnsV.

Use os metadados das tabelas do catálogo Teradata para determinar se algum desses tipos de dados deve ser migrado e permitir isso no plano de migração. Por exemplo, use uma consulta SQL como esta para localizar quaisquer ocorrências de tipos de dados sem suporte que precisem de atenção.

SELECT
ColumnType, CASE
WHEN ColumnType = '++' THEN 'TD_ANYTYPE' 
WHEN ColumnType = 'A1' THEN 'ARRAY' WHEN 
ColumnType = 'AN' THEN 'ARRAY' WHEN 
ColumnType = 'BO' THEN 'BLOB'
WHEN ColumnType = 'CO' THEN 'CLOB'
WHEN ColumnType = 'DH' THEN 'INTERVAL DAY TO HOUR' WHEN 
ColumnType = 'DM' THEN 'INTERVAL DAY TO MINUTE' WHEN 
ColumnType = 'DS' THEN 'INTERVAL DAY TO SECOND' WHEN
ColumnType = 'DT' THEN 'DATASET'
WHEN ColumnType = 'DY' THEN 'INTERVAL DAY'
WHEN ColumnType = 'HM' THEN 'INTERVAL HOUR TO MINUTE' WHEN
ColumnType = 'HR' THEN 'INTERVAL HOUR'
WHEN ColumnType = 'HS' THEN 'INTERVAL HOUR TO SECOND' WHEN
ColumnType = 'JN' THEN 'JSON'
WHEN ColumnType = 'MI' THEN 'INTERVAL MINUTE' WHEN 
ColumnType = 'MO' THEN 'INTERVAL MONTH'
WHEN ColumnType = 'MS' THEN 'INTERVAL MINUTE TO SECOND' WHEN
ColumnType = 'PD' THEN 'PERIOD(DATE)'
WHEN ColumnType = 'PM' THEN 'PERIOD (TIMESTAMP WITH TIME ZONE)'
WHEN ColumnType = 'PS' THEN 'PERIOD(TIMESTAMP)' WHEN 
ColumnType = 'PT' THEN 'PERIOD(TIME)'
WHEN ColumnType = 'PZ' THEN 'PERIOD (TIME WITH TIME ZONE)' WHEN
ColumnType = 'SC' THEN 'INTERVAL SECOND'
WHEN ColumnType = 'SZ' THEN 'TIMESTAMP WITH TIME ZONE' WHEN
ColumnType = 'XM' THEN 'XML'
WHEN ColumnType = 'YM' THEN 'INTERVAL YEAR TO MONTH' WHEN
ColumnType = 'YR' THEN 'INTERVAL YEAR'
END AS Data_Type,
COUNT (*) AS Data_Type_Count FROM
DBC.ColumnsV
WHERE DatabaseName IN ('UserDB1', 'UserDB2', 'UserDB3') -- select databases to be migrated
GROUP BY 1,2
ORDER BY 1;

Existem fornecedores terceirizados que oferecem ferramentas e serviços para automatizar a migração, incluindo o mapeamento de tipos de dados. Se uma ferramenta ETL de terceiros, como Informatica ou Talend, já estiver em uso no ambiente Teradata, essas ferramentas poderão implementar quaisquer transformações de dados necessárias.

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

Edite Teradata 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 a remoção de cláusulas adicionais específicas do Teradata, como FALLBACK ou MULTISET.

No entanto, todas as informações que especificam as definições atuais de tabelas e exibições dentro do ambiente Teradata existente são mantidas nas tabelas do catálogo do sistema. Esta é a melhor fonte desta informação, pois é garantido 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 por meio de exibições no catálogo, como DBC.ColumnsV e gere as instruções DDL equivalentes CREATE TABLE 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 Teradata, essa ferramenta poderá implementar quaisquer transformações de dados necessárias.

Diferenças do SQL DML entre o Teradata e o 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 Teradata 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 Teradata 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 Teradata SQL e o Azure Synapse (T-SQL) ao migrar:

• QUALIFY: Teradata suporta o QUALIFY operador. Por exemplo:

  SELECT col1
  FROM tab1
  WHERE col1='XYZ'
  QUALIFY ROW_NUMBER () OVER (PARTITION by
  col1 ORDER BY col1) = 1;
  

  A sintaxe equivalente do Azure Synapse é:

  SELECT * FROM (
  SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
  FROM tab1 WHERE col1='XYZ'
  ) WHERE rn = 1;
  

• Aritmética de data: o Azure Synapse tem operadores como DATEADD e DATEDIFF que podem ser usados em DATE campos ou DATETIME . O Teradata suporta subtração direta em datas como SELECT DATE1 - DATE2 FROM...

• Em GROUP BY ordinal, forneça explicitamente o nome da coluna T-SQL.

• LIKE ANY: Teradata suporta LIKE ANY sintaxe como:

  SELECT * FROM CUSTOMER
  WHERE POSTCODE LIKE ANY
  ('CV1%', 'CV2%', 'CV3%');
  

  O equivalente na sintaxe do Azure Synapse é:

  SELECT * FROM CUSTOMER
  WHERE
  (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
  

• Dependendo das configurações do sistema, as comparações de caracteres no Teradata podem não diferenciar maiúsculas de minúsculas por padrão. No Azure Synapse, as comparações de caracteres são sempre sensíveis a maiúsculas e minúsculas.

Use EXPLAIN para validar SQL herdado

Uma maneira de testar a compatibilidade do Teradata SQL herdado com o Azure Synapse é capturar algumas instruções SQL representativas dos logs de consulta do sistema herdado, prefixar essas consultas com EXPLAINe (assumindo um modelo de dados migrado "semelhante para semelhante" no Azure Synapse com os mesmos nomes de tabela e coluna) executar essas EXPLAIN instruções no Azure Synapse. Qualquer SQL incompatível lançará 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.

Funções, procedimentos armazenados, gatilhos e sequências

Ao migrar de um ambiente de data warehouse herdado maduro, como o Teradata, 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, gatilhos 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 Teradata. Nesse caso, geralmente é mais eficiente usar os recursos internos do Azure em vez de recodificar as funções do Teradata.

Os parceiros da Microsoft oferecem ferramentas e serviços que podem automatizar a migração.

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

Funções

Como acontece com a maioria dos produtos de banco de dados, Teradata 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.

Procedimentos armazenados

A maioria dos produtos de banco de dados modernos permite que os procedimentos sejam armazenados no banco de dados. Teradata fornece a linguagem SPL para esta finalidade. Um procedimento armazenado normalmente contém instruções SQL e alguma lógica processual e pode retornar dados ou um status.

Os pools SQL dedicados do Azure Synapse Analytics também dão suporte a procedimentos armazenados usando T-SQL, portanto, se você precisar migrar procedimentos armazenados, recodifice-os adequadamente.

Acionadores

O Azure Synapse não dá suporte à criação de gatilhos, mas você pode implementá-los no Azure Data Factory.

Sequências

As sequências do Azure Synapse são tratadas de forma semelhante ao Teradata, usando IDENTITY para criar chaves substitutas ou identidade gerenciada.

Mapeamento de Teradata para T-SQL

Esta tabela mostra o mapeamento de tipos de dados do Teradata para T-SQL em conformidade com o SQL do Azure Synapse.

Resumo

As instalações herdadas típicas de Teradata existentes 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 eventual ambiente final incorpore um modelo de dados diferente, como o data vault.

• Considere usar uma instância Teradata em uma VM do Azure como um trampolim como parte do processo de migração.

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

• Use metadados e logs de consulta da implementação existente do Teradata 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 Teradata para o Azure Synapse Analytics.