Optimalizace aplikací Apache Spark ve službě HDInsight

  • Článek

Tento článek obsahuje přehled strategií pro optimalizaci aplikací Apache Spark ve službě Azure HDInsight.

Přehled

Můžete se setkat s níže běžnou situací

  • Stejná úloha Sparku je pomalejší než dříve ve stejném clusteru HDInsight.
  • Úloha Sparku je v clusteru HDInsight pomalejší než místní nebo jiný poskytovatel služeb třetí strany.
  • Úloha Sparku je v jednom clusteru HDI pomalejší než jiný cluster HDI.

Výkon úloh Apache Sparku závisí na několika faktorech. Mezi tyto faktory výkonu patří:

  • Jak se ukládají vaše data
  • Způsob konfigurace clusteru
  • Operace, které se používají při zpracování dat.
  • Služba yarn, která není v pořádku
  • Omezení paměti kvůli nesprávné velikosti exekutorů a chybě OutOfMemoryError
  • Příliš mnoho úkolů nebo příliš málo úkolů
  • Nerovnoměrná distribuce dat způsobila několik náročných nebo pomalých úloh.
  • Pomalejší úkoly ve špatných uzlech

Krok 1: Kontrola, jestli je vaše služba YARN v pořádku

  1. Přejděte do uživatelského rozhraní Ambari:
  • Kontrola, jestli upozornění ResourceManageru nebo NodeManageru
  • Zkontrolujte stav ResourceManager a NodeManager v části SOUHRN YARN > : Všechny služby NodeManager by měly být ve stavu Spuštěno a v části Spuštěno by měly být jenom aktivní ResourceManager.

  1. Kontrola, jestli je uživatelské rozhraní Yarn přístupné prostřednictvím https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster

  2. Zkontrolujte, jestli v přihlášení Resource Manageru nedošlo k výjimkám nebo chybám. /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log

Další informace najdete v tématu Běžné problémy s Yarn.

Krok 2: Porovnání nových prostředků aplikace s dostupnými prostředky yarn

  1. Přejděte na SOUHRN YARN > uživatelského rozhraní > Ambari a zkontrolujte paměť clusteru v metrikách služby.

  2. Podrobně zkontrolujte metriky fronty YARN:

  • Přejděte do uživatelského rozhraní Yarn a projděte si metriky plánovače Yarn. https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
  • Alternativně můžete zkontrolovat metriky plánovače yarn prostřednictvím rozhraní Yarn REST API. Například, curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". Pro ESP byste měli použít uživatele s rolí správce domény.
  1. Výpočet celkového počtu prostředků pro novou aplikaci
  • Všechny prostředky exekutorů: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Další informace najdete v tématu Konfigurace exekutorů Sparku.
  • ApplicationMaster
    • V režimu clusteru použijte spark.driver.memory a spark.driver.cores
    • V režimu klienta použijte spark.yarn.am.memory+spark.yarn.am.memoryOverhead a spark.yarn.am.cores

Poznámka

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

  1. Porovnejte celkové prostředky nové aplikace s dostupnými prostředky yarn v zadané frontě.

Krok 3: Sledování aplikace Spark

  1. Monitorování spuštěné aplikace Spark prostřednictvím uživatelského rozhraní Sparku

  2. Monitorování úplné nebo neúplné aplikace Spark prostřednictvím uživatelského rozhraní serveru historie Sparku

Pomocí uživatelského rozhraní Sparku nebo historie Sparku musíme identifikovat následující příznaky:

  • Která fáze je pomalá
  • Plně využité virtuální jádra procesoru exekutoru v Event-Timeline na kartě Fáze
  • Pokud používáte Spark sql, jaký je fyzický plán na kartě SQL?
  • Je DAG příliš dlouhá v jedné fázi
  • Sledování metrik úloh (velikost vstupu, velikost zápisu náhodného prohaze, čas uvolňování paměti) na kartě Fáze

Další informace najdete v tématu Monitorování aplikací Spark.

Krok 4: Optimalizace aplikace Spark

Existuje mnoho optimalizací, které vám můžou pomoct tyto problémy překonat, například ukládání do mezipaměti a umožnění nerovnoměrné distribuce dat.

V každém z následujících článků najdete informace o různých aspektech optimalizace Sparku.

Optimalizace oddílů Spark SQL

  • spark.sql.shuffle.paritions ve výchozím nastavení je 200. Při náhodném prohazování dat pro spojení nebo agregace můžeme provádět úpravy na základě obchodních potřeb.
  • spark.sql.files.maxPartitionBytes ve výchozím nastavení je v HDI 1G. Maximální počet bajtů, které se mají při čtení souborů sbalit do jednoho oddílu. Tato konfigurace je platná pouze při použití souborových zdrojů, jako jsou Parquet, JSON a ORC.
  • AQE ve Sparku 3.0. Viz Adaptivní spouštění dotazů.

Další kroky