Eksport til objektlagring
Ett JSON-objekt per oppfylt mål, i en bucket du eier. Dette er veien til alle datavarehus som ikke er BigQuery.
1. Gapet dette fyller
Hittil fantes nøyaktig én vei fra MousePlayer til et datavarehus, og den gikk til Google. Bruker du Snowflake, Redshift eller ClickHouse, fantes ingen — selv om alle tre leser fra objektlagring uten problemer.
Broen skriver derfor til objektlagring i stedet for til hvert datavarehus. Snowflake leser fra S3, Redshift leser fra S3, ClickHouse leser fra S3, og BigQuery leser fra Google Cloud Storage. Én eksport når alle.
| Hvor | Hvordan det adresseres |
|---|---|
| Amazon S3 | Signature Version 4, bucket i vertsnavnet |
| Cloudflare R2 | Signature Version 4 mot kontoens endepunkt |
| Google Cloud Storage | via det S3-kompatible API-et, med en HMAC-nøkkel |
| MinIO, Wasabi, Backblaze B2 og andre | Signature Version 4 mot endepunktet ditt |
| Azure Blob Storage | en SAS-lenke til en container — ingen signering hos oss |
2. Hvorfor Azure er annerledes, og hvorfor det er bedre
Azure Blob bruker ikke Signature Version 4; det signerer med SharedKey. Vi kunne bygget en ekstra signeringsordning. I stedet tar broen imot en SAS-lenke til en container — en URL du genererer i din egen lagringskonto, med signaturen allerede innebygd.
Det gir mindre kode hos oss og krever mindre tillit fra deg. Vi ser aldri noen kontonøkkel: du gir en tillatelse du selv avgrenset til én container, med en utløpsdato du valgte, som kan tilbakekalles når som helst uten å røre noe annet.
Samme tilbakeholdenhet er verdt å bruke på S3-siden: gi tilgangsnøkkelen tillatelse til å skrive til dette ene prefikset og ingenting annet. En nøkkel som bare kan legge til under mouseplayer/goals/ kan ikke lese andre bucketer selv om den lekker.
3. Ett objekt per mål, og nøkkelen er en dato
Objektlagring har ingen funksjon for å legge til i eksisterende innhold. En dagsfil måtte blitt skrevet helt på nytt hver gang, og to mål som kom samtidig, ville overskrevet hverandre. Derfor blir hvert oppfylt mål et eget objekt.
Prisen er mange små objekter; nøkkelstrukturen gjør dette håndterbart:
prefix/YYYY/MM/DD/channel/session-goal.json
Et datavarehus leser én dag som én partisjon, og etterfylling er et prefikssøk i stedet for en spørring. Vil du partisjonere etter prosjekt i stedet for dato, legger du kanal-ID-en i prefikset.
Hvert objekt er én linje JSON
Bevisst uten innrykk, slik at et helt prefiks kan leses som NDJSON uten å åpne objektene enkeltvis. Tidsstempel, prosjekt, økt, kunde-ID, mål, verdi, valuta og lenken som spiller av opptaket.
En tom verdi er null, ikke 0
Et mål uten pengeverdi skriver null. I et datavarehus ville tallet null inngått i en sum som aldri fantes — skillet mellom «intet beløp avtalt» og «et beløp på null» overlever eksporten.
4. Hvis svaret er 403, les dette først
En avvist S3-forespørsel sier nesten ingenting, og det er en grunn til at feilmeldingen i loggen vår sier mer enn S3: regionen inngår i signaturen. Feil region og feil nøkkel gir samme 403, så den åpenbare mistanken — nøkkelen — stemmer bare halvparten av gangene.
Tre ting å kontrollere, i denne rekkefølgen:
- Regionen, nøyaktig slik bucketen oppgir den. R2 og Google Cloud Storage bruker
autoog kontrollerer den ikke; alle andre gjør det. - Prefikstillatelsen. En nøkkel avgrenset til
mouseplayer/kan ikke skrive tilmouseplayer-goals/— den avsluttende skråstreken betyr noe i en ressurs-ARN. - Endepunktet, for R2 og S3-kompatible lagre. Lim inn verten uten
https://; vi fjerner det uansett, men en sti lagt til etterpå peker på en annen bucket.
Tilgangsnøkkel-ID-en lagres bevisst i klartekst. Den følger hver signert forespørsel etter utformingen, så kryptering ville vært arbeid uten beskyttelse. Hemmeligheten krypteres, vises aldri igjen og legges aldri i den interne oppgavekøen.
Alle nevnte varemerker tilhører sine respektive eiere. MousePlayer har ingen forretningsforbindelse med disse leverandørene.