अब्जेक्ट भण्डारण निर्यात
पूरा भएको हरेक लक्ष्यको एउटा 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 | 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. प्रति लक्ष्य एउटा अब्जेक्ट, कुञ्जीमा मिति
अब्जेक्ट भण्डारणमा append हुँदैन। दैनिक फाइल हरेक पटक पूरै लेख्नुपर्थ्यो र दुई लक्ष्य एकैचोटि आए एकले अर्को मेटाउँथ्यो। त्यसैले हरेक लक्ष्यको छुट्टै अब्जेक्ट हुन्छ।
धेरै साना अब्जेक्ट बन्छन्; कुञ्जी संरचनाले सम्भव बनाउँछ:
prefix/YYYY/MM/DD/channel/session-goal.json
वेयरहाउसले दिनलाई एउटै पार्टिसनमा पढ्छ र पुरानो डेटा ल्याउनु क्वेरी होइन, प्रिफिक्स खोज हो। मितिको सट्टा परियोजनाअनुसार छुट्याउन channel 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 को यी प्रदायकसँग व्यावसायिक सम्बन्ध छैन।