ສົ່ງອອກໄປພື້ນທີ່ເກັບອອບເຈັກ

1. ຊ່ອງຫວ່າງທີ່ສິ່ງນີ້ຕື່ມເຕັມ

ຈົນເຖິງຕອນນີ້ ມີເສັ້ນທາງຈາກ MousePlayer ໄປຄັງຂໍ້ມູນພຽງທາງດຽວ ແລະ ນຳໄປ Google. ຖ້າໃຊ້ Snowflake, Redshift ຫຼື ClickHouse ຈະບໍ່ມີ - ແມ່ນແຕ່ທັງສາມອ່ານຈາກພື້ນທີ່ເກັບອອບເຈັກໄດ້ຢ່າງດີ.

ດັ່ງນັ້ນຂົວເຊື່ອມຈຶ່ງຂຽນໃສ່ພື້ນທີ່ເກັບອອບເຈັກແທນການຂຽນໃສ່ແຕ່ລະຄັງ. Snowflake ຮັບຈາກ S3, Redshift ຮັບຈາກ S3, ClickHouse ຮັບຈາກ S3 ແລະ BigQuery ຮັບຈາກ Google Cloud Storage. ການສົ່ງອອກດຽວເຂົ້າເຖິງທັງໝົດ.

ບ່ອນ	ວິທີລະບຸທີ່ຢູ່
Amazon S3	Signature Version 4, bucket ຢູ່ໃນໂຮສ
Cloudflare R2	Signature Version 4 ກັບ endpoint ບັນຊີ
Google Cloud Storage	ຜ່ານ API ທີ່ເຂົ້າກັບ S3 ດ້ວຍກະແຈ HMAC
MinIO, Wasabi, Backblaze B2 ແລະ ອື່ນໆ	Signature Version 4 ກັບ endpoint ຂອງທ່ານ
Azure Blob Storage	ລິ້ງ SAS ຄອນເທນເນີ - ບໍ່ມີການລົງລາຍເຊັນຝັ່ງພວກເຮົາເລີຍ

2. ເປັນຫຍັງ Azure ຈຶ່ງຕ່າງອອກໄປ ແລະ ເປັນຫຍັງຈຶ່ງດີກວ່າ

Azure Blob ບໍ່ໃຊ້ Signature Version 4; ມັນລົງລາຍເຊັນດ້ວຍ SharedKey. ພວກເຮົາອາດສ້າງລະບົບລາຍເຊັນທີສອງໄດ້. ແຕ່ຂົວເຊື່ອມເລືອກຮັບ ລິ້ງ SAS ຄອນເທນເນີ - URL ທີ່ທ່ານສ້າງໃນບັນຊີພື້ນທີ່ເກັບຂອງຕົນເອງ ເຊິ່ງມີລາຍເຊັນຢູ່ໃນນັ້ນແລ້ວ.

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

3. ໜຶ່ງອອບເຈັກຕໍ່ເປົ້າໝາຍ ແລະ ຄີເປັນວັນທີ

ພື້ນທີ່ເກັບອອບເຈັກບໍ່ມີການເພີ່ມຕໍ່ທ້າຍ. ໄຟລ໌ປະຈຳວັນຈະຕ້ອງຂຽນຄືນທັງໝົດທຸກຄັ້ງ ແລະ ສອງເປົ້າໝາຍທີ່ມາພ້ອມກັນຈະຂຽນທັບກັນ. ດັ່ງນັ້ນແຕ່ລະເປົ້າໝາຍທີ່ບັນລຸຈຶ່ງເປັນອອບເຈັກຂອງຕົນເອງ.

ສິ່ງທີ່ແລກມາແມ່ນອອບເຈັກນ້ອຍຈຳນວນຫຼາຍ; ໂຄງສ້າງຄີເຮັດໃຫ້ມັນໃຊ້ງານໄດ້:

prefix/YYYY/MM/DD/channel/session-goal.json

ຄັງຂໍ້ມູນອ່ານໜຶ່ງມື້ເປັນໜຶ່ງ partition ແລະ ການຕື່ມຍ້ອນຫຼັງເປັນການສະແກນ prefix ແທນຄຳສັ່ງຄົ້ນຫາ. ຖ້າຕ້ອງການແບ່ງຕາມໂຄງການແທນວັນທີ ໃຫ້ໃສ່ channel ID ໃນ prefix.

ແຕ່ລະອອບເຈັກເປັນ JSON ໜຶ່ງແຖວ

ຕັ້ງໃຈບໍ່ຍໍ້ໜ້າ ເພື່ອໃຫ້ອ່ານທັງ prefix ເປັນ NDJSON ໂດຍບໍ່ເປີດອອບເຈັກເທື່ອລະອັນ. ມີເວລາ, ໂຄງການ, ເຊດຊັນ, ID ລູກຄ້າ, ເປົ້າໝາຍ, ມູນຄ່າ, ສະກຸນເງິນ ແລະ ລິ້ງຫຼິ້ນການບັນທຶກຄືນ.

ຄ່າວ່າງແມ່ນ null ບໍ່ແມ່ນສູນ

ເປົ້າໝາຍທີ່ບໍ່ມີມູນຄ່າເງິນຈະຂຽນ null. ໃນຄັງຂໍ້ມູນ ສູນຈະຖືກບວກເຂົ້າຍອດລວມທີ່ບໍ່ເຄີຍມີຈິງ - ຄວາມແຕກຕ່າງລະຫວ່າງ “ບໍ່ໄດ້ຕົກລົງຈຳນວນເງິນ” ກັບ “ຈຳນວນເງິນເປັນສູນ” ຍັງຄົງຢູ່ໃນການສົ່ງອອກ.

4. ຖ້າຕອບ 403 ໃຫ້ອ່ານສ່ວນນີ້ກ່ອນ

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

ສາມສິ່ງທີ່ຕ້ອງກວດຕາມລຳດັບນີ້:

• ພາກພື້ນ, ຕາມທີ່ bucket ລາຍງານຢ່າງແມ່ນຍຳ. R2 ແລະ Google Cloud Storage ຮັບ auto ແລະ ບໍ່ກວດມັນ; ອັນອື່ນທັງໝົດກວດ.
• ສິດ prefix. ກະແຈທີ່ຈຳກັດຂອບເຂດໃຫ້ mouseplayer/ ຈະຂຽນໃສ່ mouseplayer-goals/ ບໍ່ໄດ້ - ຂີດທັບທ້າຍມີຄວາມສຳຄັນໃນ resource ARN.
• Endpoint, ສຳລັບ R2 ແລະ ພື້ນທີ່ເກັບທີ່ເຂົ້າກັບ S3. ວາງໂຮສໂດຍບໍ່ມີ https://; ພວກເຮົາລຶບມັນອອກທັງສອງກໍລະນີ ແຕ່ເສັ້ນທາງທີ່ຕໍ່ທ້າຍແມ່ນ bucket ອື່ນ.