Habr, merhaba! Dün Rambler&Co'daki adamlardan, katılımcılardan bu aracın yapılandırılmasıyla ilgili oldukça fazla soru geldi. Biz de onun yolundan gitmeye ve deneyimlerimizi paylaşmaya karar verdik. Konu kolay değil - bu yüzden sizi yorumlarda deneyiminizi paylaşmaya davet ediyoruz, belki biz de yanlış bir şeyler anlayıp kullanıyoruz.
Spark'ı nasıl kullandığımıza dair küçük bir giriş. Üç aylık bir programımız var ve ikinci modül boyunca katılımcılarımız bu enstrüman üzerinde çalışıyor. Buna göre organizatörler olarak bizim görevimiz böyle bir durumda kümeyi kullanıma hazırlamaktır.
Kullanımımızın özelliği, Spark üzerinde aynı anda çalışan kişi sayısının tüm gruba eşit olabilmesidir. Mesela bir seminerde herkes aynı anda bir şeyler deneyip öğretmenimizin ardından tekrarlıyor. Ve bu çok fazla değil - bazen 40 kişiye kadar. Muhtemelen dünyada bu tür bir kullanım durumuyla karşı karşıya kalan çok fazla şirket yoktur.
Daha sonra size belirli yapılandırma parametrelerini nasıl ve neden seçtiğimizi anlatacağım.
En baştan başlayalım. Spark'ın bir kümede çalıştırılması için 3 seçeneği vardır: bağımsız, Mesos kullanma ve YARN kullanma. Bize mantıklı geldiği için üçüncü seçeneği tercih etmeye karar verdik. Zaten bir hadoop kümemiz var. Katılımcılarımız zaten mimarisini iyi biliyorlar. YARN kullanalım.
spark.master=yarnDaha da ilginç. Bu 3 dağıtım seçeneğinin her birinin 2 dağıtım seçeneği vardır: istemci ve küme. Temelli ve İnternet'teki çeşitli bağlantılardan, istemcinin etkileşimli çalışma için uygun olduğu sonucuna varabiliriz - örneğin jupyter dizüstü bilgisayar aracılığıyla ve kümenin üretim çözümleri için daha uygun olduğu. Bizim durumumuzda interaktif çalışmayla ilgileniyorduk, bu nedenle:
spark.deploy-mode=clientGenel olarak Spark bundan sonra bir şekilde YARN üzerinde çalışacak ama bu bizim için yeterli olmadı. Büyük veriyle ilgili bir programımız olduğu için bazen katılımcılar kaynakların eşit dağılımı çerçevesinde elde edilenlerden yeterince yararlanamıyorlardı. Ve sonra ilginç bir şey bulduk: dinamik kaynak tahsisi. Kısacası mesele şu: Zor bir göreviniz varsa ve küme boşsa (örneğin sabah), bu seçeneği kullanmak Spark size ek kaynaklar sağlayabilir. İhtiyaç orada kurnaz bir formüle göre hesaplanır. Ayrıntılara girmeyeceğiz; iyi çalışıyor.
spark.dynamicAllocation.enabled=trueBu parametreyi ayarladık ve başlangıçta Spark çöktü ve başlamadı. Aynen öyle çünkü okumam gerekiyordu daha dikkatli. Her şeyin yolunda olması için ek bir parametreyi de etkinleştirmeniz gerektiğini belirtiyor.
spark.shuffle.service.enabled=trueNeden gerekli? İşimiz artık çok fazla kaynağa ihtiyaç duymadığında Spark bunları ortak havuza geri göndermelidir. Hemen hemen tüm MapReduce görevlerinde en çok zaman harcayan aşama Karıştırma aşamasıdır. Bu parametre, bu aşamada oluşturulan verileri kaydetmenize ve uygulayıcıları buna göre serbest bırakmanıza olanak tanır. Ve uygulayıcı da işçi üzerindeki her şeyi hesaplayan süreçtir. Belirli sayıda işlemci çekirdeğine ve belirli miktarda belleğe sahiptir.
Bu parametre eklendi. Her şey işe yaramış gibi görünüyordu. Katılımcılara ihtiyaç duyduklarında aslında daha fazla kaynak verildiği fark edildi. Ancak başka bir sorun ortaya çıktı - bir noktada diğer katılımcılar da uyandı ve Spark'ı kullanmak istediler, ancak orada her şey meşguldü ve mutsuzlardı. Anlaşılabilirler. Belgeleri incelemeye başladık. Süreci etkilemek için kullanılabilecek bir dizi başka parametrenin olduğu ortaya çıktı. Örneğin, eğer uygulayıcı bekleme modundaysa, kaynaklar ne zaman ondan alınabilir?
spark.dynamicAllocation.executorIdleTimeout=120sBizim durumumuzda, eğer uygulayıcılarınız iki dakika boyunca hiçbir şey yapmazlarsa lütfen onları ortak havuza geri gönderin. Ancak bu parametre her zaman yeterli değildi. Kişinin uzun süredir hiçbir şey yapmadığı ve kaynakların serbest bırakılmadığı açıktı. Ayrıca özel bir parametrenin de olduğu ortaya çıktı - önbelleğe alınmış verileri içeren uygulayıcıların ne zaman seçileceği. Varsayılan olarak bu parametre sonsuzdu! Düzelttik.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sYani icracılarınız 5 dakika boyunca hiçbir şey yapmazsa ortak havuza verin. Bu modda, çok sayıda kullanıcı için kaynak yayınlama ve yayınlama hızı makul hale geldi. Hoşnutsuzluk miktarı azaldı. Ancak daha da ileri gitmeye ve başvuru başına, özellikle de program katılımcısı başına düşen maksimum uygulayıcı sayısını sınırlamaya karar verdik.
spark.dynamicAllocation.maxExecutors=19Şimdi diğer tarafta elbette memnun olmayan insanlar var - "küme boşta ve benim sadece 19 uygulayıcım var" ama ne yapabilirsiniz? Bir tür doğru dengeye ihtiyacımız var. Herkesi mutlu edemezsin.
Ve vakamızın ayrıntılarıyla ilgili küçük bir hikaye daha. Her nasılsa, birkaç kişi pratik derse geç kaldı ve bir nedenden dolayı Spark onlar için başlamadı. Ücretsiz kaynak miktarına baktık; öyle görünüyor. Kıvılcım başlamalı. Neyse ki, o zamana kadar belgeler zaten alt kortekse bir yere eklenmişti ve Spark'ın başlatıldığında başlamak için bir bağlantı noktası aradığını hatırladık. Aralıktaki ilk bağlantı noktası meşgulse sırayla bir sonraki bağlantı noktasına geçer. Ücretsizse yakalar. Ve bunun için maksimum deneme sayısını gösteren bir parametre var. Varsayılan 16'dır. Sayı, grubumuzdaki sınıftaki kişi sayısından azdır. Buna göre 16 denemeden sonra Spark pes etti ve başlayamayacağımı söyledi. Bu parametreyi düzelttik.
spark.port.maxRetries=50Daha sonra size durumumuzun özellikleriyle pek ilgili olmayan bazı ayarlardan bahsedeceğim.
Spark'ı daha hızlı başlatmak için SPARK_HOME ana dizininde bulunan jars klasörünün arşivlenmesi ve HDFS'ye yerleştirilmesi önerilir. O zaman bu jarnikleri işçiler tarafından yüklemekle zaman kaybetmeyecektir.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipDaha hızlı işlem için kryo'nun seri hale getirici olarak kullanılması da önerilir. Varsayılandan daha optimize edilmiştir.
spark.serializer=org.apache.spark.serializer.KryoSerializerAyrıca Spark'ta uzun süredir devam eden bir sorun da var: Sık sık bellekten çöküyor. Çoğu zaman bu, işçilerin her şeyi hesapladığı ve sonucu sürücüye gönderdiği anda gerçekleşir. Bu parametreyi kendimiz için büyüttük. Varsayılan olarak 1GB, biz 3 yaptık.
spark.driver.maxResultSize=3072Ve son olarak tatlı olarak. HortonWorks dağıtımında Spark 2.1 sürümüne nasıl güncellenir - HDP 2.5.3.0. HDP'nin bu sürümü önceden yüklenmiş bir sürüm 2.0 içerir, ancak bir zamanlar Spark'ın oldukça aktif bir şekilde geliştiğine ve her yeni sürümün bazı hataları düzelttiğine ve python API dahil olmak üzere ek özellikler sağladığına kendimiz karar verdik, bu yüzden ne yapılması gerektiğine karar verdik. yapılacak bir güncellemedir.
Hadoop 2.7 için resmi web sitesinden sürüm indirildi. Zipten çıkartıp HDP klasörüne atın. Sembolik bağlantıları gerektiği gibi kurduk. Başlatıyoruz - başlamıyor. Çok garip bir hata yazıyor.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigGoogle'da araştırdıktan sonra Spark'ın Hadoop doğana kadar beklemeyip formanın yeni versiyonunu kullanmaya karar verdiğini öğrendik. JIRA'da bu konu hakkında kendi aralarında tartışıyorlar. Çözüm indirmekti . Bunu SPARK_HOME'daki jars klasörüne yerleştirin, tekrar sıkıştırın ve HDFS'ye yükleyin.
Bu hatayı aştık ama yeni ve daha basit bir hata ortaya çıktı.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterAynı zamanda 2.0 sürümünü çalıştırmaya çalışıyoruz - her şey yolunda. Neler olduğunu tahmin etmeye çalışın. Bu uygulamanın günlüklerine baktık ve şunun gibi bir şey gördük:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarGenel olarak hdp.version bazı nedenlerden dolayı çözülmedi. Google'da arattıktan sonra bir çözüm bulduk. Ambari'deki YARN ayarlarına gitmeniz ve özel iplik sitesine bir parametre eklemeniz gerekir:
hdp.version=2.5.3.0-37Bu sihir işe yaradı ve Spark havalandı. Jüpyter dizüstü bilgisayarlarımızdan birkaçını test ettik. Her şey çalışıyor. Cumartesi (yarın) ilk Spark dersine hazırız!
UPD. Ders sırasında bir sorun daha ortaya çıktı. YARN bir noktada Spark'a konteyner sağlamayı bıraktı. YARN'da varsayılan olarak 0.2 olan parametrenin düzeltilmesi gerekiyordu:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8 Yani kaynakların dağıtımına kaynakların yalnızca %20'si katılmıştır. Parametreleri değiştirdikten sonra YARN'ı yeniden yükledik. Sorun çözüldü ve katılımcıların geri kalanı da spark bağlamını çalıştırabildi.
Kaynak: habr.com
