Detrás de escena con Lakebase, parte 2

En la primera parte de esta serie, exploramos cómo mover la base de datos subyacente de Backstage a Databricks Lakebase convirtió las migraciones de esquemas arriesgadas en operaciones de ramificación y prueba de 1 segundo. Pero un ciclo de desarrollo más rápido solo te lleva hasta cierto punto si los equipos de seguridad y gobernanza todavía tratan tu base de datos operativa como una caja negra.

En una pila tradicional, tu base de datos de aplicaciones y tu lago de datos viven en dos paradigmas de seguridad completamente diferentes. El gráfico de propiedad de tu infraestructura vive en Backstage, respaldado por una instancia RDS aislada y gobernado por complejas funciones IAM y concesiones nativas de Postgres. Mientras tanto, los datos de tu almacén son gobernados por el equipo de datos utilizando Unity Catalog. Unity Catalog es un marco de código abierto creado por Databricks que proporciona una capa de gobernanza unificada para datos, IA y ahora bases de datos operativas, un solo lugar para administrar controles de acceso, pistas de auditoría, linaje y cumplimiento en todo lo que hay en la plataforma.

Para auditar una sola eliminación de tabla en RDS, necesitarías cruzar referencias CloudTrail para el principal de IAM, pg_stat_activity o pgaudit registros para la declaración SQL y CloudWatch para la marca de tiempo, tres servicios, tres lenguajes de consulta, tres políticas de acceso. La base de datos operativa se convierte en un canal secundario de cumplimiento.

Unity Catalog Absorbe la Base de Datos Operativa

Cuando apuntamos Backstage a Lakebase, no solo cambiamos dónde vivían los datos; cambiamos dónde vivía la política de acceso.

Debido a que Lakebase está integrado de forma nativa dentro de Databricks, Unity Catalog se extiende directamente sobre la base de datos Postgres operativa. En este POC, utilizamos Lakehouse Federation para exponer el catálogo de Backstage como un catálogo externo (lakebase_bs) en Unity Catalog. Una vez allí, las concesiones estándar de UC controlan quién puede ver qué, sin necesidad de gestión de roles a nivel de Postgres:

Si bien no creamos políticas de seguridad a nivel de fila de extremo a extremo para Backstage en este POC, arquitectónicamente, las mismas reglas de RLS que protegen las tablas de facturación confidenciales se pueden aplicar directamente a estas tablas operativas. El muro entre lo "operativo" y lo "analítico" deja de ser un límite físico y simplemente se convierte en un patrón de acceso.

Una Pista de Auditoría Unificada Lista para Usar

¿Recuerdas la ramificación de copia en escritura de 1 segundo que ejecutamos en la Parte 1? En una configuración tradicional, demostrarle a un ingeniero de seguridad que un desarrollador solo ramificó la base de datos durante una hora y luego la destruyó es un ejercicio manual.

Con Lakebase, cada acción del plano de control contra la base de datos operativa se registra automáticamente en system.access.audit. Para demostrar esto, consultamos el registro de auditoría para las operaciones exactas de ramificación de nuestro experimento de recuperación ante desastres de la Parte 1:

Resultado:

Cada creación y eliminación de rama de nuestros experimentos de la Parte 1 está registrada. Cada evento está vinculado a una identidad de usuario OAuth específica y una IP de origen, capturado automáticamente y gobernado por los mismos controles de seguridad a nivel de fila que todas las demás tablas de auditoría en Unity Catalog. Sin cruzar referencias de CloudTrail. Sin análisis de registros de RDS. Una consulta SQL.

Atribución de Costos Automatizada por Rama

Un equipo de gobernanza no solo quiere saber quién creó una rama, sino que quiere saber cuánto costó.

En un entorno AWS tradicional, el seguimiento del costo de una instancia RDS efímera requiere estrategias personalizadas de etiquetado de CloudWatch que a menudo pasan por alto cargas de trabajo de corta duración. Debido a que Lakebase se integra de forma nativa con las tablas de facturación del sistema de Unity Catalog, los costos de cómputo se desglosan automáticamente por project_id, branch_id y endpoint_id.

En este POC, la rama de producción se facturó a 31.6130 DBU, mientras que la rama de prueba eliminada se atribuyó de forma independiente 0.0107 DBU. El rastro de auditoría y el rastro de costos se rigen en el mismo lugar.

Qué Significa Esto para los Equipos que Trabajan con Ramas Diariamente

Nuestra historia de gobernanza responde a la pregunta de cumplimiento: ¿podemos demostrar quién hizo qué, cuándo y cuánto costó? La respuesta es sí, una consulta SQL en lugar de tres servicios. Pero hay una segunda pregunta de gobernanza que es igual de importante para los equipos de desarrollo que adoptan el flujo de trabajo de ramificación de la Parte 1: ¿qué sucede con la gobernanza cuando tu equipo crea docenas de ramas por sprint?

En la Parte 1, describimos un flujo de trabajo donde cada rama de características y cada solicitud de extracción obtienen su propia copia de base de datos aislada. Un equipo de seis desarrolladores que ejecutan sprints de dos semanas podría crear y destruir 30-40 ramas en un solo sprint. Eso son 30-40 copias de datos de producción, cada una de las cuales potencialmente contiene campos confidenciales: PII del cliente, registros financieros, datos de salud.

Aquí es donde la gobernanza a nivel de rama de Unity Catalog se vuelve fundamental, no solo conveniente. Cuando se crea una rama de Lakebase, las políticas de enmascaramiento a nivel de atributo de Unity Catalog se propagan automáticamente a la nueva rama. Un desarrollador que trabaja en su rama de características nunca ve datos de producción sin enmascarar, no porque alguien haya recordado configurarlo, sino porque la capa de gobernanza la aplica en el momento de la creación. La rama CI que ejecuta tus pruebas de PR se rige de manera idéntica a la producción. La rama QA donde un probador ejecuta escenarios destructivos se rige de manera idéntica a la producción. No hay una "excepción de no producción" donde los datos confidenciales se filtren porque alguien olvidó aplicar la política.

Esto es más importante de lo que parece. Según el informe "State of Data Compliance" de Perforce de 2025, el 60% de las organizaciones han experimentado brechas o robos en entornos de no producción donde los datos confidenciales se anonimizaron de manera inadecuada. El enfoque tradicional, enmascarar datos manualmente al aprovisionar entornos de desarrollo/pruebas, no escala cuando los entornos se crean y destruyen en segundos. La gobernanza debe ser automática, o no sucede.

La Nueva Oportunidad del DBA

El rastro de auditoría y los datos de atribución de costos también señalan un cambio más silencioso: el rol del DBA está evolucionando del trabajo reactivo de tickets a la arquitectura estratégica de plataformas.

Hoy en día, gran parte del tiempo de un DBA se dedica a solicitudes operativas: aprovisionamiento de entornos, revisiones de esquemas, actualizaciones de datos, concesión de accesos. Un equipo de seis desarrolladores puede generar más de 30 tickets por sprint, y el calendario del DBA se convierte en una cola. La experiencia que hace valiosos a los DBAs –comprender la integridad de los datos, el rendimiento y la gobernanza a un nivel profundo– queda sepultada bajo un trabajo repetitivo de aprovisionamiento.

Cuando la ramificación es autoservicio y la gobernanza es automática, ese trabajo repetitivo desaparece. Los desarrolladores aprovisionan sus propios entornos en un segundo. Los cambios de esquema se revisan de forma asíncrona en las solicitudes de extracción (pull requests): el DBA ve un diff de esquema formateado publicado por CI, lo revisa en su propio horario y lo aprueba o solicita cambios a través del flujo de trabajo normal de PR. Con el tiempo ahora disponible, esas revisiones van más allá: el DBA ayuda a los miembros del equipo a comprender los datos y las estructuras existentes en producción, trabaja con ellos para llegar a mejores soluciones y realiza revisiones exhaustivas que mantienen los estándares de integridad de datos y gobernanza. El enmascaramiento de datos se aplica por política, no por intervención manual. La atribución de costos es automática, no un ejercicio de conciliación mensual.

Lo que se abre es el trabajo que realmente aprovecha la experiencia del DBA: definir políticas de ramificación, diseñar reglas de gobernanza, diseñar flujos de trabajo de promoción, ajustar el rendimiento y establecer las salvaguardias que hacen que el autoservicio sea seguro. El DBA pasa de hacer el trabajo a diseñar cómo se hace el trabajo, de más de 30 tickets operativos por sprint a menos de 5 revisiones de políticas de alto valor. El rastro de auditoría demostrado anteriormente no es solo un artefacto de cumplimiento, es el nuevo panel estratégico del DBA, una vista en tiempo real de cómo se está utilizando la plataforma y dónde invertir a continuación.

Del Cambio de Rol a las Herramientas

El pivote del DBA de tickets operativos al diseño de plataformas solo funciona si las herramientas cambian con el rol. La plataforma tiene que hacer el trabajo rutinario por sí sola, y el DBA necesita un lugar para diseñar cómo se realiza ese trabajo.

Dos herramientas de código abierto, ambas implementadas como Databricks Apps y ambas gobernadas por las mismas concesiones de Unity Catalog y el rastro de auditoría descritos anteriormente, cierran ese ciclo.

LakebaseOps es lo que la plataforma hace por sí sola. Tres agentes –Aprovisionamiento, Rendimiento y Salud– reemplazan 51 de las tareas para las que un DBA solía presentar tickets. Siete de ellos se ejecutan como trabajos programados de Databricks y reemplazan el crontab pg_cron que un DBA mantendría manualmente. Una interfaz de monitoreo muestra métricas pg_stat en vivo, regresiones de consultas lentas, aplicación de TTL de ramas y un panel de adopción de 9 KPIs. Un asistente de migración califica diez motores de origen (Aurora, RDS, Cloud SQL, AlloyDB, Cosmos DB y más) frente a Lakebase, con precios en vivo de las API de AWS y Azure.

Lakebase MCP es lo que el DBA hace sobre la plataforma. Un servidor Model Context Protocol que expone 46 herramientas a cualquier agente de IA capaz de MCP (Claude, Copilot, GPT). El DBA deja de abrir pgAdmin y comienza a describir la intención:

Dos opciones de diseño mantienen esto seguro. Primero, gobernanza de doble capa: una protección de sentencias SQL y una protección de acceso por herramienta, con cuatro perfiles preconstruidos (solo lectura, analista, desarrollador, administrador) que se mapean en los mismos patrones de acceso de UC que se muestran anteriormente. Un asistente de codificación se ejecuta como read_only y físicamente no puede eliminar una tabla.

Segundo, cada consulta es atribuible: el servidor etiqueta cada sentencia con la herramienta de origen:

Combinado con la atribución de costos a nivel de rama mostrada anteriormente, puede responder "¿qué agente en qué rama generó el pico de CPU de las 4 AM?" en una sola consulta SQL.

LakebaseOps se ejecuta para el equipo. Lakebase MCP se ejecuta con el equipo. Ambos heredan la postura de gobernanza que acaba de ver.

En la Parte 3 de esta serie, veremos la recompensa definitiva: tomar los datos de propiedad de la infraestructura dentro de Backstage y unirlos directamente a los datos de facturación en la nube en una sola consulta SQL.

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