Design e desempenho das migrações netezza

Este artigo é a primeira parte de uma série de sete partes que fornece orientações sobre como migrar do Netezza para o Azure Synapse Analytics. O foco deste artigo são as melhores práticas de design e desempenho.

Descrição Geral

Devido ao fim do suporte da IBM, muitos utilizadores existentes dos sistemas de armazém de dados netezza querem tirar partido das inovações fornecidas pelos ambientes de cloud modernos. Os ambientes de cloud de infraestrutura como serviço (IaaS) e de plataforma como serviço (PaaS) permitem-lhe delegar tarefas como a manutenção da infraestrutura e o desenvolvimento de plataformas ao fornecedor de cloud.

Dica

Mais do que apenas uma base de dados— o ambiente do Azure inclui um conjunto abrangente de capacidades e ferramentas.

Embora o Netezza e o Azure Synapse Analytics sejam bases de dados SQL que utilizam técnicas de processamento paralelo em massa (MPP) para alcançar um elevado desempenho de consultas em volumes de dados excecionalmente grandes, existem algumas diferenças básicas na abordagem:

• Os sistemas Netezza legados são frequentemente instalados no local e utilizam hardware proprietário, enquanto Azure Synapse é baseado na cloud e utiliza recursos de armazenamento e computação do Azure.

• Atualizar uma configuração do Netezza é uma tarefa importante que envolve hardware físico adicional e reconfiguração de bases de dados potencialmente longa ou captura e recarregamento. Uma vez que os recursos de armazenamento e computação são separados no ambiente do Azure e têm capacidade de dimensionamento elástico, esses recursos podem ser dimensionados para cima ou para baixo de forma independente.

• Pode colocar em pausa ou redimensionar Azure Synapse conforme necessário para reduzir a utilização e o custo dos recursos.

O Microsoft Azure é um ambiente de cloud globalmente disponível, altamente seguro e dimensionável que inclui Azure Synapse e um ecossistema de ferramentas e capacidades de suporte. O diagrama seguinte resume o ecossistema Azure Synapse.

Azure Synapse fornece o melhor desempenho da base de dados relacional através de técnicas como mPP e vários níveis de colocação em cache automatizada para dados utilizados frequentemente. Pode ver os resultados destas técnicas em referências independentes, como a executada recentemente pela GigaOm, que compara Azure Synapse com outras ofertas populares do armazém de dados na cloud. Os clientes que migram para o ambiente de Azure Synapse vêem muitas vantagens, incluindo:

• Desempenho e preço/desempenho melhorados.

• Maior agilidade e tempo mais curto para valorizar.

• Implementação de servidor e desenvolvimento de aplicações mais rápido.

• Escalabilidade elástica — pague apenas a utilização real.

• Segurança/conformidade melhoradas.

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

• TCO global mais baixo, melhor controlo de custos e despesas operacionais simplificadas (OPEX).

Para maximizar estes benefícios, migre dados novos ou existentes e aplicações para a plataforma de Azure Synapse. Em muitas organizações, a migração inclui mover um armazém de dados existente de uma plataforma no local legada, como o Netezza, para Azure Synapse. A um nível elevado, o processo de migração inclui estes passos:

    Preparação 🡆

• Definir âmbito — o que deve ser migrado.

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

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

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

• Identifique as ferramentas e funcionalidades adequadas do Azure e de terceiros a utilizar.

• Treinar pessoal no início da nova plataforma.

• Configure a plataforma de destino do Azure.

    Migração 🡆

• Comece de forma pequena e simples.

• Automatize sempre que possível.

• Tire partido das ferramentas e funcionalidades incorporadas do Azure para reduzir o esforço de migração.

• Migrar metadados para tabelas e vistas.

• Migrar dados históricos a serem mantidos.

• Migrar ou refatorizar procedimentos armazenados e processos empresariais.

• Migrar ou refatorizar processos de carregamento incremental ETL/ELT.

    Pós-migração

• Monitorizar e documentar todas as fases do processo.

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

• Reengenheirar o modelo de dados, se necessário (utilizando o desempenho e escalabilidade da nova plataforma).

• Testar aplicações e ferramentas de consulta.

• Referenciar e otimizar o desempenho das consultas.

Este artigo fornece informações gerais e diretrizes para a otimização do desempenho ao migrar um armazém de dados de um ambiente Netezza existente para Azure Synapse. O objetivo da otimização do desempenho é alcançar o mesmo ou melhor desempenho do armazém de dados no Azure Synapse após a migração do esquema.

Considerações de design

Âmbito da migração

Quando estiver a preparar-se para migrar a partir de um ambiente netezza, considere as seguintes opções de migração.

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

Normalmente, os ambientes netezza legados evoluíram ao longo do tempo para abranger várias áreas temáticas e cargas de trabalho mistas. Quando decidir por onde começar um projeto de migração, escolha uma área onde poderá:

• Prove a viabilidade da migração para Azure Synapse ao proporcionar rapidamente os benefícios do novo ambiente.

• Permita que os seus técnicos internos obtenham experiência relevante com os processos e ferramentas que irão utilizar quando migrarem outras áreas.

• Crie um modelo para migrações adicionais específicas para o ambiente netezza de origem e as ferramentas e processos atuais que já estão implementados.

Um bom candidato para uma migração inicial a partir de um ambiente Netezza suporta os itens anteriores e:

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

• Tem um modelo de dados, como um esquema de estrela ou floco de neve, que pode ser migrado com modificações mínimas.

Dica

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

O volume de dados migrados numa migração inicial deve ser suficientemente grande para demonstrar as capacidades e os benefícios do ambiente Azure Synapse, mas não demasiado grande para demonstrar rapidamente o valor. Um tamanho no intervalo de 1 a 10 terabytes é típico.

Para o projeto de migração inicial, minimize o risco, o esforço e o tempo de migração para que possa ver rapidamente os benefícios do ambiente da cloud do Azure. Tanto as abordagens de migração lift-and-shift como de migração faseada limitam o âmbito da migração inicial apenas para os data marts e não abordam aspetos de migração mais amplos, como a migração etl e a migração de dados históricos. No entanto, pode abordar esses aspetos em fases posteriores do projeto assim que a camada do data mart migrada for preenchida novamente com dados e os processos de compilação necessários.

Migração lift-and-shift vs. Abordagem faseada

Em geral, existem dois tipos de migração, independentemente da finalidade e do âmbito da migração planeada: migração lift-and-shift tal como está e uma abordagem faseada que incorpora alterações.

Migração lift-and-shift

Numa migração lift-and-shift, um modelo de dados existente, como um esquema de estrela, é migrado inalterado para a nova plataforma de Azure Synapse. Esta abordagem minimiza o risco e o tempo de migração ao reduzir o trabalho necessário para tirar partido das vantagens de mudar para o ambiente de cloud do Azure. A migração lift-and-shift é uma boa opção para estes cenários:

• Tem um ambiente netezza existente com um único data mart para migrar ou
• Tem um ambiente Netezza existente com dados que já se encontram num esquema de estrela ou floco de neve bem concebido ou
• Está com pouco tempo e pressões de custos para mudar para um ambiente de cloud moderno.

Dica

A migração lift-and-shift é um bom ponto de partida, mesmo que as fases subsequentes implementem alterações ao modelo de dados.

Abordagem faseada que incorpora alterações

Se um armazém de dados legado tiver evoluído durante um longo período de tempo, poderá ter de o voltar a criar para manter os níveis de desempenho necessários. Também poderá ter de voltar a criar engenharia para suportar novos dados, como fluxos de Internet das Coisas (IoT). Como parte do processo de reengenharia, migre para Azure Synapse para obter os benefícios de um ambiente de cloud dimensionável. A migração também pode incluir uma alteração no modelo de dados subjacente, como uma mudança de um modelo do Inmon para um cofre de dados.

A Microsoft recomenda mover o modelo de dados existente tal como está para o Azure e utilizar o desempenho e a flexibilidade do ambiente do Azure para aplicar as alterações de reengenharia. Dessa forma, pode utilizar as capacidades do Azure para fazer as alterações sem afetar o sistema de origem existente.

Utilizar Azure Data Factory para implementar uma migração condicionada por metadados

Pode automatizar e orquestrar o processo de migração com as capacidades do ambiente do Azure. Esta abordagem minimiza o desempenho atingido no ambiente Netezza existente, que pode já estar em execução perto da capacidade.

Azure Data Factory é um serviço de integração de dados baseado na cloud que suporta a criação de fluxos de trabalho baseados em dados na cloud que orquestram e automatizam o movimento de dados e a transformação de dados. Pode utilizar o Data Factory para criar e agendar fluxos de trabalho baseados em dados (pipelines) que ingerem dados de arquivos de dados diferentes. O Data Factory pode processar e transformar dados através de serviços de computação como o Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

Quando estiver a planear utilizar as instalações do Data Factory para gerir o processo de migração, crie metadados que listem todas as tabelas de dados a serem migradas e a respetiva localização.

Diferenças de estrutura entre Netezza e Azure Synapse

Conforme mencionado anteriormente, existem algumas diferenças básicas na abordagem entre as bases de dados netezza e Azure Synapse Analytics e estas diferenças são abordadas a seguir.

Várias bases de dados vs. uma única base de dados e esquemas

O ambiente Netezza contém frequentemente várias bases de dados separadas. Por exemplo, podem existir bases de dados separadas para: ingestão de dados e tabelas de teste, tabelas de armazém de núcleos e data marts (por vezes denominadas camada semântica). Os processos de pipeline ETL ou ELT podem implementar associações entre bases de dados e mover dados entre bases de dados separadas.

Por outro lado, o ambiente de Azure Synapse contém uma base de dados individual e utiliza esquemas para separar tabelas em grupos logicamente separados. Recomendamos que utilize uma série de esquemas na base de dados de destino Azure Synapse para imitar as bases de dados separadas migradas do ambiente netezza. Se o ambiente netezza já utilizar esquemas, poderá ter de utilizar uma nova convenção de nomenclatura quando mover as tabelas e vistas netezza existentes para o novo ambiente. Por exemplo, pode concatenar os nomes de tabela e esquema netezza existentes no novo nome da tabela Azure Synapse e utilizar nomes de esquema no novo ambiente para manter os nomes de bases de dados separados originais. Se a nomenclatura de consolidação de esquemas tiver pontos, Azure Synapse Spark poderá ter problemas. Embora possa utilizar vistas SQL sobre as tabelas subjacentes para manter as estruturas lógicas, existem potenciais desvantagens para essa abordagem:

• As vistas no Azure Synapse são só de leitura, pelo que todas as atualizações aos dados têm de ser realizadas nas tabelas base subjacentes.

• Pode já existir uma ou mais camadas de vistas e adicionar uma camada adicional de vistas pode afetar o desempenho e a capacidade de suporte, uma vez que as vistas aninhadas são difíceis de resolver.

Dica

Combine várias bases de dados numa única base de dados dentro de Azure Synapse e utilize nomes de esquemas para separar logicamente as tabelas.

Considerações sobre tabelas

Quando migra tabelas entre ambientes diferentes, normalmente apenas os dados não processados e os metadados que o descrevem migram fisicamente. Normalmente, outros elementos da base de dados do sistema de origem, como índices, não são migrados porque podem ser desnecessários ou implementados de forma diferente no novo ambiente.

As otimizações de desempenho no ambiente de origem, como índices, indicam onde pode adicionar otimização de desempenho no novo ambiente. Por exemplo, se as consultas no ambiente Netezza de origem utilizarem frequentemente mapas de zona, isso sugere que deve ser criado um índice não agrupado dentro de 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 de índices semelhantes à reta.

Dica

Os índices existentes indicam candidatos para indexação no armazém migrado.

Tipos de objetos de base de dados Netezza não suportados

Muitas vezes, as funcionalidades específicas do Netezza podem ser substituídas por Azure Synapse funcionalidades. No entanto, alguns objetos de base de dados Netezza não são suportados diretamente no Azure Synapse. A seguinte lista de objetos de base de dados Netezza não suportados descreve como pode obter uma funcionalidade equivalente no Azure Synapse.

• Mapas de zona: no Netezza, os mapas de zona são automaticamente criados e mantidos para os seguintes tipos de coluna e são utilizados no momento da consulta para restringir a quantidade de dados a analisar:

  • INTEGER colunas de comprimento de 8 bytes ou menos.
  • Colunas temporais, como DATE, TIMEe TIMESTAMP.
  • CHAR se forem parte de uma vista materializada e mencionadas na ORDER BY cláusula .

  Pode descobrir que colunas têm mapas de zona com o nz_zonemap utilitário , que faz parte do NZ Toolkit. Azure Synapse não inclui mapas de zona, mas pode obter resultados semelhantes com outros tipos de índice definidos pelo utilizador e/ou criação de partições.

• Tabelas base agrupadas (CBT): no Netezza, os CBTs são normalmente utilizados para tabelas de factos, que podem ter milhares de milhões de registos. A análise de uma tabela tão grande requer um tempo de processamento considerável, uma vez que poderá ser necessária uma análise completa da tabela para obter os registos relevantes. Organizar registos em CBTs restritivos permite que a Netezza agrupe registos nas mesmas extensões ou nas proximidades. Este processo também cria mapas de zona que melhoram o desempenho ao reduzir a quantidade de dados que precisam de ser analisados.

  No Azure Synapse, pode obter um efeito semelhante ao criar partições e/ou ao utilizar outros índices.

• Vistas materializadas: o Netezza suporta vistas materializadas e recomenda a utilização de uma ou mais vistas materializadas para tabelas grandes com muitas colunas se apenas algumas colunas forem utilizadas regularmente em consultas. As vistas materializadas são atualizadas automaticamente pelo sistema quando os dados na tabela base são atualizados.

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

Mapeamento do tipo de dados Netezza

A maioria dos tipos de dados netezza tem um equivalente direto no Azure Synapse. A tabela seguinte mostra a abordagem recomendada para mapear tipos de dados netezza para Azure Synapse.

Tipo de Dados Netezza	Tipo de Dados Azure Synapse
BIGINT	BIGINT
VARIAÇÃO BINÁRIA(n)	VARBINARY(n)
BOOLEANO	BIT
BYTEINT	TINYINT
CARATERES VARIÁVEIS(n)	VARCHAR(n)
CARÁTER(n)	CHAR(n)
DATA	DATA(data)
DECIMAL(p;s)	DECIMAL(p;s)
PRECISÃO DUPLA	FLOAT
FLOAT(n)	FLOAT(n)
INTEGER	INT
INTERVALO	Atualmente, os tipos de dados INTERVAL não são suportados diretamente no Azure Synapse, mas podem ser calculados com funções temporais, como DATEDIFF.
DINHEIRO	DINHEIRO
NATIONAL CHARACTER VARYING(n)	NVARCHAR(n)
CARÁTER NACIONAL(n)	NCHAR(n)
NUMERIC(p;s)	NUMERIC(p;s)
REAL	REAL
SMALLINT	SMALLINT
ST_GEOMETRY(n)	Os tipos de dados espaciais, como ST_GEOMETRY não são atualmente suportados no Azure Synapse, mas os dados podem ser armazenados como VARCHAR ou VARBINARY.
HORA	HORA
HORA COM FUSO HORÁRIO	DATETIMEOFFSET
CARIMBO DE DATA/HORA	DATETIME

Dica

Avalie o número e o tipo de tipos de dados não suportados durante a fase de preparação da migração.

Os fornecedores de terceiros oferecem ferramentas e serviços para automatizar a migração, incluindo o mapeamento de tipos de dados. Se uma ferramenta ETL de terceiros já estiver a ser utilizada no ambiente Netezza, utilize essa ferramenta para implementar as transformações de dados necessárias.

Diferenças de sintaxe da DML SQL

Existem diferenças de sintaxe de DML SQL entre o NETezza SQL e Azure Synapse T-SQL. Estas diferenças são abordadas em detalhe em Minimizar problemas do SQL para migrações netezza.

• STRPOS: em Netezza, a STRPOS função devolve a posição de uma subcadeia numa cadeia. A função equivalente no Azure Synapse é CHARINDEX com a ordem dos argumentos invertida. Por exemplo, SELECT STRPOS('abcdef','def')... no Netezza é equivalente a SELECT CHARINDEX('def','abcdef')... em Azure Synapse.

• AGE: O Netezza suporta o AGE operador para dar o intervalo entre dois valores temporais, tais como carimbos de data/hora ou datas, por exemplo: SELECT AGE('23-03-1956','01-01-2019') FROM.... No Azure Synapse, utilize DATEDIFF para obter o intervalo, por exemplo: SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM.... Repare na sequência de representação de datas.

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

Funções, procedimentos armazenados e sequências

Ao migrar um armazém de dados a partir de um ambiente maduro como o Netezza, provavelmente terá de migrar elementos que não sejam tabelas e vistas simples. Verifique se as ferramentas no ambiente do Azure podem substituir a funcionalidade de funções, procedimentos armazenados e sequências, uma vez que normalmente é mais eficiente utilizar ferramentas incorporadas do Azure do que recodificar esses elementos para Azure Synapse.

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

Os 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 secções seguintes abordam ainda mais a migração de funções, procedimentos armazenados e sequências.

Funções

Tal como acontece com a maioria dos produtos de base de dados, o Netezza suporta funções definidas pelo sistema e pelo utilizador numa implementação SQL. Quando migra uma plataforma de base de dados legada para Azure Synapse, as funções comuns do sistema podem normalmente ser migradas sem alterações. Algumas funções do sistema podem ter uma sintaxe ligeiramente diferente, mas quaisquer alterações necessárias podem ser automatizadas.

Para funções do sistema Netezza ou funções arbitrárias definidas pelo utilizador que não têm equivalente em Azure Synapse, recodifigue essas funções com uma linguagem de ambiente de destino. As funções definidas pelo utilizador netezza são codificadas em idiomas nzlua ou C++. Azure Synapse utiliza a linguagem Transact-SQL para implementar funções definidas pelo utilizador.

Procedimentos armazenados

A maioria dos produtos de base de dados modernos suportam o armazenamento de procedimentos na base de dados. O Netezza fornece a linguagem NZPLSQL, baseada em Postgres PL/pgSQL, para este fim. Normalmente, um procedimento armazenado contém instruções SQL e lógica processual e devolve dados ou um estado.

Azure Synapse suporta procedimentos armazenados através do T-SQL, pelo que tem de recodificar os procedimentos armazenados migrados nesse idioma.

Sequências

No Netezza, uma sequência é um objeto de base de dados com o nome criado com CREATE SEQUENCE. Uma sequência fornece valores numéricos exclusivos através do NEXT VALUE FOR método . Pode utilizar os números exclusivos gerados como valores de chave de substituição para chaves primárias.

Azure Synapse não implementa CREATE SEQUENCE, mas pode implementar sequências com colunas IDENTITY ou código SQL que gera o número de sequência seguinte numa série.

Extrair metadados e dados de um ambiente netezza

Geração de Linguagem de Definição de Dados (DDL)

A norma SQL ANSI define a sintaxe básica para comandos DDL (Data Definition Language). Alguns comandos DDL, como CREATE TABLE e CREATE VIEW, são comuns ao Netezza e ao Azure Synapse, mas foram expandidos para fornecer funcionalidades específicas da implementação.

Pode editar netezza CREATE TABLE e CREATE VIEW scripts existentes para obter definições equivalentes no Azure Synapse. Para tal, poderá ter de utilizar tipos de dados modificados e remover ou modificar cláusulas específicas do Netezza, como ORGANIZE ON.

No ambiente Netezza, as tabelas de catálogo do sistema especificam a definição atual da tabela e da vista. Ao contrário da documentação mantida pelo utilizador, as informações do catálogo do sistema estão sempre concluídas e sincronizadas com as definições de tabela atuais. Ao utilizar utilitários como nz_ddl_table, pode aceder às informações do catálogo do sistema para gerar CREATE TABLE instruções DDL que criam tabelas equivalentes em Azure Synapse.

Também pode utilizar ferramentas de migração e ETL de terceiros que processam informações do catálogo do sistema para obter resultados semelhantes.

Extração de dados do Netezza

Pode extrair dados de tabelas não processados de tabelas netezza para ficheiros delimitados simples, como ficheiros CSV, utilizando utilitários Netezza padrão, como nzsql e nzunload, ou através de tabelas externas. Em seguida, pode comprimir os ficheiros delimitados simples com gzip e carregar os ficheiros comprimidos para Armazenamento de Blobs do Azure através do AzCopy ou das ferramentas de transporte de dados do Azure, como o Azure Data Box.

Extraia os dados da tabela da forma mais eficiente possível. Utilize a abordagem de tabelas externas porque é o método de extração mais rápido. Execute vários extratos em paralelo para maximizar o débito de extração de dados. A seguinte instrução SQL efetua um extrato de tabela externo:

CREATE EXTERNAL TABLE '/tmp/export_tab1.csv' USING (DELIM ',') AS SELECT * from <TABLENAME>;

Se estiver disponível largura de banda de rede suficiente, pode extrair dados de um sistema Netezza no local diretamente para tabelas de Azure Synapse ou o Armazenamento de Dados de Blobs do Azure. Para tal, utilize os processos do Data Factory ou a migração de dados de terceiros ou produtos ETL.

Dica

Utilize tabelas externas do Netezza para a extração de dados mais eficiente.

Os ficheiros de dados extraídos devem conter texto delimitado no formato CSV, Colunas de Linha Otimizadas (ORC) ou Parquet.

Para obter mais informações sobre a migração de dados e ETL a partir de um ambiente netezza, veja Migração de dados, ETL e carregamento para migrações netezza.

Recomendações de desempenho para migrações netezza

O objetivo da otimização do desempenho é o mesmo ou melhor desempenho do armazém de dados após a migração para Azure Synapse.

Semelhanças nos conceitos de abordagem de otimização do desempenho

Muitos conceitos de otimização do desempenho para bases de dados Netezza são verdadeiros para bases de dados Azure Synapse. Por exemplo:

• Utilize a distribuição de dados para compilar dados a serem associados ao mesmo nó de processamento.

• Utilize o tipo de dados mais pequeno para uma determinada coluna para poupar espaço de armazenamento e acelerar o processamento de consultas.

• Certifique-se de que as colunas a associar têm o mesmo tipo de dados para otimizar o processamento de associações e reduzir a necessidade de transformações de dados.

• Para ajudar o otimizador a produzir o melhor plano de execução, certifique-se de que as estatísticas estão atualizadas.

• Monitorize o desempenho com as capacidades de base de dados incorporadas para garantir que os recursos estão a ser utilizados de forma eficiente.

Dica

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

Diferenças na abordagem de otimização do desempenho

Esta secção destaca as diferenças de implementação de otimização do desempenho de baixo nível entre o Netezza e o Azure Synapse.

Opções de distribuição de dados

Para o desempenho, Azure Synapse foi concebida com arquitetura de vários nós e utiliza processamento paralelo. Para otimizar o desempenho da tabela, pode definir uma opção de distribuição de dados em CREATE TABLE instruções utilizadas DISTRIBUTION no Azure Synapse e DISTRIBUTE ON no Netezza.

Ao contrário do Netezza, Azure Synapse suporta associações locais entre uma pequena tabela e uma tabela grande através de uma pequena replicação de tabela. Por exemplo, considere uma tabela de dimensão pequena e uma tabela de factos grande dentro de um modelo de esquema de estrela. Azure Synapse pode replicar a tabela de dimensão mais pequena em todos os nós para garantir que o valor de qualquer chave de associação para a tabela grande tem uma linha de dimensão disponível localmente correspondente. A sobrecarga da replicação da tabela de dimensão é relativamente baixa para uma tabela de dimensão pequena. Para tabelas de dimensões grandes, uma abordagem de distribuição hash é mais adequada. Para obter mais informações sobre as opções de distribuição de dados, veja Documentação de orientação para estruturar a utilização de tabelas replicadas e Documentação de Orientação para a conceção de tabelas distribuídas.

Indexação de dados

Azure Synapse suporta várias opções de indexação definíveis pelo utilizador que têm uma operação e utilização diferentes em comparação com os mapas de zona geridos pelo sistema no Netezza. Para obter mais informações sobre as diferentes opções de indexação no Azure Synapse, veja Índices em tabelas de conjuntos de SQL dedicadas.

Os mapas de zona geridas pelo sistema existentes num ambiente netezza de origem fornecem uma indicação útil da utilização de dados e das colunas candidatas para indexação no ambiente Azure Synapse.

Criação de partições de dados

Num armazém de dados empresarial, as tabelas de factos podem conter milhares de milhões de linhas. A criação de partições otimiza o desempenho de manutenção e consulta destas tabelas ao dividi-las em partes separadas para reduzir a quantidade de dados processados. No Azure Synapse, a CREATE TABLE instrução define a especificação de criação de partições para uma tabela.

Só pode utilizar um campo por tabela para a criação de partições. Esse campo é, muitas vezes, um campo de data porque muitas consultas são filtradas por data ou intervalo de datas. É possível alterar a criação de partições de uma tabela após a carga inicial com a CREATE TABLE AS instrução (CTAS) para recriar a tabela com uma nova distribuição. Para uma discussão detalhada sobre a criação de partições no Azure Synapse, veja Criar partições de tabelas no conjunto de SQL dedicado.

Estatísticas da tabela de dados

Deve garantir que as estatísticas nas tabelas de dados estão atualizadas ao criar um passo de estatística para tarefas ETL/ELT.

PolyBase ou COPY INTO para carregamento de dados

O PolyBase suporta o carregamento eficiente de grandes quantidades de dados para um armazém de dados através de fluxos de carregamento paralelos. Para obter mais informações, veja Estratégia de carregamento de dados do PolyBase.

COPY INTO também suporta ingestão de dados de alto débito e:

• Obtenção de dados de todos os ficheiros numa pasta e subpastas.

• Obtenção de dados de várias localizações na mesma conta de armazenamento. Pode especificar várias localizações com caminhos separados por vírgulas.

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

• Formatos de ficheiro CSV, PARQUET e ORC.

Gestão de cargas de trabalho

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

O guia de gestão de cargas de trabalho descreve as técnicas para analisar a carga de trabalho, gerir e monitorizar a importância da carga de trabalho e os passos para converter uma classe de recursos num grupo de cargas de trabalho. Utilize as consultas portal do Azure e T-SQL em DMVs para monitorizar a carga de trabalho para garantir que os recursos aplicáveis são utilizados de forma eficiente.

Passos seguintes

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