ພວກເຮົາຈັດຕັ້ງ DataLake ທີ່ມີປະສິດທິພາບສູງ ແລະລາຄາຖືກແນວໃດ ແລະເປັນຫຍັງຄືແນວນີ້

ພວກເຮົາອາໄສຢູ່ໃນໄລຍະເວລາທີ່ຫນ້າອັດສະຈັນທີ່ທ່ານສາມາດເຊື່ອມຕໍ່ໄດ້ໄວແລະງ່າຍດາຍຫຼາຍເຄື່ອງມື open-source ທີ່ພ້ອມທີ່ຈະເຮັດ, ຕັ້ງຄ່າໃຫ້ເຂົາເຈົ້າ "ປິດສະຕິ" ຕາມຄໍາແນະນໍາຂອງ stackoverflow, ໂດຍບໍ່ມີການ delving ເຂົ້າໄປໃນ "ຫຼາຍຕົວອັກສອນ", ແລະເປີດຕົວ. ເຂົາເຈົ້າເຂົ້າໄປໃນການດໍາເນີນງານການຄ້າ. ແລະໃນເວລາທີ່ທ່ານຈໍາເປັນຕ້ອງໄດ້ປັບປຸງ / ຂະຫຍາຍຫຼືຜູ້ໃດຜູ້ຫນຶ່ງ reboots ສອງສາມເຄື່ອງໂດຍບັງເອີນ - ທ່ານຮູ້ວ່າບາງປະເພດຂອງຄວາມຝັນຮ້າຍ obsessive ໄດ້ເລີ່ມຕົ້ນໃນຄວາມເປັນຈິງແລ້ວ, ທຸກສິ່ງທຸກຢ່າງໄດ້ກາຍມາເປັນຢ່າງກະທັນຫັນສັບສົນຫຼາຍກ່ວາການຮັບຮູ້, ບໍ່ມີການຫັນກັບຄືນໄປບ່ອນ, ອະນາຄົດແມ່ນ vague. ແລະປອດໄພກວ່າ, ແທນທີ່ຈະດໍາເນີນໂຄງການ, ປັບປຸງພັນເຜິ້ງແລະເຮັດເນີຍແຂງ.

ມັນບໍ່ແມ່ນສໍາລັບບໍ່ມີຫຍັງທີ່ເພື່ອນຮ່ວມງານທີ່ມີປະສົບການຫຼາຍກວ່າ, ໂດຍຫົວຂອງພວກເຂົາເຕັມໄປດ້ວຍແມງໄມ້ແລະດັ່ງນັ້ນຈຶ່ງມີສີຂີ້ເຖົ່າແລ້ວ, ພິຈາລະນາການນໍາໃຊ້ຊຸດຂອງ "ຕູ້ຄອນເທນເນີ" ທີ່ໄວຢ່າງບໍ່ຫນ້າເຊື່ອໃນ "cubes" ໃນຫລາຍສິບເຊີຟເວີໃນ "ພາສາຄົນອັບເດດ:" ທີ່ມີການສະຫນັບສະຫນູນໃນຕົວ. I/O ທີ່ບໍ່ປິດກັ້ນແບບບໍ່ຊິ້ງໂຄນ, ຍິ້ມແບບອ່ອນໂຍນ. ແລະພວກເຂົາສືບຕໍ່ອ່ານ "man ps", ເຂົ້າໄປໃນລະຫັດແຫຼ່ງ "nginx" ຈົນກ່ວາຕາຂອງພວກເຂົາເລືອດອອກ, ແລະຂຽນ, ຂຽນ, ຂຽນການທົດສອບຫນ່ວຍ. ເພື່ອນຮ່ວມງານຮູ້ວ່າສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດຈະມາເມື່ອ "ສິ່ງທັງຫມົດນີ້" ມື້ຫນຶ່ງຖືກວາງໄວ້ໃນຕອນກາງຄືນໃນວັນປີໃຫມ່. ແລະພວກເຂົາພຽງແຕ່ຈະໄດ້ຮັບການຊ່ວຍໂດຍຄວາມເຂົ້າໃຈຢ່າງເລິກເຊິ່ງກ່ຽວກັບລັກສະນະຂອງ unix, ຕາຕະລາງລັດ TCP / IP ທີ່ຖືກຈົດຈໍາແລະວິທີການຈັດລຽງ - ຄົ້ນຫາຂັ້ນພື້ນຖານ. ເພື່ອ​ເຮັດ​ໃຫ້​ລະ​ບົບ​ກັບ​ຄືນ​ມາ​ມີ​ຊີ​ວິດ​ໃນ​ຂະ​ນະ​ທີ່​ກະ​ດິ່ງ​ປະ​ທ້ວງ​.

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

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

ການວິເຄາະດ້ານວິຊາການພື້ນຖານໃນ Bitrix24

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

Finger on the Pulse - ການວິເຄາະດ້ານວິຊາການຂັ້ນສູງ

ຄວາມປາຖະຫນາທີ່ຈະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບບັນຫາ "ໄວເທົ່າທີ່ຈະໄວໄດ້" ໄດ້ນໍາພາພວກເຮົາໄປສູ່ການທົດລອງຢ່າງຫ້າວຫັນດ້ວຍເຄື່ອງມືທີ່ງ່າຍດາຍແລະເຂົ້າໃຈໄດ້ - pinba ແລະ xhprof .

Pinba ໄດ້ສົ່ງສະຖິຕິໃຫ້ພວກເຮົາໃນແພັກເກັດ UDP ກ່ຽວກັບຄວາມໄວຂອງການດໍາເນີນງານຂອງບາງສ່ວນຂອງຫນ້າເວັບຕ່າງໆໃນ PHP, ແລະພວກເຮົາສາມາດເບິ່ງອອນໄລນ໌ຢູ່ໃນບ່ອນເກັບມ້ຽນ MySQL (Pinba ມາພ້ອມກັບເຄື່ອງຈັກ MySQL ຂອງຕົນເອງສໍາລັບການວິເຄາະເຫດການໄວ) ບັນຊີລາຍຊື່ສັ້ນຂອງບັນຫາແລະຕອບສະຫນອງຕໍ່. ເຂົາເຈົ້າ. ແລະ xhprof ອັດຕະໂນມັດອະນຸຍາດໃຫ້ພວກເຮົາເກັບກໍາກາຟຂອງການປະຕິບັດຫນ້າ PHP ທີ່ຊ້າທີ່ສຸດຈາກລູກຄ້າແລະວິເຄາະສິ່ງທີ່ສາມາດນໍາໄປສູ່ການນີ້ - ສະຫງົບ, ຖອກນ້ໍາຊາຫຼືບາງສິ່ງບາງຢ່າງທີ່ເຂັ້ມແຂງ.

ບາງຄັ້ງກ່ອນຫນ້ານີ້, ຊຸດເຄື່ອງມືໄດ້ຖືກເຕີມລົງໄປດ້ວຍເຄື່ອງຈັກທີ່ງ່າຍດາຍແລະເຂົ້າໃຈໄດ້ອີກອັນຫນຶ່ງໂດຍອີງໃສ່ລະບົບການດັດສະນີແບບປີ້ນກັບກັນ, ປະຕິບັດຢ່າງສົມບູນໃນຫ້ອງສະຫມຸດ Lucene ທີ່ມີຊື່ສຽງ - Elastic / Kibana. ຄວາມຄິດທີ່ງ່າຍດາຍຂອງການບັນທຶກຫຼາຍກະທູ້ຂອງເອກະສານເຂົ້າໄປໃນດັດຊະນີ Lucene inverse ໂດຍອີງໃສ່ເຫດການໃນບັນທຶກແລະການຄົ້ນຫາຢ່າງໄວວາໂດຍຜ່ານພວກມັນໂດຍໃຊ້ facet division ໄດ້ກາຍເປັນປະໂຫຍດແທ້ໆ.

ເຖິງວ່າຈະມີລັກສະນະທາງດ້ານວິຊາການຂອງການເບິ່ງເຫັນໃນ Kibana ທີ່ມີແນວຄວາມຄິດລະດັບຕ່ໍາເຊັ່ນ "bucket" "ໄຫຼຂຶ້ນ" ແລະພາສາ reinvented ຂອງ algebra ຄວາມສໍາພັນທີ່ຍັງບໍ່ໄດ້ລືມຫມົດ, ເຄື່ອງມືໄດ້ເລີ່ມຕົ້ນທີ່ຈະຊ່ວຍພວກເຮົາໄດ້ດີໃນວຽກງານດັ່ງຕໍ່ໄປນີ້:

• ລູກຄ້າ Bitrix24 ມີຂໍ້ຜິດພາດຂອງ PHP ເທົ່າໃດໃນປະຕູ p1 ໃນຊົ່ວໂມງທີ່ຜ່ານມາແລະອັນໃດ? ເຂົ້າໃຈ, ໃຫ້ອະໄພແລະແກ້ໄຂຢ່າງໄວວາ.
• ມີການໂທວິດີໂອຫຼາຍປານໃດຢູ່ໃນປະຕູໃນເຢຍລະມັນໃນ 24 ຊົ່ວໂມງທີ່ຜ່ານມາ, ມີຄຸນນະພາບແນວໃດ ແລະມີບັນຫາກັບຊ່ອງ/ເຄືອຂ່າຍບໍ?
• ການທໍາງານຂອງລະບົບ (ການຂະຫຍາຍ C ຂອງພວກເຮົາສໍາລັບ PHP), ລວບລວມຈາກແຫຼ່ງໃນການປັບປຸງການບໍລິການຫຼ້າສຸດແລະ rolled ອອກໃຫ້ລູກຄ້າ, ເຮັດວຽກໄດ້ດີເທົ່າໃດ? ມີ​ຄວາມ​ຜິດ​ພາດ​ບໍ?
• ຂໍ້ມູນລູກຄ້າເຫມາະກັບຫນ່ວຍຄວາມຈໍາ PHP ບໍ? ມີຂໍ້ຜິດພາດໃດໆກ່ຽວກັບການເກີນຄວາມຊົງຈໍາທີ່ຈັດສັນໃຫ້ກັບຂະບວນການ: "ອອກຈາກຄວາມຊົງຈໍາ" ບໍ? ຊອກ​ຫາ​ແລະ neutralize​.

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

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

ກິດຈະກໍາຂອງພະແນກໃດຫນຶ່ງພາຍໃນບໍລິສັດໄດ້ກາຍເປັນຄວາມສະດວກໃນການຕິດຕາມແລະການວັດແທກ - ແທນທີ່ຈະການວິເຄາະບັນທຶກດ້ວຍຕົນເອງໃນເຄື່ອງແມ່ຂ່າຍ, ທ່ານພຽງແຕ່ຕ້ອງການຕັ້ງບັນທຶກການວິເຄາະຄັ້ງດຽວແລະສົ່ງພວກມັນໄປຫາກຸ່ມ elastic ເພື່ອເພີດເພີນ, ສໍາລັບຕົວຢ່າງ, ພິຈາລະນາໃນ kibana. dashboard ຈໍາ​ນວນ​ຂອງ​ລູກ​ແມວ​ສອງ​ຫົວ​ຂາຍ​ພິມ​ໃນ​ເຄື່ອງ​ພິມ 3-D ສໍາ​ລັບ​ເດືອນ​ທີ່​ຜ່ານ​ມາ​.

ການວິເຄາະທຸລະກິດພື້ນຖານ

ທຸກຄົນຮູ້ວ່າການວິເຄາະທຸລະກິດໃນບໍລິສັດມັກຈະເລີ່ມຕົ້ນດ້ວຍການນໍາໃຊ້ຢ່າງຫ້າວຫັນ, ແມ່ນແລ້ວ, Excel. ແຕ່ສິ່ງທີ່ ສຳ ຄັນແມ່ນມັນບໍ່ສິ້ນສຸດ. Cloud-based Google Analytics ຍັງເພີ່ມນໍ້າມັນໃຫ້ກັບໄຟ - ທ່ານໄວເລີ່ມຄຸ້ນເຄີຍກັບສິ່ງທີ່ດີ.

ໃນບໍລິສັດທີ່ກໍາລັງພັດທະນາຢ່າງກົມກຽວກັນຂອງພວກເຮົາ, ຢູ່ທີ່ນີ້ແລະບ່ອນນັ້ນ "ສາດສະດາ" ຂອງການເຮັດວຽກທີ່ເຂັ້ມງວດກັບຂໍ້ມູນຂະຫນາດໃຫຍ່ໄດ້ເລີ່ມປາກົດ. ຄວາມຕ້ອງການສໍາລັບການລາຍງານໃນຄວາມເລິກແລະຫຼາຍຮູບຫຼາຍແບບໄດ້ເລີ່ມປາກົດເປັນປະຈໍາ, ແລະໂດຍຜ່ານຄວາມພະຍາຍາມຂອງ guys ຈາກພະແນກຕ່າງໆ, ບາງຄັ້ງກ່ອນຫນ້ານີ້ການແກ້ໄຂງ່າຍດາຍແລະປະຕິບັດໄດ້ຖືກຈັດຕັ້ງ - ການປະສົມປະສານຂອງ ClickHouse ແລະ PowerBI.

ສໍາລັບເວລາດົນນານ, ການແກ້ໄຂທີ່ມີຄວາມຍືດຫຍຸ່ນນີ້ຊ່ວຍຫຼາຍ, ແຕ່ຄ່ອຍໆຄວາມເຂົ້າໃຈໄດ້ເລີ່ມຕົ້ນວ່າ ClickHouse ບໍ່ແມ່ນຢາງແລະບໍ່ສາມາດຖືກເຍາະເຍີ້ຍແບບນັ້ນ.

ໃນທີ່ນີ້ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈດີວ່າ ClickHouse, ເຊັ່ນ Druid, ເຊັ່ນ Vertica, ເຊັ່ນ Amazon RedShift (ເຊິ່ງອີງໃສ່ postgres), ແມ່ນເຄື່ອງຈັກການວິເຄາະທີ່ເຫມາະສົມສໍາລັບການວິເຄາະທີ່ສະດວກພໍສົມຄວນ (ຜົນລວມ, ການລວບລວມ, ຕໍາ່ສຸດທີ່ - ສູງສຸດໂດຍຄໍລໍາແລະບາງສ່ວນທີ່ເປັນໄປໄດ້. ), ເນື່ອງຈາກວ່າ ຈັດຕັ້ງສໍາລັບການເກັບຮັກສາຄໍລໍາຂອງຕາຕະລາງທີ່ກ່ຽວຂ້ອງຢ່າງມີປະສິດທິພາບ, ບໍ່ເຫມືອນກັບຖານຂໍ້ມູນ MySQL ແລະຖານຂໍ້ມູນອື່ນໆ (ແຖວຮັດກຸມ) ທີ່ຮູ້ຈັກກັບພວກເຮົາ.

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

ຄວາມຕ້ອງການສໍາລັບ python ແລະນັກວິເຄາະ

ບໍລິສັດຂອງພວກເຮົາມີນັກພັດທະນາຫຼາຍຄົນທີ່ຂຽນລະຫັດເກືອບທຸກໆມື້ສໍາລັບ 10-20 ປີໃນ PHP, JavaScript, C#, C/C ++, Java, Go, Rust, Python, Bash. ຍັງມີຜູ້ບໍລິຫານລະບົບທີ່ມີປະສົບການຫຼາຍຄົນທີ່ມີປະສົບການຫຼາຍກວ່າຫນຶ່ງໄພພິບັດທີ່ບໍ່ຫນ້າເຊື່ອຢ່າງແທ້ຈິງທີ່ບໍ່ເຫມາະສົມກັບກົດຫມາຍຂອງສະຖິຕິ (ຕົວຢ່າງເຊັ່ນໃນເວລາທີ່ແຜ່ນສ່ວນໃຫຍ່ໃນການໂຈມຕີ -10 ຖືກທໍາລາຍໂດຍການໂຈມຕີຟ້າຜ່າທີ່ເຂັ້ມແຂງ). ໃນສະຖານະການດັ່ງກ່າວ, ເປັນເວລາດົນນານ, ມັນບໍ່ຊັດເຈນວ່າ "ນັກວິເຄາະ python" ແມ່ນຫຍັງ. Python ແມ່ນຄ້າຍຄື PHP, ພຽງແຕ່ຊື່ແມ່ນຍາວເລັກນ້ອຍແລະມີຮ່ອງຮອຍຫນ້ອຍຂອງສານທີ່ປ່ຽນແປງຈິດໃຈໃນລະຫັດແຫຼ່ງຂອງນາຍພາສາ. ຢ່າງໃດກໍຕາມ, ຍ້ອນວ່າບົດລາຍງານການວິເຄາະຫຼາຍຂື້ນໄດ້ຖືກສ້າງຂື້ນ, ນັກພັດທະນາທີ່ມີປະສົບການເລີ່ມເຂົ້າໃຈຄວາມສໍາຄັນຂອງຄວາມຊ່ຽວຊານແຄບໃນເຄື່ອງມືເຊັ່ນ numpy, pandas, matplotlib, seaborn.
ພາລະບົດບາດຕັດສິນ, ສ່ວນຫຼາຍແມ່ນ, ໄດ້ຖືກຫຼີ້ນໂດຍການລົ້ມລົງຢ່າງກະທັນຫັນຂອງພະນັກງານຈາກການປະສົມປະສານຂອງຄໍາວ່າ "ການຖົດຖອຍຂອງ logistic" ແລະການສະແດງການລາຍງານທີ່ມີປະສິດທິພາບໃນຂໍ້ມູນຂະຫນາດໃຫຍ່ໂດຍໃຊ້, ແມ່ນ, ແມ່ນ, pyspark.

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

ຄວາມພະຍາຍາມຕື່ມອີກຂອງ Apache Spark / Hadoop ທີ່ຈະເອົາໄປແລະສິ່ງທີ່ບໍ່ໄດ້ໄປຕາມສະຄິບ

ຢ່າງໃດກໍ່ຕາມ, ມັນທັນທີທີ່ເຫັນໄດ້ຊັດເຈນວ່າບາງສິ່ງບາງຢ່າງທີ່ເປັນລະບົບບໍ່ຖືກຕ້ອງກັບ Spark, ຫຼືມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະລ້າງມືຂອງເຈົ້າດີກວ່າ. ຖ້າ Hadoop / MapReduce / Lucene stack ຖືກສ້າງຂື້ນໂດຍນັກຂຽນໂປລແກລມທີ່ມີປະສົບການພໍສົມຄວນ, ເຊິ່ງເຫັນໄດ້ຊັດເຈນຖ້າທ່ານເບິ່ງຢ່າງໃກ້ຊິດຢູ່ໃນລະຫັດແຫຼ່ງໃນ Java ຫຼືແນວຄວາມຄິດຂອງ Doug Cutting ໃນ Lucene, ຫຼັງຈາກນັ້ນ Spark, ທັນທີທັນໃດ, ຖືກຂຽນໃນພາສາແປກໆ Scala, ເຊິ່ງແມ່ນ. ການຂັດແຍ້ງຫຼາຍຈາກທັດສະນະຂອງການປະຕິບັດຕົວຈິງແລະປະຈຸບັນບໍ່ໄດ້ພັດທະນາ. ແລະການຄິດໄລ່ການຫຼຸດລົງເປັນປົກກະຕິກ່ຽວກັບກຸ່ມ Spark ເນື່ອງຈາກການເຮັດວຽກທີ່ບໍ່ມີເຫດຜົນແລະບໍ່ໂປ່ງໃສຫຼາຍກັບການຈັດສັນຫນ່ວຍຄວາມຈໍາສໍາລັບການຫຼຸດຜ່ອນການດໍາເນີນງານ (ຫຼາຍປຸ່ມມາຮອດໃນຄັ້ງດຽວ) ໄດ້ສ້າງ halo ປະມານມັນຂອງບາງສິ່ງບາງຢ່າງທີ່ມີພື້ນທີ່ທີ່ຈະເຕີບໂຕ. ນອກຈາກນັ້ນ, ສະຖານະການກໍ່ຮ້າຍແຮງຂຶ້ນໂດຍຊ່ອງສຽບທີ່ແປກປະຫຼາດຈໍານວນຫລາຍ, ໄຟລ໌ຊົ່ວຄາວທີ່ເຕີບໃຫຍ່ຢູ່ໃນສະຖານທີ່ທີ່ບໍ່ສາມາດເຂົ້າໃຈໄດ້ຫຼາຍທີ່ສຸດແລະການເພິ່ງພາອາໄສນະລົກ - ເຊິ່ງເຮັດໃຫ້ຜູ້ບໍລິຫານລະບົບມີຄວາມຮູ້ສຶກຫນຶ່ງທີ່ຮູ້ຈັກກັນດີຈາກໄວເດັກ: ຄວາມກຽດຊັງຢ່າງຮຸນແຮງ (ຫຼືບາງທີ. ເຂົາເຈົ້າຕ້ອງລ້າງມືດ້ວຍສະບູ).

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ "ຢູ່ລອດ" ໂຄງການການວິເຄາະພາຍໃນຫຼາຍໆໂຄງການທີ່ໃຊ້ Apache Spark ຢ່າງຈິງຈັງ (ລວມທັງ Spark Streaming, Spark SQL) ແລະລະບົບນິເວດ Hadoop (ແລະອື່ນໆແລະອື່ນໆ). ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າເມື່ອເວລາຜ່ານໄປພວກເຮົາໄດ້ຮຽນຮູ້ການກະກຽມແລະຕິດຕາມ "ມັນ" ຂ້ອນຂ້າງດີ, ແລະ "ມັນ" ປະຕິບັດໄດ້ຢຸດເຊົາຢ່າງກະທັນຫັນເນື່ອງຈາກການປ່ຽນແປງຂອງຂໍ້ມູນແລະຄວາມບໍ່ສົມດຸນຂອງ RDD ທີ່ເປັນເອກະພາບ, ຄວາມປາຖະຫນາທີ່ຈະເອົາບາງສິ່ງບາງຢ່າງທີ່ກຽມພ້ອມແລ້ວ. , ປັບປຸງແລະບໍລິຫານບາງບ່ອນຢູ່ໃນຄລາວເພີ່ມຂຶ້ນແລະເຂັ້ມແຂງ. ມັນແມ່ນໃນເວລານີ້ທີ່ພວກເຮົາພະຍາຍາມໃຊ້ການປະກອບເມຄທີ່ກຽມພ້ອມຂອງ Amazon Web Services - EMR ແລະ, ຕໍ່ມາ, ພະຍາຍາມແກ້ໄຂບັນຫາການນໍາໃຊ້ມັນ. EMR ແມ່ນ Apache Spark ທີ່ກະກຽມໂດຍ Amazon ດ້ວຍຊອບແວເພີ່ມເຕີມຈາກລະບົບນິເວດ, ຄືກັບ Cloudera/Hortonworks builds.

ການເກັບຮັກສາໄຟລ໌ຢາງສໍາລັບການວິເຄາະແມ່ນມີຄວາມຈໍາເປັນອັນຮີບດ່ວນ

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

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

Amazon S3 ເປັນຜູ້ສະຫມັກສໍາລັບ DataLake ບໍ?

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

ອີກເທື່ອຫນຶ່ງ, ແນວຄວາມຄິດພື້ນຖານ. ບໍ່ມີຄວາມປາຖະຫນາທີ່ຈະ "ຖອກ" ຂໍ້ມູນໃຫຍ່ເຂົ້າໄປໃນເຄື່ອງຈັກການວິເຄາະກຸ່ມດຽວ, ເຊິ່ງຈະໄວຫຼືຫຼັງຈາກນັ້ນ choke ແລະທ່ານຈະຕ້ອງ shard ມັນ ugly. ຂ້ອຍຕ້ອງການເກັບຮັກສາໄຟລ໌, ພຽງແຕ່ໄຟລ໌, ໃນຮູບແບບທີ່ເຂົ້າໃຈໄດ້ແລະປະຕິບັດການສອບຖາມການວິເຄາະທີ່ມີປະສິດທິພາບໃນພວກມັນໂດຍໃຊ້ເຄື່ອງມືທີ່ແຕກຕ່າງກັນແຕ່ເຂົ້າໃຈໄດ້. ແລະ​ຈະ​ມີ​ຫຼາຍ​ແລະ​ຫຼາຍ​ໄຟລ​໌​ໃນ​ຮູບ​ແບບ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​. ແລະມັນດີກວ່າທີ່ຈະ shard ບໍ່ແມ່ນເຄື່ອງຈັກ, ແຕ່ຂໍ້ມູນແຫຼ່ງ. ພວກເຮົາຕ້ອງການ DataLake ທີ່ສາມາດຂະຫຍາຍໄດ້ ແລະທົ່ວໄປ, ພວກເຮົາຕັດສິນໃຈ...

ຈະເປັນແນວໃດຖ້າທ່ານເກັບຮັກສາໄຟລ໌ຢູ່ໃນບ່ອນເກັບຂໍ້ມູນຟັງທີ່ຄຸ້ນເຄີຍແລະຮູ້ຈັກກັນດີທີ່ Amazon S3, ໂດຍບໍ່ມີການກະກຽມຟັກຂອງທ່ານເອງຈາກ Hadoop?

ມັນເປັນທີ່ຊັດເຈນວ່າຂໍ້ມູນສ່ວນຕົວແມ່ນ "ຕໍ່າ", ແຕ່ຂໍ້ມູນອື່ນແນວໃດຖ້າພວກເຮົາເອົາມັນອອກຈາກບ່ອນນັ້ນແລະ "ເຮັດໃຫ້ມັນມີປະສິດທິພາບ"?

ລະບົບນິເວດ Cluster-bigdata-analytics ຂອງ Amazon Web Services - ໃນຄໍາສັບທີ່ງ່າຍດາຍຫຼາຍ

ການຕັດສິນໂດຍປະສົບການຂອງພວກເຮົາກັບ AWS, Apache Hadoop/MapReduce ໄດ້ຖືກນໍາໃຊ້ຢ່າງຈິງຈັງຢູ່ທີ່ນັ້ນເປັນເວລາດົນນານພາຍໃຕ້ຊອດຕ່າງໆ, ຕົວຢ່າງໃນການບໍລິການ DataPipeline (ຂ້ອຍອິດສາເພື່ອນຮ່ວມງານຂອງຂ້ອຍ, ພວກເຂົາໄດ້ຮຽນຮູ້ວິທີການກະກຽມຢ່າງຖືກຕ້ອງ). ທີ່ນີ້ພວກເຮົາຕັ້ງຄ່າການສໍາຮອງຂໍ້ມູນຈາກການບໍລິການທີ່ແຕກຕ່າງກັນຈາກຕາຕະລາງ DynamoDB:


ແລະເຂົາເຈົ້າໄດ້ແລ່ນເປັນປົກກະຕິຢູ່ໃນກຸ່ມ Hadoop/MapReduce ທີ່ຖືກຝັງໄວ້ຄືກັບການເຮັດວຽກຂອງໂມງເປັນເວລາຫຼາຍປີແລ້ວ. "ຕັ້ງມັນແລະລືມມັນ":

ນອກນັ້ນທ່ານຍັງສາມາດມີສ່ວນຮ່ວມຢ່າງມີປະສິດທິພາບຂອງຊາຕານຂໍ້ມູນໂດຍການຕັ້ງແລັບທັອບ Jupiter ຢູ່ໃນຄລາວສໍາລັບນັກວິເຄາະແລະໃຊ້ບໍລິການ AWS SageMaker ເພື່ອຝຶກອົບຮົມແລະນໍາໃຊ້ຕົວແບບ AI ເຂົ້າໃນການສູ້ຮົບ. ນີ້ແມ່ນສິ່ງທີ່ມັນຄ້າຍຄືສໍາລັບພວກເຮົາ:

ແລະແມ່ນແລ້ວ, ທ່ານສາມາດເອົາຄອມພິວເຕີໂນດບຸກສໍາລັບຕົວທ່ານເອງຫຼືນັກວິເຄາະໃນເມຄແລະຕິດມັນໃສ່ກັບກຸ່ມ Hadoop / Spark, ເຮັດການຄິດໄລ່ແລະຫຼັງຈາກນັ້ນເລັບທຸກສິ່ງທຸກຢ່າງລົງ:

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

AWS Glue - ຫຸ້ມຫໍ່ Apache Spark ຢ່າງເປັນລະບຽບກ່ຽວກັບສະເຕີຣອຍ

ມັນໄດ້ຫັນອອກວ່າ AWS ມີຮຸ່ນຂອງຕົນເອງຂອງ "Hive / Pig / Spark" stack. ບົດບາດຂອງ Hive, i.e. ລາຍການໄຟລ໌ ແລະປະເພດຂອງມັນຢູ່ໃນ DataLake ແມ່ນປະຕິບັດໂດຍການບໍລິການ "ລາຍການຂໍ້ມູນ", ເຊິ່ງບໍ່ໄດ້ເຊື່ອງຄວາມເຂົ້າກັນໄດ້ກັບຮູບແບບ Apache Hive. ທ່ານຈໍາເປັນຕ້ອງເພີ່ມຂໍ້ມູນໃສ່ບໍລິການນີ້ກ່ຽວກັບບ່ອນທີ່ໄຟລ໌ຂອງທ່ານຕັ້ງຢູ່ແລະຢູ່ໃນຮູບແບບໃດ. ຂໍ້ມູນສາມາດບໍ່ພຽງແຕ່ຢູ່ໃນ s3, ແຕ່ຍັງຢູ່ໃນຖານຂໍ້ມູນ, ແຕ່ນັ້ນບໍ່ແມ່ນຫົວຂໍ້ຂອງການຕອບນີ້. ນີ້ແມ່ນວິທີການຈັດລຽງຂໍ້ມູນ DataLake ຂອງພວກເຮົາ:

ໄຟລ໌ໄດ້ຖືກລົງທະບຽນ, ທີ່ຍິ່ງໃຫຍ່. ຖ້າໄຟລ໌ໄດ້ຖືກປັບປຸງ, ພວກເຮົາເປີດຕົວຕົວກວາດເວັບບໍ່ວ່າຈະດ້ວຍຕົນເອງຫຼືໃນຕາຕະລາງ, ເຊິ່ງຈະປັບປຸງຂໍ້ມູນກ່ຽວກັບພວກມັນຈາກທະເລສາບແລະປະຫຍັດພວກມັນ. ຫຼັງຈາກນັ້ນ, ຂໍ້ມູນຈາກທະເລສາບສາມາດຖືກປຸງແຕ່ງແລະຜົນໄດ້ຮັບທີ່ຖືກອັບໂຫລດຢູ່ບ່ອນໃດຫນຶ່ງ. ໃນກໍລະນີງ່າຍດາຍທີ່ສຸດ, ພວກເຮົາຍັງອັບໂຫລດໄປຍັງ s3. ການປະມວນຜົນຂໍ້ມູນສາມາດເຮັດໄດ້ທຸກບ່ອນ, ແຕ່ແນະນໍາໃຫ້ທ່ານຕັ້ງຄ່າການປຸງແຕ່ງຢູ່ໃນກຸ່ມ Apache Spark ໂດຍໃຊ້ຄວາມສາມາດຂັ້ນສູງຜ່ານ API AWS Glue. ໃນຄວາມເປັນຈິງ, ທ່ານສາມາດເອົາລະຫັດ python ເກົ່າແລະຄຸ້ນເຄີຍທີ່ດີໂດຍໃຊ້ຫ້ອງສະຫມຸດ pyspark ແລະກໍານົດການປະຕິບັດຂອງມັນຢູ່ໃນ N nodes ຂອງກຸ່ມທີ່ມີຄວາມສາມາດໃນການຕິດຕາມ, ໂດຍບໍ່ມີການຂຸດເຂົ້າໄປໃນ guts ຂອງ Hadoop ແລະລາກຕູ້ຄອນເທນເນີ docker-moker ແລະລົບລ້າງຄວາມຂັດແຍ້ງການເພິ່ງພາອາໄສ. .

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

ດັ່ງນັ້ນ, ຖ້າທ່ານຕ້ອງການຄິດໄລ່ບາງສິ່ງບາງຢ່າງໃນກຸ່ມ Spark ໂດຍໃຊ້ຂໍ້ມູນໃນ s3, ພວກເຮົາຂຽນລະຫັດໃນ python / pyspark, ທົດສອບມັນ, ແລະໂຊກດີກັບຟັງ.

ຈະເປັນແນວໃດກ່ຽວກັບການ orchestration? ຈະເປັນແນວໃດຖ້າວຽກງານຫຼຸດລົງແລະຫາຍໄປ? ແມ່ນແລ້ວ, ມັນໄດ້ຖືກສະເຫນີໃຫ້ສ້າງທໍ່ທີ່ສວຍງາມໃນຮູບແບບ Apache Pig ແລະພວກເຮົາກໍ່ພະຍາຍາມພວກມັນ, ແຕ່ສໍາລັບຕອນນີ້ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະໃຊ້ orchestration ຂອງພວກເຮົາຢ່າງເລິກເຊິ່ງໃນ PHP ແລະ JavaScript (ຂ້ອຍເຂົ້າໃຈ, ມັນມີສະຕິປັນຍາ, ແຕ່ມັນເຮັດວຽກ, ສໍາລັບ. ປີ​ແລະ​ບໍ່​ມີ​ຄວາມ​ຜິດ​ພາດ​)​.

ຮູບແບບຂອງໄຟລ໌ທີ່ເກັບໄວ້ໃນທະເລສາບແມ່ນກຸນແຈສໍາລັບການປະຕິບັດ

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

• ເກັບຮັກສາຄໍລໍາຂອງໄຟລ໌ແຍກຕ່າງຫາກ (ດັ່ງນັ້ນທ່ານບໍ່ຈໍາເປັນຕ້ອງອ່ານທຸກແຖວເພື່ອເຂົ້າໃຈສິ່ງທີ່ຢູ່ໃນຄໍລໍາ). ສໍາລັບການນີ້ພວກເຮົາໄດ້ເອົາຮູບແບບ parquet ດ້ວຍການບີບອັດ
• ມັນເປັນສິ່ງສໍາຄັນຫຼາຍທີ່ຈະ shard ໄຟລ໌ເຂົ້າໄປໃນໂຟນເດີເຊັ່ນ: ພາສາ, ປີ, ເດືອນ, ມື້, ອາທິດ. ເຄື່ອງຈັກທີ່ເຂົ້າໃຈປະເພດຂອງ sharding ນີ້ຈະເບິ່ງພຽງແຕ່ຢູ່ໃນໂຟນເດີທີ່ຈໍາເປັນ, ໂດຍບໍ່ມີການ sifting ຜ່ານຂໍ້ມູນທັງຫມົດຕິດຕໍ່ກັນ.

ໂດຍພື້ນຖານແລ້ວ, ໃນທາງນີ້, ເຈົ້າຈັດວາງຂໍ້ມູນແຫຼ່ງໃນຮູບແບບທີ່ມີປະສິດທິພາບທີ່ສຸດສໍາລັບເຄື່ອງຈັກການວິເຄາະທີ່ວາງໄວ້ເທິງ, ເຊິ່ງເຖິງແມ່ນວ່າຢູ່ໃນໂຟເດີ sharded ສາມາດເລືອກເຂົ້າແລະອ່ານພຽງແຕ່ຄໍລໍາທີ່ຈໍາເປັນຈາກໄຟລ໌. ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງ "ຕື່ມ" ຂໍ້ມູນຢູ່ບ່ອນໃດບ່ອນ ໜຶ່ງ (ບ່ອນເກັບມ້ຽນຈະແຕກອອກມາ) - ພຽງແຕ່ເອົາມັນໄວ້ໃນລະບົບເອກະສານໃນຮູບແບບທີ່ຖືກຕ້ອງ. ແນ່ນອນ, ມັນຄວນຈະຈະແຈ້ງຢູ່ທີ່ນີ້ວ່າການເກັບຮັກສາໄຟລ໌ csv ຂະຫນາດໃຫຍ່ໃນ DataLake, ເຊິ່ງທໍາອິດຕ້ອງໄດ້ຮັບການອ່ານແຖວໂດຍກຸ່ມເພື່ອສະກັດຄໍລໍາ, ບໍ່ແມ່ນການແນະນໍາຫຼາຍ. ຄິດກ່ຽວກັບສອງຈຸດຂ້າງເທິງນີ້ອີກເທື່ອຫນຶ່ງຖ້າຫາກວ່າມັນຍັງບໍ່ທັນຈະແຈ້ງວ່າເປັນຫຍັງທັງຫມົດນີ້ເກີດຂຶ້ນ.

AWS Athena - jack-in-the-box

ແລະຫຼັງຈາກນັ້ນ, ໃນຂະນະທີ່ສ້າງທະເລສາບ, ພວກເຮົາບັງເອີນມາໃນທົ່ວ Amazon Athena. ທັນໃດນັ້ນມັນໄດ້ຫັນອອກວ່າໂດຍການຈັດລຽງໄຟລ໌ບັນທຶກຂະຫນາດໃຫຍ່ຂອງພວກເຮົາເຂົ້າໄປໃນ shards ໂຟເດີໃນຮູບແບບຖັນທີ່ຖືກຕ້ອງ (parquet), ທ່ານສາມາດເລືອກຂໍ້ມູນຈາກພວກມັນໄດ້ຢ່າງໄວວາແລະສ້າງບົດລາຍງານໂດຍບໍ່ມີການ, ໂດຍບໍ່ມີກຸ່ມ Apache Spark / Glue.

ເຄື່ອງຈັກ Athena ຂັບເຄື່ອນໂດຍຂໍ້ມູນໃນ s3 ແມ່ນອີງໃສ່ຄວາມຫມາຍ Presto - ຕົວ​ແທນ​ຂອງ MPP (ການ​ປຸງ​ແຕ່ງ​ຂະ​ຫນານ​ຂະ​ຫນາດ​ໃຫຍ່​) ຄອບ​ຄົວ​ຂອງ​ວິ​ທີ​ການ​ສໍາ​ລັບ​ການ​ປະ​ມວນ​ຜົນ​ຂໍ້​ມູນ​, ການ​ເອົາ​ຂໍ້​ມູນ​ທີ່​ມັນ​ຢູ່​, ຈາກ s3 ແລະ Hadoop ກັບ Cassandra ແລະ​ໄຟລ​໌​ຂໍ້​ຄວາມ​ປະ​ຊຸມ​ສະ​ໄຫມ​. ທ່ານພຽງແຕ່ຕ້ອງການຂໍໃຫ້ Athena ດໍາເນີນການສອບຖາມ SQL, ແລະຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງ "ເຮັດວຽກຢ່າງໄວວາແລະອັດຕະໂນມັດ." ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່າ Athena ແມ່ນ "ສະຫຼາດ", ມັນພຽງແຕ່ໄປຫາໂຟເດີ sharded ທີ່ຈໍາເປັນແລະອ່ານພຽງແຕ່ຄໍລໍາທີ່ຈໍາເປັນໃນການຮ້ອງຂໍ.

ລາຄາສໍາລັບການຮ້ອງຂໍກັບ Athena ແມ່ນຫນ້າສົນໃຈ. ພວກເຮົາຈ່າຍສໍາລັບ ປະລິມານຂອງຂໍ້ມູນທີ່ສະແກນ. ເຫຼົ່ານັ້ນ. ບໍ່ແມ່ນສໍາລັບຈໍານວນຂອງເຄື່ອງຈັກໃນ cluster ຕໍ່ນາທີ, ແຕ່ ... ສໍາລັບຂໍ້ມູນຕົວຈິງ scanned ໃນ 100-500 ເຄື່ອງ, ພຽງແຕ່ຂໍ້ມູນທີ່ຈໍາເປັນເພື່ອເຮັດສໍາເລັດການຮ້ອງຂໍ.

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

ໂດຍວິທີທາງການ, ນີ້ແມ່ນວິທີທີ່ພວກເຮົາແບ່ງປັນຂໍ້ມູນຂອງພວກເຮົາໃນ s3:

ດັ່ງນັ້ນ, ໃນເວລາສັ້ນໆ, ພະແນກທີ່ແຕກຕ່າງກັນໃນບໍລິສັດ, ຈາກຄວາມປອດໄພຂອງຂໍ້ມູນໄປຫາການວິເຄາະ, ໄດ້ເລີ່ມຕົ້ນການຮ້ອງຂໍຢ່າງຈິງຈັງກັບ Athena ແລະຢ່າງໄວວາ, ໃນວິນາທີ, ໄດ້ຮັບຄໍາຕອບທີ່ເປັນປະໂຫຍດຈາກຂໍ້ມູນ "ໃຫຍ່" ໃນໄລຍະເວລາຫຼາຍ: ເດືອນ, ເຄິ່ງປີ, ແລະອື່ນໆ P.

ແຕ່​ພວກ​ເຮົາ​ໄດ້​ໄປ​ຕື່ມ​ອີກ​ແລະ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ທີ່​ຈະ​ໄປ​ຟັງ​ສໍາ​ລັບ​ຄໍາ​ຕອບ​ ຜ່ານໄດເວີ ODBC: ນັກວິເຄາະຂຽນຄໍາຖາມ SQL ໃນ console ທີ່ຄຸ້ນເຄີຍ, ເຊິ່ງໃນ 100-500 ເຄື່ອງຈັກ "ສໍາລັບ pennies" ສົ່ງຂໍ້ມູນໄປຫາ s3 ແລະຕອບຄໍາຕອບໂດຍປົກກະຕິໃນສອງສາມວິນາທີ. ສະດວກສະບາຍ. ແລະໄວ. ຂ້ອຍຍັງບໍ່ສາມາດເຊື່ອມັນໄດ້.

ດັ່ງນັ້ນ, ໄດ້ຕັດສິນໃຈເກັບຂໍ້ມູນໃນ s3, ໃນຮູບແບບຄໍລໍາທີ່ມີປະສິດທິພາບແລະມີການແບ່ງປັນຂໍ້ມູນທີ່ສົມເຫດສົມຜົນເຂົ້າໄປໃນໂຟນເດີ ... ພວກເຮົາໄດ້ຮັບ DataLake ແລະເຄື່ອງຈັກການວິເຄາະໄວແລະລາຄາຖືກ - ສໍາລັບການຟຣີ. ແລະລາວໄດ້ກາຍເປັນທີ່ນິຍົມຫຼາຍໃນບໍລິສັດ, ເພາະວ່າ ... ເຂົ້າ​ໃຈ SQL ແລະ​ເຮັດ​ວຽກ​ຄໍາ​ສັ່ງ​ຂະ​ຫນາດ​ໄວ​ກ​່​ວາ​ໂດຍ​ຜ່ານ​ການ​ເລີ່ມ​ຕົ້ນ / ຢຸດ / ການ​ຕັ້ງ​ຄ່າ​ກຸ່ມ​. "ແລະຖ້າຜົນໄດ້ຮັບຄືກັນ, ເປັນຫຍັງຕ້ອງຈ່າຍຫຼາຍ?"

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

ການຄົ້ນພົບ

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

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

ໃນຕອນເລີ່ມຕົ້ນຂອງການເດີນທາງ, ຫົວຂອງຂ້ອຍໄດ້ແຍກອອກຈາກສວນສັດປ່າທໍາມະຊາດຈໍານວນຫຼາຍຂອງຊອບແວເປີດແລະປິດແລະຄວາມເຂົ້າໃຈຂອງພາລະຂອງຄວາມຮັບຜິດຊອບຕໍ່ລູກຫລານ. ພຽງແຕ່ເລີ່ມຕົ້ນສ້າງ DataLake ຂອງທ່ານຈາກເຄື່ອງມືງ່າຍໆ: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., ເກັບກໍາຂໍ້ຄິດເຫັນແລະຄວາມເຂົ້າໃຈຢ່າງເລິກເຊິ່ງກ່ຽວກັບຟີຊິກຂອງຂະບວນການທີ່ເກີດຂຶ້ນ. ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ສະ​ລັບ​ສັບ​ຊ້ອນ​ແລະ murky - ໃຫ້​ມັນ​ກັບ​ສັດ​ຕູ​ແລະ​ຄູ່​ແຂ່ງ​.

ຖ້າທ່ານບໍ່ຕ້ອງການໄປຟັງຄລາວແລະມັກສະຫນັບສະຫນູນ, ປັບປຸງແລະແກ້ໄຂໂຄງການ open-source, ທ່ານສາມາດສ້າງໂຄງການທີ່ຄ້າຍຄືກັນກັບທ້ອງຖິ່ນຂອງພວກເຮົາ, ໃນເຄື່ອງສໍານັກງານລາຄາຖືກທີ່ມີ Hadoop ແລະ Presto ຢູ່ເທິງ. ສິ່ງທີ່ ສຳ ຄັນແມ່ນບໍ່ຢຸດແລະກ້າວໄປຂ້າງ ໜ້າ, ນັບ, ຊອກຫາວິທີແກ້ໄຂທີ່ງ່າຍດາຍແລະຈະແຈ້ງ, ແລະທຸກຢ່າງຈະອອກມາແນ່ນອນ! ຂໍໃຫ້ທຸກຄົນໂຊກດີ ແລະພົບກັນໃໝ່!

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