Czym są pracownicy, wykonawcy, rdzenie w samodzielnym klastrze Spark?

Question

Czym są pracownicy, wykonawcy, rdzenie w samodzielnym klastrze Spark?

Przeczytałem Przegląd trybu klastra i nadal nie mogę zrozumieć różnych procesów w klastrze Spark Standalone i równoległości.

Czy worker jest procesem JVM czy nie? Sprawdziłam bin\start-slave.sh i odkryłam, że zrodził pracownika, który jest w rzeczywistości JVM.

Zgodnie z powyższym linkiem, executor jest procesem uruchomionym dla aplikacji na węźle roboczym, który uruchamia zadania. Executor jest również JVM.

To są moje pytania:

Executors są na aplikację. Jaka jest zatem rola pracownika? Czy koordynuje z wykonawcą i przekazuje wynik z powrotem sterownikowi? a może sterownik rozmawia bezpośrednio z wykonawcą? Jeśli tak, to jaki jest cel pracownika?
Jak kontrolować liczbę wykonawców aplikacji? 3.Czy zadania mogą być uruchamiane równolegle wewnątrz executora? Jeśli tak, to jak skonfigurować liczbę wątków dla wykonawca?
Jaka jest relacja między rdzeniami worker, executors i executor (--total-executor-cores)?
Co to znaczy mieć więcej pracowników na węzeł?

Aktualizacja

Przyjmijmy przykłady, aby lepiej zrozumieć.

Przykład 1: Samodzielny klaster z 5 węzłami roboczymi (każdy węzeł ma 8 Rdzeni) Kiedy uruchamiam aplikację z ustawieniami domyślnymi.

Przykład 2 Ta sama konfiguracja klastra co przykład 1, ale uruchamiam aplikację z następującymi ustawieniami -- executor-rdzenie 10 -- total-executor-rdzenie 10.

Przykład 3 Ta sama konfiguracja klastra jak w przykładzie 1, ale uruchamiam aplikację z następującymi ustawieniami -- executor-rdzenie 10 -- total-executor-rdzenie 50.

Przykład 4 Ta sama konfiguracja klastra jak w przykładzie 1, ale uruchamiam aplikację z następującymi ustawieniami -- executor-rdzenie 50 -- total-executor-rdzenie 50.

Przykład 5 Ta sama konfiguracja klastra co przykład 1, ale uruchamiam aplikację z następującymi ustawieniami -- executor-rdzenie 50 -- total-executor-rdzenie 10.

W każdym z tych przykładów, Ilu wykonawców? Ile wątków na wykonawcę? Ile rdzeni? W jaki sposób ustala się liczbę wykonawców na aplikację. Czy zawsze jest taka sama jak liczba pracowników?

146

distributed-computing apache-spark

Author: vaichidrewar, 2015-09-17

Source

1 answers

score 179 · Accepted Answer

Spark używa architektury master / slave. Jak widać na rysunku, ma jeden centralny koordynator (sterownik), który komunikuje się z wieloma rozproszonymi pracownikami (wykonawcami). Sterownik i każdy z executorów działają w swoich własnych procesach Java.

Kierowca

Driver jest procesem, w którym uruchomiona jest główna metoda. Najpierw konwertuje program użytkownika na zadania, a następnie rozkłada zadania na executors.

EXECUTORS

Executorzy są procesami węzłów roboczych odpowiedzialnymi za wykonywanie poszczególnych zadań w danym zadaniu Spark. Są one uruchamiane na początku aplikacji Spark i zazwyczaj są uruchamiane przez cały okres użytkowania aplikacji. Po uruchomieniu zadania wysyłają wyniki do kierowcy. Zapewniają również pamięć podręczną dla RDD, które są buforowane przez programy użytkownika za pośrednictwem Menedżera bloków.

WYKONANIE APLIKACJI FLOW

Mając to na uwadze, kiedy składasz wniosek do klastra za pomocą spark-submit, dzieje się to wewnętrznie:

samodzielna aplikacja uruchamia i tworzy instancje instancji SparkContext (i jest to tylko wtedy, gdy można nazwać aplikację sterownikiem).
Program sterownika prosi o zasoby do Menedżera klastra, aby uruchomić executory.
Menedżer klastra uruchamia executorów.
proces sterownika przebiega przez użytkownika podanie. W zależności od działań i transformacji zadania RDDs są wysyłane do wykonawców.
Executors uruchamiają zadania i zapisują wyniki.
jeśli jakiś pracownik ulegnie awarii, jego zadania zostaną wysłane do różnych wykonawców, aby być ponownie przetwarzane. W książce "Learning Spark: lightning-Fast Big Data Analysis" mówią o tolerancji iskier i błędów:

Spark automatycznie zajmuje się uszkodzonymi lub wolnymi maszynami, wykonując ponownie nieudane lub powolne zadania. Na przykład, jeśli węzeł uruchamiający partycję operacji map() ulegnie awarii, Spark uruchomi ją ponownie na innym węźle; i nawet jeśli węzeł nie ulegnie awarii, ale jest po prostu znacznie wolniejszy niż inne węzły, Spark może wstępnie uruchomić "spekulatywną" kopię zadania na innym węźle i pobrać jej wynik, jeśli to się skończy.

Z SparkContext.stop() ze sterownika lub jeśli główna metoda zakończy / zawiesi wszystkie executory zostaną zakończone, a zasoby klastra zostaną zwolnione przez klaster manager.

TWOJE PYTANIA

Po uruchomieniu executors rejestrują się ze sterownikiem i od tego momentu komunikują się bezpośrednio. Pracownicy są odpowiedzialni za informowanie Menedżera klastra o dostępności swoich zasobów.
W klastrze przędzy możesz to zrobić za pomocą --num-executors. W samodzielnym klastrze otrzymasz jednego wykonawcę na pracownika, chyba że grasz spark.executor.rdzeni i pracownik ma wystarczającą ilość rdzeni posiadać więcej niż jeden wykonawca. (Jak zauważył @ JacekLaskowski, --num-executors nie jest już używany w YARN https://github.com/apache/spark/commit/16b6d18613e150c7038c613992d80a7828413e66)
Możesz przypisać liczbę rdzeni dla każdego executora za pomocą --executor-cores
--total-executor-cores to maksymalna liczba rdzeni executora na aplikację
Jak powiedział Sean Owen w tym wątku : "nie ma dobrego powodu, aby biegać więcej niż jeden pracownik na maszynę". Na przykład wiele JVM siedzi w jednej maszynie.

UPDATE

Nie byłem w stanie przetestować tego scenariusza, ale zgodnie z dokumentacją:

Przykład 1: Spark będzie chciwie nabywać tyle rdzeni i wykonawców, ile oferuje scheduler. Tak więc w końcu otrzymasz 5 executorów z 8 rdzeniami każdy.

Przykład 2 do 5: Spark nie będzie w stanie przydzielić tylu rdzeni, ile jest wymagane w jednego pracownika, stąd żaden wykonawca nie zostanie uruchomiony.