ການວິເຄາະຂໍ້ມູນແບບປະຊາທິປະໄຕຂອງ BigQuery ຂອງ Google. ພາກທີ 1

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

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

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

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

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

• ຄຳຖາມໃຫຍ່: ຄັງຂໍ້ມູນວິສາຫະກິດທີ່ມີເຄື່ອງຈັກ SQL ອີງໃສ່ Dremel, ທີ່ມີຊື່ສຽງສໍາລັບຄວາມໄວ, ຄວາມງ່າຍດາຍແລະຮັບມືກັບ ການຮຽນຮູ້ເຄື່ອງຈັກ.
• Data Studio: ເຄື່ອງມືສ້າງພາບຂໍ້ມູນຂະໜາດໃຫຍ່ດ້ວຍຄຸນສົມບັດການຮ່ວມມືທີ່ຄ້າຍຄືກັບ Google Docs.

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

ປະຫວັດຂອງຮ້ານຂໍ້ມູນ Twitter

ກ່ອນທີ່ຈະເຂົ້າໄປໃນ BigQuery, ມັນຄຸ້ມຄ່າທີ່ຈະເລົ່າຄືນປະຫວັດການເກັບຂໍ້ມູນ Twitter ສັ້ນໆ. ໃນປີ 2011, ການວິເຄາະຂໍ້ມູນ Twitter ໄດ້ດໍາເນີນຢູ່ໃນ Vertica ແລະ Hadoop. ພວກເຮົາໄດ້ໃຊ້ Pig ເພື່ອສ້າງວຽກ MapReduce Hadoop. ໃນປີ 2012, ພວກເຮົາໄດ້ປ່ຽນແທນ Pig ດ້ວຍ Scalding, ເຊິ່ງມີ Scala API ທີ່ມີຜົນປະໂຫຍດເຊັ່ນ: ຄວາມສາມາດໃນການສ້າງທໍ່ທີ່ສັບສົນແລະຄວາມງ່າຍດາຍຂອງການທົດສອບ. ຢ່າງໃດກໍຕາມ, ສໍາລັບນັກວິເຄາະຂໍ້ມູນຈໍານວນຫຼາຍແລະຜູ້ຈັດການຜະລິດຕະພັນທີ່ມີຄວາມສະດວກສະບາຍໃນການເຮັດວຽກກັບ SQL, ມັນເປັນເສັ້ນໂຄ້ງການຮຽນຮູ້ທີ່ຂ້ອນຂ້າງສູງ. ປະມານປີ 2016, ພວກເຮົາໄດ້ເລີ່ມໃຊ້ Presto ເປັນການໂຕ້ຕອບ SQL ກັບຂໍ້ມູນ Hadoop. Spark ສະເຫນີການໂຕ້ຕອບ Python, ເຊິ່ງເຮັດໃຫ້ມັນເປັນທາງເລືອກທີ່ດີສໍາລັບວິທະຍາສາດຂໍ້ມູນ ad hoc ແລະການຮຽນຮູ້ເຄື່ອງຈັກ.

ນັບຕັ້ງແຕ່ປີ 2018, ພວກເຮົາໄດ້ນໍາໃຊ້ເຄື່ອງມືດັ່ງຕໍ່ໄປນີ້ສໍາລັບການວິເຄາະຂໍ້ມູນແລະການເບິ່ງເຫັນ:

• Scalding ສໍາລັບ conveyors ການຜະລິດ
• Scalding ແລະ Spark ສໍາລັບການວິເຄາະຂໍ້ມູນສະເພາະແລະການຮຽນຮູ້ເຄື່ອງຈັກ
• Vertica ແລະ Presto ສໍາລັບການວິເຄາະ SQL ແບບພິເສດແລະການໂຕ້ຕອບ
• Druid ສໍາລັບການໂຕ້ຕອບຕ່ໍາ, ການສໍາຫຼວດແລະການເຂົ້າເຖິງ latency ຕ່ໍາຕໍ່ກັບ metrics ຊຸດເວລາ
• Tableau, Zeppelin ແລະ Pivot ສໍາລັບການເບິ່ງເຫັນຂໍ້ມູນ

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

ຄັງຂໍ້ມູນ BigQuery ຂອງ Google

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

ໃນເດືອນພະຈິກ 2018, ພວກເຮົາໄດ້ປ່ອຍຕົວ alpha ຂອງບໍລິສັດ BigQuery ແລະ Data Studio. ພວກເຮົາໄດ້ສະເໜີໃຫ້ພະນັກງານ Twitter ບາງສ່ວນຂອງສະເປຣດຊີດທີ່ໃຊ້ເລື້ອຍທີ່ສຸດຂອງພວກເຮົາດ້ວຍການອະນາໄມຂໍ້ມູນສ່ວນຕົວ. BigQuery ໄດ້ຖືກນໍາໃຊ້ໂດຍຜູ້ໃຊ້ຫຼາຍກວ່າ 250 ຄົນຈາກຫຼາຍໆທີມລວມທັງວິສະວະກໍາ, ການເງິນແລະການຕະຫຼາດ. ບໍ່ດົນມານີ້, ພວກເຂົາເຈົ້າກໍາລັງດໍາເນີນການປະມານ 8k ຄໍາຮ້ອງຂໍ, ດໍາເນີນການປະມານ 100 PB ຕໍ່ເດືອນ, ບໍ່ໄດ້ນັບຄໍາຮ້ອງຂໍທີ່ກໍານົດໄວ້. ຫຼັງຈາກໄດ້ຮັບຄໍາຕິຊົມໃນທາງບວກຫຼາຍ, ພວກເຮົາຕັດສິນໃຈກ້າວໄປຂ້າງຫນ້າແລະສະເຫນີໃຫ້ BigQuery ເປັນຊັບພະຍາກອນຕົ້ນຕໍສໍາລັບການພົວພັນກັບຂໍ້ມູນໃນ Twitter.

ນີ້ແມ່ນແຜນວາດລະດັບສູງຂອງສະຖາປັດຕະຍະກຳຄັງຂໍ້ມູນ Google BigQuery ຂອງພວກເຮົາ.

ພວກເຮົາສຳເນົາຂໍ້ມູນຈາກກຸ່ມ Hadoop ຢູ່ໃນບ່ອນໄປໃສ່ Google Cloud Storage (GCS) ໂດຍໃຊ້ເຄື່ອງມື Cloud Replicator ພາຍໃນ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາໃຊ້ Apache Airflow ເພື່ອສ້າງທໍ່ທີ່ໃຊ້ "bq_load» ເພື່ອໂຫລດຂໍ້ມູນຈາກ GCS ເຂົ້າໄປໃນ BigQuery. ພວກເຮົາໃຊ້ Presto ເພື່ອສອບຖາມຊຸດຂໍ້ມູນ Parquet ຫຼື Thrift-LZO ໃນ GCS. BQ Blaster ເປັນເຄື່ອງມື Scalding ພາຍໃນສໍາລັບການໂຫຼດຊຸດຂໍ້ມູນ HDFS Vertica ແລະ Thrift-LZO ເຂົ້າໄປໃນ BigQuery.

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

ຄວາມງ່າຍຂອງການ ນຳ ໃຊ້

ພວກເຮົາພົບວ່າມັນງ່າຍສໍາລັບຜູ້ໃຊ້ທີ່ຈະເລີ່ມຕົ້ນກັບ BigQuery ເນື່ອງຈາກວ່າມັນບໍ່ຈໍາເປັນຕ້ອງມີການຕິດຕັ້ງຊອບແວແລະຜູ້ໃຊ້ສາມາດເຂົ້າເຖິງມັນໄດ້ໂດຍຜ່ານການໂຕ້ຕອບເວັບໄຊຕ໌ intuitive. ຢ່າງໃດກໍ່ຕາມ, ຜູ້ໃຊ້ຈໍາເປັນຕ້ອງມີຄວາມຄຸ້ນເຄີຍກັບບາງລັກສະນະແລະແນວຄວາມຄິດຂອງ GCP, ລວມທັງຊັບພະຍາກອນເຊັ່ນ: ໂຄງການ, ຊຸດຂໍ້ມູນ, ແລະຕາຕະລາງ. ພວກເຮົາໄດ້ພັດທະນາອຸປະກອນການສຶກສາ ແລະບົດສອນເພື່ອຊ່ວຍຜູ້ໃຊ້ເລີ່ມຕົ້ນ. ດ້ວຍຄວາມເຂົ້າໃຈຂັ້ນພື້ນຖານທີ່ໄດ້ຮັບ, ຜູ້ໃຊ້ພົບວ່າມັນງ່າຍທີ່ຈະນໍາທາງຊຸດຂໍ້ມູນ, ເບິ່ງຕາຕະລາງແລະຂໍ້ມູນຕາຕະລາງ, ດໍາເນີນການສອບຖາມງ່າຍໆ, ແລະສະແດງຜົນໃນ Data Studio.

ເປົ້າໝາຍຂອງພວກເຮົາສຳລັບການປ້ອນຂໍ້ມູນເຂົ້າໃນ BigQuery ແມ່ນເພື່ອໃຫ້ສາມາດໂຫຼດຊຸດຂໍ້ມູນ HDFS ຫຼື GCS ໄດ້ຢ່າງບໍ່ຢຸດຢັ້ງດ້ວຍການຄລິກດຽວ. ພວກເຮົາພິຈາລະນາ Cloud Composer (ຈັດການໂດຍ Airflow) ແຕ່ບໍ່ສາມາດໃຊ້ມັນໄດ້ເນື່ອງຈາກຮູບແບບຄວາມປອດໄພຂອງການແບ່ງປັນໂດເມນທີ່ຖືກຈຳກັດຂອງພວກເຮົາ (ເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນພາກການຈັດການຂໍ້ມູນຂ້າງລຸ່ມນີ້). ພວກເຮົາໄດ້ທົດລອງໃຊ້ Google Data Transfer Service (DTS) ເພື່ອຈັດວາງວຽກ BigQuery. ໃນຂະນະທີ່ DTS ໄດ້ໄວໃນການຕັ້ງຄ່າ, ມັນບໍ່ປ່ຽນແປງໄດ້ສໍາລັບການກໍ່ສ້າງທໍ່ທີ່ມີການເພິ່ງພາອາໄສ. ສໍາລັບການປ່ອຍ alpha ຂອງພວກເຮົາ, ພວກເຮົາໄດ້ສ້າງກອບ Apache Airflow ຂອງພວກເຮົາເອງໃນ GCE ແລະກໍາລັງກະກຽມມັນເພື່ອດໍາເນີນການໃນການຜະລິດແລະສາມາດສະຫນັບສະຫນູນແຫຼ່ງຂໍ້ມູນເພີ່ມເຕີມເຊັ່ນ Vertica.

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

ຜະລິດຕະພັນ

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

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

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

ອ່ານ​ຕື່ມ:

• Data Build Tool ຫຼືສິ່ງທີ່ເປັນທົ່ວໄປລະຫວ່າງ Data Warehouse ແລະ Smoothie
• ເຂົ້າໄປໃນທະເລສາບ Delta: ການບັງຄັບໃຊ້ Schema ແລະວິວັດທະນາການ
• ຄວາມໄວສູງ Apache Parquet ໃນ Python ກັບ Apache Arrow

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