Ein Context Layer für Databricks

Ein Context Layer für Databricks ist die gesteuerte Schicht fachlicher Bedeutung, also Definitionen, Beziehungen, Lineage und Richtlinien, die aus den Daten in Ihrem Databricks Lakehouse etwas macht, das KI-Agenten verstehen und dem sie trauen können. Databricks stellt dafür mit Unity Catalog, seiner einheitlichen Governance-Schicht für Daten und KI, ein starkes natives Fundament bereit. Zu verstehen, was Unity Catalog leistet und wo ein Context Layer über eine einzelne Plattform hinausreichen muss, ist der Kern davon, KI im Unternehmen auf Databricks-Daten zu erden.

Das zählt, weil viele Organisationen auf Databricks sowohl ihre Daten als auch ihre KI betreiben und das Muster des Lakehouse strukturierte Tabellen, Dateien, ML-Features und Modelle an einem Ort mischt. Ein KI-Agent, der über dieser Landschaft arbeitet, muss wissen, was die Daten fachlich bedeuten, ob ihnen zu trauen ist und wie sie zusammenhängen, also Kontext, den das rohe Lakehouse von sich aus nicht liefert. Ein Context Layer liefert ihn, und der nützlichste spannt sich über Databricks und die übrigen Systeme, auf die das Geschäft angewiesen ist.

Ein Context Layer für Databricks

Innerhalb von Databricks heißt Context Layer, die Bestände des Lakehouse, also Tabellen, Views, ML-Features und Modelle, mit den Metadaten zu umgeben, die ihnen Bedeutung und Vertrauen geben: fachliche Definitionen für jede Kennzahl und jeden Begriff, eine Lineage, die zeigt, wie Daten durch Notebooks und Pipelines geflossen sind, die Klassifizierung sensibler Daten und die Zugriffsrichtlinien. Damit kann ein KI-Agent, der das Lakehouse abfragt, Ergebnisse richtig deuten und innerhalb der Governance bleiben, statt aus technischen Namen zu improvisieren.

Databricks hat Governance mit Unity Catalog nativ verankert statt nachträglich angebaut, und deshalb beginnt jede Diskussion über einen Context Layer für Databricks genau dort.

Databricks Unity Catalog

Unity Catalog ist die einheitliche Governance-Schicht, die in Databricks eingebaut ist; einmal aktiviert, arbeitet sie unter jeder Dateninteraktion und setzt die Zugriffskontrolle durch, verfolgt die Lineage und protokolliert Aktivität automatisch. Seine Fähigkeiten decken sich eng mit den Fundamenten eines Context Layer:

• Einheitliche Governance für Daten und KI. Ein Governance-Modell über Tabellen, Dateien, ML-Features und Modelle hinweg, mit eingebauter Zugriffskontrolle und eingebautem Auditing.
• Automatische Lineage auf Spaltenebene. Durchgängige Lineage von der Quelle bis ins Dashboard, was Folgenabschätzung und Audits der KI vereinfacht, und die externe Lineage (Preview) erweitert den Graphen auf vorgelagerte Quellen (etwa Salesforce, MySQL) und nachgelagerte Werkzeuge (etwa Tableau, Power BI).
• Auffindbarkeit, Qualität und Sharing. Eine einheitliche Sicht auf Daten- und KI-Bestände, mit Auffindbarkeit, Qualität und gesteuertem Sharing.
• Open Source. Databricks hat Unity Catalog im Juni 2024 unter der Linux Foundation quelloffen gestellt; das OSS-Projekt ist API-kompatibel mit dem verwalteten Dienst und arbeitet mit Apache Spark, Trino, Apache Iceberg, DuckDB und weiteren zusammen.

Das ist ein starkes und zunehmend offenes Governance-Fundament für Daten und KI innerhalb von Databricks.

Genie und der Bedarf an Kontext

Am schärfsten zeigt sich der Bedarf an einem Context Layer auf Databricks bei KI-Funktionen wie Databricks AI/BI Genie, mit dem Nutzer ihre Daten in natürlicher Sprache befragen können. Genie ist, wie jede Schnittstelle von natürlicher Sprache zu Daten, nur so genau wie der fachliche Kontext dahinter: Es muss wissen, was „aktiver Kunde“ bedeutet, welche Tabelle die maßgebliche ist und wie Kennzahlen definiert sind, sonst liefert es selbstbewusste, aber falsche Antworten. Unity Catalog stellt die technische Governance und die Lineage bereit; was fehlt, ist die kuratierte fachliche Bedeutung, also die Definitionen aus dem Glossar und die Beziehungen, mit denen eine KI eine Frage in natürlicher Sprache auf die richtigen, vertrauenswürdigen Daten abbildet. Genau diese fachliche Schicht legt ein Context Layer über Unity Catalog.

Die Lücke: über Databricks hinaus

Unity Catalog steuert Databricks gut, und sein Weg in Open Source und die externe Lineage schieben ihn nach außen, doch ein vollständiger Context Layer muss weiterhin zwei Dinge adressieren, die ein plattformzentrierter Katalog nur teilweise abdeckt:

• Kuratierte fachliche Bedeutung. Unity Catalog ist stark in technischer Governance und Lineage; die kuratierten fachlichen Definitionen, das Glossar und der von Menschen verantwortete Kontext, den KI zum Deuten der Daten braucht, müssen weiterhin bewusst darübergelegt und gesteuert werden.
• Die ganze Landschaft, und jeder Agent. Die meisten Unternehmen betreiben auch Snowflake, dbt, BI-Werkzeuge und operative Systeme; ein fachlicher Begriff und seine Lineage spannen sich oft über sie alle. Und KI-Agenten, die nicht nativ zu Databricks gehören, brauchen gesteuerten Kontext über einen offenen Standard, das Model Context Protocol.

Bleibt das unadressiert, wird jedes Werkzeug zu einer Kontextinsel, dem Gegenstück der Datensilos, die Unternehmen in den 2000er-Jahren bekämpft haben, nur in der Ära der KI: Databricks kennt seinen Ausschnitt, Snowflake kennt seinen, und kein Agent sieht das Ganze. Der vollständige Context Layer spannt sich über diese Inseln, also über Databricks und alles darum herum, mit kuratierter fachlicher Bedeutung obenauf.

Wie Dawiso dazu passt

Dawiso ist der plattformübergreifende, fachlich denkende Context Layer, der die Lücken schließt, die Unity Catalog lässt, mit Databricks als erstklassiger Quelle darin und nicht als Wettbewerber. Es verbindet sich mit Databricks und über 40 weiteren Plattformen und ergänzt über der nativen Governance das, was KI braucht:

• Kuratierte fachliche Bedeutung. Das Business Glossary definiert jeden Begriff einmal, über Databricks und alles andere hinweg, und verwandelt das Wissen aus Wikis und Köpfen in gesteuerten Kontext.
• Plattformübergreifend, durchgängig gesteuert. Die interaktive Data Lineage verfolgt die Flüsse von den Quellsystemen über dbt ins Lakehouse und hinaus in die BI und führt die technische Lineage von Unity Catalog zusammen, statt sie zu verdoppeln, während Klassifizierung und Richtlinien über die ganze Landschaft hinweg einheitlich bleiben, statt am Rand des Workspace zu enden.
• Jedem Agenten zugestellt, über offenes MCP. Der Context Layer stellt diesen gesteuerten Kontext jedem KI-Agenten und jedem Copilot über den offenen MCP Server zu.

Unity Catalog steuert das Lakehouse weiterhin nativ; Dawiso gibt Ihrer KI den kuratierten, plattformübergreifenden fachlichen Kontext, den ein Katalog für eine einzelne Plattform nicht liefern kann, also den Unterschied zwischen einem Agenten, der Databricks versteht, und einem, der Ihr Geschäft versteht.

Fazit

Ein Context Layer ist das, was Databricks-Daten in etwas verwandelt, dem KI trauen kann, und Databricks hat mit Unity Catalog ein starkes, zunehmend offenes Fundament gebaut: einheitliche Governance, Lineage auf Spaltenebene und eine externe Lineage, die über das Lakehouse hinausreicht. Was bleibt, ist die fachliche Bedeutung, die KI zum Deuten dieser Daten braucht, und der Umstand, dass das Geschäft auf mehr als einer Plattform läuft. Der vollständige Context Layer ergänzt kuratierte Definitionen und Beziehungen über Unity Catalog, führt Databricks mit der übrigen Landschaft zusammen und stellt jedem Agenten, auch Genie, gesteuerten Kontext über offenes MCP zu. Steuern Sie das Lakehouse nativ, und geben Sie Ihrer KI dann den fachlichen Kontext, um es zu verstehen.