YARN non prelude risorse basate su azioni corrette durante l'esecuzione di un lavoro Spark

Question

Ho un problema con il riequilibrio delle risorse dei processi Apache Spark sulle code YARN Fair Scheduled.

Per i test ho configurato Hadoop 2.6 (provato anche 2.7) per l'esecuzione in modalità pseudo-distribuita con HDFS locale su MacOS. Per la presentazione del lavoro è stata utilizzata la distribuzione "Pre-build Spark 1.4 per Hadoop 2.6 e successive" (anche la versione 1.5) da Spark's website.

Quando testato con la configurazione di base sui lavori Hadoop MapReduce, Fair Scheduler funziona come previsto: quando le risorse del cluster superano il massimo, vengono calcolate equamente le condivisioni e le risorse per i lavori in code diverse vengono preventivate e bilanciate in base a questi calcoli.

Lo stesso test viene eseguito con i lavori Spark, in questo caso YARN sta eseguendo calcoli corretti delle azioni corrette per ogni lavoro, ma le risorse per i contenitori Spark non vengono riequilibrate.

Qui sono i miei file conf:

$ HADOOP_HOME/etc/Hadoop/filato-site.xml

<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?> 
<configuration> 
    <property> 
     <name>yarn.nodemanager.aux-services</name> 
     <value>mapreduce_shuffle</value> 
    </property> 
    <property> 
     <name>yarn.nodemanager.aux-services.spark_shuffle.class</name> 
     <value>org.apache.spark.network.yarn.YarnShuffleService</value> 
    </property> 
    <property> 
     <name>yarn.resourcemanager.scheduler.class</name> 
     <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value> 
    </property> 
    <property> 
     <name>yarn.scheduler.fair.preemption</name> 
     <value>true</value> 
    </property> 
</configuration> 

$ HADOOP_HOME/etc/Hadoop/fiera-scheduler.xml

<?xml version="1.0" encoding="UTF-8"?> 
<allocations> 
    <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy> 
    <queue name="prod"> 
     <weight>40</weight> 
     <schedulingPolicy>fifo</schedulingPolicy> 
    </queue> 
    <queue name="dev"> 
     <weight>60</weight> 
     <queue name="eng" /> 
     <queue name="science" /> 
    </queue> 
    <queuePlacementPolicy> 
     <rule name="specified" create="false" /> 
     <rule name="primaryGroup" create="false" /> 
     <rule name="default" queue="dev.eng" /> 
    </queuePlacementPolicy> 
</allocations> 

$ HADOOP_HOME/etc/Hadoop/core-site.xml

<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?> 
<configuration> 
    <property> 
     <name>fs.defaultFS</name> 
     <value>hdfs://localhost:9000</value> 
    </property> 
</configuration> 

$ HADOOP_HOME/etc/Hadoop/core-site.xml

<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?> 
<configuration> 
    <property> 
     <name>dfs.replication</name> 
     <value>1</value> 
    </property> 
</configuration> 

E il banco di prova è:

eseguire un lavoro sulla coda di "pungolo" con un peso di 40 (deve destinare il 40% di tutti i risorse), come previsto, il lavoro prende tutte le risorse libere necessarie (il 62,5% delle risorse dei cluster).

./bin/spark-submit --class org.apache.spark.examples.SparkPi \ 
--master yarn-cluster \ 
--driver-memory 512M \ 
--executor-memory 768M \ 
--executor-cores 1 \ 
--num-executors 2 \ 
--queue prod \ 
lib/spark-examples*.jar 100000 

Dopo che eseguire lo stesso lavoro nella coda "dev.eng" con il peso 60, che significa che il lavoro deve destinare il 60% di tutte le risorse e diminuire le risorse del primo lavoro al ~ 40%.

./bin/spark-submit --class org.apache.spark.examples.SparkPi \ 
--master yarn-cluster \ 
--driver-memory 512M \ 
--executor-memory 768M \ 
--executor-cores 1 \ 
--num-executors 2 \ 
--queue dev.eng \ 
lib/spark-examples*.jar 100000 

Sfortunatamente, le risorse dei cluster non cambiano: il 62,5% per il primo lavoro e il 37,5% per il secondo.

Answer 1

Fair Scheduler non uccide i contenitori per il primo lavoro, Attende solo fino a quando alcune risorse sono libere e le riserva di essere utilizzate dal secondo lavoro. Se le risorse non sono libere dal primo lavoro, lo schedulatore non può assegnare tali risorse al secondo lavoro.

In MapReduce i lavori, ogni mappa o attività di riduzione richiede l'istanziazione di un nuovo contenitore e lo scheduler può bloccare il lavoro per creare un'istanza di nuovi contenitori se ha superato il suo preventivo (in base alla capacità della coda).

In Spark le cose sono diverse, gli esecutori vengono iniziati all'inizio del lavoro e le diverse attività (fasi) vengono inviate a loro. Quindi le risorse non vengono liberate e non possono essere ridistribuite.

Può essere l'allocazione dinamica potrebbe aiutare: http://spark.apache.org/docs/1.6.1/configuration.html#dynamic-allocation

Answer 2

È necessario impostare uno dei timeout prelazione nel xml di allocazione. Uno per la quota minima e uno per la quota equa, entrambi sono in secondi. Per impostazione predefinita, i timeout non sono impostati.

Da Hadoop: The Definitive Guide 4^Edizione

Se una coda attende il più a lungo il suo minimo timeout quota di prelazione senza ricevere il minimo quota garantita, allora lo scheduler può prevenire altri contenitori. Il timeout predefinito è impostato per tutte le code tramite l'elemento di primo livello defaultMinSharePreemptionTimeout nel file di allocazione e in base alla coda impostando l'elemento minSharePreemptionTimeout per una coda.

Allo stesso modo, se una coda rimane inferiore alla metà della sua quota equa per tutto il tempo come timeout di proroga delle azioni, allora lo schedulatore può escludere altri contenitori. Il timeout predefinito è impostato per tutte le code tramite l'elemento di primo livello predefinito defaultFairSharePreemptionTimeout nel file di allocazione e in base alla coda impostando fairSharePreemptionTimeout su una coda. La soglia può anche essere modificata dal suo valore predefinito di 0,5 impostando defaultFairSharePreemptionThreshold e fairSharePreemptionThreshold (per-coda).