Jaki typ klastra wybrać dla Spark?

Spark Standalone Manager : prosty menedżer klastrów dołączony do Spark, który ułatwia konfigurację klastra. Domyślnie każda aplikacja wykorzystuje wszystkie dostępne węzły w klastrze.

kilka korzyści przędzy nad samodzielnym i Mezos:

1. YARN pozwala na dynamiczne współdzielenie i centralną konfigurację tej samej puli zasobów klastra pomiędzy wszystkimi frameworkami działającymi na YARN.

2. Ty może korzystać ze wszystkich funkcji harmonogramów YARN do kategoryzowania, izolowania i priorytetyzowania obciążeń.

3. Spark standalone mode wymaga, aby każda aplikacja uruchamiała executora na każdym węźle w klastrze; podczas gdy w YARN, wybierasz liczbę executorów do użycia

4. Przędza bezpośrednio obsługuje stojak i lokalizację maszyny W twoich żądaniach, co jest wygodne.

5. Model żądania zasobów jest, co dziwne,, wstecz w Mezos . W , Użytkownik (Framework) żąda kontenerów o danej specyfikacji i podaje preferencje dotyczące lokalizacji. W Mesos dostajesz "oferty" zasobów i wybierasz akceptację lub odrzucenie tych na podstawie własnej polityki planowania. Model Mesos jest prawdopodobnie bardziej elastyczny, ale pozornie więcej pracy dla osoby wdrażającej framework.

6. Jeśli masz już duży Klaster Hadoop, YARN jest lepszym wyborem.

7. Na Standalone manager wymaga od użytkownika skonfigurowania każdego z węzłów z udostępnionym sekretem. Mesos ' domyślny moduł uwierzytelniania, Cyrus SASL, może być zastąpiony modułem niestandardowym. YARN posiada zabezpieczenia uwierzytelniania, autoryzacji poziomu usług, uwierzytelniania konsol internetowych i poufności danych. Uwierzytelnianie Hadoop wykorzystuje Kerberos do sprawdzenia, czy każdy użytkownik i usługa są uwierzytelniane przez Kerberos.

8. Wysoka dostępność jest oferowana przez wszystkie trzy menedżerów klastrów, ale Hadoop YARN nie musi uruchamiać oddzielnego kontrolera przełączania awaryjnego ZooKeeper.

Przydatne linki:

Spark strona dokumentacji

Agildata Artykuł

Standalone jest dość jasne, jak inne wymienione powinien być używany tylko wtedy, gdy masz tylko Spark obciążenia.

Pomiędzy yarn i Mezos, jedną rzeczą do rozważenia jest fakt, że w przeciwieństwie do mapreduce, spark job chwyta executorów i trzyma go przez całe życie pracy. gdzie w mapreduce praca może uzyskać i zwolnić mapery i reduktory w ciągu życia.

Jeśli masz długo działające zadania spark, które w trakcie życia zadania nie w pełni wykorzystują wszystkie zasoby, które zostały na początku, możesz udostępnić te zasoby innym aplikacjom i możesz to zrobić tylko za pośrednictwem Mesos lub Spark dynamic scheduling. https://spark.apache.org/docs/2.0.2/job-scheduling.html#scheduling-across-applications Tak więc w przypadku yarn jedynym sposobem na dynamiczną alokację spark jest użycie dynamicznej alokacji Spark. Włóczka nie będzie w to ingerować, podczas gdy Mezos będzie. Ponownie ten cały punkt jest ważny tylko wtedy, gdy masz długo działającą aplikację spark i chcesz ją skalować w górę iw dół dynamicznie.

Mesos ma bardziej wyrafinowany projekt planowania, pozwalający aplikacjom takim jak Spark negocjować z nim. Jest bardziej odpowiedni dla różnorodności zastosowań dzisiaj. Znalazłem tę stronę naprawdę wnikliwą:

Https://www.oreilly.com/ideas/a-tale-of-two-clusters-mesos-and-yarn

"... YARN jest zoptymalizowany do planowania zadań Hadoop, które są historycznie (i nadal zazwyczaj) zadaniami wsadowymi z długimi czasami pracy. Oznacza to, że przędza nie została zaprojektowana do długotrwałego użytkowania Usługi, ani krótkotrwałe zapytania interaktywne (takie jak małe i Szybkie zadania Spark) i chociaż możliwe jest zaplanowanie innych rodzajów obciążeń, nie jest to idealny model. Wymagania dotyczące zasobów, modelu wykonania i wymagań architektonicznych MapReduce bardzo różnią się od wymagań długotrwałych usług, takich jak serwery WWW lub aplikacje SOA, lub obciążeń w czasie rzeczywistym, takich jak Spark lub Storm..."