Sber.DS ເປັນແພລະຕະຟອມທີ່ຊ່ວຍໃຫ້ທ່ານສ້າງແລະປະຕິບັດຕົວແບບເຖິງແມ່ນວ່າບໍ່ມີລະຫັດ

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

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

ທີມງານຂອງພວກເຮົາກໍາລັງພັດທະນາເວທີ Sber.DS. ມັນຊ່ວຍໃຫ້ທ່ານສາມາດແກ້ໄຂບັນຫາການຮຽນຮູ້ເຄື່ອງຈັກ, ເລັ່ງຂະບວນການຂອງການທົດສອບ hypotheses, ໃນຫຼັກການເຮັດໃຫ້ຂະບວນການພັດທະນາແລະການກວດສອບຕົວແບບງ່າຍດາຍ, ແລະຍັງຄວບຄຸມຜົນໄດ້ຮັບຂອງຕົວແບບໃນ PROM.

ໃນຄໍາສັ່ງທີ່ຈະບໍ່ຫລອກລວງຄວາມຄາດຫວັງຂອງທ່ານ, ຂ້າພະເຈົ້າຕ້ອງການບອກລ່ວງຫນ້າວ່າຂໍ້ຄວາມນີ້ແມ່ນການແນະນໍາ, ແລະພາຍໃຕ້ການຕັດ, ສໍາລັບການເລີ່ມຕົ້ນ, ມັນໄດ້ຖືກບອກກ່ຽວກັບສິ່ງທີ່ເປັນພື້ນຖານພາຍໃຕ້ hood ຂອງເວທີ Sber.DS. ພວກເຮົາຈະບອກເລື່ອງກ່ຽວກັບວົງຈອນຊີວິດຂອງຕົວແບບຈາກການສ້າງໄປສູ່ການປະຕິບັດແຍກຕ່າງຫາກ.

Sber.DS ປະ​ກອບ​ດ້ວຍ​ອົງ​ປະ​ກອບ​ຈໍາ​ນວນ​ຫນຶ່ງ​, ສິ່ງ​ສໍາ​ຄັນ​ແມ່ນ​ຫ້ອງ​ສະ​ຫມຸດ​, ລະ​ບົບ​ການ​ພັດ​ທະ​ນາ​, ແລະ​ລະ​ບົບ​ປະ​ຕິ​ບັດ​ຕົວ​ແບບ​.

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

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

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

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

ຖ້າຄວາມສາມາດໃນຕົວບໍ່ພຽງພໍ, ຫຼັງຈາກນັ້ນລະບົບສະຫນອງຄວາມສາມາດໃນການສ້າງໂມດູນຂອງທ່ານເອງຢ່າງໄວວາ. ພວກເຮົາໄດ້ສ້າງຮູບແບບການພັດທະນາແບບປະສົມປະສານໂດຍອີງໃສ່ Jupyter Kernel Gateway ສໍາລັບຜູ້ທີ່ສ້າງໂມດູນໃຫມ່ຈາກ scratch.

ສະຖາປັດຕະຍະກໍາ Sber.DS ຖືກສ້າງຂຶ້ນໃນ microservices. ມີຄວາມຄິດເຫັນຫຼາຍກ່ຽວກັບສິ່ງທີ່ microservices ແມ່ນຫຍັງ. ບາງຄົນຄິດວ່າມັນພຽງພໍທີ່ຈະແບ່ງປັນລະຫັດ monolithic ເປັນສ່ວນ, ແຕ່ພວກເຂົາຍັງໄປຫາຖານຂໍ້ມູນດຽວກັນ. microservice ຂອງພວກເຮົາຕ້ອງຕິດຕໍ່ສື່ສານກັບ microservice ອື່ນຜ່ານ REST API ເທົ່ານັ້ນ. ບໍ່ມີການແກ້ໄຂສໍາລັບການເຂົ້າເຖິງຖານຂໍ້ມູນໂດຍກົງ.

ພວກເຮົາພະຍາຍາມຮັກສາການບໍລິການບໍ່ໃຫ້ມີຂະຫນາດໃຫຍ່ແລະຊ້າຫຼາຍ: ຕົວຢ່າງດຽວບໍ່ຄວນໃຊ້ RAM ຫຼາຍກວ່າ 4-8 gigabyte ແລະຄວນຈະສາມາດຂະຫຍາຍການຮ້ອງຂໍຕາມແນວນອນໂດຍການເປີດຕົວຕົວຢ່າງໃຫມ່. ແຕ່ລະບໍລິການຕິດຕໍ່ສື່ສານກັບຜູ້ອື່ນຜ່ານ REST API (ເປີດ API). ທີມງານທີ່ຮັບຜິດຊອບສໍາລັບການບໍລິການແມ່ນຕ້ອງການເພື່ອຮັກສາ API ກັບຄືນໄປບ່ອນເຂົ້າກັນໄດ້ຈົນກ່ວາລູກຄ້າສຸດທ້າຍທີ່ໃຊ້ມັນ.

ຫຼັກຂອງຄໍາຮ້ອງສະຫມັກແມ່ນຂຽນໃນ Java ໂດຍໃຊ້ Spring Framework. ການແກ້ໄຂໄດ້ຖືກອອກແບບໃນເບື້ອງຕົ້ນສໍາລັບການນໍາໃຊ້ຢ່າງໄວວາໃນໂຄງສ້າງພື້ນຖານຂອງເມຄ, ດັ່ງນັ້ນຄໍາຮ້ອງສະຫມັກໄດ້ຖືກສ້າງຂື້ນໂດຍໃຊ້ລະບົບບັນຈຸບັນຈຸ. RedHat OpenShift (Kubernetes). ແພລະຕະຟອມພັດທະນາຢ່າງຕໍ່ເນື່ອງ, ທັງໃນແງ່ຂອງການເພີ່ມປະສິດທິພາບຂອງທຸລະກິດ (ຕົວເຊື່ອມຕໍ່ໃຫມ່, AutoML ຖືກເພີ່ມ), ແລະໃນແງ່ຂອງປະສິດທິພາບທາງດ້ານເຕັກໂນໂລຢີ.

ຫນຶ່ງໃນ "ຊິບ" ຂອງເວທີຂອງພວກເຮົາແມ່ນວ່າພວກເຮົາສາມາດດໍາເນີນການລະຫັດທີ່ພັດທະນາໃນການໂຕ້ຕອບສາຍຕາໃນລະບົບການປະຕິບັດແບບຈໍາລອງ Sberbank ໃດ. ໃນປັດຈຸບັນມີສອງຂອງພວກເຂົາແລ້ວ: ຫນຶ່ງຢູ່ໃນ Hadoop, ອີກອັນຫນຶ່ງຢູ່ໃນ OpenShift (Docker). ພວກເຮົາບໍ່ຢຸດຢູ່ທີ່ນັ້ນ ແລະສ້າງໂມດູນການລວມເຂົ້າກັນເພື່ອແລ່ນລະຫັດໃນໂຄງສ້າງພື້ນຖານໃດໆ, ລວມທັງຢູ່ໃນສະຖານທີ່ ແລະໃນຄລາວ. ໃນແງ່ຂອງຄວາມເປັນໄປໄດ້ສໍາລັບການເຊື່ອມໂຍງທີ່ມີປະສິດທິພາບໃນລະບົບນິເວດ Sberbank, ພວກເຮົາຍັງວາງແຜນທີ່ຈະສະຫນັບສະຫນູນການເຮັດວຽກກັບສະພາບແວດລ້ອມ runtime ທີ່ມີຢູ່ແລ້ວ. ໃນ​ອະ​ນາ​ຄົດ, ການ​ແກ້​ໄຂ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ປະ​ສົມ​ປະ​ສານ "ນອກ​ປ່ອງ​" ການ​ປ່ຽນ​ແປງ​ໃນ​ພູມ​ສັນ​ຖານ​ຂອງ​ອົງ​ການ​ຈັດ​ຕັ້ງ​ໃດ​ຫນຶ່ງ.

ຜູ້ທີ່ເຄີຍພະຍາຍາມຮັກສາການແກ້ໄຂທີ່ດໍາເນີນການ Python ໃນ Hadoop ໃນ PROM ຮູ້ວ່າມັນບໍ່ພຽງພໍໃນການກະກຽມແລະສົ່ງສະພາບແວດລ້ອມ python ທີ່ກໍາຫນົດເອງໃຫ້ກັບແຕ່ລະ datanode. ຈໍານວນຂະຫນາດໃຫຍ່ຂອງຫ້ອງສະຫມຸດ C / C ++ ສໍາລັບການຮຽນຮູ້ເຄື່ອງຈັກທີ່ໃຊ້ໂມດູນ Python ຈະບໍ່ໃຫ້ທ່ານພັກຜ່ອນໃນຄວາມສະຫງົບ. ພວກເຮົາຕ້ອງບໍ່ລືມທີ່ຈະອັບເດດແພັກເກດເມື່ອເພີ່ມຫ້ອງສະໝຸດ ຫຼືເຊີບເວີໃໝ່, ໃນຂະນະທີ່ຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບລະຫັດຕົວແບບທີ່ນຳໃຊ້ແລ້ວ.

ມີຫຼາຍວິທີທີ່ຈະເຮັດແນວນີ້. ຕົວຢ່າງ, ກະກຽມຫ້ອງສະຫມຸດທີ່ໃຊ້ເລື້ອຍໆຫຼາຍໆຄັ້ງລ່ວງຫນ້າແລະປະຕິບັດໃນ PROM. ການແຈກຢາຍ Hadoop ຂອງ Cloudera ປົກກະຕິແລ້ວໃຊ້ ພັສດຸ. ນອກຈາກນີ້ໃນປັດຈຸບັນໃນ Hadoop ມີໂອກາດທີ່ຈະດໍາເນີນການໄດ້ docker- ບັນຈຸ. ໃນບາງກໍລະນີທີ່ງ່າຍດາຍມັນເປັນໄປໄດ້ທີ່ຈະສົ່ງລະຫັດພ້ອມກັບຊຸດ python.ໄຂ່.

ທະນາຄານຖືຄວາມປອດໄພຂອງການແລ່ນລະຫັດພາກສ່ວນທີສາມຢ່າງຈິງຈັງ, ດັ່ງນັ້ນພວກເຮົາໃຊ້ປະໂຫຍດສູງສຸດຈາກລັກສະນະໃຫມ່ຂອງ Linux kernel, ບ່ອນທີ່ຂະບວນການເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມທີ່ໂດດດ່ຽວ. Linux namespace, ທ່ານສາມາດຈໍາກັດ, ສໍາລັບຕົວຢ່າງ, ການເຂົ້າເຖິງເຄືອຂ່າຍແລະແຜ່ນທ້ອງຖິ່ນ, ເຊິ່ງຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຄວາມເປັນໄປໄດ້ຂອງລະຫັດອັນຕະລາຍ. ພື້ນທີ່ຂໍ້ມູນຂອງແຕ່ລະພະແນກແມ່ນໄດ້ຮັບການປົກປ້ອງ ແລະມີພຽງແຕ່ເຈົ້າຂອງຂໍ້ມູນນັ້ນເທົ່ານັ້ນ. ແພລະຕະຟອມຮັບປະກັນວ່າຂໍ້ມູນຈາກໂດເມນຫນຶ່ງພຽງແຕ່ສາມາດເຂົ້າໄປໃນໂດເມນອື່ນຜ່ານຂະບວນການເຜີຍແຜ່ຂໍ້ມູນທີ່ມີການຄວບຄຸມໃນທຸກຂັ້ນຕອນຈາກການເຂົ້າເຖິງແຫຼ່ງໄປຫາຂໍ້ມູນທີ່ດິນໃນ mart ເປົ້າຫມາຍ.

ປີນີ້ພວກເຮົາວາງແຜນທີ່ຈະເຮັດສໍາເລັດ MVP ຂອງແບບແລ່ນທີ່ຂຽນໃນ Python/R/Java ໃນ Hadoop. ພວກເຮົາຕັ້ງຕົວເອງເປັນວຽກງານທີ່ມີຄວາມທະເຍີທະຍານຂອງການຮຽນຮູ້ວິທີການດໍາເນີນການສະພາບແວດລ້ອມຂອງຜູ້ໃຊ້ໃດໆໃນ Hadoop, ເພື່ອບໍ່ໃຫ້ຈໍາກັດຜູ້ໃຊ້ຂອງເວທີຂອງພວກເຮົາໃນທາງໃດກໍ່ຕາມ.

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

ພວກເຮົາມີຄົນທີ່ມີຄວາມຮູ້ໃນຂົງເຂດຕ່າງໆ: Linux ແລະ DevOps, Hadoop ແລະ Spark, Java ແລະ Spring, Scala ແລະ Akka, OpenShift ແລະ Kubernetes. ໃນຄັ້ງຕໍ່ໄປພວກເຮົາຈະສົນທະນາກ່ຽວກັບຫ້ອງສະຫມຸດຂອງຕົວແບບ, ວິທີການຂອງຕົວແບບຜ່ານວົງຈອນຊີວິດພາຍໃນບໍລິສັດ, ວິທີການກວດສອບແລະການປະຕິບັດ.

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