ລະບົບການວິເຄາະເຊີບເວີ

ນີ້ແມ່ນພາກທີສອງຂອງຊຸດຂອງບົດຄວາມກ່ຽວກັບລະບົບການວິເຄາະ (ການ​ເຊື່ອມ​ຕໍ່​ກັບ​ພາກ​ສ່ວນ 1​).

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

ນັກວິເຄາະລູກຄ້າ

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

ນັກວິເຄາະເຊີບເວີ

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

ຄວາມຄິດເຫັນ
Минусы

ທ່ານສາມາດປັບແຕ່ງສິ່ງທີ່ທ່ານຕ້ອງການ
ນີ້ມັກຈະມີຄວາມຫຍຸ້ງຍາກຫຼາຍແລະຕ້ອງການນັກພັດທະນາແຍກຕ່າງຫາກ

ອັນທີສອງ: ເອົາບໍລິການ SaaS (Amazon, Google, Azure) ແທນທີ່ຈະໃຊ້ມັນເອງ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບ SaaS ໃນລາຍລະອຽດເພີ່ມເຕີມໃນສ່ວນທີສາມ.

ຄວາມຄິດເຫັນ
Минусы

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

ການບໍລິຫານໄດ້ຖືກໂອນທັງຫມົດໄປສູ່ບ່າຂອງຜູ້ໃຫ້ບໍລິການ
ມັນບໍ່ໄດ້ເປັນທີ່ຮູ້ຈັກສະເຫມີວ່າແມ່ນຫຍັງຢູ່ໃນການບໍລິການ (ມັນອາດຈະບໍ່ຈໍາເປັນ)

ວິທີການເກັບກໍາການວິເຄາະເຊີຟເວີ

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

1. ການຮັບຂໍ້ມູນ

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

ອີງຕາມການ ປະກາດໃນ Quora ໃນປີ 2014, ຜູ້ສ້າງ Apache Kafka ໄດ້ຕັດສິນໃຈຕັ້ງຊື່ຊອບແວຕາມຊື່ Franz Kafka ເພາະວ່າ "ມັນເປັນລະບົບທີ່ເຫມາະສົມສໍາລັບການຂຽນ" ແລະຍ້ອນວ່າລາວຮັກວຽກງານຂອງ Kafka. — Wikipedia

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

(ຮູບ ຈາກນີ້)

ໃນເວລາດຽວກັນ, Kafka ຊ່ວຍໃຫ້ທ່ານສາມາດອ່ານເປັນຕ່ອນແລະດໍາເນີນການກະແສຂອງເຫດການໃນ mini-batches. Kafka ເປັນເຄື່ອງມືທີ່ສະດວກຫຼາຍທີ່ສາມາດປັບຂະຫນາດໄດ້ດີກັບຄວາມຕ້ອງການທີ່ເພີ່ມຂຶ້ນ (ຕົວຢ່າງ, ໂດຍສະຖານທີ່ຕັ້ງພູມສາດຂອງເຫດການ).
ປົກກະຕິແລ້ວຫນຶ່ງ shard ແມ່ນພຽງພໍ, ແຕ່ສິ່ງຕ່າງໆໄດ້ຮັບຄວາມສັບສົນຫຼາຍເມື່ອການປັບຂະຫນາດ (ຍ້ອນວ່າພວກເຂົາເຮັດສະເຫມີ). ອາດຈະບໍ່ມີໃຜຕ້ອງການໃຊ້ພຽງແຕ່ຫນຶ່ງ shard ທາງດ້ານຮ່າງກາຍໃນການຜະລິດ, ເນື່ອງຈາກວ່າສະຖາປັດຕະຕ້ອງມີຄວາມທົນທານຕໍ່ຄວາມຜິດ. ນອກເຫນືອຈາກ Kafka, ມີການແກ້ໄຂທີ່ມີຊື່ສຽງອີກອັນຫນຶ່ງ - RabbitMQ. ພວກເຮົາບໍ່ໄດ້ໃຊ້ມັນໃນການຜະລິດເປັນແຖວສໍາລັບການວິເຄາະເຫດການ (ຖ້າທ່ານມີປະສົບການດັ່ງກ່າວ, ບອກພວກເຮົາກ່ຽວກັບມັນໃນຄໍາເຫັນ!). ຢ່າງໃດກໍຕາມ, ພວກເຮົາໃຊ້ AWS Kinesis.

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

2. ກຳລັງປະມວນຜົນກະແສເຫດການ

ຫຼັງຈາກທີ່ພວກເຮົາໄດ້ກະກຽມເຫດການທັງຫມົດແລະວາງໄວ້ໃນແຖວທີ່ເຫມາະສົມ, ພວກເຮົາກ້າວໄປສູ່ຂັ້ນຕອນການປຸງແຕ່ງ. ໃນທີ່ນີ້ຂ້າພະເຈົ້າຈະບອກທ່ານກ່ຽວກັບສອງທາງເລືອກໃນການປຸງແຕ່ງທົ່ວໄປທີ່ສຸດ.
ທາງເລືອກທໍາອິດແມ່ນເພື່ອເປີດໃຊ້ Spark Streaming ໃນລະບົບ Apache. ຜະລິດຕະພັນ Apache ທັງໝົດອາໄສຢູ່ໃນ HDFS, ລະບົບໄຟລ໌ທີ່ປອດໄພທີ່ມີການຈໍາລອງໄຟລ໌. Spark Streaming ເປັນເຄື່ອງມືທີ່ໃຊ້ງ່າຍທີ່ຈັດການການຖ່າຍທອດຂໍ້ມູນ ແລະຂະໜາດໄດ້ດີ. ຢ່າງໃດກໍ່ຕາມ, ມັນອາດຈະເປັນການຍາກທີ່ຈະຮັກສາ.
ທາງເລືອກອື່ນແມ່ນການສ້າງຕົວຈັດການເຫດການຂອງທ່ານເອງ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຕ້ອງການ, ສໍາລັບຕົວຢ່າງ, ຂຽນຄໍາຮ້ອງສະຫມັກ Python, ສ້າງມັນຢູ່ໃນ Docker ແລະຈອງຄິວ Kafka. ເມື່ອ triggers ມາຮອດຕົວຈັດການ docker, ການປະມວນຜົນຈະເລີ່ມຕົ້ນ. ດ້ວຍວິທີນີ້, ທ່ານຈໍາເປັນຕ້ອງເຮັດໃຫ້ແອັບພລິເຄຊັນເຮັດວຽກຢູ່ຕະຫຼອດເວລາ.
ໃຫ້ສົມມຸດວ່າພວກເຮົາໄດ້ເລືອກເອົາຫນຶ່ງໃນທາງເລືອກທີ່ອະທິບາຍຂ້າງເທິງນີ້ແລະກ້າວໄປສູ່ການປຸງແຕ່ງຂອງມັນເອງ. ຜູ້ປຸງແຕ່ງຄວນເລີ່ມຕົ້ນໂດຍການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນ, ການກັ່ນຕອງຂີ້ເຫຍື້ອແລະເຫດການ "ແຕກຫັກ". ສໍາລັບການກວດສອບພວກເຮົາມັກຈະໃຊ້ Cerberus. ຫຼັງຈາກນີ້, ທ່ານສາມາດເຮັດແຜນທີ່ຂໍ້ມູນ: ຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆໄດ້ຖືກປັບປຸງເປັນປົກກະຕິແລະມາດຕະຖານເພື່ອຖືກເພີ່ມເຂົ້າໃນຕາຕະລາງທົ່ວໄປ.

3. ຖານຂໍ້ມູນ

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

4. ການລວບລວມ

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

5. ດ້ານໜ້າ

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

1. ຜູ້ໃຊ້ເຮັດການສອບຖາມ SQL.
2. ໃນການຕອບສະຫນອງ, ລາວໄດ້ຮັບເຄື່ອງຫມາຍ.
3. ມັນສ້າງ 'ການເບິ່ງເຫັນໃຫມ່' ສໍາລັບມັນແລະໄດ້ຮັບກາຟທີ່ສວຍງາມທີ່ທ່ານສາມາດປະຫຍັດສໍາລັບຕົວທ່ານເອງ.

Visualizations ໃນການບໍລິການແມ່ນການປັບປຸງອັດຕະໂນມັດ, ທ່ານສາມາດປັບແຕ່ງແລະຕິດຕາມການຕິດຕາມຂອງທ່ານ. Redash ແມ່ນບໍ່ເສຍຄ່າຖ້າເປັນເຈົ້າພາບ, ແຕ່ເປັນ SaaS ມັນຈະມີລາຄາ 50 ໂດລາຕໍ່ເດືອນ.

ສະຫລຸບ

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

ຂອບໃຈສໍາລັບການອ່ານ! ຂ້ອຍຈະດີໃຈທີ່ຈະຖາມຄໍາຖາມໃນຄໍາເຫັນ.

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