Optymalizowanie aplikacji platformy Apache Spark w usłudze HDInsight

Ten artykuł zawiera omówienie strategii optymalizacji aplikacji platformy Apache Spark w usłudze Azure HDInsight.

Omówienie

Poniżej typowych scenariuszy można napotkać

• To samo zadanie spark działa wolniej niż wcześniej w tym samym klastrze usługi HDInsight
• Zadanie platformy Spark jest wolniejsze w klastrze usługi HDInsight niż lokalny lub inny dostawca usług innych firm
• Zadanie spark działa wolniej w jednym klastrze usługi HDI niż w innym klastrze usługi HDI

Wydajność zadań platformy Apache Spark zależy od wielu czynników. Te czynniki wydajności obejmują:

• Jak są przechowywane dane
• Jak skonfigurowano klaster
• Operacje używane podczas przetwarzania danych.
• Usługa przędzy w złej kondycji
• Ograniczenia pamięci spowodowane niewłaściwym rozmiarem funkcji wykonawczych i OutOfMemoryError
• Zbyt wiele zadań lub za mało zadań
• Niesymetryczność danych spowodowała kilka ciężkich zadań lub wolnych zadań
• Zadania wolniejsze w nieprawidłowych węzłach

Krok 1. Sprawdzanie, czy usługa Yarn jest w dobrej kondycji

1. Przejdź do interfejsu użytkownika systemu Ambari:

• Sprawdzanie, czy alerty usługi ResourceManager lub NodeManager
• Sprawdź stan ResourceManager i NodeManager w podsumowaniu usługi YARN > : W pozycji Uruchomiono powinien znajdować się wszystkie węzły NodeManager, a w obszarze Uruchomiono powinien znajdować się tylko aktywny menedżer zasobów

2. Sprawdź, czy interfejs użytkownika usługi Yarn jest dostępny za pośrednictwem https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster

3. Sprawdź, czy jakiekolwiek wyjątki lub błędy w dzienniku usługi ResourceManager /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log

Zobacz więcej informacji w temacie Typowe problemy z usługą Yarn

Krok 2. Porównanie nowych zasobów aplikacji z dostępnymi zasobami usługi yarn

1. Przejdź do pozycji Podsumowanie YARN >interfejsu > użytkownika systemu Ambari, sprawdź PAMIĘĆ KLASTRA w obszarze ServiceMetrics

2. Sprawdź metryki kolejki usługi yarn w szczegółach:

• Przejdź do interfejsu użytkownika usługi Yarn, sprawdź metryki harmonogramu usługi Yarn za pomocą polecenia https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
• Alternatywnie możesz sprawdzić metryki harmonogramu yarn za pomocą interfejsu API REST usługi Yarn. Na przykład curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". W przypadku rejestracji należy użyć użytkownika administratora domeny.

3. Oblicz łączną ilość zasobów dla nowej aplikacji

• Wszystkie zasoby funkcji wykonawczej: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Zobacz więcej informacji w konfiguracji funkcji wykonawczej platformy Spark
• ApplicationMaster
  • W trybie klastra użyj polecenia spark.driver.memory i spark.driver.cores
  • W trybie klienta użyj polecenia spark.yarn.am.memory+spark.yarn.am.memoryOverhead i spark.yarn.am.cores

Uwaga

yarn.scheduler.minimum-allocation-mb <= spark.executor.memory+spark.yarn.executor.memoryOverhead <= yarn.scheduler.maximum-allocation-mb

4. Porównaj nowe zasoby całkowite aplikacji z dostępnymi zasobami usługi yarn w określonej kolejce

Krok 3. Śledzenie aplikacji spark

1. Monitorowanie uruchomionej aplikacji spark za pomocą interfejsu użytkownika platformy Spark

2. Monitorowanie kompletnej lub niekompletnej aplikacji spark za pomocą interfejsu użytkownika serwera historii platformy Spark

Musimy zidentyfikować poniższe objawy za pomocą interfejsu użytkownika platformy Spark lub interfejsu użytkownika historii platformy Spark:

• Który etap działa wolno
• Czy łączna liczba rdzeni wirtualnych procesora CPU jest w pełni wykorzystywana na karcie Oś czasu zdarzeń na karcie Etap
• Jeśli używasz języka spark sql, jaki jest plan fizyczny na karcie SQL
• Czy skierowany graf acykliczny nie jest zbyt długi na jednym etapie
• Obserwowanie metryk zadań (rozmiar danych wejściowych, rozmiar zapisu shuffle, czas GC) na karcie Etap

Zobacz więcej informacji w temacie Monitorowanie aplikacji platformy Spark

Krok 4. Optymalizowanie aplikacji spark

Istnieje wiele optymalizacji, które mogą pomóc w pokonaniu tych wyzwań, takich jak buforowanie i umożliwienie niesymetryczności danych.

W każdym z poniższych artykułów można znaleźć informacje na temat różnych aspektów optymalizacji platformy Spark.

• Optymalizowanie magazynu danych dla platformy Apache Spark
• Optymalizowanie przetwarzania danych dla platformy Apache Spark
• Optymalizowanie użycia pamięci dla platformy Apache Spark
• Optymalizowanie konfiguracji klastra usługi HDInsight dla platformy Apache Spark

Optymalizowanie partycji Spark SQL

• spark.sql.shuffle.partitions domyślnie ma wartość 200. Możemy dostosować się na podstawie potrzeb biznesowych podczas mieszania danych dla sprzężeń lub agregacji.
• spark.sql.files.maxPartitionBytes jest domyślnie 1G w usłudze HDI. Maksymalna liczba bajtów do spakowania w jedną partycję podczas odczytywania plików. Ta konfiguracja jest skuteczna tylko w przypadku korzystania ze źródeł opartych na plikach, takich jak Parquet, JSON i ORC.
• AQE na platformie Spark 3.0. Zobacz Wykonywanie zapytań adaptacyjnych

Następne kroki

• Debugowanie zadań platformy Apache Spark uruchomionych w usłudze Azure HDInsight
• Zarządzanie zasobami dla klastra Apache Spark w usłudze HDInsight
• Konfigurowanie ustawień platformy Apache Spark