Open Source DataHub: LinkedIn's Metadata Search and Discovery Platform

Open Source DataHub: LinkedIn's Metadata Search and Discovery Platform

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

ໃນບົດຄວາມນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບວິທີທີ່ພວກເຮົາເຜີຍແຜ່ແຫຼ່ງຂໍ້ມູນພາຍໃຕ້ໃບອະນຸຍາດເປີດ DataHub ໃນເວທີການຄົ້ນຫາ metadata ແລະຄົ້ນພົບຂອງພວກເຮົາ, ເລີ່ມຕົ້ນຈາກມື້ທໍາອິດຂອງໂຄງການ WhereHow. LinkedIn ຮັກສາສະບັບຂອງຕົນເອງຂອງ DataHub ແຍກຕ່າງຫາກຈາກສະບັບແຫຼ່ງເປີດ. ພວກເຮົາຈະເລີ່ມຕົ້ນໂດຍການອະທິບາຍວ່າເປັນຫຍັງພວກເຮົາຕ້ອງການສອງສະພາບແວດລ້ອມການພັດທະນາແຍກຕ່າງຫາກ, ຫຼັງຈາກນັ້ນປຶກສາຫາລືວິທີການເລີ່ມຕົ້ນໃນການນໍາໃຊ້ແຫຼ່ງເປີດ WhereHows ແລະປຽບທຽບສະບັບພາຍໃນ (ການຜະລິດ) ຂອງ DataHub ຂອງພວກເຮົາກັບສະບັບໃນ. GitHub. ພວກເຮົາຍັງຈະແບ່ງປັນລາຍລະອຽດກ່ຽວກັບການແກ້ໄຂອັດຕະໂນມັດໃຫມ່ຂອງພວກເຮົາສໍາລັບການຊຸກຍູ້ແລະຮັບການອັບເດດແຫຼ່ງເປີດເພື່ອຮັກສາທັງສອງ repositories ໃນ sync. ສຸດທ້າຍ, ພວກເຮົາຈະໃຫ້ຄໍາແນະນໍາກ່ຽວກັບວິທີການເລີ່ມຕົ້ນການນໍາໃຊ້ DataHub ແຫຼ່ງເປີດແລະສົນທະນາໂດຍຫຍໍ້ກ່ຽວກັບຖາປັດຕະຍະຂອງມັນ.

WhereHows ໃນປັດຈຸບັນເປັນ DataHub!

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

Open Source Approaches

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

ພະຍາຍາມທໍາອິດ: "ແຫຼ່ງເປີດທໍາອິດ"

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

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

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

ຄວາມພະຍາຍາມທີສອງ: "ພາຍໃນທໍາອິດ"

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

ຄັ້ງທີສາມມັນເຮັດວຽກ!

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

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

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

Open Source Publishing ອັດຕະໂນມັດ

ວິທີການຫຼ້າສຸດຂອງທີມງານ Metadata ກັບ DataHub ແຫຼ່ງເປີດແມ່ນການພັດທະນາເຄື່ອງມືທີ່ຈະ syncs ອັດຕະໂນມັດ codebase ພາຍໃນແລະແຫຼ່ງເປີດ repository. ຄຸນ​ນະ​ສົມ​ບັດ​ລະ​ດັບ​ສູງ​ຂອງ​ຊຸດ​ເຄື່ອງ​ມື​ນີ້​ປະ​ກອບ​ມີ​:

1. ຊິງລະຫັດ LinkedIn ໄປ/ຈາກແຫຼ່ງເປີດ, ຄ້າຍຄືກັນ rsync.
2. ການຜະລິດຫົວໃບອະນຸຍາດ, ຄ້າຍຄືກັນກັບ Apache Rat.
3. ສ້າງບັນທຶກ commit ແຫຼ່ງເປີດໂດຍອັດຕະໂນມັດຈາກບັນທຶກການ commit ພາຍໃນ.
4. ປ້ອງກັນການປ່ຽນແປງພາຍໃນທີ່ທໍາລາຍແຫຼ່ງເປີດທີ່ສ້າງຂຶ້ນໂດຍ ການທົດສອບການເພິ່ງພາອາໄສ.

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

ການ synchronization ລະຫັດແຫຼ່ງ

ບໍ່ເຫມືອນກັບສະບັບແຫຼ່ງເປີດຂອງ DataHub, ເຊິ່ງເປັນບ່ອນເກັບມ້ຽນ GitHub ດຽວ, ສະບັບ LinkedIn ຂອງ DataHub ແມ່ນການລວມກັນຂອງຫຼາຍ repositories (ເອີ້ນວ່າພາຍໃນ. ຫຼາຍຜະລິດຕະພັນ). ການໂຕ້ຕອບ DataHub, ຫ້ອງສະຫມຸດແບບຈໍາລອງ metadata, ບໍລິການ backend warehouse metadata, ແລະວຽກ streaming ອາໄສຢູ່ໃນ repositories ແຍກຕ່າງຫາກໃນ LinkedIn. ຢ່າງໃດກໍ່ຕາມ, ເພື່ອເຮັດໃຫ້ມັນງ່າຍຂຶ້ນສໍາລັບຜູ້ໃຊ້ແຫຼ່ງເປີດ, ພວກເຮົາມີບ່ອນເກັບມ້ຽນດຽວສໍາລັບສະບັບ Open Source ຂອງ DataHub.

ຮູບທີ 1: ການຊິ້ງຂໍ້ມູນລະຫວ່າງບ່ອນເກັບມ້ຽນ LinkedIn DataHub ແລະບ່ອນເກັບມ້ຽນອັນດຽວ DataHub ແຫຼ່ງເປີດ

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

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

ການສ້າງແຜນທີ່ລະດັບໂມດູນແມ່ນ JSON ງ່າຍໆທີ່ມີກະແຈຂອງໂມດູນເປົ້າຫມາຍໃນບ່ອນເກັບມ້ຽນແຫຼ່ງເປີດແລະຄ່າຕ່າງໆແມ່ນບັນຊີລາຍຊື່ຂອງໂມດູນແຫຼ່ງໃນບ່ອນເກັບມ້ຽນ LinkedIn. ໂມດູນເປົ້າຫມາຍໃດໆໃນ repository open source ສາມາດຖືກປ້ອນໂດຍຈໍານວນໂມດູນແຫຼ່ງໃດໆ. ເພື່ອຊີ້ບອກຊື່ພາຍໃນຂອງ repositories ໃນໂມດູນແຫຼ່ງ, ໃຊ້ string interpolation ໃນແບບ Bash. ການນໍາໃຊ້ໄຟລ໌ແຜນທີ່ລະດັບໂມດູນ, ເຄື່ອງມືສ້າງໄຟລ໌ແຜນທີ່ລະດັບໄຟລ໌ໂດຍການສະແກນໄຟລ໌ທັງຫມົດໃນໄດເລກະທໍລີທີ່ກ່ຽວຂ້ອງ.

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

ການສ້າງແຜນທີ່ລະດັບໄຟລ໌ຖືກສ້າງຂື້ນໂດຍອັດຕະໂນມັດໂດຍເຄື່ອງມື; ຢ່າງໃດກໍຕາມ, ມັນຍັງສາມາດປັບປຸງດ້ວຍຕົນເອງໂດຍຜູ້ໃຊ້. ນີ້ແມ່ນການສ້າງແຜນທີ່ 1: 1 ຂອງໄຟລ໌ແຫຼ່ງ LinkedIn ກັບໄຟລ໌ໃນບ່ອນເກັບມ້ຽນແຫຼ່ງເປີດ. ມີຫຼາຍກົດລະບຽບທີ່ກ່ຽວຂ້ອງກັບການສ້າງໄຟລ໌ອັດຕະໂນມັດນີ້:

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

ການສ້າງບັນທຶກຄໍາຫມັ້ນສັນຍາ

ບັນທຶກການຜູກມັດສໍາລັບ open source commits ຍັງຖືກສ້າງຂື້ນໂດຍອັດຕະໂນມັດໂດຍການລວມເອົາບັນທຶກຂອງ commit ຂອງ repositories ພາຍໃນ. ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງຂອງ commit log ເພື່ອສະແດງໂຄງສ້າງຂອງ commit log ທີ່ສ້າງຂຶ້ນໂດຍເຄື່ອງມືຂອງພວກເຮົາ. commit ຊີ້ບອກຢ່າງຊັດເຈນວ່າສະບັບໃດຂອງ repositories ແຫຼ່ງໄດ້ຖືກຫຸ້ມຫໍ່ຢູ່ໃນຄໍາຫມັ້ນສັນຍານັ້ນແລະສະຫນອງບົດສະຫຼຸບຂອງບັນທຶກຂອງຄໍາຫມັ້ນສັນຍາ. ກວດເບິ່ງອັນນີ້ອອກ ຄໍາຫມັ້ນສັນຍາ ການນໍາໃຊ້ຕົວຢ່າງທີ່ແທ້ຈິງຂອງບັນທຶກຄໍາຫມັ້ນສັນຍາທີ່ສ້າງຂຶ້ນໂດຍຊຸດເຄື່ອງມືຂອງພວກເຮົາ.

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

ການທົດສອບການເພິ່ງພາອາໄສ

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

ນີ້ແມ່ນກົນໄກທີ່ເປັນປະໂຫຍດທີ່ຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ຄໍາຫມັ້ນສັນຍາພາຍໃນໃດໆທີ່ທໍາລາຍການສ້າງແຫຼ່ງເປີດແລະກວດພົບມັນໃນເວລາຄໍາຫມັ້ນສັນຍາ. ຖ້າບໍ່ມີສິ່ງນີ້, ມັນຈະເປັນການຍາກທີ່ຈະ ກຳ ນົດວ່າການກະ ທຳ ພາຍໃນໃດທີ່ເຮັດໃຫ້ການສ້າງບ່ອນເກັບມ້ຽນແຫຼ່ງເປີດລົ້ມເຫລວ, ເພາະວ່າພວກເຮົາຈັດການປ່ຽນແປງພາຍໃນກັບ DataHub open source repository.

ຄວາມແຕກຕ່າງລະຫວ່າງແຫຼ່ງເປີດ DataHub ແລະສະບັບການຜະລິດຂອງພວກເຮົາ

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

ແຫຼ່ງຫນຶ່ງຂອງຄວາມແຕກຕ່າງແມ່ນມາຈາກຄວາມຈິງທີ່ວ່າສະບັບການຜະລິດຂອງພວກເຮົາມີຄວາມຂຶ້ນກັບລະຫັດທີ່ຍັງບໍ່ທັນເປັນແຫຼ່ງເປີດ, ເຊັ່ນ: LinkedIn's Offspring (ໂຄງຮ່າງການສີດຂຶ້ນກັບພາຍໃນຂອງ LinkedIn). Offspring ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນ codebases ພາຍໃນເພາະວ່າມັນເປັນວິທີການທີ່ຕ້ອງການສໍາລັບການຄຸ້ມຄອງການຕັ້ງຄ່າແບບເຄື່ອນໄຫວ. ແຕ່ມັນບໍ່ແມ່ນແຫຼ່ງເປີດ; ດັ່ງນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງຊອກຫາທາງເລືອກແຫຼ່ງເປີດກັບ DataHub ແຫຼ່ງເປີດ.

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

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

ຕົວຢ່າງອື່ນຂອງຄວາມແຕກຕ່າງແມ່ນການມີ GMS ດຽວ (ຮ້ານ Metadata ທົ່ວໄປ) ໃນການປະຕິບັດແຫຼ່ງເປີດແທນທີ່ຈະເປັນ GMS ຫຼາຍ. GMA (Generalized Metadata Architecture) ແມ່ນຊື່ຂອງສະຖາປັດຕະຍະກຳດ້ານຫຼັງສຳລັບ DataHub, ແລະ GMS ແມ່ນບ່ອນເກັບຂໍ້ມູນ metadata ໃນບໍລິບົດຂອງ GMA. GMA ເປັນສະຖາປັດຕະຍະກໍາທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍທີ່ອະນຸຍາດໃຫ້ທ່ານແຈກຢາຍແຕ່ລະໂຄງສ້າງຂໍ້ມູນ (ເຊັ່ນ: ຊຸດຂໍ້ມູນ, ຜູ້ໃຊ້, ແລະອື່ນໆ) ເຂົ້າໄປໃນຮ້ານ metadata ຂອງຕົນເອງ, ຫຼືເກັບຮັກສາຂໍ້ມູນຫຼາຍໂຄງສ້າງຢູ່ໃນຮ້ານ metadata ດຽວຕາບໃດທີ່ການລົງທະບຽນທີ່ມີໂຄງສ້າງຂໍ້ມູນໃນແຜນທີ່. GMS ຖືກປັບປຸງ. ເພື່ອຄວາມສະດວກໃນການນໍາໃຊ້, ພວກເຮົາໄດ້ເລືອກຕົວຢ່າງ GMS ດຽວທີ່ເກັບຮັກສາຂໍ້ມູນການກໍ່ສ້າງທີ່ແຕກຕ່າງກັນທັງຫມົດໃນ DataHub ແຫຼ່ງເປີດ.

ບັນຊີລາຍຊື່ຄົບຖ້ວນຂອງຄວາມແຕກຕ່າງລະຫວ່າງສອງການປະຕິບັດແມ່ນໄດ້ຖືກມອບໃຫ້ຢູ່ໃນຕາຕະລາງຂ້າງລຸ່ມນີ້.

ຄຸນນະສົມບັດຜະລິດຕະພັນ
LinkedIn DataHub
Open Source DataHub

ໂຄງສ້າງຂໍ້ມູນທີ່ຮອງຮັບ
1) ຊຸດຂໍ້ມູນ 2) ຜູ້ໃຊ້ 3) Metrics 4) ຄຸນສົມບັດ ML 5) ຕາຕະລາງ 6) Dashboards
1) ຊຸດຂໍ້ມູນ 2) ຜູ້ໃຊ້

ແຫຼ່ງ Metadata ທີ່ຮອງຮັບສໍາລັບຊຸດຂໍ້ມູນ
1) Ambry 2) ຕຽງນອນ 3) Dalids 4) espresso 5) HDFS 6) Hive 7) Kafka 8) MongoDB 9) MySQL 10) Oracle 11) Pinot 12) Presto 12) ເປັນ 13) Teradata 13) Vector 14) Venice
Hive Kafka RDBMS

ຮ້ານຍ່ອຍ
LinkedIn Kafka
ຂັດກັນ Kafka

ການປະມວນຜົນກະແສ
ການຄຸ້ມຄອງ
ຝັງ (ແບບດ່ຽວ)

ການໃສ່ສີດການເພິ່ງພາອາໄສ & ການຕັ້ງຄ່າໄດນາມິກ
LinkedIn Offspring
ພາກຮຽນ spring

ການກໍ່ສ້າງເຄື່ອງມື
Ligradle (ຕົວຫໍ່ Gradle ພາຍໃນຂອງ LinkedIn)
Gradlew

CI / CD
CRT (CI/CD ພາຍໃນຂອງ LinkedIn)
Travis CI ແລະ ສູນກາງ docker

ຮ້ານຄ້າເມຕາເດຕາ
ແຈກຢາຍຫຼາຍ GMS: 1) ຊຸດຂໍ້ມູນ GMS 2) GMS ຜູ້ໃຊ້ 3) Metric GMS 4) ຄຸນສົມບັດ GMS 5) ແຜນຜັງ / Dashboard GMS
GMS ດຽວສໍາລັບ: 1) ຊຸດຂໍ້ມູນ 2) ຜູ້ໃຊ້

Microservices ໃນ Docker containers

Docker ງ່າຍ​ໃນ​ການ​ນໍາ​ໃຊ້​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ແລະ​ການ​ແຜ່​ກະ​ຈາຍ​ທີ່​ມີ​ ການບັນຈຸ. ທຸກໆພາກສ່ວນຂອງການບໍລິການໃນ DataHub ແມ່ນແຫຼ່ງເປີດ, ລວມທັງອົງປະກອບພື້ນຖານໂຄງລ່າງເຊັ່ນ Kafka, Elasticsearch, neo4j и MySQL, ມີຮູບພາບ Docker ຂອງຕົນເອງ. ເພື່ອຈັດວາງ Docker containers ພວກເຮົາເຄີຍໃຊ້ Docker Compose.

ຮູບທີ 2: ຖາປັດຕະຍະ DataHub *ແຫຼ່ງເປີດ **

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

datahub-gms: ບໍລິການເກັບຂໍ້ມູນ metadata

datahub-frontend: ຄໍາຮ້ອງສະຫມັກ ຫຼິ້ນ, ໃຫ້ບໍລິການໃນການໂຕ້ຕອບ DataHub.

datahub-mce-consumer: ແອັບພລິເຄຊັນ ກະແສ Kafka, ເຊິ່ງໃຊ້ການຖ່າຍທອດເຫດການການປ່ຽນແປງ metadata (MCE) ແລະປັບປຸງການເກັບຮັກສາ metadata.

datahub-mae-consumer: ຄໍາຮ້ອງສະຫມັກ ກະແສ Kafka, ເຊິ່ງໃຊ້ metadata audit event stream (MAE) ແລະສ້າງດັດສະນີຄົ້ນຫາແລະຖານຂໍ້ມູນກາຟ.

ເອກະສານ repository open source ແລະ ບົດຄວາມ blog DataHub ຕົ້ນສະບັບ ມີຂໍ້ມູນລະອຽດເພີ່ມເຕີມກ່ຽວກັບຫນ້າທີ່ຂອງການບໍລິການຕ່າງໆ.

CI/CD ໃນ DataHub ແມ່ນແຫຼ່ງເປີດ

ແຫຼ່ງເປີດ DataHub repository ໃຊ້ Travis CI ສໍາລັບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແລະ ສູນກາງ docker ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​ຢ່າງ​ຕໍ່​ເນື່ອງ​. ທັງສອງມີການເຊື່ອມໂຍງ GitHub ທີ່ດີແລະງ່າຍຕໍ່ການຕັ້ງຄ່າ. ສໍາລັບພື້ນຖານໂຄງລ່າງແຫຼ່ງເປີດສ່ວນໃຫຍ່ທີ່ພັດທະນາໂດຍຊຸມຊົນ ຫຼືບໍລິສັດເອກະຊົນ (ເຊັ່ນ. ສັບສົນ), ຮູບພາບ Docker ຖືກສ້າງຂຶ້ນແລະຖືກນໍາໄປໃຊ້ກັບ Docker Hub ເພື່ອຄວາມສະດວກໃນການນໍາໃຊ້ໂດຍຊຸມຊົນ. ຮູບພາບ Docker ໃດໆທີ່ພົບເຫັນຢູ່ໃນ Docker Hub ສາມາດຖືກນໍາໃຊ້ໄດ້ຢ່າງງ່າຍດາຍດ້ວຍຄໍາສັ່ງງ່າຍດາຍ docker ດຶງ.

ດ້ວຍທຸກໆຄໍາຫມັ້ນສັນຍາກັບ DataHub open source repository, ຮູບພາບ Docker ທັງຫມົດແມ່ນຖືກສ້າງຂຶ້ນໂດຍອັດຕະໂນມັດແລະຖືກນໍາໄປໃຊ້ກັບ Docker Hub ດ້ວຍແທັກ "ຫລ້າສຸດ". ຖ້າ Docker Hub ຖືກຕັ້ງຄ່າດ້ວຍບາງອັນ ການຕັ້ງຊື່ສາຂາການສະແດງອອກປົກກະຕິ, tags ທັງຫມົດໃນ open source repository ຍັງຖືກປ່ອຍອອກມາດ້ວຍຊື່ແທັກທີ່ສອດຄ້ອງກັນໃນ Docker Hub.

ໃຊ້ DataHub

ຕັ້ງຄ່າ DataHub ແມ່ນ​ງ່າຍ​ດາຍ​ຫຼາຍ​ແລະ​ປະ​ກອບ​ດ້ວຍ​ສາມ​ຂັ້ນ​ຕອນ​ທີ່​ງ່າຍ​ດາຍ​:

1. Clone the open source repository and run all Docker containers with docker-compose ໂດຍໃຊ້ docker-compose script ສະຫນອງໃຫ້ສໍາລັບການເລີ່ມຕົ້ນໄວ.
2. ດາວໂຫລດຂໍ້ມູນຕົວຢ່າງທີ່ສະຫນອງໃຫ້ຢູ່ໃນ repository ໂດຍໃຊ້ເຄື່ອງມືເສັ້ນຄໍາສັ່ງທີ່ສະຫນອງໃຫ້.
3. ຄົ້ນຫາ DataHub ໃນຕົວທ່ອງເວັບຂອງທ່ານ.

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

ແຜນສໍາລັບອະນາຄົດ

ໃນປັດຈຸບັນ, ທຸກໆໂຄງສ້າງພື້ນຖານຫຼືບໍລິການຈຸລະພາກສໍາລັບແຫຼ່ງເປີດ DataHub ໄດ້ຖືກສ້າງຂື້ນເປັນ Docker container, ແລະລະບົບທັງຫມົດໄດ້ຖືກຈັດຕັ້ງໂດຍໃຊ້ docker-compose. ເນື່ອງຈາກຄວາມນິຍົມແລະແຜ່ຫຼາຍ Kubernetes, ພວກເຮົາຍັງຕ້ອງການໃຫ້ການແກ້ໄຂທີ່ອີງໃສ່ Kubernetes ໃນອະນາຄົດອັນໃກ້ນີ້.

ພວກເຮົາຍັງວາງແຜນທີ່ຈະສະຫນອງການແກ້ໄຂ turnkey ສໍາລັບການນໍາໃຊ້ DataHub ໃນການບໍລິການຟັງສາທາລະນະເຊັ່ນ: ສີຟ້າສົດ, AWS ຫຼື Google Cloud. ເນື່ອງຈາກການປະກາດທີ່ຜ່ານມາກ່ຽວກັບການເຄື່ອນຍ້າຍຂອງ LinkedIn ກັບ Azure, ນີ້ຈະສອດຄ່ອງກັບການຈັດລໍາດັບຄວາມສໍາຄັນພາຍໃນຂອງທີມ metadata.

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

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