ការនាំចេញទៅឃ្លាំងវត្ថុ
វត្ថុ JSON មួយក្នុងមួយគោលដៅដែលបានសម្រេច ក្នុងបាក់កេតដែលជាកម្មសិទ្ធិផ្ទាល់។ នេះជាផ្លូវទៅឃ្លាំងទិន្នន័យទាំងអស់ដែលមិនមែន BigQuery។
1. គម្លាតដែលវាបំពេញ
រហូតមកដល់ពេលនេះ មានផ្លូវតែមួយពី MousePlayer ទៅឃ្លាំងទិន្នន័យ ហើយវានាំទៅ Google។ បើប្រើ Snowflake, Redshift ឬ ClickHouse គ្មានផ្លូវទេ ទោះបីទាំងបីអានពីឃ្លាំងវត្ថុបានយ៉ាងរលូន។
ដូច្នេះស្ពានសរសេរទៅឃ្លាំងវត្ថុ ជំនួសឃ្លាំងទិន្នន័យនីមួយៗ។ Snowflake ទទួលពី S3, Redshift ទទួលពី S3, ClickHouse ទទួលពី S3 ហើយ BigQuery ទទួលពី Google Cloud Storage។ ការនាំចេញមួយទៅដល់ទាំងអស់។
| ទីតាំង | របៀបកំណត់អាសយដ្ឋាន |
|---|---|
| Amazon S3 | Signature Version 4 ដាក់បាក់កេតក្នុងម៉ាស៊ីន |
| Cloudflare R2 | Signature Version 4 ទៅចំណុចបញ្ចប់គណនី |
| Google Cloud Storage | តាម API ដែលត្រូវគ្នានឹង S3 ជាមួយសោ HMAC |
| MinIO, Wasabi, Backblaze B2 និងផ្សេងទៀត | Signature Version 4 ទៅចំណុចបញ្ចប់ផ្ទាល់ |
| Azure Blob Storage | តំណ SAS កុងតឺន័រ គ្មានការចុះហត្ថលេខានៅខាងយើងទាល់តែសោះ |
2. ហេតុអ្វី Azure ខុសគេ ហើយហេតុអ្វីវាប្រសើរជាង
Azure Blob មិនប្រើ Signature Version 4 ទេ តែចុះហត្ថលេខាដោយ SharedKey។ យើងអាចបង្កើតប្រព័ន្ធហត្ថលេខាទីពីរ។ ផ្ទុយទៅវិញ ស្ពានទទួល តំណ SAS កុងតឺន័រ គឺ URL ដែលបង្កើតក្នុងគណនីឃ្លាំងផ្ទាល់ ដោយមានហត្ថលេខាក្នុងវារួចហើយ។
នេះកាត់បន្ថយកូដខាងយើង និងកម្រិតទំនុកចិត្តដែលត្រូវផ្តល់ខាងអ្នកប្រើ។ យើងមិនឃើញសោគណនីទាល់តែសោះ៖ អ្វីដែលផ្តល់គឺសិទ្ធិដែលកំណត់វិសាលភាពផ្ទាល់ ទៅកុងតឺន័រមួយ មានកាលបរិច្ឆេទផុតកំណត់ដែលជ្រើស ហើយដកហូតបានគ្រប់ពេលដោយមិនប៉ះពាល់អ្វីផ្សេង។
គួរអនុវត្តការរឹតត្បិតដូចគ្នានៅខាង S3៖ ផ្តល់សោចូលប្រើតែសិទ្ធិសរសេរទៅ បុព្វបទតែមួយនេះ ហើយគ្មានអ្វីផ្សេង។ សោដែលអាចបន្ថែមតែទៅ mouseplayer/goals/ មិនអាចអានបាក់កេតផ្សេង សូម្បីតែលេចធ្លាយ។
3. វត្ថុមួយក្នុងមួយគោលដៅ ហើយសោជាកាលបរិច្ឆេទ
ឃ្លាំងវត្ថុគ្មានមុខងារបន្ថែមចុងឯកសារ។ ឯកសារប្រចាំថ្ងៃត្រូវសរសេរឡើងវិញទាំងមូលរាល់ពេល ហើយគោលដៅពីរដែលមកព្រមគ្នានឹងសរសេរជាន់គ្នា។ ដូច្នេះគោលដៅដែលបានសម្រេចនីមួយៗក្លាយជាវត្ថុផ្ទាល់។
ផលប៉ះពាល់គឺមានវត្ថុតូចៗច្រើន ហើយប្លង់សោធ្វើឱ្យវាអាចប្រើការបាន៖
prefix/YYYY/MM/DD/channel/session-goal.json
ឃ្លាំងទិន្នន័យអានមួយថ្ងៃជាភាគថាសមួយ ហើយការបំពេញត្រឡប់ក្រោយជាការស្កេនបុព្វបទ ជំនួសសំណួរ។ បើចង់បែងចែកតាមគម្រោងជំនួសកាលបរិច្ឆេទ ដាក់លេខសម្គាល់ឆានែលក្នុងបុព្វបទ។
វត្ថុនីមួយៗជា JSON មួយបន្ទាត់
មានចេតនាមិនចូលបន្ទាត់ ដូច្នេះបុព្វបទទាំងមូលអានជា NDJSON ដោយមិនបើកវត្ថុម្តងមួយ។ ត្រាពេលវេលា គម្រោង វគ្គ លេខសម្គាល់អតិថិជន គោលដៅ តម្លៃ រូបិយប័ណ្ណ និងតំណចាក់ការថតឡើងវិញ។
តម្លៃទទេជា null មិនមែនសូន្យ
គោលដៅគ្មានតម្លៃប្រាក់សរសេរ null។ ក្នុងឃ្លាំងទិន្នន័យ សូន្យនឹងត្រូវបូកទៅសរុបដែលមិនធ្លាប់មាន។ ភាពខុសគ្នារវាង “មិនបានព្រមព្រៀងចំនួនទឹកប្រាក់” និង “ចំនួនទឹកប្រាក់សូន្យ” ត្រូវបានរក្សាក្នុងការនាំចេញ។
4. បើឆ្លើយ 403 សូមអាននេះមុន
សំណើ S3 ដែលត្រូវបានបដិសេធស្ទើរមិនប្រាប់អ្វី ហើយមានមូលហេតុដែលសារកំហុសក្នុងកំណត់ហេតុយើងប្រាប់ច្រើនជាង S3៖ តំបន់ត្រូវបានបញ្ចូលក្នុងហត្ថលេខា។ តំបន់ខុស និងសោខុសបង្កើត 403 ដូចគ្នា ដូច្នេះការសង្ស័យជាក់ស្តែងលើសោត្រូវត្រឹមពាក់កណ្តាលពេលប៉ុណ្ណោះ។
បីចំណុចត្រូវពិនិត្យតាមលំដាប់នេះ៖
- តំបន់ដូចដែលបាក់កេតរាយការណ៍។ R2 និង Google Cloud Storage ទទួល
autoហើយមិនពិនិត្យវា ប៉ុន្តែអ្នកផ្សេងទាំងអស់ពិនិត្យ។ - សិទ្ធិបុព្វបទ។ សោដែលកំណត់វិសាលភាពទៅ
mouseplayer/មិនអាចសរសេរទៅmouseplayer-goals/។ សញ្ញាខ្វែងចុងមានសារៈសំខាន់ក្នុង ARN ធនធាន។ - ចំណុចបញ្ចប់សម្រាប់ R2 និងឃ្លាំងដែលត្រូវគ្នានឹង S3។ បិទភ្ជាប់ឈ្មោះម៉ាស៊ីនដោយគ្មាន
https://។ យើងដកវាចេញគ្រប់ករណី ប៉ុន្តែផ្លូវដែលបន្ថែមទៅវាគឺជាបាក់កេតផ្សេង។
លេខសម្គាល់សោចូលប្រើត្រូវបានរក្សាជាអត្ថបទច្បាស់ដោយចេតនា។ វាត្រូវបញ្ជូនក្នុងរាល់សំណើចុះហត្ថលេខាតាមការរចនា ដូច្នេះការអ៊ិនគ្រីបវាជាការខិតខំដោយគ្មានការការពារ។ សោសម្ងាត់ត្រូវបានអ៊ិនគ្រីប មិនបង្ហាញទៀត ហើយមិនដែលចូលជួររង់ចាំផ្ទៃក្នុងដែលផ្ទុកការងារ។
ពាណិជ្ជសញ្ញាទាំងអស់ដែលមានឈ្មោះនៅទីនេះជាកម្មសិទ្ធិរបស់ម្ចាស់រៀងៗខ្លួន។ MousePlayer គ្មានទំនាក់ទំនងអាជីវកម្មជាមួយអ្នកផ្តល់សេវាទាំងនេះទេ។