Azure Synapse: gerir, melhorar ou migrar

Geralmente, não. No Microsoft Learn, a recomendação para quem inicia um novo projeto de data warehousing é começar pelo Fabric Data Warehouse. Se está a começar de raiz, leia sobre a configuração de uma plataforma de dados Azure.

Esta página aborda ambientes Synapse existentes: a sua gestão e melhoria, e a preparação de uma migração no âmbito da plataforma de dados e IA.

Analisa todos os componentes da workspace: dedicated SQL pools, serverless SQL, pipelines e Spark pools com notebooks. Identifica as queries lentas, a origem dos custos e as pipelines que falham com frequência.

Depois, melhora a estrutura das tabelas e os processos de carregamento de dados, configura a monitorização e documenta o que será necessário fazer numa migração.

Muitas vezes, a causa está na estrutura das tabelas. Uma tabela numa dedicated SQL pool está repartida por sessenta distribuições. Na distribuição por hash, uma coluna determina onde fica cada linha. Se muitos dados ficarem concentrados em poucas distribuições, a query terá de esperar pela mais lenta.

A Microsoft recomenda uma coluna com muitos valores únicos e poucos NULLs, e não uma coluna de datas. Não é possível alterar uma coluna de distribuição: é necessário recriar a tabela com CREATE TABLE AS SELECT.

Numa dedicated SQL pool, a capacidade de processamento e o armazenamento são cobrados separadamente. Se colocar a pool em pausa, deixa de pagar pela capacidade de processamento, mas continua a pagar pelo armazenamento. Por isso, se não a utilizar permanentemente, pode colocá-la em pausa fora do horário de utilização.

O serverless SQL não tem capacidade reservada: paga pelos dados processados pelas suas queries. As queries pesadas e repetidas sobre o data lake são o primeiro ponto a analisar.

Para dedicated SQL pools, a Microsoft disponibiliza o Fabric Migration Assistant. Este transfere o esquema através de um ficheiro DACPAC ou de uma ligação direta e ajuda a corrigir os objetos que não são transferidos automaticamente. Os dados são copiados com um copy job; depois, testa e compara o ambiente antigo com o novo.

Segundo a Microsoft, o T-SQL não é totalmente equivalente. Os utilizadores SQL também têm de ser substituídos por utilizadores Microsoft Entra.

Segundo a Microsoft, a migração de Synapse Spark para Fabric passa, em geral, por copiar e adaptar, não por uma migração no próprio local. Existe um Spark Migration Assistant para notebooks, Spark jobs e pools, mas terá de adaptar o código que utiliza funcionalidades e ligações específicas do Synapse.

A migração também inclui os metadados do Hive Metastore, o acesso aos dados e as permissões. Depois, verifica se tudo continua a funcionar da mesma forma.

Sim. É uma opção natural se a sua equipa trabalhar sobretudo com Spark e Python, ou se o machine learning tiver de funcionar sobre os mesmos dados. Nesse caso, transfere os notebooks e os processos de carregamento de dados para o Databricks e volta a configurar o armazenamento e as permissões.

Somos Databricks Partner e Microsoft Partner e comparamos ambas as opções. Leia também sobre a implementação do Databricks.

Não encontrámos uma data de fim na documentação do Microsoft Learn. No entanto, as páginas do Synapse recomendam a quem inicia um novo projeto de data warehousing que comece pelo Fabric Data Warehouse e indicam que as workloads existentes em dedicated SQL pools podem ser atualizadas para o Fabric.

Recomendamos que tome essa decisão com base no seu próprio ambiente, não em rumores. Leia também sobre a implementação do Microsoft Fabric.