Metodtips för klassisk beräkningskonfiguration

På den här sidan beskrivs metodtips för att konfigurera klassiska beräkningsresurser. För de flesta nya arbetsbelastningar rekommenderar Databricks att du använder serverlös beräkning, vilket inte kräver någon konfiguration. Om din arbetsbelastning inte stöds för serverlös beräkning (se Serverlösa begränsningar) använder du följande metodtips för att konfigurera en klassisk beräkningsresurs.

Åtkomstläge

Klassiska beräkningsresurser kan tilldelas till antingen standard- eller dedikerat åtkomstläge, som avgör vem som kan ansluta till och använda beräkningsresursen.

Databricks rekommenderar att du använder standardåtkomstläge för de flesta arbetsbelastningar. Standardberäkning kan delas av flera användare och grupper samtidigt som användarisolering upprätthålls och alla behörigheter för dataåtkomst respekteras. Detta gör det till ett enklare och kostnadseffektivt alternativ för de flesta arbetsbelastningar.

Använd endast dedikerat åtkomstläge om din arbetsbelastning har specifika standardberäkningsbegränsningar, till exempel ML Runtime på GPU, RDD-API:er eller R. Mer information finns i Standardkrav och begränsningar för beräkning.

Om Unity Catalog är aktiverat ska du inte ange spark.databricks.passthrough.enabled. Vidarebefordran av autentiseringsuppgifter är ett äldre läge för åtkomst som inte är kompatibelt med Unity Catalog.

Se Åtkomstlägen.

version av Databricks Runtime

Använd den senaste versionen av LTS Databricks Runtime med långsiktig support. LTS-versioner får utökade säkerhetskorrigeringar och buggkorrigeringar, vilket säkerställer att dina arbetsbelastningar förblir stabila och kompatibla med de senaste plattformsfunktionerna.

Välj endast en maskininlärningskörning om din arbetsbelastning använder GPU:er, distribuerad ML-träning eller AutoML. Databricks Runtime för ML installerar en stor uppsättning bibliotek som kan komma i konflikt med dina egna beroenden om de inte behövs, vilket kan orsaka fel eller tysta korrekthetsproblem. Se Träna AI- och ML-modeller.

Konfigurationshygien

Dessa metoder håller dina beräkningskonfigurationer rena och dina arbetsbelastningar portabla.

Undvik att använda init-skript

Init-skript kan introducera oväntade beteenden, inklusive bibliotekskonflikter som bryter arbetsbelastningar och gör miljöer mindre förutsägbara. Lägg i stället till bibliotek i dina beräkningsprinciper, använd %pip install i notebook-filer eller definiera beroenden i en miljöspecifikation. Se Lägga till bibliotek i en princip.

Undvik att hårdkoda Spark-konfigurationer

Undvik hårdkodning av Spark-konfigurationer (till exempel spark.executor.memory eller spark.dynamicAllocation.*) i beräknings- eller jobbdefinitioner. Hårdkodade värden åsidosätter de inbyggda optimeringar som Azure Databricks tillhandahåller, vilket ofta leder till slösade utgifter eller försämrade prestanda. Använd endast sessionskonfigurationer på notebooknivå när du har en specifik anledning att åsidosätta en standardinställning.

Undvik beräkningslokala lagringssökvägar

Lagra inte data på beräkningslokala sökvägar, som inte bevaras utanför beräkningens livscykel. Använd i stället Unity Catalog-volymer eller tillfällig lagring. Se Vad är volymer?.

Undvik DBFS-monteringar

DBFS-monteringar saknar korrekta åtkomstkontrollistor (ACL:er). Använd i stället Unity Catalog-volymer eller arbetsytefilsystem (WSFS). Se Vad är volymer?.

Undvik att installera beräkningsbegränsade bibliotek

Att installera bibliotek på beräkningsnivån skapar miljödrift mellan olika jobb. Använd %pip install i stället i notebook-filer eller definiera beroenden i en miljöspecifikation. Detta gör även klassiska arbetsbelastningar enklare att migrera till serverlösa.

Prestanda

Utvärdera om du skulle ha nytta av Photon

Många arbetsbelastningar drar nytta av Photon, men det är mest fördelaktigt för SQL-arbetsbelastningar och DataFrame-åtgärder som omfattar komplexa omvandlingar, till exempel kopplingar, aggregeringar och datagenomsökningar i stora tabeller. Arbetsbelastningar med frekvent diskåtkomst, breda tabeller eller upprepad databehandling ser också bättre prestanda.

Enkla batch-ETL-jobb som inte omfattar breda transformeringar eller stora datavolymer kan få minimal påverkan från att aktivera Photon, särskilt om frågor vanligtvis slutförs på mindre än två sekunder.

Använd autoskalning

Konfigurera automatisk skalning så att långvariga uppgifter dynamiskt kan lägga till och ta bort arbetsnoder under jobbkörningar. Se Aktivera automatisk skalning.

Använda instanspooler för att minska starttiderna

Instanspooler reserverar beräkningsresurser från molnleverantören. Pooler minskar starttiden för det nya klustret och säkerställer tillgängligheten för beräkningsresurser. Se Referens för poolkonfiguration.

Kostnadsoptimering

Använd beräkningsprinciper

Azure Databricks rekommenderar att du använder beräkningsprinciper. Med beräkningspolicyer kan du skapa förkonfigurerade beräkningsresurser som utformats för specifika ändamål, till exempel personliga beräkningar, delade beräkningar, prestandaanvändare och jobb. Principer begränsar de beslut du behöver fatta när du konfigurerar beräkningsinställningar.

Om du inte har åtkomst till principer kontaktar du administratören för arbetsytan. Se Standardprinciper och principfamiljer.

Använd spotinstanser

Konfigurera Spot-instanser för arbetsbelastningar som har krav på låg svarstid för att optimera kostnaderna. Se Spot-instanser.

Överväganden för beräkningsstorlek

Människor tänker ofta på beräkningsstorlek 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 parallelliteten för en beräkning.
• 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.
• Exekutorens lokala lagring: Typ och mängd lokal disklagring. Lokal disk används främst vid spill under blandningar och cachelagring.

Ytterligare överväganden är typen och storleken på arbetsinstansen, som också påverkar faktorerna ovan. När du dimensionerar din beräkningskapacitet bör du tänka på:

• 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?

Det finns en balansakt mellan antalet arbetare och storleken på arbetsinstanstyperna. Att konfigurera beräkning med två arbetare, var och en med 16 kärnor och 128 GB RAM-minne, har samma beräkning och minne som att konfigurera beräkning med 8 arbetare, var och en med 4 kärnor och 32 GB RAM-minne.

Exempel på beräkningskonfiguration

I följande exempel visas beräkningsrekommendationer 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. En beräkningsresurs med ett mindre antal större noder kan minska det nätverks- och disk-I/O som behövs för att utföra dessa blandningar.

En beräkning med en enda nod med en stor VM-typ är förmodligen det bästa valet, särskilt för en enskild analytiker.

Analytiska arbetsbelastningar kräver troligen att samma data läss upprepade gånger, så rekommenderade nodtyper är lagringsoptimerade med diskcache aktiverat eller instanser med lokal lagring.

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

• Aktivera automatisk avslutning för att säkerställa att beräkningen avslutas efter en period av inaktivitet.
• Överväg att aktivera automatisk skalning baserat på analytikerns typiska arbetsbelastning.

Grundläggande batch-ETL

För enkla batch-ETL-jobb som inte kräver breda omvandlingar, till exempel kopplingar eller aggregeringar, använder du instanser med lägre krav för minne och lagring. Detta kan leda till kostnadsbesparingar jämfört med andra arbetstyper.

Komplex batch-ETL

För ett komplext ETL-jobb, till exempel ett som kräver fackföreningar och kopplingar mellan flera tabeller, rekommenderar Azure Databricks att du använder färre arbetare för att minska mängden data som blandas. Öka storleken på dina instanser för att kompensera för färre anställda.

Komplexa omvandlingar kan vara beräkningsintensiva. Om du ser betydande spill till disk eller OOM-fel bör du öka mängden minne som är tillgängligt på dina instanser.

Om du vill kan du använda instanspooler för att minska starttiderna för beräkningsresurser och den totala körtiden när du kör jobb-pipelines.

Träna maskininlärningsmodeller

För att träna maskininlärningsmodeller rekommenderar Azure Databricks att du skapar en beräkningsresurs med hjälp av principen för personlig beräkning.

Använd en beräkning med en enda nod med en stor nodtyp för inledande experimentering. Att ha färre noder minskar effekten av omblandningar.

Att lägga till fler arbetare kan hjälpa till med stabiliteten, men undvik att lägga till för många arbetare på grund av omkostnaderna för att blanda data.

Rekommenderade arbetstyper är lagringsoptimerade med diskcachelagring aktiverat, eller en instans med lokal lagring för att ta hänsyn till upprepade läsningar av samma data och för att aktivera cachelagring av träningsdata.

Ytterligare funktioner som rekommenderas för maskininlärningsarbetsbelastningar är:

• Aktivera automatisk avslutning för att säkerställa att beräkningen avslutas efter en period av inaktivitet.
• Använd instanspooler, vilket gör det möjligt att begränsa beräkning till en förgodkänd instanstyp.
• Se till att beräkningskonfigurationerna är konsekventa med hjälp av principer.