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 versioni 7.2 e successive di Amazon EMR, se hai abilitato le etichette dei nodi e limitato i processi applicativi ai CORE nodi, la scalabilità gestita di Amazon EMR aumenta la scalabilità dei nodi principali e dei nodi di attività se la domanda dei processi applicativi aumenta e la domanda degli esecutori aumenta. Allo stesso modo, se hai abilitato le etichette dei nodi e limitato i processi applicativi ai ON_DEMAND nodi, la scalabilità gestita aumenta i nodi su richiesta se la domanda dei processi applicativi aumenta e i nodi spot se la domanda degli esecutori aumenta.

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

  • Utilizzando le etichette dei nodi, la scalabilità gestita può aumentare e diminuire 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 raggiungere il limite massimo On-Demand 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 delle 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à, Amazon EMR rimuove i nodi in base alle etichette dei nodi. Per ulteriori informazioni sulle etichette dei nodi, consulta Understand node types: primary, core e task nodes.

  • Se non hai abilitato le etichette dei nodi, Managed Scaling rimuove i nodi delle attività e quindi rimuove i nodi principali fino a raggiungere la capacità target di scalabilità 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 Spark shuffle data awareness, che impedisce il ridimensionamento 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 prevenire la riduzione dei nodi con dati shuffle della fase attuale 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 in modalità shuffle, evitando la necessità di ripetere i tentativi di lavoro e di ricalcolare i dati intermedi. Tuttavia, la prevenzione della perdita di dati shuffle non è garantita. Per una migliore protezione da Spark shuffle, consigliamo lo shuffle awareness sui cluster con etichetta di release 7.4 o superiore. Aggiungi i seguenti flag alla configurazione del cluster per abilitare una migliore protezione da Spark shuffle.

    • 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 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"
		}
	}
]

  • Il ridimensionamento gestito rimuove prima i nodi delle attività e quindi i nodi principali fino a raggiungere la capacità target di scalabilità desiderata. Il cluster non scende mai al di sotto dei vincoli minimi specificati nella politica di scalabilità gestita.

  • Per i cluster avviati con le versioni 5.34.0 e successive di Amazon EMR 5.x e 6.x 6.4.0 e successive, Amazon EMR Managed Scaling non ridimensiona i nodi che utilizzano Apache Spark, se vi sono fasi attive nelle applicazioni in ApplicationMaster 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, ci possono essere casi in cui 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 che contengono dati shuffle entreranno nello stato Decommissioning e continueranno a pubblicare file shuffle. YARN attende che i nodi segnalino l'assenza di file shuffle prima ResourceManager di rimuovere i nodi dal cluster.

    • Amazon EMR versione 6.11.0 e successive supportano lo smantellamento Yarn-based graduale dei dati Hive shuffle sia per i gestori Tez che per quelli 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 di default 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 dell'applicazione al momento della chiusura dell'applicazione. NodeManager Ciò può avere un impatto sulla velocità di disattivazione dei nodi e sull'utilizzo del computer. Per le applicazioni a lunga durata, valuta la possibilità di spark.shuffle.service.removeShuffle true rimuovere i file shuffle non più in uso per consentire una disattivazione più rapida 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, valuta la possibilità di impostare i 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 permanga 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 ripristino 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 del nodo principale 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 i parametri On-Demand limite e massimo del nodo principale non sono specificati, entrambi i parametri hanno come impostazione predefinita il limite massimo.

Questo scenario non è applicabile se si utilizza la scalabilità gestita con le 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 flotte di istanze sui nodi principali utilizzando il On-Demand tipo. Nessun dimensionamento sui nodi attività.

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

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 le etichette dei nodi e si limitano i processi dell'applicazione ai nodi ON_DEMAND, il cluster manterrà i nodi principali stabili a 2 e scalerà solo i nodi di attività tra 0 e 18 istanze o unità del parco di istanze che utilizzano il tipo or, a seconda del On-demand Spot tipo di richiesta.

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à gestiti 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 le 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 dimostrano lo scenario di avere 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 di istanze sui nodi principali utilizzando il On-Demand tipo. Scala la capacità rimanente utilizzando i On-Demand nodi delle attività. Nessun dimensionamento utilizzando istanze Spot.

Quando si utilizza la scalabilità gestita con le etichette dei nodi e si limitano i processi dell'applicazione ai CORE nodi, il cluster scala da 1 a 20 istanze o unità di flotte di istanze su CORE nodi o task nodi che utilizzano il ON_DEMAND tipo, a seconda del tipo di richiesta. La scalabilità sui nodi principali non supererà le 12 istanze o il parco di unità di 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 le 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. Nessuna scalabilità utilizzando il tipo. On-Demand

Quando utilizzi la scalabilità gestita con le etichette dei nodi e limiti i processi dell'applicazione ai CORE nodi, il cluster scala da 1 a 20 istanze o unità del parco di istanze su CORE o TASK nodi che utilizzano Spot, a seconda del tipo di richiesta. Amazon EMR non è scalabile in base al 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 delle 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 nodo principale massimo.

  • Sia il On-Demand limite che il nodo principale 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 le etichette dei nodi e si limita l'esecuzione dei processi applicativi solo su ON_DEMAND nodi o CORE nodi.

Gli esempi seguenti mostrano 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à sul nodo dell'attività e il limite massimo 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 le richieste degli esecutori.

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

Per scalare CORE i nodi in base alla richiesta dei processi applicativi e TASK i nodi in base alla richiesta dell'esecutore, è 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 specifichi il ON_DEMAND limite e i parametri massimi del CORE nodo, entrambi i parametri hanno come impostazione predefinita il limite massimo.

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

Gli esempi seguenti dimostrano lo scenario di scalabilità delle istanze CORE in base alla richiesta del processo applicativo 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. Scala i TASK nodi in base alla domanda degli esecutori 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 delle attività su richiesta non supererà il valore maximumOnDemandCapacity di 10. I nodi principali 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 richiesta del processo applicativo e SPOT le istanze per la domanda degli esecutori.

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

Per scalare ON_DEMAND i nodi in base alla richiesta dei processi applicativi e SPOT i nodi in base alla richiesta dell'esecutore, è 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 specifichi il ON_DEMAND limite e i parametri massimi del CORE nodo, entrambi i parametri hanno come impostazione predefinita il limite massimo.

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

Gli esempi seguenti mostrano 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

Scala 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. Scala i SPOT nodi in base alla domanda degli esecutori 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 e dei nodi core spot richiesti non supererà il valore maximumCoreCapacity di 10. I nodi spot o on-demand 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