ఆబ్జెక్ట్ నిల్వ ఎగుమతి

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	దాని S3 అనుకూల API ద్వారా, HMAC కీతో
MinIO, Wasabi, Backblaze B2, తదితరాలు	మీ ఎండ్‌పాయింట్‌పై Signature Version 4
Azure Blob Storage	కంటైనర్ SAS లింక్ - మా వైపు సంతకం అసలు లేదు

2. Azure ఎందుకు భిన్నం, అది ఎందుకు మెరుగు

Azure Blob Signature Version 4 ఉపయోగించదు; SharedKeyతో సంతకం చేస్తుంది. మేము రెండో సంతకం విధానాన్ని నిర్మించవచ్చు. బదులుగా బ్రిడ్జ్ తీసుకునేది కంటైనర్ SAS లింక్ - మీ స్వంత నిల్వ ఖాతాలో మీరు రూపొందించే URL; అందులో సంతకం ఇప్పటికే ఉంటుంది.

మా వైపు తక్కువ కోడ్; మీ వైపు తక్కువ నమ్మకం అవసరం. ఖాతా కీ మాకు అసలు కనిపించదు: మీరు ఇచ్చేది మీరే పరిమితం చేసిన అనుమతి, ఒక్క కంటైనర్‌కు, మీరు ఎంచుకున్న గడువుతో; ఇతర దేనినీ తాకకుండా ఎప్పుడైనా రద్దు చేయగలది.

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/ - రిసోర్స్ ARNలో చివరి స్లాష్ ముఖ్యం.
• ఎండ్‌పాయింట్, R2, S3 అనుకూల నిల్వలకు. ఇది లేకుండా హోస్ట్‌ను పేస్ట్ చేయండి: https://; ఏ సందర్భంలోనైనా మేము దాన్ని తొలగిస్తాము; కానీ జోడించిన పాత్ వేరే బకెట్ అవుతుంది.