Habr, ahoj! Včera dne , od kluků z Rambler&Co, bylo od účastníků poměrně hodně dotazů týkajících se konfigurace tohoto nástroje. Rozhodli jsme se jít v jeho stopách a podělit se o své zkušenosti. Téma není jednoduché - proto vás zveme, abyste se o své zkušenosti podělili v komentářích, možná také rozumíme a používáme něco špatně.
Malý úvod k tomu, jak používáme Spark. Máme tříměsíční program a během druhého modulu naši účastníci na tomto nástroji pracují. V souladu s tím je naším úkolem jako organizátorů připravit cluster pro použití v takovém případě.
Zvláštností našeho použití je, že počet lidí současně pracujících na Sparku se může rovnat celé skupině. Třeba na semináři, kdy všichni něco zkouší zároveň a opakují po našem učiteli. A to není mnoho – někdy až 40 lidí. Na světě pravděpodobně není mnoho společností, které čelí takovému případu použití.
Dále vám řeknu, jak a proč jsme vybrali určité konfigurační parametry.
Začněme úplně od začátku. Spark má 3 možnosti spuštění na clusteru: samostatný, pomocí Mesos a pomocí YARN. Rozhodli jsme se pro třetí možnost, protože nám to dávalo smysl. Hadoop cluster už máme. Naši účastníci již dobře znají jeho architekturu. Použijme PŘÍZE.
spark.master=yarnDále zajímavější. Každá z těchto 3 možností nasazení má 2 možnosti nasazení: klient a cluster. Na základě a různých odkazů na internetu, můžeme usoudit, že klient je vhodný pro interaktivní práci - např. přes jupyter notebook a cluster je vhodnější pro produkční řešení. V našem případě nás zaujala interaktivní práce, proto:
spark.deploy-mode=clientObecně platí, že od této chvíle bude Spark nějak fungovat na YARN, ale to nám nestačilo. Jelikož máme program o velkých datech, občas účastníkům nestačilo to, co bylo získáno v rámci rovnoměrného krájení zdrojů. A pak jsme našli zajímavou věc – dynamickou alokaci zdrojů. Stručně řečeno, jde o toto: pokud máte obtížný úkol a cluster je volný (například ráno), pomocí této možnosti vám Spark může poskytnout další zdroje. Nutnost se tam vypočítává podle mazaného vzorce. Nebudeme zabíhat do podrobností - funguje to dobře.
spark.dynamicAllocation.enabled=trueNastavili jsme tento parametr a po spuštění se Spark zhroutil a nespustil se. To je pravda, protože jsem si to musel přečíst opatrněji. Uvádí, že aby bylo vše v pořádku, je potřeba povolit i další parametr.
spark.shuffle.service.enabled=trueProč je to potřeba? Když naše práce už nebude vyžadovat tolik zdrojů, Spark by je měl vrátit do společného fondu. Časově nejnáročnější fází téměř každé úlohy MapReduce je fáze Shuffle. Tento parametr umožňuje uložit data, která jsou v této fázi vygenerována, a odpovídajícím způsobem uvolnit exekutory. A exekutor je proces, který vše vypočítává na pracovníka. Má určitý počet procesorových jader a určité množství paměti.
Tento parametr byl přidán. Zdálo se, že vše funguje. Ukázalo se, že účastníkům bylo ve skutečnosti poskytnuto více zdrojů, když je potřebovali. Vyvstal ale další problém – v určitou chvíli se probudili další účastníci a chtěli také použít Spark, ale všechno tam bylo obsazeno a oni byli nešťastní. Lze je pochopit. Začali jsme prohlížet dokumentaci. Ukázalo se, že existuje řada dalších parametrů, kterými lze proces ovlivnit. Pokud je například exekutor v pohotovostním režimu, po jaké době z něj lze prostředky odebrat?
spark.dynamicAllocation.executorIdleTimeout=120sV našem případě, pokud vaši exekutoři dvě minuty nic nedělají, tak je prosím vraťte do společného bazénu. Tento parametr ale vždy nestačil. Bylo jasné, že ten člověk už dlouho nic nedělá a zdroje se neuvolňují. Ukázalo se, že existuje také speciální parametr - po jaké době vybrat exekutory, které obsahují data v mezipaměti. Ve výchozím nastavení byl tento parametr nekonečno! Opravili jsme to.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sTo znamená, že pokud vaši exekutoři 5 minut nic nedělají, dejte je do společného fondu. V tomto režimu se rychlost uvolňování a vydávání prostředků pro velký počet uživatelů stala slušnou. Míra nespokojenosti se snížila. Rozhodli jsme se však jít dále a omezit maximální počet vykonavatelů na žádost – v podstatě na účastníka programu.
spark.dynamicAllocation.maxExecutors=19Teď jsou samozřejmě na druhé straně nespokojenci – „klastr je nečinný a já mám jen 19 exekutorů,“ ale co se dá dělat, potřebujeme nějakou správnou rovnováhu. Nemůžete udělat radost všem.
A ještě jeden malý příběh související se specifiky našeho případu. Několik lidí se nějak opozdilo na praktickou lekci a z nějakého důvodu pro ně Spark nezačal. Podívali jsme se na množství volných zdrojů – zdá se, že tam jsou. Spark by měl začít. Naštěstí už v té době byla dokumentace někde přidána do subkortexu a vzpomněli jsme si, že po spuštění Spark hledá port, na kterém by mohl začít. Pokud je první port v rozsahu obsazený, přesune se na další v pořadí. Pokud je zdarma, zachytí. A existuje parametr, který udává maximální počet pokusů. Výchozí hodnota je 16. Počet je menší než počet lidí v naší skupině ve třídě. V souladu s tím se Spark po 16 pokusech vzdal a řekl, že nemůžu začít. Toto nastavení jsme opravili.
spark.port.maxRetries=50Dále vám řeknu o některých nastaveních, která příliš nesouvisí se specifiky našeho případu.
Pro rychlejší spuštění Sparku se doporučuje archivovat složku jars umístěnou v domovském adresáři SPARK_HOME a umístit ji na HDFS. Pak nebude ztrácet čas nakládáním těchto jarníků dělníky.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipPro rychlejší provoz se také doporučuje používat kryo jako serializátor. Je optimalizovanější než výchozí.
spark.serializer=org.apache.spark.serializer.KryoSerializerA se Sparkem je také dlouholetý problém, že často padá z paměti. Často se tak stane ve chvíli, kdy pracovníci vše spočítali a výsledek pošlou řidiči. Tento parametr jsme pro sebe zvětšili. Ve výchozím nastavení je to 1 GB, my jsme to udělali 3.
spark.driver.maxResultSize=3072A nakonec jako dezert. Jak aktualizovat Spark na verzi 2.1 v distribuci HortonWorks - HDP 2.5.3.0. Tato verze HDP obsahuje předinstalovanou verzi 2.0, ale jednou jsme se sami rozhodli, že Spark se vyvíjí poměrně aktivně a každá nová verze opravuje některé chyby a poskytuje další funkce, včetně pro python API, takže jsme se rozhodli, co potřebuje be done je aktualizace.
Stažená verze z oficiálních stránek pro Hadoop 2.7. Rozbalte jej a vložte do složky HDP. Nainstalovali jsme symbolické odkazy podle potřeby. Spustíme to - nespustí se. Píše velmi zvláštní chybu.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigPo googlování jsme zjistili, že se Spark rozhodl nečekat, až se zrodí Hadoop, a rozhodl se použít novou verzi dresu. Sami se na toto téma v JIRA dohadují. Řešením bylo stáhnout . Umístěte jej do složky jars ve SPARK_HOME, znovu jej zazipujte a nahrajte do HDFS.
Tuto chybu jsme obešli, ale objevila se nová a poměrně zjednodušená.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterZároveň se snažíme spustit verzi 2.0 - vše ok. Zkuste hádat, co se děje. Podívali jsme se do protokolů této aplikace a viděli jsme něco takového:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarObecně se z nějakého důvodu hdp.version nevyřešilo. Po googlování jsme našli řešení. Musíte jít do nastavení YARN v Ambari a přidat tam parametr na vlastní stránku příze:
hdp.version=2.5.3.0-37Tato magie pomohla a Spark vzlétl. Testovali jsme několik našich notebooků Jupyter. Všechno funguje. V sobotu (zítra) jsme připraveni na první lekci Spark!
UPD. Během lekce vyšel najevo další problém. V určitém okamžiku YARN přestala poskytovat kontejnery pro Spark. V YARN bylo nutné opravit parametr, který byl ve výchozím nastavení 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
To znamená, že na rozdělování zdrojů se podílelo pouze 20 % zdrojů. Po změně parametrů jsme znovu naložili PŘÍZE. Problém byl vyřešen a zbytek účastníků byl také schopen spustit jiskrový kontext.
Zdroj: www.habr.com