Fase 1: Estratégia e planejamento de migração

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

Comece aqui antes de migrar blocos de anotações, definições de trabalho do Spark, pools ou metadados do lago. Este artigo ajuda você a avaliar o escopo do seu ambiente Synapse Spark, selecionar uma estratégia de migração que corresponda à sua tolerância a riscos e ao cronograma de entrega, além de entender as diferenças de estrutura que afetam o planejamento.

Ao final desta etapa, você deve saber o que precisa ser movido, qual padrão de migração usar, onde estão os principais riscos de compatibilidade e quais restrições de reversão ou de execução paralela você precisa considerar.

Neste artigo, você aprenderá como:

  • Avalie a pegada do Synapse Spark.
  • Escolha entre realocação sem alterações, modernização em fases e execução em paralelo.
  • Considere as limitações de reversão e sincronização.
  • Examine as principais diferenças de recursos e arquitetura entre o Synapse Spark e Fabric Spark.

Avalie o impacto do Synapse Spark

Azure Synapse Analytics abrange vários tipos de carga de trabalho. Este guia se concentra na migração de pools do Spark, notebooks, definições de trabalho do Spark, bancos de dados lake e metadados do Metastore do Hive para Microsoft Fabric. Para orientações sobre pool de SQL dedicado, pipeline, Data Explorer e orientações de migração de segurança, consulte os guias complementares disponíveis.

Carga de trabalho do Synapse Destino de Fabric Ferramenta/Caminho de Migração
Spark Pools Fabric Spark (Lakehouse) Spark Assistente de Migração (versão prévia); migração manual de pool/env
Notebooks Blocos de Anotações do Fabric Assistente de Migração do Spark; refatoração de código para APIs específicas do Synapse
Definições de trabalho do Spark definições de trabalho do Fabric Spark Spark Assistente de Migração (recomendado); recreação manual, se necessário
Bancos de Dados do Lago catálogo do Fabric Lakehouse Spark Assistente de Migração (tabelas Delta por meio de atalhos); Exportação/importação do HMS para não-Delta
Hive Metastore catálogo do Fabric Lakehouse Notebooks de exportação/importação do HMS; Atalhos do OneLake para dados
serviços vinculados Conexões do Fabric / Key Vault Criar conexões Fabric; migrar segredos para Key Vault; refatorar código do notebook

Executar a Ferramenta de Avaliação de Fabric

Antes de planejar a migração, execute a Ferramenta de Avaliação de Fabric para gerar um relatório abrangente do workspace de origem do Synapse. A ferramenta examina seu workspace e agrega um resumo de todos os objetos – pools do Spark, notebooks, definições de trabalho do Spark, bancos de dados lake, serviços vinculados e suas configurações – fornecendo uma visão clara do escopo de migração.

  1. Baixe a ferramenta. A Ferramenta de Avaliação de Fabric está disponível no repositório GitHub da caixa de ferramentas Microsoft fabric em microsoft/fabric-toolbox.

  2. Execute a avaliação. Aponte a ferramenta para o espaço de trabalho do Azure Synapse. Ele examina todos os itens relacionados ao Spark e produz um relatório com contagens de objetos, configurações, dependências e possíveis problemas de compatibilidade.

  3. Examine o relatório. Use a saída da avaliação para entender o escopo da migração: quantos notebooks, pools, SJDs e bancos de dados precisam ser migrados, quais serviços vinculados estão em uso e quais potenciais bloqueadores existem (pools de GPU, recursos sem suporte e outros).

Dica

Execute a ferramenta de avaliação no início do processo de planejamento. O relatório ajuda você a estimar o esforço, identificar bloqueadores e priorizar quais cargas de trabalho migrar primeiro. Ele também serve como o inventário de linha de base para a Fase 1 da lista de verificação de migração.

Padrões de migração

Escolha seu padrão de migração com base em suas restrições organizacionais, tolerância a riscos e linha do tempo.

Padrão de levantamento e transferência (lift-and-shift)

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 colocar notebooks e processos em execução no Fabric o mais rápido possível — refatore apenas o que falhar (serviços vinculados, caminhos de arquivo, APIs sem suporte). Aceite a arquitetura atual as-is.

Use lift-and-shift quando:

  • Seu espaço de trabalho Synapse está sendo desativado em um prazo fixo e você precisa agir rapidamente.
  • Suas cargas de trabalho do Spark já estão bem arquitetas (delta-first, código limpo, poucas dependências de serviço vinculadas).
  • Seu ambiente de trabalho é gerenciável para uma migração única, e sua equipe pode lidar com o esforço de refatoração em um único sprint.
  • Os consumidores downstream (Power BI, APIs) podem tolerar uma breve janela de substituição.

Modernização em fases

Migre cargas de trabalho de forma incremental e prioritária, re-arquitetando conforme necessário. Comece com as cargas de trabalho de maior valor ou de menor risco primeiro. À medida que você migra cada lote, consolide pools do Spark em menos ambientes, adote as práticas recomendadas do Lakehouse (Delta-first, V-Order para consumidores de BI), habilite o NEE e redesenhe para o Direct Lake.

Use a modernização em fases quando:

  • Você tem um ambiente Synapse grande ou complexo com várias equipes e cargas de trabalho diversas que não podem ser migradas de uma só vez.
  • Sua arquitetura atual tem uma dívida técnica que você deseja resolver (formatos não Delta, dependências de ponto de montagem, pools do Spark em expansão).
  • Você tem flexibilidade na linha do tempo e deseja melhorar o desempenho e a eficiência de custo durante a migração.
  • Cargas de trabalho diferentes têm proprietários diferentes e precisam de agendas de migração independentes.

Padrão de execução paralela

Execute ambos os ambientes simultaneamente durante a transição. Encaminhe novas cargas de trabalho do Spark para Fabric enquanto as cargas de trabalho herdadas continuam no Synapse. Valide as cargas de trabalho migradas comparando os resultados lado a lado antes de realizar a transição. Desativar gradualmente o Synapse à medida que a confiança aumenta.

Use uma execução paralela quando:

  • Suas cargas de trabalho têm SLAs estritas ou requisitos regulatórios que exigem validação estendida antes da transição.
  • Você precisa provar que o desempenho do Fabric atende ou excede o Synapse antes que as partes interessadas aprovem a desativação.
  • Seus consumidores downstream (dashboards, APIs, modelos de ML) não podem tolerar nenhuma discrepância durante a transição.
  • Você está migrando linhas de produção em que os resultados incorretos têm alto impacto comercial (relatórios financeiros, conformidade).

A execução paralela apresenta um problema de sincronização de dados que você deve criar antecipadamente. Escolha um destes padrões:

  • Camada de armazenamento compartilhada: permitir que Synapse e Fabric leiam e escrevam no mesmo armazenamento do ADLS Gen2 por meio de atalhos do OneLake. Isso mantém ambas as plataformas nos mesmos arquivos Delta, mas você deve evitar conflitos de gravação garantindo que apenas uma plataforma grave em uma determinada tabela de cada vez.
  • Write-once, read-both: Mantenha o Synapse como o escritor principal durante a transição e permita que o Fabric leia os mesmos dados por meio de atalhos de leitura de dados. Depois de validar os notebooks migrados no Fabric, alterne o caminho de gravação para o Fabric e defina o Synapse como consumidor de somente leitura até o descomissionamento. Essa é a opção mais segura para a maioria das migrações.
  • Gravação dupla: Evite executar o mesmo ETL em ambos os ambientes ao mesmo tempo, a menos que você já tenha ferramentas automatizadas de comparação e reconciliação. A gravação dupla tende a criar divergência, duplicação e sobrecarga operacional.

A execução paralela também afeta o gerenciamento de alterações. Embora o Synapse continue sendo o ambiente de desenvolvimento ativo, qualquer notebook, definição de trabalho do Spark, configuração do pool do Spark ou alterações de esquema de banco de dados lake feitas no Synapse não são refletidas automaticamente em Fabric. Você deve migrar novamente os ativos afetados para manter os dois ambientes alinhados.

  • Notebook code changes: Executar novamente o spark Assistente de Migração ou re-exportar e importar manualmente os notebooks atualizados. Reaplicar qualquer refatoração de código específica do Fabric, incluindo notebookutils, atualizações de caminho de arquivo e segredos do Cofre de Chaves.
  • Alterações na definição de trabalho do Spark: Remigre através do Assistente de Migração ou recrie manualmente as novas definições de trabalho (SJDs) no Fabric.
  • Alterações na configuração do pool do Spark: Atualize o Fabric Environment correspondente ao tamanho de nó revisado, configurações de escalonamento automático e bibliotecas.
  • Alterações de esquema de banco de dados Lake: executar novamente os blocos de anotações de exportação/importação do HMS ou criar ou alterar manualmente as tabelas afetadas no lakehouse do Fabric.

Para reduzir a sobrecarga de re-migração, estabeleça um congelamento de alterações do lado do Synapse assim que a migração começar. Se as alterações forem inevitáveis, mantenha um log de alterações para que você possa executá-las novamente no Fabric antes da transição.

Considerações sobre reversão

A migração do Synapse para Fabric é uma operação de cópia. Ela não modifica nem exclui o workspace do Synapse de origem. Seus pools, notebooks e dados originais do Spark permanecem intactos durante todo o processo. Isso torna a reversão simples:

  • Se os resultados da migração forem insatisfatórios, continue usando o workspace do Synapse existente. Nenhuma alteração precisa ser revertida.
  • Exclua os artefatos de Fabric migrados (notebooks, ambientes, definições de trabalho do Spark) e tente novamente após resolver problemas.
  • Os atalhos do OneLake apontam para o armazenamento existente do ADLS Gen2 — a remoção de atalhos não afeta os dados originais.
  • Não desative o espaço de trabalho do Synapse até que todas as cargas de trabalho migradas sejam validadas em Fabric e os consumidores downstream sejam redirecionados.

Dica

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

Paridade de funcionalidades e principais diferenças

Entender as diferenças arquitetônicas entre o Synapse e o Fabric é fundamental para o planejamento. As tabelas a seguir destacam as principais diferenças na arquitetura de computação e nos recursos do Spark.

Para obter a comparação completa, consulte Compare Fabric e Azure Synapse Spark: Principais diferenças.

Computação e arquitetura

Capacidade Azure Synapse Microsoft Fabric
Modelo de implantação PaaS (configurar e gerenciar recursos) SaaS (baseado em capacidade, sem gerenciamento de infraestrutura)
Modelo de computação Pools Spark baseados em nós; requer no mínimo 3 nós Unidades de capacidade (CU) compartilhadas em todas as cargas de trabalho; Pools do Spark como modelos de configuração; Execução em nó único é suportada; Cobrança de dimensionamento automático para Spark (modelo de pagamento por uso, semelhante ao modelo do Synapse)
Mecanismo spark Pools do Spark do Synapse (Spark 3.4, 3.5); Pools de GPU com suporte Fabric Spark (Runtime 1.2/1.3/2.0: Spark 3.4–4.0); sem suporte à GPU; é executado no hardware de última geração para melhorar o desempenho
Dimensionamento Dimensionamento automático de nós para Spark (mínimo de 3 nós) Escalonamento automático de nós para Spark (mínimo de um único nó); escalonamento baseado em capacidade
Inicialização da sessão Baseado em pool; inicialização a frio para novos clusters Pools iniciais (inicialização em segundos); Pools ativos personalizados; Modo de alta simultaneidade
Modelo de custo Por hora de nó (Spark); pausar/retomar Duas opções: (1) Fabric Spark usa um modelo de consumo compartilhado baseado em Unidade de Capacidade (CU) ou (2) Cobrança de Dimensionamento Automático para Spark – pague conforme o uso do modo Spark

Spark: Synapse Spark vs. Fabric Spark

Capacidade Synapse Spark Fabric Spark
Versões do Spark Spark 3.4 (EOL), 3.5 (versão prévia). Spark 3.4 (RT 1.2 EOL), 3.5 (RT 1.3 GA), 4.0 (RT 2.0 Preview)
Aceleração de consulta Nenhum mecanismo de aceleração nativo Mecanismo de Execução Nativa (Velox/Gluten, até 4x em TPC-DS)
Modelo de pool Pools fixos com contagem máxima de nós por pool; mínimo de 3 nós Pools de Inicialização (início em segundos, nenhuma configuração necessária); Pools personalizados para tamanhos de nó específicos e bibliotecas personalizadas; Execução de nó único suportada
Segurança (rede) Rede virtual gerenciada; Pontos de extremidade privados MPE (pontos de extremidade privados gerenciados); OAP (Políticas de Acesso de Saída); CMK (Chaves Gerenciadas pelo Cliente)
Suporte à GPU Pools acelerados por GPU disponíveis Sem suporte
Alta simultaneidade Sem suporte Com suporte: vários blocos de anotações compartilham uma sessão do Spark
Gerenciamento de biblioteca Bibliotecas no nível do pool e no nível do workspace; carregamento manual de rodas, JARs, tar.gz Gerenciamento de bibliotecas com base no ambiente: feeds públicos (PyPI/Conda) + uploads personalizados (wheels, JARs). Para replicar bibliotecas no 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 notebooks e SJDs na área de trabalho os herdam automaticamente.
V-Order Não disponível Otimização Parquet no momento da gravação; melhoria de 40 a 60% para Power BI Direct Lake e ~10% para endpoint de análise SQL; e sem benefício de leitura para Spark; sobrecarga de gravação de 15 a 33%
Otimizar gravação Desabilitadas por padrão Habilitada por padrão
Formato de tabela padrão Parquet (opcional Delta) Delta Lake (padrão e necessário para tabelas Lakehouse)
Hive Metastore HMS interno; HMS externo por meio de SQL do Azure DB ou MySQL (preterido após o Spark 3.4) Catálogo do Fabric Lakehouse; Migração do HMS com scripts de exportação/importação
DMTS em notebooks Suportado Com suporte em notebooks; ainda não há suporte nas definições de trabalho do Spark
Identidade Gerenciada para KV Suportado Com suporte em notebooks e definições de trabalho do Spark
mssparkutils Biblioteca de software completa (fs, credenciais, notebook, env, lakehouse) notebookutils (API semelhante; algumas diferenças nos nomes de método)

Conteúdo relacionado

  • Last updated on