Spark Yarn Architecture

Question

miałem pytanie odnośnie tego zdjęcia tutorial miałem następujący. Tak więc na podstawie tego obrazu w architekturze opartej na przędzy wykonanie aplikacji iskrownika wygląda mniej więcej tak:

Najpierw masz sterownik, który działa w węźle klienta lub w pewnym węźle danych. W tym sterowniku (podobnym do sterownika w java?) Składa się twój kod (napisany w java, python, scala itp.), Który przesyłasz do Spark Context. Wtedy ten kontekst iskry reprezentuje połączenie z HDFS i przesyła twoją prośbę do menedżera zasobów w ekosystemie Hadoop. Następnie menedżer zasobów komunikuje się z węzłem Nazwa, aby dowiedzieć się, które węzły danych w klastrze zawierają informacje, których żądał węzeł klienta. Kontekst iskry spowoduje również umieszczenie executora w węźle roboczym, który będzie wykonywał zadania. Następnie menedżer węzłów uruchomi executor, który będzie wykonywał zadania nadane mu przez kontekst Spark i zwróci dane, których zażądał klient od HDFS do sterownika.

Czy powyższa interpretacja jest poprawna?

Również sterownik wyśle ​​trzy executory do każdego węzła danych w celu pobrania danych z HDFS, ponieważ dane w HDFS są trzykrotnie replikowane na różnych węzłach danych?

Answer 1

Twoja interpretacja jest zbliżona do rzeczywistości, ale wydaje się, że w niektórych kwestiach jesteś nieco zdezorientowany.

Zobaczmy, czy mogę ci to wyjaśnić.

Załóżmy, że masz przykład liczenia słów w Scali.

object WordCount { 
    def main(args: Array[String]) { 
     val inputFile = args(0) 
     val outputFile = args(1) 
     val conf = new SparkConf().setAppName("wordCount") 

     val sc = new SparkContext(conf) 

     val input = sc.textFile(inputFile) 

     val words = input.flatMap(line => line.split(" ")) 

     val counts = words.map(word => (word, 1)).reduceByKey{case (x, y) => x + y} 

     counts.saveAsTextFile(outputFile) 
    } 
} 

W każdej pracy zapłonowej masz etap inicjalizacji gdzie utworzyć obiekt SparkContext zapewniając pewną konfigurację lubią appname i kapitana, potem czytasz plik_wejściowy, przetwarzać je i zapisać wynik swojej przetwarzania na dysk. Cały ten kod działa w sterowniku, z wyjątkiem anonimowych funkcji, które powodują faktyczne przetwarzanie (funkcje przekazywane do .flatMap, .map i reduceByKey) oraz funkcje I/O textFile i saveAsTextFile, które są zdalnie uruchamiane w klastrze.

Tutaj nazwa KIEROWCA to nazwa nadawana tej części programu, która działa lokalnie w tym samym węźle, w którym przesyła się kod z numerem spark-submit (na zdjęciu nazywa się węzeł klienta). Możesz przesłać swój kod z dowolnego komputera (albo węzła ClientNode, WorderNode, a nawet MasterNode), pod warunkiem, że masz przydział iskiernika i dostęp do sieci do klastra YARN. Dla uproszczenia założę się, że węzeł klienta to twój laptop, a klaster przędzy składa się ze zdalnych maszyn.

Dla uproszczenia pominiemy ten obraz Zookeeper, ponieważ jest używany do zapewniania wysokiej dostępności dla HDFS i nie jest zaangażowany w uruchamianie aplikacji iskrzenia. Muszę nadmienić, że Yarn Resource Manager i HDFS Namenode są rolami w Yarn i HDFS (w rzeczywistości są to procesy działające wewnątrz JVM) i mogą żyć w tym samym węźle głównym lub na oddzielnych maszynach. Nawet menedżerowie węzłów przędzy i węzły danych są tylko rolami, ale zazwyczaj żyją na tym samym komputerze w celu zapewnienia lokalizacji danych (przetwarzanie w pobliżu miejsca przechowywania danych).

Po przesłaniu zgłoszenia należy najpierw skontaktować się z Menedżerem zasobów, który wraz z Numerem Nazwy próbuje znaleźć węzły Pracowników, w których można uruchamiać zadania związane z iskrami. Aby skorzystać z zasady lokalizacji danych, Menedżer zasobów będzie preferował węzły robocze, które przechowuje na tych samych blokach HDFS maszyny (dowolne z 3 replik dla każdego bloku) dla pliku, który należy przetworzyć. Jeśli żaden węzeł roboczy z tymi blokami nie jest dostępny, użyje dowolnego innego węzła roboczego.W tym przypadku, ponieważ dane nie będą dostępne lokalnie, bloki HDFS muszą być przenoszone przez sieć z dowolnego węzła danych do menedżera węzła wykonującego zadanie iskry. Ten proces jest wykonywany dla każdego bloku, który utworzył twój plik, więc niektóre bloki można znaleźć lokalnie, niektóre muszą zostać przeniesione.

Gdy menedżer zasobów odnajdzie dostępny węzeł roboczy, skontaktuje się z menedżerem węzłów NodeManager w tym węźle i poprosi go o utworzenie kontenera przędzy (JVM), w którym należy uruchomić wykonawcę iskier. W innych trybach klastra (Mesos lub Standalone) nie będziesz miał pojemnika przędzy, ale koncepcja iskra executora jest taka sama. Wykonawca iskry działa jako maszyna JVM i może wykonywać wiele zadań.

Sterownik działający w węźle klienta i zadania uruchomione na executorach iskrowych komunikują się w celu uruchomienia zadania. Jeśli sterownik działa na twoim laptopie i awarii twojego laptopa, stracisz połączenie z zadaniami, a twoja praca się nie powiedzie. Dlatego kiedy iskra działa w klastrze Przędza, możesz określić, czy chcesz uruchomić swój sterownik na laptopie "--deploy-mode = client", czy też w klastrze przędzy jako inny pojemnik przędzy "--deploy-mode = cluster ". Aby uzyskać więcej informacji, spójrz na: spark-submit