ऑब्जेक्ट स्टोरेज एक्सपोर्ट
हर पूरे लक्ष्य का एक JSON ऑब्जेक्ट, आपके बकेट में। BigQuery के अलावा हर वेयरहाउस तक यही रास्ता है।
1. कौन-सी कमी पूरी करता है
अब तक MousePlayer से वेयरहाउस का एक रास्ता Google तक था। Snowflake, Redshift या ClickHouse का नहीं — जबकि तीनों ऑब्जेक्ट स्टोरेज आसानी से पढ़ते हैं।
इसलिए ब्रिज हर वेयरहाउस के बजाय ऑब्जेक्ट स्टोरेज में लिखता है। Snowflake, Redshift, 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 अनुरोध लगभग कुछ नहीं बताता, इसलिए हमारे लॉग में अधिक विवरण है: क्षेत्र सिग्नेचर में जाता है। ग़लत क्षेत्र और कुंजी दोनों वही 403 देते हैं; स्वाभाविक शक — कुंजी — आधी बार ही सही है।
इस क्रम में तीन जाँच:
- क्षेत्र, बिल्कुल बकेट के अनुसार। R2 और Google Cloud Storage यह लेते हैं:
autoऔर नहीं जाँचते; बाकी जाँचते हैं। - प्रीफ़िक्स अनुमति। इसमें सीमित कुंजी:
mouseplayer/यहाँ नहीं लिख सकती:mouseplayer-goals/— resource ARN में अंतिम स्लैश महत्वपूर्ण है। - एंडपॉइंट, R2 और S3-संगत स्टोर के लिए। होस्ट इसके बिना दें:
https://; हम हटा देंगे, लेकिन जुड़ा पथ अलग बकेट है।
एक्सेस कुंजी ID जानबूझकर खुली रहती है। हर हस्ताक्षरित अनुरोध में जाती है, इसलिए एन्क्रिप्शन बिना सुरक्षा की मेहनत होगा। सीक्रेट एन्क्रिप्टेड, फिर नहीं दिखता और काम की आंतरिक कतार में नहीं जाता।
यहाँ बताए ट्रेडमार्क संबंधित स्वामियों के हैं। MousePlayer का इन प्रदाताओं से व्यावसायिक संबंध नहीं।