Spark na menedżerze zasobów YARN: Relacja między kontenerami YARN i sterownikami Spark

Question

Jestem nowy w Spark on YARN i nie rozumiem relacji między YARN Containers a Spark Executors. Wypróbowałem następującą konfigurację, w oparciu o wyniki skryptu yarn-utils.py, które można wykorzystać do znalezienia optymalnej konfiguracji klastra.

Klaster Hadoop (HDP 2.4) pracuję w:

• 1 Główna węzła:
  • procesor 2 procesory z 6 rdzeni co = 12 rdzenie
  • RAM: 64 PL
  • SSD 2 x 512 PL
• 5 węzłów podrzędnych:
  • procesor 2 procesory z 6 rdzeni co = 12 rdzenie
  • RAM: 64 PL
  • HDD 4 x 3 TB = 12 TB
• zainstalowany HBase (jest to jeden z parametrów na poniższym skrypcie)

Więc wpadłem python yarn-utils.py -c 12 -m 64 -d 4 -k True rdzenie (c = m = D = pamięć HDD, k = HBase zainstalowane) i uzyskałem następujący wynik:

Using cores=12 memory=64GB disks=4 hbase=True 
Profile: cores=12 memory=49152MB reserved=16GB usableMem=48GB disks=4 
Num Container=8 
Container Ram=6144MB 
Used Ram=48GB 
Unused Ram=16GB 
yarn.scheduler.minimum-allocation-mb=6144 
yarn.scheduler.maximum-allocation-mb=49152 
yarn.nodemanager.resource.memory-mb=49152 
mapreduce.map.memory.mb=6144 
mapreduce.map.java.opts=-Xmx4915m 
mapreduce.reduce.memory.mb=6144 
mapreduce.reduce.java.opts=-Xmx4915m 
yarn.app.mapreduce.am.resource.mb=6144 
yarn.app.mapreduce.am.command-opts=-Xmx4915m 
mapreduce.task.io.sort.mb=2457 

Ustawienia dokonane przez interfejs Ambari i zrestartowałem klaster. Wartości są również zbliżone do tego, co wcześniej obliczałem ręcznie.

mam teraz problemy

• , aby znaleźć optymalne ustawienia dla mojego spark-submit skryptu
  • parametry --num-executors, --executor-cores & --executor-memory.
• uzyskać zależność pomiędzy pojemnikiem przędzy i wykonawców Spark
• do zrozumienia informacji o sprzęcie w moim Spark Historia UI (mniej pamięci pokazane jak ustawić (w przeliczeniu na ogólną pamięci przez pomnożenie z pracownika wysokości węzła))
• zrozumieć koncepcję vcores w przędza, tutaj nie mogę znaleźć żadnych użytecznych przykładów jeszcze

jednak znalazłem ten post What is a container in YARN?, ale to naprawdę nie pomaga, jak to robi” t opisać relację do executora s.

Czy ktoś może pomóc w rozwiązaniu jednego lub więcej pytań?

Answer 1

będę zgłosić swoje spostrzeżenia tutaj krok po kroku:

• Pierwszą ważną rzeczą jest fakt (Źródło: this Cloudera documentation):

  Uruchamiając zapłonowej przędza, każdy wykonawca Spark działa jako pojemnik YARN. [...]

• Oznacza to, że liczba kontenerów będzie zawsze taka sama jak executorów utworzonych przez aplikację Spark, np. za pomocą parametru --num-executors w wysyłaniu iskier.

• Ustawiany przez yarn.scheduler.minimum-allocation-mb każdy kontener zawsze przydziela co najmniej taką ilość pamięci. Oznacza to, że jeśli parametr --executor-memory jest ustawiony na np. tylko 1g, ale yarn.scheduler.minimum-allocation-mb to np. 6g, pojemnik jest znacznie większy niż potrzeba w aplikacji Spark.

• Odwrotnie, jeśli parametr --executor-memory jest ustawiony na wartość wyższą niż wartość yarn.scheduler.minimum-allocation-mb, np. 12g, Kontener będzie dynamicznie przydzielał więcej pamięci, ale jeśli żądana ilość pamięci jest mniejsza lub równa yarn.scheduler.maximum-allocation-mb wartość.

• Wartość yarn.nodemanager.resource.memory-mb określa, ile pamięci można przypisać w sumie przez wszystkie pojemniki jednego hosta!

=> Więc ustawienie yarn.scheduler.minimum-allocation-mb pozwala na uruchamianie mniejszych pojemników np dla mniejszych executorów (inaczej byłoby to marnowanie pamięci).

=> Ustawianie yarn.scheduler.maximum-allocation-mb do wartości maksymalnej (np równej yarn.nodemanager.resource.memory-mb) pozwala na zdefiniowanie większych wykonawców (więcej pamięci jest przydzielana w razie potrzeby, na przykład przez --executor-memory parametru).