Arquitectura LTAP

El Procesamiento Transaccional/Analítico de Lago (LTAP) es una arquitectura de datos que sirve tanto cargas de trabajo transaccionales (OLTP) como analíticas (OLAP) desde una capa unificada de almacenamiento de datos en el lago, bajo un único modelo de gobernanza, por lo que no tienes que mantener sistemas transaccionales y analíticos separados sincronizados. Elimina las canalizaciones de captura de datos de cambios (CDC), replicación y transformación que los equipos tradicionalmente mantienen para copiar los datos operativos en un sistema analítico separado. Azure Databricks construye LTAP sobre la arquitectura de almacenamiento Lakebase. Para el anuncio, véase Databricks lanza LTAP: la primera arquitectura de procesamiento transaccional/analítico de Lake.

LTAP es una arquitectura, no una sola característica. Azure Databricks lo entrega a través de un conjunto de capacidades de Lakebase que están siendo desarrolladas y ampliadas activamente. Las capacidades disponibles dependen de tu nube. Esta página explica la arquitectura. Para las capacidades que puedes usar hoy en tu nube, consulta Capacidades que implementan LTAP.

Importante

Antes de leer esta página, lee la arquitectura de Lakebase para entender la arquitectura de Lakebase y sus componentes: computación Postgres sin estado, safekeepers, servidores de páginas y almacenamiento de objetos en la nube. LTAP se basa directamente en cómo Lakebase separa la computación del almacenamiento, y el resto de esta página asume esa base.

El coste de mantener dos pilas sincronizadas

Las aplicaciones dividen su trabajo de datos en dos tipos de cargas de trabajo. Las cargas de trabajo transaccionales (OLTP) actúan en unas pocas filas a la vez y necesitan el contenido completo de esas filas rápidamente, como al procesar un pago o devolver un resultado de la API. Las cargas de trabajo analíticas (OLAP) buscan información en grandes conjuntos de datos, a menudo agregando y uniendo muchas filas, como prever ventas o detectar fraudes. Estos patrones tiran en direcciones opuestas: OLTP necesita lecturas y escrituras constantes de baja latencia en filas individuales, mientras que OLAP necesita escanear y agregar a través de grandes volúmenes de datos. Durante décadas, la respuesta fueron dos sistemas separados: una base de datos transaccional para la aplicación y un almacén de datos o un refugio para la analítica.

Conectar esas dos pilas es la parte costosa. Mantenerlos sincronizados implica ejecutar captura de datos de cambios (CDC), pipelines de streaming y réplicas de lectura cuya única función es copiar datos de un sistema a otro. Esa infraestructura es frágil, añade latencia entre el momento en que se escriben los datos y el momento en que pueden analizarse, y compite por recursos con la base de datos transaccional principal. A medida que las aplicaciones y los agentes de IA necesitan cada vez más análisis sobre los datos transaccionales más recientes, esta brecha ralentiza a los equipos. Copiar datos entre dos sistemas también genera un riesgo de gobernanza: la línea de identidad puede romperse a medida que avanzan los datos, lo que dificulta cumplir obligaciones como las solicitudes de retirada del RGPD.

Cómo unifica LTAP los datos en la capa de almacenamiento

En vez de crear una mejor canalización entre dos pilas, LTAP elimina por completo la necesidad de una canalización. Lo hace replanteando la base de datos desde el almacenamiento hacia arriba.

Lakebase ya separa la proceso sin estado de Postgres de una capa de almacenamiento duradero compuesta por safekeepers, pageservers y almacenamiento de objetos en la nube. Una transacción se confirma una vez que un quórum de safekeepers registra de forma duradera su registro de escritura anticipada, y los pageservers materializan entonces de forma asíncrona esos cambios en el almacenamiento de objetos en la nube, de modo que los datos ya no permanecen bloqueados dentro de un único motor de base de datos.

Nota

Para ver cómo Lakebase separa computación y almacenamiento, véase Arquitectura Lakebase.

LTAP añade un paso a esa capa de almacenamiento. A medida que el almacenamiento de Lakebase materializa los datos en el almacenamiento de objetos, transcodifica los datos de Postgres orientados a filas al formato columnar de Parquet a medida que los datos llegan al lago, donde pueden leerse mediante formatos de tabla abiertos como Delta e Iceberg. Esta transcodificación es lo que permite que una única copia de datos sirva tanto a cargas de trabajo OLTP como OLAP. Está diseñado para que la copia columnar siga siendo una representación fiel y eficiente del original de Postgres:

• Se mantiene la semántica. El almacenamiento de Lakebase transcodifica cada valor a su forma columnar manteniendo la representación original de Postgres, de modo que cualquier motor compatible con Postgres puede reinterpretar los datos sin perder información. Los tipos que no corresponden correctamente a Parquet, como NaN, NUMERIC overflow o tipos de extensión como vector, array, geography y JSON, se conservan en un campo de overflow que contiene la representación canónica de Postgres.
• Se conservan las versiones en fila. La transcodificación conserva las versiones intermedias de las filas, por lo que la copia columnar contiene la misma información de versión que los datos de las filas.
• Los datos columnares se comprimen bien. El diseño columnar está altamente comprimido, lo que reduce el espacio de almacenamiento y la cantidad de datos que se transfieren hacia y desde el almacenamiento de objetos.

La transcodificación se ejecuta completamente en la capa de almacenamiento, aislada de la instancia principal de Postgres, por lo que no afecta a tu carga de trabajo de servicio transaccional. Se basa en algo que Lakebase ya hace: volcar datos confirmados al almacenamiento de objetos en la nube. LTAP simplemente añade el formato columnar a ese mismo vaciado. No hay ningún pipeline que tengas que crear, ni ningún proceso externo consultando continuamente tu base de datos.

No todo está transcodificado. Los índices Postgres permanecen en su representación original en la capa de almacenamiento duradero, en lugar de convertirse en columnas, por lo que las lecturas y consultas transaccionales de puntos se mantienen rápidas mientras la copia columnar sirve a la analítica.

Como los datos viven en almacenamiento externalizado y versionado, crear una rama o restaurarlos a un punto en el tiempo es una operación de metadatos más que una copia física. Puedes ramificar una gran base de datos de producción en segundos, ejecutar un experimento o una migración arriesgada contra la sucursal y descartarla, sin duplicar los datos subyacentes.

Nota

Una rama de Lakebase es un clon de copia al escribir del almacenamiento de tu base de datos: comparte los datos existentes del original y almacena solo los cambios, por lo que no duplica ningún dato por adelantado. La restauración en un momento en el tiempo utiliza el mismo almacenamiento versionado para devolver una base de datos a un momento anterior dentro de su ventana de restauración. Para saber más, consulta Ramas de base de datos y Restauración en un punto en el tiempo.

Este enfoque a nivel de almacenamiento es lo que diferencia LTAP de la captura de datos por cambios (CDC). CDC replica los datos de tu almacenamiento OLTP en una capa analítica separada usando un proceso externo que consulta continuamente la base de datos principal y una canalización que transforma los cambios de fila en datos columnares. Ese pipeline consume recursos de tu base de datos transaccional principal, te obliga a gestionar tú mismo los cambios de esquema y los casos límite, y te hace elegir entre la frescura de los datos y el coste del pipeline, todo ello mientras añade puntos adicionales de fallo. LTAP adopta un enfoque a nivel de almacenamiento: el almacenamiento en Lakebase transcodifica datos al lago como parte de la operación normal de almacenamiento, sin ningún proceso externo que compita con tu carga de trabajo ni una tubería que puedas construir o mantener.

Los tres pilares de LTAP

Unificar los datos en la capa de almacenamiento otorga a LTAP tres propiedades definitorias.

• Gobernanza universal. Unity Catalog regula el acceso analítico a una copia lógica de tus datos en ambas cargas de trabajo.
• Motores hechos a propósito. Postgres atiende transacciones y Lakehouse ofrece analítica, y ninguno compromete al otro.
• Una única copia lógica en almacenamiento abierto. Ambos motores leen una copia de tus datos en formatos abiertos, sin réplicas ni canalizaciones que haya que mantener sincronizadas.

Gobernanza universal

Unity Catalog regula el acceso analítico a tus datos en ambas cargas de trabajo. Después de registrar una base de datos Lakebase, Unity Catalog aplica permisos, linaje y auditoría al cómputo externo que la lee.

Nota

La gobernanza del Catálogo Unity se aplica hoy al acceso analítico : el cómputo externo, como Lakehouse//RT y Change Data Feed, que lee tus datos registrados en Lakebase. Aún no gobierna directamente las tablas individuales de Postgres. El acceso a través de la ruta transaccional , es decir, aplicaciones y clientes que se conectan a Postgres, sigue estando controlado por los privilegios estándar de Postgres (GRANT y REVOKE), no por el Catálogo de Unity. En la práctica, Unity Catalog controla el acceso analítico y al lakehouse, mientras que los roles y privilegios de Postgres rigen el acceso transaccional.

Motores diseñados específicamente

Postgres cubre tu carga de trabajo transaccional y Lakehouse ofrece analítica, cada uno con las fortalezas para las que fue diseñado. Una idea errónea habitual es pensar que unificar los dos significa que los datos operativos se convierten en datos inactivos almacenados en Iceberg. No es así. Lakebase sigue siendo el estándar de Postgres. La indexación, la creación de ramas, la recuperación en un momento determinado, las extensiones y las lecturas y escrituras puntuales de baja latencia siguen funcionando exactamente igual que hasta ahora.

Las lecturas analíticas no compiten con tu carga de trabajo transaccional porque están aisladas de la instancia principal de Postgres. Cuando un motor analítico como Lakehouse//RT consulta datos en tiempo real de Lakebase, devuelve un resultado fresco y transaccionalmente consistente sin copiar datos:

• El motor lee la mayor parte de los datos desde la copia columnar en el almacenamiento de objetos, no desde Postgres.
• Para obtener una vista coherente a nivel transaccional, pide a Postgres solo el número de secuencia del registro (LSN) actual, un único valor que marca una posición en el registro de escritura adelantada. Esto es una búsqueda barata de metadatos.
• En cuanto al pequeño conjunto de cambios muy recientes que aún no se han incorporado al lago, los lee del servidor de páginas y los fusiona encima.

Postgres no proporciona ningún tráfico analítico de lectura más allá de devolver ese único LSN, y la transcodificación se ejecuta en la capa de almacenamiento, no en la instancia de Postgres que sirve a tu aplicación. Tu carga de trabajo operativa sigue funcionando según lo previsto.

Una única copia lógica en almacenamiento abierto

Dado que los datos residen en el lago en formato Parquet columnar, legible a través de formatos de tabla abiertos como Delta e Iceberg, Lakebase (OLTP) y el Lakehouse (OLAP) comparten la misma base de almacenamiento. Mantienes una copia lógica de los datos en ambas cargas de trabajo, en lugar de conciliar una base de datos transaccional con una copia analítica separada.

Cada motor puede almacenar en caché o representar esos datos en un formato físico diferente para el rendimiento. Lakebase utiliza páginas de Postgres para lecturas puntuales rápidas de OLTP, y los motores analíticos leen Parquet en formato columnar. Sigues trabajando con un único conjunto de datos lógico , en lugar de mantener copias transaccionales y analíticas separadas y sincronizarlas.

Cada tabla tiene un único escritor, ya sea Lakebase o el lakehouse. Ambos motores leen esa copia lógica, así que los mismos datos están disponibles para tus aplicaciones y para analítica sin necesidad de una segunda copia.

¿Necesitas cambiar cómo usas Lakebase?

N.º Adoptar capacidades LTAP no requiere una migración de datos ni un cambio en la forma en que tus aplicaciones se conectan a Lakebase. Lakebase sigue siendo el estándar Postgres: tus extensiones, índices, consultas y código de aplicación existentes siguen funcionando sin cambios. Cada una de las capacidades LTAP es independiente, así que puedes adoptar cualquiera de ellas cuando la carga de trabajo lo necesite.

Capacidades que implementan LTAP

Pones en práctica la arquitectura LTAP a través de un conjunto de capacidades de Lakebase. Cada uno se basa en la base de almacenamiento compartido descrita anteriormente, y juntos cubren los caminos que siguen los datos a través de LTAP:

• Administrar y registrar: incorporar los datos de Lakebase en Unity Catalog.
• Servir datos del lakehouse en Lakebase: tablas sincronizadas, aceleradas por LTAP Direct Writes.
• Consulta datos en vivo de Lakebase: Lakehouse//RT para análisis, Lakebase Change Data Feed para flujos de cambios.

El siguiente diagrama muestra cómo estas capacidades escriben y leen desde una copia de tus datos, gobernada por Unity Catalog.

Lakehouse//RT y Lakebase Change Data Feed leen los mismos datos subyacentes pero los representan de forma diferente. Lakehouse//RT lee el estado actual de los datos en tiempo real de Postgres para su análisis. Change Data Feed proporciona un flujo de cambios en el nivel de fila para los pipelines posteriores y la auditoría. Tampoco se trata del CDC externo que elimina LTAP: ambos operan sobre la única copia de datos.

La siguiente tabla enumera cada capacidad LTAP y qué hace, junto con su estado de lanzamiento en tu nube. La disponibilidad varía según la nube, por lo que una capacidad que no se ofrece en tu nube se marca como no disponible.

Capability	Situación	Descripción
Registrar Lakebase en el Catálogo de Unity	Disponibilidad general	Controle el acceso analítico a los datos de Lakebase y ejecute consultas entre múltiples fuentes desde el lakehouse.
Servir datos con tablas sincronizadas	Disponibilidad general	Sirve los datos de la tabla de Unity Catalog en Lakebase para lecturas OLTP de baja latencia. LTAP Direct Writes (Beta) acelera la carga inicial en cada modo de sincronización, además de los refrescos completos.
Lakehouse//RT consultando Lakebase	Beta	Ejecuta consultas OLAP transaccionalmente consistentes sobre datos en tiempo real de Postgres, sin afectar al rendimiento OLTP de Lakebase.
Flujo de cambios de datos de Lakebase	Public Preview	Almacena los cambios en el nivel de fila de las tablas de Postgres de Lakebase como tablas Delta de Unity Catalog para los flujos de trabajo posteriores y la auditoría.

Cómo abordar la implementación

Ahora que conoces las capacidades, la pregunta es cuáles necesita tu carga de trabajo. Implementas LTAP combinando las capacidades que coinciden con el flujo de datos a través de tu arquitectura.

La decisión clave es la dirección: para cada conjunto de datos, ¿qué sistema es el propietario de la escritura? Cada tabla tiene un único redactor, y eso determina qué capacidades usas.

• Lakebase es responsable de la escritura. Tu aplicación escribe en Postgres, y quieres que esos datos operativos estén disponibles para análisis sin copiarlos. Por ejemplo, una aplicación de ventas emite pedidos y pagos a Lakebase a medida que ocurren. Utiliza Lakehouse//RT para ejecutar un panel de control de ingresos en tiempo real sobre esos pedidos, o Lakebase Change Data Feed para transmitir cada cambio en los pedidos a un flujo de trabajo posterior o a un registro de auditoría.
• Lakehouse es responsable de la escritura. Sus datos se generan o mantienen en el lakehouse, y desea realizar lecturas OLTP de baja latencia sobre ellos desde su aplicación. Por ejemplo, un trabajo nocturno en una casa del lago calcula recomendaciones de productos o una tabla de precios. Utiliza tablas sincronizadas para servir esos datos en Lakebase y que tu aplicación pueda leerlos con baja latencia, y activa las escrituras directas LTAP para acelerar la carga inicial de una tabla grande.

Asigna cada conjunto de datos a una de estas opciones, registra la base de datos en Unity Catalog para fines de gobernanza y, a continuación, sigue la documentación de cada capacidad para implementar cada opción. Una misma aplicación suele utilizar ambas direcciones: servir datos de referencia desde el lakehouse a Postgres, al tiempo que expone sus propias escrituras transaccionales a los análisis. La disponibilidad varía según la nube, así que consulta la tabla de capacidades de arriba para confirmar qué se ofrece en tu nube.

Pasos siguientes

• Arquitectura Lakebase: Entiende cómo Lakebase separa la computación sin estado del almacenamiento duradero. Consulta arquitectura Lakebase.
• Registre una base de datos en Unity Catalog: administre los datos de Lakebase y consulte desde el lakehouse. Consulte Registrar una base de datos de Lakebase en el catálogo de Unity.
• Sirve datos con tablas sincronizadas: sincroniza los datos de las tablas de Unity Catalog con Lakebase para lecturas de baja latencia y acelera grandes cargas con escrituras directas LTAP. Consulte Serve lakehouse data with synced tables (Servir datos de Lakehouse con tablas sincronizadas).

• Feed de datos de cambios de Lakebase: Transmite los cambios en el nivel de fila al lakehouse para los procesos de datos y la auditoría. Consulte Lakebase Change Data Feed.

Aprende más

• Anuncio: Databricks lanza LTAP: la primera arquitectura de procesamiento transaccional/analítico de Lake
• Blog de ingeniería: De monolito a Lakebase y luego a LTAP: replanteando la base de datos desde el almacenamiento hacia arriba
• Demo: LTAP: La primera arquitectura de procesamiento transaccional/analítico de Lake