Hinter den Kulissen mit Lakebase, Teil 2

In Teil 1 dieser Serie haben wir untersucht, wie die Verlagerung der zugrunde liegenden Backstage-Datenbank zu Databricks Lakebase riskante Schema-Migrationen in 1-Sekunden-Branch-and-Test-Operationen verwandelte. Ein schnellerer Entwicklungszyklus bringt Sie jedoch nur bedingt weiter, wenn Sicherheits- und Governance-Teams Ihre operative Datenbank immer noch wie eine Black Box behandeln.

In einem traditionellen Stack leben Ihre Anwendungsdatenbank und Ihr Data Lake in zwei völlig unterschiedlichen Sicherheitsparadigmen. Der Besitzgraph für Ihre Infrastruktur befindet sich in Backstage, gestützt durch eine isolierte RDS-Instanz und gesteuert durch komplexe IAM-Rollen und native Postgres-Berechtigungen. Währenddessen werden Ihre Warehouse-Daten vom Datenteam mithilfe von Unity Catalog verwaltet. Unity Catalog ist ein von Databricks entwickeltes Open-Source-Framework, das eine vereinheitlichte Governance-Schicht für Daten, AI und jetzt auch für operative Datenbanken bietet – ein einziger Ort zur Verwaltung von Zugriffssteuerungen, Audit-Trails, Lineage und Compliance für alles auf der Plattform.

Um einen einzelnen Tabellen-Drop auf RDS zu prüfen, müssten Sie CloudTrail für den IAM-Principal, pg_stat_activity oder pgaudit Logs für die SQL-Anweisung und CloudWatch für den Zeitstempel abgleichen – drei Dienste, drei Abfragesprachen, drei Zugriffsrichtlinien. Die operative Datenbank wird zu einem Compliance-Seitenkanal.

Unity Catalog integriert die operative DB

Als wir Backstage auf Lakebase ausrichteten, änderten wir nicht nur, wo die Daten lebten; wir änderten, wo die Zugriffsrichtlinie lebte.

Da Lakebase nativ in Databricks eingebettet ist, erstreckt sich Unity Catalog direkt über die operative Postgres-Datenbank. In diesem POC haben wir Lakehouse Federation verwendet, um den Backstage-Katalog als Fremdkatalog (lakebase_bs) in Unity Catalog verfügbar zu machen. Sobald er dort ist, steuern Standard-UC-Berechtigungen, wer was sehen kann, ohne dass eine Rollenverwaltung auf Postgres-Ebene erforderlich ist:

Obwohl wir in diesem POC keine End-to-End-Row-Level-Security-Richtlinien für Backstage erstellt haben, können architektonisch die exakt gleichen RLS-Regeln, die sensible Abrechnungstabellen schützen, direkt auf diese operativen Tabellen angewendet werden. Die Trennwand zwischen „operativ“ und „analytisch“ hört auf, eine physische Grenze zu sein, und wird einfach zu einem Zugriffsmuster.

Ein vereinheitlichter Audit-Trail Out-of-the-Box

Erinnern Sie sich an das 1-Sekunden-Copy-on-Write-Branching, das wir in Teil 1 durchgeführt haben? In einem traditionellen Setup ist es eine manuelle Übung, einem Sicherheitsingenieur zu beweisen, dass ein Entwickler die Datenbank nur für eine Stunde gebrancht und dann zerstört hat.

Mit Lakebase wird jede Control-Plane-Aktion gegen die operative Datenbank automatisch in system.access.audit aufgezeichnet. Um dies zu beweisen, haben wir das Audit-Log nach den genauen Branch-Operationen aus unserem Disaster-Recovery-Experiment in Teil 1 abgefragt:

Ergebnis:

Jede Branch-Erstellung und -Löschung aus unseren Experimenten in Teil 1 wird protokolliert. Jedes Ereignis ist an eine spezifische OAuth-Benutzeridentität und Quell-IP gebunden, wird automatisch erfasst und unterliegt den exakt gleichen Row-Level-Security-Kontrollen wie jede andere Audit-Tabelle in Unity Catalog. Kein CloudTrail-Abgleich. Kein RDS-Log-Parsing. Eine SQL-Abfrage.

Automatisierte Kostenattribution nach Branch

Ein Governance-Team möchte nicht nur wissen, wer einen Branch erstellt hat, sondern auch, was er gekostet hat.

In einer traditionellen AWS-Umgebung erfordert die Nachverfolgung der Kosten einer kurzlebigen RDS-Instanz benutzerdefinierte CloudWatch-Tagging-Strategien, die oft kurzlebige Workloads übersehen. Da Lakebase nativ in die Systemabrechnungstabellen von Unity Catalog integriert ist, werden die Compute-Kosten automatisch nach project_id, branch_id und endpoint_id aufgeschlüsselt.

In diesem POC wurde der Produktions-Branch mit 31.6130 DBU abgerechnet, während der gelöschte Test-Branch unabhängig mit 0.0107 DBU zugeschrieben wurde. Der Audit-Trail und der Kosten-Trail werden am exakt selben Ort verwaltet.

Was das für Teams bedeutet, die täglich Branches erstellen

Unsere Governance-Geschichte beantwortet die Compliance-Frage: Können wir beweisen, wer was wann getan hat und was es gekostet hat? Die Antwort ist ja – eine SQL-Abfrage statt drei Diensten. Aber es gibt eine zweite Governance-Frage, die für Entwicklungsteams, die den Branching-Workflow aus Teil 1 übernehmen, genauso wichtig ist: Was passiert mit der Governance, wenn Ihr Team Dutzende von Branches pro Sprint erstellt?

In Teil 1 haben wir einen Workflow beschrieben, bei dem jeder Feature-Branch und jeder Pull-Request eine eigene isolierte Datenbankkopie erhält. Ein Team von sechs Entwicklern, das zweiwöchige Sprints durchführt, könnte in einem einzigen Sprint 30-40 Branches erstellen und zerstören. Das sind 30-40 Kopien von Produktionsdaten, von denen jede potenziell sensible Felder enthalten kann – Kunden-PII, Finanzdaten, Gesundheitsdaten.

Hier wird die Branch-Level-Governance von Unity Catalog tragend, nicht nur bequem. Wenn ein Lakebase-Branch erstellt wird, werden die Attribut-Level-Maskierungsrichtlinien von Unity Catalog automatisch auf den neuen Branch übertragen. Ein Entwickler, der an seinem Feature-Branch arbeitet, sieht niemals unmaskierte Produktionsdaten – nicht, weil jemand daran gedacht hat, es zu konfigurieren, sondern weil die Governance-Schicht dies zum Zeitpunkt der Erstellung durchsetzt. Der CI-Branch, der Ihre PR-Tests ausführt, wird identisch zur Produktion verwaltet. Der QA-Branch, in dem ein Tester destruktive Szenarien ausführt, wird identisch zur Produktion verwaltet. Es gibt keine „Nicht-Produktions-Ausnahme“, bei der sensible Daten durchsickern, weil jemand vergessen hat, die Richtlinie anzuwenden.

Dies ist wichtiger, als es scheinen mag. Laut dem Perforce-Bericht „2025 State of Data Compliance“ haben 60 % der Organisationen Datenschutzverletzungen oder Diebstähle in Nicht-Produktionsumgebungen erlebt, in denen sensible Daten unzureichend anonymisiert wurden. Der traditionelle Ansatz – manuelle Maskierung von Daten bei der Bereitstellung von Entwicklungs-/Testumgebungen – skaliert nicht, wenn Umgebungen in Sekunden erstellt und zerstört werden. Governance muss automatisch erfolgen, sonst findet sie nicht statt.

Die neue Chance des DBA

Der Audit-Trail und die Kostenattributionsdaten signalisieren auch eine leisere Verschiebung: Die Rolle des DBA entwickelt sich von reaktiver Ticketarbeit hin zu strategischer Plattformarchitektur.

Heute fließt ein Großteil der Zeit eines DBA in operative Anfragen – Umgebungsbereitstellung, Schemaüberprüfungen, Datenaktualisierungen, Zugriffsberechtigungen. Ein sechsköpfiges Entwicklerteam kann über 30 Tickets pro Sprint generieren, und der Kalender des DBA wird zu einer Warteschlange. Das Fachwissen, das DBAs wertvoll macht – ein tiefes Verständnis von Datenintegrität, Performance und Governance – wird unter sich wiederholenden Bereitstellungsarbeiten begraben.

Wenn Branching als Self-Service erfolgt und die Governance automatisch ist, entfällt diese sich wiederholende Arbeit. Entwickler stellen ihre eigenen Umgebungen in einer Sekunde bereit. Schemaänderungen werden asynchron in Pull-Requests überprüft – der DBA sieht einen formatierten Schema-Diff, der von CI gepostet wurde, überprüft ihn nach eigenem Zeitplan und genehmigt oder fordert Änderungen über den normalen PR-Workflow an. Mit der nun verfügbaren Zeit gehen diese Überprüfungen tiefer: Der DBA hilft Teammitgliedern, die vorhandenen Daten und Strukturen in der Produktion zu verstehen, arbeitet mit ihnen zusammen, um bessere Lösungen zu finden, und führt gründliche Überprüfungen durch, die die Datenintegrität und Governance-Standards aufrechterhalten. Datenmaskierung wird durch Richtlinien erzwungen, nicht durch manuelles Eingreifen. Die Kostenattribution erfolgt automatisch, nicht als monatliche Abstimmungsübung.

Was sich dadurch eröffnet, ist die Arbeit, die das Fachwissen des DBA tatsächlich nutzt: das Definieren von Branching-Richtlinien, das Entwerfen von Governance-Regeln, das Architektieren von Promotion-Workflows, das Optimieren der Performance und das Festlegen der Leitplanken, die Self-Service sicher machen. Der DBA verlagert sich von der Ausführung der Arbeit zum Entwurf, wie die Arbeit erledigt wird – von über 30 operativen Tickets pro Sprint zu weniger als 5 hochwertigen Richtlinienüberprüfungen. Der oben gezeigte Audit-Trail ist nicht nur ein Compliance-Artefakt – er ist das neue strategische Dashboard des DBA, eine Echtzeitansicht, wie die Plattform genutzt wird und wo als Nächstes investiert werden sollte.

Vom Rollenwechsel zur Tooling

Der Wandel des DBA von operativen Tickets zum Plattformdesign funktioniert nur, wenn sich das Tooling mit der Rolle verschiebt. Die Plattform muss die Routinearbeit selbst erledigen, und der DBA braucht einen Ort, um zu gestalten, wie diese Arbeit erledigt wird.

Zwei Open-Source-Tools, beide als Databricks Apps bereitgestellt und beide durch dieselben Unity Catalog Berechtigungen und den oben beschriebenen Audit-Trail geregelt, schließen diese Lücke.

LakebaseOps ist das, was die Plattform eigenständig erledigt. Drei Agenten – Provisioning, Performance und Health – ersetzen 51 der Aufgaben, für die ein DBA früher Tickets einreichen musste. Sieben davon laufen als geplante Databricks Jobs und ersetzen den pg_cron Crontab, den ein DBA sonst manuell pflegen müsste. Eine Überwachungs-UI zeigt Live-pg_stat-Metriken, Slow-Query-Regressionen, Branch-TTL-Erzwingung und ein 9-KPI-Adoptions-Dashboard an. Ein Migrationsassistent bewertet zehn Quell-Engines (Aurora, RDS, Cloud SQL, AlloyDB, Cosmos DB und mehr) gegen Lakebase, mit Live-Preisen von den AWS- und Azure-APIs.

Lakebase MCP ist das, was der DBA auf der Plattform tut. Ein Model Context Protocol Server, der 46 Tools für jeden MCP-fähigen AI-Agenten (Claude, Copilot, GPT) bereitstellt. Der DBA hört auf, pgAdmin zu öffnen, und beginnt, die Absicht zu beschreiben:

Zwei Designentscheidungen sorgen für Sicherheit. Erstens, zweischichtige Governance: ein SQL-Statement-Guard und ein pro-Tool-Zugriffs-Guard, mit vier vorgefertigten Profilen (read_only, analyst, developer, admin), die auf dieselben oben gezeigten UC-Zugriffsmuster abgebildet werden. Ein Coding Assistant läuft als read_only und kann physisch keine Tabelle löschen.

Zweitens ist jede Abfrage zuordenbar – der Server kennzeichnet jede Anweisung mit dem Ursprungstool:

In Kombination mit der zuvor gezeigten Kostenattribution auf Branch-Ebene können Sie mit einer einzigen SQL-Abfrage beantworten: "Welcher Agent auf welchem Branch hat den CPU-Spike um 4 Uhr morgens verursacht?"

LakebaseOps läuft für das Team. Lakebase MCP läuft mit dem Team. Beide übernehmen die Governance-Haltung, die Sie gerade gesehen haben.

In Teil 3 dieser Serie werden wir uns den ultimativen Nutzen ansehen: die Infrastruktur-Eigentumsdaten in Backstage zu nehmen und sie direkt mit Cloud-Abrechnungsdaten in einer einzigen SQL-Abfrage zu verknüpfen.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag