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

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

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

ຫນ້າທໍາອິດ, ບາງຄໍາອະທິບາຍແນະນໍາ.

ຂໍ້ມູນ

ສູນປະມວນຜົນຂໍ້ມູນພັນທຸກໍາຂອງມະຫາວິທະຍາໄລຂອງພວກເຮົາໄດ້ສະໜອງຂໍ້ມູນໃຫ້ພວກເຮົາໃນຮູບແບບຂອງ TSV 25 TB. ຂ້ອຍໄດ້ຮັບພວກມັນແບ່ງອອກເປັນ 5 ຊຸດ, ຖືກບີບອັດໂດຍ Gzip, ແຕ່ລະໄຟລ໌ມີປະມານ 240 ໄຟລ໌ສີ່ກິກາໄບ. ແຕ່ລະແຖວມີຂໍ້ມູນສໍາລັບຫນຶ່ງ SNP ຈາກບຸກຄົນຫນຶ່ງ. ໃນຈໍານວນທັງຫມົດ, ຂໍ້ມູນກ່ຽວກັບ ~ 2,5 ລ້ານ SNPs ແລະ ~ 60 ພັນຄົນໄດ້ຖືກຖ່າຍທອດ. ນອກເຫນືອໄປຈາກຂໍ້ມູນ SNP, ໄຟລ໌ມີຄໍລໍາຈໍານວນຫລາຍທີ່ມີຕົວເລກສະທ້ອນໃຫ້ເຫັນເຖິງລັກສະນະຕ່າງໆ, ເຊັ່ນ: ຄວາມເຂັ້ມຂົ້ນຂອງການອ່ານ, ຄວາມຖີ່ຂອງ alleles ທີ່ແຕກຕ່າງກັນ, ແລະອື່ນໆ. ໃນຈໍານວນທັງຫມົດມີປະມານ 30 ຖັນທີ່ມີມູນຄ່າເປັນເອກະລັກ.

ເປົ້າຫມາຍ

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

ເຮັດແນວໃດບໍ່ໃຫ້ເຮັດແນວນີ້

ເພື່ອອ້າງເຖິງ cliché ທີ່ເຫມາະສົມ:

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

ພະຍາຍາມ ທຳ ອິດ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ບໍ່ມີວິທີທີ່ລາຄາຖືກທີ່ຈະວິເຄາະ 25 TB ໃນເວລາດຽວ.

ໂດຍໄດ້ຮັບຫຼັກສູດ "ວິທີການຂັ້ນສູງສໍາລັບການປຸງແຕ່ງຂໍ້ມູນໃຫຍ່" ຢູ່ມະຫາວິທະຍາໄລ Vanderbilt, ຂ້າພະເຈົ້າແນ່ໃຈວ່າ trick ແມ່ນຢູ່ໃນຖົງ. ມັນອາດຈະໃຊ້ເວລາຫນຶ່ງຊົ່ວໂມງຫຼືສອງຊົ່ວໂມງເພື່ອຕັ້ງຄ່າເຄື່ອງແມ່ຂ່າຍ Hive ເພື່ອດໍາເນີນການຜ່ານຂໍ້ມູນທັງຫມົດແລະລາຍງານຜົນໄດ້ຮັບ. ເນື່ອງຈາກຂໍ້ມູນຂອງພວກເຮົາຖືກເກັບໄວ້ໃນ AWS S3, ຂ້ອຍໄດ້ໃຊ້ບໍລິການ Athena, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານນໍາໃຊ້ຄໍາຖາມ Hive SQL ກັບຂໍ້ມູນ S3. ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຕັ້ງຄ່າ / ຍົກສູງກຸ່ມ Hive, ແລະທ່ານຍັງຈ່າຍຄ່າຂໍ້ມູນທີ່ທ່ານຊອກຫາເທົ່ານັ້ນ.

ຫຼັງຈາກທີ່ຂ້ອຍສະແດງ Athena ຂໍ້ມູນຂອງຂ້ອຍແລະຮູບແບບຂອງມັນ, ຂ້ອຍໄດ້ດໍາເນີນການທົດສອບບາງຢ່າງດ້ວຍການສອບຖາມເຊັ່ນນີ້:

select * from intensityData limit 10;

ແລະໄວໄດ້ຮັບຜົນໄດ້ຮັບທີ່ມີໂຄງສ້າງທີ່ດີ. ພ້ອມ.

ຈົນກ່ວາພວກເຮົາພະຍາຍາມນໍາໃຊ້ຂໍ້ມູນໃນການເຮັດວຽກຂອງພວກເຮົາ ...

ຂ້ອຍໄດ້ຖືກຂໍໃຫ້ດຶງຂໍ້ມູນ SNP ທັງຫມົດອອກເພື່ອທົດສອບຕົວແບບ. ຂ້າພະເຈົ້າໄດ້ດໍາເນີນການສອບຖາມ:

select * from intensityData 
where snp = 'rs123456';

...ແລະເລີ່ມລໍຖ້າ. ຫຼັງຈາກແປດນາທີແລະຫຼາຍກວ່າ 4 TB ຂອງຂໍ້ມູນທີ່ຮ້ອງຂໍ, ຂ້ອຍໄດ້ຮັບຜົນໄດ້ຮັບ. Athena ຄິດຄ່າບໍລິການໂດຍປະລິມານຂໍ້ມູນທີ່ພົບເຫັນ, $5 ຕໍ່ terabyte. ດັ່ງນັ້ນຄໍາຮ້ອງຂໍດຽວນີ້ມີມູນຄ່າ $20 ແລະການລໍຖ້າແປດນາທີ. ເພື່ອດໍາເນີນການຕົວແບບໃນຂໍ້ມູນທັງຫມົດ, ພວກເຮົາຕ້ອງລໍຖ້າ 38 ປີແລະຈ່າຍເງິນ 50 ລ້ານໂດລາ, ແນ່ນອນ, ນີ້ບໍ່ເຫມາະສົມສໍາລັບພວກເຮົາ.

ມັນຈໍາເປັນຕ້ອງໃຊ້ Parquet ...

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ຈົ່ງລະມັດລະວັງກັບຂະຫນາດຂອງໄຟລ໌ Parquet ຂອງທ່ານແລະອົງການຈັດຕັ້ງຂອງພວກເຂົາ.

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

ຂ້ອຍແລ່ນວຽກງ່າຍໆ ກາວ AWS ເພື່ອປ່ຽນ TSV ຂອງພວກເຮົາເປັນ Parquet ແລະຫຼຸດລົງໄຟລ໌ໃຫມ່ເຂົ້າໄປໃນ Athena. ມັນໃຊ້ເວລາປະມານ 5 ຊົ່ວໂມງ. ແຕ່ເມື່ອຂ້ອຍດໍາເນີນການຮ້ອງຂໍ, ມັນໃຊ້ເວລາປະມານດຽວກັນແລະເງິນຫນ້ອຍລົງເລັກນ້ອຍເພື່ອໃຫ້ສໍາເລັດ. ຄວາມຈິງແລ້ວແມ່ນວ່າ Spark, ພະຍາຍາມເພີ່ມປະສິດທິພາບຫນ້າວຽກ, ພຽງແຕ່ unpacked TSV chunks ແລະເອົາໃສ່ໃນ chunk Parquet ຂອງຕົນເອງ. ແລະເນື່ອງຈາກວ່າແຕ່ລະ chunk ມີຂະຫນາດໃຫຍ່ພຽງພໍທີ່ຈະບັນຈຸບັນທຶກທັງຫມົດຂອງປະຊາຊົນຈໍານວນຫຼາຍ, ແຕ່ລະໄຟລ໌ມີ SNPs ທັງຫມົດ, ດັ່ງນັ້ນ Spark ຕ້ອງເປີດໄຟລ໌ທັງຫມົດເພື່ອສະກັດຂໍ້ມູນທີ່ມັນຕ້ອງການ.

ຫນ້າສົນໃຈ, ປະເພດການບີບອັດແບບເລີ່ມຕົ້ນ (ແລະແນະນໍາ) ຂອງ Parquet, snappy, ບໍ່ສາມາດແບ່ງປັນໄດ້. ດັ່ງນັ້ນ, ຜູ້ປະຕິບັດແຕ່ລະຄົນໄດ້ຕິດຢູ່ໃນວຽກງານຂອງ unpacking ແລະດາວໂຫຼດຊຸດຂໍ້ມູນ 3,5 GB ເຕັມ.

ໃຫ້ເຂົ້າໃຈບັນຫາ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ການຈັດລຽງແມ່ນມີຄວາມຫຍຸ້ງຍາກ, ໂດຍສະເພາະຖ້າຂໍ້ມູນຖືກແຈກຢາຍ.

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

ຂ້ອຍຮຽນ algorithms ຢູ່ໃນວິທະຍາໄລ: "Ugh, ບໍ່ມີໃຜສົນໃຈກັບຄວາມສັບສົນຂອງຄອມພິວເຕີ້ຂອງ algorithms ການຈັດລຽງເຫຼົ່ານີ້"

ຂ້ອຍພະຍາຍາມຈັດຮຽງຢູ່ໃນຖັນໃນ 20TB #ຈຸດປະກາຍ ຕາຕະລາງ: "ເປັນຫຍັງມັນໃຊ້ເວລາດົນ?" #ຂໍ້ມູນວິທະຍາສາດ ດີ້ນລົນ.

— Nick Strayer (@NicholasStrayer) ມີນາ 11, 2019

ແນ່ນອນ AWS ບໍ່ຕ້ອງການອອກເງິນຄືນຍ້ອນເຫດຜົນ "ຂ້ອຍເປັນນັກຮຽນທີ່ຖືກລົບກວນ". ຫຼັງ​ຈາກ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ແລ່ນ​ຈັດ​ລຽງ​ລໍາ​ດັບ​ໃນ Amazon Glue​, ມັນ​ແລ່ນ​ສໍາ​ລັບ 2 ມື້​ແລະ crashed​.

ຈະເປັນແນວໃດກ່ຽວກັບການແບ່ງສ່ວນ?

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: Partitions ໃນ Spark ຕ້ອງມີຄວາມສົມດູນ.

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ມາກັບຄວາມຄິດຂອງການແບ່ງປັນຂໍ້ມູນໃນໂຄໂມໂຊມ. ມີ 23 ຂອງພວກເຂົາ (ແລະອີກຫຼາຍໆອັນຖ້າທ່ານຄໍານຶງເຖິງ DNA mitochondrial ແລະພາກພື້ນທີ່ບໍ່ມີແຜນທີ່).
ນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດແຍກຂໍ້ມູນອອກເປັນຕ່ອນນ້ອຍ. ຖ້າທ່ານເພີ່ມພຽງແຕ່ຫນຶ່ງເສັ້ນໃສ່ຫນ້າທີ່ສົ່ງອອກ Spark ໃນສະຄິບກາວ partition_by = "chr", ຫຼັງຈາກນັ້ນ, ຂໍ້ມູນຄວນຈະຖືກແບ່ງອອກເປັນ buckets.

genome ປະກອບດ້ວຍຊິ້ນຈໍານວນຫລາຍທີ່ເອີ້ນວ່າ chromosomes.

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

ຈະເປັນແນວໃດຖ້າພວກເຮົາແບ່ງມັນອອກເປັນສ່ວນນ້ອຍໆ?

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ບໍ່ເຄີຍພະຍາຍາມເຮັດ 2,5 ລ້ານພາທິຊັນເລີຍ.

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

ການແບ່ງສ່ວນ + ການຈັດຮຽງ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ການຈັດລຽງແມ່ນຍັງມີຄວາມຫຍຸ້ງຍາກ, ເຊັ່ນດຽວກັນກັບການປັບ Spark.

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

# Sparklyr snippet to partition by chr and sort w/in partition
# Join the raw data with the snp bins
raw_data
  group_by(chr) %>%
  arrange(Position) %>% 
  Spark_write_Parquet(
    path = DUMP_LOC,
    mode = 'overwrite',
    partition_by = c('chr')
  )

... ແນວໃດກໍ່ຕາມ, ວຽກງານດັ່ງກ່າວຍັງບໍ່ສໍາເລັດ. ຂ້າພະເຈົ້າໄດ້ຕັ້ງຄ່າມັນດ້ວຍວິທີຕ່າງໆ: ເພີ່ມການຈັດສັນຫນ່ວຍຄວາມຈໍາສໍາລັບແຕ່ລະ query executor, ໃຊ້ nodes ທີ່ມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງຫນ່ວຍຄວາມຈໍາ, ໃຊ້ຕົວແປການອອກອາກາດ (ຕົວແປການກະຈາຍສຽງ), ແຕ່ແຕ່ລະຄັ້ງເຫຼົ່ານີ້ກາຍເປັນມາດຕະການເຄິ່ງຫນຶ່ງ, ແລະຄ່ອຍໆ executors ໄດ້ເລີ່ມຕົ້ນ. ລົ້ມເຫລວຈົນກ່ວາທຸກສິ່ງທຸກຢ່າງຢຸດເຊົາ.

ປັບປຸງໃຫ້ທັນ: ສະນັ້ນມັນເລີ່ມຕົ້ນ. pic.twitter.com/agY4GU2ru5

— Nick Strayer (@NicholasStrayer) ອາດ 15, 2019

ຂ້ອຍກາຍເປັນຄວາມຄິດສ້າງສັນຫຼາຍຂຶ້ນ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ບາງຄັ້ງຂໍ້ມູນພິເສດຕ້ອງການການແກ້ໄຂພິເສດ.

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

ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ມາແບ່ງຕໍາແຫນ່ງເປັນປະເພດ (ອັນດັບ). ການນໍາໃຊ້ຂໍ້ມູນທີ່ດາວໂຫຼດແລ້ວ, ຂ້າພະເຈົ້າໄດ້ດໍາເນີນການຮ້ອງຂໍໃຫ້ມີບັນຊີລາຍຊື່ຂອງ SNPs ທີ່ເປັນເອກະລັກ, ຕໍາແຫນ່ງແລະໂຄໂມໂຊມຂອງພວກເຂົາ. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຈັດຮຽງຂໍ້ມູນພາຍໃນແຕ່ລະໂຄໂມໂຊມແລະເກັບກໍາ SNPs ເຂົ້າໄປໃນກຸ່ມ (bin) ຂອງຂະຫນາດທີ່ກໍານົດໄວ້. ໃຫ້ເວົ້າວ່າ 1000 SNPs ແຕ່ລະຄົນ. ນີ້ເຮັດໃຫ້ຂ້ອຍມີຄວາມສໍາພັນ SNP-to-group-per-chromosome.

ໃນທີ່ສຸດ, ຂ້າພະເຈົ້າໄດ້ສ້າງກຸ່ມ (bin) ຂອງ 75 SNPs, ເຫດຜົນຈະຖືກອະທິບາຍຂ້າງລຸ່ມນີ້.

snp_to_bin <- unique_snps %>% 
  group_by(chr) %>% 
  arrange(position) %>% 
  mutate(
    rank = 1:n()
    bin = floor(rank/snps_per_bin)
  ) %>% 
  ungroup()

ທໍາອິດລອງໃຊ້ Spark

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ການລວບລວມ Spark ແມ່ນໄວ, ແຕ່ການແບ່ງສ່ວນແມ່ນຍັງມີລາຄາແພງ.

ຂ້າພະເຈົ້າຕ້ອງການອ່ານກອບຂໍ້ມູນຂະຫນາດນ້ອຍ (2,5 ລ້ານແຖວ) ເຂົ້າໄປໃນ Spark, ສົມທົບມັນກັບຂໍ້ມູນດິບ, ແລະຫຼັງຈາກນັ້ນແບ່ງປັນມັນໂດຍຖັນທີ່ເພີ່ມໃຫມ່. bin.

# Join the raw data with the snp bins
data_w_bin <- raw_data %>%
  left_join(sdf_broadcast(snp_to_bin), by ='snp_name') %>%
  group_by(chr_bin) %>%
  arrange(Position) %>% 
  Spark_write_Parquet(
    path = DUMP_LOC,
    mode = 'overwrite',
    partition_by = c('chr_bin')
  )

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

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

ເພີ່ມ AWK

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ຢ່ານອນເມື່ອຖືກສອນພື້ນຖານ. ແນ່ນອນວ່າບາງຄົນໄດ້ແກ້ໄຂບັນຫາຂອງເຈົ້າແລ້ວໃນຊຸມປີ 1980.

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

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

ຂ້ອຍຂຽນ script Bash ເພື່ອທົດລອງໃຊ້ມັນ. ດາວໂຫຼດໜຶ່ງໃນ TSVs ທີ່ຫຸ້ມຫໍ່ແລ້ວ, ຈາກນັ້ນຖອດມັນອອກໂດຍໃຊ້ gzip ແລະຖືກສົ່ງໄປຫາ awk.

gzip -dc path/to/chunk/file.gz |
awk -F 't' 
'{print $1",..."$30">"chunked/"$chr"_chr"$15".csv"}'

ມັນເຮັດວຽກ!

ການຕື່ມຂໍ້ມູນໃສ່ແກນ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: gnu parallel - ມັນເປັນສິ່ງມະຫັດສະຈັນ, ທຸກຄົນຄວນໃຊ້ມັນ.

ການແຍກຕົວແມ່ນຂ້ອນຂ້າງຊ້າແລະເມື່ອຂ້ອຍເລີ່ມຕົ້ນ htopການກວດສອບການໃຊ້ EC2 ທີ່ມີປະສິດທິພາບ (ແລະລາຄາແພງ), ມັນໄດ້ຫັນອອກວ່າຂ້ອຍກໍາລັງໃຊ້ພຽງແຕ່ຫນຶ່ງຫຼັກແລະມີຫນ່ວຍຄວາມຈໍາປະມານ 200 MB. ເພື່ອ​ແກ້​ໄຂ​ບັນ​ຫາ​ແລະ​ບໍ່​ໄດ້​ສູນ​ເສຍ​ເງິນ​ຫຼາຍ​, ພວກ​ເຮົາ​ໄດ້​ຊອກ​ຫາ​ວິ​ທີ​ການ​ຂະ​ຫນານ​ຂອງ​ການ​ເຮັດ​ວຽກ​. ໂຊກດີ, ໃນຫນັງສືທີ່ຫນ້າປະຫລາດໃຈແທ້ໆ ວິທະຍາສາດຂໍ້ມູນຢູ່ໃນເສັ້ນຄໍາສັ່ງ ຂ້າພະເຈົ້າໄດ້ພົບເຫັນບົດໂດຍ Jeron Janssens ກ່ຽວກັບການຂະຫນານ. ຈາກມັນຂ້າພະເຈົ້າໄດ້ຮຽນຮູ້ກ່ຽວກັບ gnu parallel, ວິທີການທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍສໍາລັບການປະຕິບັດ multithreading ໃນ Unix.

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

1. ຂ້າພະເຈົ້າໄດ້ພົບເຫັນວ່າມັນເປັນໄປໄດ້ທີ່ຈະປະຕິບັດຂັ້ນຕອນການດາວໂຫຼດ S3 ໂດຍກົງໃນທໍ່, ກໍາຈັດການເກັບຮັກສາລະດັບກາງໃນແຜ່ນຢ່າງສົມບູນ. ນີ້ຫມາຍຄວາມວ່າຂ້ອຍສາມາດຫຼີກເວັ້ນການຂຽນຂໍ້ມູນດິບໃສ່ແຜ່ນແລະໃຊ້ຂະຫນາດນ້ອຍກວ່າ, ແລະດັ່ງນັ້ນ, ລາຄາຖືກກວ່າ, ການເກັບຮັກສາໃນ AWS.
2. ທີມງານ aws configure set default.s3.max_concurrent_requests 50 ເພີ່ມຈໍານວນກະທູ້ທີ່ AWS CLI ເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ (ໂດຍຄ່າເລີ່ມຕົ້ນມີ 10).
3. ຂ້ອຍໄດ້ປ່ຽນເປັນຕົວຢ່າງ EC2 ທີ່ຖືກປັບແຕ່ງສໍາລັບຄວາມໄວເຄືອຂ່າຍ, ດ້ວຍຕົວອັກສອນ n ໃນຊື່. ຂ້າພະເຈົ້າໄດ້ພົບເຫັນວ່າການສູນເສຍພະລັງງານການປຸງແຕ່ງໃນເວລາທີ່ການນໍາໃຊ້ n-instances ແມ່ນຫຼາຍກ່ວາການຊົດເຊີຍໂດຍການເພີ່ມຄວາມໄວໃນການໂຫຼດ. ສໍາລັບວຽກງານສ່ວນໃຫຍ່ຂ້ອຍໃຊ້ c5n.4xl.
4. ປ່ຽນແປງ gzip ສຸດ pigz, ນີ້ແມ່ນເຄື່ອງມື gzip ທີ່ສາມາດເຮັດສິ່ງທີ່ເຢັນເພື່ອຂະຫນານກັບວຽກງານທີ່ບໍ່ມີຂະຫນານໃນເບື້ອງຕົ້ນຂອງການບີບອັດໄຟລ໌ (ອັນນີ້ຊ່ວຍໄດ້ຫນ້ອຍທີ່ສຸດ).

# Let S3 use as many threads as it wants
aws configure set default.s3.max_concurrent_requests 50

for chunk_file in $(aws s3 ls $DATA_LOC | awk '{print $4}' | grep 'chr'$DESIRED_CHR'.csv') ; do

        aws s3 cp s3://$batch_loc$chunk_file - |
        pigz -dc |
        parallel --block 100M --pipe  
        "awk -F 't' '{print $1",..."$30">"chunked/{#}_chr"$15".csv"}'"

       # Combine all the parallel process chunks to single files
        ls chunked/ |
        cut -d '_' -f 2 |
        sort -u |
        parallel 'cat chunked/*_{} | sort -k5 -n -S 80% -t, | aws s3 cp - '$s3_dest'/batch_'$batch_num'_{}'
        
         # Clean up intermediate data
       rm chunked/*
done

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

ບໍ່ມີຫຍັງທີ່ຫວານກວ່າການເຫັນຫຼັກທັງໝົດທີ່ເຈົ້າກຳລັງຈ່າຍໃຫ້ກັບ AWS ທີ່ຖືກນໍາໃຊ້. ຂໍຂອບໃຈກັບ gnu-parallel ຂ້ອຍສາມາດ unzip ແລະແບ່ງປັນ csv 19gig ໄວເທົ່າທີ່ຂ້ອຍສາມາດດາວໂຫລດໄດ້. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ເຖິງ​ແມ່ນ​ວ່າ​ໄດ້​ຮັບ​ຈຸດ​ປະ​ກາຍ​ເພື່ອ​ດໍາ​ເນີນ​ການ​ນີ້​. #ຂໍ້ມູນວິທະຍາສາດ #ລິນຸກ pic.twitter.com/Nqyba2zqEk

— Nick Strayer (@NicholasStrayer) ອາດ 17, 2019

tweet ນີ້ຄວນຈະໄດ້ກ່າວເຖິງ 'TSV'. ອະນິຈາ.

ການ​ນໍາ​ໃຊ້​ຂໍ້​ມູນ​ທີ່​ໄດ້​ວິ​ເຄາະ​ໃຫມ່​

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: Spark ມັກຂໍ້ມູນທີ່ບໍ່ຖືກບີບອັດ ແລະບໍ່ມັກການລວມພາທິຊັນ.

ໃນປັດຈຸບັນຂໍ້ມູນແມ່ນຢູ່ໃນ S3 ໃນຮູບແບບ unpacked (ອ່ານ: ແບ່ງປັນ) ແລະເຄິ່ງຄໍາສັ່ງ, ແລະຂ້າພະເຈົ້າສາມາດກັບຄືນໄປ Spark ອີກເທື່ອຫນຶ່ງ. ຄວາມແປກໃຈລໍຖ້າຂ້ອຍຢູ່: ຂ້ອຍລົ້ມເຫລວອີກຄັ້ງທີ່ຈະບັນລຸສິ່ງທີ່ຂ້ອຍຕ້ອງການ! ມັນເປັນເລື່ອງຍາກຫຼາຍທີ່ຈະບອກ Spark ຢ່າງແທ້ຈິງວ່າຂໍ້ມູນຖືກແບ່ງປັນແນວໃດ. ແລະເຖິງແມ່ນວ່າໃນເວລາທີ່ຂ້າພະເຈົ້າເຮັດນີ້, ມັນໄດ້ຫັນອອກວ່າມີການແບ່ງປັນຫຼາຍເກີນໄປ (95 ພັນ), ແລະໃນເວລາທີ່ຂ້າພະເຈົ້າໃຊ້ coalesce ຫຼຸດຈໍານວນຂອງພວກເຂົາໄປສູ່ຂອບເຂດຈໍາກັດທີ່ສົມເຫດສົມຜົນ, ນີ້ໄດ້ທໍາລາຍການແບ່ງປັນຂອງຂ້ອຍ. ຂ້າ​ພະ​ເຈົ້າ​ແນ່​ໃຈວ່​າ​ນີ້​ສາ​ມາດ​ແກ້​ໄຂ​ໄດ້​, ແຕ່​ຫຼັງ​ຈາກ​ສອງ​ສາມ​ມື້​ຂອງ​ການ​ຊອກ​ຫາ​ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ຊອກ​ຫາ​ວິ​ທີ​ແກ້​ໄຂ​ໄດ້​. ໃນ​ທີ່​ສຸດ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ສໍາ​ເລັດ​ວຽກ​ງານ​ທັງ​ຫມົດ​ໃນ Spark​, ເຖິງ​ແມ່ນ​ວ່າ​ມັນ​ໃຊ້​ເວ​ລາ​ໃນ​ຂະ​ນະ​ທີ່​ແລະ​ການ​ແບ່ງ​ປັນ​ໄຟລ​໌ Parquet ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ມີ​ຂະ​ຫນາດ​ນ້ອຍ​ຫຼາຍ (~200 KB​)​. ຢ່າງໃດກໍຕາມ, ຂໍ້ມູນແມ່ນບ່ອນທີ່ມັນຕ້ອງການ.

ຂະ​ຫນາດ​ນ້ອຍ​ເກີນ​ໄປ​ແລະ​ບໍ່​ສະ​ເຫມີ​ພາບ​, ສິ່ງ​ມະ​ຫັດ​!

ການທົດສອບການສອບຖາມ Spark ທ້ອງຖິ່ນ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: Spark ມີ overhead ຫຼາຍເກີນໄປໃນເວລາທີ່ແກ້ໄຂບັນຫາງ່າຍດາຍ.

ໂດຍການດາວໂຫຼດຂໍ້ມູນໃນຮູບແບບທີ່ສະຫລາດ, ຂ້ອຍສາມາດທົດສອບຄວາມໄວໄດ້. ຕັ້ງຄ່າສະຄຣິບ R ເພື່ອແລ່ນເຊີບເວີ Spark ທ້ອງຖິ່ນ, ແລະຫຼັງຈາກນັ້ນໂຫລດກອບຂໍ້ມູນ Spark ຈາກບ່ອນເກັບຂໍ້ມູນກຸ່ມ Parquet (bin). ຂ້າ​ພະ​ເຈົ້າ​ພະ​ຍາ​ຍາມ​ທີ່​ຈະ​ໂຫຼດ​ຂໍ້​ມູນ​ທັງ​ຫມົດ​ແຕ່​ບໍ່​ສາ​ມາດ​ໄດ້​ຮັບ Sparklyr ເພື່ອ​ຮັບ​ຮູ້​ການ​ແບ່ງ​ປັນ​.

sc <- Spark_connect(master = "local")

desired_snp <- 'rs34771739'

# Start a timer
start_time <- Sys.time()

# Load the desired bin into Spark
intensity_data <- sc %>% 
  Spark_read_Parquet(
    name = 'intensity_data', 
    path = get_snp_location(desired_snp),
    memory = FALSE )

# Subset bin to snp and then collect to local
test_subset <- intensity_data %>% 
  filter(SNP_Name == desired_snp) %>% 
  collect()

print(Sys.time() - start_time)

ການປະຫານໃຊ້ເວລາ 29,415 ວິນາທີ. ດີກວ່າຫຼາຍ, ແຕ່ບໍ່ດີເກີນໄປສໍາລັບການທົດສອບມະຫາຊົນຂອງສິ່ງໃດ. ນອກຈາກນັ້ນ, ຂ້າພະເຈົ້າບໍ່ສາມາດເລັ່ງສິ່ງຕ່າງໆໃນຖານຄວາມຈໍາໄດ້ເພາະວ່າໃນເວລາທີ່ຂ້າພະເຈົ້າພະຍາຍາມ cache ກອບຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາ, Spark ສະເຫມີ crashed, ເຖິງແມ່ນວ່າໃນເວລາທີ່ຂ້າພະເຈົ້າຈັດສັນຫຼາຍກ່ວາ 50 GB ຂອງຫນ່ວຍຄວາມຈໍາໃຫ້ກັບຊຸດຂໍ້ມູນທີ່ມີນ້ໍາຫນັກຫນ້ອຍກວ່າ 15.

ກັບຄືນຫາ AWK

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: Associative arrays ໃນ AWK ມີປະສິດທິພາບຫຼາຍ.

ຂ້ອຍຮູ້ວ່າຂ້ອຍສາມາດບັນລຸຄວາມໄວສູງກວ່າ. ຂ້າພະເຈົ້າຈື່ໄດ້ວ່າໃນສິ່ງມະຫັດ ການສອນ AWK ໂດຍ Bruce Barnett ຂ້ອຍໄດ້ອ່ານກ່ຽວກັບຄຸນສົມບັດທີ່ເຢັນທີ່ເອີ້ນວ່າ "array ສະມາຄົມ" ໂດຍພື້ນຖານແລ້ວ, ເຫຼົ່ານີ້ແມ່ນຄູ່ມູນຄ່າທີ່ສໍາຄັນ, ເຊິ່ງສໍາລັບເຫດຜົນບາງຢ່າງຖືກເອີ້ນແຕກຕ່າງກັນໃນ AWK, ແລະດັ່ງນັ້ນຂ້າພະເຈົ້າບໍ່ຄິດຫຼາຍກ່ຽວກັບພວກມັນ. Roman Cheplyaka ຈື່ໄວ້ວ່າຄໍາວ່າ "ອາເຣສະມາຄົມ" ແມ່ນເກົ່າກວ່າຄໍາສັບ "ຄູ່ທີ່ສໍາຄັນ". ເຖິງແມ່ນວ່າທ່ານ ຊອກຫາ key-value ໃນ Google Ngram, ເຈົ້າຈະບໍ່ເຫັນຄໍານີ້ຢູ່ທີ່ນັ້ນ, ແຕ່ເຈົ້າຈະພົບເຫັນ arrays ທີ່ກ່ຽວຂ້ອງ! ນອກຈາກນັ້ນ, "ຄູ່ມູນຄ່າທີ່ສໍາຄັນ" ມັກຈະກ່ຽວຂ້ອງກັບຖານຂໍ້ມູນ, ດັ່ງນັ້ນມັນມີຄວາມຫມາຍຫຼາຍທີ່ຈະປຽບທຽບມັນກັບ hashmap. ຂ້ອຍຮູ້ວ່າຂ້ອຍສາມາດໃຊ້ associative arrays ເຫຼົ່ານີ້ເພື່ອເຊື່ອມໂຍງ SNPs ຂອງຂ້ອຍກັບຕາຕະລາງຖັງແລະຂໍ້ມູນດິບໂດຍບໍ່ຕ້ອງໃຊ້ Spark.

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

join_data.awk
BEGIN {
  FS=",";
  batch_num=substr(chunk,7,1);
  chunk_id=substr(chunk,15,2);
  while(getline < "snp_to_bin.csv") {bin[$1] = $2}
}
{
  print $0 > "chunked/chr_"chr"_bin_"bin[$1]"_"batch_num"_"chunk_id".csv"
}

ທີມງານ while(getline...) ໂຫຼດແຖວທັງໝົດຈາກກຸ່ມ CSV (bin), ຕັ້ງຖັນທຳອິດ (ຊື່ SNP) ເປັນກະແຈສຳລັບ associative array bin ແລະມູນຄ່າທີສອງ (ກຸ່ມ) ເປັນມູນຄ່າ. ຫຼັງຈາກນັ້ນ, ໃນຕັນ { }, ເຊິ່ງຖືກປະຕິບັດຢູ່ໃນທຸກເສັ້ນຂອງໄຟລ໌ຕົ້ນຕໍ, ແຕ່ລະເສັ້ນຖືກສົ່ງໄປຫາໄຟລ໌ຜົນຜະລິດ, ເຊິ່ງໄດ້ຮັບຊື່ທີ່ເປັນເອກະລັກຂຶ້ນກັບກຸ່ມ (bin): ..._bin_"bin[$1]"_....

ຕົວແປ batch_num и chunk_id ກົງກັບຂໍ້ມູນທີ່ສະໜອງໃຫ້ໂດຍທໍ່ນັ້ນ, ຫຼີກລ່ຽງສະພາບການແຂ່ງຂັນ, ແລະແຕ່ລະກະທູ້ປະຕິບັດການແລ່ນ parallel, ຂຽນໃສ່ໄຟລ໌ທີ່ເປັນເອກະລັກຂອງຕົນເອງ.

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

DESIRED_CHR='13'

# Download chromosome data from s3 and split into bins
aws s3 ls $DATA_LOC |
awk '{print $4}' |
grep 'chr'$DESIRED_CHR'.csv' |
parallel "echo 'reading {}'; aws s3 cp "$DATA_LOC"{} - | awk -v chr=""$DESIRED_CHR"" -v chunk="{}" -f split_on_chr_bin.awk"

# Combine all the parallel process chunks to single files and upload to rds using R
ls chunked/ |
cut -d '_' -f 4 |
sort -u |
parallel "echo 'zipping bin {}'; cat chunked/*_bin_{}_*.csv | ./upload_as_rds.R '$S3_DEST'/chr_'$DESIRED_CHR'_bin_{}.rds"
rm chunked/*

script ມີສອງພາກ parallel.

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

Conveyor ຈາກພາກທີສອງ parallel ໄປໂດຍຜ່ານກຸ່ມ (bin) ແລະລວມໄຟລ໌ສ່ວນບຸກຄົນຂອງເຂົາເຈົ້າເຂົ້າໄປໃນ CSV ທົ່ວໄປ c catແລະຫຼັງຈາກນັ້ນສົ່ງໃຫ້ເຂົາເຈົ້າສໍາລັບການສົ່ງອອກ.

ການອອກອາກາດໃນ R?

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ທ່ານສາມາດຕິດຕໍ່ stdin и stdout ຈາກ R script, ແລະດັ່ງນັ້ນຈິ່ງໃຊ້ມັນຢູ່ໃນທໍ່.

ທ່ານອາດຈະໄດ້ສັງເກດເຫັນເສັ້ນນີ້ຢູ່ໃນສະຄິບ Bash ຂອງທ່ານ: ...cat chunked/*_bin_{}_*.csv | ./upload_as_rds.R.... ມັນແປໄຟລ໌ກຸ່ມທີ່ຕິດກັນທັງໝົດ (bin) ເປັນ R script ຂ້າງລຸ່ມນີ້. {} ແມ່ນເຕັກນິກພິເສດ parallel, ເຊິ່ງໃສ່ຂໍ້ມູນໃດໆທີ່ມັນສົ່ງໄປຫາສາຍນ້ໍາທີ່ລະບຸໂດຍກົງເຂົ້າໄປໃນຄໍາສັ່ງຂອງມັນເອງ. ທາງເລືອກ {#} ໃຫ້ ID ກະທູ້ທີ່ເປັນເອກະລັກ, ແລະ {%} ເປັນຕົວແທນຂອງຕົວເລກບ່ອນເຮັດວຽກ (ຊ້ຳໆ, ແຕ່ບໍ່ເຄີຍພ້ອມໆກັນ). ບັນຊີລາຍຊື່ຂອງທາງເລືອກໃນການທັງຫມົດສາມາດໄດ້ຮັບການພົບເຫັນຢູ່ໃນ ເອກະສານ.

#!/usr/bin/env Rscript
library(readr)
library(aws.s3)

# Read first command line argument
data_destination <- commandArgs(trailingOnly = TRUE)[1]

data_cols <- list(SNP_Name = 'c', ...)

s3saveRDS(
  read_csv(
        file("stdin"), 
        col_names = names(data_cols),
        col_types = data_cols 
    ),
  object = data_destination
)

ເມື່ອຕົວແປ file("stdin") ສົ່ງໄປ readr::read_csv, ຂໍ້ມູນທີ່ແປເປັນ R script ແມ່ນ loaded ເຂົ້າໄປໃນກອບ, ເຊິ່ງຫຼັງຈາກນັ້ນໃນຮູບແບບ .rds- ການ​ນໍາ​ໃຊ້​ໄຟລ​໌​ aws.s3 ຂຽນໂດຍກົງກັບ S3.

RDS ແມ່ນບາງສິ່ງບາງຢ່າງເຊັ່ນ: Parquet ຮຸ່ນ junior, ໂດຍບໍ່ມີການ frills ຂອງການເກັບຮັກສາລໍາໂພງ.

ຫຼັງຈາກສໍາເລັດການຂຽນ Bash ຂ້ອຍໄດ້ຮັບມັດ .rds-files ທີ່ຕັ້ງຢູ່ໃນ S3, ເຊິ່ງອະນຸຍາດໃຫ້ຂ້ອຍໃຊ້ການບີບອັດທີ່ມີປະສິດທິພາບແລະສ້າງໃນປະເພດ.

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

ຂໍ້ຈໍາກັດ S3

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ຂໍຂອບໃຈກັບການປະຕິບັດເສັ້ນທາງທີ່ສະຫຼາດ, S3 ສາມາດຈັດການກັບໄຟລ໌ຈໍານວນຫຼາຍ.

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

ໂຟນເດີໃນ S3 ແມ່ນພຽງແຕ່ສໍາລັບການສະແດງໃຫ້ເຫັນ, ໃນຄວາມເປັນຈິງລະບົບບໍ່ສົນໃຈສັນຍາລັກ /. ຈາກໜ້າ FAQ S3.

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

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

ຈະເປັນແນວໃດກ່ຽວກັບຄວາມເຂົ້າກັນໄດ້ຂ້າມ?

ສິ່ງທີ່ຂ້ອຍໄດ້ຮຽນຮູ້: ສາເຫດອັນດັບຫນຶ່ງຂອງການເສຍເວລາແມ່ນການເພີ່ມປະສິດທິພາບວິທີການເກັບຮັກສາຂອງທ່ານກ່ອນໄວອັນຄວນ.

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

ການແບ່ງວຽກ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ຢ່າພະຍາຍາມເພີ່ມປະສິດທິພາບວຽກດ້ວຍຕົນເອງ, ໃຫ້ຄອມພິວເຕີເຮັດມັນ.

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

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈຂຽນ script ໃນ R ເພື່ອເພີ່ມປະສິດທິພາບການປຸງແຕ່ງ.

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

library(aws.s3)
library(tidyverse)

chr_sizes <- get_bucket_df(
  bucket = '...', prefix = '...', max = Inf
) %>% 
  mutate(Size = as.numeric(Size)) %>% 
  filter(Size != 0) %>% 
  mutate(
    # Extract chromosome from the file name 
    chr = str_extract(Key, 'chr.{1,4}.csv') %>%
             str_remove_all('chr|.csv')
  ) %>% 
  group_by(chr) %>% 
  summarise(total_size = sum(Size)/1e+9) # Divide to get value in GB



# A tibble: 27 x 2
   chr   total_size
   <chr>      <dbl>
 1 0           163.
 2 1           967.
 3 10          541.
 4 11          611.
 5 12          542.
 6 13          364.
 7 14          375.
 8 15          372.
 9 16          434.
10 17          443.
# … with 17 more rows

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ຂຽນຫນ້າທີ່ໃຊ້ເວລາຂະຫນາດທັງຫມົດ, shuffles ຄໍາສັ່ງຂອງ chromosomes, ແບ່ງອອກເປັນກຸ່ມ. num_jobs ແລະບອກທ່ານວ່າຂະໜາດຂອງວຽກປຸງແຕ່ງທັງໝົດມີຄວາມແຕກຕ່າງກັນແນວໃດ.

num_jobs <- 7
# How big would each job be if perfectly split?
job_size <- sum(chr_sizes$total_size)/7

shuffle_job <- function(i){
  chr_sizes %>%
    sample_frac() %>% 
    mutate(
      cum_size = cumsum(total_size),
      job_num = ceiling(cum_size/job_size)
    ) %>% 
    group_by(job_num) %>% 
    summarise(
      job_chrs = paste(chr, collapse = ','),
      total_job_size = sum(total_size)
    ) %>% 
    mutate(sd = sd(total_job_size)) %>% 
    nest(-sd)
}

shuffle_job(1)



# A tibble: 1 x 2
     sd data            
  <dbl> <list>          
1  153. <tibble [7 × 3]>

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ແລ່ນຜ່ານຫນຶ່ງພັນ shuffles ໂດຍໃຊ້ purrr ແລະເລືອກທີ່ດີທີ່ສຸດ.

1:1000 %>% 
  map_df(shuffle_job) %>% 
  filter(sd == min(sd)) %>% 
  pull(data) %>% 
  pluck(1)

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

for DESIRED_CHR in "16" "9" "7" "21" "MT"
do
# Code for processing a single chromosome
fi

ໃນທີ່ສຸດຂ້ອຍເພີ່ມຄໍາສັ່ງປິດ:

sudo shutdown -h now

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

aws ec2 run-instances ...
--tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=<<job_name>>}]" 
--user-data file://<<job_script_loc>>

ຊອງກັນເລີຍ!

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: API ຄວນຈະງ່າຍດາຍສໍາລັບ sake ຂອງຄວາມສະດວກແລະຄວາມຍືດຫຍຸ່ນຂອງການນໍາໃຊ້.

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

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

ການເກັບຂໍ້ມູນອັດສະລິຍະ

ຂ້ອຍໄດ້ຮຽນຮູ້ຫຍັງ: ຖ້າຂໍ້ມູນຂອງທ່ານຖືກກະກຽມດີ, caching ຈະງ່າຍ!

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

# Part of get_snp()
...
  # Test if our current snp data has the desired snp.
  already_have_snp <- desired_snp %in% prev_snp_results$snps_in_bin

  if(!already_have_snp){
    # Grab info on the bin of the desired snp
    snp_results <- get_snp_bin(desired_snp)

    # Download the snp's bin data
    snp_results$bin_data <- aws.s3::s3readRDS(object = snp_results$data_loc)
  } else {
    # The previous snp data contained the right bin so just use it
    snp_results <- prev_snp_results
  }
...

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

ກະລຸນາສັງເກດວ່າວັດຖຸ prev_snp_results ມີກະແຈ snps_in_bin. ນີ້ແມ່ນ array ຂອງ SNPs ທີ່ເປັນເອກະລັກທັງຫມົດໃນກຸ່ມ (bin), ຊ່ວຍໃຫ້ທ່ານສາມາດກວດສອບໄດ້ໄວວ່າທ່ານມີຂໍ້ມູນຈາກການສອບຖາມທີ່ຜ່ານມາ. ມັນຍັງເຮັດໃຫ້ມັນງ່າຍທີ່ຈະ loop ຜ່ານ SNPs ທັງຫມົດໃນກຸ່ມ (bin) ດ້ວຍລະຫັດນີ້:

# Get bin-mates
snps_in_bin <- my_snp_results$snps_in_bin

for(current_snp in snps_in_bin){
  my_snp_results <- get_snp(current_snp, my_snp_results)
  # Do something with results 
}

Результаты

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

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

ຄວາມໄວໄດ້ເພີ່ມຂຶ້ນຢ່າງເຫັນໄດ້ຊັດ. ພວກເຮົາປົກກະຕິແລ້ວສະແກນຊິ້ນສ່ວນພັນທຸກໍາທີ່ສໍາຄັນທີ່ມີປະໂຫຍດ. ກ່ອນຫນ້ານີ້, ພວກເຮົາບໍ່ສາມາດເຮັດສິ່ງນີ້ໄດ້ (ມັນກາຍເປັນລາຄາແພງເກີນໄປ), ແຕ່ໃນປັດຈຸບັນ, ຍ້ອນໂຄງສ້າງຂອງກຸ່ມ (bin) ແລະຖານຄວາມຈໍາ, ການຮ້ອງຂໍສໍາລັບ SNP ຫນຶ່ງໃຊ້ເວລາໂດຍສະເລ່ຍຫນ້ອຍກວ່າ 0,1 ວິນາທີ, ແລະການນໍາໃຊ້ຂໍ້ມູນແມ່ນດັ່ງນັ້ນ. ຕ່ໍາທີ່ຄ່າໃຊ້ຈ່າຍສໍາລັບ S3 ແມ່ນຖົ່ວດິນ.

ບໍ່ດົນມານີ້, ຂ້າພະເຈົ້າໄດ້ຮັບການປ່ຽນແປງຂອງ wrangling 25+ TB ຂອງຂໍ້ມູນ genotyping ດິບສໍາລັບຫ້ອງທົດລອງຂອງຂ້າພະເຈົ້າ. ເມື່ອຂ້ອຍເລີ່ມຕົ້ນ, ການໃຊ້ spark ໃຊ້ເວລາ 8 ນາທີ ແລະຄ່າໃຊ້ຈ່າຍ $20 ເພື່ອສອບຖາມ SNP. ຫຼັງຈາກໃຊ້ AWK+ #ສະຖິຕິ ເພື່ອປະມວນຜົນ, ມັນໃຊ້ເວລາໜ້ອຍກວ່າໜຶ່ງສ່ວນ 10 ຂອງວິນາທີ ແລະລາຄາ 0.00001 ໂດລາ. ສ່ວນຕົວຂອງຂ້ອຍ #ຂໍ້ມູນໃຫຍ່ ຊະນະ. pic.twitter.com/ANOXVGrmkk

— Nick Strayer (@NicholasStrayer) ອາດ 30, 2019

ສະຫລຸບ

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

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

ສິ່ງທີ່ຂ້ອຍໄດ້ຮຽນຮູ້:

• ບໍ່ມີວິທີທີ່ລາຄາຖືກທີ່ຈະວິເຄາະ 25 TB ໃນເວລາດຽວ;
• ຈົ່ງລະມັດລະວັງກັບຂະຫນາດຂອງໄຟລ໌ Parquet ຂອງທ່ານແລະອົງການຈັດຕັ້ງຂອງພວກເຂົາ;
• Partitions ໃນ Spark ຕ້ອງມີຄວາມສົມດູນ;
• ໂດຍທົ່ວໄປ, ບໍ່ເຄີຍພະຍາຍາມເຮັດໃຫ້ 2,5 ລ້ານພາທິຊັນ;
• ການຈັດລຽງແມ່ນຍັງມີຄວາມຫຍຸ້ງຍາກ, ເຊັ່ນດຽວກັນກັບການສ້າງຕັ້ງ Spark;
• ບາງຄັ້ງຂໍ້ມູນພິເສດຮຽກຮ້ອງໃຫ້ມີການແກ້ໄຂພິເສດ;
• ການລວບລວມ Spark ແມ່ນໄວ, ແຕ່ການແບ່ງສ່ວນແມ່ນຍັງມີລາຄາແພງ;
• ຢ່ານອນເມື່ອພວກເຂົາສອນພື້ນຖານໃຫ້ທ່ານ, ບາງຄົນອາດຈະແກ້ໄຂບັນຫາຂອງເຈົ້າແລ້ວໃນຊຸມປີ 1980;
• gnu parallel - ອັນນີ້ເປັນຂອງ magical, ທຸກຄົນຄວນໃຊ້ມັນ;
• Spark ມັກຂໍ້ມູນທີ່ບໍ່ຖືກບີບອັດແລະບໍ່ມັກການລວມພາທິຊັນ;
• Spark ມີ overhead ຫຼາຍເກີນໄປໃນເວລາທີ່ແກ້ໄຂບັນຫາງ່າຍດາຍ;
• AWK's associative arrays ມີປະສິດທິພາບຫຼາຍ;
• ທ່ານສາມາດຕິດຕໍ່ stdin и stdout ຈາກ R script, ແລະດັ່ງນັ້ນຈຶ່ງໃຊ້ມັນຢູ່ໃນທໍ່;
• ຂໍຂອບໃຈກັບການປະຕິບັດເສັ້ນທາງທີ່ສະຫລາດ, S3 ສາມາດປຸງແຕ່ງໄຟລ໌ຈໍານວນຫຼາຍ;
• ເຫດຜົນຕົ້ນຕໍສໍາລັບການເສຍເວລາແມ່ນການເພີ່ມປະສິດທິພາບວິທີການເກັບຮັກສາຂອງທ່ານກ່ອນໄວອັນຄວນ;
• ຢ່າພະຍາຍາມເພີ່ມປະສິດທິພາບວຽກງານດ້ວຍຕົນເອງ, ໃຫ້ຄອມພິວເຕີເຮັດມັນ;
• API ຄວນຈະງ່າຍດາຍສໍາລັບ sake ຂອງຄວາມສະດວກແລະຄວາມຍືດຫຍຸ່ນຂອງການນໍາໃຊ້;
• ຖ້າຂໍ້ມູນຂອງທ່ານຖືກກະກຽມດີ, caching ຈະງ່າຍ!

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