2015-12-11 17 views
5

Pracuję nad projektem w Spark, a ostatnio zmieniono z użycia Spark Standalone na Mesos do zarządzania klastrami. Teraz jestem zdezorientowany, jak przydzielać zasoby podczas składania pracy w nowym systemie.Zrozumienie alokacji zasobów dla zadań iskier na mesach

W trybie autonomicznym, używałem czegoś takiego (po kilka zaleceń z this Cloudera blog post.

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

Jest w klastrze gdzie każda maszyna ma 16 rdzeni i ~ 32 GB pamięci RAM

Co było fajne, że mam dobrą kontrolę nad liczbą uruchomionych executorów i przydzielonymi dla nich zasobami.W powyższym przykładzie wiedziałem, że otrzymuję 240/8 = 30 executorów, każdy z 16 GB pamięci i 8 rdzeniami. pamięć na każdym komputerze w klastrze, to nie więcej niż dwa executory działające na każdej maszynie chciał więcej wykonawców, mógłby zrobić coś podobnego

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

To teraz dać mi 240/5 = 47 wykonawców, każdy z 5 rdzeni i 10GB pamięci i pozwoli maksymalnie 3 wykonawców na maszynie.

Ale teraz, gdy jestem na mesos, jestem trochę zdezorientowany. Po pierwsze, używam trybu gruboziarnistego, aby upewnić się, że mogę naprawić i kontrolować mój przydział zasobów (jest to w przypadku dość złożonego modelu, w którym chcemy wstępnie przydzielić zasoby).

Teraz mogę określić --total-executor-cores i --executor-memory, ale dokumentacja mówi mi, że --exeuctor-cores dotyczy Spark autonomiczny i przędzy tylko, co sprawia, określający całkowitą liczbę wykonawców i środków przydzielonych każdemu trudne. Załóżmy, że to uruchomiłem:

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

Kiedy sprawdzam tę pracę w interfejsie internetowym Mesos, sytuacja zaczyna się myląc. Oto moje pytania:

  1. Terminologia. W interfejsie internetowym wyświetlane są "frameworki", które, jak przypuszczam, odpowiadają "zadaniom" w samodzielnym interfejsie użytkownika. Ale kiedy klikam na szczegół dla danej struktury, wyszczególnia "zadania". Ale to nie mogą być rzeczywiste zadania Sparka, prawda? O ile mogę powiedzieć, "zadanie" tutaj musi faktycznie oznaczać "wykonawcę" w odniesieniu do Sparka. Byłoby to zgodne z interfejsem użytkownika, który mówi, że moja struktura (zadanie) ma: 15 aktywnych zadań, 240 procesorów i 264 GB pamięci.

    264/15 = 17,6, co wydaje się być zgodne z pamięcią 16 GB na każdym określonym executorze (plus trochę narzut, jak sądzę). Czy mam rację, tłumacząc to wszystko?

  2. Zakładając, że tak, kiedy badam którekolwiek z tych "zadań" (executorów), widzę, że każdy ma 16 rdzeni przypisanych. Biorąc pod uwagę, że mamy 16 rdzeni na maszynę, wydaje się to wskazywać, że zasadniczo uruchamiam jeden executor na każdej z 16 maszyn i że każdy executor otrzymuje pełne 16 rdzeni, ale tylko 16 GB pamięci RAM. (zwróć uwagę, że nawet jeśli upuszczę --executor-memory w dół, do czegoś podobnego do 4GB, mesy po prostu uruchomią jeden executor na węzeł, z 16 rdzeniami i 4 GB pamięci RAM). Ale to, co chcę osiągnąć, to coś w rodzaju moich pierwszych dwóch przykładów. To znaczy, chcę uruchomić wiele executorów na węzeł, z których każdy dzieli pamięć RAM i rdzenie tego węzła (tj. Umiarkowana liczba rdzeni pre executora, 5-8). Biorąc pod uwagę, że nie mogę podać w Mesos numeru --executor-cores, w jaki sposób mogę to zrobić? A może jestem poza bazą z jakiegoś powodu, nawet chcąc to osiągnąć? Czy Mesos po prostu nie pozwolą na wielokrotne wydalanie na węzeł?

Odpowiedz

4

Pytanie 1: W trybie gruboziarnistego, wykonawca Sparka (org.apache.spark.executor.CoarseGrainedExecutorBackend) jest uruchamiany jako zadanie Mesos. Mesos Framework faktycznie jest Spark Driver. Jeden Spark Driver może przesłać wiele zadań Spark. To zależy od twojej aplikacji Spark. Spark and Mesos zarówno pochodzą z AMPLab z UC Berkeley i są rozwijane równolegle, więc używają podobnych terminologii (executor, zadanie ...), które mogą wprowadzać w błąd :-).

Pytanie 2: W trybie gruboziarnistym Spark uruchamia tylko jeden executor na hosta (szczegółowe informacje można znaleźć w sekcji https://issues.apache.org/jira/browse/SPARK-5095). Tak więc, dla ciebie, Spark uruchomi jeden executor na hosta (każdy executor zużyje pamięć 16G i wszystkie dostępne rdzenie na hoście, które są 16 rdzeniami, jeśli nie ma innego obciążenia), dopóki wszystkie rdzenie executorów nie osiągną 240 rdzeni. Będzie 240/16 = 15 wykonawców.

Odnośnie iskry.mesos.mesosExecutor.cores działa tylko w trybie drobnoziarnistym. W trybie drobnoziarnistym Spark uruchomi jeden executor (org.apache.spark.executor.MesosExecutorBackend) na hosta. Executor zużywa liczbę rdzeni spark.mesos.mesosExecutor.cores, mimo że nie ma zadania. Każde zadanie pochłonie kolejną liczbę rdzeni spark.task.cpus.

+1

[Spark Doc] (https://spark.apache.org/docs/2.1.0/running-on-mesos.html#mesos-run-modes) "Spark może przejechać przez Mesy w dwóch trybach:" gruboziarnisty "(domyślnie) i * * "Drobnoziarnisty" (przestarzały) **. " Począwszy od wersji Spark 2.0.0 – Vezir

0

Odnośnie 1)

To jest mój zrozumienie, jak również. Zadanie Mesos to tak naprawdę Spark Executor (zadanie).

Odnośnie 2)

Z mojego zrozumienia, powinieneś być w stanie korzystać z własności spark.mesos.mesosExecutor.cores konfiguracji:

(tylko tryb drobnoziarnista) Ilość rdzeni aby każdy wykonawca Mesos. Nie obejmuje to rdzeni używanych do uruchamiania zadań Sparka. Innymi słowy, nawet jeśli żadne zadanie Sparka nie zostanie uruchomione, każdy executor Mesos zajmie liczbę rdzeni tutaj skonfigurowanych. Wartość może być liczbą zmiennoprzecinkową.

Zobacz

+0

Hmm ... może myliłem się myśląc, że powinienem użyć trybu gruboziarnistego? Jeśli rozumiem poprawnie, pozwoliłoby to nam na ustalenie liczby rdzeni/executorów, ale nadal będziemy mieli do czynienia z automatycznym skalowaniem zasobów, których tutaj nie chcę ... – moustachio