ຕັ້ງຄ່າ Spark ໃນ YARN

Habr, ສະບາຍດີ! ມື້ວານນີ້ ກອງປະຊຸມອຸທິດຕົນເພື່ອ Apache Spark, ຈາກ guys ຈາກ Rambler & Co, ມີຂ້ອນຂ້າງຫຼາຍຄໍາຖາມຈາກຜູ້ເຂົ້າຮ່ວມທີ່ກ່ຽວຂ້ອງກັບການຕັ້ງຄ່າເຄື່ອງມືນີ້. ພວກ​ເຮົາ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ເດີນ​ຕາມ​ຮອຍ​ຕີນ​ຂອງ​ພຣະ​ອົງ​ແລະ​ແບ່ງ​ປັນ​ປະ​ສົບ​ການ​ຂອງ​ພວກ​ເຮົາ. ຫົວຂໍ້ບໍ່ແມ່ນເລື່ອງງ່າຍ - ດັ່ງນັ້ນພວກເຮົາເຊີນທ່ານແບ່ງປັນປະສົບການຂອງທ່ານໃນຄໍາເຫັນ, ບາງທີພວກເຮົາຍັງເຂົ້າໃຈແລະໃຊ້ບາງສິ່ງບາງຢ່າງທີ່ຜິດພາດ.

ການແນະນໍາເລັກນ້ອຍກ່ຽວກັບວິທີທີ່ພວກເຮົາໃຊ້ Spark. ພວກເຮົາມີໂຄງການສາມເດືອນ "ຜູ້ຊ່ຽວຊານດ້ານຂໍ້ມູນໃຫຍ່", ແລະຕະຫຼອດໂມດູນທີສອງຜູ້ເຂົ້າຮ່ວມຂອງພວກເຮົາເຮັດວຽກກ່ຽວກັບເຄື່ອງມືນີ້. ດັ່ງນັ້ນ, ວຽກງານຂອງພວກເຮົາ, ໃນຖານະຜູ້ຈັດຕັ້ງ, ແມ່ນການກະກຽມກຸ່ມສໍາລັບການນໍາໃຊ້ພາຍໃນກໍລະນີດັ່ງກ່າວ.

peculiarity ຂອງການນໍາໃຊ້ຂອງພວກເຮົາແມ່ນວ່າຈໍານວນຂອງປະຊາຊົນພ້ອມໆກັນເຮັດວຽກກ່ຽວກັບ Spark ສາມາດເທົ່າກັບກຸ່ມທັງຫມົດ. ຕົວຢ່າງ, ໃນກອງປະຊຸມສໍາມະນາ, ເມື່ອທຸກຄົນພະຍາຍາມບາງສິ່ງບາງຢ່າງໃນເວລາດຽວກັນແລະເຮັດຊ້ໍາອີກຫຼັງຈາກຄູສອນຂອງພວກເຮົາ. ແລະນີ້ບໍ່ແມ່ນຫຼາຍ - ບາງຄັ້ງເຖິງ 40 ຄົນ. ອາດຈະບໍ່ມີບໍລິສັດຈໍານວນຫຼາຍໃນໂລກທີ່ປະເຊີນກັບກໍລະນີການນໍາໃຊ້ດັ່ງກ່າວ.

ຕໍ່ໄປ, ຂ້ອຍຈະບອກເຈົ້າວ່າແນວໃດແລະເປັນຫຍັງພວກເຮົາເລືອກຕົວກໍານົດການກໍາຫນົດຄ່າທີ່ແນ່ນອນ.

ໃຫ້ເລີ່ມຕົ້ນຈາກຈຸດເລີ່ມຕົ້ນ. Spark ມີ 3 ທາງ​ເລືອກ​ໃນ​ການ​ດໍາ​ເນີນ​ການ​ໃນ​ກຸ່ມ​: standalone​, ການ​ນໍາ​ໃຊ້ Mesos​, ແລະ​ການ​ນໍາ​ໃຊ້ YARN​. ພວກເຮົາຕັດສິນໃຈເລືອກທາງເລືອກທີສາມເພາະວ່າມັນມີຄວາມຫມາຍສໍາລັບພວກເຮົາ. ພວກເຮົາມີກຸ່ມ hadoop ແລ້ວ. ຜູ້ເຂົ້າຮ່ວມຂອງພວກເຮົາແມ່ນຮູ້ຈັກດີກັບສະຖາປັດຕະຍະກໍາຂອງມັນ. ໃຫ້ໃຊ້ YARN.

spark.master=yarn

ຫນ້າສົນໃຈຫຼາຍ. ແຕ່ລະຕົວເລືອກການນຳໃຊ້ 3 ອັນນີ້ມີ 2 ທາງເລືອກໃນການນຳໃຊ້: ລູກຄ້າ ແລະກຸ່ມ. ອີງ ເອກະສານ ແລະການເຊື່ອມຕໍ່ຕ່າງໆໃນອິນເຕີເນັດ, ພວກເຮົາສາມາດສະຫຼຸບໄດ້ວ່າລູກຄ້າແມ່ນເຫມາະສົມສໍາລັບການເຮັດວຽກແບບໂຕ້ຕອບ - ຕົວຢ່າງ, ໂດຍຜ່ານປື້ມບັນທຶກຂອງ jupyter, ແລະ cluster ແມ່ນເຫມາະສົມສໍາລັບການແກ້ໄຂການຜະລິດ. ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາມີຄວາມສົນໃຈໃນການເຮັດວຽກແບບໂຕ້ຕອບ, ດັ່ງນັ້ນ:

spark.deploy-mode=client

ໂດຍທົ່ວໄປແລ້ວ, ຈາກນີ້ Spark ຈະເຮັດວຽກຢູ່ໃນ YARN, ແຕ່ນີ້ບໍ່ພຽງພໍສໍາລັບພວກເຮົາ. ເນື່ອງຈາກພວກເຮົາມີໂຄງການກ່ຽວກັບຂໍ້ມູນໃຫຍ່, ບາງຄັ້ງຜູ້ເຂົ້າຮ່ວມບໍ່ມີພຽງພໍຂອງສິ່ງທີ່ໄດ້ຮັບໃນກອບຂອງຊັບພະຍາກອນທີ່ຕັດກັນ. ແລະຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ພົບເຫັນສິ່ງທີ່ຫນ້າສົນໃຈ - dynamic resource allocation . ໃນສັ້ນ, ຈຸດນີ້ແມ່ນ: ຖ້າທ່ານມີວຽກທີ່ມີຄວາມຫຍຸ້ງຍາກແລະກຸ່ມແມ່ນບໍ່ເສຍຄ່າ (ຕົວຢ່າງ, ໃນຕອນເຊົ້າ), ຫຼັງຈາກນັ້ນ, ການນໍາໃຊ້ທາງເລືອກນີ້ Spark ສາມາດໃຫ້ຊັບພະຍາກອນເພີ່ມເຕີມ. ຄວາມຈໍາເປັນໄດ້ຖືກຄິດໄລ່ຢູ່ທີ່ນັ້ນຕາມສູດທີ່ສະຫລາດ. ພວກເຮົາຈະບໍ່ເຂົ້າໄປໃນລາຍລະອຽດ - ມັນເຮັດວຽກໄດ້ດີ.

spark.dynamicAllocation.enabled=true

ພວກເຮົາກໍານົດພາລາມິເຕີນີ້, ແລະເມື່ອເລີ່ມຕົ້ນ Spark crashed ແລະບໍ່ໄດ້ເລີ່ມຕົ້ນ. ນັ້ນແມ່ນ, ເພາະວ່າຂ້ອຍຕ້ອງອ່ານມັນ ເອກະສານ ລະມັດລະວັງຫຼາຍຂຶ້ນ. ມັນລະບຸວ່າເພື່ອໃຫ້ທຸກສິ່ງທຸກຢ່າງບໍ່ເປັນຫຍັງ, ທ່ານກໍ່ຈໍາເປັນຕ້ອງເປີດໃຊ້ຕົວກໍານົດການເພີ່ມເຕີມ.

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 ຄວນເລີ່ມຕົ້ນ. ໂຊກດີ, ໃນເວລານັ້ນເອກະສານໄດ້ຖືກເພີ່ມເຂົ້າໄປໃນ subcortex ຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ, ແລະພວກເຮົາຈື່ໄດ້ວ່າເມື່ອເປີດຕົວ, Spark ຊອກຫາພອດທີ່ຈະເລີ່ມຕົ້ນ. ຖ້າພອດທໍາອິດໃນຂອບເຂດບໍ່ຫວ່າງ, ມັນຈະຍ້າຍໄປບ່ອນຕໍ່ໄປຕາມລໍາດັບ. ຖ້າມັນບໍ່ເສຍຄ່າ, ມັນຈັບ. ແລະມີພາລາມິເຕີທີ່ຊີ້ໃຫ້ເຫັນເຖິງຈໍານວນສູງສຸດຂອງຄວາມພະຍາຍາມສໍາລັບການນີ້. ຄ່າເລີ່ມຕົ້ນແມ່ນ 16. ຕົວເລກແມ່ນຫນ້ອຍກວ່າຈໍານວນຄົນໃນກຸ່ມຂອງພວກເຮົາໃນຫ້ອງຮຽນ. ດັ່ງນັ້ນ, ຫຼັງຈາກ 16 ຄວາມພະຍາຍາມ, Spark ໄດ້ຍອມແພ້ແລະເວົ້າວ່າຂ້ອຍບໍ່ສາມາດເລີ່ມຕົ້ນໄດ້. ພວກເຮົາໄດ້ແກ້ໄຂພາລາມິເຕີນີ້ແລ້ວ.

spark.port.maxRetries=50

ຕໍ່ໄປຂ້າພະເຈົ້າຈະບອກທ່ານກ່ຽວກັບການຕັ້ງຄ່າບາງຢ່າງທີ່ບໍ່ກ່ຽວຂ້ອງກັບສະເພາະຂອງກໍລະນີຂອງພວກເຮົາ.

ເພື່ອເລີ່ມຕົ້ນ Spark ໄດ້ໄວຂຶ້ນ, ແນະນຳໃຫ້ເກັບໂຟນເດີ jars ທີ່ຕັ້ງຢູ່ໃນ SPARK_HOME home directory ແລ້ວໃສ່ໃນ HDFS. ຫຼັງຈາກນັ້ນ, ລາວຈະບໍ່ເສຍເວລາໃນການໂຫຼດກະປ໋ອງເຫຼົ່ານີ້ໂດຍຄົນງານ.

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

ມັນຍັງແນະນໍາໃຫ້ໃຊ້ kryo ເປັນ serializer ສໍາລັບການດໍາເນີນງານໄວຂຶ້ນ. ມັນຖືກປັບປຸງໃຫ້ດີທີ່ສຸດກ່ວາຄ່າເລີ່ມຕົ້ນ.

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

ແລະຍັງມີບັນຫາທີ່ຍາວນານກັບ Spark ທີ່ມັນມັກຈະຂັດຈາກຄວາມຊົງຈໍາ. ເລື້ອຍໆນີ້ເກີດຂື້ນໃນເວລາທີ່ຄົນງານໄດ້ຄິດໄລ່ທຸກຢ່າງແລະສົ່ງຜົນໃຫ້ຜູ້ຂັບຂີ່. ພວກເຮົາເຮັດໃຫ້ພາລາມິເຕີນີ້ໃຫຍ່ຂຶ້ນສໍາລັບຕົວເຮົາເອງ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ມັນແມ່ນ 1GB, ພວກເຮົາເຮັດໃຫ້ມັນ 3.

spark.driver.maxResultSize=3072

ແລະສຸດທ້າຍ, ເປັນ dessert. ວິທີການອັບເດດ Spark ເປັນເວີຊັນ 2.1 ກ່ຽວກັບການແຈກຢາຍ HortonWorks - HDP 2.5.3.0. ສະບັບນີ້ຂອງ HDP ປະກອບດ້ວຍເວີຊັນ 2.0 ທີ່ຕິດຕັ້ງໄວ້ກ່ອນ, ແຕ່ພວກເຮົາໄດ້ຕັດສິນໃຈສໍາລັບຕົວເຮົາເອງວ່າ Spark ກໍາລັງພັດທະນາຢ່າງຫ້າວຫັນ, ແລະແຕ່ລະຮຸ່ນໃຫມ່ແກ້ໄຂບາງຂໍ້ບົກພ່ອງບວກກັບຄຸນສົມບັດເພີ່ມເຕີມ, ລວມທັງສໍາລັບ python API, ດັ່ງນັ້ນພວກເຮົາໄດ້ຕັດສິນໃຈ, ສິ່ງທີ່ຕ້ອງການ. ເຮັດແມ່ນການປັບປຸງ.

ດາວໂຫລດເວີຊັນຈາກເວັບໄຊທ໌ທາງການສໍາລັບ Hadoop 2.7. Unzipped ມັນແລະເອົາໃສ່ໃນໂຟນເດີ HDP. ພວກເຮົາຕິດຕັ້ງ symlinks ຕາມຄວາມຕ້ອງການ. ພວກເຮົາເປີດຕົວມັນ - ມັນບໍ່ໄດ້ເລີ່ມຕົ້ນ. ຂຽນຂໍ້ຜິດພາດທີ່ແປກປະຫຼາດຫຼາຍ.

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

ຫຼັງຈາກ googling, ພວກເຮົາພົບວ່າ Spark ຕັດສິນໃຈບໍ່ລໍຖ້າຈົນກ່ວາ Hadoop ເກີດ, ແລະຕັດສິນໃຈໃຊ້ jersey ຮຸ່ນໃຫມ່. ພວກເຂົາເອງໂຕ້ຖຽງກັນກ່ຽວກັບຫົວຂໍ້ນີ້ໃນ JIRA. ການແກ້ໄຂແມ່ນເພື່ອດາວໂຫລດ jersey ລຸ້ນ 1.17.1. ວາງອັນນີ້ໄວ້ໃນໂຟນເດີ jars ໃນ 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 ບໍ່ໄດ້ແກ້ໄຂ. ຫຼັງຈາກ google, ພວກເຮົາພົບເຫັນວິທີແກ້ໄຂ. ທ່ານຈໍາເປັນຕ້ອງໄປທີ່ການຕັ້ງຄ່າ YARN ໃນ Ambari ແລະເພີ່ມພາລາມິເຕີຢູ່ທີ່ນັ້ນເພື່ອກໍານົດເອງ yarn-site:

hdp.version=2.5.3.0-37

magic ນີ້ຊ່ວຍໄດ້, ແລະ Spark ເອົາໄປ. ພວກເຮົາໄດ້ທົດສອບໂນດບຸກ jupyter ຂອງພວກເຮົາຫຼາຍໜ່ວຍ. ທຸກສິ່ງທຸກຢ່າງແມ່ນເຮັດວຽກ. ພວກເຮົາກຽມພ້ອມສໍາລັບບົດຮຽນ Spark ທໍາອິດໃນວັນເສົາ (ມື້ອື່ນ)!

DUP. ໃນ​ລະ​ຫວ່າງ​ບົດ​ຮຽນ​, ບັນ​ຫາ​ຫນຶ່ງ​ໄດ້​ເກີດ​ຂຶ້ນ​. ໃນບາງຈຸດ, YARN ຢຸດເຊົາການສະຫນອງບັນຈຸສໍາລັບ Spark. ໃນ YARN ມັນຈໍາເປັນຕ້ອງແກ້ໄຂພາລາມິເຕີ, ເຊິ່ງໂດຍຄ່າເລີ່ມຕົ້ນແມ່ນ 0.2:

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

ນັ້ນແມ່ນ, ມີພຽງແຕ່ 20% ຂອງຊັບພະຍາກອນທີ່ເຂົ້າຮ່ວມໃນການແຈກຢາຍຊັບພະຍາກອນ. ຫຼັງຈາກການປ່ຽນແປງພາລາມິເຕີ, ພວກເຮົາໂຫຼດ YARN ຄືນໃໝ່. ບັນຫາໄດ້ຖືກແກ້ໄຂແລະສ່ວນທີ່ເຫຼືອຂອງຜູ້ເຂົ້າຮ່ວມຍັງສາມາດດໍາເນີນການ spark context.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com