Konfigurera kluster

Kommentar

Det här är instruktioner för det äldre användargränssnittet för skapa kluster och ingår endast för historisk noggrannhet. Alla kunder bör använda det uppdaterade användargränssnittet för skapa 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 Databricks CLI, Kluster-API:et och Databricks Terraform-providern.

Hjälp med att bestämma vilken kombination av konfigurationsalternativ som passar bäst för dina behov finns i metodtips för klusterkonfiguration.

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 .

Kommentar

Om inga principer har skapats på arbetsytan visas inte listrutan Princip.

Om du har:

• Skapa klusterbehörighet. Du kan välja principen Obegränsad och skapa fullständigt konfigurerbara kluster. Principen Obegränsad begränsar inte några klusterattribut eller attributvärden.
• Både kluster skapar behörighet och åtkomst till klusterprinciper. Du kan välja principen Obegränsad och de principer som du har åtkomst till.
• Du kan bara välja de principer som du har åtkomst till.

Klusterläge

Kommentar

Den här artikeln beskriver användargränssnittet för äldre kluster. Information om det nya klustrets användargränssnitt (i förhandsversion) finns i Referens för beräkningskonfiguration. Detta omfattar vissa terminologiändringar för 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 för 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. Standardklusterläget är Standard.

Viktigt!

• Om din arbetsyta har tilldelats ett Unity Catalog-metaarkiv är kluster med hög samtidighet inte tillgängliga. I stället använder du åtkomstläge för att säkerställa integriteten för åtkomstkontroller och framtvinga starka isoleringsgarantier. Se även Åtkomstlägen.
• Du kan inte ändra klusterläget när ett kluster har skapats. Om du vill ha ett annat klusterläge måste du skapa ett nytt kluster.

Klusterkonfigurationen innehåller en inställning för automatisk uppsägning vars standardvärde är beroende av klusterläge:

• Standard- och single node-kluster avslutas automatiskt efter 120 minuter som standard.
• Kluster med hög samtidighet avslutas inte automatiskt som standard.

Standardkluster

Varning

Standardlägeskluster (kallas ibland Inga isoleringsdelade kluster) 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 standardlägeskluster. 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 som kluster med hög samtidighet med tabell-ACL:er.

Ett standardkluster rekommenderas endast för enskilda användare. Standardkluster kan köra arbetsbelastningar som utvecklats i 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 detaljerad delning för maximal resursanvändning och minsta frågesvarstider.

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 köra användarkod 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 anger du Klusterläge till Hög samtidighet.

Kluster med en nod

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

Ett Standard-kluster 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 anger du Klusterläge till Enskild nod.

Mer information om hur du arbetar med kluster med en nod finns i Beräkning med en nod eller flera noder.

Pooler

För att minska starttiden för klustret kan du koppla ett kluster till en fördefinierad pool med inaktiva instanser för drivrutins- och arbetsnoderna. Klustret skapas med hjälp av instanser i poolerna. Om en pool inte har tillräckligt med inaktiva resurser för att skapa den begärda drivrutinen eller arbetsnoderna expanderar poolen genom att allokera nya instanser 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 konfigurationen av arbetsnoden.

Viktigt!

Om du försöker välja en pool för drivrutinsnoden men inte för arbetsnoder uppstår ett fel och klustret skapas inte. Det här kravet förhindrar en situation där drivrutinsnoden måste vänta tills arbetsnoder skapas, eller tvärtom.

Mer information om hur du arbetar med pooler i Azure Databricks finns i Referens för poolkonfiguration.

Databricks Runtime

Databricks-körning är den uppsättning kärnkomponenter som körs i dina kluster. Alla Databricks-körningar inkluderar Apache Spark och lägger till komponenter och uppdateringar som förbättrar användbarhet, prestanda och säkerhet. Mer information finns i Versionsanmärkningsversioner och kompatibilitet för Databricks Runtime.

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.

Fotoacceleration

Foton är tillgängligt för kluster som kör Databricks Runtime 9.1 LTS och senare.

Om du vill aktivera fotonacceleration markerar du kryssrutan Använd fotonacceleration .

Om du vill kan du ange instanstypen i listrutan Arbetstyp och Drivrutinstyp.

Databricks rekommenderar följande instanstyper för optimalt pris och prestanda:

• Standard_E4ds_v4
• Standard_E8ds_v4
• Standard_E16ds_v4

Du kan visa fotoaktivitet i Spark-användargränssnittet. Följande skärmbild visar frågeinformationen DAG. Det finns två indikationer på Foton i DAG. Först börjar fotooperatorer med "Photon", till exempel PhotonGroupingAgg. För det andra, i DAG är fotonoperatorer och stadier färgade persika, medan de icke-fotoniska ä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 Service och Databricks Container Services på GPU-beräkning.

Klusternodtyp

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

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

Kommentar

Om dina säkerhetskrav omfattar beräkningsisolering väljer du en Standard_F72s_V2 instans som arbetstyp. Dessa instanstyper representerar isolerade virtuella datorer som använder hela den fysiska värden och tillhandahåller den isoleringsnivå som krävs för att stödja till exempel IL5-arbetsbelastningar (US Department of Defense Impact Level 5).

• Drivrutinsnod
• Arbetsnod
• GPU-instanstyper
• Oanvända instanser

Drivrutinsnod

Drivrutinsnoden upprätthåller tillståndsinformation för alla notebook-filer som är kopplade till klustret. Drivrutinsnoden underhåller också SparkContext, och tolkar alla kommandon som du kör från en notebook-fil eller ett bibliotek i klustret, och kör Apache Spark-huvudservern som samordnar med Spark-utförarna.

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

Dricks

Eftersom drivrutinsnoden har all tillståndsinformation för de anslutna notebook-filerna ser du till att koppla från oanvända notebook-filer från drivrutinsnoden.

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 arbetsbelastningen med Spark sker all distribuerad bearbetning på arbetsnoder. Azure Databricks kör en köre per arbetsnod. Därför används termerna executor och worker utbytbart i kontexten för Azure Databricks-arkitekturen.

Dricks

Om du vill köra ett Spark-jobb behöver du minst en arbetsnod. Om ett kluster har noll arbetare, kan du köra kommandon som inte är Spark-baserade i drivrutinsnoden, men Spark-kommandon kommer inte att fungera.

GPU-instanstyper

För beräkningsmässigt utmanande uppgifter som kräver höga prestanda, som de som är associerade med djupinlärning, stöder Azure Databricks kluster som accelereras med grafikprocessorer (GPU:er). Mer information finns i GPU-aktiverad beräkning.

Oanvända instanser

Om du vill spara kostnader kan du välja att använda instanser av oanvänd kapacitet, även kallade virtuella Azure Spot-datorer genom att markera kryssrutan Spot instances (Spot instances ).

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

Klusterstorlek och autoskalning

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

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

Med automatisk skalning omallokerar Azure Databricks arbetare dynamiskt för att ta hänsyn till egenskaperna för ditt jobb. Vissa delar av pipelinen 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).

Med automatisk skalning blir det enklare att uppnå hög klusteranvändning eftersom du inte behöver etablera klustret för att matcha arbetsbelastningen. Detta gäller särskilt för arbetsbelastningar vars krav ändras över tid (till exempel att utforska en datauppsättning under en dag), men det kan även gälla för en enstaka kortare arbetsbelastning vars etableringskrav är okända. Autoskalning erbjuder därför två fördelar:

• Arbetsbelastningar kan köras snabbare jämfört med ett underetablerade kluster med konstant storlek.
• Autoskalningskluster kan minska de totala kostnaderna jämfört med ett statiskt kluster.

Beroende på klustrets och arbetsbelastningens konstanta storlek ger automatisk skalning dig en eller båda av dessa fördelar samtidigt. Klusterstorleken kan gå under det minsta antal arbetare som valts när molnleverantören avslutar instanser. I det här fallet försöker Azure Databricks kontinuerligt att återetablera instanser för att behålla det minsta antalet arbetare.

Kommentar

Autoskalning är inte tillgängligt för spark-submit-jobb.

Så beter sig autoskalning

• Skalas upp från min till max i två 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.
• I jobbkluster skalas ned om klustret underutnyttjers under de senaste 40 sekunderna.
• I kluster för alla syften skalas ned om klustret underutnyttjers under de senaste 150 sekunderna.
• Egenskapen spark.databricks.aggressiveWindowDownS Spark-konfiguration anger i sekunder hur ofta ett kluster fattar beslut om nedskalning. Om du ökar värdet skalas ett kluster ned långsammare. Det maximala värdet är 600.

Aktivera och konfigurera autoskalning

Om du vill tillåta att Azure Databricks ändrar storlek på klustret automatiskt aktiverar du automatisk skalning för klustret och anger minsta och högsta antal arbetare.

1. Aktivera automatisk skalning.

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

     

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

     

2. Konfigurera min- och maxarbetarna.

   

   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.

Viktigt!

Om du använder en instanspool:

• Kontrollera att den begärda klusterstorleken är mindre än eller lika med det minsta antalet inaktiva instanser i poolen. Om den är större blir klustrets starttid samma som för ett kluster som inte använder en pool.
• Kontrollera att den maximala klusterstorleken är mindre än eller lika med poolens maximala kapacitet . Om den är större går det inte att skapa klustret.

Exempel på automatisk skalning

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

Ursprunglig storlek	Storlek efter omkonfiguration
6	6
12	10
3	5

Automatisk skalning av lokal lagring

Det kan ofta vara svårt att uppskatta hur mycket diskutrymme ett visst jobb tar. För att spara dig från att behöva uppskatta hur många gigabyte hanterad disk som ska anslutas till klustret vid skapandetillfället aktiverar Azure Databricks automatiskt automatisk skalning av lokal lagring på alla Azure Databricks-kluster.

Med lokal lagring med automatisk skalning övervakar Azure Databricks mängden ledigt diskutrymme som är tillgängligt för spark-arbetare i klustret. Om en arbetare börjar köra för lågt på disken kopplar Databricks automatiskt en ny hanterad disk till arbetaren innan diskutrymmet tar slut. Diskar är anslutna till en gräns på 5 TB totalt diskutrymme per virtuell dator (inklusive den virtuella datorns ursprungliga lokala lagring).

De hanterade diskar som är anslutna till en virtuell dator kopplas endast från när den virtuella datorn returneras till Azure. Hanterade diskar kopplas alltså aldrig från en virtuell dator så länge de ingår i ett kluster som körs. För att skala ned användningen av hanterade diskar rekommenderar Azure Databricks att du använder den här funktionen i ett kluster som konfigurerats med klusterstorlek och automatisk skalning eller oväntad avslutning.

Lokal diskkryptering

Viktigt!

Den här funktionen finns som allmänt tillgänglig förhandsversion.

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

Viktigt!

Dina arbetsbelastningar kan köras långsammare på grund av prestandapåverkan vid läsning och skrivning av krypterade data till och från lokala volymer.

När lokal diskkryptering är aktiverat genererar 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. Omfånget för nyckeln är lokalt för varje klusternod och förstörs tillsammans med själva klusternoden. Under dess livslängd 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:et. När klustret skapas eller redigeras anger du:

{
  "enable_local_disk_encryption": true
}

Se Kluster-API:et för exempel på hur du anropar dessa API:er.

Här är ett exempel på ett klusterskapandeanrop 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
}

Säkerhetsläge

Om din arbetsyta har tilldelats ett Unity Catalog-metaarkiv använder du säkerhetsläge i stället för klusterläge med hög samtidighet för att säkerställa åtkomstkontrollernas integritet och framtvinga starka isoleringsgarantier. Klusterläget hög samtidighet är inte tillgängligt med Unity Catalog.

Under Avancerade alternativ väljer du bland följande klustersäkerhetslägen:

• Ingen: Ingen isolering. Framtvingar inte åtkomstkontroll eller genomströmning av autentiseringsuppgifter för arbetsytans lokala tabell. Det går inte att komma åt Unity Catalog-data.
• Enskild användare: Kan endast användas av en enskild användare (som standard den användare som skapade klustret). Andra användare kan inte ansluta till klustret. När du kommer åt en vy från ett kluster med säkerhetsläge för en användare körs vyn med användarens behörigheter. Kluster med en användare stöder arbetsbelastningar med Python, Scala och R. Init-skript, biblioteksinstallation och DBFS-monteringar stöds i kluster med en användare. Automatiserade jobb bör använda kluster med en användare.
• Användarisolering: Kan delas av flera användare. Endast SQL-arbetsbelastningar stöds. Biblioteksinstallation, init-skript och DBFS-monteringar inaktiveras för att framtvinga strikt isolering mellan klusteranvändare.
• Endast tabell-ACL (äldre): Framtvingar åtkomstkontroll för arbetsytor–lokal tabell, men kan inte komma åt Unity Catalog-data.
• Endast genomströmning (äldre): Framtvingar genomströmning av arbetsytelokala autentiseringsuppgifter, men kan inte komma åt Unity Catalog-data.

De enda säkerhetslägen som stöds för Unity Catalog-arbetsbelastningar är Isolering av enskild användare och användare.

Mer information finns i Åtkomstlägen.

Apache 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-konfiguration anger du konfigurationsegenskaperna som ett nyckel/värde-par per rad.

När du konfigurerar ett kluster med hjälp av kluster-API:et anger du Spark-egenskaper i spark_conf fältet i API:et Skapa nytt kluster eller Uppdatera klusterkonfigurations-API.

Databricks rekommenderar inte att du använder globala init-skript.

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)

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

Databricks rekommenderar att du lagrar känslig information, till exempel lösenord, 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.<property-name> {{secrets/<scope-name>/<secret-name>}}

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

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

Mer information finns i Syntax för att referera till hemligheter i en Spark-konfigurationsegenskap eller miljövariabel.

Miljövariabler

Du kan konfigurera anpassade miljövariabler som du kan komma åt från init-skript som körs i ett kluster. Databricks innehåller också fördefinierade miljövariabler som du kan använda i init-skript. Du kan inte åsidosätta dessa fördefinierade miljövariabler.

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 spark_env_vars fältet i API:et Skapa nytt kluster eller Uppdatera klusterkonfigurations-API.

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 taggarna för anpassade kluster 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 enkelhetens skull tillämpar Azure Databricks fyra standardtaggar på varje kluster: Vendor, Creator, ClusterNameoch ClusterId.

Dessutom tillämpar Azure Databricks två standardtaggar på jobbkluster: RunName och JobId.

På resurser som används av Databricks SQL tillämpar Azure Databricks även standardtaggen SqlWarehouseId.

Varning

Tilldela inte en anpassad tagg med nyckeln Name till ett kluster. Varje kluster har en tagg Name vars värde anges av Azure Databricks. Om du ändrar värdet som är associerat med nyckeln Namekan klustret inte längre spåras av Azure Databricks. Därför kanske klustret inte avslutas när det har blivit inaktivt och fortsätter att medföra användningskostnader.

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 SSH-porten som standard i Azure Databricks. Om du vill aktivera SSH-åtkomst till dina Spark-kluster kontaktar du Azure Databricks-supporten.

Kommentar

SSH kan endast aktiveras om din arbetsyta distribueras i ditt eget virtuella Azure-nätverk.

Klusterloggsleverans

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

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

Så här konfigurerar du loggleveransplatsen:

1. På sidan klusterkonfiguration 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.

Kommentar

Den här funktionen är också tillgänglig i REST-API:et. Se KLUSTER-API:et.

Init-skript

Ett initieringsskript för klusternoder – eller init – är ett gränssnittsskript som körs under starten för varje klusternod innan Spark-drivrutinen eller JVM-arbetaren startar. Du kan använda init-skript för att installera paket och bibliotek som inte ingår i Databricks-körningen, ändra JVM-systemklassökvägen, 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 instruktioner finns i Vad är init-skript?.