Хабр, здраво! Вчера на , од момците од Rambler&Co, имаше доста прашања од учесниците поврзани со конфигурирање на оваа алатка. Решивме да ги следиме неговите стапки и да го споделиме нашето искуство. Темата не е лесна - затоа ве покануваме да го споделите вашето искуство во коментари, можеби и ние разбираме и користиме нешто погрешно.
Мал вовед како го користиме Spark. Имаме тримесечна програма , а во текот на вториот модул нашите учесници работат на овој инструмент. Според тоа, наша задача како организатори е да го подготвиме кластерот за употреба во таков случај.
Особеноста на нашата употреба е дека бројот на луѓе кои истовремено работат на Spark може да биде еднаков на целата група. На пример, на семинар, кога секој пробува нешто во исто време и повторува по нашиот учител. И ова не е многу - понекогаш и до 40 луѓе. Веројатно нема многу компании во светот кои се соочуваат со ваков случај на употреба.
Следно, ќе ви кажам како и зошто избравме одредени параметри за конфигурација.
Да почнеме од самиот почеток. Spark има 3 опции за работа на кластер: самостоен, користење Mesos и користење YARN. Решивме да ја избереме третата опција бидејќи ни имаше смисла. Веќе имаме кластер за Хадуп. Нашите учесници веќе се добро запознаени со неговата архитектура. Ајде да користиме предиво.
spark.master=yarnПонатаму поинтересно. Секоја од овие 3 опции за распоредување има 2 опции за распоредување: клиент и кластер. Врз основа и разни врски на Интернет, можеме да заклучиме дека клиентот е погоден за интерактивна работа - на пример, преку тетратка jupyter, а кластерот е посоодветен за производствени решенија. Во нашиот случај, бевме заинтересирани за интерактивна работа, затоа:
spark.deploy-mode=clientВо принцип, отсега Spark некако ќе работи на YARN, но ова не ни беше доволно. Бидејќи имаме програма за големи податоци, понекогаш учесниците немаа доволно од она што беше добиено во рамките на рамномерно сечење на ресурсите. И тогаш најдовме интересна работа - динамична распределба на ресурси. Накратко, поентата е следна: ако имате тешка задача и кластерот е бесплатен (на пример, наутро), тогаш користењето на оваа опција Spark може да ви даде дополнителни ресурси. Таму нужноста се пресметува по лукава формула. Ние нема да навлегуваме во детали - работи добро.
spark.dynamicAllocation.enabled=trueГо поставивме овој параметар и при стартувањето Spark падна и не стартуваше. Така е, затоа што морав да го прочитам повнимателно. Во него пишува дека за да биде се во ред треба да вклучиш и дополнителен параметар.
spark.shuffle.service.enabled=trueЗошто е потребно? Кога нашата работа веќе не бара толку многу ресурси, Spark треба да ги врати во заедничкиот базен. Најмногу време одзема фаза во речиси секоја задача на MapReduce е фазата Shuffle. Овој параметар ви овозможува да ги зачувате податоците што се генерираат во оваа фаза и соодветно да ги ослободите извршителите. А извршител е процесот кој пресметува се на работникот. Има одреден број на процесорски јадра и одредена количина на меморија.
Овој параметар е додаден. Се чинеше дека сè функционира. Стана забележливо дека на учесниците всушност им беа дадени повеќе ресурси кога им беа потребни. Но, се појави друг проблем - во одреден момент другите учесници се разбудија и исто така сакаа да користат Spark, но таму сè беше зафатено и тие беа несреќни. Тие можат да се разберат. Почнавме да ја разгледуваме документацијата. Се покажа дека има голем број други параметри кои можат да се користат за да се влијае на процесот. На пример, ако извршителот е во режим на подготвеност, по кое време може да се преземат ресурси од него?
spark.dynamicAllocation.executorIdleTimeout=120sВо нашиот случај, ако вашите извршители не прават ништо две минути, тогаш ве молиме вратете ги во заедничкиот базен. Но, овој параметар не беше секогаш доволен. Беше јасно дека лицето не правело ништо долго време, а ресурсите не се ослободуваат. Се покажа дека има и посебен параметар - по кое време да се изберат извршители што содржат кеширани податоци. Стандардно, овој параметар беше бесконечност! Го коригиравме.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sОдносно, ако вашите извршители не прават ништо 5 минути, дајте ги на заедничкиот базен. Во овој режим, брзината на ослободување и издавање ресурси за голем број корисници стана пристојна. Износот на незадоволството е намален. Но, решивме да одиме понатаму и да го ограничиме максималниот број на извршители по апликација - во суштина по учесник во програмата.
spark.dynamicAllocation.maxExecutors=19Сега, се разбира, има незадоволни луѓе од другата страна - „кластерот е неактивен, а јас имам само 19 извршители“, но што можете да направите? Потребен ни е некој вид правилен баланс. Не можеш сите да ги направиш среќни.
И уште една мала приказна поврзана со спецификите на нашиот случај. Некако неколку луѓе доцнеа на практична лекција и поради некоја причина Спарк не им почна. Ја разгледавме количината на бесплатни ресурси - се чини дека е таму. Искра треба да започне. За среќа, дотогаш документацијата веќе некаде беше додадена во подкортексот и се сетивме дека кога ќе биде лансиран, Spark бара пристаниште од кое ќе започне. Ако првата порта во опсегот е зафатена, таа се префрла на следната по редослед. Ако е бесплатен, фаќа. И постои параметар што го покажува максималниот број обиди за ова. Стандардно е 16. Бројот е помал од бројот на луѓе во нашата група во класата. Според тоа, по 16 обиди, Спарк се откажа и рече дека не можам да започнам. Го коригиравме овој параметар.
spark.port.maxRetries=50Следно, ќе ви кажам за некои поставки кои не се многу поврзани со спецификите на нашиот случај.
За да го стартувате Spark побрзо, се препорачува да ја архивирате папката jars лоцирана во домашниот директориум SPARK_HOME и да ја ставите на HDFS. Тогаш нема да губи време да ги товари овие јарници од работници.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipИсто така, се препорачува да се користи kryo како серијализатор за побрзо работење. Пооптимизиран е од стандардниот.
spark.serializer=org.apache.spark.serializer.KryoSerializerИсто така, постои долгогодишен проблем со Spark што често се урива од меморијата. Често тоа се случува во моментот кога работниците пресметале сè и го испраќаат резултатот до возачот. Овој параметар го направивме поголем за себе. Стандардно е 1GB, ние го направивме 3.
spark.driver.maxResultSize=3072И на крај, како десерт. Како да го ажурирате Spark на верзијата 2.1 на дистрибуцијата на HortonWorks - HDP 2.5.3.0. Оваа верзија на HDP содржи претходно инсталирана верзија 2.0, но еднаш решивме сами дека Spark се развива доста активно, и секоја нова верзија поправа некои грешки, плус обезбедува дополнителни функции, вклучително и за API за python, па решивме , што треба да да се направи е ажурирање.
Ја презеде верзијата од официјалната веб-страница за Hadoop 2.7. Отпакувајте го и ставете го во фолдерот HDP. Ги инсталиравме симболите по потреба. Го лансираме - не започнува. Пишува многу чудна грешка.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigОткако прогуглавме, дознавме дека Спарк решил да не чека да се роди Хадуп и решил да ја искористи новата верзија на дресот. Тие самите се расправаат на оваа тема во ЈИРА. Решението беше да се преземе . Ставете го ова во папката тегли во SPARK_HOME, повторно затворете го и поставете го на HDFS.
Ја заобиколивме оваа грешка, но се појави нова и прилично рационализирана грешка.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterВо исто време, се обидуваме да ја извршиме верзијата 2.0 - сè е во ред. Обидете се да погодите што се случува. Ги погледнавме дневниците на оваа апликација и видовме вакво нешто:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarВо принцип, поради некоја причина hdp.version не се реши. По гуглање најдовме решение. Треба да отидете во поставките на YARN во Ambari и да додадете параметар таму на приспособена локација за предиво:
hdp.version=2.5.3.0-37Оваа магија помогна, а Спарк полета. Тестиравме неколку наши јупитер лаптопи. Сè работи. Подготвени сме за првиот час по Spark во сабота (утре)!
ДУП. За време на часот на виделина се појави уште еден проблем. Во одреден момент, YARN престана да обезбедува контејнери за Spark. Во YARN беше неопходно да се поправи параметарот, кој стандардно беше 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Односно, само 20% од ресурсите учествувале во распределбата на ресурсите. Откако ги променивме параметрите, повторно го вчитавме YARN. Проблемот беше решен и останатите учесници исто така можеа да го испратат контекстот на искра.
Извор: www.habr.com