View a markdown version of this page

Comprendere la strategia e gli scenari di allocazione dei nodi di Amazon EMR - Amazon EMR
Strategia di assegnazione dei nodiConsiderazioni sull'assegnazioneScenari di assegnazione dei nodi

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Comprendere la strategia e gli scenari di allocazione dei nodi di Amazon EMR

In questa sezione viene fornita una panoramica della strategia di allocazione dei nodi e degli scenari di dimensionamento comuni che è possibile utilizzare con il dimensionamento gestito da Amazon EMR.

Strategia di assegnazione dei nodi

Il dimensionamento gestito da Amazon EMR assegna nodi core e attività in base alle seguenti strategie di aumento e riduzione:

Scale-up strategia

  • Per le versioni 7.2 e successive di Amazon EMR, la scalabilità gestita aggiunge innanzitutto i nodi in base alle etichette dei nodi e alla proprietà YARN di restrizione del processo applicativo.

  • Per le release 7.2 e successive di Amazon EMR, se hai abilitato le etichette dei nodi e i processi applicativi limitati ai nodiCORE, la scalabilità gestita di Amazon EMR aumenta la scalabilità verso i nodi core e i nodi task se la domanda dei processi applicativi aumenta e la domanda degli esecutori aumenta. Allo stesso modo, se sono state abilitate le etichette dei nodi e i processi applicativi sono limitati ai ON_DEMAND nodi, la scalabilità gestita aumenta i nodi su richiesta se la domanda del processo applicativo aumenta e aumenta i nodi spot se aumenta la domanda degli esecutori.

  • Se le etichette dei nodi non sono abilitate, il posizionamento dei processi applicativi non è limitato a nessun tipo di nodo o mercato.

  • Utilizzando le etichette dei nodi, la scalabilità gestita può aumentare e ridimensionare diversi gruppi di istanze e flotte di istanze nella stessa operazione di ridimensionamento. Ad esempio, in uno scenario in cui instance_group1 ha un ON_DEMAND nodo e instance_group2 ha un SPOT nodo e le etichette dei nodi sono abilitate e i processi applicativi sono limitati ai nodi con l'etichetta. ON_DEMAND La scalabilità gestita si ridurrà instance_group1 e aumenterà instance_group2 se la domanda dei processi applicativi diminuisce e la domanda degli esecutori aumenta.

  • Quando Amazon EMR subisce un ritardo nel dimensionamento verticale rispetto al gruppo di istanze corrente, i cluster che utilizzano il dimensionamento gestito passano automaticamente a un gruppo di istanze di attività diverso.

  • Se hai impostato il parametro MaximumCoreCapacityUnits, Amazon EMR ridimensiona i nodi principali fino a quando le unità principali non raggiungono il limite massimo consentito. La capacità rimanente viene aggiunta ai nodi attività.

  • Se il MaximumOnDemandCapacityUnits parametro è impostato, Amazon EMR ridimensiona il cluster utilizzando le On-Demand istanze fino a quando le On-Demand unità raggiungono il limite massimo consentito. La capacità rimanente viene aggiunta utilizzando istanze Spot.

  • Se hai impostato entrambi i parametri MaximumCoreCapacityUnits e MaximumOnDemandCapacityUnits, Amazon EMR considera entrambi i limiti durante il dimensionamento.

    Ad esempio, se l'opzione MaximumCoreCapacityUnits è minore di MaximumOnDemandCapacityUnits, Amazon EMR ridimensiona innanzitutto i nodi principali fino al raggiungimento del limite di capacità principale. Per la capacità residua, Amazon EMR utilizza prima On-Demand le istanze per scalare i nodi di attività fino al raggiungimento del On-Demand limite, quindi utilizza le istanze Spot per i nodi di attività.

Scale-down strategia

  • Analogamente alla strategia di scalabilità verticale, Amazon EMR rimuove i nodi in base alle etichette dei nodi. Per ulteriori informazioni sulle etichette dei nodi, consulta Comprendere i tipi di nodi: nodi primari, principali e nodi di attività.

  • Se non hai abilitato le etichette dei nodi, la scalabilità gestita rimuove i nodi di attività e quindi rimuove i nodi principali fino a raggiungere la capacità target di scalabilità verso il basso desiderata. La scalabilità gestita non riduce mai il cluster al di sotto dei vincoli minimi specificati nella politica di scalabilità gestita.

  • Le versioni 5.34.0 e successive di Amazon EMR e le versioni 6.4.0 e successive di Amazon EMR supportano il riconoscimento dei dati shuffle di Spark, che impedisce la scalabilità verso il basso di un'istanza mentre Managed Scaling è a conoscenza dei dati shuffle esistenti. Per ulteriori informazioni sulle operazioni di shuffle, consulta la Guida di programmazione Spark. Managed Scaling fa del suo meglio per evitare che i nodi vengano ridimensionati in modo casuale, con dati provenienti dalla fase corrente e precedente di qualsiasi applicazione Spark attiva, fino a un massimo di 30 minuti. Questo aiuta a ridurre al minimo la perdita involontaria dei dati provenienti dallo shuffle, evitando la necessità di ripetere i tentativi di lavoro e il ricalcolo dei dati intermedi. Tuttavia, la prevenzione della perdita di dati in modalità shuffle non è garantita. Per una migliore protezione da Spark Shuffle, consigliamo di riconoscere lo shuffle su cluster con etichetta di release 7.4 o superiore. Aggiungi i seguenti flag alla configurazione del cluster per abilitare una migliore protezione Spark shuffle.

    • Se il yarn.nodemanager.shuffledata-monitor.interval-ms flag (predefinito 30000 ms) o il spark.dynamicAllocation.executorIdleTimeout (predefinito 60 sec) sono stati modificati rispetto ai valori predefiniti, assicurati che la condizione spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms rimanga aggiornata true aggiornando il flag necessario.

      [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

  • La scalabilità gestita rimuove prima i nodi di attività e poi i nodi principali fino a raggiungere la capacità target di scalabilità verso il basso desiderata. Il cluster non scende mai al di sotto dei vincoli minimi specificati nella politica di scalabilità gestita.

  • Per i cluster lanciati con Amazon EMR 5.x release 5.34.0 e successive e 6.x versioni 6.4.0 e successive, Amazon EMR Managed Scaling non ridimensiona i nodi con ApplicationMaster Apache Spark, se sono presenti fasi attive nelle applicazioni in esecuzione su di essi. Ciò riduce al minimo gli errori e i nuovi tentativi del processo, il che aiuta a migliorare le prestazioni lavorative e a ridurre i costi. Per confermare su quali nodi del cluster è in esecuzione ApplicationMaster, visita Spark History Server e filtra i driver nella scheda Esecutori dell'ID applicazione Spark.

  • Sebbene la scalabilità intelligente con EMR Managed Scaling riduca al minimo la perdita di dati shuffle per Spark, in alcuni casi i dati shuffle transitori potrebbero non essere protetti durante uno scale-down. Per fornire una maggiore resilienza dei dati shuffle durante lo scale-down, consigliamo di abilitare Graceful Decommissioning for Shuffle Data in YARN. Quando Graceful Decommissioning for Shuffle Data è abilitato in YARN, i nodi selezionati per lo scale-down con dati shuffle entreranno nello stato Decommissioning e continueranno a servire i file shuffle. YARN attende che i nodi segnalino l'assenza di file ResourceManager shuffle prima di rimuovere i nodi dal cluster.

    • La versione 6.11.0 e successive di Amazon EMR supportano lo smantellamento Yarn-based graduale dei dati Hive shuffle per i gestori Tez e Shuffle. MapReduce

      • Abilita Graceful yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data Decommissioning true for Shuffle Data impostando su.

    • Amazon EMR versione 7.4.0 e successive supportano lo smantellamento Yarn-based graduale dei dati Spark shuffle quando il servizio shuffle esterno è abilitato (abilitato per impostazione predefinita in EMR su EC2).

      • Il comportamento predefinito del servizio shuffle esterno Spark, quando si esegue Spark su Yarn, prevede che Yarn rimuova i file shuffle delle applicazioni al momento della chiusura dell'applicazione. NodeManager Ciò può avere un impatto sulla velocità di disattivazione dei nodi e sull'utilizzo del calcolo. Per le applicazioni con esecuzione prolungata, valuta la possibilità di spark.shuffle.service.removeShuffle true impostare la rimozione dei file shuffle non più in uso per consentire una più rapida disattivazione dei nodi senza dati shuffle attivi.

    • Per ridurre al minimo la perdita di dati Spark shuffle in Amazon EMR versione 7.4.0 e successive, prendi in considerazione l'impostazione dei seguenti flag.

      • Se il yarn.nodemanager.shuffledata-monitor.interval-ms flag (predefinito 30000 ms) o il spark.dynamicAllocation.executorIdleTimeout (predefinito 60 sec) è stato modificato rispetto ai valori predefiniti, assicurati che la condizione spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms rimanga aggiornata aggiornando il flag necessario. true

        [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

Se il cluster non ha alcun carico, Amazon EMR annulla l'aggiunta di nuove istanze da una valutazione precedente ed esegue operazioni di dimensionamento verso il basso. Se il cluster presenta un carico pesante, Amazon EMR annulla la rimozione delle istanze ed esegue operazioni di aumento.

Considerazioni sull'assegnazione

Ti consigliamo di utilizzare l'opzione di On-Demand acquisto per i nodi principali per evitare la perdita di dati HDFS in caso di recupero di Spot. È possibile utilizzare l'opzione di acquisto Spot per i nodi attività al fine di ridurre i costi e ottenere un'esecuzione più rapida dei processi quando vengono aggiunte più istanze Spot ai nodi attività.

Scenari di assegnazione dei nodi

È possibile creare vari scenari di scalabilità in base alle proprie esigenze impostando i parametri dei nodi principali Massimo, Minimo, On-Demand Limite e Massimo in diverse combinazioni.

Scenario 1: Dimensionare i soli nodi principali

Per ridimensionare solo i nodi principali, i parametri di dimensionamento gestiti devono soddisfare i seguenti requisiti:

  • Il On-Demand limite è uguale al limite massimo.

  • Il nodo principale massimo è uguale al limite massimo.

Quando il On-Demand limite e i parametri massimi del nodo principale non sono specificati, entrambi i parametri utilizzano per impostazione predefinita il limite massimo.

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui CORE nodi, poiché la scalabilità gestita ridimensiona i nodi delle attività per soddisfare la domanda degli esecutori.

I seguenti esempi dimostrano lo scenario di dimensionamento dei nodi principali.

Stato iniziale del cluster Parametri di dimensionamento Comportamento del dimensionamento

Gruppi di istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand e 1 Spot

UnitType: Istanze

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Scala da 1 a 20 istanze o unità del parco istanze sui nodi principali utilizzando il On-Demand tipo. Nessun dimensionamento sui nodi attività.

Quando utilizzi la scalabilità gestita con etichette di nodi e limiti i processi applicativi ai ON_DEMAND nodi, il cluster scalerà da 1 a 20 istanze o unità del parco istanze sui CORE nodi utilizzando il Spot tipo On-Demand o, a seconda del tipo di domanda.

Parchi istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand e 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Scenario 2: Dimensionamento dei soli nodi attività

Per ridimensionare solo i nodi attività, i parametri di dimensionamento gestiti devono soddisfare il seguente requisito:

  • Il nodo principale massimo è uguale al limite minimo.

I seguenti esempi dimostrano lo scenario di dimensionamento dei nodi attività.

Stato iniziale del cluster Parametri di dimensionamento Comportamento del dimensionamento

Gruppi di istanze

Nucleo: 2 On-Demand

Attività: 1 Spot

UnitType: Istanze

MinimumCapacityUnits 2:

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits 2:

Mantenimento dei nodi principali a 2 e dimensionamento dei soli nodi attività da 0 a 18 istanze o unità di parchi istanze. La capacità tra i limiti minimo e massimo viene aggiunta solo ai nodi attività.

Quando si utilizza la scalabilità gestita con etichette dei nodi e si limitano i processi applicativi ai nodi ON_DEMAND, il cluster mantiene invariati i nodi principali su 2 e ridimensiona i nodi di attività solo tra 0 e 18 istanze o unità del parco istanze che utilizzano il tipo or, a seconda del On-demand Spot tipo di domanda.

Parchi istanze

Nucleo: 2 On-Demand

Attività: 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits 2:

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits 2:

Scenario 3: solo On-Demand istanze nel cluster

Per avere solo On-Demand istanze, il cluster e i parametri di scalabilità gestita devono soddisfare i seguenti requisiti:

  • Il On-Demand limite è uguale al limite massimo.

    Quando il On-Demand limite non è specificato, il valore predefinito del parametro è il limite massimo. Il valore predefinito indica che Amazon EMR ridimensiona solo le istanze. On-Demand

Se il nodo principale massimo è inferiore al limite massimo, è possibile utilizzare il parametro nodo principale massimo per dividere l'assegnazione della capacità tra nodi principali e nodi attività.

Per abilitare questo scenario in un cluster composto da gruppi di istanze, tutti i gruppi di nodi del cluster devono utilizzare il tipo di On-Demand mercato durante la configurazione iniziale.

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui ON_DEMAND nodi, poiché la scalabilità gestita ridimensiona i Spot nodi per soddisfare la domanda degli esecutori.

Gli esempi seguenti illustrano lo scenario di presenza di On-Demand istanze nell'intero cluster.

Stato iniziale del cluster Parametri di dimensionamento Comportamento del dimensionamento

Gruppi di istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand

UnitType: Istanze

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Scala da 1 a 12 istanze o unità del parco istanze sui nodi principali utilizzando On-Demand type. Scala la capacità residua utilizzando On-Demand i nodi di attività. Nessun dimensionamento utilizzando istanze Spot.

Quando si utilizza la scalabilità gestita con etichette di nodi e si limitano i processi applicativi ai soli CORE nodi, il cluster viene scalato da 1 a 20 istanze o unità del parco istanze sui nodi o sui CORE nodi che utilizzano il ON_DEMAND tipo, a seconda del tipo di domanda. task La scalabilità sui nodi principali non supererà le 12 istanze o unità del parco istanze.

Parchi istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Scenario 4: Solo istanze Spot nel cluster

Per avere solo istanze Spot, i parametri di dimensionamento gestito devono soddisfare i requisiti seguenti:

  • On-Demand il limite è impostato su 0.

Se il nodo principale massimo è inferiore al limite massimo, è possibile utilizzare il parametro nodo principale massimo per dividere l'assegnazione della capacità tra nodi principali e nodi attività.

Per abilitare questo scenario in un cluster composto da gruppi di istanze, il gruppo di istanze principale deve utilizzare l'opzione acquisto Spot durante la configurazione iniziale. Se non è presente alcuna istanza spot nel gruppo di istanze attività, il dimensionamento gestito da Amazon EMR crea un gruppo di attività utilizzando le istanze spot quando necessario.

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui ON_DEMAND nodi, poiché la scalabilità gestita ridimensiona i ON_DEMAND nodi per soddisfare la domanda dei processi applicativi.

Negli esempi seguenti viene illustrato lo scenario che presenta istanze Spot nell'intero cluster.

Stato iniziale del cluster Parametri di dimensionamento Comportamento del dimensionamento

Gruppi di istanze

Principale: 1 Spot

Attività: 1 Spot

UnitType: Istanze

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Dimensionamento da 1 a 20 istanze o unità di parchi istanze sui nodi principali utilizzando il tipo Spot. Nessun ridimensionamento utilizzando il tipo. On-Demand

Quando si utilizza la scalabilità gestita con etichette di nodi e si limitano i processi applicativi ai soli CORE nodi, il cluster viene scalato da 1 a 20 istanze o unità del parco istanze su CORE o TASK nodi che utilizzano Spot, a seconda del tipo di domanda. Amazon EMR non è scalabile utilizzando questo tipo. ON_DEMAND

Parchi istanze

Principale: 1 Spot

Attività: 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Scenario 5: scalabilità On-Demand delle istanze sui nodi principali e istanze Spot sui nodi delle attività

Per scalare On-Demand le istanze sui nodi principali e le istanze Spot sui nodi delle attività, i parametri di scalabilità gestiti devono soddisfare i seguenti requisiti:

  • Il On-Demand limite deve essere uguale al numero massimo di nodi principali.

  • Sia il On-Demand limite che il nodo centrale massimo devono essere inferiori al limite massimo.

Per abilitare questo scenario in un cluster composto da gruppi di istanze, il gruppo di nodi principali deve utilizzare l'opzione On-Demand di acquisto.

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette di nodi e si limita l'esecuzione dei processi applicativi solo su ON_DEMAND nodi o CORE nodi.

Gli esempi seguenti illustrano lo scenario di scalabilità delle On-Demand istanze sui nodi principali e delle istanze Spot sui nodi delle attività.

Stato iniziale del cluster Parametri di dimensionamento Comportamento del dimensionamento

Gruppi di istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand e 1 Spot

UnitType: Istanze

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Scala fino a 6 On-Demand unità sul nodo principale poiché c'è già 1 On-Demand unità nel nodo attività e il limite massimo per On-Demand è 7. In seguito, aumento a 13 unità Spot sui nodi attività.

Parchi istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand e 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Scenario 6: scalare CORE le istanze per la domanda dei processi applicativi e TASK le istanze per la domanda degli esecutori.

Questo scenario è applicabile solo se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui nodi. CORE

Per scalare CORE i nodi in base alla richiesta del processo applicativo e TASK i nodi in base alla domanda degli esecutori, è necessario impostare le seguenti configurazioni all'avvio del cluster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'CORE'

Se non si specificano il ON_DEMAND limite e i parametri massimi del CORE nodo, entrambi i parametri utilizzano per impostazione predefinita il limite massimo.

Se il ON_DEMAND nodo massimo è inferiore al limite massimo, la scalabilità gestita utilizza il parametro del ON_DEMAND nodo massimo per suddividere l'allocazione della capacità tra i nodi. ON_DEMAND SPOT Se si imposta il parametro del CORE nodo massimo su un valore inferiore o uguale al parametro di capacità minima, CORE i nodi rimangono statici alla capacità core massima.

Gli esempi seguenti illustrano lo scenario di scalabilità delle istanze CORE in base alla domanda dei processi applicativi e delle istanze TASK in base alla domanda dell'esecutore.

Stato iniziale del cluster Parametri di dimensionamento Comportamento del dimensionamento

Gruppi di istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand

UnitType: Istanze

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Scala i CORE nodi tra 1 e 20 nodi in base alla richiesta del processo applicativo del cluster utilizzando il tipo di mercato On-Demand o Spot. Ridimensiona i TASK nodi in base alla domanda dell'esecutore e alla capacità disponibile residua dopo l'allocazione dei nodi da parte di Amazon EMR. CORE

La somma delle richieste CORE e dei TASK nodi non supererà il valore di 20. maximumCapacity La somma dei nodi principali su richiesta e dei nodi di attività su richiesta non supererà il numero maximumOnDemandCapacity di 10. I nodi core o task aggiuntivi utilizzano il tipo di mercato Spot.

Parchi istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Scenario 7: scalare ON_DEMAND le istanze per la domanda dei processi applicativi e SPOT le istanze per la domanda degli esecutori.

Questo scenario è applicabile solo se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui nodi. ON_DEMAND

Per scalare ON_DEMAND i nodi in base alla richiesta del processo applicativo e SPOT i nodi in base alla domanda degli esecutori, è necessario impostare le seguenti configurazioni all'avvio del cluster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'

Se non si specificano il ON_DEMAND limite e i parametri massimi del CORE nodo, entrambi i parametri utilizzano per impostazione predefinita il limite massimo.

Se il CORE nodo massimo è inferiore al limite massimo, la scalabilità gestita utilizza il parametro del CORE nodo massimo per suddividere l'allocazione della capacità tra i nodi. CORE TASK Se si imposta il parametro del CORE nodo massimo su un valore inferiore o uguale al parametro di capacità minima, CORE i nodi rimangono statici alla capacità core massima.

Gli esempi seguenti illustrano lo scenario di scalabilità delle On-Demand istanze in base alla domanda del processo applicativo e delle istanze Spot in base alla domanda dell'esecutore.

Stato iniziale del cluster Parametri di dimensionamento Comportamento del dimensionamento

Gruppi di istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand

UnitType: Istanze

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10

Ridimensiona i ON_DEMAND nodi tra 1 e 20 nodi in base alla richiesta del processo applicativo del cluster utilizzando il tipo di TASK nodo CORE or. Ridimensiona i SPOT nodi in base alla domanda dell'esecutore e alla capacità disponibile residua dopo l'allocazione dei nodi da parte di Amazon EMR. ON_DEMAND

La somma delle richieste ON_DEMAND e dei SPOT nodi non supererà il valore di 20. maximumCapacity La somma dei nodi core on-demand richiesti e dei nodi core spot non supererà il valore maximumCoreCapacity di 10. I nodi on-demand o spot aggiuntivi utilizzano il tipo di TASK nodo.

Parchi istanze

Nucleo: 1 On-Demand

Compito: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10