آبجيڪٽ اسٽوريج ايڪسپورٽ

هر مڪمل مقصد لاءِ هڪ JSON object، توهان جي پنهنجي بڪيٽ ۾. هي هر انهيءَ warehouse ڏانهن رستو آهي جيڪو BigQuery ناهي.

1. ڪهڙو خال ڀري ٿو

اڳ MousePlayer مان data warehouse ڏانهن بلڪل هڪ رستو هو، ۽ اهو Google ڏانهن ويو ٿي. Snowflake، Redshift يا ClickHouse هجي ته ڪو نه — جيتوڻيڪ ٽئي آبجيڪٽ اسٽوريج مان آساني سان پڙهن ٿا.

تنهنڪري پل هر warehouse ۾ الڳ لکڻ بدران آبجيڪٽ اسٽوريج ۾ لکي ٿو. Snowflake، S3 مان وٺي ٿو، Redshift، S3 مان وٺي ٿو، ClickHouse، S3 مان وٺي ٿو ۽ BigQuery، Google Cloud Storage مان وٺي ٿو. هڪ ايڪسپورٽ سڀني تائين پهچي ٿو.

ڪٿيپتو ڪيئن طئي ٿئي ٿو
Amazon S3Signature Version 4، بڪيٽ host ۾
Cloudflare R2Signature Version 4، توهان جي اڪائونٽ endpoint سان
Google Cloud Storageان جي S3-compatible API ذريعي، HMAC key سان
MinIO، Wasabi، Backblaze B2 ۽ ٻياSignature Version 4، توهان جي endpoint سان
Azure Blob StorageContainer SAS لنڪ — اسان جي پاسي صحي ڪرڻ بلڪل نه

2. Azure الڳ ڇو آهي، ۽ اهو بهتر ڇو آهي

Azure Blob، Signature Version 4 استعمال نٿو ڪري؛ SharedKey سان صحي ڪري ٿو. ٻيو صحي وارو طريقو ٺاهي سگهياسين ٿي. ان جي بدران پل هي وٺي ٿو Container SAS لنڪ — اهو URL جيڪو توهان پنهنجي storage اڪائونٽ ۾ ٺاهيو، صحي اڳ ئي ان ۾ آهي.

اسان جي پاسي گهٽ ڪوڊ، توهان جي پاسي گهٽ ڀروسي جي ضرورت. اسان ڪڏهن اڪائونٽ key نٿا ڏسون: توهان هڪ container تائين پنهنجي مقرر ڪيل اجازت ڏيو ٿا، پنهنجي چونڊيل ختم ٿيڻ جي تاريخ سان، جيڪا ٻئي ڪنهن شيءِ کي ڇهڻ کان سواءِ ڪنهن به وقت واپس وٺي سگهجي ٿي.

ساڳي احتياط S3 پاسي به ڪارائتي آهي: access key کي لکڻ جي اجازت ڏيو رڳو هن ۾ هن هڪ prefix ۽ ٻئي ڪنهن ۾ نه. جيڪا key رڳو هن ۾ وڌائي سگهي mouseplayer/goals/ ، اها ليڪ ٿيڻ تي به ٻيا بڪيٽ نٿي پڙهي سگهي.

3. هر مقصد لاءِ هڪ object، ۽ key تاريخ آهي

آبجيڪٽ اسٽوريج ۾ append ناهي. روزاني فائل هر ڀيري پوري ٻيهر لکڻي پوي، ۽ هڪ ئي وقت ٻه مقصد هڪٻئي کي مٽائي ڇڏين. تنهنڪري هر مڪمل مقصد پنهنجو object بڻجي ٿو.

قيمت گهڻا ننڍا object آهن؛ key جي ترتيب ان کي ڪارائتو بڻائي ٿي:

prefix/YYYY/MM/DD/channel/session-goal.json

Warehouse هڪ ڏينهن کي هڪ partition طور پڙهي ٿو، ۽ پراڻي ڊيٽا ڀرڻ query بدران prefix scan آهي. تاريخ بدران پروجيڪٽ موجب partition ڪرڻ چاهيو ته channel ID کي prefix ۾ رکو.

هر object JSON جي هڪ سٽ آهي

ڄاڻي واڻي بنا indentation، ته هڪ وقت هڪ object کولڻ کان سواءِ پورو prefix NDJSON طور پڙهجي. وقت، پروجيڪٽ، سيشن، گراهڪ ID، مقصد، قدر، ڪرنسي ۽ رڪارڊنگ هلائيندڙ لنڪ.

خالي قدر null آهي، ٻڙي نه

مالي قدر کان سواءِ مقصد هي لکي ٿو null. Warehouse ۾ ٻڙي اهڙي مجموعي ۾ شامل ٿئي ها جيڪو ڪڏهن هو ئي نه — “رقم طئي ناهي” ۽ “ٻڙي رقم” جو فرق ايڪسپورٽ ۾ برقرار رهي ٿو.

4. جواب 403 هجي ته پهرين هي پڙهو

رد ٿيل S3 درخواست تقريباً ڪجهه نٿي ٻڌائي، ۽ اسان جي لاگ جو پيغام S3 کان وڌيڪ ٻڌائڻ جو سبب آهي: علائقو صحي ۾ شامل ٿئي ٿو. غلط علائقو ۽ غلط key ساڳيو 403 ڏين ٿا، تنهنڪري ظاهر شڪ — key — رڳو اڌ وقت صحيح آهي.

هن ترتيب ۾ ٽي شيون جاچيو:

  • علائقو، بلڪل جيئن بڪيٽ ٻڌائي. R2 ۽ Google Cloud Storage هي وٺن ٿا auto ۽ نٿا جاچين؛ ٻيا سڀ جاچين ٿا.
  • Prefix جي اجازت. هن تائين محدود key mouseplayer/ هن ۾ نٿي لکي سگهي mouseplayer-goals/ — resource ARN ۾ آخري slash اهم آهي.
  • Endpoint، R2 ۽ S3-compatible اسٽورن لاءِ. Host هن کان سواءِ پيسٽ ڪريو https://؛ اسان ٻنهي صورتن ۾ هٽايون ٿا، پر ان سان ڳنڍيل path ٻيو بڪيٽ آهي.

Access key ID ڄاڻي واڻي کليل صورت ۾ محفوظ آهي. بناوت موجب هر صحيح ٿيل درخواست ۾ وڃي ٿو، تنهنڪري انڪرپشن بنا تحفظ جي محنت هوندي. Secret انڪرپٽ ٿيل آهي، وري نه ڏيکارجي ٿو، ۽ ڪم کڻندڙ اندروني قطار ۾ ڪڏهن نٿو اچي.

هتي ڄاڻايل سڀ تجارتي نشان پنهنجن مالڪن جا آهن. MousePlayer جو انهن فراهم ڪندڙن سان ڪو ڪاروباري لاڳاپو ناهي.