La regla de bases de datos de hace 40 años que los agentes acaban de romper: cómo LTAP unifica las cargas de trabajo OLTP y OLAP

Jonathan Katz ha pasado su carrera a ambos lados de una línea con la que la mayor parte de la industria de los datos simplemente ha aprendido a convivir. Como colaborador de Postgres desde hace mucho tiempo y ahora Senior Staff Product Manager en Databricks, ha visto cómo los sistemas operativos y analíticos funcionan como dos mundos separados, conectados únicamente por pipelines, copias y concesiones.

En esta conversación, Jonathan explica por qué existía esa separación en primer lugar, por qué los agentes de AI son lo que finalmente la está rompiendo y cómo LTAP reduce la brecha al replantear dónde se encuentran ambos mundos: no en un solo motor, sino en una capa de almacenamiento unificada.

La suposición que rompieron los agentes de AI

La industria ha convivido con una separación estricta entre los sistemas de bases de datos operativas y analíticas durante décadas. ¿Por qué el auge de los agentes de AI autónomos está rompiendo con eso?

Jonathan Katz: Existen dos mundos de datos. Los datos operativos son los que tocas cuando procesas una transacción de tarjeta de crédito o buscas fraudes: consultas muy cortas y rápidas, analizando los datos línea por línea. Los datos analíticos son los que has estado acumulando durante semanas, meses o años, y cuando los consultas, buscas en todo el conjunto de datos. Ambos intentan devolver una respuesta lo más rápido posible, pero lo hacen de formas completamente diferentes.

Esa diferencia no es arbitraria. Se reduce a una cuestión física. Si almacenas tus datos en filas, así es como devuelves una única respuesta rápida lo antes posible. Si los almacenas en columnas, así es como escaneas y agregas a través de todo lo más rápido posible. Además, por diseño, una consulta analítica puede consumir todos los recursos de un sistema masivamente paralelizado para obtener una respuesta sobre un conjunto de datos muy grande, mientras que una consulta operativa está diseñada para consumir la menor cantidad de recursos posible y, al mismo tiempo, devolver una respuesta rápidamente. Esto conduce a dos formas muy diferentes de pensar en cómo diseñar y gestionar tu sistema de datos, y requiere diferentes tipos de optimizaciones.

Postgres, una de las bases de datos más implementadas del planeta, está construida en torno a filas porque está optimizada para cargas de trabajo operativas. Los motores analíticos están construidos en torno a columnas por la razón opuesta. Debido a esa diferencia física fundamental, ambos sistemas siempre han tenido que estar separados, y cada vez que querías analizar datos operativos, tenías que enviarlos a otra parte.

El auge de los agentes de AI ha cambiado lo que necesitamos de las bases de datos. Es parte de la razón por la que existe la arquitectura de Lakebase en primer lugar: bases de datos creadas para seguir el ritmo de cómo funcionan realmente los agentes. Por ejemplo, los agentes tienen la tarea de buscar fraudes o anomalías, y esos eventos ocurren en cientos de milisegundos. Pero ese sistema también maneja un gran volumen de escrituras y lecturas cortas al mismo tiempo. Un solo agente puede ser lo suficientemente inteligente como para saber qué consulta necesita ejecutar. Un grupo de agentes puede saturar fácilmente un sistema operativo si no se establecen medidas de protección.

Qué es realmente LTAP

¿Qué es LTAP y cómo funciona realmente por dentro?

Jonathan Katz: LTAP (Lake Transactional/Analytical Processing) te permite ejecutar consultas analíticas directamente sobre datos operativos en tiempo real sin mover esos datos a ninguna parte y sin sobrecargar el sistema que atiende tus transacciones. Lo hace unificando los datos transaccionales y analíticos en una sola capa de almacenamiento lógico, en lugar de forzarlos a pasar por sistemas separados conectados por un pipeline.

Por dentro, LTAP solo es posible gracias a cómo está diseñada la propia arquitectura de Lakebase: un cómputo sin estado y efímero que está completamente desacoplado del almacenamiento en el lago. Esa separación, heredada de Neon, significa que la capa de almacenamiento duradero puede manejar escrituras de alto rendimiento y enviarlas periódicamente al almacenamiento de objetos para su permanencia, independientemente del cómputo que se esté ejecutando contra ella en cualquier momento. Dado que esos datos ya se estaban optimizando para el almacenamiento en la nube, ¿por qué no representarlos en el mismo formato columnar que ya utiliza el Lakehouse, de modo que motores como Apache Spark y SQL puedan leerlos directamente y obtener lecturas analíticas de alto rendimiento sin una segunda copia?

La parte más difícil fue asegurarse de que nada se perdiera en el camino. Postgres tiene sus propios tipos de datos y codificaciones, y los formatos abiertos como Iceberg y Delta tienen los suyos. Tuvimos que escribir los datos de manera que se preservara la representación física exacta de los datos originales de Postgres, sin cambiar un solo bit, y llevarlos a un archivo Parquet. Esa es la pieza que nos permitió fusionar las representaciones operativas y analíticas de los mismos datos en una sola. En la práctica, la capa de almacenamiento funciona en dos niveles: un nivel caliente (hot) que mantiene los datos en formato de fila para un acceso operativo rápido, y un nivel frío (cool) que los mantiene en formato columnar para lecturas analíticas, de modo que cualquiera de las partes pueda obtener lo que necesita de manera eficiente.

Por qué LTAP tiene éxito donde HTAP se estancó

HTAP intentó resolver la analítica en tiempo real hace años y se estancó. ¿Por qué hacer esto en la capa de almacenamiento del lakehouse tiene éxito donde el HTAP tradicional falló?

Jonathan Katz: Puedes hacer que los sistemas HTAP funcionen, pero son costosos. Son complejos, difíciles de ejecutar y, por lo general, no son abiertos. Lo que diferencia al modelo LTAP es que obtienes cómputo operativo serverless y cómputo analítico serverless como dos cosas separadas. Puedes adaptar exactamente cuánto cómputo utilizas para cada carga de trabajo de forma independiente, en lugar de pagar por un único sistema que intenta hacer ambos trabajos a la vez. El almacenamiento es la parte barata de cualquier sistema de datos. El cómputo es la parte costosa.

Ese es todo el argumento para unificar la capa de almacenamiento en lugar del motor: puedes conservar el motor especializado y eficiente para cada tarea, y solo pagas por el cómputo donde realmente lo necesitas, en lugar de ejecutar un sistema costoso que intenta ser bueno en todo a la vez.

Qué falla cuando los agentes actúan sobre datos desactualizados

Explícame un flujo de trabajo agéntico específico que falle o se degrade hoy en día porque lee y actúa sobre datos desactualizados. ¿Qué es lo que realmente sale mal?

Jonathan Katz: La detección de fraudes es el ejemplo más claro. Las transacciones de tarjetas de crédito se autorizan en cientos de milisegundos o menos. Si el agente responsable de detectar el fraude trabaja con una copia de datos por lotes (batch) que tiene minutos u horas de antigüedad, simplemente es demasiado lento para detectar algo antes de que la transacción ya se haya procesado. Por lo tanto, lo ideal es que ese agente trabaje directamente contra el sistema operativo.

Pero el sistema operativo maneja un flujo constante de escrituras y lecturas cortas, y no fue diseñado para absorber también consultas analíticas pesadas. Si el agente ejecuta una consulta que escanea todo el historial de compras de un cliente para buscar anomalías, esa es una consulta costosa de ejecutar en un sistema optimizado para el tipo de carga de trabajo opuesto. Esto puede degradar el rendimiento de todas las demás transacciones que intentan procesarse al mismo tiempo. Además, una arquitectura moderna suele necesitar datos tanto del lado operativo como del analítico para tomar una buena decisión, por lo que el agente tiene que extraer información de ambos. Un solo agente podría manejar eso de manera responsable. Una flota de agentes que ejecutan consultas similares al mismo tiempo puede saturar rápidamente el sistema operativo si no hay nada que regule cuánta carga se les permite ejercer sobre él.

Gobernanza, apertura y el caso empresarial

¿Cómo implementa Databricks específicamente LTAP hoy en día y cómo se lo describirías a alguien que ya entiende por qué HTAP se queda corto?

Jonathan Katz: Más allá de la mecánica de almacenamiento, la otra pieza fundamental es el catálogo. Una de las verdaderas innovaciones del Lakehouse fue brindar a las organizaciones una visión centralizada y unificada de todos sus datos: quién tiene acceso a qué, políticas consistentes en todo, de modo que las personas no puedan leer algo como un número de seguro social a menos que pertenezcan a un grupo privilegiado. Eso nunca se aplicó realmente a los sistemas operativos, porque estos se construyeron como silos de datos desde el principio. La relación entre los datos operativos y analíticos solía ser: creas un pipeline, envías los datos y, después de eso, buena suerte. Nadie se hacía responsable de lo que sucedía con ellos en las etapas posteriores. LTAP cambia eso por completo. Todos tus datos están en un modelo de almacenamiento unificado, bajo un solo catálogo. No tienes que preocuparte de que los datos operativos salgan de un límite de gobernanza solo porque alguien necesitó analizarlos.

También hay un argumento de por qué esto debe construirse sobre una base abierta. Postgres se está acercando a ser la tercera base de datos con mejor valoración sentimental en las clasificaciones de DB-Engines. Eso no es necesariamente una medida de adopción, pero es una señal sólida de hacia dónde van las cosas y muestra el valor de la flexibilidad y la capacidad de elección. El código abierto ha impulsado algunos de los sistemas más importantes del mundo durante décadas. LTAP amplía ese mismo principio. Incluso dentro de Postgres, tus datos son portables entre sistemas Postgres, pero sigues estando limitado a Postgres. Con la capa de almacenamiento unificada de LTAP, ya no tienes que mover los datos de un lado a otro para aplicarles el motor adecuado. Ahora llevas el motor a los datos.

El cambio fundamental: almacenamiento unificado

Si tuvieras que describir el cambio fundamental que representa LTAP en una sola frase, independientemente de cómo lo plantees, ¿cómo lo dirías?

Jonathan Katz: La versión simplificada al extremo es el almacenamiento unificado. Díselo a alguien del lado de la analítica y lo entenderá casi de inmediato. Díselo a alguien del lado operativo y puede que te pregunte a qué te refieres. Pero una vez que puedes unificar las representaciones operativas y analíticas de los mismos datos sin mover nada, sin cambiar ni un solo bit, desaparecen de golpe muchos problemas que antes parecían inevitables. Ya no necesito ejecutar pipelines solo para llevar los datos a una capa de bronce o plata. Puedo empezar a analizarlos en el momento en que se escriben. También le daría la vuelta: no se trata tanto de inventar algo nuevo, sino de volver a unir dos mundos que nunca debieron separarse. Los datos son solo datos. Cuanto más los tratemos así, más fácil será para las personas, y ahora para los agentes, trabajar con ellos sin que todos tengan que negociar a través de un pipeline primero.

Volver a unir ambos mundos

Durante cuarenta años, la línea divisoria entre los datos operativos y analíticos se mantuvo porque la física del almacenamiento así lo exigía. Los agentes son la primera carga de trabajo que no puede tolerar el retraso que genera esa línea. LTAP no intenta borrar la diferencia entre una transacción y una consulta analítica. Elimina el coste adicional que solía conllevar ejecutar ambas sobre los mismos datos. Para un Data Architect que evalúa si una carga de trabajo de agentes realmente necesita este patrón, la prueba que describe Jonathan es muy útil: si la próxima decisión de un agente depende de datos que aún se están asentando, en un sistema diseñado para mantener esos datos cercanos y protegidos, el antiguo modelo de pipeline y copia no será lo suficientemente rápido. Ese es el problema específico que LTAP se diseñó para resolver.

Para obtener más información sobre LTAP, lea De monolito a Lakebase y a LTAP: repensar la base de datos desde el almacenamiento hacia arriba.

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