ଅବଜେକ୍ଟ୍ ସଂରକ୍ଷଣ ଏକ୍ସପୋର୍ଟ୍
ଆପଣଙ୍କ ମାଲିକାନାର bucket ରେ ପ୍ରତି ପୂରଣ ହୋଇଥିବା ଲକ୍ଷ୍ୟ ପାଇଁ ଗୋଟିଏ JSON ଅବଜେକ୍ଟ୍। BigQuery ବ୍ୟତୀତ ସବୁ ୱେୟାରହାଉସ୍କୁ ଯିବା ପଥ ଏହା।
1. କେଉଁ ଅଭାବ ପୂରଣ କରେ
ଏପର୍ଯ୍ୟନ୍ତ MousePlayer ରୁ ଡାଟା ୱେୟାରହାଉସ୍କୁ ଯିବାର ଠିକ୍ ଗୋଟିଏ ପଥ ଥିଲା, ଯାହା Google କୁ ଯାଉଥିଲା। Snowflake, Redshift କିମ୍ବା ClickHouse ବ୍ୟବହାର କଲେ କୌଣସି ପଥ ନଥିଲା - ଯଦିଓ ତିନୋଟି ଅବଜେକ୍ଟ୍ ସଂରକ୍ଷଣରୁ ସହଜରେ ପଢ଼ନ୍ତି।
ତେଣୁ ବ୍ରିଜ୍ ପ୍ରତି ୱେୟାରହାଉସ୍କୁ ଅଲଗା ଲେଖିବା ପରିବର୍ତ୍ତେ ଅବଜେକ୍ଟ୍ ସଂରକ୍ଷଣରେ ଲେଖେ। Snowflake S3 ରୁ, Redshift S3 ରୁ, ClickHouse S3 ରୁ ଓ BigQuery Google Cloud Storage ରୁ ତଥ୍ୟ ନିଏ। ଗୋଟିଏ ଏକ୍ସପୋର୍ଟ୍ ସମସ୍ତଙ୍କୁ ପହଞ୍ଚେ।
| କେଉଁଠି | କିପରି ଠିକଣା ଦିଆଯାଏ |
|---|---|
| Amazon S3 | Signature Version 4, host ରେ bucket |
| Cloudflare R2 | ଆପଣଙ୍କ ଆକାଉଣ୍ଟ୍ ଏଣ୍ଡପଏଣ୍ଟ୍ରେ Signature Version 4 |
| Google Cloud Storage | S3-ସୁସଙ୍ଗତ API ଦ୍ୱାରା, HMAC ଚାବି ସହ |
| MinIO, Wasabi, Backblaze B2 ଓ ଅନ୍ୟମାନେ | ଆପଣଙ୍କ ଏଣ୍ଡପଏଣ୍ଟ୍ରେ Signature Version 4 |
| Azure Blob Storage | container SAS ଲିଙ୍କ୍ - ଆମ ପଟେ କୌଣସି ସ୍ୱାକ୍ଷର ନାହିଁ |
2. Azure କାହିଁକି ଭିନ୍ନ ଓ କାହିଁକି ଭଲ
Azure Blob Signature Version 4 ବ୍ୟବହାର କରେ ନାହିଁ; SharedKey ରେ ସ୍ୱାକ୍ଷର କରେ। ଆମେ ଦ୍ୱିତୀୟ ସ୍ୱାକ୍ଷର ପଦ୍ଧତି ତିଆରି କରିପାରିଥାନ୍ତୁ। ତାହା ବଦଳରେ ବ୍ରିଜ୍ ନିଏ ଏକ container SAS ଲିଙ୍କ୍ - ଆପଣଙ୍କ ନିଜ ସଂରକ୍ଷଣ ଆକାଉଣ୍ଟ୍ରେ ତିଆରି URL, ଯାହା ଭିତରେ ସ୍ୱାକ୍ଷର ପୂର୍ବରୁ ଅଛି।
ଏଥିରେ ଆମ ପଟେ କମ୍ କୋଡ୍ ଓ ଆପଣଙ୍କ ପଟେ କମ୍ ବିଶ୍ୱାସ ଦରକାର। ଆମେ ଆକାଉଣ୍ଟ୍ ଚାବି ଆଦୌ ଦେଖୁନାହୁଁ: ଆପଣ ଦେଉଛନ୍ତି ନିଜେ ସୀମିତ କରିଥିବା ଗୋଟିଏ container ର ଅନୁମତି, ନିଜେ ବାଛିଥିବା ଶେଷ ତାରିଖ ସହ, ଅନ୍ୟ କିଛି ନବଦଳାଇ ଯେକୌଣସି ସମୟରେ ପ୍ରତ୍ୟାହାରଯୋଗ୍ୟ।
S3 ପଟେ ମଧ୍ୟ ସମାନ ସଂଯମ ଭଲ: access key କୁ କେବଳ ଏଠାରେ ଲେଖିବା ଅନୁମତି ଦିଅନ୍ତୁ: ଏହି ଗୋଟିଏ prefix ଅନ୍ୟ କିଛି ନୁହେଁ। କେବଳ ଏଠାରେ ଯୋଡ଼ିପାରୁଥିବା ଚାବି mouseplayer/goals/ ଲିକ୍ ହେଲେ ମଧ୍ୟ ଅନ୍ୟ bucket ପଢ଼ିପାରେ ନାହିଁ।
3. ପ୍ରତି ଲକ୍ଷ୍ୟ ପାଇଁ ଗୋଟିଏ ଅବଜେକ୍ଟ୍, ଚାବି ହେଉଛି ତାରିଖ
ଅବଜେକ୍ଟ୍ ସଂରକ୍ଷଣରେ append ନାହିଁ। ପ୍ରତିଥର ଦୈନିକ ଫାଇଲ୍ ସମ୍ପୂର୍ଣ୍ଣ ପୁଣି ଲେଖିବାକୁ ପଡ଼ନ୍ତା, ଏବଂ ଦୁଇଟି ଲକ୍ଷ୍ୟ ଏକାସହ ଆସିଲେ ପରସ୍ପର ତଥ୍ୟ ଉପରେ ଲେଖିଦିଅନ୍ତା। ତେଣୁ ପ୍ରତ୍ୟେକ ପୂରଣ ହୋଇଥିବା ଲକ୍ଷ୍ୟ ନିଜ ଅବଜେକ୍ଟ୍ ହୁଏ।
ମୂଲ୍ୟ ହେଉଛି ଅନେକ ଛୋଟ ଅବଜେକ୍ଟ୍; ଚାବି ଗଠନ ଏହାକୁ କାର୍ଯ୍ୟକ୍ଷମ କରେ:
prefix/YYYY/MM/DD/channel/session-goal.json
ୱେୟାରହାଉସ୍ ଗୋଟିଏ ଦିନକୁ ଗୋଟିଏ partition ଭାବେ ପଢ଼େ, ପଛୁଆ ତଥ୍ୟ ଭରିବା କ୍ୱେରି ବଦଳରେ prefix scan। ତାରିଖ ପରିବର୍ତ୍ତେ ପ୍ରକଳ୍ପ ଅନୁସାରେ ବିଭାଜନ ଚାହିଁଲେ channel ID କୁ prefix ରେ ଦିଅନ୍ତୁ।
ପ୍ରତି ଅବଜେକ୍ଟ୍ ଗୋଟିଏ ଧାଡ଼ି JSON
ଜାଣିଶୁଣି ଇଣ୍ଡେଣ୍ଟ୍ ନାହିଁ, ତେଣୁ ଅବଜେକ୍ଟ୍ ଗୋଟିଗୋଟି ନଖୋଲି ସମ୍ପୂର୍ଣ୍ଣ prefix NDJSON ଭାବେ ପଢ଼ିହେବ। Timestamp, ପ୍ରକଳ୍ପ, ସେସନ୍, ଗ୍ରାହକ ID, ଲକ୍ଷ୍ୟ, ମୂଲ୍ୟ, ମୁଦ୍ରା ଓ ରେକର୍ଡିଂ ଚଲାଇବା ଲିଙ୍କ୍।
ଖାଲି ମୂଲ୍ୟ null, ଶୂନ ନୁହେଁ
ଧନମୂଲ୍ୟ ନଥିବା ଲକ୍ଷ୍ୟ ଏହା ଲେଖେ: null। ୱେୟାରହାଉସ୍ରେ ଶୂନ ଯୋଡ଼ିଲେ କେବେ ନଥିବା ମୋଟ ସୃଷ୍ଟି ହେବ - “ରାଶି ନିର୍ଣ୍ଣୟ ହୋଇନାହିଁ” ଓ “ଶୂନ ରାଶି” ମଧ୍ୟରେ ପାର୍ଥକ୍ୟ ଏକ୍ସପୋର୍ଟ୍ରେ ରହେ।
4. 403 ଉତ୍ତର ଆସିଲେ ପ୍ରଥମେ ଏହା ପଢ଼ନ୍ତୁ
ଅସ୍ୱୀକୃତ S3 ଅନୁରୋଧ ପ୍ରାୟ କିଛି ଜଣାଏ ନାହିଁ, ଆଉ ଆମ ଲଗ୍ S3 ଠାରୁ ଅଧିକ କହିବାର କାରଣ ଅଛି: ଅଞ୍ଚଳ ସ୍ୱାକ୍ଷରରେ ଯାଏ। ଭୁଲ୍ ଅଞ୍ଚଳ ଓ ଭୁଲ୍ ଚାବି ସମାନ 403 ଦିଏ, ତେଣୁ ପ୍ରଥମ ସନ୍ଦେହ - ଚାବି - କେବଳ ଅଧା ସମୟ ଠିକ୍।
ଏହି କ୍ରମରେ ତିନିଟି ଜିନିଷ ଯାଞ୍ଚ କରନ୍ତୁ:
- ଅଞ୍ଚଳ, bucket ଯାହା ଜଣାଏ ଠିକ୍ ସେପରି। R2 ଓ Google Cloud Storage ଏହା ନିଅନ୍ତି:
autoଓ ଯାଞ୍ଚ କରନ୍ତି ନାହିଁ; ଅନ୍ୟ ସମସ୍ତେ କରନ୍ତି। - prefix ଅନୁମତି। ଏଠାରେ ସୀମିତ ଚାବି
mouseplayer/ଏଠାରେ ଲେଖିପାରେ ନାହିଁ:mouseplayer-goals/- resource ARN ରେ ଶେଷ ସ୍ଲାଶ୍ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। - ଏଣ୍ଡପଏଣ୍ଟ୍, R2 ଓ S3-ସୁସଙ୍ଗତ ସଂରକ୍ଷଣ ପାଇଁ। ଏହା ବିନା host ଲଗାନ୍ତୁ:
https://; ଆମେ ଯେକୌଣସି ଅବସ୍ଥାରେ ହଟାଉ, କିନ୍ତୁ ପରେ ପଥ ଯୋଡ଼ିଲେ ଭିନ୍ନ bucket ହେବ।
access key ID ଜାଣିଶୁଣି ସାଧାରଣ ପାଠ୍ୟରେ ରଖାଯାଏ। ଡିଜାଇନ୍ ଅନୁସାରେ ପ୍ରତି ସ୍ୱାକ୍ଷରିତ ଅନୁରୋଧରେ ଯାଏ, ତେଣୁ ଏନକ୍ରିପ୍ଟ୍ କଲେ ସୁରକ୍ଷା ବିନା ପରିଶ୍ରମ ହେବ। secret ଏନକ୍ରିପ୍ଟ୍, ପୁଣି ଦେଖାଯାଏ ନାହିଁ ଓ କାମ ଥିବା ଆଭ୍ୟନ୍ତରୀଣ ଧାଡ଼ିକୁ କେବେ ଯାଏ ନାହିଁ।
ଏଠାରେ ଥିବା ସମସ୍ତ ଟ୍ରେଡ୍ମାର୍କ୍ ସେମାନଙ୍କ ସମ୍ବନ୍ଧିତ ମାଲିକଙ୍କର। ଏହି ପ୍ରଦାନକାରୀଙ୍କ ସହ MousePlayer ର କୌଣସି ବ୍ୟବସାୟିକ ସମ୍ପର୍କ ନାହିଁ।