Fase 1: Estratégia e planeamento da migração

Este artigo é a Fase 1 de 4 da série de melhores práticas de migração do Azure Synapse Spark para Microsoft Fabric.

Comece por aqui antes de migrar quaisquer blocos de notas, definições de tarefas do Spark, pools ou metadados do lago. Este artigo ajuda-o a avaliar o âmbito do seu ambiente Synapse Spark, a escolher uma abordagem de migração que corresponda à sua tolerância ao risco e ao prazo de entrega, e a compreender as diferenças do Fabric que afetam o planeamento.

No final deste passo, deves saber o que precisa de ser movido, que padrão de migração usar, onde estão os principais riscos de compatibilidade e que restrições de rollback ou execução paralela deves ter em conta.

Neste artigo, você aprenderá a:

Avalie a sua pegada no Synapse Spark.
Escolha entre levantar e deslocar, modernização faseada e corrida paralela.
Tenha em conta as restrições de rollback e sincronização.
Analise as principais características e diferenças de arquitetura entre o Synapse Spark e o Fabric Spark.

Avalie a sua pegada no Synapse Spark

Azure Synapse Analytics abrange vários tipos de carga de trabalho. Este guia foca-se na migração de pools do Spark, cadernos, definições de trabalhos do Spark, bases de dados de lagos e metadados do Hive Metastore para o Microsoft Fabric. Para pool SQL dedicado, pipeline, Data Explorer e orientações de migração de segurança, consulte os guias complementares.

Carga de trabalho Synapse	Fabric Destino	Ferramenta/Caminho de Migração
Spark Pools	Fabric Spark (Lakehouse)	Spark Assistente de Migração (pré-visualização); migração manual do pool/ambiente
Notebooks	Cadernos de tecido	Spark Assistente de Migração; refatoração de código para APIs específicas do Synapse
Definições de trabalhos do Spark	Definições de funções Fabric Spark	Spark Assistente de Migração (recomendado); recreação manual se necessário
Bases de Dados de Lagos	Catálogo Fabric Lakehouse	Spark Assistente de Migração (tabelas Delta através de atalhos); Exportação/importação do HMS para não-Delta
Hive Metastore	Catálogo Fabric Lakehouse	Notebooks de exportação/importação HMS; Atalhos OneLake para dados
Serviços Vinculados	Fabric Connections / Key Vault	Criar Conexões de Fabric; migrar segredos para o Key Vault; refatorar código de notebook

Execute a Ferramenta de Avaliação Fabric

Antes de planear a sua migração, execute a Ferramenta de Avaliação Fabric para gerar um relatório abrangente do seu espaço de trabalho fonte Synapse. A ferramenta analisa o seu espaço de trabalho e agrega um resumo de todos os objetos — pools Spark, cadernos, definições de trabalhos Spark, bases de dados lacustres, serviços ligados e as suas configurações — dando-lhe uma visão clara do âmbito da migração.

Descarregue a ferramenta. A Ferramenta de Avaliação Fabric está disponível no repositório Microsoft fabric-toolbox GitHub em microsoft/fabric-toolbox.
Faz a avaliação. Aponte a ferramenta para o seu espaço de trabalho no Azure Synapse. Varre todos os itens relacionados com o Spark e produz um relatório com contagens de objetos, configurações, dependências e potenciais problemas de compatibilidade.
Analise o relatório. Use o resultado da avaliação para compreender o âmbito da sua migração: quantos notebooks, pools, SJDs e bases de dados precisam de ser migrados, que serviços ligados estão em uso e que potenciais bloqueios existem (pools de GPU, funcionalidades não suportadas e outros).

Tip

Execute a ferramenta de avaliação cedo no seu processo de planeamento. O relatório ajuda-o a estimar o esforço, identificar bloqueios e priorizar quais as cargas de trabalho a migrar primeiro. Também serve como inventário de referência para a Fase 1 da lista de verificação da migração.

Padrões migratórios

Escolha o seu padrão de migração com base nas suas restrições organizacionais, tolerância ao risco e prazos.

Padrão de levantar e deslocar

Migre todas as cargas de trabalho do Spark de uma só vez usando o Assistente de Migração com alterações mínimas. Concentre-se em pôr notebooks e jobs a correr no Fabric o mais rapidamente possível — refatorem apenas o que falha (serviços ligados, caminhos de ficheiros, APIs não suportadas). Aceita a arquitetura atual como está.

Utilize o lift-and-shift quando:

O seu espaço de trabalho Synapse vai ser desativado com prazo fixo e precisa de agir rapidamente.
As tuas cargas de trabalho no Spark já estão bem arquitetadas (Delta-first, código limpo, poucas dependências de serviços ligados).
O seu ambiente de trabalho é gerível para uma migração única e a sua equipa pode lidar com o esforço de refatoração num único ciclo de desenvolvimento.
Os consumidores finais (Power BI, APIs) podem tolerar uma curta janela de transição.

Modernização faseada

Migra as cargas de trabalho incrementalmente por prioridade, reestruturando à medida que avanças. Comece primeiro pelas cargas de trabalho de maior ou menor risco. À medida que migra cada lote, consolida os pools do Spark em menos ambientes, adota as melhores práticas do Lakehouse (Delta-first, V-Order para consumidores de BI), ativa o NEE e redesenha para o Direct Lake.

Use a modernização faseada quando:

Tens um ambiente Synapse grande ou complexo, com várias equipas e cargas de trabalho diversificadas que não podem ser migradas de uma só vez.
A tua arquitetura atual tem dívidas técnicas que queres resolver (formatos não-Delta, dependências de mount-point, vastos pools Spark).
Tens flexibilidade nos prazos e queres melhorar o desempenho e a eficiência de custos durante a migração.
Cargas de trabalho diferentes têm proprietários diferentes e precisam de horários de migração independentes.

Padrão de execução paralela

Executa ambos os ambientes simultaneamente durante a transição. Encaminhar novas cargas de trabalho do Spark para o Fabric, ao mesmo tempo mantendo as cargas de trabalho legadas no Synapse. Valide as cargas de trabalho migradas comparando os resultados lado a lado antes de proceder à transição. Vai descomissionando gradualmente a Synapse à medida que a confiança cresce.

Use uma corrida paralela quando:

As suas cargas de trabalho têm acordos de nível de serviço (SLAs) ou requisitos regulamentares rigorosos que exigem validação extensa antes da transição.
Precisa de provar que o desempenho da Fabric iguala ou supera a Synapse antes de as partes interessadas aprovarem a desativação.
Os seus consumidores a jusante (dashboards, APIs, modelos de ML) não conseguem tolerar qualquer discrepância durante a transição.
Estás a migrar pipelines de produção onde resultados incorretos têm um impacto elevado no negócio (relatórios financeiros, conformidade).

A execução paralela introduz um problema de sincronização de dados que você deve conceber desde o início. Escolha um destes padrões:

Camada de armazenamento partilhada: Ter tanto o Synapse como o Fabric ler e escrever no mesmo armazenamento ADLS Gen2 através de atalhos OneLake. Isto mantém ambas as plataformas nos mesmos ficheiros Delta, mas deve evitar conflitos de escrita garantindo que apenas uma plataforma escreve numa dada tabela de cada vez.
Write-once, read-both: Mantenha o Synapse como escritor principal durante a transição e deixe o Fabric ler os mesmos dados através de atalhos. Depois de validar os cadernos migrados no Fabric, muda o caminho de escrita para o Fabric e faz do Synapse o consumidor em modo de leitura até ser desativado. Esta é a opção mais segura para a maioria das migrações.
Escrita dupla: Evite correr o mesmo ETL em ambos os ambientes ao mesmo tempo, a menos que já tenha ferramentas automáticas de comparação e reconciliação. A escrita dupla tende a criar divergência, duplicação e sobrecarga operacional.

A corrida paralela também afeta a gestão de mudanças. Embora o Synapse continue a ser o ambiente de desenvolvimento ativo, quaisquer alterações feitas num notebook, na definição de trabalhos do Spark, na configuração do pool Spark, ou nos esquemas de base de dados lacustres no Synapse não são refletidas automaticamente no Fabric. Deves migrar novamente os ativos afetados para manter ambos os ambientes alinhados.

Alterações ao código do caderno: Volte a executar o Assistente de Migração do Spark ou reexporte e reimporte manualmente os cadernos atualizados. Reaplique qualquer refatoração de código específica de Fabric, incluindo notebookutils, atualizações dos caminhos dos ficheiros e segredos do Key Vault.
Remigrar através do Assistente de Migração ou recriar manualmente os SJDs atualizados no Fabric.
Alterações na configuração do pool Spark: Atualize o Ambiente Fabric correspondente para coincidir com o tamanho do nó revisto, as definições de autoescala e as bibliotecas.
Alterações no esquema da base de dados do lake: Reexecute os cadernos de exportação/importação do HMS ou crie e altere as tabelas afetadas manualmente no Fabric lakehouse.

Para reduzir a sobrecarga de remigração, estabeleça um congelamento de alterações do lado do Synapse a partir do início da migração. Se as alterações forem inevitáveis, mantém um registo de alterações para poderes repeti-las no Fabric antes do cutover.

Considerações de recuo

A migração do Synapse para o Fabric é uma operação de cópia — não modifica nem elimina o seu espaço de trabalho Synapse de origem. Os seus pools do Spark originais, cadernos e dados permanecem intactos durante todo o processo. Isto torna o processo de rollback descomplicado:

Se os resultados da migração forem insatisfatórios, continue a usar o seu espaço de trabalho Synapse existente. Nenhuma alteração precisa de ser revertida.
Apague os artefactos migrados do Fabric (cadernos, ambientes, definições de trabalhos do Spark) e tente novamente depois de resolver os problemas.
Os atalhos OneLake apontam para o armazenamento ADLS Gen2 existente — remover atalhos não afeta os dados subjacentes.
Não descomissione o seu espaço de trabalho Synapse até que todas as cargas de trabalho migradas sejam validadas no Fabric e os consumidores a jusante sejam redirecionados.

Tip

Começa pequeno e prova a viabilidade rapidamente. Escolha uma carga de trabalho representativa do Spark e migre-a de ponta a ponta — desde a configuração do pool, passando pela refatoração do notebook até à validação. Escolha algo que exerça os seus padrões mais comuns (acesso a dados, serviços ligados, operações de catálogo), mas que seja de baixo risco suficiente para iterar. Documente os passos, problemas encontrados e resoluções para construir um processo repetível para migrações subsequentes.

Paridade de funcionalidades e diferenças chave

Compreender as diferenças arquitetónicas entre a Synapse e a Fabric é fundamental para o planeamento. As tabelas seguintes destacam as principais diferenças na arquitetura computacional e nas capacidades do Spark.

Para a comparação completa, veja Compare Fabric and Azure Synapse Spark: Key Differences.

Computação e arquitetura

Capacidade	Azure Synapse	Microsoft Fabric
Modelo de implantação	PaaS (configurar e gerir recursos)	SaaS (baseado em capacidade, sem gestão de infraestruturas)
Modelo de computação	Piscinas de faísca (baseadas em nós); requer um mínimo de 3 nós	Unidades de Capacidade (CU) partilhadas por todas as cargas de trabalho; pools Spark como modelos de configuração; execução de nó único suportada; faturação Autoscale para Spark (pagar por utilização, semelhante ao modelo Synapse)
Motor de faísca	Piscinas de Spark Synapse (Spark 3.4, 3.5); Piscinas de GPU suportadas	Fabric Spark (Runtime 1.2/1.3/2.0: Spark 3.4–4.0); sem suporte a GPU; funciona em hardware de última geração para melhorar o desempenho
Dimensionamento	Autoescala de nós para Spark (mínimo 3 nós)	Autoescala de nós para Spark (mínimo de um nó); Escala baseada na capacidade
Início da sessão	Baseado em pool; Inicialização a frio para novos clusters	Starter Pools (inicialização em segundos); Pools Personalizados ao Vivo; Modo de Alta Concorrência
Modelo de custos	Por nó-hora (Apache Spark); Pausa/Retomar	Duas opções: (1) Fabric Spark utiliza um modelo de consumo partilhado baseado em Unidade de Capacidade (CU), ou (2) Faturação Autoscale Spark – modo pay as you go

Spark: Synapse Spark vs. Fabric Spark

Capacidade	Synapse Spark	Fabric Spark
Versões Spark	Spark 3.4 (Fim de vida), 3.5 (Pré-visualização).	Spark 3.4 (RT 1.2 EOL), 3.5 (RT 1.3 GA), 4.0 (Pré-visualização RT 2.0)
Aceleração de consultas	Sem motor de aceleração nativo	Motor de Execução Nativa (Velox/Gluten, até 4x de desempenho no TPC-DS)
Modelo de pool	Pools fixos com o número máximo de nós por pool; mínimo 3 nós	Starter Pools (arranque de segundo nível, sem necessidade de configuração); Pools personalizados para tamanhos específicos de nós e bibliotecas personalizadas; Execução de nó único suportada
Segurança (rede)	Rede virtual gerida; Pontos Finais Privados	Endpoints Privados Geridos (MPE); Políticas de Acesso de Saída (OAP); Chaves Geridas pelo Cliente (CMK)
Suporte para GPU	Pools acelerados por GPU disponíveis	Não suportado
Alta simultaneidade	Não suportado	Suportado: vários cadernos partilham uma sessão Spark
Gestão de bibliotecas	Bibliotecas ao nível de pool e do espaço de trabalho; upload manual de pacotes em formato Wheel, JARs, tar.gz	Gestão de bibliotecas baseada no ambiente: feeds públicos (PyPI/Conda) + uploads personalizados (wheels, JARs). Para replicar as bibliotecas ao nível do workspace do Synapse, crie um Ambiente com as bibliotecas necessárias e defina-o como o padrão do workspace. Todos os cadernos e SJDs no espaço de trabalho herdam-no automaticamente.
V-Order	Não disponível	Otimização do Parquet durante a escrita, 40–60% de melhoria para Power BI Direct Lake e ~10% para endpoints de análises SQL, não há benefício de leitura Spark, 15–33% de sobrecarga de escrita
Otimizar Escrita	Desabilitado por padrão	Ativado por padrão
Formato padrão da tabela	Parquet (Delta opcional)	Delta Lake (padrão e necessário para as tabelas Lakehouse)
Hive Metastore	HMS incorporado; HMS externo via SQL do Azure DB ou MySQL (obsoleto após o Spark 3.4)	Catálogo Fabric Lakehouse; migração do HMS via scripts de exportação/importação
DMTS em cadernos	Suportado	Suportado em cadernos; ainda não suportado nas definições de funções da Spark
Identidade gerida para KV	Suportado	Suportado em cadernos e definições de funções no Spark
mssparkutils	Biblioteca completa (fs, credenciais, caderno, ambiente, lakehouse)	notebookutils (API semelhante; algumas diferenças nos nomes dos métodos)

Comentários

Esta página foi útil?

Last updated on 2026-04-28