Metodtips: Klusterkonfiguration

Azure Databricks innehåller ett antal alternativ när du skapar och konfigurerar kluster som hjälper dig att få bästa möjliga prestanda till lägsta kostnad. Den här flexibiliteten kan dock skapa utmaningar när du försöker fastställa optimala konfigurationer för dina arbetsbelastningar. Om du noga överväger hur användarna ska använda kluster kan du vägleda konfigurationsalternativen när du skapar nya kluster eller konfigurerar befintliga kluster. Några av de saker du bör tänka på när du fastställer konfigurationsalternativ är:

  • Vilken typ av användare kommer att använda klustret? En dataexpert kan köra olika jobbtyper med andra krav än en datatekniker eller dataanalytiker.
  • Vilka typer av arbetsbelastningar kommer användarna att köra i klustret? Till exempel har batch-jobb för extrahering, transformering och inläsning (ETL) sannolikt andra krav än analytiska arbetsbelastningar.
  • Vilken servicenivåavtal (SLA) behöver du uppfylla?
  • Vilka budgetbegränsningar har du?

Den här artikeln innehåller rekommendationer för klusterkonfiguration för olika scenarier baserat på dessa överväganden. Den här artikeln beskriver också specifika funktioner i Azure Databricks-kluster och överväganden att tänka på för dessa funktioner.

Konfigurationsbesluten kräver en kompromiss mellan kostnad och prestanda. Den primära kostnaden för ett kluster omfattar de Databricks-enheter (DBUs) som förbrukas av klustret och kostnaden för de underliggande resurser som behövs för att köra klustret. Vad som kanske inte är uppenbart är de sekundära kostnaderna, till exempel kostnaden för ditt företag att inte uppfylla ett serviceavtal, minskad effektivitet för anställda eller eventuellt slöseri med resurser på grund av dåliga kontroller.

Klusterfunktioner

Innan du diskuterar mer detaljerade scenarier för klusterkonfiguration är det viktigt att förstå vissa funktioner i Azure Databricks-kluster och hur du bäst använder dessa funktioner.

Kluster och jobbkluster för alla syften

När du skapar ett kluster väljer du en klustertyp: ett kluster för alla syften eller ett jobbkluster. Kluster för alla syften kan delas av flera användare och är bäst för att utföra ad hoc-analys, datautforskning eller utveckling. När du har implementerat bearbetningen och är redo att operationalisera koden växlar du till att köra den i ett jobbkluster. Jobbkluster avslutas när jobbet slutar, vilket minskar resursanvändningen och kostnaden.

Klusterläge

Anteckning

Den här artikeln beskriver det äldre användargränssnittet för kluster. Mer information om användargränssnittet för förhandsversionen finns i Skapa ett kluster. Detta inkluderar vissa terminologiändringar av klusteråtkomsttyper och -lägen. En jämförelse av de nya och äldre klustertyperna finns i Kluster användargränssnittsändringar och klusteråtkomstlägen. I förhandsgranskningsgränssnittet:

  • Standardlägeskluster kallas nu kluster för delat åtkomstläge utan isolering.
  • Hög samtidighet med ACL:er för tabeller kallas nu kluster för delat åtkomstläge.

Azure Databricks stöder tre klusterlägen: Standard, Hög samtidighet och Enskild nod. De flesta vanliga användare använder Standard- eller Single Node-kluster.

Varning

Kluster i standardläge (kallas ibland delade kluster utan isolering) kan delas av flera användare, utan isolering mellan användare. Om du använder klusterläget Hög samtidighet utan ytterligare säkerhetsinställningar, till exempel tabell-ACL:er eller genomströmning av autentiseringsuppgifter, används samma inställningar som kluster i standardläge. Kontoadministratörer kan förhindra att interna autentiseringsuppgifter genereras automatiskt för Databricks-arbetsyteadministratörer i dessa typer av kluster. För säkrare alternativ rekommenderar Databricks alternativ, till exempel kluster med hög samtidighet med tabell-ACL:er.

  • Standardkluster rekommenderas endast för enskilda användare. Standardkluster kan köra arbetsbelastningar som utvecklats i Python, SQL, R och Scala.
  • Kluster med en nod är avsedda för jobb som använder små mängder data eller icke-distribuerade arbetsbelastningar, till exempel maskininlärningsbibliotek med en nod.
  • Kluster med hög samtidighet är idealiska för grupper av användare som behöver dela resurser eller köra ad hoc-jobb. Administratörer skapar vanligtvis kluster med hög samtidighet. Databricks rekommenderar att du aktiverar automatisk skalning för kluster med hög samtidighet.

Instanser på begäran och oanvänd kapacitet

För att spara kostnader har Azure Databricks stöd för att skapa kluster med hjälp av en kombination av instanser på begäran och oanvänd kapacitet. Du kan använda spotinstanser för att dra nytta av outnyttjad kapacitet i Azure för att minska kostnaden för att köra dina program, öka programmets beräkningskapacitet och öka dataflödet.

Automatisk skalning

Med autoskalning kan kluster ändra storlek automatiskt baserat på arbetsbelastningar. Autoskalning kan dra nytta av många användningsfall och scenarier ur både kostnads- och prestandaperspektiv, men det kan vara svårt att förstå när och hur du använder autoskalning. Följande är några saker att tänka på när du ska avgöra om du ska använda autoskalning och hur du får ut mest av fördelarna:

  • Autoskalning minskar vanligtvis kostnaderna jämfört med ett kluster med fast storlek.
  • Arbetsbelastningar för automatisk skalning kan köras snabbare jämfört med ett underetablerad kluster med fast storlek.
  • Vissa arbetsbelastningar är inte kompatibla med kluster för automatisk skalning, inklusive spark-submit-jobb och vissa Python-paket.
  • Med kluster för alla syften för en användare kan användare upptäcka att autoskalning saktar ned deras utveckling eller analys när det minsta antalet arbetare har angetts som för lågt. Detta beror på att de kommandon eller frågor som de kör ofta är flera minuters mellanrum, tid då klustret är inaktivt och kan skalas ned för att spara på kostnaderna. När nästa kommando körs försöker klusterhanteraren skala upp, vilket tar några minuter när instanser hämtas från molnleverantören. Under den här tiden kan jobb köras med otillräckliga resurser, vilket gör att tiden för att hämta resultat går långsammare. Samtidigt som en ökning av det minsta antalet arbetstagare bidrar, ökar det också kostnaderna. Det här är ett annat exempel där kostnader och prestanda måste balanseras.
  • Om deltacachelagring används är det viktigt att komma ihåg att cachelagrade data på en nod går förlorade om noden avslutas. Om det är viktigt att behålla cachelagrade data för din arbetsbelastning bör du överväga att använda ett kluster med fast storlek.
  • Om du har ett jobbkluster som kör en ETL-arbetsbelastning kan du ibland ändra storleken på klustret på rätt sätt när du justerar om du vet att jobbet sannolikt inte kommer att ändras. Autoskalning ger dig dock flexibilitet om dina datastorlekar ökar. Det är också värt att notera att optimerad autoskalning kan minska kostnaderna med långvariga jobb om det finns långa perioder när klustret är underutnyttrat eller väntar på resultat från en annan process. Men återigen kan jobbet drabbas av mindre fördröjningar när klustret försöker skala upp på rätt sätt. Om du har snäva serviceavtal för ett jobb kan ett kluster med fast storlek vara ett bättre alternativ eller överväga att använda en Azure Databricks-pool för att minska klustrets starttider.

Azure Databricks stöder även automatisk skalning av lokal lagring. Med lokal lagring för automatisk skalning övervakar Azure Databricks mängden ledigt diskutrymme som är tillgängligt för spark-arbetarna i klustret. Om en arbetare börjar få ont om disk ansluter Azure Databricks automatiskt en ny hanterad volym till arbetaren innan diskutrymmet tar slut.

Pooler

Pooler minskar start- och uppskalningstider för kluster genom att upprätthålla en uppsättning tillgängliga, färdiga instanser. Databricks rekommenderar att du drar nytta av pooler för att förbättra bearbetningstiden samtidigt som kostnaderna minimeras.

Databricks Runtime-versioner

Databricks rekommenderar att du använder den senaste Databricks Runtime-versionen för kluster för alla syften. Med den senaste versionen ser du till att du har de senaste optimeringarna och den senaste kompatibiliteten mellan din kod och förinstallerade paket.

Överväg att använda Databricks Runtime-versionen (Long Term Support) för jobbkluster som kör driftsarbetsbelastningar. Om du använder LTS-versionen ser du till att du inte stöter på kompatibilitetsproblem och kan testa arbetsbelastningen noggrant innan du uppgraderar. Om du har ett avancerat användningsfall kring maskininlärning bör du överväga den specialiserade Databricks Runtime-versionen.

Klusterprinciper

Med Azure Databricks-klusterprinciper kan administratörer framtvinga kontroller över skapande och konfiguration av kluster. Databricks rekommenderar att du använder klusterprinciper för att tillämpa rekommendationerna som beskrivs i den här guiden. Läs mer om klusterprinciper i guiden metodtips för klusterprinciper.

Automatisk avslutning

Många användare tror inte att de ska avsluta sina kluster när de är klara med att använda dem. Som tur är avslutas kluster automatiskt efter en viss period, med standardvärdet 120 minuter.

Administratörer kan ändra den här standardinställningen när de skapar klusterprinciper. Om du minskar den här inställningen kan du sänka kostnaden genom att minska tiden som kluster är inaktiva. Det är viktigt att komma ihåg att när ett kluster avslutas går allt tillstånd förlorat, inklusive alla variabler, temporära tabeller, cacheminnen, funktioner, objekt och så vidare. Allt detta tillstånd måste återställas när klustret startar igen. Om en utvecklare kliver ut för en 30-minuters lunchpaus skulle det vara slösaktigt att spendera samma tid på att få tillbaka en anteckningsbok till samma tillstånd som tidigare.

Viktigt

Inaktiva kluster fortsätter att ackumulera DBU- och molninstansavgifter under inaktivitetsperioden före avslutningen.

Skräpinsamling

Det kan vara mindre uppenbart än andra överväganden som beskrivs i den här artikeln, men att vara uppmärksam på skräpinsamling kan hjälpa dig att optimera jobbprestanda i dina kluster. Att tillhandahålla en stor mängd RAM-minne kan hjälpa jobb att utföra mer effektivt, men kan också leda till fördröjningar vid skräpinsamling.

Undvik att distribuera kluster med stora mängder RAM-minne som konfigurerats för varje instans för att minimera effekten av långa skräpinsamlingsrensningar. Om fler RAM-minne allokeras till utföraren leder det till längre skräpinsamlingstider. Konfigurera i stället instanser med mindre RAM-storlekar och distribuera fler instanser om du behöver mer minne för dina jobb. Det finns dock fall där färre noder med mer RAM rekommenderas, till exempel arbetsbelastningar som kräver många blandningar, enligt beskrivningen i Överväganden för klusterstorlek.

Åtkomstkontroll för kluster

Du kan konfigurera två typer av klusterbehörigheter:

  • Behörigheten Tillåt klusterskapande styr möjligheten för användare att skapa kluster.
  • Behörigheter på klusternivå styr möjligheten att använda och ändra ett visst kluster.

Mer information om hur du konfigurerar klusterbehörigheter finns i Åtkomstkontroll för kluster.

Du kan skapa ett kluster om du antingen har behörighet att skapa kluster eller åtkomst till en klusterprincip, vilket gör att du kan skapa valfritt kluster inom principens specifikationer. Klusterskaparen är ägare och har behörigheten Kan hantera, vilket gör att de kan dela den med andra användare inom begränsningarna för dataåtkomstbehörigheterna för klustret.

Det är viktigt att förstå klusterbehörigheter och klusterprinciper när du bestämmer dig för klusterkonfigurationer för vanliga scenarier.

Klustertaggar

Med klustertaggar kan du enkelt övervaka kostnaden för molnresurser som används av olika grupper i din organisation. Du kan ange taggar som nyckel/värde-strängar när du skapar ett kluster, och Azure Databricks tillämpar dessa taggar på molnresurser, till exempel instanser och EBS-volymer. Läs mer om taggtillämpning i guiden metodtips för klusterprinciper.

Överväganden för klusterstorlekar

Azure Databricks kör en utförare per arbetsnod. Därför används termerna executor och worker 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 executor-kärnor (beräkning): Det totala antalet kärnor för alla utförare. Detta avgör den maximala parallelliteten för ett kluster.
  • 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 spills till disken.
  • Lokal lagring för utförare: Typ och mängd lokal disklagring. Lokal disk används främst vid spill under blandningar och cachelagring.

Ytterligare överväganden är arbetsinstanstyp och -storlek, som också påverkar faktorerna ovan. Tänk på följande när du ändrar storlek på klustret:

  • Hur mycket data kommer din arbetsbelastning att förbruka?
  • Vad är beräkningskomplexiteten för din arbetsbelastning?
  • Varifrån läser du data?
  • Hur partitioneras data i extern lagring?
  • Hur mycket parallellitet behöver du?

Svar på dessa frågor hjälper dig att fastställa optimala klusterkonfigurationer baserat på arbetsbelastningar. För enkla ETL-arbetsbelastningar som endast använder smala transformeringar (transformeringar där varje indatapartition endast bidrar till en utdatapartition) fokuserar du på en beräkningsoptimerad konfiguration. Om du förväntar dig en hel del blandningar är mängden minne viktigt, samt lagring för att ta hänsyn till datautsläpp. Färre stora instanser kan minska nätverkets I/O vid överföring av data mellan datorer under shuffle-heavy-arbetsbelastningar.

Det finns en balansgång mellan antalet arbetare och storleken på arbetsinstanstyperna. Ett kluster med två arbetare, var och en med 40 kärnor och 100 GB RAM-minne, har samma beräkning och minne som ett åtta arbetskluster med 10 kärnor och 25 GB RAM-minne.

Om du förväntar dig många omläsningar av samma data kan dina arbetsbelastningar ha nytta av cachelagring. Överväg en lagringsoptimerad konfiguration med Delta Cache.

Exempel på klusterstorlek

I följande exempel visas klusterrekommendationer baserat på specifika typer av arbetsbelastningar. De här exemplen omfattar även konfigurationer att undvika och varför dessa konfigurationer inte är lämpliga för arbetsbelastningstyperna.

Dataanalys

Dataanalytiker utför vanligtvis bearbetning som kräver data från flera partitioner, vilket leder till många shuffle-åtgärder. Ett kluster med ett mindre antal noder kan minska nätverket och disk-I/O som behövs för att utföra dessa blandningar. Kluster A i följande diagram är förmodligen det bästa valet, särskilt för kluster som stöder en enskild analytiker.

Kluster D ger förmodligen sämre prestanda eftersom ett större antal noder med mindre minne och lagring kräver mer blandning av data för att slutföra bearbetningen.

Storleksändring av dataanalyskluster

Analytiska arbetsbelastningar kräver troligen att samma data läss upprepade gånger, så rekommenderade arbetstyper är lagringsoptimerade med Delta Cache aktiverat.

Ytterligare funktioner som rekommenderas för analytiska arbetsbelastningar är:

  • Aktivera automatisk avslutning för att säkerställa att kluster avslutas efter en period av inaktivitet.
  • Överväg att aktivera autoskalning baserat på analytikerns typiska arbetsbelastning.
  • Överväg att använda pooler, vilket gör det möjligt att begränsa kluster till förgodkända instanstyper och säkerställa konsekventa klusterkonfigurationer.

Funktioner som förmodligen inte är användbara:

  • Automatisk skalning av lagring, eftersom den här användaren förmodligen inte kommer att producera mycket data.
  • Kluster med hög samtidighet, eftersom det här klustret är för en enskild användare och kluster med hög samtidighet passar bäst för delad användning.

Grundläggande batch-ETL

Enkla batch-ETL-jobb som inte kräver breda omvandlingar, till exempel kopplingar eller aggregeringar, drar vanligtvis nytta av kluster som är beräkningsoptimerade. För dessa typer av arbetsbelastningar är alla kluster i följande diagram sannolikt acceptabla.

Basic batch ETL-klusterstorlek

Beräkningsoptimerade arbetstyper rekommenderas. Dessa blir billigare, och dessa arbetsbelastningar kommer sannolikt inte att kräva betydande minne eller lagring.

Användning av en pool kan vara en fördel för kluster som stöder enkla ETL-jobb genom att minska antalet starttider för kluster och minska den totala körningen vid körning av jobbpipelines. Men eftersom dessa typer av arbetsbelastningar vanligtvis körs som schemalagda jobb där klustret bara körs tillräckligt länge för att slutföra jobbet, kanske det inte ger någon fördel att använda en pool.

Följande funktioner är förmodligen inte användbara:

  • Deltacachelagring eftersom det inte är förväntat att läsa data igen.
  • Automatisk avslutning krävs förmodligen inte eftersom dessa troligen är schemalagda jobb.
  • Autoskalning rekommenderas inte eftersom beräkning och lagring bör förkonfigureras för användningsfallet.
  • Kluster med hög samtidighet är avsedda för flera användare och gynnar inte ett kluster som kör ett enda jobb.

Komplex batch-ETL

Mer komplexa ETL-jobb, till exempel bearbetning som kräver unioner och kopplingar mellan flera tabeller, fungerar förmodligen bäst när du kan minimera mängden data som blandas. Eftersom en minskning av antalet arbetare i ett kluster hjälper till att minimera blandningar bör du överväga ett mindre kluster som kluster A i följande diagram över ett större kluster som kluster D.

Komplex storleksändring av ETL-kluster

Komplexa transformeringar kan vara beräkningsintensiva, så för vissa arbetsbelastningar som når ett optimalt antal kärnor kan det krävas att ytterligare noder läggs till i klustret.

Precis som enkla ETL-jobb rekommenderas beräkningsoptimerade arbetstyper. Dessa blir billigare, och dessa arbetsbelastningar kommer sannolikt inte att kräva betydande minne eller lagring. Precis som enkla ETL-jobb är dessutom huvudklusterfunktionen att överväga pooler för att minska antalet starttider för kluster och minska den totala körningen vid körning av jobbpipelines.

Följande funktioner är förmodligen inte användbara:

  • Deltacachelagring eftersom det inte är förväntat att läsa data igen.
  • Automatisk avslutning krävs förmodligen inte eftersom dessa troligen är schemalagda jobb.
  • Autoskalning rekommenderas inte eftersom beräkning och lagring bör förkonfigureras för användningsfallet.
  • Kluster med hög samtidighet är avsedda för flera användare och gynnar inte ett kluster som kör ett enda jobb.

Träna maskininlärningsmodeller

Eftersom inledande iterationer av träning av en maskininlärningsmodell ofta är experimentella är ett mindre kluster, till exempel kluster A, ett bra val. Ett mindre kluster minskar också effekten av blandningar.

Om stabilitet är ett problem, eller för mer avancerade faser, kan ett större kluster, till exempel kluster B eller C, vara ett bra val.

Ett stort kluster, till exempel kluster D, rekommenderas inte på grund av omkostnaderna för att blanda data mellan noder.

Storleksändring av maskininlärningskluster

Rekommenderade arbetstyper är lagringsoptimerade med Delta-cachelagring aktiverat för att ta hänsyn till upprepade läsningar av samma data och för att aktivera cachelagring av träningsdata. Om de beräknings- och lagringsalternativ som tillhandahålls av lagringsoptimerade noder inte är tillräckliga kan du överväga GPU-optimerade noder. En möjlig nackdel är bristen på deltacachelagringsstöd med dessa noder.

Ytterligare funktioner som rekommenderas för analytiska arbetsbelastningar är:

  • Aktivera automatisk avslutning för att säkerställa att kluster avslutas efter en period av inaktivitet.
  • Överväg att aktivera autoskalning baserat på analytikerns typiska arbetsbelastning.
  • Använd pooler, vilket gör det möjligt att begränsa kluster till förgodkända instanstyper och säkerställa konsekventa klusterkonfigurationer.

Funktioner som förmodligen inte är användbara:

  • Autoskalning eftersom cachelagrade data kan gå förlorade när noder tas bort när ett kluster skalar ned. Dessutom förbrukar vanliga maskininlärningsjobb ofta alla tillgängliga noder, vilket innebär att autoskalning inte ger någon fördel.
  • Automatisk skalning av lagring, eftersom den här användaren förmodligen inte kommer att producera mycket data.
  • Kluster med hög samtidighet, eftersom det här klustret är för en enskild användare och kluster med hög samtidighet passar bäst för delad användning.

Vanliga scenarier

Följande avsnitt innehåller ytterligare rekommendationer för att konfigurera kluster för vanliga mönster för klusteranvändning:

  • Flera användare som kör dataanalys och ad hoc-bearbetning.
  • Specialiserade användningsfall som maskininlärning.
  • Stöd för schemalagda batchjobb.

Kluster för flera användare

Scenario

Du måste ge flera användare åtkomst till data för att köra dataanalys och ad hoc-frågor. Klusteranvändningen kan variera över tid och de flesta jobb är inte särskilt resursintensiva. Användarna behöver främst skrivskyddad åtkomst till data och vill utföra analyser eller skapa instrumentpaneler via ett enkelt användargränssnitt.

Den rekommenderade metoden för klusteretablering är en hybridmetod för nodetablering i klustret tillsammans med autoskalning. En hybridmetod innebär att definiera antalet instanser på begäran och spotinstanser för klustret och aktivera automatisk skalning mellan det lägsta och högsta antalet instanser.

Scenario för flera användare

Det här klustret är alltid tillgängligt och delas av användare som tillhör en grupp som standard. Genom att aktivera autoskalning kan klustret skala upp och ned beroende på belastningen.

Användarna har inte åtkomst till att starta/stoppa klustret, men de första instanserna på begäran är omedelbart tillgängliga för att svara på användarfrågor. Om användarfrågan kräver mer kapacitet etablerar autoskalning automatiskt fler noder (främst oanvända instanser) för att hantera arbetsbelastningen.

Azure Databricks har andra funktioner för att ytterligare förbättra användningsfall för flera innehavare:

Den här metoden håller nere den totala kostnaden genom att:

  • Använda en delad klustermodell.
  • Använda en blandning av instanser på begäran och oanvänd kapacitet.
  • Använd autoskalning för att undvika att betala för underutnyttlade kluster.

Specialiserade arbetsbelastningar

Scenario

Du måste tillhandahålla kluster för specialiserade användningsfall eller team inom din organisation, till exempel dataforskare som kör komplexa datautforsknings- och maskininlärningsalgoritmer. Ett typiskt mönster är att en användare behöver ett kluster under en kort period för att köra analysen.

Den bästa metoden för den här typen av arbetsbelastning är att skapa klusterprinciper med fördefinierade konfigurationer för standard-, fast- och inställningsintervall. De här inställningarna kan omfatta antalet instanser, instanstyper, instanser för oanvänd kapacitet jämfört med på begäran-instanser, roller, bibliotek som ska installeras och så vidare. Med hjälp av klusterprinciper kan användare med mer avancerade krav snabbt starta kluster som de kan konfigurera efter behov för sitt användningsfall och framtvinga kostnader och efterlevnad av principer.

Specialiserade arbetsbelastningar

Den här metoden ger mer kontroll till användare samtidigt som du behåller möjligheten att hålla kostnaderna under kontroll genom att definiera klusterkonfigurationer i förväg. På så sätt kan du också konfigurera kluster för olika grupper av användare med behörighet att komma åt olika datauppsättningar.

En nackdel med den här metoden är att användarna måste arbeta med administratörer för eventuella ändringar i kluster, till exempel konfiguration, installerade bibliotek och så vidare.

Batch-arbetsbelastningar

Scenario

Du måste ange kluster för schemalagda batchjobb, till exempel ETL-produktionsjobb som utför förberedelse av data. Den rekommenderade metoden är att starta ett nytt kluster för varje jobbkörning. Genom att köra varje jobb i ett nytt kluster kan du undvika fel och missade serviceavtal som orsakas av andra arbetsbelastningar som körs i ett delat kluster. Beroende på nivån av allvarlighetsgrad för jobbet kan du använda alla instanser på begäran för att uppfylla serviceavtal eller balansera mellan instanser för oanvänd kapacitet och på begäran för kostnadsbesparingar.

Schemalagda batcharbetsbelastningar