Viktiga begrepp i Databricks-appar

Den här artikeln beskriver huvudbegreppen bakom Databricks-appar, inklusive hur appar är strukturerade, hur de hanterar beroenden och tillstånd, hur behörigheter fungerar och hur appar interagerar med plattformsresurser. Att förstå dessa begrepp hjälper dig att utveckla, distribuera och hantera appar på din arbetsyta.

App

En Databricks-app är ett webbprogram som körs som en containerbaserad tjänst på den serverlösa Azure Databricks-plattformen. Utvecklare använder ramverk som stöds, till exempel Streamlit, Dash eller Gradio för att skapa appar som levererar interaktiva data eller AI-upplevelser på en Azure Databricks-arbetsyta.

Varje app innehåller sin egen konfiguration, identitet och isolerade körningsmiljö. Eftersom appar tillhör en specifik arbetsyta kan de komma åt resurser på arbetsytenivå, till exempel SQL-lager och resurser på kontonivå, till exempel Unity Catalog. Utvecklare kan också välja att dela appar med användare utanför arbetsytan men inom samma Azure Databricks-konto.

Även om appcontainern körs på den serverlösa infrastrukturen i Azure Databricks kan själva appen ansluta till både serverlösa och icke-serverlösa resurser. Konceptuellt fungerar en app som en kontrollplanstjänst som är värd för ett webbgränssnitt och har åtkomst till tillgängliga Azure Databricks-dataplanstjänster. Mer information finns i översikten över Databricks-arkitekturen.

Om du vill starta och hantera appar går du till avsnittet Appar i arbetsytans användargränssnitt.

App-URL

Databricks tilldelar automatiskt varje app en unik URL när du skapar den. URL:en följer det här formatet:

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

Where:

• <app-name> är namnet du anger när du skapar appen
• <workspace-id> är den unika identifieraren för din arbetsyta
• <region> är den molnregion där din arbetsyta finns

Du kan inte ändra URL:en när du har skapat appen. Om du behöver en annan URL skapar du en ny app med ett annat namn.

Template

En appmall är en fördefinierad byggnadsställning som hjälper utvecklare att börja skapa appar snabbt med hjälp av ett ramverk som stöds. Varje mall innehåller en grundläggande filstruktur, ett app.yaml manifest, en requirements.txt fil för Python-appar och exempel på källkod.

Filen app.yaml definierar kommandot för att köra appen (till exempel streamlit run <app-name> för en Streamlit-app), konfigurerar lokala miljövariabler och deklarerar alla nödvändiga resurser.

• Använd requirements.txt för att lista ytterligare Python-paket som ska installeras med pip.
• Använd package.json för att lista Node.js paket som ska installeras med npm.

Dessa filer kompletterar standardsystemmiljön och förinstallerade paket. Mer information finns i Databricks Apps-systemmiljön.

Utvecklare kan generera en ny app från en mall med hjälp av Azure Databricks-användargränssnittet eller CLI.

Systemmiljö och paket

Databricks Apps körs i en förkonfigurerad systemmiljö som hanteras av Azure Databricks. Mer information finns i Databricks Apps-systemmiljön.

Varje app har en egen isolerad miljö för att förhindra beroendekonflikter. Definiera nödvändiga paket och deras versioner i rätt fil för din app för att säkerställa konsekvens:

• För Python använder du requirements.txt.
• För Node.jsanvänder du package.json.

För hybriddistributioner har du förmodligen båda filerna.

Under distributionen installerar Azure Databricks dessa beroenden i appens isolerade körningsmiljö. Om du inkluderar ett paket som redan är förinstallerat åsidosätter den angivna versionen standardvärdet.

Mer information finns i Hantera beroenden för en Databricks-app .

Appresurser

Appresurser är Azure Databricks-interna tjänster som en app är beroende av, till exempel SQL-lager, modell som betjänar slutpunkter, jobb, hemligheter eller volymer. Du deklarerar dessa beroenden i manifestet databricks.yml med hjälp av fältet resources . Azure Databricks stöder följande resurstyper:

• SQL-lager
• Job
• Modell som betjänar slutpunkt
• Genieområde
• Secret
• Volume

Om du vill komma åt Azure Databricks-tjänster som ännu inte har någon resurstyp som stöds använder du en Unity Catalog-hanterad hemlighet för att på ett säkert sätt mata in autentiseringsuppgifter. Se Hemlig hantering.

Det finns två steg för att konfigurera appresurser:

• Deklaration (utveckling) – Deklarera varje nödvändig resurs i manifestet databricks.yml . Detta definierar vilka resurser appen behöver och vilka behörigheter den behöver.
• Konfiguration (distribution) – Under distributionen använder du användargränssnittet för Databricks Apps för att konfigurera de deklarerade resurserna med faktiska arbetsytespecifika instanser (till exempel genom att välja ett specifikt SQL-lager).

Den här separationen mellan deklaration och konfiguration gör att appar kan vara portabla i olika miljöer. Du kan till exempel distribuera samma appkod på en utvecklingsarbetsyta och länka den till ett SQL-lager. I produktion kan du återanvända koden och konfigurera ett annat lager utan att göra kodändringar. Undvik att hårdkoda resurs-ID:er eller miljöspecifika värden i din app för att stödja detta.

Azure Databricks tillämpar åtkomst med lägsta behörighet. Appar måste använda befintliga resurser och kan inte skapa nya. Under distributionen granskar och godkänner arbetsyteadministratörer appens begärda åtkomst till resurser. Appens tjänsthuvudnamn får de behörigheter som krävs och apputvecklaren måste ha behörighet att bevilja dem.

Mer information finns i Lägga till resurser i en Databricks-app.

Appstatus

En app kan ha någon av följande statusar: Kör, Stoppad, Distribuerad eller Kraschad.

• Körs – Appen är aktiv och tillgänglig. Azure Databricks fakturerar för de beräkningsresurser som används när appen körs.
• Stoppad – Appen är inte tillgänglig och medför inga kostnader. Azure Databricks bevarar appens konfiguration och miljö, så att du kan starta om den utan att konfigurera om den.
• Distribuera – Appen startas. Det är ännu inte tillgängligt och medför inga avgifter under den här fasen.
• Kraschad – Appen kunde inte startas eller stoppades oväntat. Det är otillgängligt och medför inte avgifter. Du kan visa loggar för att felsöka och starta om appen när problemet har lösts.

Apptillstånd

Apptillståndet innehåller alla data eller kontexter som appen behöver bevara mellan användarsessioner eller interaktioner. Appar bevarar inte minnesinternt tillstånd efter omstarter. Data som lagras i minnet går förlorade när appen stängs av.

Du kan lagra tillståndet på följande sätt:

• Minnesintern lagring för tillfälliga data i en enda session. Dessa data går förlorade när appen startas om.
• Lokalt filsystem för temporära filer under appkörningen. Dessa data går förlorade när appen startas om.
• Azure Databricks-tabeller med Databricks SQL för beständiga strukturerade data- och analysarbetsbelastningar.
• Arbetsytefiler för beständiga ostrukturerade data.
• Unity Catalog-volymer för beständiga ostrukturerade data med Unity Catalog-styrning.

• Lakebase-databasinstanser för beständiga relationsdata med PostgreSQL-kompatibilitet.

Vanliga användningsfall är att cachelagra frågeresultat, spara användarinställningar eller logga användaråtgärder mellan sessioner.

Appautentisering och auktorisering

Databricks Apps använder OAuth 2.0 för autentisering och åtkomstkontroll. Varje app har två kompletterande identiteter som avgör hur den autentiserar och auktoriserar åtkomst till Azure Databricks-resurser: appauktorisering och användarauktorisering.

• Appauktorisering – Azure Databricks skapar automatiskt ett huvudnamn för tjänsten för varje app. Tjänstens huvudnamn fungerar som appens identitet och beviljas behörigheter av apputvecklaren. Alla användare av appen delar den här identiteten och har åtkomst till samma uppsättning behörigheter. Den här modellen är användbar för åtgärder som inte är beroende av den enskilda användarens kontext, till exempel loggning eller åtgärder på systemnivå.

• Användarauktorisering – Den här modellen använder appanvändarens identitet för att autentisera och auktorisera åtkomst. Användarna måste tillhöra det Azure Databricks-konto där appen distribueras. När du har loggat in via enkel inloggning (SSO) kan appen använda användarens autentiseringsuppgifter för att komma åt reglerade resurser som ett SQL-lager. På så sätt kan appen respektera de finmaskiga behörigheter som hanteras av Unity Catalog utan att bevilja dessa behörigheter till appens huvudanvändare.

Appar begär specifika OAuth-omfång i sitt manifest för att kontrollera vilka API:er och resurser de kan komma åt. Den här flexibla modellen stöder säkerhet i företagsklass och möjliggör detaljerad åtkomstkontroll.

Mer information finns i Konfigurera auktorisering i en Databricks-app.

Appanvändare

Efter distributionen kan apputvecklare dela en app med användare eller grupper genom att bevilja CAN_USE eller CAN_MANAGE behörighet för appinstansen. Användarna behöver inte tillhöra samma arbetsyta, men de måste ingå i samma Azure Databricks-konto. Om du vill dela med externa användare synkroniserar du dem först med kontot med hjälp av din identitetsprovider. Mer information finns i Synkronisera användare och grupper från Microsoft Entra-ID med SCIM.

Du kan också distribuera samma app i utvecklings-, mellanlagrings- och produktionsmiljöer med hjälp av CI/CD-pipelines och infrastruktur som kod. Det centraliserade användargränssnittet för appar hjälper användare att identifiera och starta appar som de har behörighet att använda.