Konfigurera kluster

Den här artikeln beskriver de konfigurationsalternativ som är tillgängliga när du skapar och redigerar Azure Databricks kluster. Den fokuserar på att skapa och redigera kluster med hjälp av användargränssnittet. Andra metoder finns i Clusters CLI and Clusters API 2.0 (Kluster-CLI och kluster-API 2.0).

Information om hur du bestämmer vilken kombination av konfigurationsalternativ som passar dina behov bäst finns i Metodtips för klusterkonfiguration.

Hämta en Spark-konfigurationsegenskap från en hemlighet

Databricks rekommenderar att känslig information, till exempel lösenord, lagras i en hemlighet i stället för i klartext. Om du vill referera till en hemlighet i Spark-konfigurationen använder du följande syntax:

spark.<secret-prop-name> <path-value>

Om du till exempel vill ange en Spark-konfigurationsegenskap password som anropas till värdet för hemligheten som lagras i secrets/apps/acme-app/password :

spark.password {{secrets/apps/acme-app/password}}

Mer information finns i Hemliga sökvägar i en Spark-konfigurationsegenskap eller miljövariabel.

Klusterprincip

En klusterprincip begränsar möjligheten att konfigurera kluster baserat på en uppsättning regler. Principreglerna begränsar de attribut eller attributvärden som är tillgängliga för att skapa kluster. Klusterprinciper har ACL:er som begränsar deras användning till specifika användare och grupper och därmed begränsar vilka principer du kan välja när du skapar ett kluster.

Om du vill konfigurera en klusterprincip väljer du klusterprincipen i listrutan Princip.

Om du har:

• Behörighet att skapakluster kan du välja principen Obegränsad och skapa fullständigt konfigurerbara kluster. Principen Obegränsad begränsar inte klusterattribut eller attributvärden.
• Både behörighet att skapa kluster och åtkomst till klusterprinciper kan du välja principen Obegränsad och de principer som du har åtkomst till.
• Åtkomst till endast klusterprinciper, du kan välja de principer som du har åtkomst till.

Klusterläge

Azure Databricks stöder tre klusterlägen: Standard, Hög samtidighet och enskild nod. Standardklusterläget är Standard.

Standardkluster

Ett standardkluster rekommenderas för en enskild användare. Standardkluster kan köra arbetsbelastningar som utvecklats på alla språk: Python, SQL, R och Scala.

Kluster med hög samtidighet

Ett kluster med hög samtidighet är en hanterad molnresurs. De viktigaste fördelarna med kluster med hög samtidighet är att de ger mer information om maximal resursanvändning och minsta frågesvarstid.

Kluster med hög samtidighet kan köra arbetsbelastningar som utvecklats i SQL, Python och R. Prestanda och säkerhet för kluster med hög samtidighet tillhandahålls genom att användarkod körs i separata processer, vilket inte är möjligt i Scala.

Dessutom stöder endast kluster med hög samtidighet åtkomstkontroll för tabeller.

Om du vill skapa ett kluster med hög samtidighet ställer du in Klusterlägepå Hög samtidighet.

Ett exempel på hur du skapar ett kluster med hög samtidighet med hjälp av kluster-API:et finns i Exempel på kluster med hög samtidighet.

Kluster med en nod

Ett kluster med en nod har inga arbetare och kör Spark-jobb på drivrutinsnoden.

Ett standardkluster kräver däremot minst en Spark-arbetsnod utöver drivrutinsnoden för att köra Spark-jobb.

Om du vill skapa ett kluster med en nod ställer du in Klusterläge på En nod.

Mer information om hur du arbetar med kluster med en nod finns i Kluster med en nod.

Pooler

Om du vill minska klustrets starttid kan du koppla ett kluster till en fördefinierad pool med inaktiva instanser för drivrutins- och arbetsnoderna. Klustret skapas med instanser i poolerna. Om en pool inte har tillräckligt med inaktiva resurser för att skapa begärda drivrutins- eller arbetsnoder expanderas poolen genom att nya instanser allokeras från instansprovidern. När ett anslutet kluster avslutas returneras de instanser som det använde till poolerna och kan återanvändas av ett annat kluster.

Om du väljer en pool för arbetsnoder men inte för drivrutinsnoden ärver drivrutinsnoden poolen från arbetsnodkonfigurationen.

I Pooler kan du läsa mer om att arbeta med pooler i Azure Databricks.

Databricks Runtime

Databricks-körningar är den uppsättning kärnkomponenter som körs på dina kluster. Alla Databricks-körningar innehåller Apache Spark och lägger till komponenter och uppdateringar som förbättrar användbarhet, prestanda och säkerhet. Mer information finns i Databricks runtimes.

Azure Databricks erbjuder flera typer av körningar och flera versioner av dessa körningstyper i listrutan Databricks Runtime Version när du skapar eller redigerar ett kluster.

Fotonbilder

Så här väljer du en Photon-bild:

1. Visa endast körningar som innehåller bildtyper för Photon. Markera kryssrutan Photon:

   

2. Välj en Photon-körning.

3. Du kan också välja en instanstyp i listrutan Arbetstyp och Drivrutinstyp.

Databricks rekommenderar följande instanstyper för bästa pris och prestanda:

• Standard_E4ds_v4
• Standard_E8ds_v4
• Standard_E16ds_v4

Du kan visa photon-aktiviteten i Spark-användargränssnittet. Följande skärmbild visar frågeinformationen DAG. Det finns två tecken på Photon i DAG. Först börjar photon-operatorerna med "Photon", till exempel PhotonGroupingAgg . För det andra färgas fotooperatorer och faser i DAG, medan de som inte är foton är blå.

Docker-avbildningar

För vissa Databricks Runtime versioner kan du ange en Docker-avbildning när du skapar ett kluster. Exempel på användningsfall är biblioteksanpassning, en gyllene containermiljö som inte ändras och Docker CI/CD-integrering.

Du kan också använda Docker-avbildningar för att skapa anpassade djupinlärningsmiljöer i kluster med GPU-enheter.

Anvisningar finns i Anpassa containrar med Databricks Container Services och Databricks Container Services på GPU-kluster.

Python-version

Python-kluster som Databricks Runtime 6.0 och högre

Databricks Runtime 6.0 (stöds inte) och högre stöder endast Python 3. Större ändringar som rör Python-miljön som introducerades av Databricks Runtime 6.0 finns i Python-miljön i viktig information.

Python-kluster som kör Databricks Runtime 5.5 LTS

För Databricks Runtime 5.5 LTS stöder Spark-jobb, Python Notebook-celler och biblioteksinstallationer både Python 2 och 3.

Standardversionen av Python för kluster som skapats med hjälp av användargränssnittet är Python 3. I Databricks Runtime 5.5 LTS är standardversionen för kluster som skapats med hjälp REST API Python 2.

Ange Python-version

Om du vill ange Python-versionen när du skapar ett kluster med hjälp av användargränssnittet väljer du den i listrutan Python-version.

Om du vill ange Python-versionen när du skapar ett kluster med hjälp av API:et anger du miljövariabeln PYSPARK_PYTHON/databricks/python/bin/python till eller /databricks/python3/bin/python3 . Ett exempel finns i REST API exempel Upload storfil i DBFS.

Verifiera att konfigurationen har PYSPARK_PYTHON börja gälla genom att köra följande i en Python-notebook-dator %python (eller cell):

import sys
print(sys.version)

Om du har /databricks/python3/bin/python3 angett bör det skriva ut något som liknar följande:

3.5.2 (default, Sep 10 2016, 08:21:44)
[GCC 5.4.0 20160609]

Vanliga frågor och svar (FAQ)

Kan jag använda både Python 2- och Python 3-notebook-datorer i samma kluster?

Nej. Python-versionen är en klusteromfattande inställning och kan inte konfigureras per notebook-version.

Vilka bibliotek är installerade på Python-kluster?

Mer information om de specifika bibliotek som är installerade finns i Versionsinformation för Databricks Runtime.

Kommer mina befintliga PyPI-bibliotek att fungera med Python 3?

Det beror på om versionen av biblioteket stöder Python 3-versionen av en Databricks Runtime version.

Databricks Runtime 5.5 LTS använder Python 3.5. Databricks Runtime 6.0 och Databricks Runtime conda använder Python 3.7. Det är möjligt att en specifik gammal version av ett Python-bibliotek inte är kompatibel med Python 3.7. I det här fallet måste du använda en nyare version av biblioteket.

Kommer mina befintliga .egg bibliotek att fungera med Python 3?

Det beror på om ditt befintliga bibliotek är korskompatibelt med både Python 2 och 3. Om biblioteket inte stöder Python 3 misslyckas antingen biblioteksbilagan eller så uppstår körningsfel.

En omfattande guide om hur du portar kod till Python 3 och skriver kod som är kompatibel med både Python 2 och 3 finns i Stöd för Python 3.

Kan jag fortfarande installera Python-bibliotek med init-skript?

Ett vanligt användningsfall för initieringsskript för klusternoder är att installera paket.

För Databricks Runtime 5.5 LTS använder du för att se till att Python-paket installeras i en virtuell Databricks Python-miljö i stället för /databricks/python/bin/pip i systemets Python-miljö.

För Databricks Runtime 6.0 och Databricks Runtime med Conda refererar kommandot till i rätt pippip virtuell Python-miljö. Men om du använder ett init-skript för att skapa den virtuella Python-miljön ska du alltid använda den absoluta sökvägen för att komma python åt och pip .

Klusternodtyp

Ett kluster består av en drivrutinsnod och noll eller flera arbetsnoder.

Du kan välja separata typer av molnleverantörsinstanser för drivrutins- och arbetsnoderna, men som standard använder drivrutinsnoden samma instanstyp som arbetsnoden. Olika typer av instanser passar olika användningsfall, till exempel minnesintensiva eller beräkningsintensiva arbetsbelastningar.

• Drivrutinsnod
• Arbetsnod
• GPU-instanstyper
• Spot-instanser

Drivrutinsnod

Drivrutinsnoden underhåller tillståndsinformation för alla notebook-filer som är anslutna till klustret. Drivrutinsnoden underhåller även SparkContext och tolkar alla kommandon som du kör från en notebook-fil eller ett bibliotek i klustret och kör Apache Spark som samordnar med Spark-utförare.

Standardvärdet för drivrutinsnodtypen är samma som arbetsnodtypen. Du kan välja en större drivrutinsnodtyp med mer minne om du planerar att använda mycket data från collect() Spark-arbetare och analysera dem i anteckningsboken.

Arbetsnod

Azure Databricks arbetsnoder kör Spark-utförare och andra tjänster som krävs för att klustren ska fungera korrekt. När du distribuerar din arbetsbelastning med Spark sker all distribuerad bearbetning på arbetsnoder. Azure Databricks kör en utförare per arbetsnod. Därför används termerna executoroch worker synonymt i kontexten för den Azure Databricks arkitekturen.

GPU-instanstyper

För beräkningsmässigt utmanande uppgifter som kräver höga prestanda, till exempel de som är associerade med djupinlärning, stöder Azure Databricks kluster som accelereras med grafikprocessorer (GPU). Det här stödet är i betaversion. Mer information finns i GPU-aktiverade kluster.

Spot-instanser

För att spara pengar kan du välja att använda spotinstanser, även kallade virtuella Azure Spot-datorer, genom att markera kryssrutan Punktinstanser.

Den första instansen kommer alltid att vara på begäran (drivrutinsnoden är alltid på begäran) och efterföljande instanser är spot-instanser. Om spotinstanser avlägsnas på grund av otillgänglighet distribueras instanser på begäran för att ersätta avlägsnade instanser.

Klusterstorlek och automatisk skalning

När du skapar ett Azure Databricks-kluster kan du antingen ange ett fast antal arbetare för klustret eller ange ett lägsta och högsta antal arbetare för klustret.

När du anger ett kluster med fast storlek Azure Databricks att klustret har det angivna antalet arbetare. När du anger ett intervall för antalet arbetare väljer Databricks lämpligt antal arbetare som krävs för att köra jobbet. Detta kallas autoskalning.

Med autoskalning kan Azure Databricks dynamiskt om arbetare för att ta hänsyn till jobbets egenskaper. Vissa delar av din pipeline kan vara mer beräkningsmässigt krävande ä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 gör det enklare att uppnå hög klusteranvändning eftersom du inte behöver etablera klustret för att matcha en arbetsbelastning. Detta gäller särskilt för arbetsbelastningar vars krav ändras över tid (t.ex. att utforska en datauppsättning under en dag), men det kan också gälla för en en gång kortare arbetsbelastning vars etableringskrav är okända. Automatisk skalning har därför två fördelar:

• Arbetsbelastningar kan köras snabbare jämfört med ett underetableerat kluster med konstant storlek.
• Kluster för automatisk skalning kan minska de totala kostnaderna jämfört med ett kluster med statisk storlek.

Beroende på klustrets och arbetsbelastningens konstanta storlek ger autoskalning dig en eller båda av dessa fördelar på samma gång. Klusterstorleken kan vara lägre än det minsta antal arbetare som valts när molnleverantören avslutar instanser. I det här Azure Databricks kontinuerligt återförsök att etablera instanser för att upprätthålla det minsta antalet arbetare.

Typer av automatisk skalning

Azure Databricks erbjuder två typer av automatisk skalning av klusternoder: standard och optimerad. En diskussion om fördelarna med optimerad autoskalning finns i blogginlägget om optimerad autoskalning.

Automatiserade kluster (jobb) använder alltid optimerad automatisk skalning. Vilken typ av automatisk skalning som utförs på kluster för alla syften beror på arbetsytans konfiguration.

Automatisk standardskalning används av kluster för alla syften på arbetsytor på prisnivån Standard. Optimerad automatisk skalning används av kluster för alla syften i Azure Databricks Premium plan.

Så beter sig autoskalning

Autoskalning fungerar olika beroende på om den är optimerad eller standard och om den tillämpas på ett all-purpose eller ett jobbkluster.

Optimerad automatisk skalning

• Skalar upp från min till max i 2 steg.
• Kan skala ned även om klustret inte är inaktivt genom att titta på shuffle-filtillståndet.
• Skalas ned baserat på en procentandel av de aktuella noderna.
• På jobbkluster skalar ned om klustret är underutnyttjat under de senaste 40 sekunderna.
• I kluster för alla syften skalar ned om klustret är underutnyttjat under de senaste 150 sekunderna.
• Egenskapen spark.databricks.aggressiveWindowDownS Spark-konfiguration anger på några sekunder hur ofta ett kluster fattar beslut om nedskalning. När värdet ökas skalas ett kluster ned långsammare. Det maximala värdet är 600.

Automatisk standardskalning

• Börjar med att lägga till 8 noder. Därefter skalas upp exponentiellt, men det kan ta många steg för att nå max. Du kan anpassa det första steget genom att ange spark.databricks.autoscaling.standardFirstStepUp spark-konfigurationsegenskapen.
• Skalar bara ned när klustret är helt inaktivt och har underutnyttjats under de senaste 10 minuterna.
• Skalar ned exponentiellt, från och med 1 nod.

Aktivera och konfigurera autoskalning

Om du Azure Databricks att ändra storlek på klustret automatiskt aktiverar du automatisk skalning för klustret och anger det minsta och högsta antalet arbetare.

1. Aktivera automatisk skalning.

   • All-Purpose kluster – På sidan Skapa kluster markerar du kryssrutan Aktivera autoskalning i rutan Autopilot-alternativ:

     

   • Jobbkluster – På sidan Konfigurera kluster markerar du kryssrutan Aktivera autoskalning i rutan Autopilot-alternativ:

     

2. Konfigurera minsta och högsta antal arbetare.

   

   När klustret körs visar klusterinformationssidan antalet allokerade arbetare. Du kan jämföra antalet allokerade arbetare med arbetskonfigurationen och göra justeringar efter behov.

Exempel på automatisk skalning

Om du konfigurerar om ett statiskt kluster som ett kluster för automatisk skalning Azure Databricks omedelbart storleksändrar klustret inom de lägsta och högsta gränserna och startar sedan autoskalning. Följande tabell visar till exempel vad som händer med kluster med en viss inledande storlek om du konfigurerar om ett kluster för automatisk skalning mellan 5 och 10 noder.

Automatisk skalning av lokal lagring

Det kan ofta vara svårt att uppskatta hur mycket diskutrymme ett visst jobb kommer att ta. För att du inte ska behöva uppskatta hur många gigabyte hanterade diskar som ska anslutas till klustret när klustret skapas, aktiverar Azure Databricks automatiskt automatisk skalning av lokal lagring på alla Azure Databricks kluster.

Med automatisk skalning av lokal lagring övervakar Azure Databricks mängden ledigt diskutrymme som är tillgängligt i klustrets Spark-arbetare. Om en arbetsroll börjar få för lite diskutrymme kopplar Databricks automatiskt en ny hanterad disk till arbetsrollen innan diskutrymmet tar slut. Diskar är anslutna upp till en gräns på 5 TB totalt diskutrymme per virtuell dator (inklusive den virtuella datorns ursprungliga lokala lagring).

De hanterade diskarna som är anslutna till en virtuell dator kopplas bara från när den virtuella datorn returneras till Azure. Det innebär att hanterade diskar aldrig frånkopplade från en virtuell dator så länge de ingår i ett kluster som körs. Om du vill skala ned användningen av hanterade diskar Azure Databricks du använda den här funktionen i ett kluster som konfigurerats med GPU-instanstyper eller automatisk avslutning.

Lokal diskkryptering

Vissa instanstyper som du använder för att köra kluster kan ha lokalt anslutna diskar. Azure Databricks lagra shuffle-data eller tillfälliga data på dessa lokalt anslutna diskar. För att säkerställa att alla vilodata krypteras för alla lagringstyper, inklusive blanda data som lagras tillfälligt på klustrets lokala diskar, kan du aktivera lokal diskkryptering.

När lokal diskkryptering är aktiverat Azure Databricks en krypteringsnyckel lokalt som är unik för varje klusternod och som används för att kryptera alla data som lagras på lokala diskar. Nyckelns omfattning är lokal för varje klusternod och förstörs tillsammans med själva klusternoden. Under livslängden finns nyckeln i minnet för kryptering och dekryptering och lagras krypterad på disken.

Om du vill aktivera lokal diskkryptering måste du använda kluster-API 2.0. När klustret skapas eller redigeras anger du:

{
  "enable_local_disk_encryption": true
}

Se Skapa och redigera i kluster-API-referensen för exempel på hur du anropar dessa API:er.

Här är ett exempel på ett kluster create-anrop som möjliggör lokal diskkryptering:

{
  "cluster_name": "my-cluster",
  "spark_version": "7.3.x-scala2.12",
  "node_type_id": "Standard_D3_v2",
  "enable_local_disk_encryption": true,
  "spark_conf": {
    "spark.speculation": true
  },
  "num_workers": 25
}

Spark-konfiguration

Om du vill finjustera Spark-jobb kan du ange anpassade Spark-konfigurationsegenskaper i en klusterkonfiguration.

1. På sidan klusterkonfiguration klickar du på växlingsknappen Avancerade alternativ.

2. Klicka på fliken Spark.

   

   I Spark-konfigurationanger du konfigurationsegenskaperna som ett nyckel/värde-par per rad.

När du konfigurerar ett kluster med hjälp av Kluster-API 2.0anger du Spark-egenskaper i fältet i Begäran om att skapa kluster eller Redigera klusterbegäran.

Om du vill ange Spark-egenskaper för alla kluster skapar du ett globalt init-skript:

dbutils.fs.put("dbfs:/databricks/init/set_spark_params.sh","""
  |#!/bin/bash
  |
  |cat << 'EOF' > /databricks/driver/conf/00-custom-spark-driver-defaults.conf
  |[driver] {
  |  "spark.sql.sources.partitionOverwriteMode" = "DYNAMIC"
  |}
  |EOF
  """.stripMargin, true)

Miljövariabler

Du kan ange miljövariabler som du kan komma åt från skript som körs i ett kluster.

1. På sidan klusterkonfiguration klickar du på växlingsknappen Avancerade alternativ.

2. Klicka på fliken Spark.

3. Ange miljövariablerna i fältet Miljövariabler.

   

Du kan också ange miljövariabler med hjälp av fältet i Skapa klusterbegäran eller spark_env_varsRedigera klusterbegärande-API-slutpunkter för kluster. spark_env_vars

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-par när du skapar ett kluster och Azure Databricks tillämpar dessa taggar på molnresurser som virtuella datorer och diskvolymer samt DBU-användningsrapporter.

För kluster som startas från pooler tillämpas de anpassade klustertaggarna endast på DBU-användningsrapporter och sprids inte till molnresurser. Detaljerad information om hur pool- och klustertaggtyper fungerar tillsammans finns i Övervaka användning med hjälp av taggar för kluster, pooler och arbetsytor.

För enkelhetens skull Azure Databricks fyra standardtaggar för varje kluster: VendorCreator , , och ClusterNameClusterId .

I jobbkluster tillämpas dessutom Azure Databricks standardtaggar: RunName och JobId . På resurser som används av Databricks SQL använder Azure Databricks även standardtaggen SqlEndpointId .

Du kan lägga till anpassade taggar när du skapar ett kluster. Så här konfigurerar du klustertaggar:

1. På sidan klusterkonfiguration klickar du på växlingsknappen Avancerade alternativ.

2. Klicka på fliken Taggar längst ned på sidan.

   

3. Lägg till ett nyckel/värde-par för varje anpassad tagg. Du kan lägga till upp till 43 anpassade taggar.

SSH-åtkomst till kluster

Av säkerhetsskäl stängs Azure Databricks SSH-porten som standard. Om du vill aktivera SSH-åtkomst till dina Spark-kluster kontaktar Azure Databricks support.

Klusterloggsleverans

När du skapar ett kluster kan du ange en plats för att leverera loggarna för Spark-drivrutinsnoden, arbetsnoderna och händelserna. Loggar levereras var femte minut till ditt valda mål. När ett kluster avslutas kan Azure Databricks att leverera alla loggar som genererats fram tills klustret avslutades.

Målet för loggarna beror på kluster-ID:t. Om det angivna målet är dbfs:/cluster-log-delivery levereras 0630-191345-leap375 klusterloggar för till dbfs:/cluster-log-delivery/0630-191345-leap375 .

Så här konfigurerar du loggleveransplatsen:

1. På klusterkonfigurationssidan klickar du på växlingsknappen Avancerade alternativ.

2. Klicka på fliken Loggning.

   

3. Välj en måltyp.

4. Ange sökvägen till klusterloggen.

Init-skript

En klusternods initiering, eller init, är ett gränssnittsskript som körs under start för varje klusternod innan Spark-drivrutinen eller arbets-JVM startar. Du kan använda init-skript för att installera paket och bibliotek som inte ingår i Databricks-körningen, ändra klassökvägen för JVM-systemet, ange systemegenskaper och miljövariabler som används av JVM eller ändra Spark-konfigurationsparametrar, bland andra konfigurationsuppgifter.

Du kan koppla init-skript till ett kluster genom att expandera avsnittet Avancerade alternativ och klicka på fliken Init-skript.

Detaljerade anvisningar finns i Initieringsskript för klusternoder.