Databricks Apps: Interne Daten- und KI-Anwendungen direkt auf Databricks betreiben

Bei einer Bestandsaufnahme zeigt sich, dass verschiedene Fachteams mehrere eigene Anwendungen betreiben. Eine Forecast-App läuft auf einer eigenen virtuellen Maschine des Data-Science-Teams. Das Controlling betreibt eine weitere Anwendung in einer eigenen Container-Umgebung. Ein interner KI-Assistent nutzt separat gespeicherte Zugangsdaten, um auf freigegebene Tabellen zuzugreifen. Es gibt weder eine gemeinsame Anmeldung noch eine durchgängige Nachvollziehbarkeit der Datenzugriffe, und welche Nutzer über welche App auf welche Daten zugreifen, lässt sich nur schwer nachvollziehen.

Solche Strukturen entstehen, wenn Teams Anwendungen entwickeln, bevor ein einheitlicher Betriebs- und Bereitstellungsweg festgelegt wurde. Daten und Modelle werden zwar zentral in Databricks verwaltet. Die Anwendung selbst läuft jedoch auf einer separaten Infrastruktur, mit eigenem Hosting, eigener Anmeldung und separat gepflegten Berechtigungen.

Daraus ergeben sich mehrere Fragen:

Können diese Anwendungen direkt auf Databricks betrieben und in das bestehende Berechtigungsmodell eingebunden werden? Verwendet die App die Rechte des angemeldeten Nutzers oder ein gemeinsames technisches Konto? Wann ist eine Anwendung sinnvoller als ein bereits vorhandenes Dashboard? Welche Kosten entstehen und für welche Anwendungen ist der Dienst nicht geeignet?

Databricks Apps stellt eine Benutzeroberfläche direkt auf den vorhandenen Daten und Modellen bereit. Die App lässt sich damit ohne zusätzliche Hosting-Plattform betreiben. Voraussetzung sind jedoch sauber gepflegte Nutzer, Gruppen und Datenberechtigungen.

Databricks Apps eignet sich besonders für interne Anwendungen, die direkt mit zentral verwalteten Daten und Modellen arbeiten. Der Nutzen ist besonders groß, wenn die Anwendung heute noch eigene Zugangsdaten und eine separate Infrastruktur benötigt. Anmeldung, Hosting und ein Teil des Berechtigungsmanagements müssen dann nicht mehr separat betrieben werden.

Besonders geeignet ist der Einsatz unter drei Voraussetzungen:

• Die Nutzer gehören zum Unternehmen und können über die zentrale Databricks-Identität angemeldet werden.
• Die benötigten Daten, Modelle oder KI-Endpunkte liegen bereits in Databricks.
• Es soll kein eigener Webserver und kein separates Login-System betrieben werden.

Nicht geeignet ist der Dienst für öffentliche Anwendungen ohne Databricks-Anmeldung. Auch Anwendungen mit sehr hoher Schreiblast oder besonders strengen Antwortzeitvorgaben sollten separat geprüft werden. Für häufige transaktionale Schreibvorgänge kann eine operative Datenbank wie Lakebase eingesetzt werden: Wie Lakebase als transaktionale, Postgres-basierte Schicht solche Schreib-Workloads direkt auf der Plattform übernimmt, ordnen wir im Überblick zu Lakebase ein. Die App stellt dabei die Oberfläche bereit, Lakebase speichert die Anwendungsdaten, und dauerhafte Einstellungen, Sitzungen oder Bearbeitungsstände können dort gespeichert werden. Für externe Kundenanwendungen bleibt eine separate Webanwendung mit eigener Infrastruktur meist die bessere Lösung.

Die typischen Einsatzfälle liegen vor allem bei internen Werkzeugen: Databricks nennt für den GA-Zeitpunkt über 20.000 gebaute Apps in mehr als 2.500 Organisationen. Typische Einsatzbereiche sind interne Werkzeuge: Oberflächen zur Prüfung und Anpassung von Prognosen, Anwendungen zur Überwachung von Datenqualität, Formulare für Eingaben, Korrekturen und Freigaben, interne KI-Assistenten auf Basis eigener Dokumente und Daten.

Vor der Umsetzung muss festgelegt werden, welche Identität die App für Datenzugriffe verwendet. Databricks Apps kennt zwei Modelle. Diese Entscheidung bestimmt, ob jeder Nutzer nur seine persönlich freigegebenen Daten sieht.

Beim nutzerbezogenen Zugriff gelten die bereits vergebenen Rechte des angemeldeten Nutzers. Die App berücksichtigt dabei Tabellenrechte sowie vorhandene Zeilenfilter und Spaltenmaskierungen. Nutzer sehen in der App nur die Daten, die sie auch außerhalb der App sehen dürfen. Verwendet die App ein gemeinsames technisches Konto, arbeitet sie für alle Nutzer mit denselben Rechten; persönliche Datenrechte greifen dann nicht automatisch.

Beim ersten Aufruf kann der Nutzer aufgefordert werden, die benötigten Zugriffsrechte für die App zu bestätigen. Erst danach greift sie auf die freigegebenen Daten zu. Ein technisches Konto erhält nur die Rechte, die ihm ausdrücklich vergeben wurden. Lese-Rechte auf eine Tabelle, Zugriff auf ein Secret, die Erlaubnis, ein SQL Warehouse oder einen Serving-Endpunkt abzufragen, werden einzeln vergeben. Fehlt eine erforderliche Berechtigung, kann die Anwendung die jeweilige Ressource nicht verwenden. In der Praxis scheitern Apps häufig an fehlenden Rechten auf Tabellen, Warehouses, Secrets oder Modellendpunkte.

Der größte Vorteil ist, dass vorhandene Datenberechtigungen nicht vollständig neu aufgebaut werden müssen. App-Abfragen wenden bestehende Tabellen-Rechte, Zeilen- und Spalten-Sicherheit automatisch an. Passwörter, Tokens und andere Zugangsdaten gehören nicht in den App-Code: Secrets, SQL Warehouses und externe Quellen werden über Unity-Catalog-Verbindungen angebunden und beim Start der App sicher über die Plattform bereitgestellt. Zugriffe auf die App und Änderungen an Berechtigungen laufen in die Audit-Tabellen von Unity Catalog, und über die App-Telemetrie lassen sich Logs, Traces und Metriken in Unity-Catalog-Tabellen schreiben. App-Zugriffe und Änderungen an Rechten können zentral protokolliert und ausgewertet werden: Damit lässt sich nachvollziehen, welcher Nutzer wann über die App auf Daten zugegriffen hat. Anwendung, Betriebsmodell und Governance liegen damit auf einer Plattform: Hosting, Identität, Datenrechte und Protokollierung kommen aus demselben Stack, ohne dass die App Databricks für einen dieser Bausteine verlassen muss. Wie das Berechtigungsmodell darunter aufgebaut ist, zeigen wir im Überblick zu Unity Catalog.

Eine vorgeschriebene Sprache oder ein festes Framework gibt es nicht: Bestehende Anwendungen lassen sich weiterverwenden. Databricks Apps unterstützt verbreitete Python- und JavaScript-Frameworks, darunter Streamlit, Dash, Gradio, Shiny, Flask und FastAPI sowie Node.js und React. Eine vorhandene Streamlit- oder Dash-Anwendung kann damit ohne Umbau auf Databricks laufen, statt auf einem eigenen Server oder in einem Container betrieben zu werden.

Streamlit ist für viele interne Werkzeuge der schnellste Weg, weil sich Datenabfrage, Logik und Oberfläche in wenig Python-Code zusammenfassen lassen. Dash und Shiny eignen sich für analytisch dichtere Oberflächen, Flask, FastAPI und Node.js mit React für Anwendungen mit eigenem Frontend oder eigener API. Maßgeblich ist nicht das Framework, sondern dass Anmeldung, Datenzugriff und Betrieb von der Plattform kommen statt aus selbst gebauter Infrastruktur.

Databricks stellt die benötigte Laufzeitumgebung automatisch bereit: Das Compute wird serverlos bereitgestellt und stundenweise abgerechnet, das Team muss weder Server noch Cluster einrichten und überwachen. Wie dieses Modell Kosten und Betrieb verändert, erklären wir im Überblick zu Serverless auf Databricks.

Die Kosten hängen von der gewählten Instanzgröße und der Betriebsdauer der App ab und werden über den üblichen Databricks-Verbrauch abgerechnet (DBU). Databricks dokumentiert zwei Instanz-Größen mit 0,5 DBU und 1,0 DBU pro Stunde, Medium und Large. Für einfache interne Anwendungen und wenige gleichzeitige Nutzer reicht häufig die kleinere Größe; die größere Instanz verursacht entsprechend höhere Kosten und ist vor allem bei speicherintensiven Anwendungen oder vielen gleichzeitigen Nutzern sinnvoll. Bei Bedarf kann die App auf mehreren Instanzen laufen; jede weitere Instanz erhöht jedoch die laufenden Kosten.