ऑब्जेक्ट स्टोरेज निर्यात
प्रत्येक पूर्ण उद्दिष्टासाठी तुमच्या बकेटमध्ये एक JSON ऑब्जेक्ट. BigQuery व्यतिरिक्त प्रत्येक वेअरहाउसचा मार्ग.
1. कोणती उणीव भरते
आतापर्यंत डेटा वेअरहाउसचा एकच मार्ग, 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 | HMAC कीसह S3-सुसंगत API |
| 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
वेअरहाउस एक दिवस एक पार्टीशन वाचते; जुना डेटा भरण्यासाठी क्वेरीऐवजी प्रीफिक्स स्कॅन. तारखेऐवजी प्रकल्पानुसार हवे तर प्रीफिक्समध्ये चॅनेल ID ठेवा.
प्रत्येक ऑब्जेक्ट JSON ची एक ओळ
मुद्दाम इंडेंट नाही; प्रत्येक ऑब्जेक्ट न उघडता पूर्ण प्रीफिक्स NDJSON म्हणून वाचता येतो. वेळ, प्रकल्प, सत्र, ग्राहक ID, उद्दिष्ट, मूल्य, चलन आणि रेकॉर्डिंग दुवा.
रिकामे मूल्य null, शून्य नाही
आर्थिक मूल्य नसलेल्या उद्दिष्टासाठी लिहितो: null. शून्य केल्यास नसलेली रक्कम बेरीजेत येईल — “रक्कम ठरवली नाही” आणि “शून्य रक्कम” हा फरक टिकतो.
4. 403 मिळाल्यास आधी वाचा
नाकारलेल्या S3 विनंतीत फार माहिती नाही; आमच्या नोंदीत S3 पेक्षा अधिक माहिती देण्याचे कारण: प्रदेश स्वाक्षरीत येतो. चुकीचा प्रदेश आणि की दोन्ही 403 देतात; म्हणून कीचा संशय अर्ध्यावेळीच बरोबर.
या क्रमाने तीन तपासण्या:
- प्रदेश, बकेटने दिल्याप्रमाणे अचूक. R2 आणि Google Cloud Storage पुढील घेतात:
autoआणि तपासत नाहीत; इतर सर्व तपासतात. - प्रीफिक्स परवानगी. पुढीलपुरती की:
mouseplayer/येथे लिहू शकत नाही:mouseplayer-goals/— resource ARN मध्ये शेवटचा स्लॅश महत्त्वाचा. - एंडपॉइंट, R2 आणि S3-सुसंगत स्टोरेजसाठी. पुढीलशिवाय होस्ट पेस्ट करा:
https://; आम्ही काढतोच, पण जोडलेला मार्ग म्हणजे वेगळे बकेट.
अॅक्सेस की ID मुद्दाम उघडा साठतो. प्रत्येक स्वाक्षरी विनंतीत जातोच; एन्क्रिप्शनने संरक्षण वाढणार नाही. सीक्रेट एन्क्रिप्टेड; पुन्हा दिसत नाही, कामाच्या रांगेत जात नाही.
सर्व ट्रेडमार्क संबंधित मालकांचे आहेत. MousePlayer चे या प्रदात्यांशी व्यावसायिक संबंध नाहीत.