Best practices: Clusterconfiguratie

Azure Databricks biedt een aantal opties bij het maken en configureren van clusters om u te helpen de beste prestaties te krijgen tegen de laagste kosten. Deze flexibiliteit kan echter voor uitdagingen zorgen wanneer u probeert optimale configuraties voor uw workloads te bepalen. Wanneer u nieuwe clusters maakt of bestaande clusters configureert, kunt u zorgvuldig overwegen hoe gebruikers clusters gaan gebruiken. Enkele van de dingen die u moet overwegen bij het bepalen van configuratieopties zijn:

  • Welk type gebruiker gebruikt het cluster? Een data scientist kan verschillende taaktypen uitvoeren met andere vereisten dan een data engineer of gegevensanalist.
  • Welke typen workloads worden gebruikers uitgevoerd op het cluster? EtL-taken (batchextractie, transformatie en belasting) hebben bijvoorbeeld waarschijnlijk andere vereisten dan analytische workloads.
  • Aan welk slaniveau (Service Level Agreement) moet u voldoen?
  • Welke budgetbeperkingen hebt u?

Dit artikel bevat aanbevelingen voor clusterconfiguratie voor verschillende scenario's op basis van deze overwegingen. In dit artikel worden ook specifieke functies van Azure Databricks clusters en de overwegingen besproken waar u rekening mee moet houden voor deze functies.

Uw configuratiebeslissingen vereisen een afweging tussen kosten en prestaties. De primaire kosten van een cluster omvatten de Databricks Units (DDO's) die worden gebruikt door het cluster en de kosten van de onderliggende resources die nodig zijn om het cluster uit te voeren. Wat mogelijk niet duidelijk is, zijn de secundaire kosten, zoals de kosten voor uw bedrijf om niet te voldoen aan een SLA, verminderde efficiëntie van werknemers of mogelijke verspilling van resources vanwege slechte controles.

Clusterfuncties

Voordat u meer gedetailleerde scenario's voor clusterconfiguraties bespreekt, is het belangrijk dat u een aantal functies van Azure Databricks clusters begrijpt en hoe u deze functies het beste kunt gebruiken.

Clusters en taakclusters voor alle doeleinden

Wanneer u een cluster maakt, selecteert u een clustertype: een cluster voor alle doeleinden of een taakcluster. Clusters voor alle doeleinden kunnen worden gedeeld door meerdere gebruikers en zijn het beste voor het uitvoeren van ad-hocanalyse, gegevensverkenning of ontwikkeling. Zodra u klaar bent met het implementeren van uw verwerking en klaar bent om uw code operationeel te maken, schakelt u over naar het uitvoeren ervan op een taakcluster. Taakclusters worden beëindigd wanneer uw taak is beëindigd, waardoor het resourcegebruik en de kosten worden verkleind.

Clustermodus

Azure Databricks ondersteunt drie clustermodi:Standard, Hoge gelijktijdigheid en Eén knooppunt. De meeste gewone gebruikers gebruiken Standard- of Single Node-clusters.

  • Standaardclusters zijn ideaal voor het verwerken van grote hoeveelheden gegevens met Apache Spark.
  • Clusters met één knooppunt zijn bedoeld voor taken die kleine hoeveelheden gegevens of niet-gedistribueerde workloads gebruiken, zoals bibliotheken met machine learning knooppunt.
  • Clusters met hoge gelijktijdigheid zijn ideaal voor groepen gebruikers die resources moeten delen of ad-hoctaken moeten uitvoeren. Beheerders maken meestal clusters met hoge gelijktijdigheid. Databricks raadt aan automatisch schalen in te schakelen voor clusters met hoge gelijktijdigheid.

Instanties op aanvraag en spot-instanties

Om kosten te besparen, Azure Databricks het maken van clusters met behulp van een combinatie van on-demand en spot-exemplaren. U kunt spot-exemplaren gebruiken om te profiteren van ongebruikte capaciteit in Azure om de kosten voor het uitvoeren van uw toepassingen te verlagen, de rekencapaciteit van uw toepassing te vergroten en de doorvoer te verhogen.

Automatisch schalen

Met automatische schalen kunnen clusters automatisch de schalen op basis van workloads. Automatisch schalen kan profiteren van veel gebruiksscenario's en scenario's vanuit zowel het oogpunt van kosten als prestaties, maar het kan lastig zijn om te begrijpen wanneer en hoe u automatisch schalen gebruikt. Hier volgen enkele overwegingen om te bepalen of automatisch schalen moet worden gebruikt en hoe u het meeste voordeel kunt halen:

  • Automatisch schalen verlaagt doorgaans de kosten in vergelijking met een cluster met een vaste grootte.
  • Werkbelastingen voor automatisch schalen kunnen sneller worden uitgevoerd in vergelijking met een te klein ingericht cluster met een vaste grootte.
  • Sommige workloads zijn niet compatibel met clusters voor automatisch schalen, waaronder spark-submit-taken en sommige Python-pakketten.
  • Met clusters voor alle doeleinden voor één gebruiker kunnen gebruikers merken dat automatisch schalen hun ontwikkeling of analyse vertraagt wanneer het minimum aantal werknemers te laag is ingesteld. Dit komt doordat de opdrachten of query's die ze uitvoeren vaak enkele minuten uit elkaar liggen, de tijd waarin het cluster inactief is en omlaag kan worden geschaald om kosten te besparen. Wanneer de volgende opdracht wordt uitgevoerd, probeert de clusterbeheerder omhoog te schalen. Dit duurt enkele minuten bij het ophalen van exemplaren van de cloudprovider. Gedurende deze tijd kunnen taken worden uitgevoerd met onvoldoende resources, wat de tijd vertraagt om resultaten op te halen. Hoewel het verhogen van het minimum aantal werkpersoneel helpt, verhoogt het ook de kosten. Dit is nog een voorbeeld waarin kosten en prestaties in balans moeten worden gebracht.
  • Als Delta Caching wordt gebruikt, is het belangrijk om te onthouden dat alle gegevens in de cache op een knooppunt verloren gaan als dat knooppunt wordt beëindigd. Als het bewaren van gegevens in de cache belangrijk is voor uw workload, kunt u een cluster met een vaste grootte gebruiken.
  • Als u een taakcluster hebt waarop een ETL-workload wordt uitgevoerd, kunt u het cluster soms op de juiste manier in grootte wijzigen als u weet dat uw taak waarschijnlijk niet zal veranderen. Automatisch schalen biedt u echter flexibiliteit als uw gegevensgrootten toenemen. Het is ook belangrijk om te weten dat geoptimaliseerde automatische schalen de kosten voor langlopende taken kan verminderen als er lange perioden zijn waarin het cluster te weinig wordt gebruikt of wacht op resultaten van een ander proces. Nogmaals, uw taak kan kleine vertragingen ervaren omdat het cluster op de juiste manier omhoog probeert te schalen. Als u strenge SLA's voor een taak hebt, is een cluster met vaste grootte mogelijk een betere keuze of kunt u overwegen een Azure Databricks-pool te gebruiken om de begintijden van het cluster te verminderen.

Azure Databricks biedt ook ondersteuning voor automatisch schalen van lokale opslag. Met automatisch schalen van lokale opslag bewaakt Azure Databricks de hoeveelheid vrije schijfruimte die beschikbaar is op de Spark-werksters van uw cluster. Als een werker te weinig op schijf wordt uitgevoerd, Azure Databricks automatisch een nieuw beheerd volume aan de werkmedewerker gekoppeld voordat de schijfruimte op is.

Pools

Pools verminderen de opstart- en opschaaltijden van clusters door een set beschikbare, kant-en-klaar instanties te onderhouden. Databricks raadt aan gebruik te maken van pools om de verwerkingstijd te verbeteren en tegelijkertijd de kosten te minimaliseren.

Databricks Runtime versies

Databricks raadt u aan de meest recente Databricks Runtime voor clusters voor alle doeleinden te gebruiken. Als u de meest recente versie gebruikt, hebt u de nieuwste optimalisaties en de meest recente compatibiliteit tussen uw code en vooraf geladen pakketten.

Voor taakclusters met operationele workloads kunt u de lts-versie (Long Term Support) Databricks Runtime gebruiken. Als u de LTS-versie gebruikt, hebt u geen compatibiliteitsproblemen en kunt u uw workload grondig testen voordat u een upgrade gaat uitvoeren. Als u een geavanceerde use-case hebt met machine learning of genomics, kunt u de gespecialiseerde Databricks Runtime overwegen.

Clusterbeleid

Azure Databricks clusterbeleid kunnen beheerders controle afdwingen over het maken en configureren van clusters. Databricks raadt het gebruik van clusterbeleid aan om de aanbevelingen toe te passen die in deze handleiding worden besproken. Meer informatie over clusterbeleid in de handleiding met best practices voor clusterbeleid.

Automatische beëindiging

Veel gebruikers zullen er niet aan denken om hun clusters te beëindigen wanneer ze klaar zijn met het gebruik ervan. Gelukkig worden clusters automatisch beëindigd na een bepaalde periode, met een standaardwaarde van 120 minuten.

Beheerders kunnen deze standaardinstelling wijzigen bij het maken van clusterbeleid. Als u deze instelling verlaagt, kunnen de kosten worden verlaagd doordat clusters minder lang inactief zijn. Wanneer een cluster wordt beëindigd, gaat alle status verloren, inclusief alle variabelen, tijdelijke tabellen, caches, functies, objecten, enzovoort. Al deze status moet worden hersteld wanneer het cluster opnieuw wordt gestart. Als een ontwikkelaar een lunchpauze van 30 minuten heeft, is het een verspilling om net zoveel tijd te besteden aan het terug krijgen van een notebook als voorheen.

Belangrijk

Inactieve clusters blijven kosten voor DBU's en cloud-exemplaren in rekening brengen tijdens de inactiviteitsperiode vóór beëindiging.

Garbageverzameling

Hoewel het minder voor de hand ligt dan andere overwegingen die in dit artikel worden besproken, kan het beter zijn om te letten op garbageverzameling om de taakprestaties van uw clusters te optimaliseren. Het bieden van een grote hoeveelheid RAM-geheugen kan helpen taken efficiënter uit te voeren, maar kan ook leiden tot vertragingen tijdens garbageverzameling.

Om de impact van lange garbageopruimingsopruimingen te minimaliseren, moet u voorkomen dat clusters worden geïmplementeerd met grote hoeveelheden RAM-geheugen die voor elk exemplaar zijn geconfigureerd. Als er meer RAM aan de uitvoerder wordt toegewezen, leidt dit tot langere garbage-ophaaltijden. Configureer in plaats daarvan exemplaren met kleinere RAM-grootten en implementeer meer exemplaren als u meer geheugen nodig hebt voor uw taken. Er zijn echter gevallen waarin minder knooppunten met meer RAM-geheugen worden aanbevolen, bijvoorbeeld workloads waarvoor veel shuffles zijn vereist, zoals besproken in Overwegingenvoor clustersizing.

Toegangsbeheer voor clusters

U kunt twee typen clustermachtigingen configureren:

  • Met de machtiging Cluster maken toestaan bepaalt u de mogelijkheid van gebruikers om clusters te maken.
  • Machtigingen op clusterniveau bepalen de mogelijkheid om een specifiek cluster te gebruiken en te wijzigen.

Zie clustertoegangsbeheer voor meer informatie over het configureren van clustermachtigingen.

U kunt een cluster maken als u over machtigingen voor het maken van clusters of toegang tot een clusterbeleid hebt, zodat u een cluster kunt maken binnen de specificaties van het beleid. De maker van het cluster is de eigenaar en heeft machtigingen voor kan beheren, waardoor deze kan worden gedeeld met andere gebruikers binnen de beperkingen van de machtigingen voor gegevenstoegang van het cluster.

Inzicht in clustermachtigingen en clusterbeleid is belangrijk bij het bepalen van clusterconfiguraties voor algemene scenario's.

Clustertags

Met clustertags kunt u eenvoudig de kosten bewaken van cloudbronnen die door verschillende groepen in uw organisatie worden gebruikt. U kunt tags opgeven als sleutel-waardereeksen bij het maken van een cluster. Azure Databricks tags worden toegepast op cloudbronnen, zoals instanties en EBS-volumes. Meer informatie over het afdwingen van tags in de handleiding met best practices voor clusterbeleid.

Overwegingen met het oog op cluster-formaat

Azure Databricks voert één uitvoerder per werkpunt uit. Daarom worden de termen executor en worker door elkaar gebruikt in de context van de Azure Databricks architectuur. Mensen denken vaak aan de clustergrootte 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. Hiermee bepaalt u de maximale parallellisme van een cluster.
  • Totaal uitvoergeheugen: de totale hoeveelheid RAM-geheugen voor alle uitvoerders. Hiermee bepaalt u hoeveel gegevens in het geheugen kunnen worden opgeslagen voordat ze naar de schijf worden geleed.
  • Lokale uitvoerderopslag: het type en de hoeveelheid lokale schijfopslag. Lokale schijf wordt voornamelijk gebruikt in het geval van lekkage tijdens willekeurige volgorde en caching.

Aanvullende overwegingen zijn het type en de grootte van het worker-exemplaar, die ook van invloed zijn op de bovenstaande factoren. Overweeg het volgende wanneer u de cluster het formaat wilt laten insommen:

  • Hoeveel gegevens verbruikt uw workload?
  • Wat is de rekencomplexiteit van uw workload?
  • Waar leest u gegevens vandaan?
  • Hoe worden de gegevens gepart partitioneerd in externe opslag?
  • Hoeveel parallelle parallellelisme hebt u nodig?

Door deze vragen te beantwoorden, kunt u optimale clusterconfiguraties bepalen op basis van workloads. Voor eenvoudige WORKLOADS in ETL-stijl die alleen beperkte transformaties gebruiken (transformaties waarbij elke invoerpartitie bijdraagt aan slechts één uitvoerpartitie), richt u zich op een voor rekenkracht geoptimaliseerde configuratie. Als u veel willekeurige volgordes verwacht, is de hoeveelheid geheugen belangrijk, evenals opslag om rekening te houden met lekkage van gegevens. Minder grote instanties kunnen de netwerk-I/O verminderen bij het overdragen van gegevens tussen machines tijdens het verdelen van zware werkbelastingen.

Er is een taakverdeling tussen het aantal werksters en de grootte van de typen werk exemplaar. Een cluster met twee werkknooppunt, elk met 40 kernen en 100 GB RAM, heeft dezelfde rekenkracht en hetzelfde geheugen als een acht werkknooppuntcluster met 10 kernen en 25 GB RAM-geheugen.

Als u veel herlezen van dezelfde gegevens verwacht, kunnen uw workloads profiteren van caching. Overweeg een configuratie die is geoptimaliseerd voor opslag met Delta Cache.

Voorbeelden van clusteringsizing

In de volgende voorbeelden worden clusteraanbevelingen op basis van specifieke typen workloads gegeven. Deze voorbeelden omvatten ook configuraties om te voorkomen en waarom deze configuraties niet geschikt zijn voor de workloadtypen.

Gegevensanalyse

Gegevensanalisten voeren doorgaans verwerking uit waarvoor gegevens uit meerdere partities zijn vereist, wat leidt tot veel willekeurige bewerkingen. Een cluster met een kleiner aantal knooppunten kan het netwerk en de schijf-I/O verminderen die nodig zijn om deze willekeurige volgordes uit te voeren. Cluster A in het volgende diagram is waarschijnlijk de beste keuze, met name voor clusters die één analist ondersteunen.

Cluster D levert waarschijnlijk de slechtste prestaties, omdat voor een groter aantal knooppunten met minder geheugen en opslag meer gegevenssnippers nodig zijn om de verwerking te voltooien.

Formaat van gegevensanalysecluster

Analytische workloads moeten waarschijnlijk dezelfde gegevens herhaaldelijk lezen, dus aanbevolen werktypen zijn geoptimaliseerd voor opslag waarvoor Delta Cache is ingeschakeld.

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

  • Schakel automatische beëindiging in om ervoor te zorgen dat clusters worden beëindigd na een periode van inactiviteit.
  • Overweeg automatische schalen in te stellen op basis van de typische workload van de analist.
  • Overweeg het gebruik van pools, waarmee clusters worden beperkt tot vooraf goedgekeurde exemplaartypen en consistente clusterconfiguraties worden gegarandeerd.

Functies die waarschijnlijk niet nuttig zijn:

  • Storage automatisch schalen, omdat deze gebruiker waarschijnlijk niet veel gegevens produceert.
  • Clusters met hoge gelijktijdigheid, omdat dit cluster voor één gebruiker is, en clusters met hoge gelijktijdigheid het meest geschikt zijn voor gedeeld gebruik.

Basic batch ETL

Eenvoudige batch-ETL-taken waarvoor geen brede transformaties nodig zijn, zoals samenvoegingen of aggregaties, profiteren doorgaans van clusters die zijn geoptimaliseerd voor rekenkracht. Voor deze typen workloads zijn clusters in het volgende diagram waarschijnlijk acceptabel.

Basic batch ETL cluster sizing (Formaat van ETL-basisbatchcluster)

Werktypen die zijn geoptimaliseerd voor rekenkracht worden aanbevolen; Deze zijn goedkoper en voor deze workloads is waarschijnlijk geen aanzienlijk geheugen of opslag nodig.

Het gebruik van een pool kan een voordeel bieden voor clusters die eenvoudige ETL-taken ondersteunen door de starttijden van clusters te verlagen en de totale runtime bij het uitvoeren van taakpijplijnen te verminderen. Omdat dit soort werkbelastingen doorgaans worden uitgevoerd als geplande taken waarbij het cluster slechts lang genoeg wordt uitgevoerd om de taak te voltooien, biedt het gebruik van een pool mogelijk geen voordeel.

De volgende functies zijn waarschijnlijk niet nuttig:

  • Delta Caching, omdat het opnieuw lezen van gegevens niet wordt verwacht.
  • Automatische beëindiging is waarschijnlijk niet vereist, omdat dit waarschijnlijk geplande taken zijn.
  • Automatische schalen wordt niet aanbevolen omdat reken- en opslaginstellingen vooraf moeten worden geconfigureerd voor de use-case.
  • Clusters met hoge gelijktijdigheid zijn bedoeld voor meerdere gebruikers en profiteren niet van een cluster met één taak.

Complexe batch-ETL

Complexere ETL-taken, zoals verwerking die samenslances en joins tussen meerdere tabellen vereisen, werken waarschijnlijk het beste wanneer u de hoeveelheid gegevens in willekeurige volgorde kunt minimaliseren. Omdat het verminderen van het aantal werklasten in een cluster helpt bij het minimaliseren van willekeurige volgordes, moet u een kleiner cluster zoals cluster A overwegen in het volgende diagram over een groter cluster, zoals cluster D.

Complexe ETL-clustering

Complexe transformaties kunnen rekenintensief zijn, dus voor sommige workloads die een optimaal aantal kernen bereiken, moeten mogelijk extra knooppunten aan het cluster worden toegevoegd.

Net als bij eenvoudige ETL-taken worden werktypen aanbevolen die zijn geoptimaliseerd voor rekenkracht; Deze zijn goedkoper en voor deze workloads is waarschijnlijk geen aanzienlijk geheugen of opslag nodig. Net als bij eenvoudige ETL-taken is de belangrijkste clusterfunctie waarmee u rekening moet houden pools om de starttijden van clusters te verlagen en de totale runtime bij het uitvoeren van taakpijplijnen te verminderen.

De volgende functies zijn waarschijnlijk niet nuttig:

  • Delta Caching, omdat het opnieuw lezen van gegevens niet wordt verwacht.
  • Automatische beëindiging is waarschijnlijk niet vereist, omdat dit waarschijnlijk geplande taken zijn.
  • Automatische schalen wordt niet aanbevolen omdat reken- en opslaginstellingen vooraf moeten worden geconfigureerd voor de use-case.
  • Clusters met hoge gelijktijdigheid zijn bedoeld voor meerdere gebruikers en profiteren niet van een cluster met één taak.

Trainingsmodellen machine learning trainen

Aangezien initiële iteraties van het trainen van machine learning model vaak experimenteel zijn, is een kleiner cluster, zoals cluster A, een goede keuze. Een kleiner cluster vermindert ook de impact van willekeurige volgorde.

Als stabiliteit een probleem is, of voor meer geavanceerde fasen, kan een groter cluster, zoals cluster B of C, een goede keuze zijn.

Een groot cluster, zoals cluster D, wordt niet aanbevolen vanwege de overhead van het insempleren van gegevens tussen knooppunten.

Formaat van Machine Learning-cluster

Aanbevolen werktypen zijn geoptimaliseerd voor opslag met Delta Caching ingeschakeld om rekening te houden met herhaalde lees lezen van dezelfde gegevens en om het opslaan van trainingsgegevens in de caching mogelijk te maken. Als de reken- en opslagopties van knooppunten die zijn geoptimaliseerd voor opslag niet voldoende zijn, kunt u gpu-geoptimaliseerde knooppunten overwegen. Een mogelijk nadeel is het ontbreken van Delta-Caching ondersteuning voor deze knooppunten.

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

  • Schakel automatische beëindiging in om ervoor te zorgen dat clusters worden beëindigd na een periode van inactiviteit.
  • Overweeg automatische schalen in te stellen op basis van de typische workload van de analist.
  • Gebruik pools, waarmee clusters worden beperkt tot vooraf goedgekeurde exemplaartypen en consistente clusterconfiguraties worden gegarandeerd.

Functies die waarschijnlijk niet nuttig zijn:

  • Automatisch schalen, omdat gegevens in de cache verloren kunnen gaan wanneer knooppunten worden verwijderd wanneer een cluster omlaag wordt geschaald. Daarnaast worden bij machine learning taken vaak alle beschikbare knooppunten gebruikt. In dat geval biedt automatisch schalen geen voordelen.
  • Storage automatisch schalen, omdat deze gebruiker waarschijnlijk niet veel gegevens produceert.
  • Clusters met hoge gelijktijdigheid, omdat dit cluster voor één gebruiker is, en clusters met hoge gelijktijdigheid het meest geschikt zijn voor gedeeld gebruik.

Algemene scenario's

De volgende secties bieden aanvullende aanbevelingen voor het configureren van clusters voor algemene clustergebruikspatronen:

  • Meerdere gebruikers die gegevensanalyse en ad-hocverwerking uitvoeren.
  • Gespecialiseerde gebruiksgevallen zoals machine learning.
  • Ondersteuning voor geplande batchtaken.

Clusters voor meerdere gebruikers

Scenario

U moet meerdere gebruikers toegang geven tot gegevens voor het uitvoeren van gegevensanalyse en ad-hocquery's. Het clustergebruik kan in de tijd fluctueren en de meeste taken zijn niet erg resource-intensief. De gebruikers hebben voornamelijk alleen-lezentoegang tot de gegevens nodig en willen analyses uitvoeren of dashboards maken via een eenvoudige gebruikersinterface.

De aanbevolen aanpak voor het inrichten van clusters is een hybride benadering voor het inrichten van knooppunt in het cluster, samen met automatische schalen. Een hybride benadering omvat het definiëren van het aantal on-demand exemplaren en spot-exemplaren voor het cluster en het inschakelen van automatisch schalen tussen het minimum en het maximum aantal exemplaren.

Scenario voor meerdere gebruikers

Dit cluster is altijd beschikbaar en wordt standaard gedeeld door de gebruikers die tot een groep behoren. Door automatisch schalen in te stellen, kan het cluster omhoog en omlaag worden geschaald, afhankelijk van de belasting.

Gebruikers hebben geen toegang tot het starten/stoppen van het cluster, maar de eerste instanties op aanvraag zijn onmiddellijk beschikbaar om te reageren op gebruikersquery's. Als de gebruikersquery meer capaciteit vereist, worden met automatische schalen automatisch meer knooppunten (voornamelijk spot-instanties) voor de werkbelasting geconfigureerd.

Azure Databricks heeft andere functies om gebruiksgevallen met meerdere tenancy verder te verbeteren:

Met deze aanpak blijven de totale kosten omlaag door:

  • Een gedeeld clustermodel gebruiken.
  • Een combinatie van on-demand en spot-exemplaren gebruiken.
  • Automatisch schalen gebruiken om te voorkomen dat u betaalt voor te veel gebruikte clusters.

Gespecialiseerde workloads

Scenario

U moet clusters bieden voor gespecialiseerde use cases of teams binnen uw organisatie, bijvoorbeeld gegevenswetenschappers die complexe gegevensverkenning uitvoeren en machine learning algoritmen. Een typisch patroon is dat een gebruiker een cluster voor een korte periode nodig heeft om de analyse uit te voeren.

De beste aanpak voor dit type workload is het maken van clusterbeleid met vooraf gedefinieerde configuraties voor standaard-, vaste- en instellingenbereiken. Deze instellingen kunnen het aantal exemplaren, exemplaartypen, spot- versus on-demand exemplaren, rollen, bibliotheken die moeten worden geïnstalleerd, enzovoort omvatten. Met behulp van clusterbeleid kunnen gebruikers met geavanceerdere vereisten snel clusters maken die ze naar behoefte kunnen configureren voor hun use-case en kosten en naleving van beleid afdwingen.

Gespecialiseerde workloads

Deze aanpak biedt gebruikers meer controle terwijl de mogelijkheid wordt behouden om de kosten onder controle te houden door vooraf clusterconfiguraties te definiëren. Hiermee kunt u ook clusters configureren voor verschillende groepen gebruikers met machtigingen voor toegang tot verschillende gegevenssets.

Een nadeel van deze benadering is dat gebruikers met beheerders moeten werken voor eventuele wijzigingen in clusters, zoals configuratie, geïnstalleerde bibliotheken, enzovoort.

Batchworkloads

Scenario

U moet clusters bieden voor geplande batchtaken, zoals productie-ETL-taken die gegevensvoorbereiding uitvoeren. De voorgestelde best practice is het starten van een nieuw cluster voor elke taak die wordt uitgevoerd. Het uitvoeren van elke taak in een nieuw cluster helpt fouten en gemiste SLA's te voorkomen die worden veroorzaakt door andere workloads die worden uitgevoerd op een gedeeld cluster. Afhankelijk van het kritieke niveau voor de taak kunt u alle instanties op aanvraag gebruiken om te voldoen aan sla's of om een balans te vinden tussen spot- en on-demand instanties voor kostenbesparingen.

Geplande batchworkloads