Un agente puede razonar sobre media transacción: Databricks hace las escrituras multitabla todo o nada

Un analista de siniestros le pregunta a un agente qué pasivos abiertos están ligados a los siniestros cerrados esta semana. El proceso nocturno que cierra siniestros ya actualizó la tabla de siniestros y todavía está recorriendo la tabla de pasivos. El agente cruza las dos, encuentra siniestros marcados como cerrados con pasivos aún abiertos y reporta un problema de reservas que no existe. Su razonamiento era impecable. Sus datos eran media transacción.

Las plataformas analíticas han tolerado durante años esa ventana porque una persona que leía un dashboard a las 9 de la mañana rara vez consultaba en mitad de un lote. Los agentes consultan cada vez que se les pide, y afirman lo que encuentran con confianza.

Qué lanzó Databricks

El 16 de octubre Databricks puso en disponibilidad general (GA) las transacciones multi sentencia para tablas gestionadas por Unity Catalog, tanto en formato Delta Lake como Apache Iceberg. Una transacción puede abarcar varias sentencias y varias tablas, en ambos formatos, y se confirma de forma atómica: todos los cambios se hacen visibles a la vez, o ninguno. Databricks describe el uso de tablas temporales para preparar los datos, empaquetar la lógica en procedimientos almacenados y confirmar todo el workflow como una sola unidad, con GET DIAGNOSTICS entre las herramientas para inspeccionar qué ocurrió.

Tres detalles importan para el uso en producción:

• Concurrencia a nivel de fila. Las transacciones concurrentes pueden escribir en la misma tabla siempre que no actualicen la misma fila, en lugar de serializar a todos los escritores con bloqueos de tabla.
• La gobernanza también aplica a las escrituras. El control de acceso basado en atributos de Unity Catalog, la seguridad a nivel de fila y el enmascaramiento de columnas se aplican a las lecturas y escrituras dentro de una transacción.
• Las tablas de streaming pueden ser destinos, de modo que los pipelines posteriores reciben actualizaciones consistentes.

Dos clientes ilustran el caso. El History Mode de Fivetran conserva cada versión de un registro de origen, lo que significa que cada cambio son dos escrituras: cerrar la versión anterior e insertar la nueva. Fivetran ahora confirma ambas como una sola unidad y afirma que eliminó código de reconciliación y de reparación de consistencia. Accolade ejecuta unas 1,700 transacciones de producción al día para el procesamiento de siniestros y pasivos. Databricks también cita transacciones concurrentes 4.7x más rápidas a escala, una cifra del proveedor sin metodología publicada.

Por qué esto pertenece a una revisión de arquitectura de IA

Los agentes que leen necesitan instantáneas consistentes. Los agentes de text-to-SQL, los asistentes de analítica y los agentes de informes consultan el estado en que estén las tablas. Si los pipelines que los alimentan publican los cambios en varias tablas de forma atómica, el agente nunca ve el estado intermedio. Esa es una propiedad de la plataforma de datos, y sale más barato resolverla ahí que enseñar a cada agente a detectar lotes a medio terminar. Va en la misma lista que las definiciones semánticas que describimos en la capa de definiciones de negocio.

Los agentes que escriben necesitan una unidad de deshacer. Los agentes que reparan datos, concilian registros o aplican correcciones hacen varios cambios relacionados. Una transacción le da a ese trabajo un límite de todo o nada: si un paso falla, nada queda a medio aplicar. También es una unidad natural para revisar y registrar: una transacción con sus cambios y la identidad que los hizo, en lugar de una ristra de sentencias separadas. Para las escrituras de agentes, la misma idea aparece en el runtime como checkpoints y compensación; en el lakehouse ahora existe en la capa de datos.

La gobernanza se queda con los datos. Como las políticas de Unity Catalog se aplican dentro de las transacciones, un agente que escribe con la identidad de un usuario o de un service principal no puede usar una transacción para saltarse los filtros de fila ni las máscaras.

Lo que la atomicidad no le da

Atómico no es correcto. Una transacción que confirma valores equivocados los confirma de forma consistente. Las comprobaciones de calidad de datos, las conciliaciones contra los sistemas de origen y el trabajo de reparación de datos que los agentes suelen desencadenar siguen siendo necesarios.

Atómico tampoco es toda la historia del aislamiento. El anuncio de Databricks describe la concurrencia a nivel de fila, pero no detalla el nivel de aislamiento para cada combinación de lectura y escritura, ni enumera qué tipos de cómputo y qué operaciones son compatibles. Revise la documentación sobre esos puntos antes de apoyarse en transacciones para escrituras concurrentes de agentes.

Y la disponibilidad general (GA) cubre las tablas gestionadas por Unity Catalog. Las tablas externas y los datos que viven fuera de la plataforma quedan fuera de la garantía, algo que conviene saber antes de describirle a alguien la respuesta de un agente como consistente.