Dans les coulisses de Lakebase, partie 2

Dans la première partie de cette série, nous avons exploré comment le passage de la base de données sous-jacente de Backstage à Databricks Lakebase a transformé des migrations de schéma risquées en opérations de branchement et de test en 1 seconde. Mais un cycle de développement plus rapide ne vous mène que jusqu'à un certain point si les équipes de sécurité et de gouvernance traitent toujours votre base de données opérationnelle comme une boîte noire.

Dans une pile traditionnelle, votre base de données d'application et votre lac de données vivent dans deux paradigmes de sécurité entièrement différents. Le graphe de propriété de votre infrastructure vit dans Backstage, soutenu par une instance RDS isolée et régi par des rôles IAM complexes et des autorisations natives Postgres. Pendant ce temps, les données de votre entrepôt sont régies par l'équipe de données à l'aide d'Unity Catalog. Unity Catalog est un framework Open Source créé par Databricks qui fournit une couche de gouvernance unifiée pour les données, l'IA, et maintenant les bases de données opérationnelles – un seul endroit pour gérer les contrôles d'accès, les pistes d'audit, la lignée et la conformité sur tout ce qui se trouve sur la plateforme.

Pour auditer une seule suppression de table sur RDS, vous devriez croiser CloudTrail pour le principal IAM, pg_stat_activity ou pgaudit les journaux pour l'instruction SQL, et CloudWatch pour l'horodatage, trois services, trois langages de requête, trois politiques d'accès. La base de données opérationnelle devient un canal secondaire de conformité.

Unity Catalog Absorbe la Base de Données Opérationnelle

Lorsque nous avons pointé Backstage vers Lakebase, nous n'avons pas seulement changé l'emplacement des données ; nous avons changé l'emplacement de la politique d'accès.

Parce que Lakebase est nativement intégré dans Databricks, Unity Catalog s'étend directement sur la base de données Postgres opérationnelle. Dans ce POC, nous avons utilisé Lakehouse Federation pour exposer le catalogue Backstage en tant que catalogue étranger (lakebase_bs) dans Unity Catalog. Une fois qu'il est là, les autorisations UC standard contrôlent qui peut voir quoi, sans gestion de rôles au niveau Postgres requise :

Bien que nous n'ayons pas construit de politiques de sécurité au niveau des lignes (RLS) de bout en bout pour Backstage dans ce POC, architecturalement, les mêmes règles RLS qui protègent les tables de facturation sensibles peuvent être appliquées directement à ces tables opérationnelles. Le mur entre "opérationnel" et "analytique" cesse d'être une frontière physique et devient simplement un modèle d'accès.

Une Piste d'Audit Unifiée Prête à l'Emploi

Vous vous souvenez du branchement en copie sur écriture en 1 seconde que nous avons exécuté dans la partie 1 ? Dans une configuration traditionnelle, prouver à un ingénieur de sécurité qu'un développeur n'a fait que brancher la base de données pendant une heure, puis l'a détruite, est un exercice manuel.

Avec Lakebase, chaque action du plan de contrôle contre la base de données opérationnelle est automatiquement enregistrée dans system.access.audit. Pour le prouver, nous avons interrogé le journal d'audit pour les opérations de branchement exactes de notre expérience de reprise après sinistre de la partie 1 :

Résultat :

Chaque création et suppression de branche de nos expériences de la partie 1 est enregistrée. Chaque événement est lié à une identité d'utilisateur OAuth spécifique et à une adresse IP source, capturé automatiquement, et régi par les mêmes contrôles de sécurité au niveau des lignes que toutes les autres tables d'audit dans Unity Catalog. Pas de croisement de CloudTrail. Pas d'analyse des journaux RDS. Une seule requête SQL.

Attribution Automatisée des Coûts par Branche

Une équipe de gouvernance ne veut pas seulement savoir qui a créé une branche, elle veut savoir combien cela a coûté.

Dans un environnement AWS traditionnel, le suivi du coût d'une instance RDS éphémère nécessite des stratégies de balisage CloudWatch personnalisées qui manquent souvent les charges de travail de courte durée. Parce que Lakebase s'intègre nativement aux tables de facturation système d'Unity Catalog, les coûts de calcul sont ventilés automatiquement par project_id, branch_id, et endpoint_id.

Dans ce POC, la branche de production a été facturée à 31.6130 DBU, tandis que la branche de test supprimée a été attribuée indépendamment 0.0107 DBU. La piste d'audit et la piste de coûts sont gérées au même endroit.

Ce que Cela Signifie pour les Équipes qui Brancheront Chaque Jour

Notre histoire de gouvernance répond à la question de conformité : pouvons-nous prouver qui a fait quoi, quand, et combien cela a coûté ? La réponse est oui – une requête SQL au lieu de trois services. Mais il y a une deuxième question de gouvernance qui est tout aussi importante pour les équipes de développement qui adoptent le flux de travail de branchement de la partie 1 : que se passe-t-il pour la gouvernance lorsque votre équipe crée des dizaines de branches par sprint ?

Dans la partie 1, nous avons décrit un flux de travail où chaque branche de fonctionnalité et chaque demande de tirage obtient sa propre copie de base de données isolée. Une équipe de six développeurs exécutant des sprints de deux semaines pourrait créer et détruire 30 à 40 branches en un seul sprint. Cela fait 30 à 40 copies des données de production, chacune pouvant contenir des champs sensibles – PII client, dossiers financiers, données de santé.

C'est là que la gouvernance au niveau des branches d'Unity Catalog devient porteuse, pas seulement pratique. Lorsqu'une branche Lakebase est créée, les politiques de masquage au niveau des attributs d'Unity Catalog se propagent automatiquement à la nouvelle branche. Un développeur travaillant sur sa branche de fonctionnalité ne voit jamais de données de production non masquées – non pas parce que quelqu'un s'est souvenu de la configurer, mais parce que la couche de gouvernance l'applique à la création. La branche CI qui exécute vos tests de PR est régie de manière identique à la production. La branche QA où un testeur exécute des scénarios destructeurs est régie de manière identique à la production. Il n'y a pas d'"exception non-production" où des données sensibles fuient parce que quelqu'un a oublié d'appliquer la politique.

Cela est plus important qu'il n'y paraît. Selon le rapport 2025 State of Data Compliance de Perforce, 60 % des organisations ont subi des violations ou des vols dans des environnements non-production où des données sensibles ont été anonymisées de manière inadéquate. L'approche traditionnelle – masquer manuellement les données lors de la mise à disposition d'environnements de développement/test – ne fonctionne pas à l'échelle lorsque les environnements sont créés et détruits en quelques secondes. La gouvernance doit être automatique, sinon elle n'a pas lieu.

La Nouvelle Opportunité du DBA

La piste d'audit et les données d'attribution des coûts signalent également un changement plus discret : le rôle du DBA évolue du travail réactif sur tickets vers l'architecture stratégique de la plateforme.

Aujourd'hui, une grande partie du temps d'un DBA est consacrée aux demandes opérationnelles – provisionnement de l'environnement, revues de schéma, actualisations de données, octroi d'accès. Une équipe de six développeurs peut générer plus de 30 tickets par sprint, et le calendrier du DBA devient une file d'attente. L'expertise qui rend les DBA précieux – la compréhension de l'intégrité des données, des performances et de la gouvernance à un niveau approfondi – est enterrée sous un travail de provisionnement répétitif.

Lorsque le branchement est en libre-service et que la gouvernance est automatique, ce travail répétitif disparaît. Les développeurs provisionnent leurs propres environnements en une seconde. Les modifications de schéma sont examinées de manière asynchrone dans les pull requests – le DBA voit un diff de schéma formaté publié par CI, l'examine à son propre rythme et approuve ou demande des modifications via le flux de travail PR normal. Avec le temps maintenant disponible, ces revues vont plus loin : le DBA aide les membres de l'équipe à comprendre les données et les structures existantes en production, travaille avec eux pour trouver de meilleures solutions et effectue des revues approfondies qui respectent les normes d'intégrité des données et de gouvernance. Le masquage des données est appliqué par politique, pas par intervention manuelle. L'attribution des coûts est automatique, pas un exercice de réconciliation mensuel.

Ce qui s'ouvre, c'est le travail qui exploite réellement l'expertise du DBA : définir les politiques de branchement, concevoir les règles de gouvernance, architecturer les flux de promotion, optimiser les performances et établir les garde-fous qui rendent le libre-service sûr. Le DBA passe de l'exécution du travail à la conception de la manière dont le travail est effectué – de plus de 30 tickets opérationnels par sprint à moins de 5 revues de politiques de grande valeur. La piste d'audit démontrée ci-dessus n'est pas seulement un artefact de conformité – c'est le nouveau tableau de bord stratégique du DBA, une vue en temps réel de la manière dont la plateforme est utilisée et où investir ensuite.

Du changement de rôle à l'outillage

Le pivot du DBA des tickets opérationnels vers la conception de la plateforme ne fonctionne que si l'outillage évolue avec le rôle. La plateforme doit effectuer le travail de routine par elle-même, et le DBA a besoin d'un endroit pour concevoir la manière dont ce travail est effectué.

Deux outils open-source, tous deux déployés en tant qu'applications Databricks et tous deux régis par les mêmes octrois Unity Catalog et la même piste d'audit décrits ci-dessus, bouclent la boucle.

LakebaseOps est ce que la plateforme fait par elle-même. Trois agents – Provisionnement, Performance et Santé – remplacent 51 des tâches pour lesquelles un DBA déposait auparavant des tickets. Sept d'entre eux s'exécutent en tant que tâches Databricks planifiées et remplacent le crontab pg_cron qu'un DBA maintiendrait autrement manuellement. Une interface de surveillance présente les métriques pg_stat en direct, les régressions de requêtes lentes, l'application du TTL de branche et un tableau de bord d'adoption de 9 KPI. Un assistant de migration évalue dix moteurs sources (Aurora, RDS, Cloud SQL, AlloyDB, Cosmos DB, et plus) par rapport à Lakebase, avec des prix en direct des API AWS et Azure.

Lakebase MCP est ce que le DBA fait par-dessus la plateforme. Un serveur Model Context Protocol exposant 46 outils à tout agent IA compatible MCP (Claude, Copilot, GPT). Le DBA arrête d'ouvrir pgAdmin et commence à décrire l'intention :

Deux choix de conception maintiennent la sécurité. Premièrement, une gouvernance à double couche : un garde-fou d'instruction SQL et un garde-fou d'accès par outil, avec quatre profils pré-construits (lecture seule, analyste, développeur, administrateur) qui correspondent aux mêmes modèles d'accès UC montrés ci-dessus. Un assistant de codage s'exécute en tant que read_only et ne peut physiquement pas supprimer une table.

Deuxièmement, chaque requête est attribuable – le serveur étiquette chaque instruction avec l'outil d'origine :

Combiné avec l'attribution des coûts au niveau de la branche montrée précédemment, vous pouvez répondre "quel agent sur quelle branche a généré le pic de CPU de 4h du matin ?" en une seule requête SQL.

LakebaseOps s'exécute pour l'équipe. Lakebase MCP s'exécute avec l'équipe. Les deux héritent de la posture de gouvernance que vous venez de voir.

Dans la partie 3 de cette série, nous examinerons le bénéfice ultime : prendre les données de propriété de l'infrastructure à l'intérieur de Backstage et les joindre directement aux données de facturation cloud dans une seule requête SQL.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original