Tableau ໃນຮ້ານຂາຍຍ່ອຍ, ແທ້ບໍ?

ເວລາສໍາລັບການລາຍງານໃນ Excel ແມ່ນຫາຍໄປຢ່າງໄວວາ - ແນວໂນ້ມໄປສູ່ເຄື່ອງມືທີ່ສະດວກສໍາລັບການນໍາສະເຫນີແລະການວິເຄາະຂໍ້ມູນແມ່ນເຫັນໄດ້ໃນທຸກຂົງເຂດ. ພວກເຮົາໄດ້ປຶກສາຫາລືພາຍໃນການເປັນດິຈິຕອນຂອງການລາຍງານເປັນເວລາດົນນານແລະເລືອກລະບົບການວິເຄາະຕາບອດແລະການບໍລິການຕົນເອງ. Alexander Bezugly, ຫົວຫນ້າຝ່າຍແກ້ໄຂບັນຫາການວິເຄາະແລະການລາຍງານຂອງກຸ່ມ M.Video-Eldorado, ເວົ້າກ່ຽວກັບປະສົບການແລະຜົນໄດ້ຮັບຂອງການກໍ່ສ້າງ dashboard ສູ້ຮົບ.

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

ຂ້າງລຸ່ມນີ້ການຕັດແມ່ນກ່ຽວກັບສິ່ງທີ່ພວກເຮົາໄດ້ພົບແລະສິ່ງທີ່ພວກເຮົາໄດ້ຮຽນຮູ້ກ່ຽວກັບ.

ພວກເຮົາເລີ່ມຕົ້ນບ່ອນໃດ?

M.Video-Eldorado ມີຮູບແບບຂໍ້ມູນທີ່ມີການພັດທະນາດີ: ຂໍ້ມູນທີ່ມີໂຄງສ້າງທີ່ມີຄວາມເລິກການເກັບຮັກສາທີ່ຕ້ອງການແລະບົດລາຍງານແບບຟອມຄົງທີ່ຈໍານວນຫລາຍ (ເບິ່ງລາຍລະອຽດເພີ່ມເຕີມ ຫົວ​ຂໍ້​ນີ້). ຈາກສິ່ງເຫຼົ່ານີ້, ນັກວິເຄາະສ້າງຕາຕະລາງ pivot ຫຼືຈົດຫມາຍຂ່າວທີ່ມີຮູບແບບໃນ Excel, ຫຼືການນໍາສະເຫນີ PowerPoint ທີ່ສວຍງາມສໍາລັບຜູ້ໃຊ້ສຸດທ້າຍ.

ປະມານສອງປີກ່ອນ, ແທນທີ່ຈະເປັນບົດລາຍງານແບບຄົງທີ່, ພວກເຮົາໄດ້ເລີ່ມຕົ້ນສ້າງບົດລາຍງານການວິເຄາະໃນ SAP Analysis (Excel add-on, ສໍາຄັນເປັນຕາຕະລາງ pivot ໃນໄລຍະເຄື່ອງຈັກ OLAP). ແຕ່ເຄື່ອງມືນີ້ບໍ່ສາມາດຕອບສະຫນອງຄວາມຕ້ອງການຂອງຜູ້ໃຊ້ທັງຫມົດ; ສ່ວນໃຫຍ່ຍັງສືບຕໍ່ນໍາໃຊ້ຂໍ້ມູນທີ່ຖືກປຸງແຕ່ງໂດຍນັກວິເຄາະ.

ຜູ້ໃຊ້ສຸດທ້າຍຂອງພວກເຮົາຕົກຢູ່ໃນສາມປະເພດ:

ບໍລິຫານສູງສຸດ. ຮ້ອງຂໍຂໍ້ມູນໃນລັກສະນະທີ່ນໍາສະເຫນີໄດ້ດີແລະເຂົ້າໃຈຢ່າງຈະແຈ້ງ.

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

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

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

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

ນີ້ແມ່ນສິ່ງທີ່ຮູບແບບຂອງ dashboard ຕົ້ນຕໍຂອງພວກເຮົາເບິ່ງຄືວ່າ:

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

ລາຍລະອຽດ 1. ປະລິມານຂໍ້ມູນ

ຕາຕະລາງຕົ້ນຕໍຂອງພວກເຮົາສໍາລັບການຂາຍປະຈໍາປີໃຊ້ເວລາປະມານ 300 ລ້ານແຖວ. ເນື່ອງຈາກວ່າມັນເປັນສິ່ງຈໍາເປັນເພື່ອສະທ້ອນໃຫ້ເຫັນເຖິງນະໂຍບາຍດ້ານສໍາລັບປີທີ່ຜ່ານມາແລະປີກ່ອນ, ປະລິມານຂໍ້ມູນຂອງການຂາຍຕົວຈິງພຽງແຕ່ປະມານ 1 ຕື້ສາຍ. ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ຂໍ້​ມູນ​ທີ່​ວາງ​ແຜນ​ໄວ້​ແລະ​ຕັນ​ການ​ຂາຍ​ອອນ​ໄລ​ນ​໌​ຍັງ​ຖືກ​ເກັບ​ຮັກ​ສາ​ໄວ້​ແຍກ​ຕ່າງ​ຫາກ​. ດັ່ງນັ້ນ, ເຖິງແມ່ນວ່າພວກເຮົາໃຊ້ columnar in-memory DB SAP HANA, ຄວາມໄວຂອງການສອບຖາມທີ່ມີການຄັດເລືອກຕົວຊີ້ວັດທັງຫມົດສໍາລັບຫນຶ່ງອາທິດຈາກການເກັບຮັກສາໃນປະຈຸບັນກ່ຽວກັບການບິນແມ່ນປະມານ 15-20 ວິນາທີ. ການແກ້ໄຂບັນຫານີ້ຊີ້ໃຫ້ເຫັນເຖິງຕົວຂອງມັນເອງ - ການເພີ່ມເຕີມ materialization of data . ແຕ່ມັນຍັງມີ pitfalls, ເພີ່ມເຕີມກ່ຽວກັບພວກເຂົາຂ້າງລຸ່ມນີ້.

ລາຍລະອຽດ 2. ຕົວຊີ້ວັດທີ່ບໍ່ແມ່ນສານເສບຕິດ

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

ເພື່ອເຮັດໃຫ້ການຄິດໄລ່ຂອງທ່ານຖືກຕ້ອງ, ທ່ານສາມາດ:

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

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

ລາຍລະອຽດ 3. ການປຽບທຽບຂໍ້ມູນ

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

ການ​ປຽບ​ທຽບ​ກັບ​ໄລ​ຍະ​ທີ່​ຜ່ານ​ມາ (ມື້​ຕໍ່​ມື້​, ອາ​ທິດ​ຕໍ່​ອາ​ທິດ​, ເດືອນ​ຕໍ່​ເດືອນ​)

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

ປຽບທຽບກັບປີທີ່ຜ່ານມາ

nuance ຕົ້ນ​ຕໍ​ໃນ​ທີ່​ນີ້​ແມ່ນ​ວ່າ​ໃນ​ເວ​ລາ​ທີ່​ການ​ປຽບ​ທຽບ​ໂດຍ​ມື້​ແລະ​ອາ​ທິດ​, ທ່ານ​ບໍ່​ໄດ້​ກິນ​ມື້​ດຽວ​ກັນ​ຂອງ​ປີ​ກາຍ​ນີ້​, i.e. ທ່ານບໍ່ສາມາດພຽງແຕ່ເອົາປີປັດຈຸບັນລົບຫນຶ່ງ. ທ່ານຕ້ອງເບິ່ງມື້ຂອງອາທິດທີ່ທ່ານກໍາລັງປຽບທຽບ. ເມື່ອປຽບທຽບເດືອນ, ໃນທາງກົງກັນຂ້າມ, ທ່ານ ຈຳ ເປັນຕ້ອງເອົາວັນປະຕິທິນດຽວກັນຂອງປີທີ່ຜ່ານມາ. ນອກຈາກນີ້ຍັງມີ nuances ກັບປີ LEAP. ໃນ repositories ຕົ້ນສະບັບ, ຂໍ້ມູນທັງຫມົດແມ່ນແຈກຢາຍໂດຍມື້; ບໍ່ມີຊ່ອງຫວ່າງແຍກຕ່າງຫາກທີ່ມີອາທິດ, ເດືອນ, ຫຼືປີ. ດັ່ງນັ້ນ, ເພື່ອໃຫ້ໄດ້ຮັບການວິເຄາະພາກກາງທີ່ສົມບູນໃນຄະນະກໍາມະ, ທ່ານຈໍາເປັນຕ້ອງບໍ່ນັບໄລຍະເວລາຫນຶ່ງ, ຕົວຢ່າງຫນຶ່ງອາທິດ, ແຕ່ 4 ອາທິດ, ແລະຫຼັງຈາກນັ້ນປຽບທຽບຂໍ້ມູນເຫຼົ່ານີ້, ສະທ້ອນໃຫ້ເຫັນເຖິງນະໂຍບາຍດ້ານ, deviations. ຕາມ​ນັ້ນ​ແລ້ວ, ເຫດຜົນ​ນີ້​ເພື່ອ​ສ້າງ​ການ​ປຽບ​ທຽບ​ດ້ານ​ນະ​ໂຍ​ບາຍ​ດ້ານ​ການ​ເຄື່ອນ​ໄຫວ​ຍັງ​ສາ​ມາດ​ຖືກ​ປະ​ຕິ​ບັດ​ທັງ​ຢູ່​ໃນ Tableau ຫຼື​ຂ້າງ​ຫນ້າ​ຮ້ານ. ແມ່ນແລ້ວ, ແລະແນ່ນອນພວກເຮົາໄດ້ຮູ້ແລະຄິດກ່ຽວກັບລາຍລະອຽດເຫຼົ່ານີ້ຢູ່ໃນຂັ້ນຕອນຂອງການອອກແບບ, ແຕ່ວ່າມັນເປັນການຍາກທີ່ຈະຄາດຄະເນຜົນກະທົບຂອງພວກເຂົາຕໍ່ການປະຕິບັດຂອງ dashboard ສຸດທ້າຍ.

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

ພາກທີ 1: ຄວາມເຊື່ອໃນຕາຕະລາງ

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

ຂັ້ນ​ຕອນ​ທີ 1. ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ແມ່ນ​ມີ​ຊີ​ວິດ​, ບໍ່​ມີ​ການ​ດັດ​ແກ້ window​.

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

ຜົນໄດ້ຮັບ:

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

ຂັ້ນ​ຕອນ​ທີ 2. ພວກ​ເຮົາ​ປັບ​ກໍ​ລະ​ນີ​ການ​ສະ​ແດງ​, ບໍ່​ມີ materialization​, ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ໃນ​ການ​ບິນ​.

ພວກເຮົາໄດ້ສ້າງຕູ້ວາງສະແດງໃຫມ່ແຍກຕ່າງຫາກທີ່ຜະລິດຂໍ້ມູນທີ່ຕ້ອງການສໍາລັບ TABLEAU ທັນທີ. ໂດຍທົ່ວໄປ, ພວກເຮົາໄດ້ຮັບຜົນດີ; ພວກເຮົາຫຼຸດລົງເວລາສໍາລັບການສ້າງຕົວຊີ້ວັດທັງຫມົດໃນຫນຶ່ງອາທິດເປັນ 9-10 ວິນາທີ. ແລະພວກເຮົາຄາດຫວັງຢ່າງຈິງຈັງວ່າໃນ Tableau ເວລາຕອບສະຫນອງຂອງ dashboard ຈະເປັນ 20-30 ວິນາທີໃນເວລາເປີດຄັ້ງທໍາອິດແລະຫຼັງຈາກນັ້ນເນື່ອງຈາກ cache ຈາກ 10 ຫາ 12, ເຊິ່ງໂດຍທົ່ວໄປຈະເຫມາະສົມກັບພວກເຮົາ.

ຜົນໄດ້ຮັບ:

ຫນ້າທໍາອິດເປີດ dashboard: 4-5 ນາທີ
ຄລິກໃດນຶ່ງ: 3-4 ນາທີ
ບໍ່ມີໃຜຄາດຫວັງວ່າການເພີ່ມຂື້ນດັ່ງກ່າວໃນການເຮັດວຽກຂອງຫນ້າຮ້ານ.

ສ່ວນທີ 2. Dive into Tableau

ຂັ້ນຕອນທີ 1. ການວິເຄາະປະສິດທິພາບຂອງຕາຕະລາງ ແລະ ການປັບໄວ

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

- ການ​ຖ່າຍ​ໂອນ​ຂໍ້​ມູນ​. ເນື່ອງຈາກ Tableau ບໍ່ມີເຄື່ອງມືສໍາລັບການຖ່າຍທອດຊຸດຂໍ້ມູນ, ເພື່ອສ້າງດ້ານຊ້າຍຂອງ dashboard ດ້ວຍການເປັນຕົວແທນລາຍລະອຽດຂອງ KPIs ທັງຫມົດ, ພວກເຮົາຕ້ອງສ້າງຕາຕະລາງໂດຍໃຊ້ກໍລະນີ. ຂະຫນາດຂອງການສອບຖາມ SQL ໃນຖານຂໍ້ມູນບັນລຸ 120 ຕົວອັກສອນ.

- ທາງ​ເລືອກ​ຂອງ​ໄລ​ຍະ​ເວ​ລາ​. ການສອບຖາມດັ່ງກ່າວໃນລະດັບຖານຂໍ້ມູນໃຊ້ເວລາຫຼາຍກວ່າທີ່ຈະລວບລວມກ່ວາການປະຕິບັດ:

ເຫຼົ່ານັ້ນ. ຮ້ອງຂໍການປະມວນຜົນ 12 ວິນາທີ + 5 ວິນາທີປະຕິບັດ.

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

ຫນ້າທໍາອິດ, ພວກເຮົາໄດ້ເຮັດການຫັນປ່ຽນໃນການບິນ, ພວກເຮົາໄດ້ເຮັດມັນໂດຍຜ່ານການເຂົ້າຮ່ວມພາຍນອກຢ່າງເຕັມທີ່ໃນຂັ້ນຕອນສຸດທ້າຍຂອງການຄິດໄລ່ VIEW, ອີງຕາມວິທີການນີ້ອະທິບາຍຢູ່ໃນ wiki. Transpose - ວິກິພີເດຍ, ສານຸກົມຟຣີ и ມາຕຣິກເບື້ອງປະຖົມ - Wikipedia, encyclopedia ຟຣີ.

ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ສ້າງຕາຕະລາງການຕັ້ງ - ຕາຕະລາງການປ່ຽນ (21x21) ແລະໄດ້ຮັບຕົວຊີ້ວັດທັງຫມົດໃນການແບ່ງແຖວຕໍ່ແຖວ.

ແມ່ນ:


ມັນໄດ້ກາຍເປັນ:


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

ດັ່ງນັ້ນ, ຄວາມໄວຂອງ dashboard ຫຼຸດລົງເກືອບ 3 ເທົ່າ.

ຜົນໄດ້ຮັບ:

1. 5 ວິນາທີ – parsing dashboards, visualizations
2. 15-20 ວິ​ນາ​ທີ - ການ​ກະ​ກຽມ​ສໍາ​ລັບ​ການ​ສັງ​ລວມ​ການ​ສອບ​ຖາມ​ທີ່​ມີ​ການ​ປະ​ຕິ​ບັດ​ການ​ຄິດ​ໄລ່​ລ່ວງ​ຫນ້າ​ໃນ Tableau
3. 35-45 ວິນາທີ - ການລວບລວມຄໍາຖາມ SQL ແລະການປະຕິບັດຕາມລໍາດັບຂະຫນານຂອງພວກເຂົາໃນ Hana
4. 5 ວິ​ນາ​ທີ – ການ​ປຸງ​ແຕ່ງ​ຜົນ​ໄດ້​ຮັບ​, ການ​ຄັດ​ເລືອກ​, recalculating visualizations ໃນ Tableau​
5. ແນ່ນອນ, ຜົນໄດ້ຮັບດັ່ງກ່າວບໍ່ເຫມາະສົມກັບທຸລະກິດ, ແລະພວກເຮົາສືບຕໍ່ການເພີ່ມປະສິດທິພາບ.

ຂັ້ນ​ຕອນ​ທີ 2. ຕາມ​ເຫດ​ຜົນ​ຕໍາ​່​ສຸດ​ທີ່​ໃນ Tableau​, ອຸ​ປະ​ກອນ​ການ​ຄົບ​ຖ້ວນ​ສົມ​ບູນ​

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

ດັ່ງນັ້ນ, ໃນຂັ້ນຕອນສຸດທ້າຍນີ້, ພວກເຮົາປະກອບ repository ແຍກຕ່າງຫາກທີ່ພວກເຮົາໄດ້ເພີ່ມ KPIs ທັງຫມົດໃນຮູບແບບ transposed. ໃນດ້ານຖານຂໍ້ມູນ, ການຮ້ອງຂໍໃດໆຕໍ່ການເກັບຮັກສາດັ່ງກ່າວຈະຖືກປະມວນຜົນໃນ 0,1 - 0,3 ວິນາທີ. ໃນ dashboard ພວກເຮົາໄດ້ຮັບຜົນໄດ້ຮັບດັ່ງຕໍ່ໄປນີ້:

ເປີດຄັ້ງທໍາອິດ: 8-10 ວິນາທີ
ຄລິກໃດນຶ່ງ: 6-7 ວິນາທີ

ເວລາທີ່ໃຊ້ໂດຍ Tableau ປະກອບດ້ວຍ:

1. 0,3 ວິ. - ການວິເຄາະ dashboard ແລະການລວບລວມການສອບຖາມ SQL
2. 1,5-3 ວິ. - ການ​ປະ​ຕິ​ບັດ​ຂອງ​ການ​ສອບ​ຖາມ SQL ໃນ Hana ສໍາ​ລັບ​ການ​ສາຍ​ຕາ​ຕົ້ນ​ຕໍ (ແລ່ນ​ຂະ​ຫນານ​ກັບ​ຂັ້ນ​ຕອນ​ທີ 1​)
3. 1,5-2 ວິນາທີ. - ການ​ສະ​ແດງ​, ການ​ຄິດ​ໄລ່​ຂອງ​ການ​ສະ​ແດງ​ໃຫ້​ເຫັນ​
4. 1,3 ວິນາທີ - ການ​ປະ​ຕິ​ບັດ​ການ​ສອບ​ຖາມ SQL ເພີ່ມ​ເຕີມ​ເພື່ອ​ໃຫ້​ໄດ້​ຮັບ​ຄຸນ​ຄ່າ​ການ​ກັ່ນ​ຕອງ​ທີ່​ກ່ຽວ​ຂ້ອງ (ຍີ່​ຫໍ້​, ພະ​ແນກ​, ເມືອງ​, ຮ້ານ​)​, parsing ຜົນ​ໄດ້​ຮັບ

ເພື່ອສະຫຼຸບມັນສັ້ນໆ

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

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

1. Tableau ບໍ່ສາມາດເຮັດວຽກກັບຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍ. ຖ້າຢູ່ໃນຮູບແບບຂໍ້ມູນຕົ້ນສະບັບທ່ານມີຂໍ້ມູນຫຼາຍກວ່າ 10 GB (ປະມານ 200 ລ້ານ X 50 ແຖວ), ຫຼັງຈາກນັ້ນ dashboard ຈະຊ້າລົງຢ່າງຈິງຈັງ - ຈາກ 10 ວິນາທີຫາຫຼາຍນາທີສໍາລັບການຄລິກແຕ່ລະຄົນ. ພວກ​ເຮົາ​ໄດ້​ທົດ​ລອງ​ມີ​ທັງ​ການ​ເຊື່ອມ​ຕໍ່​ສົດ​ແລະ​ການ​ສະ​ກັດ​. ຄວາມໄວໃນການດໍາເນີນງານແມ່ນທຽບເທົ່າ.
2. ຂໍ້ຈໍາກັດໃນເວລາທີ່ການນໍາໃຊ້ການເກັບຮັກສາຫຼາຍ (ຊຸດຂໍ້ມູນ). ບໍ່ມີວິທີທີ່ຈະຊີ້ບອກຄວາມສໍາພັນລະຫວ່າງຊຸດຂໍ້ມູນໂດຍໃຊ້ວິທີການມາດຕະຖານ. ຖ້າທ່ານໃຊ້ວິທີການແກ້ໄຂເພື່ອເຊື່ອມຕໍ່ຊຸດຂໍ້ມູນ, ນີ້ຈະມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ການປະຕິບັດ. ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາໄດ້ພິຈາລະນາທາງເລືອກຂອງການສ້າງຂໍ້ມູນໃນແຕ່ລະພາກເບິ່ງທີ່ຕ້ອງການແລະເຮັດການປ່ຽນຊຸດຂໍ້ມູນວັດສະດຸເຫຼົ່ານີ້ໃນຂະນະທີ່ຮັກສາຕົວກອງທີ່ເລືອກໄວ້ກ່ອນຫນ້ານີ້ - ນີ້ໄດ້ກາຍເປັນສິ່ງທີ່ເປັນໄປບໍ່ໄດ້ໃນ Tableau.
3. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະສ້າງພາລາມິເຕີແບບເຄື່ອນໄຫວໃນ Tableau. ທ່ານບໍ່ສາມາດຕື່ມໃສ່ພາລາມິເຕີທີ່ຖືກນໍາໃຊ້ເພື່ອການກັ່ນຕອງຊຸດຂໍ້ມູນໃນສານສະກັດຈາກຫຼືໃນລະຫວ່າງການເຊື່ອມຕໍ່ສົດກັບຜົນຂອງການເລືອກອື່ນຈາກຊຸດຂໍ້ມູນຫຼືຜົນຂອງການສອບຖາມ SQL ອື່ນ, ພຽງແຕ່ການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້ພື້ນເມືອງຫຼືຄົງທີ່.
4. ຂໍ້ຈໍາກັດທີ່ກ່ຽວຂ້ອງກັບການສ້າງ dashboard ທີ່ມີອົງປະກອບ OLAP|PivotTable.
   ໃນ MSTR, SAP SAC, SAP ການວິເຄາະ, ຖ້າທ່ານເພີ່ມຊຸດຂໍ້ມູນເຂົ້າໃນບົດລາຍງານ, ຫຼັງຈາກນັ້ນ, ວັດຖຸທັງຫມົດທີ່ຢູ່ໃນນັ້ນແມ່ນກ່ຽວຂ້ອງກັບກັນແລະກັນໂດຍຄ່າເລີ່ມຕົ້ນ. Tableau ບໍ່ມີອັນນີ້; ການເຊື່ອມຕໍ່ຕ້ອງຖືກຕັ້ງຄ່າດ້ວຍຕົນເອງ. ນີ້ອາດຈະມີຄວາມຍືດຫຍຸ່ນຫຼາຍ, ແຕ່ສໍາລັບ dashboards ຂອງພວກເຮົາທັງຫມົດນີ້ແມ່ນຄວາມຕ້ອງການທີ່ຈໍາເປັນສໍາລັບອົງປະກອບ - ດັ່ງນັ້ນນີ້ແມ່ນຄ່າໃຊ້ຈ່າຍແຮງງານເພີ່ມເຕີມ. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າທ່ານເຮັດຕົວກອງທີ່ກ່ຽວຂ້ອງ, ຕົວຢ່າງເຊັ່ນ, ເມື່ອການກັ່ນຕອງພາກພື້ນ, ບັນຊີລາຍຊື່ຂອງເມືອງຖືກຈໍາກັດພຽງແຕ່ເມືອງຂອງພາກພື້ນນີ້, ທ່ານທັນທີທັນໃດກັບການສອບຖາມຢ່າງຕໍ່ເນື່ອງກັບຖານຂໍ້ມູນຫຼືສະກັດ, ເຊິ່ງສັງເກດເຫັນຊ້າລົງ. ແຜງໜ້າປັດ.
5. ຂໍ້ຈໍາກັດໃນຫນ້າທີ່. ການຫັນປ່ຽນມະຫາຊົນບໍ່ສາມາດເຮັດໄດ້ບໍ່ວ່າຈະຢູ່ໃນສານສະກັດຫຼື, ໂດຍສະເພາະ, ໃນຊຸດຂໍ້ມູນຈາກ Live-connecta. ນີ້ສາມາດເຮັດໄດ້ໂດຍຜ່ານ Tableau Prep, ແຕ່ມັນເປັນວຽກເພີ່ມເຕີມແລະເຄື່ອງມືອື່ນທີ່ຈະຮຽນຮູ້ແລະຮັກສາ. ຕົວຢ່າງ, ທ່ານບໍ່ສາມາດຖ່າຍທອດຂໍ້ມູນ ຫຼືເຂົ້າຮ່ວມກັບມັນເອງໄດ້. ສິ່ງທີ່ປິດໂດຍຜ່ານການຫັນປ່ຽນຢູ່ໃນແຕ່ລະຄໍລໍາຫຼືຊ່ອງຂໍ້ມູນ, ເຊິ່ງຕ້ອງໄດ້ຮັບການຄັດເລືອກຜ່ານກໍລະນີຫຼືຖ້າ, ແລະນີ້ສ້າງແບບສອບຖາມ SQL ທີ່ສັບສົນຫຼາຍ, ເຊິ່ງຖານຂໍ້ມູນໃຊ້ເວລາສ່ວນໃຫຍ່ໃນການລວບລວມຂໍ້ຄວາມສອບຖາມ. ຄວາມບໍ່ຍືດຫຍຸ່ນເຫຼົ່ານີ້ຂອງເຄື່ອງມືຕ້ອງໄດ້ຮັບການແກ້ໄຂໃນລະດັບ showcase, ເຊິ່ງເຮັດໃຫ້ການເກັບຮັກສາສະລັບສັບຊ້ອນຫຼາຍ, ການດາວໂຫຼດເພີ່ມເຕີມແລະການຫັນປ່ຽນ.

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

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

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

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