Data Engineer ຫຼືເສຍຊີວິດ: ເລື່ອງຂອງນັກພັດທະນາຄົນຫນຶ່ງ

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

ເປັນຫຍັງວິສະວະກໍາຂໍ້ມູນ?

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

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

ຖ້າທ່ານຕ້ອງການທີ່ຈະເປັນ Data Driven, ທໍາອິດກາຍເປັນເຫດການຂັບເຄື່ອນ

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

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

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

ຄວາມຫຍຸ້ງຍາກໃນເວລາຫັນປ່ຽນຈາກການພັດທະນາ

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

1. ສິ່ງທໍາອິດທີ່ຂ້ອຍເຫັນແມ່ນບໍ່ມີ tuling ແລະການປະຕິບັດບາງຢ່າງ. ສໍາລັບຕົວຢ່າງ, ການຄຸ້ມຄອງລະຫັດທີ່ມີການທົດສອບ. ພວກເຮົາມີກອບການທົດສອບຫຼາຍຮ້ອຍໃນການພັດທະນາ. ເມື່ອເຮັດວຽກກັບຂໍ້ມູນ, ທຸກສິ່ງທຸກຢ່າງແມ່ນສັບສົນຫຼາຍ. ແມ່ນແລ້ວ, ພວກເຮົາສາມາດທົດສອບທໍ່ ETL ໃນຂໍ້ມູນການທົດສອບ, ແຕ່ພວກເຮົາຕ້ອງເຮັດທັງຫມົດດ້ວຍຕົນເອງແລະຊອກຫາວິທີແກ້ໄຂສໍາລັບແຕ່ລະກໍລະນີສະເພາະ. ດັ່ງນັ້ນ, ການຄຸ້ມຄອງການທົດສອບແມ່ນຮ້າຍແຮງກວ່າເກົ່າ. ໂຊກດີ, ມີອີກຊັ້ນຫນຶ່ງຂອງຄໍາຄຶດຄໍາເຫັນໃນຮູບແບບຂອງການຕິດຕາມແລະບັນທຶກ, ແຕ່ນີ້ແລ້ວຮຽກຮ້ອງໃຫ້ພວກເຮົາ reactly ແທນທີ່ຈະ proactively, ເຊິ່ງ infuriating ແລະ unnerving.

2. ໂລກຈາກທັດສະນະຂອງ DE ແມ່ນບໍ່ແມ່ນສິ່ງທີ່ມັນເບິ່ງຄືວ່ານັກພັດທະນາຜະລິດຕະພັນທໍາມະດາ (ດີ, ແນ່ນອນ, ຜູ້ອ່ານບໍ່ເປັນແນວນັ້ນ, ແລະລາວຮູ້ທຸກຢ່າງແລ້ວ, ແຕ່ຂ້ອຍບໍ່ຮູ້ແລະຕອນນີ້ຂ້ອຍກໍາລັງຫັນຫນ້າ. ມັນຂຶ້ນ). ໃນຖານະນັກພັດທະນາ, ຂ້ອຍສ້າງ microservice ຂອງຂ້ອຍເອງ, ເອົາຂໍ້ມູນໄວ້ໃນ [ຖານຂໍ້ມູນທີ່ທ່ານເລືອກ], ຊ່ວຍປະຢັດລັດຂອງຂ້ອຍຢູ່ທີ່ນັ້ນ, ເອົາບາງສິ່ງບາງຢ່າງໂດຍ ID ແລະມັນດີ. ການບໍລິການຊ້າ, ຄໍາສັ່ງແມ່ນສັບສົນ, ນັ້ນແມ່ນທັງຫມົດ. ພວກເຂົາຂໍໃຫ້ຂ້ອຍຊອກຫາລັດຂອງຂ້ອຍໃນການບໍລິການອື່ນ, ດັ່ງນັ້ນຂ້ອຍຈະຖິ້ມເຫດການເຂົ້າໄປໃນ RabbitMQ ແລະນັ້ນແມ່ນມັນ. ແລະໃນທີ່ນີ້ພວກເຮົາອີກເທື່ອຫນຶ່ງໄດ້ກັບຄືນໄປຫາບັນຫາຂອງເຫດການທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.

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

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

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

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

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

ບົດສະຫຼຸບ ແລະ ປະກາດຜົນກອງປະຊຸມ

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

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

ໃນໂອກາດນີ້, ຂ້າພະເຈົ້າຂໍເຊີນຊວນທຸກຄົນທີ່ສົນໃຈມາຮ່ວມກອງປະຊຸມຊຸມຊົນຄັ້ງທຳອິດຂອງພວກເຮົາດ້ວຍຫົວຂໍ້ “DE or DIE”, ເຊິ່ງຈະຈັດຂຶ້ນໃນວັນທີ 27.02.2020 ກຸມພາ XNUMX ທີ່ຫ້ອງການ Dodo Pizza. ລາຍລະອຽດໄດ້ທີ່ TimePad.

ຖ້າມີຫຍັງເກີດຂື້ນ, ຂ້ອຍຈະຢູ່ທີ່ນັ້ນ, ເຈົ້າສາມາດບອກຂ້ອຍສ່ວນຕົວກັບໃບຫນ້າຂອງຂ້ອຍວ່າຂ້ອຍຜິດແນວໃດກ່ຽວກັບນັກພັດທະນາ.

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