Metodtips: Klusterkonfiguration

Azure Databricks innehåller ett antal alternativ när du skapar och konfigurerar kluster för att få bästa möjliga prestanda till den lägsta kostnaden. Den här flexibiliteten kan dock skapa utmaningar när du försöker fastställa optimala konfigurationer för dina arbetsbelastningar. Genom att noga överväga hur användarna kommer att använda kluster får du hjälp med konfigurationsalternativen när du skapar nya kluster eller konfigurerar befintliga kluster. Några saker att 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? Batch-extraherings-, transformerings- och inläsningsjobb (ETL) har troligen 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 även specifika funktioner Azure Databricks kluster och överväganden att tänka på för dessa funktioner.

Dina konfigurationsbeslut 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. Det som kanske inte är uppenbart är de sekundära kostnaderna, till exempel kostnaden för att din verksamhet inte uppfyller ett serviceavtal, minskad personaleffektivitet eller eventuellt slöseri med resurser på grund av dåliga kontroller.

Klusterfunktioner

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

Kluster för alla syften och jobbkluster

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 ad hoc-analys, datagranskning eller utveckling. När du har slutfört implementeringen av bearbetningen och är redo att operationalisera koden växlar du till att köra den i ett jobbkluster. Jobbkluster avslutas när jobbet avslutas, vilket minskar resursanvändningen och kostnaden.

Klusterläge

Azure Databricks har stöd för tre klusterlägen:Standard, Hög samtidighet och Enskild nod. De flesta vanliga användare använder standardkluster eller kluster med en nod.

  • Standardkluster är idealiska för bearbetning av stora mängder data med Apache Spark.
  • 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 autoskalning för kluster med hög samtidighet.

Instanser på begäran och för punkt

För att spara pengar Azure Databricks stöd för att skapa kluster med en kombination av instanser på begäran och punktinstanser. 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, utö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 autoskalning ska användas. Här följer 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 mesta 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 underetableringskluster 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 det hända att autoskalning gör utvecklingen eller analysen långsammare när det minsta antalet arbetare är för lågt. Det beror på att de kommandon eller frågor som körs ofta har flera minuters mellanrum, och att klustret är inaktivt och kan skalas ned för att minska kostnaderna. När nästa kommando körs försöker klusterhanteraren skala upp, vilket tar några minuter medan 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. Att öka det minsta antalet arbetare hjälper, men det ökar också kostnaderna. Det här är ett annat exempel där kostnader och prestanda måste balanseras.
  • Om Delta-cachelagring 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 när du finjusterar om du vet att jobbet troligen kommer att ändras. Autoskalning ger dock flexibilitet om datastorlekarna ökar. Det är också värt att notera att optimerad automatisk skalning kan minska kostnaderna med långvariga jobb om det finns långa perioder när klustret underutnyttjas eller väntar på resultat från en annan process. Men återigen kan jobbet uppleva mindre fördröjningar när klustret försöker skala upp på rätt sätt. Om du har nära serviceavtal för ett jobb kan ett kluster med fast storlek vara ett bättre val eller överväga att använda en Azure Databricks-pool för att minska klustrets starttider.

Azure Databricks har även stöd för automatisk skalning av lokal lagring. Med lokal lagring för automatisk skalning kan Azure Databricks övervaka mängden ledigt diskutrymme som är tillgängligt på klustrets Spark-arbetare. Om en arbetsroll börjar få slut på disk Azure Databricks automatiskt en ny hanterad volym till arbetsrollen innan diskutrymmet tar slut.

Pooler

Pooler minskar klustrets start- och uppskalningstider genom att upprätthålla en uppsättning tillgängliga instanser som är redo att användas. Databricks rekommenderar att du använder pooler för att förbättra bearbetningstiden samtidigt som kostnaderna minimeras.

Databricks Runtime versioner

Databricks rekommenderar att du använder Databricks Runtime senaste 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.

För jobbkluster som kör arbetsbelastningar bör du överväga att använda LTS -versionen (Long Term Support) Databricks Runtime arbetsbelastningar. Genom att använda LTS-versionen ser du till att du inte får kompatibilitetsproblem och kan testa arbetsbelastningen noggrant innan du uppgraderar. Om du har ett avancerat användningsfall för maskininlärning eller genomik kan du överväga de Databricks Runtime versionerna.

Klusterprinciper

Azure Databricks klusterprinciper gör det möjligt för administratörer att framtvinga kontroller för 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 metodtipsen 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 kostnaderna genom att minska tiden som klustren ä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 tar en lunchrast på 30 minuter är det slöseri att ägna samma tid åt att få tillbaka en notebook-dator till samma tillstånd som tidigare.

Viktigt

Inaktiva kluster fortsätter att ackumulera DBU- och molninstansavgifter under inaktivitetsperioden innan de avslutas.

Skräpinsamling

Även om det kan vara mindre uppenbart än andra överväganden som beskrivs i den här artikeln kan skräpinsamling vara till hjälp för att optimera jobbprestanda i dina kluster. Att tillhandahålla en stor mängd RAM-minne kan hjälpa jobb att prestera 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äpinsamlingssvepar. Att ha mer RAM-minne allokerat till utföraren leder 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-minne rekommenderas, till exempel arbetsbelastningar som kräver mycket blandningar, enligt vad som beskrivs i Överväganden för klusterändring.

Åtkomstkontroll för kluster

Du kan konfigurera två typer av klusterbehörigheter:

  • Behörigheten Tillåt att kluster skapas styr användarnas möjlighet att skapa kluster.
  • Behörigheter på klusternivå styr möjligheten att använda och ändra ett specifikt 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 har åtkomst till en klusterprincip, vilket gör att du kan skapa kluster inom principens specifikationer. Klusterskaparen är ägare och har behörigheten Kan hantera, vilket gör det möjligt för dem att dela den med andra användare inom begränsningarna för dataåtkomstbehörigheter 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 dessa taggar för molnresurser, till exempel instanser och EBS-volymer. Läs mer om tvingande taggar i guiden med metodtips för klusterprinciper.

Överväganden för klusterändring

Azure Databricks kör en utförare per arbetsnod. Därför används termerna executor och worker synonymt i kontexten för den Azure Databricks arkitekturen. Personer tänker ofta på klusterstorlek när det gäller 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 parallellitet 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 disk.
  • Lokal körbar lagring: Typ och mängd lokal disklagring. Lokal disk används främst för spill under blandningar och cachelagring.

Ytterligare överväganden omfattar typ av arbetsinstans och storlek, vilket även påverkar faktorerna ovan. Tänk på följande när du ska ändra 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?

Genom att besvara dessa frågor får du hjälp att fastställa optimala klusterkonfigurationer baserat på arbetsbelastningar. För enkla arbetsbelastningar i ETL-format som endast använder smala transformationer (transformationer där varje indatapartition endast bidrar till en utdatapartition) fokuserar du på en beräkningsoptimerad konfiguration. Om du förväntar dig mycket blandningar är mängden minne viktigt, samt lagring för att ta hänsyn till dataläckage. Färre stora instanser kan minska nätverks-I/O vid överföring av data mellan datorer under blandade arbetsbelastningar.

Det finns en balans mellan antalet arbetare och storleken på typer av arbetsinstanser. 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 nya läsningar av samma data kan dina arbetsbelastningar dra nytta av cachelagring. Överväg en lagringsoptimerad konfiguration med Delta Cache.

Exempel på klusterändring

I följande exempel visas klusterrekommendationer baserat på specifika typer av arbetsbelastningar. De här exemplen omfattar även konfigurationer som ska undvikas 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ämst prestanda eftersom ett större antal noder med mindre minne och lagring kräver mer blandning av data för att slutföra bearbetningen.

Storlek på dataanalyskluster

Analytiska arbetsbelastningar kräver troligen läsning av samma data 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 tids inaktivitet.
  • Överväg att aktivera autoskalning baserat på analytikerns normala arbetsbelastning.
  • Överväg att använda pooler, vilket gör att du kan begränsa kluster till förgodkända instanstyper och säkerställa konsekventa klusterkonfigurationer.

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

  • Automatisk lagringsskalning 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 något av klustren i följande diagram godtagbara.

Enkel storleksändring för batch-ETL-kluster

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

Användning av en pool kan ge en fördel för kluster som stöder enkla ETL-jobb genom att minska klusterstarttiderna och minska den totala körningstiden när du kör 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 användningen av en pool inte ger någon fördel.

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

  • Deltacachelagring eftersom återläsning av data inte förväntas.
  • Automatisk avslutning krävs förmodligen inte eftersom dessa sannolikt är schemalagda jobb.
  • Automatisk skalning rekommenderas inte eftersom beräkning och lagring ska förkonfigureras för användningsfallet.
  • Kluster med hög samtidighet är avsedda för flera användare och kommer inte att ha nytta av ett kluster som kör ett enda jobb.

Komplex batch-ETL

Mer komplexa ETL-jobb, till exempel bearbetning som kräver unioner och kopplingar över 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 bidrar 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 transformationer 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 med enkla ETL-jobb rekommenderas beräkningsoptimerade arbetstyper. dessa blir billigare och dessa arbetsbelastningar kommer troligen inte att kräva betydande minne eller lagring. Precis som med enkla ETL-jobb är huvudklusterfunktionen att överväga pooler för att minska klusterstarttiderna och minska den totala körningstiden när du kör jobbpipelines.

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

  • Deltacachelagring eftersom återläsning av data inte förväntas.
  • Automatisk avslutning krävs förmodligen inte eftersom dessa sannolikt är schemalagda jobb.
  • Automatisk skalning rekommenderas inte eftersom beräkning och lagring ska förkonfigureras för användningsfallet.
  • Kluster med hög samtidighet är avsedda för flera användare och kommer inte att ha nytta av 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 steg, 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.

Storlek på maskininlärningskluster

Rekommenderade arbetstyper är lagringsoptimerade med Delta-cachelagring aktiverat för upprepade läsningar av samma data och för att möjliggöra cachelagring av träningsdata. Om beräknings- och lagringsalternativen som tillhandahålls av lagringsoptimerade noder inte är tillräckliga kan du överväga GPU-optimerade noder. En möjlig nackdel är bristen på stöd för Delta-cachelagring 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 tids inaktivitet.
  • Överväg att aktivera autoskalning baserat på analytikerns normala arbetsbelastning.
  • Använd pooler, vilket gör att du kan begränsa kluster till förgodkända instanstyper och säkerställa konsekventa klusterkonfigurationer.

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

  • Automatisk skalning eftersom cachelagrade data kan gå förlorade när noder tas bort när ett kluster skalas ned. Dessutom förbrukar vanliga maskininlärningsjobb ofta alla tillgängliga noder, vilket innebär att autoskalning inte ger några fördelar.
  • Automatisk lagringsskalning 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 klusteranvändningsmönster:

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

Kluster med 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 skrivskyddat å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 hybridmodell för nodetablering i klustret tillsammans med autoskalning. En hybridmodell innebär att definiera antalet instanser på begäran och instanser för oskadd plats 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 de användare som tillhör en grupp som standard. Om du aktiverar 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, tillser autoskalning automatiskt fler noder (främst spotinstanser) för att hantera arbetsbelastningen.

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

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

  • Använda en modell för delat kluster.
  • Använda en blandning av instanser på begäran och spot.
  • Använd autoskalning för att undvika att betala för underutnyttjade kluster.

Specialiserade arbetsbelastningar

Scenario

Du måste tillhandahålla kluster för specialiserade användningsfall eller team i din organisation, till exempel dataforskare som kör komplex datagranskning och maskininlärningsalgoritmer. Ett vanligt mönster är att en användare behöver ett kluster under en kort period för att köra sin analys.

Den bästa metoden för den här typen av arbetsbelastning är att skapa klusterprinciper med fördefinierade konfigurationer för standardintervall, fasta intervall och inställningar. De här inställningarna kan omfatta antalet instanser, instanstyper, punktinstanser jämfört med instanser på begäran, roller, bibliotek som ska installeras och så vidare. Med hjälp av klusterprinciper kan användare med mer avancerade krav snabbt skapa kluster som de kan konfigurera efter behov för sitt användningsfall och tillämpa kostnader och efterlevnad av principer.

Specialiserade arbetsbelastningar

Den här metoden ger mer kontroll till användarna 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 datamängder.

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 produktions-ETL-jobb som utför förberedelse av data. Den rekommenderade bästa praxis ä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å hur kritiskt jobbet är kan du använda alla instanser på begäran för att uppfylla serviceavtal eller balansera mellan instanser för punkt och på begäran för kostnadsbesparingar.

Schemalagda batcharbetsbelastningar