Cómo elegir entre Lakehouse, Spark Declarative Pipelines o PySpark, y cuándo combinarlos
por Rafael Aielo
Su equipo tiene cientos de procedimientos almacenados, un par de planificadores, permisos dispersos en diferentes roles y esquemas, y se acerca la fecha límite de renovación de su almacén de datos en la nube. Nadie se pone de acuerdo sobre qué migrar primero. Algunos quieren reescribirlo todo en PySpark. Otros quieren migrar el SQL tal cual y darlo por terminado. Lo que se pierde en la conversación: los metadatos, el linaje y los permisos que se mueven con el código, además de la oportunidad de consolidarlos en el camino.
Ninguno de los dos extremos funciona. Los equipos que logran migrar con éxito su almacén de datos analizan cada carga de trabajo de forma individual y eligen la herramienta adecuada para cada tarea. Este artículo propone un marco de decisión para la selección: cuándo usar Lakehouse (Databricks SQL), Spark Declarative Pipelines o PySpark, y cómo organizar el trabajo por fases para entregar resultados en lugar de quedarse estancados en la planificación.
En Databricks, puede migrar pipelines de ETL de tres formas principales, que a menudo se utilizan de manera conjunta.
Este es el camino más directo para los equipos que utilizan mucho SQL. Cubre un espectro que va desde lo simple hasta lo complejo. Se ejecuta en SQL warehouses, que están acelerados por Photon de forma predeterminada y son totalmente compatibles con ANSI y Spark SQL (%sql). Elija Serverless para cargas de trabajo variables o impredecibles (inicio rápido, escalado a cero, pago por segundo). Elija Classic para cargas de trabajo estables o cuando necesite controles de red o de costos específicos.
Una tarea de SQL sencilla:
Cuando la lógica requiere control de flujo (condicionales), bucles, variables, control de errores o ejecución basada en parámetros, los procedimientos almacenados ofrecen esa capa procedimental. Se gestionan a través de Unity Catalog y se pueden llamar desde Workflows con parámetros.
La regla general: si su código heredado es una única sentencia SQL, mígrelo como una tarea de SQL. Si tiene lógica procedimental (variables, bucles, parámetros, control de errores), considérelo dentro de un procedimiento almacenado, gestionado por Unity Catalog y al que se pueda llamar desde Workflows. No envuelva un SQL simple en un procedimiento solo porque el sistema original lo requería.
Que forma parte de Lakeflow, adopta un enfoque diferente. Usted declara lo que debe producir su pipeline y el motor se encarga del orden de ejecución, los reintentos y el escalado. Obtiene restricciones de calidad de datos integradas, resolución automática de dependencias y procesamiento por lotes y streaming unificados en la misma definición.
Bajo el capó, Enzyme decide cuándo realizar actualizaciones incrementales en lugar de recalcular por completo las tablas derivadas. El escalado automático (autoscaling) ajusta la capacidad a los cambios en el volumen de datos sin necesidad de realizar ajustes manuales. Empresas como Block se apoyan en este modelo declarativo para simplificar la orquestación de pipelines a medida que crece el uso.
Que le ofrecen un control total. Se ejecutan en clusters de trabajo (job clusters) y gestionan las cargas de trabajo que no se adaptan a un SQL Warehouse o a un pipeline declarativo.
Recurra a PySpark cuando la carga de trabajo requiera una lógica de negocio compleja, ingeniería de características de ML, integraciones de API o validación personalizada. El siguiente ejemplo evalúa transacciones con un modelo registrado en Unity Catalog:
Recurra a Spark SQL en un notebook cuando el lenguaje siga siendo SQL pero la carga de trabajo pueda superar la capacidad de un SQL Warehouse: tablas muy grandes, shuffles pesados, procesos ETL por lotes de larga duración donde desee un control explícito sobre la partición, los broadcast joins o el almacenamiento en caché (caching).
Habilite Photon en el cluster de trabajo para tareas de SQL o DataFrame limitadas por el cómputo: uniones (joins) grandes, agregaciones, funciones de ventana (window functions), escaneos en tablas columnares de gran tamaño. Photon es un motor nativo y vectorizado que acelera estos patrones sin necesidad de cambiar el código, incluidos los Pandas UDFs (basados en Arrow). Evite usar Photon cuando predominen los Python UDFs por filas, los conjuntos de datos sean pequeños o el trabajo sea puramente de I/O.
Los notebooks también se adaptan bien a los pipelines híbridos: ingesta en SDP, enriquecimiento en una tarea de notebook.
La siguiente tabla es un punto de partida para las conversaciones del equipo, no una regla estricta.
| Criterios | Lakehouse (tareas y procedimientos almacenados) | Spark Declarative Pipelines | Notebooks de PySpark + Spark SQL |
|---|---|---|---|
| Perfil del equipo | Especialistas en SQL, DBAs, ingenieros de DW | Ingenieros de datos y equipos de SQL que crean pipelines gestionados | Desarrolladores de Python/Spark, ingenieros de ML |
| Tipo de lógica | ETL de SQL: tareas sencillas para sentencias únicas, procedimientos almacenados para lógica procedimental | Pipelines declarativos, CDC, SCD | Lógica compleja, UDFs personalizados, preparación de ML |
| Velocidad de migración de SQL | Alta para cargas de trabajo de tipo SQL ANSI | Media: rediseño de pipelines, pero con reutilización de SQL | Variable: puede requerir una refactorización significativa |
| Orquestación de pipelines | Workflows con tareas de SQL o procedimiento CALL | Integrada en los pipelines | Workflows con tareas de notebook |
| Lotes (batch) frente a streaming | Principalmente por lotes (batch) | Lotes y streaming unificados | Lotes y streaming a través de Structured Streaming |
| Calidad de datos | Comprobaciones manuales de SQL | Restricciones declarativas | Validación personalizada en el código |
Busque a su equipo en la columna y la complejidad de su carga de trabajo en la fila. La celda puede sugerirle por dónde empezar.
| Complejidad de la carga de trabajo | Equipo centrado en SQL | Equipo híbrido | Equipo centrado en código |
|---|---|---|---|
| Baja (cargas por lotes, agregaciones, MERGE) | Tareas de SQL en Workflows | Tareas de SQL o SDP | PySpark o SDP |
| Media (pipelines de varios pasos, CDC, calidad de datos) | Procedimientos almacenados o SDP | SDP | SDP o PySpark |
| Alta (preparación de ML, UDFs personalizados, APIs, lógica de negocio densa) | SDP + asistencia de PySpark | PySpark + SDP para la ingesta | PySpark |
En lugar de decidir "qué enfoque aplicar para todo", decida "qué hacer a continuación" en cada fase.
Fase 1 — Evaluar. Recopile métricas de su data warehouse heredado: tiempo de CPU, tiempo de ejecución, frecuencia, y tablas de origen y destino. Clasifique las cargas de trabajo por complejidad. Utilice herramientas de migración, cuando sea posible, para crear un inventario clasificado por valor frente a dificultad. Dónde encontrar estos datos depende del origen. En Teradata, consulte DBC.QryLog. En SQL Server, use sys.dm_exec_query_stats. En Oracle, informes AWR. En Snowflake, QUERY_HISTORY. Los detalles específicos pueden variar. Si cuenta con una herramienta de integración, puede aprovechar sus metadatos para identificar relaciones entre tablas, o confiar en un LLM para ayudar a construir este linaje. El resultado es un mapa, no un plan de reescritura. El objetivo sigue siendo el mismo: clasificar las cargas de trabajo por consumo de recursos y nivel de dependencia para saber por dónde empezar. Si se hace bien, esta evaluación lleva días utilizando herramientas de migración, no semanas de scripting manual.
Fase 2 — Victorias rápidas. Elija cargas de trabajo que combinen un bajo riesgo de migración con casos de uso de alta visibilidad empresarial. Eso podría significar comenzar con tareas de SQL pesadas que sean fáciles de convertir, o con pipelines de informes que pongan la nueva plataforma frente a las partes interesadas desde el principio. Las sentencias simples se convertirán en tareas de SQL en Workflows. La lógica procedimental se convierte en procedimientos almacenados. Utilice transpiladores y conversión asistida por IA para la traducción inicial. Ejecute ambos sistemas en paralelo y compare recuentos de filas, sumas de comprobación (checksums) y registros de muestra. El objetivo es generar confianza, tanto técnica como organizativa.
Walgreens, por ejemplo, retiró Teradata local en una migración por fases y ahora procesa alrededor de 40,000 eventos de datos por segundo en el lakehouse, impulsando la optimización de la cadena de suministro en casi 9,000 tiendas.
Fase 3 — Modernizar. Ahora rediseñe los pipelines que valga la pena modernizar. Candidatos: flujos donde las restricciones de calidad de datos y el linaje reducen las comprobaciones manuales, trabajos por lotes que se benefician de tablas de streaming y CDC, pipelines donde las vistas materializadas reducen la complejidad, y los metadatos, permisos y auditorías que antes residían en herramientas independientes, ahora consolidados bajo Unity Catalog. Un patrón común es mantener el procedimiento heredado como respaldo mientras el nuevo pipeline se ejecuta en paralelo hasta que supera la validación. Los pipelines modernizados a menudo reducen las ventanas de procesamiento por lotes de horas a minutos y eliminan la necesidad de herramientas de DQ independientes.
Fase 4 — Optimizar. Consolide los pipelines de ETL redundantes que solo existían para eludir las limitaciones del antiguo DW. Mueva los puntos críticos complejos a PySpark cuando simplifique la lógica. Vuelva a analizar los límites entre procesamiento por lotes y streaming ahora que dispone de un motor unificado. Aquí es donde la migración da sus frutos: la plataforma heredada está apagada, los pipelines redundantes han desaparecido y la arquitectura se ejecuta en un solo sistema en lugar de dos.
Las herramientas de migración automatizan el trabajo mecánico, pero no reemplazan las decisiones de arquitectura. Tres roles típicos:
Un enfoque pragmático: deje que las herramientas cubran entre el 60% y el 80% de la conversión inicial y reserve el tiempo de los ingenieros para los patrones que realmente desea modernizar. Esto evita una migración directa de la deuda técnica.
Las migraciones exitosas retiran activamente los sistemas, no solo convierten el código: servidores de programación independientes, frameworks de DQ personalizados, herramientas independientes de metadatos y linaje, compiladores de procedimientos almacenados específicos del proveedor y entornos de validación personalizados. La migración no termina hasta que esos sistemas se apagan y dejan de llegar las facturas.
Si el ETL de SQL sigue fragmentado en diferentes motores, capas y herramientas, la plataforma seguirá fragmentada, incluso si los datos se encuentran en formatos abiertos.
No existe una única forma correcta de migrar pipelines de datos. Lakehouse le ayuda a lograrlo rápidamente: tareas sencillas para una lógica simple, procedimientos almacenados cuando necesita control procedimental. SDP le ofrece pipelines de ETL modernos con calidad y linaje integrados. Los Notebooks se encargan del resto, ya sea que recurra a PySpark o Spark SQL. Divida el trabajo en fases, comience con victorias rápidas y utilice todos los aceleradores que pueda.
Explore la Guía de migración de Databricks para obtener tutoriales técnicos, o pruébelo usted mismo con la edición gratuita de Databricks.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.