Habr, salam! Dünən , Rambler&Co-dan olan uşaqlardan iştirakçılardan bu alətin konfiqurasiyası ilə bağlı kifayət qədər çox sual var idi. Biz də onun yolunu davam etdirmək və təcrübəmizi bölüşmək qərarına gəldik. Mövzu asan deyil - buna görə sizi şərhlərdə təcrübənizi bölüşməyə dəvət edirik, bəlkə biz də səhv bir şeyi başa düşürük və istifadə edirik.
Spark-dan necə istifadə etdiyimizə bir az giriş. Üç aylıq proqramımız var , və ikinci modul ərzində iştirakçılarımız bu alət üzərində işləyirlər. Müvafiq olaraq, təşkilatçılar kimi bizim vəzifəmiz klasteri belə bir vəziyyətdə istifadəyə hazırlamaqdır.
İstifadəmizin özəlliyi ondan ibarətdir ki, Spark-da eyni vaxtda işləyən insanların sayı bütün qrupa bərabər ola bilər. Məsələn, seminarda hamı eyni vaxtda nəyisə sınayanda və müəllimimizin arxasınca təkrarlayanda. Və bu çox deyil - bəzən 40 nəfərə qədər. Yəqin ki, dünyada belə bir istifadə halı ilə üzləşən şirkətlər çox deyil.
Sonra, bəzi konfiqurasiya parametrlərini necə və niyə seçdiyimizi sizə xəbər verəcəyəm.
Ən başdan başlayaq. Spark-ın klasterdə işləmək üçün 3 variantı var: müstəqil, Mesos-dan istifadə və YARN-dən istifadə. Üçüncü variantı seçməyə qərar verdik, çünki bu, bizim üçün məna kəsb etdi. Artıq bir hadoop klasterimiz var. İştirakçılarımız artıq onun memarlığı ilə yaxşı tanışdırlar. Gəlin YARN-dən istifadə edək.
spark.master=yarnDaha da maraqlı. Bu 3 yerləşdirmə variantının hər birinin 2 yerləşdirmə variantı var: müştəri və klaster. əsasında və İnternetdəki müxtəlif bağlantılardan belə nəticəyə gələ bilərik ki, müştəri interaktiv iş üçün uyğundur - məsələn, jupyter notebook vasitəsilə, klaster isə istehsal həlləri üçün daha uyğundur. Bizim vəziyyətimizdə interaktiv işlə maraqlandıq, buna görə də:
spark.deploy-mode=clientÜmumiyyətlə, bundan sonra Spark birtəhər YARN üzərində işləyəcək, lakin bu bizim üçün kifayət etmədi. Böyük verilənlərlə bağlı proqramımız olduğundan, bəzən iştirakçılar resursların bərabər bölünməsi çərçivəsində əldə edilənlərə kifayət etmirdilər. Və sonra maraqlı bir şey tapdıq - dinamik resurs bölgüsü. Bir sözlə, məsələ belədir: əgər çətin işiniz varsa və klaster pulsuzdursa (məsələn, səhər), onda bu seçimdən istifadə edərək Spark sizə əlavə resurslar verə bilər. Orada zərurət hiyləgər düsturla hesablanır. Təfərrüatlara girməyəcəyik - yaxşı işləyir.
spark.dynamicAllocation.enabled=trueBu parametri təyin etdik və işə salındıqda Spark qəzaya uğradı və başlamadı. Düzdü, çünki oxumalı idim daha diqqətlə. Hər şeyin qaydasında olması üçün əlavə parametri də aktivləşdirməlisiniz.
spark.shuffle.service.enabled=trueNiyə lazımdır? İşimiz artıq bu qədər resurs tələb etmədikdə, Spark onları ümumi hovuza qaytarmalıdır. Demək olar ki, istənilən MapReduce tapşırığında ən çox vaxt aparan mərhələ Qarışdırma mərhələsidir. Bu parametr bu mərhələdə yaradılan məlumatları saxlamağa və müvafiq olaraq icraçıları buraxmağa imkan verir. İcraçı isə hər şeyi işçinin üzərində hesablayan prosesdir. O, müəyyən sayda prosessor nüvəsinə və müəyyən miqdarda yaddaşa malikdir.
Bu parametr əlavə edildi. Hər şey işlək kimi görünürdü. İştirakçılara ehtiyac duyduqda daha çox resurs verildiyi nəzərə çarpdı. Ancaq başqa bir problem ortaya çıxdı - bir anda digər iştirakçılar oyandılar və Spark-dan da istifadə etmək istədilər, lakin orada hər şey məşğul idi və onlar bədbəxt idilər. Onları başa düşmək olar. Sənədlərə baxmağa başladıq. Məlum oldu ki, prosesə təsir etmək üçün istifadə edilə bilən bir sıra başqa parametrlər də var. Məsələn, əgər icraçı gözləmə rejimindədirsə, ondan hansı vaxtdan sonra resurslar götürülə bilər?
spark.dynamicAllocation.executorIdleTimeout=120sBizim vəziyyətimizdə, əgər icraçılarınız iki dəqiqə ərzində heç nə etmirlərsə, xahiş edirəm onları ümumi hovuza qaytarın. Ancaq bu parametr həmişə kifayət deyildi. Adamın uzun müddət heç nə etmədiyi, resursların boşaldılmadığı aydın idi. Məlum oldu ki, xüsusi bir parametr də var - hansı vaxtdan sonra keşləşdirilmiş məlumatları ehtiva edən icraçıları seçmək. Varsayılan olaraq, bu parametr sonsuz idi! Biz düzəliş etdik.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sYəni, əgər icraçılarınız 5 dəqiqə ərzində heç nə etmirlərsə, onları ümumi hovuza verin. Bu rejimdə, çox sayda istifadəçi üçün resursların buraxılması və buraxılması sürəti layiqli hala gəldi. Narazılığın miqdarı azalıb. Lakin biz daha da irəli getməyə qərar verdik və hər bir proqram üzrə icraçıların maksimum sayını - mahiyyətcə proqram iştirakçısına görə məhdudlaşdıraq.
spark.dynamicAllocation.maxExecutors=19İndi, əlbəttə ki, qarşı tərəfdə narazı insanlar var - “klaster boşdur, mənim cəmi 19 icraçım var”, amma siz nə edə bilərsiniz? Hamını xoşbəxt edə bilməzsən.
Və işimizin xüsusiyyətləri ilə bağlı daha bir kiçik hekayə. Nə isə, bir neçə nəfər praktiki dərsə gecikdi və Spark nədənsə onlar üçün başlamadı. Biz pulsuz resursların miqdarına baxdıq - deyəsən, var. Qığılcım başlamalıdır. Xoşbəxtlikdən, o vaxta qədər sənədlər haradasa subkorteksə əlavə edilmişdi və xatırladıq ki, Spark işə salındıqda başlamaq üçün bir liman axtarır. Diapazondakı birinci port məşğul olarsa, o, ardıcıllıqla növbəti birinə keçir. Pulsuzdursa, tutur. Və bunun üçün maksimum cəhdlərin sayını göstərən bir parametr var. Standart 16-dır. Sayı qrupumuzdakı sinifdəki insanların sayından azdır. Müvafiq olaraq, 16 cəhddən sonra Spark təslim oldu və başlaya bilməyəcəyimi söylədi. Bu ayarı düzəltdik.
spark.port.maxRetries=50Sonra işimizin xüsusiyyətləri ilə çox əlaqəli olmayan bəzi parametrlər haqqında sizə məlumat verəcəyəm.
Spark-ı daha sürətli işə salmaq üçün SPARK_HOME ev kataloqunda yerləşən jar qovluğunu arxivləşdirmək və HDFS-ə yerləşdirmək tövsiyə olunur. O zaman bu jarnikləri işçilərə yükləməklə vaxt itirməyəcək.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipDaha sürətli işləmək üçün kryo-dan serializer kimi istifadə etmək də tövsiyə olunur. Standartdan daha optimallaşdırılmışdır.
spark.serializer=org.apache.spark.serializer.KryoSerializerHəm də Spark ilə uzun müddətdir davam edən bir problem var ki, o, tez-tez yaddaşdan çökür. Çox vaxt bu, işçilərin hər şeyi hesabladığı və nəticəni sürücüyə göndərdiyi anda baş verir. Bu parametri özümüz üçün daha böyük etdik. Varsayılan olaraq, 1 GB-dır, biz onu 3 etdik.
spark.driver.maxResultSize=3072Və nəhayət, desert kimi. HortonWorks paylanmasında Spark-ı 2.1 versiyasına necə yeniləmək olar - HDP 2.5.3.0. HDP-nin bu versiyası əvvəlcədən quraşdırılmış 2.0 versiyasını ehtiva edir, lakin biz bir dəfə özümüz üçün qərar verdik ki, Spark olduqca aktiv şəkildə inkişaf edir və hər yeni versiya bəzi səhvləri düzəldir və əlavə funksiyalar, o cümlədən python API üçün təmin edir, ona görə də qərara gəldik ki, nə etmək lazımdır? edilməsi bir yeniləmədir.
Hadoop 2.7 üçün rəsmi veb saytından versiya yükləndi. Sızdırmazlığı açın və HDP qovluğuna qoyun. Lazım olduqda simvolik əlaqələri quraşdırdıq. Biz onu işə salırıq - başlamır. Çox aydın olmayan bir səhv yazır.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigGooglingdən sonra Sparkın Hadoop doğulana qədər gözləməmək qərarına gəldiyini və formanın yeni versiyasını istifadə etməyə qərar verdiyini bildik. Onlar özləri JIRA-da bu mövzu ətrafında bir-biri ilə mübahisə edirlər. Həll yolu yükləmək idi . Bunu SPARK_HOME-da jars qovluğuna yerləşdirin, yenidən zipləyin və HDFS-ə yükləyin.
Biz bu xətanın öhdəsindən gəldik, lakin yeni və kifayət qədər sadələşdirilmiş bir səhv yarandı.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterEyni zamanda, biz 2.0 versiyasını işə salmağa çalışırıq - hər şey qaydasındadır. Nə baş verdiyini təxmin etməyə çalışın. Bu tətbiqin qeydlərinə baxdıq və belə bir şey gördük:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarÜmumiyyətlə, nədənsə hdp.version həll olunmadı. Google axtarışından sonra bir həll tapdıq. Siz Ambari-də YARN parametrlərinə keçməlisiniz və orada xüsusi iplik saytına bir parametr əlavə etməlisiniz:
hdp.version=2.5.3.0-37Bu sehr kömək etdi və Spark getdi. Bir neçə jupyter noutbukumuzu sınaqdan keçirdik. Hər şey işləyir. Şənbə günü (sabah) ilk Spark dərsinə hazırıq!
DUP. Dərs zamanı daha bir problem üzə çıxdı. Bir nöqtədə YARN Spark üçün konteynerlər verməyi dayandırdı. YARN-də standart olaraq 0.2 olan parametri düzəltmək lazım idi:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Yəni resursların bölüşdürülməsində resursların yalnız 20%-i iştirak edib. Parametrləri dəyişdirdikdən sonra YARN-i yenidən yüklədik. Problem həll olundu və qalan iştirakçılar da kontekstdə qığılcım işlədə bildilər.
Mənbə: www.habr.com