Exportació a emmagatzematge d’objectes

1. El buit que cobreix

Fins ara hi havia exactament una via de MousePlayer cap a un magatzem de dades, i portava a Google. Si utilitza Snowflake, Redshift o ClickHouse, no n’hi havia cap, encara que tots tres llegeixen d’emmagatzematge d’objectes sense problemes.

Per això el pont escriu a l’emmagatzematge d’objectes en lloc de fer-ho a cada magatzem de dades per separat. Snowflake ingereix des d’S3, Redshift des d’S3, ClickHouse des d’S3 i BigQuery des de Google Cloud Storage. Una sola exportació arriba a tots.

On	Com s’hi accedeix
Amazon S3	Signature Version 4, amb el bucket al host
Cloudflare R2	Signature Version 4 contra l’endpoint del seu compte
Google Cloud Storage	mitjançant la seva API compatible amb S3, amb una clau HMAC
MinIO, Wasabi, Backblaze B2 i altres	Signature Version 4 contra el seu endpoint
Azure Blob Storage	un enllaç SAS de contenidor; cap signatura a la nostra banda

2. Per què Azure és diferent i per què això és millor

Azure Blob no utilitza Signature Version 4; signa amb SharedKey. Podríem haver creat un segon esquema de signatura. En lloc d’això, el pont accepta un enllaç SAS de contenidor que és un URL generat al seu propi compte d’emmagatzematge, amb la signatura ja inclosa.

Això significa menys codi a la nostra banda i menys confiança exigida a la seva. No veiem mai cap clau de compte: ens proporciona un permís que vostè mateix ha limitat a un contenidor, amb una data de caducitat escollida per vostè i revocable en qualsevol moment sense tocar res més.

3. Un objecte per objectiu, i la clau és una data

L’emmagatzematge d’objectes no permet afegir dades al final. Caldria reescriure un fitxer diari sencer cada vegada, i dos objectius que arribessin alhora se sobreescriurien mútuament. Per això cada objectiu assolit es converteix en un objecte propi.

El preu és tenir molts objectes petits; la disposició de les claus ho fa viable:

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

Un magatzem de dades llegeix un dia com una partició, i completar dades antigues és un escaneig per prefix en lloc d’una consulta. Si vol particionar per projecte en lloc de per data, inclogui l’identificador de canal al prefix.

Cada objecte és una línia de JSON

Expressament sense sagnat, perquè tot un prefix es pugui llegir com a NDJSON sense obrir els objectes d’un en un. Marca de temps, projecte, sessió, identificador de client, objectiu, valor, moneda i l’enllaç per reproduir la gravació.

Un valor buit és null, no zero

Un objectiu sense valor monetari escriu null. En un magatzem de dades, un zero se sumaria a un total que no ha existit mai: la diferència entre «cap import acordat» i «un import de zero» es conserva a l’exportació.

4. Si respon 403, llegeixi això primer

Una petició S3 rebutjada gairebé no explica res, i hi ha un motiu pel qual el missatge d’error del nostre registre explica més que S3: la regió forma part de la signatura. Una regió incorrecta i una clau incorrecta produeixen el mateix 403; per tant, la sospita òbvia —la clau— només és correcta la meitat de les vegades.

Tres coses que cal comprovar, en aquest ordre:

• La regió, exactament com la indica el bucket. R2 i Google Cloud Storage accepten auto i no la comproven; tots els altres sí.
• El permís del prefix. Una clau limitada a mouseplayer/ no pot escriure a mouseplayer-goals/ perquè la barra final importa en un ARN de recurs.
• L’endpoint, per a R2 i els emmagatzematges compatibles amb S3. Enganxi el host sense https://; el suprimim en qualsevol cas, però un camí afegit al final correspon a un bucket diferent.