Optymalizacja konfiguracji klastra dla platformy Apache Spark
W tym artykule omówiono sposób optymalizacji konfiguracji klastra Apache Spark w celu uzyskania najlepszej wydajności w usłudze Azure HDInsight.
Omówienie
W zależności od obciążenia klastra Spark można określić, że nie domyślna konfiguracja platformy Spark spowoduje bardziej zoptymalizowane wykonywanie zadań platformy Spark. Przetestuj testy porównawcze z przykładowymi obciążeniami, aby zweryfikować wszystkie konfiguracje klastra inne niż domyślne.
Poniżej przedstawiono kilka typowych parametrów, które można dostosować:
| Parametr | Opis |
|---|---|
| --num-executors | Ustawia odpowiednią liczbę funkcji wykonawczych. |
| --executor-cores | Ustawia liczbę rdzeni dla każdego wykonawcy. Zazwyczaj należy mieć funkcje wykonawcze o średnim rozmiarze, ponieważ inne procesy zużywają część dostępnej pamięci. |
| --executor-memory | Ustawia rozmiar pamięci dla każdego modułu wykonawczego, który kontroluje rozmiar sterty w usłudze YARN. Pozostaw część pamięci na potrzeby nakładu pracy. |
Wybierz prawidłowy rozmiar funkcji wykonawczej
Podczas podejmowania decyzji o konfiguracji funkcji wykonawczej należy wziąć pod uwagę obciążenie związane z odzyskiwaniem pamięci w języku Java (GC).
Czynniki zmniejszające rozmiar funkcji wykonawczej:
- Zmniejsz rozmiar sterty poniżej 32 GB, aby utrzymać obciążenie < 10%.
- Zmniejsz liczbę rdzeni, aby utrzymać obciążenie < GC na 10%.
Czynniki zwiększające rozmiar funkcji wykonawczej:
- Zmniejsz obciążenie komunikacji między funkcjami wykonawczej.
- Zmniejsz liczbę otwartych połączeń między funkcjami wykonawczej (N2) w większych klastrach (>100 funkcji wykonawczych).
- Zwiększ rozmiar sterty w celu uwzględnienia zadań intensywnie korzystających z pamięci.
- Opcjonalnie: Zmniejsz obciążenie pamięci na funkcję wykonawczej.
- Opcjonalnie: Zwiększ użycie i współbieżność przez nadmierne subskrybowanie procesora CPU.
Ogólnie rzecz biorąc, podczas wybierania rozmiaru funkcji wykonawczej:
- Zacznij od 30 GB na funkcję wykonawcza i dystrybuuj dostępne rdzenie maszyn.
- Zwiększ liczbę rdzeni funkcji wykonawczej dla większych klastrów (> 100 funkcji wykonawczych).
- Zmodyfikuj rozmiar na podstawie przebiegów próbnych i na poprzednich czynnikach, takich jak obciążenie GC.
Podczas uruchamiania zapytań współbieżnych rozważ:
- Zacznij od 30 GB na funkcję wykonawcza i wszystkich rdzeni komputera.
- Utwórz wiele równoległych aplikacji Spark przez nadmierne subskrybowanie procesora CPU (około 30% poprawy opóźnienia).
- Dystrybuuj zapytania w aplikacjach równoległych.
- Zmodyfikuj rozmiar na podstawie przebiegów próbnych i na poprzednich czynnikach, takich jak obciążenie GC.
Aby uzyskać więcej informacji na temat konfigurowania funkcji wykonawczych przy użyciu systemu Ambari, zobacz Ustawienia platformy Apache Spark — funkcje wykonawcze platformy Spark.
Monitoruj wydajność zapytań pod kątem wartości odstających lub innych problemów z wydajnością, przeglądając widok osi czasu. Wykres SQL, statystyki zadań itd. Aby uzyskać informacje na temat debugowania zadań platformy Spark przy użyciu usługi YARN i serwera historii platformy Spark, zobacz Debugowanie zadań platformy Apache Spark uruchomionych w usłudze Azure HDInsight. Aby uzyskać porady dotyczące korzystania z serwera osi czasu usługi YARN, zobacz Uzyskiwanie dostępu do dzienników aplikacji usługi Apache Hadoop YARN.
Zadania wolniejsze w niektórych funkcjach wykonawczych lub węzłach
Czasami jeden lub kilka funkcji wykonawczych jest wolniejszych niż inne, a wykonywanie zadań trwa znacznie dłużej. To spowolnienie często występuje w większych klastrach (> 30 węzłów). W takim przypadku należy podzielić pracę na większą liczbę zadań, aby harmonogram mógł zrekompensować powolne zadania. Na przykład ma co najmniej dwa razy więcej zadań niż liczba rdzeni funkcji wykonawczej w aplikacji. Można również włączyć spekulacyjne wykonywanie zadań za pomocą polecenia conf: spark.speculation = true.