--- title: "Was Dawiso zu Databricks Unity Catalog hinzufügt | Dawiso Blog" description: "Dawiso ist validierter Partner von Databricks. So erweitern Access Gate, ein tieferer Scanner für Metadaten, das Rückschreiben und MCP den Unity Catalog." url: "https://www.dawiso.com/de/blog-post/dawiso-databricks-unity-catalog" language: "de" --- # Wie Dawiso Databricks Unity Catalog erweitert, vom Access Gate bis zum geregelten Kontext für KI Samuel Nagy VP of Strategic Growth \7. September 2026 Databricks regelt Daten innerhalb von Databricks ausgesprochen gut. Was Unity Catalog Ihnen überlässt, ist der Prozess darum herum: wie eine Person oder ein Agent tatsächlich Zugriff auf ein Datenprodukt erhält, und der fachliche Kontext, der die Daten danach nutzbar macht. Dawiso ist validierter Partner von Databricks und einer der ersten Kataloge im MCP Marketplace von Databricks. Hier sind die vier Stellen, an denen sich die beiden Produkte treffen. ## Das Access Gate, von der Anfrage bis zum bereitgestellten Zugriff Das Access Gate ist der Teil der [Dawiso Data Product Platform](https://www.dawiso.com/de/product/data-products-platform), der die **Genehmigung des Zugriffs auf Datenprodukte** übernimmt. Jemand findet ein Datenprodukt im Katalog und fragt Zugriff darauf an. Von da an steuert das Access Gate den ganzen Prozess, von der Genehmigung selbst bis zur **automatischen Vergabe des Zugriffs auf der Plattform, auf der die Daten tatsächlich liegen**. Für Kunden von Databricks heißt das: Die Berechtigung landet in Databricks, ohne dass jemand dafür einen Workspace öffnen muss. Diesen Teil lohnt es sich am meisten zu verstehen, denn er sitzt genau dort, wo [Unity Catalog](https://www.dawiso.com/de/glossary/databricks-unity-catalog) aufhört. Unity Catalog setzt eine Berechtigung gut durch. Die Entscheidung dahinter fällt aber woanders, meist an einem Ort mit viel weniger Governance, in einer Ticket-Warteschlange, einer Tabelle mit Genehmigungen oder im Postfach eines Data Stewards, und Unity Catalog sieht immer nur das Ergebnis. Nichts in der Plattform hält fest, wer gefragt hat, wer genehmigt hat, zu welchem Zweck und wann der Zugriff ablaufen soll. Der Zugriff auf ein Datenprodukt ist eine geschäftliche Entscheidung. Im Access Gate wird diese Entscheidung getroffen, festgehalten und in eine Berechtigung umgesetzt. Weil die Anfrage in Dawiso an ein [Datenprodukt](https://www.dawiso.com/de/product/data-products) gerichtet wird und nicht an einen nackten Tabellennamen, hängt alles, was die genehmigende Person braucht, bereits daran. Das Produkt trägt eine [verantwortliche Person](https://www.dawiso.com/de/glossary/data-ownership), eine Klassifizierung, eine fachliche Definition und die Lineage, die zeigt, woher die Daten stammen. Die verantwortliche Person kann auf dieser Grundlage genehmigen, statt die Frage an das Datenteam weiterzuleiten und zu hoffen, dass jemand die Tabelle erkennt. Dasselbe Gate dient **Menschen wie KI-Agenten**. Ein Agent, der einen Datensatz braucht, fragt ihn genauso an wie ein Mensch, über denselben Genehmigungsweg und mit demselben hinterlassenen Nachweis. Das wird jedes Quartal wichtiger, denn die Zahl der nicht menschlichen Nutzer in einer Databricks-Umgebung wächst schneller als die der menschlichen, und ein Agent, der unter einem gemeinsamen Service Principal läuft, ist für jede Überprüfung von Zugriffen unsichtbar. Was am anderen Ende herauskommt, ist ein Nachweis. Eine Anfrage, eine Genehmigung und ein Eintrag, den Prüfer für [DSGVO](https://www.dawiso.com/de/glossary/gdpr), [DORA](https://www.dawiso.com/de/glossary/dora-digital-operational-resilience-act) oder [NIS2](https://www.dawiso.com/de/glossary/nis2-directive) lesen können, ohne ihn über drei Systeme hinweg rekonstruieren zu müssen. So sieht [Zugriffsmanagement für Daten](https://www.dawiso.com/de/glossary/data-access-management) aus, wenn der Katalog an der Entscheidung beteiligt ist, statt erst danach benachrichtigt zu werden. ## Ein Scanner, der über Tabellen und Views hinaussieht Ein Databricks-Konto hat zwei Achsen, und ein Scan, der nur einer davon folgt, sieht das halbe Bild. Auf der einen Seite steht der Metastore von Unity Catalog mit Katalogen, Schemas, Tabellen und Views. Auf der anderen Seite stehen die **Workspaces**, und ein Workspace kann aus mehreren Katalogen lesen. Einige der Objekte, die für das Geschäft am wichtigsten sind, hängen am Workspace statt am Katalog. Ein Scan nur des Metastores deckt die erste Achse ab. Der Databricks-Scanner von Dawiso liest beide. Neben Katalogen, Schemas, Tabellen und Views übernimmt er auch **ML-Modelle**, Constraints von Tabellen, Tags von Unity Catalog, Spaltenmasken, Zeilenfilter und die Klassifizierung von Daten, externe Speicherorte und Zugangsdaten für Speicher, **AI/BI-Dashboards samt ihren Datasets** und **Genie Agents samt ihren Beispielabfragen**. Die letzten beiden entscheiden darüber, ob die Governance die Menschen erreicht, die die Daten tatsächlich nutzen. Ein Dashboard ist ein geregelter Datenbestand wie jeder andere, und liegt es außerhalb des Rahmens der Governance, endet jede Wirkungsanalyse einen Schritt vor der Person, die den Schaden tatsächlich bemerken wird. Genie Agents, die Databricks Genie Spaces nannte, bis es sie [2026 umbenannte und erweiterte](https://www.databricks.com/blog/introducing-genie-one-genie-ontology-and-genie-agents), sind kuratierte Sichten auf Daten, die Menschen in natürlicher Sprache abfragen. Ein Agent, der fachliche Fragen beantwortet, gehört in denselben Katalog wie die Tabellen, aus denen er antwortet. So sieht das auf beiden Seiten aus. Im Workspace von Databricks sitzen Dashboards und Genie Agents in der Seitenleiste neben dem SQL-Editor und den Modellen, ganz getrennt vom Baum des Katalogs. Und hier ist einer dieser Genie Spaces nach einem Scan durch Dawiso, im Baum des Katalogs neben Tabellen, Views und ML-Modellen. Der Scan übernimmt seine Beschreibung, seine Beispielabfragen und seine Diagramme und gibt ihm **eigene Felder für die Zuständigkeit**, sodass dem Agenten selbst ein Data Owner und ein Data Steward zugewiesen werden können. Dawiso bezeichnet diese weiterhin als Genie Spaces, den Namen, den Databricks vor der Umbenennung verwendete. Die Lineage stammt aus den Lineage-Ereignissen in `system.access` von Unity Catalog, mit zwei Einstellungen, die sich abzustimmen lohnen. Ein Zeitfenster für die Lineage bestimmt, wie weit der Scan in die Vergangenheit liest, und ein Umfang für den Workspace entscheidet, ob Dawiso Ereignisse nur aus dem verbundenen Workspace oder aus dem ganzen Metastore übernimmt. Ein kurzes Fenster scannt schneller, ein längeres erfasst auch die Pipeline, die einmal im Monat läuft. Skalierung ist die andere Hälfte beim Scannen. Die Ingestion von Dawiso ist dafür gebaut, **Millionen von Objekten** zu laden und sie in großen Mengen zu aktualisieren, ohne den Bereich der Metadaten zu sperren, in dem gerade gearbeitet wird. Die Scanner laufen in der Cloud von Dawiso, oder Sie betreiben sie als Kommandozeilenwerkzeuge in Ihrem eigenen Netzwerk und schicken die Metadaten hinaus, was eine Bank oder eine Versicherung meist braucht. Beide Betriebsarten lassen sich je Quellsystem kombinieren. ## Gepflegt in Dawiso, zurückgeschrieben in Unity Catalog Scannen ist die eine Richtung. Die interessantere ist der Rückweg. Zuständigkeit, Klassifizierung nach DSGVO und Sicherheit sowie fachliche Metadaten lassen sich **in Dawiso pflegen und in Unity Catalog zurückschreiben**, sodass das kuratierte Ergebnis in Databricks selbst erscheint. Technisch schreibt eine Automatisierungsaktion in Dawiso den Wert in die Spalte von Databricks, entweder als **Tag** von Unity Catalog oder als **Property**, unter einem Schlüssel Ihrer Wahl. Eine in Dawiso gepflegte Sicherheitsklassifizierung kann in Unity Catalog etwa als `dawiso_security_classification` ankommen, und von da an sind es gewöhnliche Metadaten von Unity Catalog, die Richtlinien und Abfragen in Databricks lesen können. Das Ziel ist der Reiter Overview der Tabelle im Catalog Explorer, der Bildschirm, den ein Data Engineer ohnehin offen hat. Owner, Tags und Klassifizierung stehen dort alle nebeneinander, neben dem Block Quality und den Richtlinien. Das bringt Ihnen eine saubere Arbeitsteilung. Der fachlich Verantwortliche arbeitet in Dawiso, in einer Oberfläche für Menschen, die kein SQL schreiben, mit Unterstützung durch KI beim Entwerfen von Definitionen und beim Klassifizieren von Datenbeständen. Der Data Engineer muss nie nachsehen, denn die Antwort steht bereits an der Spalte in Databricks. **Dawiso will die Governance von Unity Catalog innerhalb von Databricks nicht ersetzen.** Es erweitert sie auf die Fachbereiche, denen die Bedeutung gehört, und schreibt das Ergebnis dann dorthin zurück, wo die Engineers ohnehin arbeiten. ## Databricks führt die Prüfungen aus, Dawiso zeigt sie dem Fachbereich Databricks hat eine eigene Funktion für die Datenqualität, [Data Quality Monitoring](https://docs.databricks.com/aws/en/data-governance/unity-catalog/data-quality-monitoring), deren Profiling der Daten früher Lakehouse Monitoring hieß. Sie ist der Block Quality auf demselben Reiter Overview, wird je Tabelle eingeschaltet, und ihre Erkennung von Anomalien, die den normalen Rhythmus der Commits und die Zeilenzahlen einer Tabelle lernt, um veraltete oder unvollständige Daten zu melden, [erreichte im Februar 2026 die öffentliche Vorschau](https://docs.databricks.com/aws/en/release-notes/product/2026/february). Darüber hinaus können Sie eigene Metriken für die Prüfungen festlegen, die Ihr Fachgebiet braucht. Dawiso bindet diese Funktion ein, statt mit ihr zu konkurrieren. **Die Prüfungen laufen auf der Rechenleistung von Databricks**, mit dem Rahmenwerk und den Regeln, die Sie bereits haben. Dawiso verfolgt die Ergebnisse auf der Ebene der Metadaten, neben der Definition, dem Owner und der Klassifizierung des Datenbestands, zu dem sie gehören, und macht daraus **Dashboards, die ein fachlich Verantwortlicher tatsächlich lesen kann**. Die praktische Folge ist ein Posten, den Sie nicht kaufen müssen. Die Verbindung der nativen Engine von Databricks mit einer Oberfläche für die Fachbereiche gibt Analysten und Data Owners eine klare Antwort darauf, welchen Datenbeständen man trauen kann, ohne ein drittes Werkzeug für die Datenqualität und einen dritten Satz Zugangsdaten. ## Geregelter Kontext für Genie Agents über MCP Im Mai 2026 wurde Dawiso [im MCP Marketplace von Databricks gelistet](https://www.dawiso.com/de/news/dawiso-joins-databricks-marketplace-as-mcp-provider-for-data-catalog), als eines der ersten unabhängigen Werkzeuge außerhalb der ursprünglichen Startpartner, das zugelassen wurde. Databricks ist eine der wenigen Plattformen, die Server für das [Model Context Protocol](https://modelcontextprotocol.io/) nativ in ihren agentischen Abläufen unterstützt, und genau das macht die Integration lohnend, statt eine Übersetzungsschicht anzuflanschen. Alles, was in Dawiso kuratiert ist, lässt sich über den [MCP Server](https://www.dawiso.com/de/product/mcp) an KI-Agenten und KI-Werkzeuge auf Databricks liefern. Fachbegriffe, Datenprodukte, Zuständigkeit und Klassifizierung, all das wird zu Kontext, den ein Agent lesen kann. Für [Genie Agents](https://docs.databricks.com/aws/en/genie-agents/concepts) ist das der Unterschied zwischen einem Agenten, der Ihre Tabellennamen kennt, und einem, der weiß, was Ihr Unternehmen unter „aktiver Kunde“ versteht. Was viele überrascht: Die Verbindung **schreibt ebenso, wie sie liest**. Wenn ein Agent auf Databricks eine Pipeline baut, Daten transformiert oder einen neuen Datenbestand anlegt, kann er diese Arbeit in Dawiso dokumentieren, während sie geschieht, beschränkt auf die Berechtigungen des Nutzers, der ihn ausführt. Beschreibungen, neue Objekte, Fachbegriffe und veröffentlichte Dokumentation werden so zu etwas, zu dem ein Agent beiträgt, statt zu etwas, das ein Mensch später nachträgt. ## Wo Dawiso ins Bild passt Nichts davon verlangt von Databricks, etwas zu sein, das es nicht ist. Unity Catalog bleibt die Governance-Engine für alles innerhalb der Plattform, und zwar eine gute. Dawiso ergänzt die fachliche Schicht darüber, das Access Gate davor und die Reichweite über ihre Ränder hinaus. Dieser letzte Punkt ist meist der Grund, warum das Gespräch überhaupt beginnt. Sehr wenige Landschaften bestehen nur aus Databricks. Die übliche Form ist Databricks plus Power BI oder Microsoft Fabric, mit dbt für die Transformation, einer Datenbank von Oracle oder SAP, die noch das führende System hält, und Confluent, das Ereignisse zwischen ihnen bewegt. Ein Katalog, der zu einer Plattform gehört, kann immer nur seinen eigenen Ausschnitt regeln, und genau das spricht für einen [plattformübergreifenden Context Layer](https://www.dawiso.com/de/glossary/context-layer-for-databricks) und für eine [durchgängige Lineage](https://www.dawiso.com/de/product/interactive-data-lineage), die nicht an der Grenze des Workspace endet. Dieses Argument haben wir ausführlich unter [wie Dawiso Unity Catalog ergänzt](https://www.dawiso.com/de/glossary/databricks-unity-catalog) aufgeschrieben, dort lohnt es sich zu lesen, statt es hier zu wiederholen. Dawiso ist ein validierter Technologiepartner von Databricks, und besonders der Scanner wurde durch Rückmeldungen von Lösungsarchitekten von Databricks aus echten Einführungen geprägt. Wenn Sie sehen wollen, was er liest, was er zurückschreibt und wie der [Databricks-Konnektor](https://www.dawiso.com/de/connectors/databricks) eingerichtet wird, finden Sie dort die Liste der Objekte und die Berechtigungen. Der [Context Layer](https://www.dawiso.com/de/context-layer) ist der Ort, an dem derselbe geregelte Kontext an Ihre [KI-Governance](https://www.dawiso.com/de/solutions/ai-governance) weitergereicht wird. [In Aktion erleben](https://www.dawiso.com/de/connectors/databricks) Eine fachliche Schicht für Ihr Lakehouse Sehen Sie, was der Databricks-Konnektor von Dawiso liest, zurückschreibt und womit er sich verbindet. ### Inhalt Das Access GateEin Scanner, der über Tabellen hinaussiehtZurückgeschrieben in Unity CatalogDatabricks führt die Prüfungen ausGeregelter Kontext über MCPWo Dawiso ins Bild passt ## Mehr zum Thema Lesen Sie weiter und tauchen Sie tiefer in unsere neuesten Beiträge zu Metadatenmanagement und mehr ein: ### [Wo sollten Sie die KI-Agenten bauen, die mit Ihren Daten sprechen?](https://www.dawiso.com/de/blog-post/build-agents-where-your-data-lives) Alle bauen Agenten, die mit Daten sprechen. Bauen Sie sie dort, wo Daten und Rechenleistung ohnehin liegen, und bringen Sie den geregelten Kontext zu ihnen. Weiterlesen ### [Ergibt ein eigenständiger Context Layer im Zeitalter der Ontologie von Genie noch Sinn?](https://www.dawiso.com/de/blog-post/standalone-context-layer-genie-ontology) Databricks Genie Ontology ist ein echter Context Layer. Wozu noch ein eigenständiger? Zwei Gründe: verantwortete Definitionen und Reichweite über Plattformen. Weiterlesen ### [Snowflake Cortex Agents und Semantic Views regeln](https://www.dawiso.com/de/blog-post/snowflake-cortex-agents-semantic-views-dawiso) Dawiso scannt Snowflake Cortex Agents und Semantic Views in eine interaktive Lineage und erzeugt dann geregelte Semantic Views über OSI zurück in Snowflake. Weiterlesen