Cómo abordar una migración de Synapse a Databricks

Azure Synapse ha servido como una base confiable para la analítica SQL a escala, y los equipos que la adoptaron tomaron una decisión sensata en su momento. Sin embargo, una plataforma diseñada principalmente en torno a un almacén de datos no está preparada para toda la gama de soluciones que hoy se espera que entreguen los equipos de datos. Cubrir esas brechas suele implicar la adición de más servicios, integraciones y sobrecarga operativa, lo que se acumula con el tiempo.

Migrar a Databricks es una forma de abordar este problema. En este blog explicamos cómo abordar la migración de Synapse y qué tener en cuenta al ejecutarla.

Lo que desbloquea una migración de Synapse

En los proyectos de migración de Synapse que vemos con nuestros clientes, surgen constantemente tres impulsores de negocio:

1. Entorno de datos unificado. A medida que las plataformas de datos crecen, el número de servicios involucrados también aumenta. Por ejemplo, los pools de Synapse Analytics manejan un conjunto de cargas de trabajo, los pools de Spark manejan otro y el SQL serverless proporciona acceso ad hoc. Azure Data Factory a menudo los acompaña para orquestarlo todo. Muchas organizaciones también tienen cargas de trabajo heredadas de SSIS que aún deben recibir soporte. Ninguno de estos componentes es problemático de forma aislada. Sin embargo, el desafío surge cuando se introducen servicios adicionales, ya que esto añade otra capa de gobernanza, monitoreo, gestión de permisos y sobrecarga operativa.
   Databricks aborda este problema al unificar la ingeniería de datos, la analítica, el aprendizaje automático y la gobernanza en una sola plataforma. En lugar de moverse entre servicios con diferentes modelos operativos, los equipos pueden trabajar con la misma arquitectura y marco de gobernanza subyacentes. El resultado es una menor complejidad, menos puntos de integración y una plataforma que es más fácil de operar a escala.
2. Preparación para el futuro. El enfoque de los equipos de datos modernos se ha desplazado hacia el soporte de modelos de aprendizaje automático, pipelines de datos en tiempo real y aplicaciones impulsadas por IA. Todas estas cargas de trabajo dependen de los mismos datos subyacentes. El desafío es que las arquitecturas tradicionales, centradas en almacenes de datos, no fueron diseñadas para este nivel de convergencia y se dirigían principalmente a necesidades de BI. A medida que los requisitos se expanden, las organizaciones a menudo se ven obligadas a añadir más servicios y herramientas especializadas para cubrir las brechas de capacidad.
   Databricks está diseñado para esta convergencia, unificando datos, analítica e IA en una sola plataforma. Con Unity Catalog proporcionando una gobernanza consistente en datos, notebooks y activos de IA/ML, y Unity AI Gateway extendiendo esos controles a modelos, agentes y aplicaciones de IA, las organizaciones pueden adoptar nuevas cargas de trabajo de IA sin añadir nuevos silos de gobernanza.
3. Eficiencia operativa. Aunque la mayoría de los casos de negocio de migración comienzan con los costos de licencia, rara vez es de ahí de donde provienen los mayores ahorros. El mayor impacto suele provenir de reducir la cantidad de sistemas que los equipos deben operar y soportar. Menos servicios significan menos integraciones, menos transferencias entre herramientas y menos problemas potenciales.

Las organizaciones que ya han dado el paso están viendo resultados tangibles. Por ejemplo, Casey's, la tercera cadena de tiendas de conveniencia más grande de los Estados Unidos, migró su entorno analítico de Synapse a Databricks Lakehouse (anteriormente Databricks SQL), reduciendo los tiempos de entrega de datos operativos de ocho horas a cuatro. Como otro ejemplo, Italgas simplificó su arquitectura al eliminar tanto Synapse como Azure Analysis Services. La empresa reportó una reducción del 73% en los costos de las cargas de trabajo al tiempo que ofrece tanto Power BI como analítica impulsada por IA directamente desde Databricks.

Aunque los detalles varían de una organización a otra, el patrón sigue siendo el mismo: arquitecturas más simples, entrega de datos más rápida y una plataforma mejor alineada con las exigencias de los equipos de datos modernos.

Entender qué está migrando realmente

Algo que a menudo toma por sorpresa a los equipos al principio de una migración de Synapse es el alcance de lo que están moviendo. Aunque Azure Synapse suele considerarse una única plataforma, en la práctica comprende una variedad de servicios distintos que operan bajo una misma marca, cada uno de los cuales puede requerir diferentes estrategias de migración y tiene un nivel de complejidad diferente.

La mayoría de las migraciones dedican la mayor parte de su esfuerzo a los Dedicated SQL Pools, donde la lógica de negocio, los procedimientos almacenados, las estrategias de distribución, las decisiones de indexación y las optimizaciones de rendimiento se han acumulado a lo largo de los años. Pero la complejidad rara vez se detiene en el SQL. La misma migración suele tener que dar cuenta de la orquestación (Azure Data Factory y Synapse Pipelines), los permisos y la gobernanza (permisos de SQL más Microsoft Purview, con el linaje a menudo unido de forma manual), y la conectividad de BI y de terceros (modelos semánticos, informes y herramientas descendentes conectadas directamente a los endpoints de Synapse). Esta es la parte del entorno que exige un mayor rediseño, pruebas y validación, y la que tiene más probabilidades de ser subestimada.

Los Serverless SQL Pools son generalmente más simples, porque proporcionan principalmente una capa de consulta sobre archivos en un lago de datos. La migración aquí consiste principalmente en restablecer vistas, tablas externas y patrones de acceso, en lugar de rediseñar cargas de trabajo complejas. Los Spark Pools son el componente más sencillo de mover, ya que Synapse Spark y Databricks están construidos sobre Apache Spark y los notebooks a menudo se pueden migrar con relativamente pocos cambios.

El punto importante es que estos componentes se mueven a diferentes velocidades, involucran a diferentes partes interesadas y presentan diferentes riesgos. Las organizaciones que abordan la migración como un único flujo de trabajo con un único cronograma a menudo subestiman tanto el esfuerzo como la complejidad. Ahí es donde los plazos comienzan a retrasarse y los programas de migración comienzan a expandirse más allá de su alcance original. Para migrar con éxito, los equipos deben estructurar el proceso de migración.

Cómo estructurar la migración

Una migración de Synapse a Databricks no es un único flujo de trabajo. Está moviendo tres modelos de cómputo diferentes, consolidando la gobernanza, modernizando la orquestación y reelaborando años de lógica T-SQL acumulada. Los equipos que manejan esto bien lo tratan como un programa estructurado en lugar de un proyecto técnico con un enfoque por fases.

Descubrimiento. Toda migración comienza con entender qué se está ejecutando realmente. Lakebridge Profiler escanea el entorno de Synapse y recopila metadatos sobre la configuración, la utilización de recursos, los patrones de consulta y las líneas base de rendimiento. El resultado se utiliza para construir un caso de TCO.

Evaluación. Una vez que se dispone del inventario, el siguiente paso es comprender la complejidad. Lakebridge Analyzer evalúa la base de código T-SQL, clasificando cada objeto por complejidad, señalando las estructuras no admitidas y mapeando las dependencias. El resultado se puede utilizar para evaluar el cronograma de migración y los esfuerzos asociados, así como para definir la prioridad de las migraciones de activos. Comience con las cargas de trabajo de complejidad baja y media como objetivos fáciles de alcanzar, y planifique el esfuerzo posterior para los casos de uso más críticos.

Diseño. Con visibilidad sobre el entorno, la atención se desplaza hacia la arquitectura y el diseño. Lo primero es el enfoque: lift-and-shift, modernización o híbrido. Para la mayoría de las migraciones de Synapse, el enfoque híbrido es la respuesta correcta. Las herramientas automatizadas se encargan de la mayor parte de la conversión de código para salir de Synapse según lo programado, mientras que la modernización se realiza de forma incremental una vez que las cargas de trabajo se ejecutan en Databricks.

La segunda decisión es la secuenciación. Un enfoque centrado en BI tiende a generar impulso más rápido que comenzar con ETL. Usando Lakehouse Federation, puede exponer los datos de Synapse a través de Unity Catalog antes de que las pipelines subyacentes se hayan movido; y una forma práctica de comenzar es alojar primero los datos aumentados orientados al negocio (sus data marts) en Databricks, y luego ponerlos directamente a disposición de los usuarios de negocio con Genie para analítica en lenguaje natural. Las partes interesadas del negocio ven el progreso y el valor de manera temprana, mientras que los equipos de ingeniería modernizan la ETL subyacente más compleja. Lea nuestra publicación de blog para definir el enfoque de migración adecuado para usted.

Piloto. Antes de escalar, la estrategia de migración debe validarse de extremo a extremo con una carga de trabajo real. Elija un caso de uso piloto, mígrelo desde la ingesta hasta el consumo y páselo a producción. Un piloto valida la arquitectura, el modelo de gobernanza, los procedimientos de prueba y las herramientas frente a condiciones del mundo real, y produce activos reutilizables para las siguientes fases.

Migración en fases. Para la fase de escalado, se recomienda la migración en fases. Cada fase está diseñada para ofrecer una victoria empresarial visible y establece el bucle de retroalimentación con los usuarios finales.

La ejecución normalmente se realiza en cuatro flujos de trabajo paralelos: ingesta (trasladar las cargas de trabajo de ADF y Synapse Pipeline a Lakeflow Connect), transformación (migrar los procedimientos T-SQL y la lógica de negocio a Databricks), orquestación (mover las programaciones y dependencias a Databricks Workflows) y consumo (redireccionar las herramientas de BI y los modelos semánticos a Databricks SQL Warehouses). Ejecutarlos en paralelo permite a los equipos aportar valor de forma temprana y retirar Synapse en un plazo predecible.

Databricks admite las migraciones de Synapse desde múltiples perspectivas: asesoramiento y entrega por parte de nuestro equipo de Forward Deployed Engineering, socios certificados de Brickbuilder y aceleradores como Lakebridge que automatizan el trabajo pesado. El objetivo no es solo completar la migración, sino desarrollar las habilidades y el modelo operativo que el equipo necesita para mantener la plataforma mucho después de que finalice el proyecto.

Ingesta de datos

Antes de convertir el código SQL, primero se deben ingerir los datos en el lakehouse. Databricks ofrece varias opciones según los sistemas de origen y los requisitos operativos.

Para muchas fuentes empresariales comunes, Lakeflow Connect ofrece una experiencia de ingesta gestionada con conectores integrados y gestión automatizada de canalizaciones. Al mismo tiempo, Databricks se basa en formatos de almacenamiento abiertos, lo que permite a las organizaciones utilizar una amplia gama de herramientas de ingesta de terceros. Soluciones como Fivetran, Airbyte y otras plataformas ETL/ELT pueden ingerir datos directamente en Delta Lake, lo que permite a los clientes integrarse con los ecosistemas de integración de datos existentes en lugar de estar vinculados a un único marco de ingesta.

Conversión de código en la práctica

Con los datos disponibles en el lakehouse, el esfuerzo de migración se traslada a la conversión de código, que suele ser la fase más compleja de la migración. Aunque las herramientas automatizadas se encargan de la mayor parte de la traducción, normalmente entre el 80 y el 90 %, el esfuerzo restante se dedica a perfeccionar la lógica procedimental y a resolver patrones que no se pueden traducir automáticamente.

A continuación, se indican algunas diferencias que se deben tener en cuenta en la sintaxis de Synapse y Databricks.

Eliminación de directivas físicas

El patrón de conversión más común es la eliminación de directivas de optimización física. Los Dedicated SQL Pools dependen en gran medida de construcciones como la distribución HASH, la distribución ROUND_ROBIN, la distribución REPLICATE y los índices de almacén de columnas agrupados. Estos son fundamentales para el ajuste del rendimiento de Synapse, pero no tienen un equivalente directo en Databricks, por lo que normalmente se omiten durante la migración.

En su lugar, Databricks se basa en la optimización del almacenamiento y en Liquid Clustering para mejorar el rendimiento de las consultas. Lo primero se gestiona automáticamente a través de Predictive Optimization, que realiza continuamente operaciones de mantenimiento como la compactación de archivos, la recopilación de estadísticas y VACUUM para las tablas Delta. Lo segundo lo proporciona Liquid Clustering, que organiza los datos dentro de las tablas Delta utilizando una o más columnas de agrupación para mejorar el rendimiento de las consultas. Sin embargo, la selección de las columnas de agrupación óptimas depende de la comprensión de cómo se consultan los datos, una tarea que a menudo resulta difícil en la práctica y que cambia con frecuencia a medida que evolucionan las cargas de trabajo. Para reducir esta carga operativa, Databricks introdujo CLUSTER BY AUTO, que identifica automáticamente y perfecciona continuamente las columnas de agrupación en función de los patrones de acceso a las consultas observados. Juntas, estas capacidades reducen significativamente la cantidad de ajuste físico manual requerido en comparación con los Dedicated SQL Pools.

Las decisiones de diseño físico que consumían un esfuerzo de ingeniería significativo en Synapse simplemente se descartan. La plataforma se encarga de lo que antes era manual.

Reasignación de funciones

La mayoría de las funciones de T-SQL de uso común tienen equivalentes directos en Databricks, y Lakebridge se encarga de la gran mayoría de las asignaciones de forma automática.

La fuente de problemas más común no son las asignaciones de funciones en sí, sino las diferencias de comportamiento que afectan a los resultados de formas sutiles. La comparación de cadenas es un buen ejemplo. Los Dedicated SQL Pools de Synapse suelen funcionar con intercalaciones que no distinguen entre mayúsculas y minúsculas, mientras que Databricks SQL distingue entre mayúsculas y minúsculas por defecto. La lógica que depende implícitamente de la coincidencia que no distingue entre mayúsculas y minúsculas puede devolver resultados diferentes después de la migración. Cuando sea necesario, las comparaciones deben hacerse explícitas utilizando LOWER() o UPPER() en ambos lados. La conversión de sintaxis suele ser sencilla; las diferencias semánticas requieren más cuidado.

Procedimientos almacenados: migrar primero, optimizar después

Con el soporte nativo para procedimientos almacenados en Databricks, la mayoría de los procedimientos de Synapse se pueden migrar con su estructura general intacta. Se admiten parámetros, variables, lógica condicional y operaciones DML.

El procedimiento en sí rara vez es el problema. La complejidad reside en su interior: cursores, procesamiento fila por fila, SQL dinámico y optimizaciones de rendimiento específicas de Synapse. Esos patrones requieren criterio, no solo traducción.

SCD Tipo 2: preservar el historial con Delta Lake

Las dimensiones de variación lenta son una de las áreas donde las implementaciones de Synapse varían más. Muchas organizaciones han acumulado procedimientos almacenados personalizados y lógica de fusión a lo largo de los años. El objetivo de la migración no es reproducir exactamente esa implementación, sino preservar el requisito empresarial: mantener las versiones históricas de los registros de dimensiones y, al mismo tiempo, permitir la consulta del estado actual.

Un enfoque común de Databricks consta de dos pasos. Primero, caducar los registros que han cambiado. Luego, insertar las nuevas versiones.

Las transacciones ACID de Delta Lake hacen que este patrón sea seguro incluso cuando intervienen múltiples operaciones.

Control de errores

Muchos procedimientos almacenados de Synapse dependen de bloques TRY...CATCH para capturar fallos o escribir registros de auditoría. Databricks SQL proporciona equivalentes nativos a través de controladores de condiciones, por lo que la mayoría de los patrones existentes pueden seguir basándose en SQL.

Los escenarios sencillos, como el registro de auditoría y los fallos controlados, normalmente se traducen directamente. Los flujos de trabajo más complejos pueden requerir un diseño adicional, especialmente cuando interviene la coordinación descendente a través de Databricks Workflows.

Lo que nos enseña la experiencia de campo

Algunas lecciones surgen de manera constante en las migraciones de Synapse, independientemente del tamaño de la organización o de la complejidad de la infraestructura.

Comience con la evaluación, no con la conversión. Ejecute Lakebridge Profiler y Analyzer antes de escribir una sola línea de código convertido. Tenga claro el uso real, el alcance, la complejidad y las dependencias, y use esos datos para reducir el alcance donde sea posible.

Automatice decididamente. Lakebridge gestiona del 80 al 90 % de la conversión de código. Concentre el tiempo de ingeniería en el 10 o 20 % restante que requiere el criterio humano: cursores, SQL dinámico y gestión de errores compleja.

Nunca subestime la validación. En la práctica, la validación suele consumir más esfuerzo que la propia migración. El enfoque más eficaz consiste en realizar una conciliación después de cada ola de migración, comparando el recuento de filas, las agregaciones, las comparaciones de registros basadas en hash y las comprobaciones basadas en la tolerancia para valores en los que no es adecuada una igualdad exacta. Lakebridge Reconcile admite esto en todas estas dimensiones. Para las cargas de trabajo críticas para el negocio, ejecutar ambos entornos en paralelo antes de la transición final permite a los equipos comparar los resultados en paralelo mientras los usuarios siguen trabajando con los informes habituales.

Evite pensar con la mentalidad de Synapse. Un buen ejemplo es el diseño de tablas. Los equipos suelen intentar asignar las claves de distribución HASH de Synapse directamente a las columnas de partición de Delta Lake. En la mayoría de los casos, esto introduce una complejidad innecesaria y un rendimiento deficiente. Los valores de alta cardinalidad, como los ID de cliente o de pedido, rara vez son claves de partición adecuadas y, a menudo, se gestionan mejor mediante liquid clustering y las capacidades de optimización automatizadas de Databricks, como el mantenimiento predictivo.

No vuelva a crear lo que la plataforma ya gestiona. Las migraciones ofrecen la oportunidad de simplificar las arquitecturas en lugar de reproducirlas exactamente. Delta Lake, la optimización automatizada y los patrones modernos de lakehouse eliminan muchas de las técnicas de ajuste manual que eran necesarias en los entornos de almacenamiento de datos tradicionales. Trasladar cada decisión histórica de optimización a Databricks a menudo conserva las antiguas limitaciones sin conservar las razones por las que existían.

Prepare la preparación operativa. Las tablas Delta acumulan de forma natural archivos pequeños a medida que se ejecutan cargas de trabajo incrementales a lo largo del tiempo. Sin procesos de compactación y mantenimiento, el rendimiento puede degradarse gradualmente. A los equipos que provienen de plataformas tradicionales de almacenamiento de datos a menudo les sorprende que la optimización del almacenamiento pase a formar parte del modelo operativo continuo. No es difícil de gestionar, pero debe planificarse desde el principio.

Planifique la gestión del cambio. La mayoría de los equipos de Synapse son nuevos en Databricks, y la falta de inversión en capacitación es una de las razones más comunes por las que los proyectos no alcanzan los objetivos de adopción. Trabaje en el plan de capacitación con la misma seriedad que en el plan técnico.

Evite el desmantelamiento prematuro de Synapse. La mayoría de las migraciones exitosas mantienen disponible el entorno heredado durante un período después de haber trasladado las cargas de trabajo de producción. El cómputo se puede pausar para minimizar los costos, al tiempo que se conserva una opción de reversión si surgen problemas inesperados. Lo que es más importante, mantener esa red de seguridad brinda confianza a las partes interesadas del negocio mientras la nueva plataforma demuestra su eficacia en condiciones de uso reales.

Migrar de Synapse a Databricks rara vez es solo un proyecto tecnológico. En el fondo, implica simplificar una plataforma que se ha vuelto cada vez más compleja con el tiempo, al tiempo que se establecen las bases para dar soporte a la próxima generación de productos de análisis, AI y datos. Aunque el trabajo técnico es importante, las organizaciones que más se benefician de estas migraciones son aquellas que aprovechan la oportunidad para simplificar su arquitectura, eliminar la complejidad innecesaria y modernizar sus prácticas operativas de forma simultánea. El mayor beneficio es acabar con una plataforma de datos que es más sencilla de operar, más fácil de ampliar y que está mejor alineada con la dirección futura de la organización.

Qué hacer a continuación

Si se encuentra al inicio de una migración de Synapse:

• Ejecute Lakebridge Profiler y Analyzer en su entorno. Obtenga los datos antes de definir el alcance del trabajo.
• Lea el blog Estrategia de migración: lecciones aprendidas y el libro electrónico Transformación de almacenes de datos heredados.
• Si desea ayuda práctica, el equipo de FDE de Databricks y los socios de migración certificados ofrecen migraciones de Synapse de extremo a extremo.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original