Aanbevolen procedures voor klassieke rekenconfiguratie

Op deze pagina vindt u een overzicht van aanbevolen procedures voor het configureren van klassieke rekenresources. Voor de meeste nieuwe workloads raadt Databricks aan om serverloze berekeningen te gebruiken. Hiervoor is geen configuratie vereist. Als uw workload niet wordt ondersteund op serverloze berekeningen (zie serverloze beperkingen), gebruikt u de volgende aanbevolen procedures om een klassieke rekenresource te configureren.

Toegangsmodus

Klassieke rekenresources kunnen worden toegewezen aan de standaard- of toegewezen toegangsmodus, waarmee wordt bepaald wie de rekenresource kan koppelen en gebruiken.

Databricks raadt aan om de standaardtoegangsmodus te gebruiken voor de meeste workloads. Standaard rekenresources kunnen worden gedeeld tussen meerdere gebruikers en groepen, waarbij gebruikersisolatie en alle toegangsrechten voor gegevens worden afgedwongen. Dit maakt het een eenvoudiger te beheren, rendabele optie voor de meeste workloads.

Gebruik alleen de toegewezen toegangsmodus als uw workload specifieke standaard rekenbeperkingen heeft, zoals ML Runtime op GPU, RDD-API's of R. Zie Standard-rekenvereisten en -beperkingen voor meer informatie.

Als Unity Catalog is ingeschakeld, stel spark.databricks.passthrough.enabled dan niet in. Referentiepassthrough is een verouderde toegangsmodus die niet compatibel is met Unity Catalog.

Zie Toegangsmodi.

Databricks Runtime-versie

Gebruik de nieuwste versie voor langetermijnondersteuning (LTS) Databricks Runtime. LTS-versies ontvangen uitgebreide beveiligingspatches en bugfixes, zodat uw workloads stabiel en compatibel blijven met de nieuwste platformfuncties.

Selecteer alleen een machine learning-runtime als uw workload GPU's, gedistribueerde ML-training of AutoML gebruikt. Databricks Runtime voor ML installeert een groot aantal bibliotheken die, als u die niet nodig hebt, in conflict kunnen komen met uw eigen afhankelijkheden, wat fouten of ongemerkt onjuiste resultaten kan veroorzaken. Zie AI- en ML-modellen trainen.

Configuratiehygiëne

Deze procedures houden uw rekenconfiguraties schoon en uw workloads zijn draagbaar.

Vermijd het gebruik van init-scripts

Init-scripts kunnen onverwacht gedrag veroorzaken, waaronder bibliotheekconflicten die workloads breken en omgevingen minder voorspelbaar maken. Voeg in plaats daarvan bibliotheken toe aan uw rekenbeleid, gebruik %pip install in notebooks of definieer afhankelijkheden in een omgevingsspecificatie. Zie Bibliotheken toevoegen aan een beleid.

Voorkom het hardcoderen van Spark-configuraties

Vermijd hardcodering van Spark-configuraties (zoals spark.executor.memory of spark.dynamicAllocation.*) in berekenings- of taakdefinities. Hardcoded waarden overschrijven de ingebouwde optimalisaties die Azure Databricks biedt, wat vaak leidt tot verspilde uitgaven of verminderde prestaties. Gebruik sessieconfiguraties met notebookbereik alleen als u een specifieke reden hebt om een standaardinstelling te overschrijven.

Vermijd compute-lokale opslagpaden

Sla geen gegevens op in compute-lokale paden, die niet langer duren dan de levenscyclus van de berekening. Gebruik in plaats daarvan Unity Catalog-volumes of tijdelijke opslag. Zie Wat zijn volumes?

DBFS-koppeling voorkomen

DBFS-koppelingen hebben geen juiste toegangsbeheerlijsten (ACL's). Gebruik in plaats daarvan Unity Catalog-volumes of werkruimtebestandssystemen (WSFS). Zie Wat zijn volumes?.

Voorkomen dat u bibliotheken met rekenbereik installeert

Door bibliotheken op computeniveau te installeren, veroorzaakt u omgevingsdrift tussen taken. Gebruik in plaats daarvan %pip install in notebooks of definieer afhankelijkheden in een omgevingsspecificatiebestand. Dit maakt het ook eenvoudiger om klassieke workloads naar serverless te migreren.

prestatie

Beoordelen of u baat hebt bij Photon

Veel workloads profiteren van Photon, maar het is het nuttigst voor SQL-workloads en DataFrame-bewerkingen met complexe transformaties, zoals joins, aggregaties en gegevensscans op grote tabellen. Workloads met frequente schijftoegang, brede tabellen of herhaalde gegevensverwerking zien ook verbeterde prestaties.

Eenvoudige BATCH ETL-taken waarvoor geen brede transformaties of grote gegevensvolumes nodig zijn, kunnen minimale gevolgen hebben voor het inschakelen van Photon, met name als query's doorgaans binnen twee seconden zijn voltooid.

Automatische schaalaanpassing gebruiken

Stel autoscaling zo in dat voor langlopende taken werkknooppunten dynamisch kunnen worden toegevoegd en verwijderd tijdens het uitvoeren van taken. Zie Automatisch schalen inschakelen.

Exemplaarpools gebruiken om de begintijden te verminderen

Instancepools reserveren rekenbronnen bij uw cloudprovider. Pools verminderen de begintijd van het nieuwe cluster en zorgen voor beschikbaarheid van rekenresources. Zie referentie voor poolconfiguratie.

Kostenoptimalisatie

Rekenbeleid gebruiken

Azure Databricks raadt het gebruik van rekenbeleid aan. Met rekenbeleid kunt u vooraf geconfigureerde rekenresources maken die zijn ontworpen voor specifieke doeleinden, zoals persoonlijke rekenkracht, gedeelde rekenkracht, energiegebruikers en taken. Beleidsregels beperken de beslissingen die u moet nemen bij het configureren van rekeninstellingen.

Als u geen toegang hebt tot beleid, neemt u contact op met uw werkruimtebeheerder. Zie Standaardbeleid en beleidsfamilies.

Spot-exemplaren gebruiken

Configureer spot-exemplaren voor workloads met lage latentievereisten om de kosten te optimaliseren. Zie Spot-instances.

Overwegingen voor het berekenen van de grootte

Mensen denken vaak aan rekenkracht in termen van het aantal werknemers, maar er zijn andere belangrijke factoren om rekening mee te houden:

• Totaal aantal uitvoerkernen (compute): het totale aantal kernen voor alle uitvoerders. Dit bepaalt de maximale parallelle uitvoering van een rekenproces.
• Totaal geheugen voor uitvoerders: de totale hoeveelheid RAM-geheugen voor alle uitvoerders. Hiermee bepaalt u hoeveel gegevens in het geheugen kunnen worden opgeslagen voordat deze naar de schijf worden overgeslagen.
• Lokale opslag van uitvoerprogramma: het type en de hoeveelheid lokale schijfopslag. Lokale schijf wordt voornamelijk gebruikt in het geval van uitvallen tijdens shuffle-processen en caching.

Aanvullende overwegingen zijn onder andere het type en de grootte van de werkexemplaren, die ook van invloed zijn op de bovenstaande factoren. Overweeg bij het bepalen van de grootte van uw computing capaciteit het volgende:

• Hoeveel gegevens verbruikt uw workload?
• Wat is de rekenkundige complexiteit van uw workload?
• Waar leest u gegevens vandaan?
• Hoe worden de gegevens gepartitioneerd in externe opslag?
• Hoeveel parallelle uitvoering hebt u nodig?

Er is een taakverdeling tussen het aantal werkrollen en de grootte van de werkrolinstantietypen. Het configureren van rekenkracht met twee werkrollen, elk met 16 kernen en 128 GB RAM, heeft dezelfde rekenkracht en hetzelfde geheugen als het configureren van rekenkracht met 8 werkrollen, elk met 4 kernen en 32 GB RAM.

Voorbeelden van rekenconfiguratie

In de volgende voorbeelden ziet u aanbevelingen voor berekeningen op basis van specifieke typen workloads. Deze voorbeelden omvatten ook configuraties om te voorkomen en waarom deze configuraties niet geschikt zijn voor de workloadtypen.

Gegevensanalyse

Gegevensanalisten voeren doorgaans verwerking uit die gegevens van meerdere partities nodig heeft, wat leidt tot veel shuffle-bewerkingen. Een rekenresource met een kleiner aantal grotere knooppunten kan de netwerk- en schijf-I/O verminderen die nodig zijn om deze shuffles uit te voeren.

Een rekenproces met één knooppunt met een groot VM-type is waarschijnlijk de beste keuze, met name voor één analist.

Analytische werkbelastingen vereisen waarschijnlijk dat dezelfde gegevens herhaaldelijk worden gelezen, dus aanbevolen knooppunttypen zijn geoptimaliseerd voor opslag met schijfcache ingeschakeld of exemplaren met lokale opslag.

Aanvullende functies die worden aanbevolen voor analytische workloads zijn onder andere:

• Schakel automatische beëindiging in om ervoor te zorgen dat de berekening wordt beëindigd na een periode van inactiviteit.
• Overweeg automatische schaalaanpassing in te schakelen op basis van de typische workload van de analist.

Basisbatch-ETL

Voor eenvoudige BATCH ETL-taken waarvoor geen brede transformaties nodig zijn, zoals joins of aggregaties, gebruikt u exemplaren met lagere vereisten voor geheugen en opslag. Dit kan kostenbesparingen opleveren ten opzichte van andere typen werknemers.

Complexe batch ETL

Voor een complexe ETL-taak, zoals een taak waarvoor samenvoegingen en joins in meerdere tabellen zijn vereist, raadt Azure Databricks aan om minder werkrollen te gebruiken om de hoeveelheid gegevens in willekeurige volgorde te verminderen. Om te compenseren voor het hebben van minder werknemers, verhoogt u de grootte van uw instanties.

Complexe transformaties kunnen rekenintensief zijn. Als u aanzienlijke overloop naar schijven of 'Out of Memory'-fouten tegenkomt, verhoog dan de hoeveelheid geheugen die beschikbaar is op uw instanties.

U kunt eventueel exemplaargroepen gebruiken om de starttijden van rekenprocessen te verlagen en de totale runtime te verminderen bij het uitvoeren van taakpijplijnen.

Machine Learning-modellen trainen

Als u machine learning-modellen wilt trainen, raadt Azure Databricks u aan een rekenresource te maken met behulp van het persoonlijke rekenbeleid.

Gebruik een rekenproces met één knooppunt met een groot knooppunttype voor de eerste experimenten. Minder knooppunten verminderen de impact van herverdelingen.

Het toevoegen van meer werknemers kan helpen bij stabiliteit, maar vermijd te veel werkrollen vanwege de overhead van het versnipperen van gegevens.

Aanbevolen werkroltypen zijn geoptimaliseerd voor opslag met schijfcaching ingeschakeld, of een exemplaar met lokale opslag om rekening te houden met herhaalde leesbewerkingen van dezelfde gegevens en om caching van trainingsgegevens mogelijk te maken.

Aanvullende functies die worden aanbevolen voor machine learning-workloads zijn onder andere:

• Schakel automatische beëindiging in om ervoor te zorgen dat de berekening wordt beëindigd na een periode van inactiviteit.
• Gebruik exemplaargroepen, waarmee rekenkracht kan worden beperkt tot een vooraf goedgekeurd exemplaartype.
• Zorg voor consistente rekenconfiguraties met behulp van beleid.