Delta: ແພລະຕະຟອມ synchronization ແລະປັບປຸງຂໍ້ມູນ

ໃນຄວາມຄາດຫວັງຂອງການເປີດຕົວຂອງການໄຫຼໃຫມ່ໃນອັດຕາ ວິສະວະກອນຂໍ້ມູນ ພວກເຮົາໄດ້ກະກຽມການແປພາສາຂອງເອກະສານທີ່ຫນ້າສົນໃຈ.

ພາບລວມ

ພວກເຮົາຈະເວົ້າກ່ຽວກັບຮູບແບບທີ່ຂ້ອນຂ້າງເປັນທີ່ນິຍົມໃນການນໍາໃຊ້ທີ່ເກັບຂໍ້ມູນຫຼາຍ, ບ່ອນທີ່ແຕ່ລະຮ້ານຖືກນໍາໃຊ້ເພື່ອຈຸດປະສົງຂອງຕົນເອງ, ສໍາລັບການຍົກຕົວຢ່າງ, ເກັບຮັກສາຮູບແບບ canonical ຂອງຂໍ້ມູນ (MySQL, ແລະອື່ນໆ), ສະຫນອງຄວາມສາມາດຄົ້ນຫາແບບພິເສດ (ElasticSearch, etc.) .), caching (Memcached, ແລະອື່ນໆ) ແລະອື່ນໆ. ໂດຍປົກກະຕິ, ເມື່ອນໍາໃຊ້ບ່ອນເກັບຂໍ້ມູນຫຼາຍ, ຫນຶ່ງໃນນັ້ນເຮັດຫນ້າທີ່ເປັນຮ້ານຕົ້ນຕໍແລະບ່ອນອື່ນເປັນຮ້ານອະນຸພັນ. ບັນຫາພຽງແຕ່ແມ່ນວິທີການ synchronize ເກັບຮັກສາຂໍ້ມູນເຫຼົ່ານີ້.

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

Delta ໄດ້ຖືກພັດທະນາເພື່ອແກ້ໄຂບັນຫາເຫຼົ່ານີ້. ໃນທີ່ສຸດ Delta ສະຫນອງການສອດຄ່ອງ, ເວທີການຂັບເຄື່ອນເຫດການສໍາລັບການ synchronization ຂໍ້ມູນແລະການເສີມສ້າງ.

ວິທີແກ້ໄຂທີ່ມີຢູ່

ເຂົ້າຄູ່

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

ບັນຫາ:

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

ປ່ຽນຕາຕະລາງບັນທຶກ

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

ບັນຫາ:

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

ບັນຫາອື່ນແມ່ນຢູ່ໃນການໄດ້ຮັບການປ່ຽນແປງ schema ໃນລະບົບທີ່ບໍ່ສະຫນັບສະຫນູນການປ່ຽນແປງ schema ການເຮັດທຸລະກໍາ [1][2], ເຊັ່ນ MySQL. ດັ່ງນັ້ນ, ຮູບແບບຂອງການປ່ຽນແປງ (ຕົວຢ່າງ, ການປ່ຽນແປງ schema) ແລະບັນທຶກການເຮັດທຸລະກໍາໃນຕາຕະລາງການປ່ຽນແປງຈະບໍ່ເຮັດວຽກສະເຫມີ.

ທຸລະກໍາທີ່ແຈກຢາຍ

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

ບັນຫາ:

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

Delta

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

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

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

ຮູບທີ 1. ລະບົບການລົງຄະແນນສຽງໄປຫາເຂດແດນ
ຫຼັງຈາກການນໍາໃຊ້ Delta, ລະບົບໄດ້ຖືກປັບປຸງໃຫ້ເປັນລະບົບການຂັບເຄື່ອນເຫດການດັ່ງທີ່ສະແດງຢູ່ໃນຮູບຕໍ່ໄປນີ້. ເຫດການ CDC (Change-Data-Capture) ຖືກສົ່ງໄປຫາຫົວຂໍ້ Keystone Kafka ໂດຍໃຊ້ Delta-Connector. ແອັບພລິເຄຊັນ Delta ທີ່ສ້າງຂຶ້ນໂດຍໃຊ້ Delta Stream Processing Framework (ອີງໃສ່ Flink) ໄດ້ຮັບເຫດການ CDC ຈາກຫົວຂໍ້ໃດຫນຶ່ງ, ເຮັດໃຫ້ພວກເຂົາອຸດົມສົມບູນໂດຍການໂທຫາ microservices ອື່ນໆ, ແລະສຸດທ້າຍຈະສົ່ງຂໍ້ມູນທີ່ອຸດົມສົມບູນໄປຫາດັດສະນີຄົ້ນຫາໃນ Elasticsearch. ຂະບວນການທັງຫມົດເກີດຂຶ້ນເກືອບໃນເວລາທີ່ແທ້ຈິງ, ນັ້ນແມ່ນ, ທັນທີທີ່ມີການປ່ຽນແປງໃນຄັງຂໍ້ມູນ, ດັດສະນີຄົ້ນຫາໄດ້ຖືກປັບປຸງ.

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

CDC (ປ່ຽນ-ຂໍ້ມູນ-ຈັບພາບ)

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

Delta-Connector ຮອງຮັບຄຸນສົມບັດເພີ່ມເຕີມຫຼາຍຢ່າງເຊັ່ນ:

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

ໃນປັດຈຸບັນພວກເຮົາສະຫນັບສະຫນູນ MySQL ແລະ Postgres, ລວມທັງການນໍາໃຊ້ໃນ AWS RDS ແລະ Aurora. ພວກເຮົາຍັງສະຫນັບສະຫນູນ Cassandra (multi-master). ທ່ານສາມາດຊອກຫາລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບ Delta-Connector ທີ່ນີ້ blog post.

Kafka ແລະຊັ້ນການຂົນສົ່ງ

ຊັ້ນການຂົນສົ່ງເຫດການຂອງ Delta ຖືກສ້າງຂຶ້ນໃນການບໍລິການສົ່ງຂໍ້ຄວາມຂອງເວທີ Keystone.

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

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

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

ພວກເຮົາຍັງເພີ່ມຂຶ້ນ ປັດໄຈການຈໍາລອງ ຈາກ 2 ຫາ 3 ແລະ insync replicas ຕໍາ່ສຸດທີ່ 1 ຫາ 2. ຜູ້ພິມຂຽນໃສ່ກຸ່ມນີ້ຕ້ອງການ acks ຈາກຜູ້ອື່ນທັງໝົດ, ໃຫ້ແນ່ໃຈວ່າ 2 ໃນ 3 replicas ມີຂໍ້ຄວາມໃນປະຈຸບັນຫຼາຍທີ່ສຸດທີ່ຜູ້ເຜີຍແຜ່ສົ່ງມາ.

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

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

Stream Processing Framework

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

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

ຮູບ 3. ຕົວຢ່າງຂອງການເສີມສ້າງ DSL ໃນ Delta

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

Delta Stream Processing Framework ປະກອບດ້ວຍສອງໂມດູນຫຼັກ, ໂມດູນ DSL & API ແລະໂມດູນ Runtime. ໂມດູນ DSL & API ສະຫນອງ DSL ແລະ UDF (User-Defined-Function) APIs ເພື່ອໃຫ້ຜູ້ໃຊ້ສາມາດຂຽນເຫດຜົນການປຸງແຕ່ງຂອງຕົນເອງ (ເຊັ່ນ: ການກັ່ນຕອງຫຼືການປ່ຽນແປງ). ໂມດູນ Runtime ສະຫນອງການປະຕິບັດຕົວວິເຄາະ DSL ທີ່ສ້າງຕົວແທນພາຍໃນຂອງຂັ້ນຕອນການປຸງແຕ່ງໃນຮູບແບບ DAG. ອົງປະກອບປະຕິບັດການຕີຄວາມແບບຈໍາລອງ DAG ເພື່ອເລີ່ມຕົ້ນຄໍາຖະແຫຼງການ Flink ຕົວຈິງແລະສຸດທ້າຍດໍາເນີນການຄໍາຮ້ອງສະຫມັກ Flink. ສະຖາປັດຕະຍະກໍາຂອງກອບແມ່ນສະແດງຢູ່ໃນຮູບຕໍ່ໄປນີ້.

ຮູບທີ 4. ສະຖາປັດຕະຍະກໍາ Delta Stream Processing Framework

ວິທີການນີ້ມີຂໍ້ດີຫຼາຍ:

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

ການນໍາໃຊ້ການຜະລິດ

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

ຮູບ 5. ສະຖາປັດຕະຍະກໍາລະດັບສູງຂອງ Delta.

ຂອບໃຈ

ພວກເຮົາຂໍຂອບໃຈຄົນຕໍ່ໄປນີ້ທີ່ມີສ່ວນຮ່ວມໃນການສ້າງແລະພັດທະນາ Delta ຢູ່ Netflix: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang ແລະ Zhenzhong Xu.

ແຫຼ່ງຂໍ້ມູນ

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: ການປະມວນຜົນເຫດການອອນໄລນ໌. ຊຸມຊົນ. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

ລົງທະບຽນສໍາລັບການ webinar ຟຣີ: "ເຄື່ອງມືສ້າງຂໍ້ມູນສໍາລັບການເກັບຮັກສາ Amazon Redshift."

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