Design e desempenho para migrações do Teradata

Esta é a primeira parte de uma série de sete artigos que orientam sobre como migrar do Teradata para o Azure Synapse Analytics. O foco deste artigo é fornecer práticas recomendadas de design e desempenho.

Visão geral

Muitos usuários de sistemas de data warehouse Teradata desejam aproveitar as inovações fornecidas pelos ambientes de nuvem modernos. A IaaS (infraestrutura como serviço) e os ambientes de nuvem PaaS (plataforma como serviço) permitem delegar tarefas como manutenção de infraestrutura e desenvolvimento de plataforma ao provedor de nuvem.

Dica

Mais do que apenas um banco de dados — o ambiente do Azure inclui um conjunto abrangente de recursos e ferramentas.

Embora o Teradata e o Azure Synapse sejam semelhantes por serem ambos bancos de dados SQL que usam técnicas de MPP (processamento paralelo massivo) a fim de obter alto desempenho de consulta em grandes volumes de dados, eles têm algumas diferenças básicas:

• Os sistemas herdados do Teradata geralmente são instalados localmente e usam hardware proprietário, enquanto Azure Synapse é baseado em nuvem e usa recursos de computação e Armazenamento do Azure.

• Como os recursos de armazenamento e computação são separados no ambiente do Azure e têm recursos de escalonamento elásticos, eles podem ser dimensionados para mais ou para menos de forma independente.

• É possível pausar ou redimensionar o Azure Synapse conforme necessário para reduzir a utilização de recursos e o custo.

• Atualizar uma configuração do Teradata é uma tarefa importante que envolve hardware físico adicional e um trabalho de reconfiguração ou recarga de banco de dados potencialmente demorado.

O Microsoft Azure é um ambiente de nuvem escalonável, altamente seguro e disponível globalmente que inclui o Azure Synapse em um ecossistema de ferramentas e recursos de suporte. O próximo diagrama resume o ecossistema do Azure Synapse.

O Azure Synapse fornece o melhor desempenho da categoria de bancos de dados relacionais com o uso de técnicas como MPP e vários níveis de cache automatizado para dados usados com frequência. Os resultados dessas técnicas podem ser vistos em parâmetros de comparação independentes, como aquele executado recentemente pela GigaOm, que compara o Azure Synapse com outras ofertas de data warehouse de nuvem populares. Os clientes que migram para o ambiente Azure Synapse observam muitos benefícios, inclusive:

• Desempenho e preço por desempenho aprimorados.

• Maior agilidade e menor tempo de retorno.

• Implantação de servidor e desenvolvimento de aplicativos mais rápidos.

• Escalabilidade elástica – pague apenas pelo uso real.

• Melhora da segurança/conformidade.

• Custos reduzidos de armazenamento e recuperação de desastre.

• TCO geral mais baixo, melhor controle de custo e OPEX (despesas operacionais simplificadas).

Para maximizar esses benefícios, migre dados e aplicativos novos ou existentes para a plataforma do Azure Synapse. Em muitas organizações, a migração inclui mover um data warehouse existente de uma plataforma local herdada, como o Teradata, para o Azure Synapse. Em alto nível, o processo de migração inclui estas etapas:

    Preparação 🡆

• Definir escopo – o que deve ser migrado.

• Compilar o inventário de dados e processos para migração.

• Definir alterações de modelo de dados (se houver).

• Definir o mecanismo de extração de dados de origem.

• Identificar as ferramentas e recursos de terceiros e do Azure apropriados a este uso.

• Treine a equipe antecipadamente na nova plataforma.

• Configure a plataforma de destino do Azure.

    Migração 🡆

• Comece aos poucos e de maneira simples.

• Automatize sempre que possível.

• Use ferramentas e recursos internos do Azure para reduzir o esforço de migração.

• Migre metadados para tabelas e exibições.

• Migre os dados históricos a serem mantidos.

• Migre ou refatore os processos de negócios e procedimentos armazenados.

• Migre ou refatore os processos de carga incremental de ETL/ELT.

    Pós-migração

• Monitore e documente todos os estágios do processo.

• Use a experiência adquirida para criar um modelo para migrações futuras.

• Refaça a engenharia do modelo de dados, se preciso (usando o novo desempenho e a escalabilidade da plataforma).

• Aplicativos de teste e ferramentas de consulta.

• Crie um parâmetro de comparação e otimize o desempenho da consulta.

Este artigo fornece informações gerais e diretrizes para otimização de desempenho ao migrar um data warehouse de um ambiente Netezza existente para o Azure Synapse. A meta de otimização de desempenho é alcançar o desempenho igual ou melhor do data warehouse no Azure Synapse após a migração do esquema.

Considerações sobre o design

Escopo da migração

Ao se preparar para migrar de um ambiente Teradata, considere as seguintes opções de migração.

Escolha a carga de trabalho para a migração inicial

Normalmente, os ambientes Teradata herdados evoluem ao longo do tempo para abranger várias áreas de assunto e cargas de trabalho mistas. Ao decidir onde iniciar um projeto de migração, escolha uma área em que você possa:

• Comprove a viabilidade da migração para o Azure Synapse por meio da entrega rápida de benefícios do novo ambiente.

• Permitir que sua equipe técnica interna ganhe experiência relevante com os processos e as ferramentas que eles usarão ao migrar outras áreas.

• Criar um modelo para migrações adicionais específicas do ambiente Teradata de origem e as ferramentas e processos atuais já em vigor.

Um bom candidato à migração inicial de um ambiente Teradata oferece suporte aos itens anteriores e:

• Implementa uma carga de trabalho de BI/Analytics em vez de OLTP (processamento de transações online).

• Tem um modelo de dados que possa ser migrado com modificações mínimas, como um esquema em estrela ou snowflake.

Dica

Crie um inventário de objetos que precisem ser migrados e documente o processo de migração.

O volume de dados migrados em uma migração inicial deve ser grande o suficiente para demonstrar os recursos e benefícios do ambiente Azure Synapse, porém sem excesso, para uma demonstração rápida do seu valor. Um tamanho entre 1 e 10 terabytes é típico.

No seu projeto de migração inicial, minimize o risco, o esforço e o tempo de migração para poder ver rapidamente os benefícios do ambiente de nuvem do Azure, limitando o escopo da migração apenas aos data marts, como a parte OLAP DB de um warehouse do Teradata. As abordagens de migração em fases e lift-and-shift limitam o escopo da migração inicial apenas aos data marts e não abordam aspectos de migração mais amplos, como migração de ETL e de dados históricos. No entanto, você pode abordar esses aspectos em fases posteriores do projeto após a camada de data mart migrada ser novamente preenchida com os dados e processos de compilação necessários.

Migração lift-and-shift versus abordagem em Fases

Em geral, há dois tipos de migração, independentemente da finalidade e do escopo planejado: lift-and-shift sem alterações e uma abordagem em fases que incorpora alterações.

Lift-and-shift

Em uma migração do tipo lift-and-shift, um modelo de dados existente, como um esquema em estrela, é migrado inalterado para a nova plataforma Azure Synapse. Essa abordagem minimiza o risco e o tempo de migração, reduzindo o trabalho necessário para alcançar os benefícios da migração para o ambiente de nuvem do Azure. A migração lift-and-shift é uma boa opção para estes cenários:

• Você tem um ambiente Teradata já existente com um único data mart para migrar ou
• Você tem um ambiente Teradata com dados que já estão em um esquema de estrela ou snowflake bem projetado, ou
• Você está sob pressão de tempo e custo para migrar para um ambiente de nuvem moderno.

Dica

O formato lift-and-shift é um bom ponto de partida, mesmo que as fases subsequentes implementem alterações no modelo de dados.

Abordagem em fases que incorpora alterações

Se um data warehouse herdado estiver em evolução há um longo período, talvez seja necessário refazer sua engenharia para manter os níveis de desempenho necessários. Talvez você também precise refazer a engenharia para oferecer suporte a novos dados, como fluxos de IoT (Internet das Coisas). Como parte do processo de reengenharia, migre para o Azure Synapse para obter os benefícios de um ambiente de nuvem escalonável. A migração pode incluir uma alteração no modelo de dados subjacente, como a mudança de um modelo Inmon para um cofre de dados.

A Microsoft recomenda mover o modelo de dados existente sem alterações para o Azure (opcionalmente usando a instância do Teradata de VM no Azure) e usar o desempenho e a flexibilidade do ambiente do Azure para aplicar as alterações geradas pelo trabalho de reengenharia. Dessa forma, você pode usar os recursos do Azure para fazer as alterações sem afetar o sistema de origem existente.

Usar uma instância do Teradata de VM do Azure durante a migração

Ao migrar de um ambiente Teradata local, você pode aproveitar o armazenamento em nuvem e a escalabilidade elástica no Azure para criar uma instância do Teradata em uma VM. Essa abordagem agrupa a instância do Teradata e o ambiente do Azure Synapse de destino. Com essa abordagem, utilitários padrão do Teradata, como o Teradata Parallel Data Transporter, podem mover com eficiência o subconjunto de tabelas Teradata que estão sendo migradas para a instância da VM. Em seguida, todas as tarefas de migração podem ocorrer no ambiente do Azure. Essa abordagem tem vários benefícios:

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

• Há interfaces, ferramentas e utilitários conhecidos do Teradata disponíveis no ambiente do Azure.

• Após a migração para o ambiente do Azure, não haverá nenhum problema potencial 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 para migrar dados de forma rápida, fácil e eficaz.

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

Dica

Use VMs do Azure para criar uma instância temporária do Teradata a fim de acelerar a migração e minimizar o impacto no sistema de origem.

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

Automatize e orquestre o processo de migração usando os recursos do ambiente do Azure. Essa abordagem minimiza o impacto no ambiente Netezza existente, que talvez já esteja funcionando próximo da capacidade total.

O Azure Data Factory é um serviço de integração de dados baseado em nuvem que permite criar na nuvem fluxos de trabalho controlados por dados que orquestram e automatizam a movimentação e a transformação de dados. Você pode usar o Azure Data Factory para criar e agendar fluxos de trabalho controlados por dados (pipelines) que ingerem dados de diferentes armazenamentos de dados. O Data Factory é capaz de processar e transformar dados usando serviços de computação como o Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e o Azure Machine Learning.

Quando você planeja usar as instalações do Data Factory para gerenciar o processo de migração, crie metadados que listem todas as tabelas de dados a serem migradas e sua localização.

Diferenças de design entre o Teradata e o Azure Synapse

Como mencionado anteriormente, há algumas diferenças básicas na abordagem entre os bancos de dados do Teradata e do Azure Synapse Analytics, que são discutidas em seguida.

Diversos bancos de dados vs. um único banco de dados e esquemas

O ambiente Teradata geralmente contém vários bancos de dados separados. Por exemplo, pode haver bancos de dados separados para: ingestão de dados e tabelas de preparo, tabelas principais do warehouse e data marts (às vezes chamados de camada semântica). Os processos de pipeline ETL ou ELT podem implementar junções entre bancos de dados e mover dados entre os bancos de dados separados.

Por outro lado, o ambiente Azure Synapse contém um único banco de dados e usa esquemas para separar tabelas em grupos separados logicamente. Recomendamos usar uma série de esquemas no banco de dados do Azure Synapse de destino para imitar os bancos de dados separados migrados do ambiente Teradata. Se o ambiente Teradata já usar esquemas, talvez seja necessário empregar uma nova convenção de nomenclatura a fim de mover as tabelas e exibições existentes do Teradata para o novo ambiente. Por exemplo, é possível concatenar o esquema existente do Teradata e os nomes de tabela no novo nome de tabela do Azure Synapse e, em seguida, usar nomes de esquema no novo ambiente para manter os nomes de banco de dados separados originais. Se a nomenclatura de consolidação de esquema tiver pontos, o Azure Synapse Spark poderá ter problemas. Você pode usar exibições SQL sobre as tabelas subjacentes para manter as estruturas lógicas, mas há algumas desvantagens potenciais nessa abordagem:

• As exibições no Azure Synapse são somente leitura, portanto, as atualizações nos dados devem ocorrer nas tabelas base subjacentes.

• Talvez já haja uma ou mais camadas de exibições, e a adição de uma camada extra pode afetar o desempenho e a capacidade de suporte, pois é difícil difíceis de solucionar problemas em exibições aninhadas.

Dica

Combine vários bancos de dados em um único banco de dados no Azure Synapse e use esquemas para separar logicamente as tabelas.

Considerações sobre tabela

Ao migrar tabelas entre ambientes diferentes, normalmente só é possível migrar dados brutos e os metadados que os descrevem. Outros elementos de banco de dados do sistema de origem, como índices, geralmente não são migrados porque podem ser desnecessários ou implementados de forma diferente no novo ambiente. Otimizações de desempenho no ambiente de origem, como índices, indicam onde você pode adicionar otimização de desempenho no novo ambiente. Por exemplo, se uma tabela no ambiente Teradata de origem tiver um NUSI (índice secundário não exclusivo), isso sugerirá que um índice não clusterizado deve ser criado no Azure Synapse. Outras técnicas nativas de otimização de desempenho, como a replicação de tabela, podem ser mais aplicáveis do que uma criação direta de índice por semelhança.

Dica

Índices existentes indicam candidatos à indexação no warehouse migrado.

Alta disponibilidade para banco de dados

O Teradata oferece suporte à replicação de dados entre nós por meio da opção FALLBACK, em que linhas de tabela que residem fisicamente em um determinado nó são replicadas para outro nó no sistema. Essa abordagem garante que os dados não serão perdidos se houver uma falha de nó e fornece a base para cenários de failover.

O objetivo da arquitetura de alta disponibilidade no Azure Synapse Analytics é garantir que seu banco de dados esteja em execução 99,9% do tempo, sem preocupação com o impacto de operações de manutenção e interrupções. Confira mais informações sobre o SLA em SLA do Azure Synapse Analytics. O Azure lida automaticamente com tarefas críticas de manutenção, como patches, backups e atualizações do Windows e do SQL. O Azure também lida automaticamente com eventos não planejados, como falhas no hardware, software ou rede subjacentes.

O armazenamento de dados no Azure Synapse é feito automaticamente com backup de instantâneos. Esses instantâneos são um recurso interno do serviço e criam pontos de restauração. Não é necessário habilitar essa funcionalidade. No momento, usuários individuais não podem excluir pontos de restauração automáticos usados pelo serviço a fim de manter SLAs (contratos de nível de serviço) para recuperação.

O pool de SQL Dedicado do Azure Synapse obtém instantâneos do data warehouse ao longo do dia para criar pontos de restauração que ficam disponíveis por sete dias. Esse período de retenção não pode ser alterado. O Azure Synapse dá suporte a um RPO (objetivo de ponto de recuperação) de oito horas. É possível restaurar seu data warehouse na região primária com base em qualquer um dos instantâneos tirados nos últimos sete dias. Se você precisar de backups mais granulares, pode usar outras opções definidas pelo usuário.

Tipos de tabela do Teradata sem suporte

O Teradata dá suporte a tipos de tabelas especiais para séries temporais e dados temporais. A sintaxe e algumas funções para esses tipos de tabela não têm suporte direto no Azure Synapse. No entanto, você pode migrar os dados para uma tabela padrão no Azure Synapse mapeando para tipos de dados apropriados e indexando ou particionando a coluna data/hora.

Dica

As tabelas Standard no Azure Synapse podem dar suporte a séries temporais e a dados temporais do Teradata migrados.

O Teradata implementa a funcionalidade de consulta temporal usando a reescrita de consulta para adicionar filtros em uma consulta temporal para limitar o intervalo de datas aplicável. Se você planeja migrar essa funcionalidade do ambiente Teradata de origem, adicione a filtragem adicional às consultas temporais relevantes.

O ambiente do Azure oferece suporte a insights de série temporal para análises complexas sobre dados de série temporal em escala. Essa funcionalidade é voltada para aplicativos de análise de dados de IoT.

Diferenças de sintaxe de DML SQL

Há algumas diferenças na sintaxe de DML (Linguagem de Manipulação de Dados) do SQL entre o SQL do Teradata e o T-SQL do Azure Synapse:

• QUALIFY: o Teradata dá suporte ao operador QUALIFY. Por exemplo:

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

  A sintaxe equivalente no 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 campos DATE ou DATETIME. O Teradata dá suporte à subtração direta em datas, como SELECT DATE1 - DATE2 FROM...

• GROUP BY: para o GROUP BY ordinal, forneça explicitamente o nome de uma coluna T-SQL.

• LIKE ANY: o Teradata dá suporte à sintaxe LIKE ANY, 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 sempre diferenciam maiúsculas de minúsculas.

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

Muitas vezes, ao migrar um data warehouse de um ambiente herdado maduro como o Teradata, provavelmente é preciso migrar elementos que não sejam tabelas e exibições simples. Os exemplos incluem funções, procedimentos armazenados e sequências. Verifique se as ferramentas do ambiente do Azure podem substituir a funcionalidade de funções, procedimentos armazenados e sequências, pois geralmente é mais eficaz usar ferramentas internas do Azure do que recodificar esses elementos para o Azure Synapse.

Como parte da fase de preparação, crie um inventário de objetos que precisem ser migrados, defina um método para tratá-los e aloque os recursos corretos no seu plano de migração.

Parceiros de integração de dados oferecem ferramentas e serviços que podem automatizar a migração de funções, procedimentos armazenados e sequências.

As seções a seguir discutem mais profundamente a migração de funções, procedimentos armazenados e sequências.

Funções

Como a maioria dos produtos de banco de dados, o Teradata oferece suporte a funções do sistema e definidas pelo usuário em uma implementação SQL. Quando você migra uma plataforma de banco de dados herdada para o Azure Synapse, as funções comuns do sistema geralmente podem ser migradas sem alterações. Algumas funções do sistema podem ter sintaxes um pouco diferentes, mas todas as alterações necessárias podem ser automatizadas.

No caso de funções do sistema Teradata ou arbitrárias definidas pelo usuário sem equivalente no Azure Synapse, recodifique-as usando uma linguagem de ambiente de destino. O Azure Synapse usa a linguagem Transact-SQL 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. O Teradata oferece a linguagem SPL para essa finalidade. Um procedimento armazenado normalmente contém instruções SQL e lógica de procedimento, retornando dados ou um status.

O Azure Synapse oferece suporte a procedimentos armazenados usando T-SQL, portanto, você precisa recodificar todos os procedimentos armazenados migrados nessa linguagem.

Gatilhos

O Azure Synapse não oferece suporte à criação de gatilho, mas ela pode ser implementada com o Azure Data Factory.

Sequências

O Azure Synapse lida com sequências de maneira semelhante ao Teradata, e você pode implementar sequências usando colunas IDENTITY ou código SQL que gere o próximo número de sequência em uma série. Uma sequência fornece valores numéricos exclusivos que você pode usar como valores de chave alternativa para chaves primárias.

Extrair metadados e dados de um ambiente Teradata

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

O padrão ANSI SQL define a sintaxe básica para comandos DDL (Linguagem de Definição de Dados). Alguns comandos DDL, como CREATE TABLE eCREATE VIEW, são comuns ao Teradata e ao Azure Synapse, mas também fornecem recursos específicos de implementação, como indexação, distribuição de tabelas e opções de particionamento.

Você pode editar scripts Teradata CREATE TABLE e CREATE VIEW existentes para alcançar definições equivalentes no Azure Synapse. Para isso, talvez seja necessário usar tipos de dados modificados e remover ou modificar cláusulas específicas do Teradata, como FALLBACK.

No entanto, todas as informações que especificam as definições atuais de tabelas e exibições no ambiente do Teradata existente são mantidas nas tabelas do catálogo do sistema. Essas tabelas são a melhor fonte dessas informações, pois é garantido que elas estão atualizadas e completas. A documentação mantida pelo usuário pode não estar sincronizada com as definições de tabela atuais.

No ambiente Teradata, as tabelas do catálogo do sistema especificam a tabela e a definição de exibição atuais. Ao contrário da documentação mantida pelo usuário, as informações do catálogo do sistema estão sempre completas e em sincronia com as definições de tabela atuais. Usando exibições no catálogo, comoDBC.ColumnsV, você pode acessar informações do catálogo do sistema para gerar instruções DDL CREATE TABLE que criam tabelas equivalentes no Azure Synapse.

Dica

Use metadados existentes do Teradata para automatizar a geração de DDL CREATE TABLE e CREATE VIEW para o Azure Synapse.

Você também pode usar ferramentas ETL e de migração de terceiros que processem informações de catálogo do sistema para obter resultados semelhantes.

Extração de dados do Teradata

Você pode extrair dados brutos de tabelas Teradata para arquivos delimitados simples, como arquivos CSV, usando utilitários padrão do Teradata, como BTEQ (Basic Teradata Query), Teradata FastExport ou TPT (Teradata Parallel Transporter). Use o TPT para extrair dados de tabela da forma mais eficaz possível. O TPT usa vários fluxos FastExport paralelos para obter a maior taxa de transferência.

Dica

Use o Teradata Parallel Transporter para extrair os dados mais eficazes.

Chame o TPT diretamente no Azure Data Factory. Esta é a abordagem recomendada para a migração de dados de instâncias locais do Teradata e instâncias do Teradata executadas em uma VM no ambiente do Azure.

Os arquivos de dados extraídos devem conter texto delimitado no formato CSV, ORC (Optimized Row Columnar) ou Parquet.

Para obter mais informações sobre o processo de migração de dados e ETL de um ambiente Teradata, consulte Migração de dados, ETL e carregamento para migrações do Teradata.

Recomendações de desempenho para migrações do Teradata

A meta de otimização de desempenho é um desempenho do data warehouse igual ou melhor após a migração para o Azure Synapse.

Dica

Priorize a familiaridade com as opções de ajuste no Azure Synapse no início de uma migração.

Diferenças na abordagem de ajuste de desempenho

Esta seção destaca diferenças de implementação de ajuste de desempenho de nível inferior entre o Teradata e o Azure Synapse.

Opções de distribuição de dados

Em termos de desempenho, o Azure Synapse foi projetado com arquitetura de vários nós e usa processamento paralelo. Para otimizar o desempenho de tabelas individuais no Azure Synapse, você pode definir uma opção de distribuição de dados em instruções CREATE TABLE usando a instrução DISTRIBUTION. Por exemplo, você pode especificar uma tabela distribuída por hash, que distribui linhas de tabela entre nós de computação usando uma função de hash determinística. O objetivo é reduzir a quantidade de dados que devem ser movidos entre nós de processamento na execução de uma consulta.

Para junções de tabelas grandes, o hash distribui uma ou, na forma ideal, ambas as tabelas em uma das colunas de junção, que tem um amplo intervalo de valores para ajudar a garantir uma distribuição uniforme. Execute o processamento de junção localmente, pois as linhas de dados a serem unidas já serão agrupadas no mesmo nó de processamento.

O Azure Synapse também oferece suporte a junções locais entre uma tabela pequena e uma tabela grande por meio de replicação de tabela pequena. Por exemplo, considere uma tabela de dimensões pequena e uma tabela de fatos grande em um modelo de esquema em estrela. O Azure Synapse pode replicar a tabela de dimensões menores em todos os nós para garantir que o valor de qualquer chave de junção para a tabela grande tenha uma linha de dimensão correspondente e disponível localmente. A sobrecarga da replicação da tabela de dimensões é relativamente baixa em uma tabela de pequenas dimensões. Para tabelas de grandes dimensões, uma abordagem de distribuição de hash é mais apropriada. Para obter mais informações sobre opções de distribuição de dados, consulte Orientações sobre design para uso de tabelas replicadas e Orientações sobre a criação de tabelas distribuídas.

Indexação de dados

O Azure Synapse fornece várias opções de indexação definíveis pelo usuário que diferem daquelas implementadas no Teradata. Para obter mais informações sobre as diferentes opções de indexação no Azure Synapse, consulte Índices em tabelas de pool de SQL dedicadas.

Índices existentes no ambiente Teradata de origem podem fornecer indicações úteis de uso de dados e as colunas candidatas à indexação no ambiente do Azure Synapse.

Particionamento de dados

Em um data warehouse corporativo, as tabelas de fatos podem conter bilhões de linhas. O particionamento otimiza a manutenção e a consulta dessas tabelas, dividindo-as em partes separadas para reduzir a quantidade de dados processados. No Azure Synapse, a instrução CREATE TABLE define a especificação de particionamento para uma tabela. Particione apenas tabelas muito grandes e certifique-se de que cada partição contenha pelo menos 60 milhões de linhas.

Só é possível usar um campo por tabela para particionamento. Frequentemente, esse é um campo de datas, pois muitas consultas são filtradas por data ou intervalo de datas. É possível alterar o particionamento de uma tabela após o carregamento inicial, usando a instrução CTAS (CREATE TABLE AS) para recriá-la com uma nova distribuição. Para obter uma descrição detalhada do particionamento no Azure Synapse, consulte Tabelas de particionamento em um pool de SQL dedicado.

Estatísticas da tabela de dados

Verifique se as estatísticas nas tabelas de dados estão atualizadas criando em uma etapa de estatísticas para trabalhos ETL/ELT.

PolyBase ou COPY INTO para carregamento de dados

O PolyBase oferece suporte ao carregamento eficiente de grandes volumes de dados para um data warehouse com o uso de fluxos de carregamento paralelos. Para obter mais informações, consulte a estratégia de carregamento de dados do PolyBase.

COPY INTO também oferece suporte à ingestão de dados de alta taxa de transferência e:

• Recuperação de dados de todos os arquivos em uma pasta e em subpastas.

• Recuperação de dados de vários locais na mesma conta de armazenamento. Você pode especificar vários locais usando caminhos separados por vírgulas.

• ADLS (Azure Data Lake Storage) e Armazenamento de Blobs do Azure.

• Formatos de arquivo CSV, PARQUET e ORC.

Gerenciamento de carga de trabalho

A execução de cargas de trabalho mistas pode representar desafios de recursos em sistemas ocupados. Um esquema de gerenciamento de carga de trabalho bem-sucedido gerencia efetivamente os recursos, garante uma utilização de recursos altamente eficiente e maximiza o ROI (retorno sobre o investimento). A classificação da carga de trabalho, a importância da carga de trabalho e o isolamento da carga de trabalho dão mais controle sobre como a carga de trabalho utiliza os recursos do sistema.

O guia de gerenciamento de carga de trabalho descreve as técnicas para analisar a carga de trabalho, gerenciar e monitorar a importância da carga de trabalho e as etapas para converter uma classe de recurso em um grupo de carga de trabalho. Use o portal do Azure e as consultas T-SQL em DMVs para monitorar a carga de trabalho para garantir que os recursos aplicáveis sejam utilizados com eficiência.

Próximas etapas

Para saber mais sobre ETL e carregamento para migração do Teradata, confira o próximo artigo desta série: Migração de dados, ETL e carregamento para migrações do Teradata.