Fase 1: Estrategia de migración y planeación

Este artículo es la Fase 1 de 4 de la serie de procedimientos recomendados para la migración de Azure Synapse Spark a Microsoft Fabric.

Comience aquí antes de migrar los cuadernos, las definiciones de trabajos de Spark, los grupos o los metadatos de lago. Este artículo le ayuda a evaluar el ámbito de su infraestructura de Synapse Spark, elegir un enfoque de migración que coincida con su tolerancia al riesgo y el plazo de entrega, y comprender las diferencias de Fabric que afectan a la planificación.

Al final de este paso, debe saber qué debe mover, qué patrón de migración se va a usar, dónde se encuentran los principales riesgos de compatibilidad y qué restricciones de reversión o ejecución en paralelo debe tener en cuenta.

En este artículo aprenderá a:

• Evalúe la huella de Spark de Synapse.
• Elija entre lift-and-shift, modernización por fases y ejecución paralela.
• Tenga en cuenta las restricciones de reversión y sincronización.
• Revise las principales diferencias de características y arquitecturas entre Synapse Spark y Fabric Spark.

Evaluar la huella de Synapse Spark

Azure Synapse Analytics abarca varios tipos de carga de trabajo. Esta guía se centra en la migración de grupos de Spark, cuadernos, definiciones de trabajos de Spark, bases de datos del lago de datos y metadatos del Hive Metastore a Microsoft Fabric. Para instrucciones de migración relativas a grupo SQL dedicado, canalizaciones, Data Explorer y seguridad, consulte las guías complementarias.

Ejecución de la herramienta de evaluación de Fabric

Antes de planear la migración, ejecute la herramienta de evaluación de Fabric para generar un informe completo del área de trabajo de origen de Synapse. La herramienta examina el área de trabajo y agrega un resumen de todos los objetos ( grupos de Spark, cuadernos, definiciones de trabajos de Spark, bases de datos de lago, servicios vinculados y sus configuraciones), lo que le proporciona una imagen clara del ámbito de migración.

1. Descargue la herramienta. La herramienta de evaluación de Fabric está disponible en el repositorio GitHub del cuadro de herramientas de Microsoft fabric en microsoft/fabric-toolbox.

2. Ejecute la evaluación. Dirija la herramienta hacia el área de trabajo de Azure Synapse. Examina todos los elementos relacionados con Spark y genera un informe con recuentos de objetos, configuraciones, dependencias y posibles problemas de compatibilidad.

3. Revise el informe. Use la salida de evaluación para comprender el ámbito de la migración: cuántos cuadernos, grupos, SJD y bases de datos deben migrarse, qué servicios vinculados están en uso y qué posibles bloqueadores existen (grupos de GPU, características no admitidas y otros).

Patrones de migración

Elija el patrón de migración en función de las restricciones de la organización, la tolerancia al riesgo y la escala de tiempo.

Patrón de migración tal cual

Migre todas las cargas de trabajo de Spark a la vez mediante el Migration Assistant con cambios mínimos. Céntrese en hacer que los cuadernos y trabajos se ejecuten en Fabric lo más rápido posible; refactorice solo lo que se rompa (servicios vinculados, rutas de acceso de archivos, API no admitidas). Acepte la arquitectura actual tal cual.

Utiliza lift-and-shift cuando:

• El área de trabajo de Synapse se va a retirar en una fecha límite fija y debe actuar rápidamente.
• Las cargas de trabajo de Spark ya están bien diseñadas (código delta-first, limpio, pocas dependencias de servicio vinculadas).
• El alcance del área de trabajo es manejable para una migración única y el equipo puede abordar el esfuerzo de refactorización en un solo sprint.
• Los consumidores descendentes (Power BI, APIs) pueden tolerar una breve ventana de conmutación.

Modernización por fases

Migre las cargas de trabajo de forma incremental por prioridad, rediseñando a medida que avanza. Comience primero con las cargas de trabajo de mayor valor o riesgo más bajo. A medida que migre cada lote, consolide los grupos de Spark en menos entornos, adopte las mejores prácticas de Lakehouse (Delta-first, V-Order para consumidores de BI), habilite el NEE y rediseñe para Direct Lake.

Use la modernización por fases cuando:

• Tiene un entorno de Synapse grande o complejo con varios equipos y cargas de trabajo diversas que no se pueden migrar de un solo golpe.
• La arquitectura actual tiene deuda técnica que desea abordar (formatos no delta, dependencias de punto de montaje, grupos de Spark en expansión).
• Tiene flexibilidad en la escala de tiempo y quiere mejorar el rendimiento y la eficiencia de los costos durante la migración.
• Las diferentes cargas de trabajo tienen propietarios diferentes y necesitan programaciones de migración independientes.

Patrón de ejecución en paralelo

Ejecute ambos entornos simultáneamente durante la transición. Enrute las nuevas cargas de trabajo de Spark a Fabric mientras las cargas de trabajo heredadas continúan en Synapse. Valide las cargas de trabajo que han sido migradas comparando directamente los resultados antes de completar la transición. Retirar gradualmente Synapse a medida que aumenta la confianza.

Use una ejecución paralela cuando:

• Si sus flujos de trabajo tienen estrictos acuerdos de nivel de servicio o requisitos normativos que exigen una validación extendida antes del cambio.
• Debe demostrar que el rendimiento de Fabric cumple o supera al de Synapse antes de que las partes interesadas aprueben el desmantelamiento.
• Los consumidores de nivel inferior (paneles, API, modelos de ML) no pueden tolerar ninguna discrepancia durante la transición.
• Está migrando canalizaciones de producción en las que los resultados incorrectos tienen un gran impacto empresarial (informes financieros, cumplimiento).

La ejecución en paralelo presenta un problema de sincronización de datos que debe diseñar por adelantado. Elija uno de estos patrones:

• Capa de almacenamiento compartido: Tanto Synapse como Fabric deben leer y escribir en el mismo almacenamiento de ADLS Gen2 mediante los accesos directos de OneLake. Esto mantiene ambas plataformas en los mismos archivos Delta, pero debe evitar conflictos de escritura asegurándose de que solo una plataforma escribe en una tabla determinada a la vez.
• Write-once, read-both: Mantener Synapse como escritor principal durante la transición y permitir que Fabric lea los mismos datos a través de accesos directos. Después de validar los cuadernos migrados en Fabric, cambie la ruta de escritura a Fabric y configure Synapse como consumidor de solo lectura hasta su desmantelamiento. Esta es la opción más segura para la mayoría de las migraciones.
• Escritura doble: Evite ejecutar el mismo ETL en ambos entornos al mismo tiempo, a menos que ya tenga herramientas de comparación y conciliación automatizadas. La doble escritura tiende a crear divergencias, duplicaciones y sobrecarga operativa.

La ejecución en paralelo también afecta a la administración de cambios. Aunque Synapse sigue siendo el entorno de desarrollo activo, cualquier notebook, definición de trabajos Spark, configuración del pool de Spark o cambios de esquema de base de datos lake realizados en Synapse no se reflejan automáticamente en Fabric. Debe volver a migrar los recursos afectados para mantener ambos entornos alineados.

• Cambios en el código deNotebook: Vuelva a ejecutar el Migration Assistant de Spark o vuelva a exportar manualmente y vuelva a importar los cuadernos actualizados. Vuelva a aplicar cualquier refactorización de código específica de Fabric, incluidas notebookutils, actualizaciones de ruta de archivo y secretos de Key Vault.
• Cambios en la definición del trabajo de Spark: Vuelva a migrar a través del Asistente de Migración o vuelva a crear manualmente las Definiciones de Trabajo de Spark (SJD) actualizadas en Fabric.
• Cambios de configuración del grupo de Spark: Actualice el entorno de Fabric correspondiente para que coincida con el tamaño de nodo revisado, la configuración de escalado automático y las bibliotecas.
• Cambios en el esquema de la base de datos del lago: Vuelva a ejecutar los cuadernos de exportación/importación de HMS, o cree o altere manualmente las tablas afectadas en el almacén de datos de Fabric.

Para reducir la sobrecarga de la remigración, establezca una congelación de cambios en el lado de Synapse una vez iniciada la migración. Si los cambios son inevitables, lleve un registro de cambios para poder reproducirlos en Fabric antes del cambio.

Consideraciones de reversión

La migración de Synapse a Fabric es una operación de copia; no modifica ni elimina el área de trabajo de Synapse de origen. Los grupos, cuadernos y datos originales de Spark siguen intactos durante todo el proceso. Esto hace que la reversión sea sencilla:

• Si los resultados de la migración no son satisfactorios, siga usando el área de trabajo de Synapse existente. No es necesario revertir ningún cambio.
• Elimine los artefactos de Fabric migrados (cuadernos, entornos, definiciones de trabajo de Spark) y vuelva a intentarlo después de solucionar problemas.
• Los accesos directos de OneLake apuntan al almacenamiento de ADLS Gen2 existente: la eliminación de accesos directos no afecta a los datos subyacentes.
• No desactive el área de trabajo de Synapse hasta que todas las cargas de trabajo migradas sean validadas en Fabric y los consumidores a lo largo del flujo sean redirigidos.

Diferencias clave y paridad de características

Comprender las diferencias arquitectónicas entre Synapse y Fabric es fundamental para la planeación. En las tablas siguientes se resaltan las diferencias clave en la arquitectura de proceso y las funcionalidades de Spark.

Para obtener la comparación completa, consulte Compare Fabric y Azure Synapse Spark: Diferencias clave.

Proceso y arquitectura

Spark: Synapse Spark frente a Fabric Spark

Contenido relacionado

• Fase 1: Estrategia de migración y planeación
• Fase 2: migración de cargas de trabajo de Spark
• Fase 3: Metastore de Hive y migración de datos
• Fase 4: Migración de seguridad y gobernanza