Queries en Milisegundos en Databricks Lakehouse: Del OLAP al OLTP
Tengo un millón de transacciones en mi archivo Delta y quiero procesar una en milisegundos (SELECT * WHERE id = y LIMIT 1). Este requerimiento, aunque suene simple, plantea un desafío único en arquitecturas Lakehouse.
El dilema del Lakehouse: diseñado para volumen, no para velocidad
Las arquitecturas Lakehouse son excelentes para lo que fueron diseñadas: trabajar con archivos grandes (usualmente de 1 GB) almacenados en la nube y usar cómputo distribuido para escanear tablas completas o hacer agregaciones masivas.
Sin embargo, cuando se trata de obtener una sola fila, el rendimiento puede ser sorprendentemente bajo.
El problema es arquitectónico: los Lakehouses están optimizados para procesamiento analítico por lotes (OLAP), no para consultas puntuales (OLTP). Lograr que una consulta de una sola fila se ejecute en milisegundos —o incluso en menos de un segundo— puede ser muy difícil.
¿Por qué importa tanto el rendimiento en milisegundos?
Porque hay casos reales que lo exigen:
Inferencia en línea: modelos de machine learning que generan predicciones en tiempo real.
Aplicaciones de cara al cliente: por ejemplo, una app de supermercado que genera cupones personalizados al instante.
La solución: crear una instancia OLTP sobre tu Lakehouse
La respuesta está en crear una instancia OLTP (Online Transaction Processing) encima de tu arquitectura Lakehouse.
Esto te da lo mejor de ambos mundos: el poder analítico del Lakehouse con la velocidad de bases de datos transaccionales como PostgreSQL.
Opciones de configuración
Al configurar tu instancia OLTP, vas a encontrar varias opciones clave:
Capacity units: cada unidad representa 16 GB de RAM. Ajustá según tus necesidades de rendimiento.
Restore window: permite hacer backups automáticos y clonar bases de datos para pruebas (como un “Git para bases de datos”).
Alta disponibilidad (HA): crea una instancia espejada para redundancia, que además puede funcionar como réplica de lectura para mejorar el rendimiento.
Creación de tablas sincronizadas en Unity Catalog
Para que tus tablas Delta sean accesibles desde la instancia OLTP, necesitás crear tablas sincronizadas en Unity Catalog.
Se recomienda deduplicar por ID y timestamp (también conocido como Slowly Changing Dimension type 1), lo cual se maneja automáticamente durante la sincronización.
En escenarios donde la tabla Delta se construye con un campo ID BIGINT GENERATED ALWAYS AS IDENTITY, podés dejar activa la opción de clave primaria única.
La clave primaria no forzada (solo informativa) de Delta se convierte en un índice de clave primaria real en PostgreSQL, permitiendo búsquedas ultrarrápidas.
Una vez configurado, Unity Catalog mostrará metadatos adicionales indicando que la tabla está corriendo sobre PostgreSQL, incluyendo información de la clave primaria.
Resultados de rendimiento
Al conectar el editor SQL a la base OLTP, vas a poder ver tus tablas sincronizadas junto con los catálogos del sistema PostgreSQL.
Luego, al ejecutar una consulta como:
Una vez conectado a Postgres en la vista previa del catálogo del panel izquierdo, vemos nuestra tabla sincronizada, además de los catálogos de Postgres.
Y ahora podemos ejecutar SELECT en nuestra tabla de transacciones para obtener solo una fila:
El resultado llega en menos de 1 milisegundo!
Antes de empezar
Tené en cuenta que:
La funcionalidad OLTP está disponible solo en regiones seleccionadas.
Puede requerir activación previa desde la sección Previews de tu workspace de Databricks.
Conclusión
Combinando el poder analítico del Lakehouse con la velocidad de los sistemas OLTP, podés lograr consultas en milisegundos ideales para aplicaciones modernas y de alta interacción, sin perder tus flujos analíticos existentes.
Este enfoque híbrido marca la evolución natural de las arquitecturas de datos: ya no tenés que elegir entre potencia analítica y velocidad transaccional — ahora podés tener ambas.
