Հաբր, բարև: Երեկ ին , Rambler&Co-ի տղաներից բավականին շատ հարցեր կային մասնակիցների կողմից՝ կապված այս գործիքի կազմաձևման հետ։ Մենք որոշեցինք գնալ նրա հետքերով և կիսվել մեր փորձով։ Թեման հեշտ չէ, ուստի մենք ձեզ հրավիրում ենք կիսվել ձեր փորձով մեկնաբանություններում, միգուցե մենք նույնպես ինչ-որ սխալ ենք հասկանում և օգտագործում:
Մի փոքր ներածություն, թե ինչպես ենք մենք օգտագործում Spark-ը: Մենք ունենք եռամսյա ծրագիր , և երկրորդ մոդուլի ընթացքում մեր մասնակիցներն աշխատում են այս գործիքի վրա: Ըստ այդմ, մեր՝ որպես կազմակերպիչների խնդիրն է պատրաստել կլաստերը՝ նման դեպքի շրջանակներում օգտագործելու համար։
Մեր օգտագործման առանձնահատկությունն այն է, որ Spark-ում միաժամանակ աշխատող մարդկանց թիվը կարող է հավասար լինել ամբողջ խմբին։ Օրինակ՝ սեմինարի ժամանակ, երբ բոլորը միաժամանակ ինչ-որ բան են փորձում և կրկնում մեր ուսուցչի հետևից. Եվ սա շատ չէ՝ երբեմն մինչև 40 հոգի։ Աշխարհում, հավանաբար, շատ ընկերություններ չկան, որոնք բախվում են նման օգտագործման դեպքի:
Հաջորդը, ես ձեզ կասեմ, թե ինչպես և ինչու ենք ընտրել որոշակի կազմաձևման պարամետրեր:
Սկսենք հենց սկզբից։ Spark-ն ունի կլաստերի վրա աշխատելու 3 տարբերակ՝ ինքնուրույն, օգտագործելով Mesos և օգտագործելով YARN: Մենք որոշեցինք ընտրել երրորդ տարբերակը, քանի որ այն մեզ համար իմաստալից էր։ Մենք արդեն ունենք hadoop կլաստեր: Մեր մասնակիցներն արդեն քաջածանոթ են նրա ճարտարապետությանը։ Եկեք օգտագործենք ՄԱՆԵԼ.
spark.master=yarnԱվելի հետաքրքիր. Այս 3 տեղակայման տարբերակներից յուրաքանչյուրն ունի 2 տեղակայման տարբերակ՝ հաճախորդ և կլաստեր: Հիմնված և ինտերնետի տարբեր հղումներով, կարող ենք եզրակացնել, որ հաճախորդը հարմար է ինտերակտիվ աշխատանքի համար, օրինակ՝ jupyter notebook-ի միջոցով, իսկ կլաստերն ավելի հարմար է արտադրական լուծումների համար: Մեր դեպքում մեզ հետաքրքրում էր ինտերակտիվ աշխատանքը, հետևաբար.
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-ը չսկսվեց նրանց համար: Մենք նայեցինք անվճար ռեսուրսների քանակին, կարծես թե կա: Կայծը պետք է սկսվի: Բարեբախտաբար, այդ ժամանակ փաստաթղթերն արդեն ինչ-որ տեղ ավելացվել էին ենթակեղևում, և մենք հիշեցինք, որ գործարկվելիս Spark-ը փնտրում է մի նավահանգիստ, որտեղից պետք է սկսել: Եթե միջակայքի առաջին նավահանգիստը զբաղված է, այն հերթականությամբ տեղափոխվում է հաջորդը: Եթե ազատ է, գրավում է։ Եվ կա մի պարամետր, որը ցույց է տալիս դրա համար փորձերի առավելագույն քանակը: Կանխադրվածը 16 է: Թիվն ավելի քիչ է, քան դասարանում մեր խմբի մարդկանց թիվը: Համապատասխանաբար, 16 փորձից հետո Սփարկը հանձնվեց և ասաց, որ չեմ կարող սկսել: Մենք շտկել ենք այս պարամետրը:
spark.port.maxRetries=50Հաջորդը ես ձեզ կասեմ որոշ պարամետրերի մասին, որոնք այնքան էլ կապված չեն մեր գործի առանձնահատկությունների հետ:
Spark-ն ավելի արագ գործարկելու համար խորհուրդ է տրվում արխիվացնել բանկաների թղթապանակը, որը գտնվում է SPARK_HOME գլխավոր գրացուցակում և տեղադրել այն HDFS-ում: Հետո նա ժամանակ չի կորցնի այդ ժառնիկները բանվորներով բեռնելու վրա։
spark.yarn.archive=hdfs:///tmp/spark-archive.zipԽորհուրդ է տրվում նաև օգտագործել kryo-ն որպես սերիալիզատոր՝ ավելի արագ աշխատանքի համար: Այն ավելի օպտիմիզացված է, քան լռելյայն:
spark.serializer=org.apache.spark.serializer.KryoSerializerԵվ կա նաև Spark-ի վաղեմի խնդիր, որ այն հաճախ խափանում է հիշողությունից: Հաճախ դա տեղի է ունենում այն պահին, երբ աշխատողները հաշվարկել են ամեն ինչ և արդյունքն ուղարկել վարորդին։ Մենք այս պարամետրն ավելի մեծ դարձրինք մեզ համար: Լռելյայն 1 ԳԲ է, մենք դարձրինք 3։
spark.driver.maxResultSize=3072Եվ վերջապես, որպես աղանդեր: Ինչպես թարմացնել Spark-ը 2.1 տարբերակին HortonWorks բաշխման վրա - HDP 2.5.3.0: HDP-ի այս տարբերակը պարունակում է նախապես տեղադրված 2.0 տարբերակ, բայց մենք մի անգամ որոշեցինք, որ Spark-ը բավականին ակտիվ է զարգանում, և յուրաքանչյուր նոր տարբերակ շտկում է որոշ սխալներ և լրացուցիչ հնարավորություններ է տալիս, այդ թվում՝ python API-ի համար, ուստի մենք որոշեցինք, թե ինչ է պետք։ կատարել թարմացում է:
Ներբեռնել է տարբերակը Hadoop 2.7-ի պաշտոնական կայքից: Անջատեք այն և դրեք HDP թղթապանակում: Մենք տեղադրեցինք symlinks ըստ անհրաժեշտության: Մենք գործարկում ենք այն, այն չի սկսվում: Շատ տարօրինակ սխալ է գրում.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigԳուգլելուց հետո պարզեցինք, որ Սփարկը որոշել է չսպասել Հադուպի ծնվելուն և որոշել է օգտագործել մարզաշապիկի նոր տարբերակը։ Իրենք այս թեմայով JIRA-ում վիճում են միմյանց հետ։ Լուծումը ներբեռնելն էր . Տեղադրեք սա 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-ը չլուծվեց: Գուգլելուց հետո մենք լուծում գտանք։ Դուք պետք է գնաք Ambari-ում YARN-ի կարգավորումներ և այնտեղ պարամետր ավելացնեք մաքսային yarn-site-ում.
hdp.version=2.5.3.0-37Այս կախարդանքը օգնեց, և Spark-ը թռավ: Մենք փորձարկեցինք մեր մի քանի jupyter նոութբուքեր: Ամեն ինչ աշխատում է։ Մենք պատրաստ ենք շաբաթ օրը (վաղը) առաջին Spark դասին:
DUP. Դասի ընթացքում ի հայտ եկավ մեկ այլ խնդիր. Ինչ-որ պահի YARN-ը դադարեցրեց Spark-ի համար տարաներ տրամադրելը: YARN-ում անհրաժեշտ էր ուղղել այն պարամետրը, որը լռելյայն 0.2 էր.
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Այսինքն՝ ռեսուրսների միայն 20%-ն է մասնակցել ռեսուրսների բաշխմանը։ Պարամետրերը փոխելուց հետո մենք վերաբեռնեցինք YARN-ը: Խնդիրը լուծվեց, և մնացած մասնակիցները նույնպես կարողացան գործարկել կայծային համատեքստը:
Source: www.habr.com