Metodtips för utvecklare på Databricks

Den här sidan innehåller metodtips för din livscykel för datateknik och utveckling, inklusive versionskontroll, miljöhantering, utvecklarverktyg och hanterade distributioner.

Källkontroll

Versionskontroll av alla filer

Deklarativ automatisering bygger på tanken att om något inte finns i versionskontrollen finns det inte. Därför rekommenderar Databricks att du versionshanterar nästan alla filer, inklusive:

• Alla notebook-filer och källfiler (.py, .sql)
• Paketkonfigurationsfiler (databricks.yml och miljöspecifika YAML-åsidosättningar)

Checka dock inte in:

• Skapa artefakter, till exempel .jar eller .whl filer. Ladda i stället upp kompilerade binärfiler till Unity Catalog-volymer under CI. Se ladda upp JAR.
• Token eller autentiseringsuppgifter. Använd hemlighetshantering på arbetsytenivå som backas upp av en molnhemlighetshanterare (till exempel AWS Secrets Manager eller Azure Key Vault) och synkronisera värden i Databricks hemliga omfång. Se Hemlig hantering.
• Lokala dataexempel och filer med PII. Använd .gitignore för att exkludera dem.

Enkel lagringsplats

Databricks rekommenderar att du använder en enda lagringsplats för all din kod (källkod och konfigurationsfiler), eftersom det gör samarbete och delning av kod och metodtips för både människor och AI enklare. Om du har flera paket för separata distributionslivscykler behåller du dem på en enda lagringsplats.

Det enda undantaget från rekommendationen för den enskilda lagringsplatsen är i reglerade branscher där flera lagringsplatser är nödvändiga för konfidentialitetsändamål.

Strategi för trunkbaserad förgrening

Om du vill minimera sammanslagningskonflikter och se till att huvudgrenen alltid är i ett distributionsbart tillstånd använder du en trunkbaserad förgreningsstrategi.

Ett enkelt arbetsflöde skulle vara:

1. Utveckla lokalt eller på arbetsytan och distribuera till en Databricks-utvecklingsarbetsyta för att testa ändringar.
2. Skapa en kortlivad funktionsgren för att versionskontrollera uppdateringar och synkronisera dina lokala ändringar eller arbetsyteändringar regelbundet.
3. När testningen är klar sammanfogar du funktionsgrenen till huvudgrenen.
4. CI/CD distribuerar automatiskt huvudgrenen till en förberedande arbetsyta och automatiserade tester utlöses.
5. När stagingtester och kontroller har klarats implementerar CI/CD huvudgrenen till en produktionsarbetsyta.

De här stegen beskrivs i följande diagram:

Konfiguration av arbetsyta

Isolera arbetsytemiljöer

Isolera arbetsytemiljöer för att minimera effekten av en misslyckad distribution. Ett exempel:

• Små team (upp till 5 datatekniker): Börja med två arbetsytor (utveckling och produktion) i ett enda molnkonto.
• Växande team (5+ datatekniker): Flytta till tre arbetsytor (utveckling, mellanlagring och produktion). Stagingmiljön bör vara funktionellt representativ för produktionsmiljön – samma buildkonfiguration, schema och kritiska integrationer – även om den är nedskalad.
• Reglerade branscher (bank, sjukvård, försvar): Isolera arbetsytor och molnkonton fysiskt för att förhindra dataläckage. Det är möjligt att hantera isolering via IAM- och Unity Catalog-gränser inom ett enda konto, men ger en mindre robust säkerhetsstatus.

För produktionsarbetsytor använder du serverlös beräkning med nätverksprinciper där det är möjligt. Annars konfigurerar du molnkonton så att de använder privata undernät eller VNets med strikt kontrollerad utgående trafik och nätverkssäkerhetskontroller.

Mer information finns i Kontextbaserade nätverksprinciper.

Isolera datalagring

• Använd ett enda Unity Catalog-metaarkiv och skapa separata kataloger för utveckling, mellanlagring (om tillämpligt) och produktion, vilket speglar arbetsytans layout.
• Använd personliga scheman för enskilda utvecklare i kataloger för utveckling och test (icke-produktion).
• Knyt produktionskatalogen i läget ISOLATED endast till produktionsarbetsytan. Om du ställer in en katalogs isoleringsläge ser du till ISOLATED att produktionsdata inte kan nås från utvecklings- eller mellanlagringsmiljöer, även om en identitet är felkonfigurerad.
• Reservera separata metaarkiv, konton eller regioner endast för organisationer med regler, datasuveränitet eller krav på flera regioner som isolering på katalognivå inte kan uppfylla.

Behandla tabell- och kolumnmetadata som kod

Behandla tabell- och kolumnkommenteringar som en del av koden. Förvara dem i .sql filer tillsammans med definitionerna för deklarativa Automation-paket och distribuera dem via ett metadatajobb så att korrekta, affärsinriktade definitioner alltid är tillgängliga. Skriv kommentarer som beskriver vad en rad representerar, enheterna och giltiga värden på vanligt språk i stället för att upprepa kolumnnamnet.

Konfigurera personliga scheman

Under utvecklingen konfigurerar du paket för att använda ett personligt schema per användare, till exempel dev_${user_name}. Detta hindrar utvecklare från att skriva över varandras tabeller på en delad arbetsyta.

Använda serverlös beräkning

Använd serverlös beräkning för att förenkla klusterhanteringen och optimera kostnaden. Se Ansluta till serverlös beräkning.

CI/CD-rekommendationer

Deklarativ automatiseringspaket för CI/CD

Deklarativa Automation-paket (tidigare kallade Databricks-tillgångspaket) erbjuder en kraftfull, enhetlig metod för att hantera kod, arbetsflöden och infrastruktur i Databricks-ekosystemet och rekommenderas för dina CI/CD-pipelines.

Mer information om hur du använder paket för CI/CD-arbetsflöden finns i CI/CD-arbetsflöden på Databricks.

Mer information om deklarativa automatiseringspaket finns i Vad är deklarativa automatiseringspaket?.

Använd endast Terraform för externa resurser

Använd Terraform för att definiera följande resurser:

• Resurser på molnnivå och externa resurser
• Administratörsåtgärder som icke-privilegierade användare inte ska utföra, till exempel etablering av arbetsytor eller konfiguration av molnnätverk

Använd deklarativa Automation-paket för alla andra Databricks-resurser.

Pakethantering

Skapa små paket

Databricks rekommenderar att du utvecklar små, fokuserade paket över ett enda stort paket.

• Lägg allt som ett enda team äger i ett paket.
• Testa och distribuera via samma CI/CD-pipeline som delar samma livscykel och lanseringstakt.
• Varje paket bör omfatta alla miljöer för ett visst projekt (utveckling, mellanlagring, produktion) i stället för att använda separata paket per miljö.

Skapa separata paket för:

• Olika produkter eller domäner, till exempel "Faktureringsanalys" och "Bedrägeriidentifiering"
• Olika ägarskaps- eller behörighetsgränser
• Arbetsbelastningar med helt olika livscykeler
• Fall där du behöver oberoende befordran eller återställning

Använda sync.paths för att synkronisera delade mappar

När du hanterar flera paket på en lagringsplats använder du sync.paths för att synkronisera delade mappar utanför paketroten. På så sätt kan olika projekt dela en gemensam biblioteksmapp, till exempel , samtidigt som ../commonseparata distributionsidentiteter upprätthålls.

Modellera beroenden mellan paket i CI/CD

När paket B är beroende av tillgångar som publicerats av paket A modellerar du det beroendet i ditt CI/CD- eller orkestreringslager i stället för att komprimera båda i ett paket.

• Gör arbetsflödet för distribution och publicering av paket A till en explicit förutsättning för paket B. Koppla pipelinen så att paket B startar först när paket A-distributionen har slutförts och alla nödvändiga verifieringskontroller har godkänts.
• Skicka publicerade resursidentifierare eller sökvägar vidare som indata till pipelinen och avbryt omedelbart om uppströmsresurser saknas. Detta säkerställer att Bundle B aldrig driftsätts mot ett delvis publicerat läge.

Mer information om paketdelning finns i Dela paket och paketfiler.

Anpassade paketmallar

Använd anpassade deklarativa Automation-paketmallar som standardstartpunkt för nya projekt så att varje projekt ärver samma skyddsräcken – behörigheter, taggning, klusterprinciper, CI/CD-ledningar och instansbaslinjer – utan att varje team löser det från grunden.

Mallar bör koda delade, långvariga konventioner som styrning, standardprestanda, miljölayout och kvotgränser. Undvik appspecifik affärslogik, hemligheter eller engångskonfiguration i mallar.

Parameterisera endast indata som förväntas variera beroende på team, projekt eller miljö:

• Project eller programnamn
• Inställningar för målarbetsyta
• Katalog- eller schemanamn
• Identifierare för tjänsthuvudnamn
• Scheman och meddelandeinställningar

Håll plattformsskydd och delade standardvärden fasta i mallen i stället för att parametrisera dem.

Information om anpassade paketmallar och hur du skapar dem finns i Projektmallar för deklarativa Automation-paket.

Planera för återställningar och snabbkorrigeringar

Håll paketen så små att du kan göra en riktad återställning på ett enda paket i stället för att samordna en återställning över många orelaterade arbetsbelastningar.

Under en incident:

1. Återställ eller rulla tillbaka det berörda paketet till den senaste kända fungerande versionen.
2. Använd endast en snabbkorrigering för brådskande, begränsade korrigeringar som inte kan vänta på det normala upphöjningsflödet.
3. Sammanfoga eventuella snabbkorrigeringar tillbaka till huvudgrenen omedelbart efter valideringen så att stammen förblir den enda sanningskällan.

Allmän utveckling

Använd tjänsthuvudnamn eller OIDC

Använd tjänstens huvudnamn för all icke-utvecklingsautomatisering för att frikoppla automatiserade arbetsflöden från enskilda användarkonton och se till att jobben fortsätter att köras när interna användare lämnar. Se Tjänstens huvudprincipaler.

• Använd separata tjänsthuvudnamn för distribution och körning. Ett dedikerat tjänsthuvudkonto för distribution av bundlar bör ha minimala dataåtkomsträttigheter. Varje produktionsjobb eller pipeline ska ha ett eget kör som-tjänsthuvudnamn som endast är begränsat till de data och resurser som arbetsbelastningen kräver. Den här separationen säkerställer att distributioner förblir säkra när du roterar eller skärper behörigheter för dataåtkomst och undviker att koppla infrastrukturändringar till åtkomst till produktionsdata.
• Reglerade branscher: Använd OIDC (Workload Identity Federation) för CI/CD. Detta eliminerar långvariga hemligheter i GitHub Actions eller Azure DevOps. Se Aktivera arbetsbelastningsidentitetsfederation i CI/CD.

Använda Databricks-utvecklarverktyg

Utveckla i databricks-arbetsytans användargränssnitt med Git-mappar eller i en lokal IDE. Om du använder Visual Studio Code eller en kompatibel förgrening installerar du det officiella Databricks-tillägget för:

• Databricks-specifika agentkunskaper
• Åtkomst till Unity Catalog och filsystem
• Funktioner för fjärrutveckling för att köra arbetsbelastningar på Databricks-beräkningsresurser

Mer information finns i Databricks-tillägget för Visual Studio Code.

Minimera affärslogik i notebook-filer

Behandla inte notebook-filer som den primära containern för affärslogik. Använd dem endast för utforskning och visualisering.

• Python: Placera kärnlogik i importbara .py moduler i src/ eller src/py/och anropa dessa funktioner från notebook-filer.
• SQL: Spara SQL-frågor i .sql-filer i src/ eller src/sql/, och referera till dessa filer från jobb och pipelines i stället för att infoga SQL direkt i notebook-filer.

Använd endast notebook-filer som tunna orkestrerings- och visualiseringslager som anropar den underliggande koden. Den här metoden gör det enklare att testa och återanvända.

När du migrerar ett notebook-tungt projekt gör du det stegvis. Extrahera en återanvändbar modul eller SQL-fil i taget och använd Deklarativa Automation-paket för att få migrerade tillgångar under samma distributions- och testarbetsflöde som resten av projektet.

Skicka kontext dynamiskt

Undvik statiska variabler för aktivitetsberoenden. Använd dynamiska värdereferenser som {{tasks.<task_key>.values.<value_key>}} för att skicka körningskontext mellan aktiviteter i ett jobb i flera steg.

Testning och observerbarhet

Inför testlager

Använd tre testlager som matchar hur dina paket går mot produktion:

1. Enhetstester: Behåll affärslogik i importbara src/ moduler och täck den med pytest eller ett motsvarande ramverk. Kör dessa för varje pull request så att misslyckanden blockerar sammanslagningar.
2. Paketverifiering: Kör bundle validate lokalt. I CI bör du föredra bundle deploy framför en icke-produktionsarbetsyta för att fånga upp YAML- och resursmappningsproblem innan driftsättning till produktion.
3. Integrationstester i testmiljö: När du har distribuerat till testmiljön kör du end-to-end-jobb med kontroller av att de slutförts och kritiska datakvalitetskontroller, till exempel förväntningar på antal rader eller schema.

Använd "att alla tester klaras på huvudgrenen och i stagingmiljön" som kriterium för att befordra artefakter till produktion.

För Lakeflow Spark deklarativa pipelines, använd de inbyggda utvecklings- och valideringsfunktionerna i stället för ad hoc-körningar i notebook. Testa pipelinelogik mot små representativa datauppsättningar som innehåller poster med fel och använd utvecklingsläget för att verifiera ändringar innan du uppdaterar produktionstabeller.

Behandla loggning som en del av driftsättningen

För arbetsbelastningar som distribueras med deklarativa automatiseringspaket bör mätvärden och loggning betraktas som en del av distributionskontraktet snarare än något som varje projekt definierar för sig.

• Generera strukturerade loggar på ett enhetligt sätt i jobb, pipelines och uppgifter. Inkludera paketnamnet, målmiljön, arbetsbelastningsnamnet, körningsidentifieraren och alla affärsidentifierare som behövs för att spåra fel.
• Spåra en standarduppsättning driftsmått för varje produktionsarbetsbelastning: körningsstatus, varaktighet, antal återförsök och indikatorer för dataflöde eller färskhet där det är relevant.
• Koda dessa konventioner i delade bibliotek, återanvändbara arbetsbelastningsdefinitioner eller paketmallar så att teamen inte behöver återskapa observerbarhetsmönster för varje projekt.