Metodtips för kostnadsoptimering

Den här artikeln beskriver metodtips som stöder principer för kostnadsoptimering, ordnade efter princip.

1. Välj optimala resurser

Använda prestandaoptimerade dataformat

För att få ut mesta möjliga av Databricks Data Intelligence Platform måste du använda Delta Lake som ditt lagringsramverk. Det hjälper dig att skapa enklare och mer tillförlitliga ETL-pipelines och levereras med många prestandaförbättringar som avsevärt kan påskynda arbetsbelastningar jämfört med användning av Parquet, ORC och JSON. Se Optimeringsrekommendationer för Azure Databricks. Om arbetsbelastningen också körs på en jobbberäkning leder detta direkt till kortare drifttid för beräkningsresurser, vilket leder till lägre kostnader.

Använda jobbberäkning

Ett jobb är ett sätt att köra icke-interaktiv kod på en Databricks-beräkningsinstans. Du kan till exempel köra en ETL-arbetsbelastning (extrahering, transformering och laddning) interaktivt eller enligt ett schema. Naturligtvis kan du även köra jobb interaktivt i notebook-användargränssnittet. Vid jobbberäkning kostar dock de icke-interaktiva arbetsbelastningarna betydligt mindre än vid all användningsberäkning. Se prisöversikten för att jämföra Jobbberäkning och All-Purpose Compute.

En ytterligare fördel för vissa jobb är att varje jobb eller arbetsflöde kan köras på en ny beräkningsinstans och isolera arbetsbelastningar från varandra. Men multitask-arbetsflöden kan också återanvända beräkningsresurser för alla uppgifter, så starttiden för beräkning sker bara en gång per arbetsflöde. Se Konfigurera beräkning för jobb.

Använda SQL Warehouse för SQL-arbetsbelastningar

För interaktiva SQL-arbetsbelastningar är ett Databricks SQL-lager den mest kostnadseffektiva motorn. Se prisöversikten. Alla SQL-lager levereras med Photon som standard, vilket påskyndar dina befintliga SQL- och DataFrame API-anrop och minskar din totala kostnad per arbetsbelastning.

Dessutom stöder serverlösa SQL-lager intelligent arbetsbelastningshantering (IWM), en uppsättning funktioner som förbättrar Databricks SQL-serverlösa möjligheter att bearbeta ett stort antal frågor snabbt och kostnadseffektivt.

Använda uppdaterade körningar för dina arbetsbelastningar

Azure Databricks-plattformen tillhandahåller olika körningar som är optimerade för datateknikuppgifter (Databricks Runtime) eller maskininlärningsuppgifter (Databricks Runtime för Machine Learning). Körningarna skapas för att ge det bästa valet av bibliotek för aktiviteterna och för att säkerställa att alla bibliotek som tillhandahålls är uppdaterade och fungerar tillsammans optimalt. Databricks Runtimes släpps regelbundet, vilket ger prestandaförbättringar mellan större versioner. Dessa prestandaförbättringar resulterar ofta i kostnadsbesparingar på grund av effektivare användning av beräkningsresurser.

Använd endast GPU:er för rätt arbetsbelastningar

Virtuella datorer med GPU:er kan dramatiskt påskynda beräkningar för djupinlärning, men är betydligt dyrare än datorer som endast är processorer. Använd endast GPU-instanser för arbetsbelastningar som har GPU-accelererade bibliotek.

De flesta arbetsbelastningar använder inte GPU-accelererade bibliotek, så de drar inte nytta av GPU-aktiverade instanser. Arbetsyteadministratörer kan begränsa GPU-datorer och beräkningsresurser för att förhindra onödig användning. Se blogginlägget "Är GPU:er riktigt dyra? Benchmarking GPU:er för slutsatsdragning på Databricks-kluster".

Använda serverlösa tjänster för dina arbetsbelastningar

BI-användningsfall

BI-arbetsbelastningar förbrukar vanligtvis data i skurar och genererar flera samtidiga frågeställningar. Till exempel kan någon som använder ett BI-verktyg uppdatera en instrumentpanel eller skriva en fråga och sedan helt enkelt analysera resultaten utan ytterligare interaktion med plattformen. I det här scenariot dataplattformen:

• Avslutar inaktiva beräkningsresurser för att spara kostnader.
• Tillhandahåller snabbt beräkningsresurserna när användaren begär nya eller uppdaterade data med BI-verktyget.

Icke-serverlösa Azure Databricks SQL-lager har en starttid på minuter, så många användare tenderar att acceptera den högre kostnaden och inte avsluta dem under inaktiva perioder. Å andra sidan startar och skalas serverlösa SQL-lager upp på några sekunder, så att både omedelbar tillgänglighet och inaktiv avslutning kan uppnås. Detta resulterar i en bra användarupplevelse och övergripande kostnadsbesparingar.

Dessutom skalas serverlösa SQL-lager ned tidigare än icke-serverlösa lager, vilket återigen resulterar i lägre kostnader.

ML- och AI-modellhantering

De flesta modeller hanteras som ett REST-API för integrering i ditt webb- eller klientprogram. modellen som betjänar tjänsten tar emot varierande belastningar av begäranden över tid, och en modell som betjänar plattformen bör alltid tillhandahålla tillräckliga resurser, men bara så många som faktiskt behövs (uppskalning och nedskalning).

Mosaic AI Model Serving använder serverlös beräkning och tillhandahåller en tjänst med hög tillgänglighet och låg svarstid för att distribuera modeller. Tjänsten skalas automatiskt upp eller ned för att möta förändringar i efterfrågan, vilket minskar infrastrukturkostnaderna samtidigt som svarstidsprestandan optimeras.

Använd rätt instanstyp

Att använda den senaste generationen av molninstanstyper ger nästan alltid prestandafördelar, eftersom de erbjuder bästa prestanda och de senaste funktionerna.

Baserat på dina arbetsbelastningar är det också viktigt att välja rätt instansfamilj för att få bästa prestanda/prisförhållande. Några enkla tumregler är:

• Minnesoptimerad för ML- och tung shuffle- och spillarbetsbelastningar
• Optimerad beräkning för strukturerade strömningsarbetsflöden och underhållsprocesser (till exempel optimering och skräprensning)
• Lagring som är optimerad för arbetsbelastningar som drar nytta av cachelagring, till exempel ad hoc- och interaktiv dataanalys
• GPU optimerad för specifika ML- och DL-arbetsbelastningar
• Generell användning i avsaknad av särskilda krav

Välj den mest effektiva beräkningsstorleken

Azure Databricks kör en utförare per arbetsnod. Därför används termerna utförare och arbetare synonymt i kontexten för Azure Databricks-arkitekturen. Många tänker ofta på klusterstorlek utifrån antalet arbetare, men det finns andra viktiga faktorer att tänka på:

• Totalt antal körkärnor (beräkning): Det totala antalet kärnor för alla utförare. Detta avgör den maximala parallelliteten för en beräkningsinstans.
• Totalt körminne: Den totala mängden RAM-minne för alla utförare. Detta avgör hur mycket data som kan lagras i minnet innan de sprids till disken.
• Lokal körningslagring: Typ och mängd lokal disklagring. Lokal disk används främst vid spill under blandningar och cachelagring.

Ytterligare överväganden är typ och storlek för arbetsinstanser, som också påverkar föregående faktorer. När du ändrar storlek på din beräkning bör du tänka på följande:

• Hur mycket data kommer din arbetsbelastning att förbruka?
• Vilken beräkningskomplexitet har din arbetsbelastning?
• Var läser du data från?
• Hur partitioneras data i extern lagring?
• Hur mycket parallellitet behöver du?

Information och exempel finns under Överväganden för beräkningsstorlek.

Utvärdera prestandaoptimerade frågemotorer

Photon är en databricks-inbyggd databricks-baserad vektoriserad frågemotor som påskyndar dina SQL-arbetsbelastningar och DataFrame API-anrop (för datainmatning, ETL, strömning, datavetenskap och interaktiva frågor). Photon är kompatibelt med Apache Spark-API:er, så det är lika enkelt att komma igång som att aktivera det – inga kodändringar och ingen inlåsning.

Den observerade hastigheten kan leda till betydande kostnadsbesparingar, och jobb som körs regelbundet bör utvärderas för att se om de inte bara är snabbare utan också billigare med Photon.

2. Dynamiskt allokera resurser

Använda automatisk skalningsberäkning

Med automatisk skalning omallokerar Databricks arbetare dynamiskt för att ta hänsyn till egenskaperna för ditt jobb. Vissa delar av pipelinen kan vara mer beräkningsintensiva än andra, och Databricks lägger automatiskt till ytterligare arbetare under dessa faser av jobbet (och tar bort dem när de inte längre behövs). Autoskalning kan minska de totala kostnaderna jämfört med en statisk beräkningsinstans.

Automatisk skalning av beräkning har begränsningar vid nedskalning av klusterstorlek för strukturerade strömningsarbetsbelastningar. Databricks rekommenderar att du använder Delta Live Tables med förbättrad automatisk skalning för arbetsbelastningar i realtid.

Använda automatisk avslutning

Azure Databricks innehåller flera funktioner som hjälper dig att kontrollera kostnaderna genom att minska inaktiva resurser och styra när beräkningsresurser kan distribueras.

• Konfigurera automatisk avslutning för alla interaktiva beräkningsresurser. Efter en angiven inaktivitetstid stängs beräkningsresursen av. Se Automatisk avslutning.
• För användningsfall där beräkning endast behövs under kontorstid kan beräkningsresurser konfigureras med automatisk avslutning och en schemalagd process kan starta om beräkning (och eventuellt förvärma data om det behövs) på morgonen innan användarna är tillbaka på sina skrivbord. Se CACHE SELECT.
• Om starttiderna för beräkning är för långa kan du överväga att använda klusterpooler i Metodtips för pooler. Azure Databricks-pooler är en uppsättning inaktiva instanser som är redo att användas. När klusternoder skapas med inaktiva instanser minskas tiden för klusterstart och automatisk skalning. Om poolerna inte har några inaktiva instanser expanderar poolerna genom att allokera en ny instans från instansprovidern för att hantera klustrets begäran.

Azure Databricks debiterar inte Databricks-enheter (DBUs) medan instanser är inaktiva i poolen, vilket resulterar i kostnadsbesparingar. Faktureringen för instansprovidern gäller.

Använda beräkningsprinciper för att kontrollera kostnader

Beräkningsprinciper kan framtvinga många kostnadsspecifika begränsningar för beräkningsresurser. Se Operational Excellence – Använda beräkningsprinciper. Till exempel:

• Aktivera klustrets automatiska skalning med ett visst minsta antal arbetsnoder.
• Aktivera automatisk avslutning av kluster med ett rimligt värde (till exempel 1 timme) för att undvika att betala för inaktiva tider.
• Se till att endast kostnadseffektiva VM-instanser kan väljas. Följ metodtipsen för klusterkonfiguration. Se rekommendationer för beräkningskonfiguration.
• Tillämpa en instansstrategi för oanvänd kapacitet.

3. Övervaka och kontrollera kostnader

Övervaka kostnader

Använd Azure Cost Manager för att analysera Kostnader för Azure Databricks. Taggar för beräkning och arbetsyta levereras också till Azure Cost Manager. Se Tagga kluster för kostnadstillskrivning.

Tagga kluster för kostnadstillskrivning

Om du vill övervaka kostnader i allmänhet och korrekt tillskriva Azure Databricks-användning till organisationens affärsenheter och team i återbetalningssyfte kan du tagga kluster, SQL-lager och pooler. Dessa taggar sprids till detaljerade Databricks-enheter (DBU) och molnleverantörens virtuella dator och bloblagringsanvändning för kostnadsanalys.

Se till att kostnadskontroll och tillskrivning beaktas när du konfigurerar arbetsytor och kluster för team och användningsfall. Detta effektiviserar taggningen och förbättrar noggrannheten för kostnadsattribution.

De totala kostnaderna omfattar den virtuella DBU-datorn, disken och eventuella tillhörande nätverkskostnader. För serverlösa SQL-lager inkluderar DBU-kostnaden redan de virtuella dator- och diskkostnaderna.

Taggarna för Azure Databricks-resurser kan användas i verktygen för kostnadsanalys i Azure-portalen

Implementera observerbarhet för att spåra och debitera kostnader

När du arbetar med komplexa tekniska ekosystem är det viktigt att proaktivt förstå det okända för att upprätthålla plattformens stabilitet och kontrollera kostnaderna. Med observerbarhet kan du analysera och optimera system baserat på de data de genererar. Detta skiljer sig från övervakning, som fokuserar på att identifiera nya mönster i stället för att spåra kända problem.

Databricks tillhandahåller utmärkta observerbarhetsfunktioner med hjälp av systemtabeller som är Databricks-värdbaserade analyslager för ett kundkontos driftdata som finns i systemkatalogen. De ger historisk observerbarhet över hela kontot och innehåller användarvänlig tabellinformation om plattformstelemetri.

Se Blogg: Balansera kostnadsoptimering och tillförlitlighet på Databricks på ett intelligent sätt

Dela kostnadsrapporter regelbundet

Generera månatliga kostnadsrapporter för att spåra förbrukningstillväxt och avvikelser. Dela dessa rapporter efter användningsfall eller team med de team som äger arbetsbelastningarna med hjälp av klustertaggning. Detta eliminerar överraskningar och gör det möjligt för team att proaktivt justera sina arbetsbelastningar om kostnaderna blir för höga.

Övervaka och hantera utgående kostnader för deltadelning

Till skillnad från andra datadelningsplattformar kräver Delta-delning inte datareplikering. Den här modellen har många fördelar, men det innebär att molnleverantören kan ta ut avgifter för utgående data när du delar data mellan moln eller regioner. Se Övervaka och hantera utgående kostnader för Delta Sharing (för leverantörer) för att övervaka och hantera utgående kostnader.

4. Utforma kostnadseffektiva arbetsbelastningar

Balansera alltid på och utlöst direktuppspelning

Traditionellt, när folk tänker på streaming, kommer termer som "realtid", "24/7" eller "alltid på" att tänka på. Om datainmatning sker i realtid måste de underliggande beräkningsresurserna köras dygnet om, vilket medför kostnader varje timme på dagen.

Men inte alla användningsfall som förlitar sig på en kontinuerlig ström av händelser kräver att dessa händelser omedelbart läggs till i analysdatauppsättningen. Om affärskravet för användningsfallet endast kräver nya data med några timmars mellanrum eller varje dag kan det kravet uppfyllas med bara några få körningar per dag, vilket resulterar i en betydande minskning av arbetsbelastningskostnaden. Databricks rekommenderar att du använder Structured Streaming med AvailableNow utlösaren för inkrementella arbetsbelastningar som inte har krav på låg svarstid. Se Konfigurera inkrementell batchbearbetning.

Balans mellan instanser på begäran och kapacitetsöverskott

Spot-instanser drar nytta av överskott av virtuella datorresurser i molnet som är tillgängliga till ett lägre pris. För att spara kostnader har Azure Databricks stöd för att skapa kluster med hjälp av instanser av oanvänd kapacitet. Databricks rekommenderar att den första instansen (Spark-drivrutinen) alltid ska vara en virtuell dator på begäran. Spot-instanser är ett bra val för arbetsbelastningar där det är acceptabelt att ta längre tid eftersom en eller flera spotinstanser har avlägsnats av molnleverantören.