2015-12-11 15 views
5

Sto lavorando a un progetto in Spark e di recente sono passato dall'utilizzo di Spark Standalone a Mesos per la gestione dei cluster. Ora mi trovo confuso su come allocare risorse quando si invia un lavoro sotto il nuovo sistema.Informazioni sull'allocazione delle risorse per i lavori spark su mesos

In modalità stand-alone, stavo usando qualcosa di simile (in seguito alcune raccomandazioni da this Cloudera blog post:.

/opt/spark/bin/spark-submit --executor-memory 16G --executor-cores 8 
    --total-executor-cores 240 myscript.py 

Questo è su un cluster in cui ogni macchina ha 16 core e ~ 32 GB di RAM

Cosa è stato bello avere il controllo sul numero di esecutori in esecuzione e le risorse assegnate a ciascuno. Nell'esempio precedente, sapevo di avere 240/8 = 30 esecutori, ciascuno con 16 GB di memoria e 8 core. la memoria su ogni macchina nel cluster, ciò equivarrebbe a non più di due esecutori in esecuzione su ciascuna macchina voluto più esecutori, avrei potuto fare qualcosa di simile

/opt/spark/bin/spark-submit --executor-memory 10G --executor-cores 5 
    --total-executor-cores 240 myscript.py 

Questo sarebbe ora mi danno 240/5 = 47 esecutori, ognuna con 5 core e la memoria da 10 GB, e permetterebbe fino a 3 esecutori per macchina.

Ma ora che sono su un mesos, sono un po 'confuso. Prima di tutto, sono in esecuzione in modalità a grana grossa per assicurarmi di poter correggere e controllare la mia allocazione delle risorse (questo è al servizio di un modello abbastanza complesso in cui vogliamo pre-allocare le risorse).

Ora, posso specificare --total-executor-cores e --executor-memory, ma la documentazione mi dice che --exeuctor-cores vale per Spark stand-alone e FILATO solo, il che rende specificando il numero totale di esecutori e risorse assegnate a ciascun difficile. Di 'corro questo:

/opt/spark/bin/spark-submit --total-executor-cores 240 --executor-memory 16G --conf spark.mesos.coarse=true myscript.py 

Quando esamino questo lavoro nell'interfaccia utente web di Mesos, le cose iniziano sempre confusione. Così, qui sono le mie domande:

  1. terminologia. L'interfaccia utente Web elenca "framework", che presumo corrispondono a "lavori" nell'interfaccia utente autonoma. Ma quando clicco sul dettaglio per un dato framework, elenca "tasks". Ma questi non possono essere veri compiti Spark, giusto? Per quanto posso dire, "compito" qui deve in realtà significare "esecutore" per quanto riguarda Spark. Ciò sarebbe coerente con l'interfaccia utente dicendo che il mio framework (lavoro) ha: 15 attività attive, 240 CPU e 264 GB di memoria.

    264/15 = 17,6, che sembra coerente con la memoria da 16 GB per esecutore che ho specificato (più un sovraccarico, immagino). Ho ragione su come sto interpretando tutto questo?

  2. Assumendo sì, quando esamino qualcuno di questi "compiti" (esecutori), vedo che ognuno di essi ha 16 core assegnati. Dato che abbiamo 16 core per macchina, ciò sembrerebbe indicare che sto fondamentalmente eseguendo un executor su ciascuna delle 16 macchine, e che ciascun executor sta ricevendo i 16 core completi, ma solo 16 GB di RAM. (nota che, anche se faccio cadere in basso lo --executor-memory fino a qualcosa come 4 GB, il mesos esegue ancora un solo executor per nodo, con 16 core e 4 GB di RAM). Ma quello che voglio realizzare è qualcosa come i miei primi due esempi. Cioè, voglio eseguire più executor per nodo, ognuno condividendo la RAM e i core di quel nodo (cioè un numero moderato di core pre-executor, 5-8). Considerando che non riesco a specificare --executor-cores in Mesos, come posso realizzare questo? O sono in qualche modo fuori base per qualche motivo nel voler anche realizzare questo? Mesos non permetterà semplicemente più exeuctor per nodo?

risposta

4

Domanda 1: Nella modalità a grana grossa, esecutore di Spark (org.apache.spark.executor.CoarseGrainedExecutorBackend) viene lanciato come compito Mesos. Mesos Framework è in realtà Spark Driver. One Spark Driver può inviare più lavori Spark. Dipende dalla tua applicazione Spark. Spark e Mesos vengono entrambi da AMPLab di UC Berkeley e sono sviluppati in parallelo, quindi usano terminologie simili (esecutore, compito ...) che potrebbero confondervi :-).

Domanda 2: In modalità a grana grossa, Spark avvia solo un executor per host (fare riferimento a https://issues.apache.org/jira/browse/SPARK-5095 per i dettagli). Quindi, per te, Spark lancerà un executor per host (ogni executor consuma memoria 16G e tutti i core disponibili nell'host che è 16 core se non c'è altro carico di lavoro) finché i core totali degli executors raggiungono i 240 core. Ci saranno 240/16 = 15 esecutori.

Riguardo a spark.mesos.mesosExecutor.cores, funziona solo per la modalità a grana fine. In modalità a grana fine, Spark avvierà un executor (org.apache.spark.executor.MesosExecutorBackend) per host. L'esecutore consuma il numero di core di spark.mesos.mesosExecutor.cores anche se non vi è alcuna attività. Ogni attività consumerà un altro numero di core di spark.task.cpus.

+1

[Spark Doc] (https://spark.apache.org/docs/2.1.0/running-on-mesos.html#mesos-run-modes) "Spark può funzionare su Mesos in due modi:" a grana grossa "(predefinito) e * * "A grana fine" (deprecato) **. " A partire da Spark versione 2.0.0 – Vezir

0

Per quanto riguarda 1)

Questa è la mia comprensione pure. Un Task Mesos è in realtà uno Spark Executor (task).

Per quanto riguarda 2)

Dalla mia comprensione, si dovrebbe essere in grado di utilizzare la proprietà di configurazione spark.mesos.mesosExecutor.cores:

(modalità a grana fine solo) Numero di core per dare ad ogni esecutore Mesos. Questo non include i core utilizzati per eseguire le attività Spark. In altre parole, anche se non viene eseguita alcuna attività Spark, ciascun esecutore di Mesos occuperà il numero di core configurato qui. Il valore può essere un numero in virgola mobile.

Vedi

+0

Hmm ... forse ho sbagliato a pensare che dovrei usare la modalità a grana grossa? Se sto capendo correttamente, questo ci permetterebbe di correggere il numero di core/executor, ma poi continueremmo a correre nel ridimensionamento automatico delle risorse che non voglio qui ... – moustachio