Habr, hello! Semalam pada , daripada rakan-rakan dari Rambler&Co, terdapat banyak soalan daripada peserta yang berkaitan dengan mengkonfigurasi alat ini. Kami memutuskan untuk mengikuti jejaknya dan berkongsi pengalaman kami. Topiknya tidak mudah - jadi kami menjemput anda untuk berkongsi pengalaman anda dalam ulasan, mungkin kami juga memahami dan menggunakan sesuatu yang salah.
Sedikit pengenalan tentang cara kami menggunakan Spark. Kami ada program tiga bulan , dan sepanjang modul kedua peserta kami mengusahakan instrumen ini. Sehubungan itu, tugas kami, sebagai penganjur, adalah menyediakan kluster untuk digunakan dalam kes sedemikian.
Keistimewaan penggunaan kami ialah bilangan orang yang bekerja pada Spark secara serentak boleh sama dengan keseluruhan kumpulan. Sebagai contoh, di seminar, apabila semua orang mencuba sesuatu pada masa yang sama dan mengulangi selepas guru kita. Dan ini tidak banyak - kadang-kadang sehingga 40 orang. Mungkin tidak banyak syarikat di dunia yang menghadapi kes penggunaan sedemikian.
Seterusnya, saya akan memberitahu anda bagaimana dan mengapa kami memilih parameter konfigurasi tertentu.
Mari kita mulakan dari awal lagi. Spark mempunyai 3 pilihan untuk dijalankan pada kelompok: berdiri sendiri, menggunakan Mesos dan menggunakan BENANG. Kami memutuskan untuk memilih pilihan ketiga kerana ia masuk akal kepada kami. Kami sudah mempunyai kluster hadoop. Peserta kami sudah pun mengenali seni binanya. Jom guna BENANG.
spark.master=yarnLebih menarik lagi. Setiap satu daripada 3 pilihan penggunaan ini mempunyai 2 pilihan penggunaan: klien dan kelompok. berdasarkan dan pelbagai pautan di Internet, kita boleh membuat kesimpulan bahawa pelanggan sesuai untuk kerja interaktif - contohnya, melalui buku nota jupyter, dan kluster lebih sesuai untuk penyelesaian pengeluaran. Dalam kes kami, kami berminat dengan kerja interaktif, oleh itu:
spark.deploy-mode=clientSecara umum, mulai sekarang Spark entah bagaimana akan berfungsi pada BENANG, tetapi ini tidak mencukupi untuk kami. Memandangkan kami mempunyai program tentang data besar, kadangkala para peserta tidak cukup dengan apa yang diperoleh dalam rangka kerja penghirisan sumber yang sekata. Dan kemudian kami menemui satu perkara yang menarik - peruntukan sumber dinamik. Ringkasnya, perkara ini ialah: jika anda mempunyai tugas yang sukar dan kluster itu percuma (contohnya, pada waktu pagi), maka menggunakan pilihan ini Spark boleh memberi anda sumber tambahan. Keperluan dikira di sana mengikut formula yang licik. Kami tidak akan pergi ke butiran - ia berfungsi dengan baik.
spark.dynamicAllocation.enabled=trueKami menetapkan parameter ini, dan apabila permulaan Spark ranap dan tidak bermula. Betul, kerana saya terpaksa membacanya lebih berhati-hati. Ia menyatakan bahawa untuk semuanya menjadi ok, anda juga perlu mendayakan parameter tambahan.
spark.shuffle.service.enabled=trueMengapa ia diperlukan? Apabila tugas kita tidak lagi memerlukan begitu banyak sumber, Spark harus mengembalikannya ke kumpulan biasa. Peringkat yang paling memakan masa dalam hampir semua tugasan MapReduce ialah peringkat Kocok. Parameter ini membolehkan anda menyimpan data yang dijana pada peringkat ini dan melepaskan pelaksana dengan sewajarnya. Dan pelaksana adalah proses yang mengira segala-galanya pada pekerja. Ia mempunyai bilangan teras pemproses tertentu dan jumlah memori tertentu.
Parameter ini telah ditambah. Segala-galanya seolah-olah berfungsi. Ia menjadi ketara bahawa peserta sebenarnya diberi lebih banyak sumber apabila mereka memerlukannya. Tetapi masalah lain timbul - pada satu ketika peserta lain bangun dan juga ingin menggunakan Spark, tetapi semuanya sibuk di sana, dan mereka tidak berpuas hati. Mereka boleh difahami. Kami mula melihat dokumentasi. Ternyata terdapat beberapa parameter lain yang boleh digunakan untuk mempengaruhi proses tersebut. Sebagai contoh, jika pelaksana berada dalam mod siap sedia, selepas masa berapakah sumber boleh diambil daripadanya?
spark.dynamicAllocation.executorIdleTimeout=120sDalam kes kami, jika pelaksana anda tidak melakukan apa-apa selama dua minit, sila kembalikan mereka ke kumpulan biasa. Tetapi parameter ini tidak selalu mencukupi. Adalah jelas bahawa orang itu telah lama tidak melakukan apa-apa, dan sumber tidak dibebaskan. Ternyata terdapat juga parameter khas - selepas masa untuk memilih pelaksana yang mengandungi data cache. Secara lalai, parameter ini ialah infiniti! Kami membetulkannya.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sIaitu, jika pelaksana anda tidak melakukan apa-apa selama 5 minit, berikan mereka kepada kumpulan biasa. Dalam mod ini, kelajuan mengeluarkan dan mengeluarkan sumber untuk sejumlah besar pengguna telah menjadi baik. Jumlah rasa tidak puas hati telah berkurangan. Tetapi kami memutuskan untuk pergi lebih jauh dan mengehadkan bilangan maksimum pelaksana bagi setiap permohonan - pada asasnya setiap peserta program.
spark.dynamicAllocation.maxExecutors=19Kini, sudah tentu, terdapat orang yang tidak berpuas hati di pihak yang lain - "kelompok itu terbiar, dan saya hanya mempunyai 19 pelaksana," tetapi apa yang boleh anda lakukan? Kami memerlukan semacam keseimbangan yang betul. Anda tidak boleh membuat semua orang gembira.
Dan satu lagi cerita kecil yang berkaitan dengan spesifik kes kami. Entah bagaimana, beberapa orang telah lewat untuk pelajaran praktikal, dan atas sebab tertentu Spark tidak bermula untuk mereka. Kami melihat jumlah sumber percuma - nampaknya ada. Percikan harus bermula. Nasib baik, pada masa itu dokumentasi telah ditambahkan ke subkorteks di suatu tempat, dan kami teringat bahawa apabila dilancarkan, Spark mencari pelabuhan untuk dimulakan. Jika port pertama dalam julat sibuk, ia bergerak ke port seterusnya mengikut urutan. Jika ia percuma, ia menangkap. Dan terdapat parameter yang menunjukkan bilangan maksimum percubaan untuk ini. Lalai ialah 16. Bilangan itu kurang daripada bilangan orang dalam kumpulan kami dalam kelas. Oleh itu, selepas 16 percubaan, Spark menyerah dan berkata bahawa saya tidak boleh bermula. Kami telah membetulkan tetapan ini.
spark.port.maxRetries=50Seterusnya saya akan memberitahu anda tentang beberapa tetapan yang tidak begitu berkaitan dengan spesifik kes kami.
Untuk memulakan Spark dengan lebih pantas, adalah disyorkan untuk mengarkibkan folder jars yang terletak dalam direktori utama SPARK_HOME dan meletakkannya pada HDFS. Kemudian dia tidak akan membuang masa memuatkan jarnik ini oleh pekerja.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipIa juga disyorkan untuk menggunakan kryo sebagai serializer untuk operasi yang lebih pantas. Ia lebih dioptimumkan daripada yang lalai.
spark.serializer=org.apache.spark.serializer.KryoSerializerDan terdapat juga masalah lama dengan Spark yang sering ranap dari ingatan. Selalunya ini berlaku pada masa ini apabila pekerja telah mengira segala-galanya dan menghantar hasilnya kepada pemandu. Kami menjadikan parameter ini lebih besar untuk diri kami sendiri. Secara lalai, ia adalah 1GB, kami menjadikannya 3.
spark.driver.maxResultSize=3072Dan terakhir, sebagai pencuci mulut. Cara mengemas kini Spark kepada versi 2.1 pada pengedaran HortonWorks - HDP 2.5.3.0. Versi HDP ini mengandungi versi prapasang 2.0, tetapi kami pernah memutuskan sendiri bahawa Spark sedang membangun dengan agak aktif, dan setiap versi baharu membetulkan beberapa pepijat serta menyediakan ciri tambahan, termasuk untuk API python, jadi kami memutuskan , perkara yang perlu dilakukan adalah kemas kini.
Memuat turun versi dari laman web rasmi untuk Hadoop 2.7. Buka zip dan masukkan ke dalam folder HDP. Kami memasang symlinks seperti yang diperlukan. Kami melancarkannya - ia tidak bermula. Menulis ralat yang sangat tidak jelas.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigSelepas googling, kami mendapati bahawa Spark memutuskan untuk tidak menunggu sehingga Hadoop dilahirkan, dan memutuskan untuk menggunakan versi baharu jersi. Mereka sendiri berbalah sesama sendiri tentang topik ini dalam JIRA. Penyelesaiannya ialah memuat turun . Letakkan ini dalam folder balang dalam SPARK_HOME, zip sekali lagi dan muat naik ke HDFS.
Kami berjaya mengatasi ralat ini, tetapi ralat baharu dan agak diperkemas timbul.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterPada masa yang sama, kami cuba menjalankan versi 2.0 - semuanya ok. Cuba teka apa yang berlaku. Kami melihat ke dalam log aplikasi ini dan melihat sesuatu seperti ini:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarSecara umum, atas sebab tertentu hdp.version tidak dapat diselesaikan. Selepas googling, kami menemui penyelesaian. Anda perlu pergi ke tetapan BENANG di Ambari dan tambahkan parameter di sana pada tapak benang tersuai:
hdp.version=2.5.3.0-37Sihir ini membantu, dan Spark berlepas. Kami menguji beberapa komputer riba jupyter kami. Semuanya berfungsi. Kami bersedia untuk pelajaran Spark pertama pada hari Sabtu (esok)!
DUP. Semasa pelajaran, satu lagi masalah terbongkar. Pada satu ketika, YARN berhenti menyediakan bekas untuk Spark. Dalam YARN adalah perlu untuk membetulkan parameter, yang secara lalai ialah 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Iaitu, hanya 20% daripada sumber yang mengambil bahagian dalam pengagihan sumber. Selepas menukar parameter, kami memuat semula BENANG. Masalah itu telah diselesaikan dan peserta yang lain juga dapat menjalankan konteks percikan api.
Sumber: www.habr.com
