ຈາກອຸປະຕິເຫດປະຈໍາວັນເພື່ອຄວາມຫມັ້ນຄົງ: Informatica 10 ຜ່ານຕາຂອງຜູ້ບໍລິຫານ

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

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

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

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

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

Informatica PowerCenter/Big Data Management ປະຈຸບັນຖືວ່າເປັນຊອບແວຊັ້ນນໍາໃນດ້ານເຄື່ອງມືການເຊື່ອມໂຍງຂໍ້ມູນ. ນີ້ແມ່ນຜະລິດຕະພັນຂອງບໍລິສັດ Informatica ອາເມລິກາ, ເຊິ່ງເປັນຫນຶ່ງໃນຜູ້ຫຼິ້ນທີ່ເຂັ້ມແຂງທີ່ສຸດໃນ ETL (Extract Transform Load), ການຄຸ້ມຄອງຄຸນນະພາບຂໍ້ມູນ, MDM (Master Data Management), ILM (Information Lifecycle Management) ແລະອື່ນໆອີກ.

PowerCenter ທີ່ພວກເຮົາໃຊ້ແມ່ນເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ Tomcat ປະສົມປະສານທີ່ແອັບພລິເຄຊັນ Informatica ຕົວເອງດໍາເນີນການ, ປະຕິບັດການບໍລິການຂອງມັນ:

ໂດເມນ, ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນພື້ນຖານສໍາລັບສິ່ງອື່ນ; ການບໍລິການ, ຜູ້ໃຊ້, ແລະອົງປະກອບ GRID ດໍາເນີນການພາຍໃນໂດເມນ.

ຄອນໂຊຜູ້ບໍລິຫານ, ເຄື່ອງມືການຄຸ້ມຄອງແລະການຕິດຕາມເວັບໄຊທ໌, ນອກເຫນືອຈາກລູກຄ້າຜູ້ພັດທະນາ Informatica, ເຄື່ອງມືຕົ້ນຕໍສໍາລັບການພົວພັນກັບຜະລິດຕະພັນ.

MRS, ບໍລິການເກັບມ້ຽນແບບຈໍາລອງ, metadata repository, ແມ່ນຊັ້ນລະຫວ່າງຖານຂໍ້ມູນທີ່ metadata ຖືກເກັບໄວ້ທາງດ້ານຮ່າງກາຍແລະລູກຄ້າ Informatica Developer ທີ່ການພັດທະນາກໍາລັງເກີດຂຶ້ນ. Repositories ເກັບລາຍລະອຽດຂໍ້ມູນແລະຂໍ້ມູນອື່ນໆ, ລວມທັງການບໍລິການ Infromatica ອື່ນ, ຕົວຢ່າງ, ຕາຕະລາງການເຮັດວຽກ (ຕາຕະລາງ) ຫຼືຂໍ້ມູນການຕິດຕາມ, ເຊັ່ນດຽວກັນກັບຕົວກໍານົດການຄໍາຮ້ອງສະຫມັກ, ໂດຍສະເພາະ, ອະນຸຍາດໃຫ້ນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກດຽວກັນສໍາລັບການເຮັດວຽກກັບ. ແຫຼ່ງຂໍ້ມູນ ແລະເຄື່ອງຮັບຕ່າງໆ.

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

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

Informatica PowerCenter, schematic

ໃນໄລຍະຕົ້ນຂອງການເຮັດວຽກເປັນສ່ວນຫນຶ່ງຂອງລະບົບຕ່ອງໂສ້ການສະຫນອງຂໍ້ມູນ, ບັນຫາທີ່ເກີດຂຶ້ນເປັນປົກກະຕິ, ບາງສ່ວນຂອງພວກເຂົາເນື່ອງຈາກການດໍາເນີນງານທີ່ບໍ່ຫມັ້ນຄົງຂອງ Informatica ໃນເວລານັ້ນ. ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ແບ່ງ​ປັນ​ບາງ​ຕອນ​ທີ່​ຫນ້າ​ຈົດ​ຈໍາ​ຂອງ saga ນີ້ - mastering Informatica 10 .

ໂລໂກ້ Informatica ອະດີດ

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

ນີ້ເກີດຂຶ້ນໄດ້ແນວໃດ

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

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

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

ສິ່ງທໍາອິດທີ່ພວກເຮົາຕ້ອງເຮັດສໍາລັບນັກພັດທະນາຂອງທີມງານຂອງພວກເຮົາແລະຜູ້ຮັບເຫມົາແມ່ນເພື່ອສະຖຽນລະພາບການເຮັດວຽກຂອງ Informatica ຕົວຂອງມັນເອງ, ເພື່ອຮັບປະກັນການເຮັດວຽກຂອງ console ບໍລິຫານເວັບ (Informatica Administrator).

ນີ້ແມ່ນວິທີທີ່ພວກເຮົາໄດ້ພົບກັບນັກພັດທະນາ Informatica ເລື້ອຍໆ

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

ຫນຶ່ງໃນຄວາມພະຍາຍາມເພື່ອໃຫ້ Informatica Monitor ເຮັດວຽກ

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

ການເລືອກພາລາມິເຕີ java ເພື່ອເຮັດໃຫ້ການເຮັດວຽກຄົງທີ່

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

ກ່ອນອື່ນ ໝົດ, MRS ແຍກຕ່າງຫາກໄດ້ຖືກສ້າງຂື້ນເພື່ອຕິດຕາມ; ຍ້ອນວ່າມັນໄດ້ຫັນອອກຕໍ່ມາ, ນີ້ແມ່ນ ໜຶ່ງ ໃນຜູ້ບໍລິໂພກຕົ້ນຕໍຂອງຊັບພະຍາກອນໃນສະພາບແວດລ້ອມຂອງພວກເຮົາ, ເພາະວ່າແຜນທີ່ຖືກເປີດຕົວຢ່າງເຂັ້ມງວດ. ຕົວກໍານົດການກ່ຽວກັບ java heap ແລະຈໍານວນອື່ນໆໄດ້ຖືກປ່ຽນແປງ.
ດັ່ງນັ້ນ, ໂດຍການປັບປຸງຕໍ່ໄປ Informatica 10.1.1, ການດໍາເນີນງານຂອງ console ແລະ monitor ໄດ້ສະຖຽນລະພາບ, ນັກພັດທະນາເລີ່ມເຮັດວຽກທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ແລະຂະບວນການປົກກະຕິໄດ້ກາຍເປັນປົກກະຕິຫຼາຍຂຶ້ນ.

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

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

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

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

ມັນຍັງເຮັດວຽກ!

ເມື່ອພວກເຮົາເລີ່ມເຮັດວຽກຢູ່ໃນໂຫມດເປົ້າຫມາຍ, Informatica ເບິ່ງຄືວ່ານີ້. ເວີຊັນຂອງ Informatica 10.1.1HF1 (HF1 ແມ່ນ HotFix1, ການປະກອບຜູ້ຂາຍຈາກສະລັບສັບຊ້ອນຂອງ EBFs) ພ້ອມກັບ EBF ທີ່ຕິດຕັ້ງເພີ່ມເຕີມ, ເຊິ່ງແກ້ໄຂບັນຫາຂອງພວກເຮົາກ່ຽວກັບການປັບຂະຫນາດແລະອື່ນໆ, ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງໃນສາມທີ່ເປັນສ່ວນຫນຶ່ງຂອງ GRID, 20 x86_64 cores. ແລະການເກັບຮັກສາ, ໃນອາເຣຊ້າອັນໃຫຍ່ຫຼວງຂອງແຜ່ນທ້ອງຖິ່ນ - ນີ້ແມ່ນການຕັ້ງຄ່າເຊີຟເວີສໍາລັບກຸ່ມ Hadoop. ໃນເຄື່ອງແມ່ຂ່າຍທີ່ຄ້າຍຄືກັນອື່ນ - Oracle DBMS ທີ່ທັງໂດເມນ Informatica ແລະກົນໄກການຄວບຄຸມ ETL ເຮັດວຽກ. ທັງຫມົດນີ້ແມ່ນຖືກກວດສອບໂດຍເຄື່ອງມືການຕິດຕາມມາດຕະຖານທີ່ໃຊ້ໃນທີມງານ (Zabbix + Grafana) ທັງສອງດ້ານ - Informatica ຕົວຂອງມັນເອງກັບການບໍລິການຂອງມັນ, ແລະຂະບວນການໂຫຼດເຂົ້າໄປໃນມັນ. ໃນປັດຈຸບັນທັງການປະຕິບັດແລະຄວາມຫມັ້ນຄົງ, ໂດຍບໍ່ມີການຄໍານຶງເຖິງປັດໃຈພາຍນອກ, ໃນປັດຈຸບັນແມ່ນຂຶ້ນກັບການຕັ້ງຄ່າທີ່ຈໍາກັດການໂຫຼດ.

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

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

ບັນຫາອື່ນທີ່ເກີດຂື້ນຈາກສະຖານະການດຽວກັນນີ້ - ບາງຄັ້ງການເປີດຕົວຫຼາຍຂອງກົນໄກການຄວບຄຸມຂອງພວກເຮົາເກີດຂື້ນ.

ການເປີດຕົວແອັບພລິເຄຊັນຫຼາຍອັນເຮັດໃຫ້ກົນໄກລົ້ມເຫລວ

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

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

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

ຄູ່ຊົ່ວຄາວໃນ MRS ບັນທຶກ "ໂດຍການອອກແບບ"

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

ພະຍາຍາມທີ່ດີທີ່ສຸດ

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

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

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

ບົດຄວາມໄດ້ຖືກກະກຽມໂດຍທີມງານຄຸ້ມຄອງຂໍ້ມູນ Rostelecom

ໂລໂກ້ Informatica ປະຈຸບັນ

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