Belangrijkste concepten in Databricks-apps

In dit artikel worden de belangrijkste concepten van Databricks-apps geïntroduceerd, waaronder hoe apps zijn gestructureerd, hoe ze afhankelijkheden en status beheren, hoe machtigingen werken en hoe apps communiceren met platformresources. Als u deze concepten begrijpt, helpt u bij het ontwikkelen, implementeren en beheren van apps in uw werkruimte.

App

Een Databricks-app is een webtoepassing die wordt uitgevoerd als een containerservice op het serverloze Azure Databricks-platform. Ontwikkelaars gebruiken ondersteunde frameworks zoals Streamlit, Dash of Gradio om apps te bouwen die interactieve gegevens of AI-ervaringen bieden binnen een Azure Databricks-werkruimte.

Elke app bevat een eigen configuratie, identiteit en geïsoleerde runtime-omgeving. Omdat apps deel uitmaken van een specifieke werkruimte, hebben ze toegang tot resources op werkruimteniveau, zoals SQL Warehouses en resources op accountniveau, zoals Unity Catalog. Ontwikkelaars kunnen er ook voor kiezen om apps te delen met gebruikers buiten de werkruimte, maar binnen hetzelfde Azure Databricks-account.

Hoewel de app-container wordt uitgevoerd op de serverloze Infrastructuur van Azure Databricks, kan de app zelf verbinding maken met zowel serverloze als niet-serverloze resources. Conceptueel gezien fungeert een app als een besturingsvlakservice die als host fungeert voor een webgebruikersinterface en toegang heeft tot beschikbare Azure Databricks-gegevensvlakservices. Zie het overzicht van de Databricks-architectuur voor meer informatie.

Als u apps wilt starten en beheren, gaat u naar de sectie Apps in de gebruikersinterface van de werkruimte.

App-URL

Databricks wijst elke app automatisch een unieke URL toe wanneer u deze maakt. De URL volgt deze indeling:

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

Where:

• <app-name> is de naam die u opgeeft bij het maken van de app
• <workspace-id> is de unieke identificatie voor uw werkruimte
• <region> is de cloudregio waar uw werkruimte zich bevindt

U kunt de URL niet wijzigen nadat u de app hebt gemaakt. Als u een andere URL nodig hebt, maakt u een nieuwe app met een andere naam.

Template

Een app-sjabloon is een vooraf gedefinieerde scaffold waarmee ontwikkelaars snel apps kunnen bouwen met behulp van een ondersteund framework. Elke sjabloon bevat een basisbestandsstructuur, een app.yaml manifest, een requirements.txt bestand voor Python-apps en voorbeeldbroncode.

Het app.yaml bestand definieert de opdracht voor het uitvoeren van de app (bijvoorbeeld streamlit run <app-name> voor een Streamlit-app), stelt lokale omgevingsvariabelen in en declareert alle vereiste resources.

• Gebruik requirements.txt om extra Python-pakketten op te sommen die moeten worden geïnstalleerd met pip.
• Gebruik package.json om Node.js pakketten te vermelden die u kunt installeren met npm.

Deze bestanden vormen een aanvulling op de standaardsysteemomgeving en vooraf geïnstalleerde pakketten. Zie de systeemomgeving van Databricks Apps voor meer informatie.

Ontwikkelaars kunnen een nieuwe app genereren op basis van een sjabloon met behulp van de Gebruikersinterface of CLI van Azure Databricks.

Systeemomgeving en -pakketten

Databricks-apps worden uitgevoerd in een vooraf geconfigureerde systeemomgeving die wordt beheerd door Azure Databricks. Zie de Systeemomgeving van Databricks Apps voor meer informatie.

Elke app heeft een eigen geïsoleerde omgeving om afhankelijkheidsconflicten te voorkomen. Om consistentie te garanderen, definieert u de vereiste pakketten en de bijbehorende versies in het juiste bestand voor uw app:

• Voor Python gebruikt u requirements.txt.
• Gebruik voor Node.jspackage.json.

Voor hybride implementaties hebt u waarschijnlijk beide bestanden.

Tijdens de implementatie installeert Azure Databricks deze afhankelijkheden in de geïsoleerde runtime-omgeving van de app. Als u een pakket opneemt dat al vooraf is geïnstalleerd, overschrijft de opgegeven versie de standaardversie.

Zie Afhankelijkheden beheren voor een Databricks-app voor meer informatie.

Appresources

App-resources zijn systeemeigen Azure Databricks-services waarvoor een app afhankelijk is, zoals SQL-warehouses, model voor eindpunten, taken, geheimen of volumes. U declareert deze afhankelijkheden in het databricks.yml manifest met behulp van het resources veld. Azure Databricks ondersteunt de volgende resourcetypen:

• SQL Warehouse
• Job
• Eindpunt voor modelserver
• Genieruimte
• Secret
• Volume

Als u toegang wilt krijgen tot Azure Databricks-services die nog geen ondersteund resourcetype hebben, gebruikt u een door Unity Catalog beheerd geheim om referenties veilig te injecteren. Zie Geheimbeheer.

Er zijn twee fasen voor het configureren van app-resources:

• Declaratie (ontwikkeling): declareer elke vereiste resource in het databricks.yml manifest. Hiermee definieert u welke resources de app nodig heeft en welke machtigingen deze nodig heeft.
• Configuratie (implementatie): gebruik tijdens de implementatie de Gebruikersinterface van Databricks Apps om de gedeclareerde resources te configureren met werkelijke werkruimtespecifieke exemplaren (bijvoorbeeld door een specifiek SQL-warehouse te selecteren).

Door deze scheiding tussen declaratie en configuratie kunnen apps overdraagbaar zijn in omgevingen. U kunt bijvoorbeeld dezelfde app-code implementeren in een ontwikkelwerkruimte en deze koppelen aan één SQL Warehouse. In productie kunt u de code opnieuw gebruiken en een ander magazijn configureren zonder codewijzigingen aan te brengen. Om dit te ondersteunen, vermijdt u het coderen van resource-id's of omgevingsspecifieke waarden in uw app.

Azure Databricks dwingt toegang met minimale bevoegdheden af. Apps moeten bestaande resources gebruiken en kunnen geen nieuwe resources maken. Tijdens de implementatie controleren en goedkeuren werkruimtebeheerders de aangevraagde toegang tot resources van de app. De service-principal van de app ontvangt de benodigde machtigingen en de app-ontwikkelaar moet toestemming hebben om deze te verlenen.

Zie Resources toevoegen aan een Databricks-app voor meer informatie.

App-status

Een app kan een van de volgende statussen hebben: Actief, Gestopt, Implementeren of Vastgelopen.

• Wordt uitgevoerd : de app is actief en toegankelijk. Azure Databricks factureert voor de rekenresources die worden gebruikt terwijl de app wordt uitgevoerd.
• Gestopt : de app is niet toegankelijk en er worden geen kosten in rekening gebracht. Azure Databricks behoudt de configuratie en omgeving van de app, zodat u deze opnieuw kunt starten zonder de configuratie opnieuw te configureren.
• Implementeren : de app wordt gestart. Het is nog niet toegankelijk en er worden geen kosten in rekening gebracht tijdens deze fase.
• Vastgelopen : de app kan niet worden gestart of onverwacht gestopt. Het is niet toegankelijk en er worden geen kosten in rekening gebracht. U kunt logboeken weergeven om de app op te lossen en opnieuw op te starten zodra het probleem is opgelost.

App-status

De status van de app bevat gegevens of context die de app moet behouden voor gebruikerssessies of interacties. Apps behouden de status van het geheugen niet na het opnieuw opstarten. Alle gegevens die in het geheugen zijn opgeslagen, gaan verloren wanneer de app wordt afgesloten.

U kunt de status op de volgende manieren opslaan:

• Opslag in het geheugen voor tijdelijke gegevens binnen één sessie. Deze gegevens gaan verloren wanneer de app opnieuw wordt opgestart.
• Lokaal bestandssysteem voor tijdelijke bestanden tijdens het uitvoeren van de app. Deze gegevens gaan verloren wanneer de app opnieuw wordt opgestart.
• Azure Databricks-tabellen met Databricks SQL voor permanente gestructureerde gegevens- en analyseworkloads.
• Werkruimtebestanden voor permanente ongestructureerde gegevens.
• Unity Catalog-volumes voor permanente ongestructureerde gegevens met Unity Catalog-governance.

• Lakebase-database-exemplaren voor permanente relationele gegevens met PostgreSQL-compatibiliteit.

Veelvoorkomende gebruiksvoorbeelden zijn het opslaan van queryresultaten, het opslaan van gebruikersvoorkeuren of het vastleggen van gebruikersacties in verschillende sessies.

App-verificatie en -autorisatie

Databricks Apps maakt gebruik van OAuth 2.0 voor verificatie en toegangsbeheer. Elke app heeft twee complementaire identiteiten die bepalen hoe de app toegang tot Azure Databricks-resources verifieert en autoriseert: app-autorisatie en gebruikersautorisatie.

• App-autorisatie : Azure Databricks maakt automatisch een service-principal voor elke app. Deze service-principal fungeert als de identiteit van de app en krijgt machtigingen van de app-ontwikkelaar. Alle gebruikers van de app delen deze identiteit en hebben toegang tot dezelfde set machtigingen. Dit model is handig voor bewerkingen die niet afhankelijk zijn van de context van de afzonderlijke gebruiker, zoals logboekregistratie of acties op systeemniveau.

• Gebruikersautorisatie : dit model maakt gebruik van de identiteit van de app-gebruiker om toegang te verifiëren en te autoriseren. Gebruikers moeten behoren tot het Azure Databricks-account waar de app is geïmplementeerd. Nadat u zich hebt aangemeld via eenmalige aanmelding (SSO), kan de app de referenties van de gebruiker gebruiken voor toegang tot beheerde resources, zoals een SQL Warehouse. Hierdoor kan de app de verfijnde machtigingen respecteren die worden beheerd door Unity Catalog zonder deze machtigingen te verlenen aan de service-principal van de app.

Apps vragen specifieke OAuth-bereiken aan in hun manifest om te bepalen welke API's en resources ze kunnen openen. Dit flexibele model biedt ondersteuning voor beveiliging op ondernemingsniveau en maakt gedetailleerd toegangsbeheer mogelijk.

Zie Autorisatie configureren in een Databricks-app voor meer informatie.

App-gebruikers

Na de implementatie kunnen app-ontwikkelaars een app delen met gebruikers of groepen door de machtiging CAN_USE of CAN_MANAGE te verlenen op het app-exemplaar. Gebruikers hoeven niet tot dezelfde werkruimte te behoren, maar ze moeten deel uitmaken van hetzelfde Azure Databricks-account. Als u wilt delen met externe gebruikers, synchroniseert u ze eerst met het account met behulp van uw id-provider. Zie Gebruikers en groepen van Microsoft Entra-id synchroniseren met behulp van SCIMvoor meer informatie.

U kunt dezelfde app ook distribueren over ontwikkel-, faserings- en productieomgevingen met behulp van CI/CD-pijplijnen en infrastructuur als code. Met de gecentraliseerde gebruikersinterface voor apps kunnen gebruikers apps detecteren en starten die ze mogen gebruiken.