Optymalizowanie aplikacji platformy Apache Spark w usłudze HDInsight

  • Artykuł

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

Omówienie

Poniższe typowe scenariusze mogą wystąpić

  • 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 innej firmy
  • 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ą:

  • Sposób przechowywania danych
  • 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 zbyt mało zadań
  • Niesymetryczność danych spowodowała kilka ciężkich zadań lub powolnych zadań
  • Zadania wolniejsze w nieprawidłowych węzłach

Krok 1. Sprawdzanie, czy usługa przędzy 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 > : Wszystkie węzłyManager powinny znajdować się w obszarze Uruchomiono, a w obszarze Uruchomiono powinien znajdować się tylko aktywny menedżer zasobów

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

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

Zobacz więcej informacji na temat typowych problemów z usługą Yarn

Krok 2. Porównanie nowych zasobów aplikacji z dostępnymi zasobami przędzy

  1. Przejdź do pozycji Podsumowanie YARN > interfejsu > użytkownika systemu Ambari, sprawdź PAMIĘĆ KLASTRA w metrykach usługi

  2. Sprawdź metryki kolejki przędzy w szczegółach:

  • Przejdź do interfejsu użytkownika usługi Yarn, sprawdź metryki harmonogramu usługi Yarn za pośrednictwem https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
  • Alternatywnie możesz sprawdzić metryki harmonogramu przędzy 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.
  1. Obliczanie łącznych 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

  1. Porównaj łączną ilość zasobów nowej aplikacji z dostępnymi zasobami 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 jest powolny
  • Czy łączna liczba rdzeni wirtualnych procesora CPU jest w pełni wykorzystywana w Event-Timeline na karcie Etap
  • Jeśli używasz języka spark sql, jaki jest plan fizyczny na karcie SQL
  • Czy daG 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 partycji Spark SQL

  • spark.sql.shuffle.paritions domyślnie jest to 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 używania źródeł opartych na plikach, takich jak Parquet, JSON i ORC.
  • AQE na platformie Spark 3.0. Zobacz Wykonywanie zapytań adaptacyjnych

Następne kroki