Sdílet prostřednictvím

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ásledujícími běžnými scénáři.

  • 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ích stran.
  • Úloha Sparku je pomalejší v jednom clusteru HDI než v jiném clusteru HDI.

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

  • Způsob ukládání dat
  • Jak je cluster nakonfigurovaný
  • Operace, které se používají při zpracování dat.
  • Služba yarn, která není v pořádku
  • Omezení paměti z důvodu nesprávné velikosti exekutorů a chyby OutOfMemoryError
  • Příliš mnoho úkolů nebo příliš málo úkolů
  • Nerovnoměrná distribuce dat způsobila několik náročných úloh nebo pomalých úloh.
  • Pomalejší úlohy 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
  • V souhrnu YARN > zkontrolujte stav ResourceManager a NodeManager: Měl by být spuštěný jenom Active ResourceManager.

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

  2. Zkontrolujte, jestli se v přihlášení ResourceManageru nechybují nějaké výjimky nebo chyby. /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log

Další informace o běžných problémech s Yarn

Krok 2: Porovnání novýchprostředkůch

  1. Přejděte na Ambari UI > YARN > SUMMARY, zkontrolujte paměť clusteru v ServiceMetrics.

  2. Podrobnosti najdete v metrikách fronty yarn:

  • Přejděte do uživatelského rozhraní Yarn, projděte si metriky plánovače Yarn prostřednictvím https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
  • Případně můžete zkontrolovat metriky plánovače yarn prostřednictvím rozhraní REST API Yarn. Například curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". Pro ESP byste měli použít uživatele správce domény.
  1. Výpočet celkových prostředků pro novou aplikaci
  • Všechny exekutory prostředky: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Zobrazit další informace v konfiguraci exekutorů Sparku
  • ApplicationMaster
    • V režimu clusteru používejte spark.driver.memory a spark.driver.cores
    • V klientském režimu používejte 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. Porovnání celkových prostředků 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 uživatelského rozhraní historie Sparku musíme identifikovat následující příznaky:

  • Která fáze je pomalá
  • Jsou celkové využití procesorových jader procesoru na časové ose událostí na kartě Fáze plně využité.
  • Pokud používáte Spark SQL, jaký je fyzický plán na kartě SQL?
  • Ukazuje orientovaný acyklický graf příliš dlouhou dobu trvání jedné fáze?
  • Sledování metrik úkolů (velikost vstupu, velikost náhodného zápisu, čas GC) na kartě Fáze

Další informace o monitorování aplikací Spark

Krok 4: Optimalizace aplikace Spark

Existuje mnoho optimalizací, které vám můžou pomoct tyto problémy překonat, jako je ukládání do mezipaměti a které umožňují nerovnoměrnou distribuci 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.partitions ve výchozím nastavení je 200. Při náhodném prohazování dat pro spojení nebo agregace můžeme upravit obchodní potřeby.
  • spark.sql.files.maxPartitionBytes ve výchozím nastavení je v HDI 1G. Maximální počet bajtů, které se mají zabalit do jednoho oddílu při čtení souborů. Tato konfigurace je efektivní pouze při použití souborových zdrojů, jako jsou Parquet, JSON a ORC.
  • AQE ve Sparku 3.0. Zobrazení adaptivního spouštění dotazů

Další kroky