યાર્ન પર સ્પાર્કને ગોઠવી રહ્યું છે

હેબ્ર, હેલો! ગઈ કાલે અપાચે સ્પાર્કને સમર્પિત મીટઅપ, Rambler&Co ના લોકો તરફથી, આ ટૂલને ગોઠવવા સંબંધિત સહભાગીઓ તરફથી ઘણા બધા પ્રશ્નો હતા. અમે તેમના પગલે ચાલવાનું અને અમારા અનુભવને શેર કરવાનું નક્કી કર્યું. વિષય સરળ નથી - તેથી અમે તમને ટિપ્પણીઓમાં તમારો અનુભવ શેર કરવા માટે આમંત્રિત કરીએ છીએ, કદાચ અમે પણ સમજીએ છીએ અને કંઈક ખોટું વાપરીએ છીએ.

આપણે સ્પાર્કનો ઉપયોગ કેવી રીતે કરીએ છીએ તેનો થોડો પરિચય. અમારી પાસે ત્રણ મહિનાનો કાર્યક્રમ છે "બિગ ડેટા સ્પેશિયાલિસ્ટ", અને બીજા મોડ્યુલ દરમ્યાન અમારા સહભાગીઓ આ સાધન પર કામ કરે છે. તદનુસાર, અમારું કાર્ય, આયોજકો તરીકે, આવા કિસ્સામાં ઉપયોગ માટે ક્લસ્ટર તૈયાર કરવાનું છે.

અમારા ઉપયોગની ખાસિયત એ છે કે સ્પાર્ક પર એકસાથે કામ કરતા લોકોની સંખ્યા સમગ્ર જૂથની સમાન હોઈ શકે છે. ઉદાહરણ તરીકે, સેમિનારમાં, જ્યારે દરેક વ્યક્તિ એક જ સમયે કંઈક કરવાનો પ્રયાસ કરે છે અને અમારા શિક્ષક પછી પુનરાવર્તન કરે છે. અને આ ઘણું નથી - કેટલીકવાર 40 લોકો સુધી. વિશ્વમાં કદાચ એવી ઘણી કંપનીઓ નથી કે જે આવા ઉપયોગના કેસનો સામનો કરે છે.

આગળ, હું તમને કહીશ કે અમે ચોક્કસ રૂપરેખા પરિમાણો કેવી રીતે અને શા માટે પસંદ કર્યા.

ચાલો શરૂઆતથી જ શરૂ કરીએ. ક્લસ્ટર પર ચાલવા માટે સ્પાર્ક પાસે 3 વિકલ્પો છે: સ્ટેન્ડઅલોન, મેસોસનો ઉપયોગ કરીને અને યાર્નનો ઉપયોગ કરીને. અમે ત્રીજો વિકલ્પ પસંદ કરવાનું નક્કી કર્યું કારણ કે તે અમને સમજાયું. અમારી પાસે પહેલેથી જ હૅડૂપ ક્લસ્ટર છે. અમારા સહભાગીઓ પહેલાથી જ તેના આર્કિટેક્ચરથી સારી રીતે પરિચિત છે. ચાલો યાર્નનો ઉપયોગ કરીએ.

spark.master=yarn

આગળ વધુ રસપ્રદ. આ 3 ડિપ્લોયમેન્ટ વિકલ્પોમાંના દરેકમાં 2 ડિપ્લોયમેન્ટ વિકલ્પો છે: ક્લાયન્ટ અને ક્લસ્ટર. આધારિત દસ્તાવેજીકરણ અને ઈન્ટરનેટ પરની વિવિધ લિંક્સ, અમે નિષ્કર્ષ પર આવી શકીએ છીએ કે ક્લાયંટ ઇન્ટરેક્ટિવ કાર્ય માટે યોગ્ય છે - ઉદાહરણ તરીકે, જ્યુપીટર નોટબુક દ્વારા, અને ક્લસ્ટર ઉત્પાદન ઉકેલો માટે વધુ યોગ્ય છે. અમારા કિસ્સામાં, અમને ઇન્ટરેક્ટિવ કાર્યમાં રસ હતો, તેથી:

spark.deploy-mode=client

સામાન્ય રીતે, હવેથી સ્પાર્ક કોઈક રીતે યાર્ન પર કામ કરશે, પરંતુ આ અમારા માટે પૂરતું ન હતું. અમારો પ્રોગ્રામ મોટા ડેટા વિશે હોવાથી, કેટલીકવાર સહભાગીઓ પાસે સંસાધનોની સમાન કાપણીના માળખામાં જે પ્રાપ્ત થયું હતું તે પૂરતું નહોતું. અને પછી અમને એક રસપ્રદ વસ્તુ મળી - ગતિશીલ સંસાધન ફાળવણી. ટૂંકમાં, મુદ્દો આ છે: જો તમારી પાસે મુશ્કેલ કાર્ય છે અને ક્લસ્ટર મફત છે (ઉદાહરણ તરીકે, સવારે), તો આ વિકલ્પનો ઉપયોગ કરીને સ્પાર્ક તમને વધારાના સંસાધનો આપી શકે છે. આવશ્યકતાની ગણતરી ત્યાં ઘડાયેલું સૂત્ર અનુસાર કરવામાં આવે છે. અમે વિગતોમાં જઈશું નહીં - તે સારી રીતે કાર્ય કરે છે.

spark.dynamicAllocation.enabled=true

અમે આ પરિમાણ સેટ કર્યું, અને સ્ટાર્ટઅપ પર સ્પાર્ક ક્રેશ થઈ ગયો અને શરૂ થયો નહીં. તે સાચું છે, કારણ કે મારે તે વાંચવું હતું દસ્તાવેજીકરણ વધુ કાળજીપૂર્વક. તે જણાવે છે કે બધું બરાબર થવા માટે, તમારે વધારાના પરિમાણને સક્ષમ કરવાની પણ જરૂર છે.

spark.shuffle.service.enabled=true

તેની શા માટે જરૂર છે? જ્યારે અમારા કામને હવે આટલા સંસાધનોની જરૂર નથી, ત્યારે સ્પાર્કે તેમને સામાન્ય પૂલ પર પાછા ફરવા જોઈએ. લગભગ કોઈપણ MapReduce કાર્યમાં સૌથી વધુ સમય લેતો તબક્કો શફલ સ્ટેજ છે. આ પરિમાણ તમને આ તબક્કે જનરેટ થયેલ ડેટાને સાચવવાની અને તે મુજબ એક્ઝિક્યુટર્સને મુક્ત કરવાની મંજૂરી આપે છે. અને વહીવટકર્તા એ પ્રક્રિયા છે જે કાર્યકર પરની દરેક વસ્તુની ગણતરી કરે છે. તેમાં ચોક્કસ સંખ્યામાં પ્રોસેસર કોરો અને ચોક્કસ માત્રામાં મેમરી છે.

આ પરિમાણ ઉમેરવામાં આવ્યું છે. બધું કામ લાગતું હતું. તે નોંધનીય બન્યું કે સહભાગીઓને જ્યારે તેમની જરૂર હોય ત્યારે ખરેખર વધુ સંસાધનો આપવામાં આવ્યા હતા. પરંતુ બીજી સમસ્યા ઊભી થઈ - અમુક સમયે અન્ય સહભાગીઓ જાગી ગયા અને સ્પાર્કનો ઉપયોગ કરવા માંગતા હતા, પરંતુ ત્યાં બધું જ વ્યસ્ત હતું, અને તેઓ નાખુશ હતા. તેઓ સમજી શકાય છે. અમે દસ્તાવેજો જોવાનું શરૂ કર્યું. તે બહાર આવ્યું છે કે ત્યાં અન્ય ઘણા પરિમાણો છે જેનો ઉપયોગ પ્રક્રિયાને પ્રભાવિત કરવા માટે થઈ શકે છે. ઉદાહરણ તરીકે, જો એક્ઝિક્યુટર સ્ટેન્ડબાય મોડમાં હોય, તો કેટલા સમય પછી તેમાંથી સંસાધનો લઈ શકાય?

spark.dynamicAllocation.executorIdleTimeout=120s

અમારા કિસ્સામાં, જો તમારા એક્ઝિક્યુટર્સ બે મિનિટ માટે કંઈ ન કરે, તો કૃપા કરીને તેમને સામાન્ય પૂલ પર પાછા ફરો. પરંતુ આ પરિમાણ હંમેશા પૂરતું ન હતું. તે સ્પષ્ટ હતું કે વ્યક્તિ લાંબા સમયથી કંઇ કરી રહ્યો ન હતો, અને સંસાધનો મુક્ત કરવામાં આવ્યા ન હતા. તે બહાર આવ્યું છે કે ત્યાં એક વિશેષ પરિમાણ પણ છે - કેશ્ડ ડેટા ધરાવતા એક્ઝિક્યુટર્સ પસંદ કરવા માટે કયા સમય પછી. મૂળભૂત રીતે, આ પરિમાણ અનંત હતું! અમે તેને સુધારી.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

એટલે કે, જો તમારા એક્ઝિક્યુટર્સ 5 મિનિટ સુધી કંઈ ન કરે, તો તેમને સામાન્ય પૂલમાં આપો. આ મોડમાં, મોટી સંખ્યામાં વપરાશકર્તાઓ માટે સંસાધનોને રિલીઝ કરવાની અને જારી કરવાની ઝડપ યોગ્ય બની છે. અસંતોષનું પ્રમાણ ઘટ્યું છે. પરંતુ અમે વધુ આગળ વધવાનું નક્કી કર્યું અને એપ્લિકેશન દીઠ એક્ઝિક્યુટર્સની મહત્તમ સંખ્યાને મર્યાદિત કરવાનું નક્કી કર્યું - આવશ્યકપણે પ્રોગ્રામ સહભાગી દીઠ.

spark.dynamicAllocation.maxExecutors=19

હવે, અલબત્ત, બીજી બાજુ અસંતુષ્ટ લોકો છે - "ક્લસ્ટર નિષ્ક્રિય છે, અને મારી પાસે ફક્ત 19 એક્ઝિક્યુટર્સ છે," પરંતુ તમે શું કરી શકો? અમને અમુક પ્રકારના યોગ્ય સંતુલનની જરૂર છે. તમે બધાને ખુશ કરી શકતા નથી.

અને અમારા કેસની વિશિષ્ટતાઓને લગતી એક વધુ નાની વાર્તા. કોઈક રીતે, ઘણા લોકો વ્યવહારિક પાઠ માટે મોડા પડ્યા હતા, અને કેટલાક કારણોસર સ્પાર્ક તેમના માટે શરૂ થયો ન હતો. અમે મફત સંસાધનોની માત્રા પર જોયું - તે ત્યાં હોવાનું જણાય છે. સ્પાર્ક શરૂ થવો જોઈએ. સદનસીબે, તે સમય સુધીમાં સબકોર્ટેક્સમાં દસ્તાવેજો પહેલેથી જ ક્યાંક ઉમેરવામાં આવ્યા હતા, અને અમને યાદ છે કે જ્યારે લોન્ચ કરવામાં આવે છે, ત્યારે સ્પાર્ક એક પોર્ટ શોધે છે કે જેના પર શરૂ કરવું. જો શ્રેણીમાં પ્રથમ પોર્ટ વ્યસ્ત છે, તો તે ક્રમમાં આગામી એક પર જાય છે. જો તે મફત છે, તો તે મેળવે છે. અને ત્યાં એક પરિમાણ છે જે આ માટેના પ્રયત્નોની મહત્તમ સંખ્યા સૂચવે છે. ડિફોલ્ટ 16 છે. આ સંખ્યા વર્ગમાં અમારા જૂથના લોકોની સંખ્યા કરતા ઓછી છે. તદનુસાર, 16 પ્રયાસો પછી, સ્પાર્કે હાર માની અને કહ્યું કે હું શરૂ કરી શકતો નથી. અમે આ સેટિંગ સુધારી છે.

spark.port.maxRetries=50

આગળ હું તમને કેટલીક સેટિંગ્સ વિશે કહીશ જે અમારા કેસની વિશિષ્ટતાઓ સાથે ખૂબ સંબંધિત નથી.

સ્પાર્કને ઝડપથી શરૂ કરવા માટે, SPARK_HOME હોમ ડિરેક્ટરીમાં સ્થિત જર્સ ફોલ્ડરને આર્કાઇવ કરીને HDFS પર મૂકવાની ભલામણ કરવામાં આવે છે. પછી તે કામદારો દ્વારા આ જાર્નિક્સ લોડ કરવામાં સમય બગાડે નહીં.

spark.yarn.archive=hdfs:///tmp/spark-archive.zip

ઝડપી કામગીરી માટે ક્રિઓનો સીરીયલાઇઝર તરીકે ઉપયોગ કરવાની પણ ભલામણ કરવામાં આવે છે. તે ડિફોલ્ટ કરતાં વધુ ઑપ્ટિમાઇઝ છે.

spark.serializer=org.apache.spark.serializer.KryoSerializer

અને સ્પાર્ક સાથે લાંબા સમયથી ચાલતી સમસ્યા પણ છે કે તે ઘણીવાર મેમરીમાંથી ક્રેશ થાય છે. મોટેભાગે આ તે ક્ષણે થાય છે જ્યારે કામદારોએ દરેક વસ્તુની ગણતરી કરી હોય છે અને પરિણામ ડ્રાઇવરને મોકલે છે. અમે આ પરિમાણને અમારા માટે મોટું બનાવ્યું છે. મૂળભૂત રીતે, તે 1GB છે, અમે તેને 3 બનાવ્યું છે.

spark.driver.maxResultSize=3072

અને છેલ્લે, ડેઝર્ટ તરીકે. HortonWorks વિતરણ - HDP 2.1 પર સંસ્કરણ 2.5.3.0 માં સ્પાર્કને કેવી રીતે અપડેટ કરવું. HDP ના આ સંસ્કરણમાં પ્રી-ઇન્સ્ટોલ કરેલ વર્ઝન 2.0 છે, પરંતુ અમે એકવાર જાતે નક્કી કર્યું કે સ્પાર્ક ખૂબ જ સક્રિય રીતે વિકાસ કરી રહ્યું છે, અને દરેક નવું સંસ્કરણ કેટલીક ભૂલોને સુધારે છે અને વધારાની સુવિધાઓ પ્રદાન કરે છે, જેમાં python API માટેનો સમાવેશ થાય છે, તેથી અમે નક્કી કર્યું, શું કરવાની જરૂર છે કરવું એ અપડેટ છે.

Hadoop 2.7 માટે સત્તાવાર વેબસાઇટ પરથી સંસ્કરણ ડાઉનલોડ કર્યું. તેને અનઝિપ કરો અને HDP ફોલ્ડરમાં મૂકો. અમે જરૂર મુજબ સિમલિંક ઇન્સ્ટોલ કર્યું છે. અમે તેને લોન્ચ કરીએ છીએ - તે શરૂ થતું નથી. ખૂબ જ અસ્પષ્ટ ભૂલ લખે છે.

java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig

ગૂગલિંગ કર્યા પછી, અમને જાણવા મળ્યું કે સ્પાર્કે Hadoop ના જન્મ સુધી રાહ ન જોવાનું નક્કી કર્યું, અને જર્સીના નવા સંસ્કરણનો ઉપયોગ કરવાનું નક્કી કર્યું. તેઓ પોતે જ જીરામાં આ વિષય વિશે એકબીજા સાથે દલીલ કરે છે. ઉકેલ ડાઉનલોડ કરવાનો હતો જર્સી સંસ્કરણ 1.17.1. આને 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 ઉકેલાયું નથી. ગૂગલિંગ કર્યા પછી, અમને એક ઉકેલ મળ્યો. તમારે અંબરીમાં યાર્ન સેટિંગ્સ પર જવાની જરૂર છે અને ત્યાં કસ્ટમ યાર્ન-સાઇટમાં પેરામીટર ઉમેરવાની જરૂર છે:

hdp.version=2.5.3.0-37

આ જાદુએ મદદ કરી, અને સ્પાર્ક ઉપડ્યો. અમે અમારા ઘણા જુપીટર લેપટોપનું પરીક્ષણ કર્યું. બધું કામ કરી રહ્યું છે. અમે શનિવારે (કાલે) પ્રથમ સ્પાર્ક પાઠ માટે તૈયાર છીએ!

યુપીડી. પાઠ દરમિયાન, બીજી સમસ્યા પ્રકાશમાં આવી. અમુક સમયે, યાર્નએ સ્પાર્ક માટે કન્ટેનર આપવાનું બંધ કર્યું. યાર્નમાં પેરામીટરને ઠીક કરવું જરૂરી હતું, જે મૂળભૂત રીતે 0.2 હતું:

yarn.scheduler.capacity.maximum-am-resource-percent=0.8

એટલે કે, સંસાધનોના વિતરણમાં માત્ર 20% સંસાધનોએ ભાગ લીધો હતો. પરિમાણો બદલ્યા પછી, અમે યાર્ન ફરીથી લોડ કર્યું. સમસ્યાનું નિરાકરણ કરવામાં આવ્યું હતું અને બાકીના સહભાગીઓ પણ સ્પાર્ક સંદર્ભ ચલાવવા માટે સક્ષમ હતા.

સોર્સ: www.habr.com