Εξαγωγή σε αποθήκευση αντικειμένων

1. Το κενό που καλύπτει

Μέχρι τώρα υπήρχε ακριβώς μία διαδρομή από το MousePlayer σε αποθήκη δεδομένων και οδηγούσε στην Google. Αν χρησιμοποιούσατε Snowflake, Redshift ή ClickHouse, δεν υπήρχε καμία - παρότι και τα τρία διαβάζουν απρόσκοπτα από αποθήκευση αντικειμένων.

Έτσι η γέφυρα γράφει σε αποθήκευση αντικειμένων αντί σε κάθε αποθήκη δεδομένων ξεχωριστά. Το Snowflake εισάγει από S3, το Redshift εισάγει από S3, το ClickHouse εισάγει από S3 και το BigQuery εισάγει από Google Cloud Storage. Μία εξαγωγή φτάνει σε όλα.

Πού	Πώς γίνεται η πρόσβαση
Amazon S3	Signature Version 4, με το bucket στον κεντρικό υπολογιστή
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, οπότε η προφανής υποψία - το κλειδί - είναι σωστή μόνο τις μισές φορές.

Τρία πράγματα να ελέγξετε, με αυτή τη σειρά:

• Η περιοχή, ακριβώς όπως την αναφέρει το bucket. Τα R2 και Google Cloud Storage δέχονται auto και δεν το ελέγχουν· όλοι οι άλλοι το ελέγχουν.
• Το δικαίωμα προθέματος. Ένα κλειδί περιορισμένο στο mouseplayer/ δεν μπορεί να γράψει στο mouseplayer-goals/ - η τελική κάθετος έχει σημασία σε ένα ARN πόρου.
• Το τελικό σημείο, για το R2 και αποθηκευτικούς χώρους συμβατούς με S3. Επικολλήστε τον κεντρικό υπολογιστή χωρίς https://· το αφαιρούμε ούτως ή άλλως, αλλά μια διαδρομή που προσαρτάται σε αυτόν αντιστοιχεί σε διαφορετικό bucket.