Migración de PostgreSQL a Databricks: Acortando el camino al Lakehouse
La publicación de hoy marca el lanzamiento de una nueva estructura en nuestro blog: más ágil, concisa y directa al punto.
¿Por qué este cambio? Principalmente porque, en nuestras publicaciones anteriores sobre migraciones, hemos explorado repetidamente temas relacionados con la gestión de proyectos, planificación, estrategias de coexistencia y aspectos similares. Por lo tanto, asumiremos que estos conceptos ya están claros, dado que la única variable real es la tecnología de origen (explora nuestros blogs de migración aquí).
Fuente: SunnyData
En este contexto, hablaremos específicamente sobre la migración de PostgreSQL a Databricks. En comparación con otras alternativas, esta migración es relativamente sencilla, al menos al principio. Por supuesto, esta simplicidad puede verse desafiada cuando el equipo se enfrenta a la tarea de refactorizar 350 procedimientos almacenados, pero ese es precisamente el tipo de detalle técnico que exploraremos hoy.
Introducción a la Dinámica de las Migraciones*
*Siéntete libre de omitir esta sección si ya estás familiarizado con ella
La estructura conceptual de la decomisión sigue un patrón común de cuatro macro fases, que pueden dividirse en etapas secundarias. Sin embargo, para comprender la idea general y la estructura de las migraciones, no entraremos en detalles (ya los hemos cubierto en publicaciones anteriores). Las dos primeras fases están más relacionadas con la plataforma o sistema de origen que se está migrando, mientras que las dos últimas dependen más de la tecnología de destino, en este caso, Databricks.
Fase 1: Análisis
La primera fase, el análisis, se centra en una evaluación exhaustiva de la infraestructura actual, incluyendo datos (tablas, esquemas, número de bases de datos, volumen, etc.), funciones, procedimientos almacenados y dependencias (tanto para la ingesta como para el consumo de datos). Este proceso generalmente comienza en la etapa de preventa y continúa durante la ejecución del proyecto, proporcionando una visión general del alcance y el esfuerzo de la migración. Este ejercicio no es solo una revisión técnica detallada, sino también una evaluación integral desde una perspectiva funcional y de negocio.
Fase 2: Diseño
A esta fase le sigue la fase de diseño, que depende en gran medida de la anterior. Un análisis deficiente conducirá a una fase de diseño defectuosa y a un desastroso inicio del proyecto. En esta etapa, se define la estrategia de migración (Lift & Shift, Modernizar o Refactorizar) para cada componente tecnológico o proceso involucrado. Esta estrategia está determinada por factores críticos como el tiempo disponible para la ejecución, la tecnología de origen (cubriremos un ejemplo concreto en el próximo blog) y un enfoque equilibrado entre los costos actuales y futuros.
Por ejemplo, construir un componente desde cero podría requerir una mayor inversión inicial en servicios profesionales, pero también podría resultar en menores costos operativos y mejor eficiencia a medio y largo plazo.
Fuente: SunnyData
Fase 3: Desarrollo
A continuación viene la fase de desarrollo, cuando nos alejamos de las tecnologías de origen y nos enfocamos más en adaptarnos a la plataforma de destino, en este caso, Databricks.
Durante esta fase, se diseñará el esquema de Unity Catalog en Databricks para alinearse con las necesidades del negocio, y se traducirá el código PostgreSQL para garantizar la compatibilidad con Databricks. Explicaremos e ilustraremos cómo funciona este proceso conceptualmente en la siguiente sección.
Contexto: RDBMS con Procedimientos Almacenados o Lógica Procedimental
Esta sección se aplica al presente post del blog, así como a futuras publicaciones relacionadas con migraciones desde bases de datos relacionales que contienen procedimientos almacenados, lógica procedimental o soporte para PL/SQL (o similar). Esto incluye RDBMS ampliamente utilizados como PostgreSQL, Oracle Database, Microsoft SQL Server, MySQL e IBM DB2.
⚠️ Importante: Databricks admite todos los comandos SQL estándar ANSI. Sin embargo, PostgreSQL, como otros RDBMS, extiende el estándar SQL con funcionalidades específicas que no existen en Databricks. Por ejemplo, la declaración CREATE PROCEDURE no es válida en Databricks. - Actualización: Esto ya no aplica. Ahora es compatible.
Entonces, ¿cómo se pueden replicar estas funcionalidades en Databricks?
El código SQL procedimental de PostgreSQL puede migrarse fácilmente convirtiéndolo en funciones Python alojadas en notebooks. Gracias a Databricks Workflows, es posible replicar la lógica original y automatizar estos procesos, aprovechando completamente las capacidades de programación integrada, escalabilidad y orquestación nativa de la plataforma.
Si bien esto es menos problemático hoy en día —ya que la mayoría de las empresas han adoptado la arquitectura Lakehouse— hubo un tiempo en que surgió confusión en torno a que Databricks no admitía procedimientos almacenados, lo que llevó a algunas empresas a elegir soluciones tradicionales en su lugar. La verdad es que Databricks es incompatible con los procedimientos almacenados tradicionales y requiere refactorización de código, pero el resultado es el mismo. - Actualización: Esto ya no aplica. Ahora es compatible.
Sí, requiere un esfuerzo adicional. Sin embargo, con los avances en IA y aceleradores de conversión de código, incluso si Databricks admitiera procedimientos almacenados de manera tradicional, aún sería más beneficioso refactorizar para capitalizar completamente una plataforma cloud-native.
Técnicamente, ¿Qué Implica la Migración?
El principal desafío es transformar los procedimientos almacenados en funciones Python que se puedan gestionar a través de Databricks Workflows. Si bien existen varios enfoques, nos centraremos en el más sencillo con fines didácticos.
El primer paso es obtener el esquema de la base de datos. Usaremos pg_dump para generar un archivo SQL con todas las definiciones de tablas y procedimientos almacenados. Con este archivo, podemos replicar tablas en Databricks, asegurándonos de ajustar las diferencias entre los tipos de campo de PostgreSQL y Databricks. Dado que Databricks no admite declaraciones CREATE PROCEDURE, necesitaremos reescribir la lógica a Python (usar asistencia de IA puede ahorrar mucho tiempo). - Actualización: Esto ya no aplica. Ahora es compatible.
Aquí tienes un ejemplo:
📌 1. Creando una tabla en Databricks:
Equivalente a PostgreSQL pero adaptado al metastore de Databricks.
Fuente: SunnyData
🐍 2. Convirtiendo un procedimiento almacenado de PostgreSQL a Databricks usando Python:
El procedimiento original en PostgreSQL:
Fuente: SunnyData
👉 Databricks ahora admite SQL Scripting, por lo que tenemos dos opciones de implementación: usar SQL scripting o usar Python para una ejecución más flexible dentro de notebooks.
Ejemplo en Python:
Fuente: SunnyData
Ejecutar función en un notebook: transfer(1, 2, 2000)
Validar el resultado con SQL: SELECT * FROM hive_metastore.default.accounts;
Este proceso te muestra cómo transformar efectivamente tu lógica SQL para la plataforma Databricks usando Python y notebooks. Tu resultado final debería funcionar exactamente como el original, y querrás hacer pruebas exhaustivas para asegurar que el nuevo código Python se comporta de la misma manera que tus procedimientos PostgreSQL originales.
Más Allá de la Conversión de Código: Otros Componentes Clave a Considerar
La migración de PostgreSQL a Databricks no se trata solo de convertir procedimientos almacenados en funciones Python; también requiere reestructurar la capa de orquestación. Esto significa identificar cómo y dónde se activan estos procedimientos y adaptar esos flujos de trabajo dentro de Databricks Workflows u orquestadores externos para garantizar una ejecución sin problemas. Al rediseñar dependencias, disparadores y flujos de ejecución, podemos alinearnos con la arquitectura de Databricks y optimizar los pipelines de procesamiento de datos.
Para la carga de datos, utilizamos técnicas estándar de ETL/ELT, como notebooks Spark que leen archivos CSV, JSON o Parquet, almacenando todo en tablas de Unity Catalog dentro de Databricks. Además, como parte de la fase de validación, es crucial realizar pruebas exhaustivas para asegurar que la nueva implementación basada en Python se comporte exactamente como los procedimientos originales de PostgreSQL. Los aceleradores de calidad de datos en Databricks pueden ayudar a automatizar este proceso de validación, garantizando consistencia y precisión en todos los conjuntos de datos.
Otro paso crítico es redirigir los consumidores de datos a la plataforma migrada. Esto incluye herramientas de BI (por ejemplo, Power BI, Tableau) y pipelines de ML, que deben reconfigurarse para consultar desde el nuevo entorno de Databricks en lugar de PostgreSQL. Garantizar una transición fluida para estos consumidores es esencial para minimizar la interrupción y mantener la continuidad del negocio.
🔥 Actualización (Marzo 2025): Impacto de SQL Scripting en Databricks
La disponibilidad de SQL Scripting en Databricks cambia significativamente el enfoque para migraciones desde RDBMS tradicionales. Anteriormente, Databricks no admitía procedimientos almacenados nativos, requiriendo que la lógica se reescribiera en notebooks.
Con esta actualización, ahora podemos escribir scripts SQL y procedimientos almacenados directamente en Databricks, reduciendo la necesidad de adaptación de código y permitiendo un enfoque de migración más cercano a Lift & Shift.
¿Cómo afecta esto a las migraciones de PostgreSQL?
Menos conversión a Python: Ya no es necesario transformar procedimientos almacenados en funciones Python, simplificando la migración de lógica SQL avanzada.
Ejemplo de SQL Scripting en Databricks (hipotético basado en el mismo ejercicio):
Fuente: SunnyData
Compatibilidad nativa con bases de datos tradicionales: Ahora se pueden escribir scripts SQL completos directamente en Databricks, reduciendo la fricción para equipos acostumbrados a trabajar con PL/pgSQL.
Ejecución optimizada de consultas y procesos ETL/ELT: Se pueden diseñar, programar y ejecutar flujos de trabajo SQL complejos dentro de Databricks, eliminando la necesidad de notebooks.
Mejor gobernanza y auditoría: Al permitir procedimientos almacenados y scripting SQL, facilita la estandarización de consultas y procesos en entornos empresariales.
Reflexión Final: ¿Qué Opción es Mejor?
Ahora que tenemos ambas opciones, ¿cuál es la mejor? En mi opinión, convertir código a Notebooks sigue siendo el enfoque recomendado, ya que proporciona mayor flexibilidad, escalabilidad e integración con los flujos de trabajo de Databricks.
Sin embargo, SQL Scripting es una alternativa valiosa para clientes con una fuerte dependencia de procedimientos almacenados. Permite una transición más suave, reduciendo el esfuerzo de migración y manteniendo la lógica existente cuando las limitaciones de tiempo o la continuidad operativa son prioridades.
En última instancia, la mejor elección depende de las necesidades de la organización, la estrategia técnica y los objetivos a largo plazo.
Fase de Implementación (¿Y Decomisión?)
Antes de lanzarnos completamente, es mejor comenzar con un pequeño grupo piloto de usuarios o un conjunto de datos limitado para validar la migración. Este enfoque ayuda tanto a ti como a tu cliente a reducir el riesgo y la incertidumbre.
El proceso debe seguir un ciclo iterativo:
Migrar un módulo/dominio a la vez, probarlo exhaustivamente y obtener retroalimentación.
Realizar los ajustes necesarios en tu código o configuración.
Repetir hasta que hayas movido completamente todo el código y datos de PostgreSQL a Databricks.
Ahora, ¿qué sucede una vez que todo está migrado y validado?
Es hora de decomisionar o desmantelar la tecnología antigua. Esta fase a menudo se pasa por alto 🤷♂️, lo que lleva a la deuda técnica en muchas organizaciones.
Para maximizar el Retorno de la Inversión (ROI), es esencial:
✔️ Planificar el retiro de los sistemas PostgreSQL heredados.
✔️ Desactivar servidores, bases de datos y conexiones antiguas.
✔️ Redirigir todos los procesos y aplicaciones a Databricks.
Conclusiones
Como hemos mostrado, el traslado de almacenes de datos tradicionales como PostgreSQL a Databricks es bastante sencillo en concepto, pero eso no lo hace simple en la práctica. Muchos clientes empresariales han acumulado años de procedimientos almacenados (a menudo con poca o ninguna documentación) que pueden ser increíblemente complejos, lo que da mucho trabajo a los equipos de ingeniería.
Es por eso que tiene sentido utilizar herramientas de aceleración como BladeBridge o el acelerador personalizado de SunnyData para acelerar y simplificar todo el proceso.