Wichtige Konzepte in Databricks-Apps

In diesem Artikel werden die Kernkonzepte von Databricks-Apps vorgestellt, einschließlich der Struktur von Apps, der Verwaltung von Abhängigkeiten und Zustand, der Funktionsweise von Berechtigungen und der Interaktion von Apps mit Plattformressourcen. Das Verständnis dieser Konzepte hilft beim Entwickeln, Bereitstellen und Verwalten von Apps in Ihrem Arbeitsbereich.

App

Eine Databricks-App ist eine Webanwendung, die als containerisierter Dienst auf der serverlosen Azure Databricks-Plattform ausgeführt wird. Entwickler verwenden unterstützte Frameworks wie Streamlit, Dash oder Gradio, um Apps zu erstellen, die interaktive Daten oder KI-Erfahrungen in einem Azure Databricks-Arbeitsbereich bereitstellen.

Jede App enthält eine eigene Konfiguration, Identität und isolierte Laufzeitumgebung. Da Apps zu einem bestimmten Arbeitsbereich gehören, können sie auf Ressourcen auf Arbeitsbereichsebene wie SQL-Lagerhäuser und Ressourcen auf Kontoebene wie Unity Catalog zugreifen. Entwickler können apps auch für Benutzer außerhalb des Arbeitsbereichs freigeben, aber innerhalb desselben Azure Databricks-Kontos.

Obwohl der App-Container in der serverlosen Azure Databricks-Infrastruktur ausgeführt wird, kann die App selbst eine Verbindung mit serverlosen und nicht serverlosen Ressourcen herstellen. Konzeptionell fungiert eine App als Steuerungsebenendienst, der eine Web-UI hostet und auf verfügbare Azure Databricks-Datenebenendienste zugreift. Weitere Informationen finden Sie in der Übersicht über die Databricks-Architektur.

Um Apps zu starten und zu verwalten, wechseln Sie in der Arbeitsbereichs-UI zum Abschnitt "Apps ".

App-URL

Databricks weist jeder App automatisch eine eindeutige URL zu, wenn Sie sie erstellen. Die URL weist das folgende Format auf:

https://<app-name>-<workspace-id>.<region>.databricksapps.com

Ort:

• <app-name> ist der Name, den Sie beim Erstellen der App angeben
• <workspace-id> ist der eindeutige Bezeichner für Ihren Arbeitsbereich
• <region> ist die Cloudregion, in der sich Ihr Arbeitsbereich befindet.

Sie können die URL nach dem Erstellen der App nicht mehr ändern. Wenn Sie eine andere URL benötigen, erstellen Sie eine neue App mit einem anderen Namen.

Template

Eine App-Vorlage ist ein vorgefertigtes Gerüst, das Entwicklern hilft, Apps schnell mithilfe eines unterstützten Frameworks zu erstellen. Jede Vorlage enthält eine grundlegende Dateistruktur, ein app.yaml Manifest, eine requirements.txt Datei für Python-Apps und Beispielquellcode.

Die app.yaml Datei definiert den Befehl zum Ausführen der App (z streamlit run <app-name> . B. für eine Streamlit-App), richtet lokale Umgebungsvariablen ein und deklariert alle erforderlichen Ressourcen.

• Verwenden Sie requirements.txt, um zusätzliche Python-Pakete zur Installation mit pip aufzulisten.
• Verwenden Sie package.json, um Node.js-Pakete zur Installation mit npm aufzulisten.

Diese Dateien ergänzen die Standardsystemumgebung und vorinstallierte Pakete. Weitere Informationen finden Sie in der Systemumgebung "Databricks Apps".

Entwickler können eine neue App aus einer Vorlage mithilfe der Azure Databricks UI oder CLI generieren.

Systemumgebung und -pakete

Databricks-Apps werden in einer vorkonfigurierten Systemumgebung ausgeführt, die von Azure Databricks verwaltet wird. Ausführliche Informationen finden Sie in der Systemumgebung "Databricks Apps".

Jede App verfügt über eine eigene isolierte Umgebung, um Abhängigkeitskonflikte zu verhindern. Um die Konsistenz zu gewährleisten, definieren Sie erforderliche Pakete und deren Versionen in der entsprechenden Datei für Ihre App:

• Verwenden Sie für requirements.txt .
• Für Node.js verwenden Sie package.json.

Bei Hybridbereitstellungen verfügen Sie wahrscheinlich über beide Dateien.

Während der Bereitstellung installiert Azure Databricks diese Abhängigkeiten in der isolierten Laufzeitumgebung der App. Wenn Sie ein Paket einschließen, das bereits vorinstalliert ist, setzt die angegebene Version den Standardwert außer Kraft.

Weitere Details finden Sie unter Verwalten von Abhängigkeiten für eine Databricks-App .

App-Ressourcen

App-Ressourcen sind Azure Databricks-native Dienste, von denen eine App abhängt, wie SQL-Ablageorte, Modell-Servicemodelle, Aufträge, Geheimnisse oder Volumes. Sie deklarieren diese Abhängigkeiten im databricks.yml Manifest mithilfe des resources Felds. Azure Databricks unterstützt die folgenden Ressourcentypen:

• SQL Warehouse
• Job
• Modell, das Endpunkt bedient
• Genie Space
• Secret
• Volume

Um auf Azure Databricks-Dienste zuzugreifen, die noch nicht über einen unterstützten Ressourcentyp verfügen, verwenden Sie einen vom Unity-Katalog verwalteten Geheimschlüssel, um Anmeldeinformationen sicher einzugeben. Siehe Verwaltung von Geheimnissen.

Es gibt zwei Phasen zum Konfigurieren von App-Ressourcen:

• Deklaration (Entwicklung) – Deklarieren Sie jede erforderliche Ressource im databricks.yml Manifest. Dadurch wird definiert, welche Ressourcen die App benötigt und welche Berechtigungen erforderlich sind.
• Konfiguration (Bereitstellung) – Verwenden Sie während der Bereitstellung die Benutzeroberfläche von Databricks-Apps, um die deklarierten Ressourcen mit tatsächlichen arbeitsbereichspezifischen Instanzen zu konfigurieren (z. B. auswählen eines bestimmten SQL Warehouse).

Durch diese Trennung zwischen Deklaration und Konfiguration können Apps in allen Umgebungen portierbar sein. Sie können z. B. denselben App-Code in einem Entwicklungsarbeitsbereich bereitstellen und mit einem SQL Warehouse verknüpfen. In der Produktion können Sie den Code wiederverwenden und ein anderes Lager konfigurieren, ohne Codeänderungen vorzunehmen. Um dies zu unterstützen, vermeiden Sie die Hartcodierung von Ressourcen-IDs oder umgebungsspezifischen Werten in Ihrer App.

Azure Databricks erzwingt den Zugriff mit minimalen Berechtigungen. Apps müssen vorhandene Ressourcen verwenden und können keine neuen erstellen. Während der Bereitstellung überprüfen und genehmigen Arbeitsbereichsadministratoren den angeforderten Zugriff der App auf Ressourcen. Der Serviceprinzipal der App erhält die erforderlichen Berechtigungen, und der App-Entwickler muss die Berechtigung haben, sie zu erteilen.

Weitere Informationen finden Sie unter Hinzufügen von Ressourcen zu einer Databricks-App.

App-Status

Eine App kann einen der folgenden Status haben: Rennen, Beenden, Bereitstellen oder Absturz.

• Rennen - Die App ist aktiv und zugänglich. Azure Databricks berechnet die Computeressourcen, die während der Ausführung der App verwendet werden.
• Beendet – Die App ist nicht zugänglich und verursacht keine Kosten. Azure Databricks behält die Konfiguration und Umgebung der App bei, sodass Sie sie neu starten können, ohne sie neu zu konfigurieren.
• Bereitstellen - Die App startet. Es ist noch nicht zugänglich und verursacht während dieser Phase keine Gebühren.
• Abgestürzt – Die App konnte nicht gestartet oder unerwartet beendet werden. Auf sie kann nicht zugegriffen werden, und es entstehen keine Gebühren. Sie können Protokolle anzeigen, um probleme zu beheben und die App neu zu starten, sobald das Problem behoben wurde.

App-Status

Der App-Zustand enthält alle Daten oder Kontexte, die die App über Benutzersitzungen oder Interaktionen hinweg beibehalten muss. Apps behalten den Speicherstatus nach einem Neustart nicht bei. Alle im Arbeitsspeicher gespeicherten Daten gehen verloren, wenn die App heruntergefahren wird.

Sie können den Zustand auf folgende Weise speichern:

• In-Memory-Speicher für temporäre Daten innerhalb einer einzigen Sitzung. Diese Daten gehen verloren, wenn die App neu gestartet wird.
• Lokales Dateisystem für temporäre Dateien während der App-Ausführung. Diese Daten gehen verloren, wenn die App neu gestartet wird.
• Azure Databricks-Tabellen mit Databricks SQL für persistente strukturierte Daten- und Analyseworkloads.
• Arbeitsbereichsdateien für persistente unstrukturierte Daten.
• Unity-Katalogvolumes für persistente unstrukturierte Daten mit Unity Catalog Governance.

• Lakebase-Datenbankinstanzen für persistente relationale Daten mit PostgreSQL-Kompatibilität.

Häufige Anwendungsfälle umfassen das Zwischenspeichern von Abfrageergebnissen, das Speichern von Benutzereinstellungen oder das Protokollieren von Benutzeraktionen über Sitzungen hinweg.

App-Authentifizierung und Autorisierung

Databricks Apps verwendet OAuth 2.0 für die Authentifizierung und Zugriffssteuerung. Jede App verfügt über zwei ergänzende Identitäten, die bestimmen, wie sie den Zugriff auf Azure Databricks-Ressourcen authentifiziert und autorisiert: App-Autorisierung und Benutzerautorisierung.

• App-Autorisierung – Azure Databricks erstellt automatisch einen Dienstprinzipal für jede App. Dieser Dienstprinzipal fungiert als Identität der App und erhält vom App-Entwickler Berechtigungen. Alle Benutzer der App teilen diese Identität und haben Zugriff auf denselben Satz von Berechtigungen. Dieses Modell ist nützlich für Vorgänge, die nicht vom Kontext des einzelnen Benutzers abhängen, z. B. Protokollierung oder Aktionen auf Systemebene.

• Benutzerautorisierung – Dieses Modell verwendet die Identität des App-Benutzers, um den Zugriff zu authentifizieren und zu autorisieren. Benutzer müssen zum Azure Databricks-Konto gehören, in dem die App bereitgestellt wird. Nach der Anmeldung über einmaliges Anmelden (Single Sign-On, SSO) kann die App die Anmeldeinformationen des Benutzers verwenden, um auf geregelte Ressourcen wie ein SQL Warehouse zuzugreifen. Auf diese Weise kann die Anwendung die feinkörnigen Berechtigungen, die von Unity Catalog verwaltet werden, beachten, ohne diese Berechtigungen dem Dienstprinzipal der Anwendung zu übertragen.

Apps fordern bestimmte OAuth-Bereiche in ihrem Manifest an, um zu steuern, auf welche APIs und Ressourcen sie zugreifen können. Dieses flexible Modell unterstützt die Sicherheit auf Unternehmensniveau und ermöglicht eine differenzierte Zugriffssteuerung.

Weitere Informationen finden Sie unter Konfigurieren der Autorisierung in einer Databricks-App.

App-Benutzer

Nach der Bereitstellung können App-Entwickler eine App für Benutzer oder Gruppen freigeben, indem sie die Berechtigung CAN_USE oder CAN_MANAGE auf der App-Instanz erteilen. Benutzer müssen nicht zum gleichen Arbeitsbereich gehören, müssen aber Teil desselben Azure Databricks-Kontos sein. Um mit externen Benutzern zu teilen, synchronisieren Sie sie zuerst über Ihren Identitätsanbieter in das Konto. Weitere Informationen finden Sie unter Synchronisieren von Benutzern und Gruppen von Microsoft Entra ID mithilfe von SCIM-.

Sie können dieselbe App auch über Entwicklungs-, Staging- und Produktionsumgebungen verteilen, indem Sie CI/CD-Pipelines und Infrastruktur als Code verwenden. Die zentrale Benutzeroberfläche von Apps hilft Benutzern, Apps zu erkennen und zu starten, die sie verwenden dürfen.