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.

HvorHvordan det adresseres
Amazon S3Signature Version 4, bucket i vertsnavnet
Cloudflare R2Signature Version 4 mot kontoens endepunkt
Google Cloud Storagevia det S3-kompatible API-et, med en HMAC-nøkkel
MinIO, Wasabi, Backblaze B2 og andreSignature Version 4 mot endepunktet ditt
Azure Blob Storageen 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 auto og kontrollerer den ikke; alle andre gjør det.
  • Prefikstillatelsen. En nøkkel avgrenset til mouseplayer/ kan ikke skrive til mouseplayer-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.