Export till objektlagring
Ett JSON-objekt per uppnått mål i en bucket du äger. Det här är vägen till alla datalager som inte är BigQuery.
1. Glappet som detta fyller
Hittills fanns exakt en väg från MousePlayer till ett datalager och den ledde till Google. För Snowflake, Redshift eller ClickHouse fanns ingen väg, trots att alla tre utan problem läser från objektlagring.
Därför skriver bryggan till objektlagring i stället för till varje datalager för sig. Snowflake läser från S3, Redshift läser från S3, ClickHouse läser från S3 och BigQuery läser från Google Cloud Storage. En export når alla.
| Var | Hur den adresseras |
|---|---|
| Amazon S3 | Signature Version 4, bucket i värdnamnet |
| Cloudflare R2 | Signature Version 4 mot ditt kontos slutpunkt |
| Google Cloud Storage | via dess S3-kompatibla API med en HMAC-nyckel |
| MinIO, Wasabi, Backblaze B2 och andra | Signature Version 4 mot din slutpunkt |
| Azure Blob Storage | en SAS-länk för containern, ingen signering alls på vår sida |
2. Varför Azure skiljer sig och varför det är bättre
Azure Blob använder inte Signature Version 4 utan signerar med SharedKey. Vi kunde ha byggt ett andra signeringssystem. I stället tar bryggan en SAS-länk för containern – en URL du skapar i ditt eget lagringskonto med signaturen redan inbyggd.
Det innebär mindre kod hos oss och mindre behov av tillit från dig. Vi ser aldrig någon kontonyckel. Det du lämnar är en behörighet du själv begränsat till en container med ett eget utgångsdatum, som kan återkallas när som helst utan att något annat påverkas.
Samma återhållsamhet är klok på S3-sidan: ge åtkomstnyckeln rätt att skriva till just detta prefix och inget annat. En nyckel som bara kan lägga till under mouseplayer/goals/ kan inte läsa dina andra bucketar ens om den läcker.
3. Ett objekt per mål och en datumbaserad nyckel
Objektlagring kan inte lägga till i slutet av en fil. En daglig fil skulle behöva skrivas om helt varje gång och två samtidiga mål skulle skriva över varandra. Därför blir varje uppnått mål ett eget objekt.
Priset är många små objekt. Nyckelstrukturen gör det hanterbart:
prefix/YYYY/MM/DD/channel/session-goal.json
Ett datalager läser en dag som en partition och en efterinläsning är en prefixgenomsökning i stället för en fråga. Om du vill partitionera efter projekt i stället för datum lägger du kanal-ID:t i prefixet.
Varje objekt är en rad JSON
Avsiktligt utan indrag, så att ett helt prefix kan läsas som NDJSON utan att öppna objekten ett i taget. Tidsstämpel, projekt, session, kund-ID, mål, värde, valuta och länken som spelar upp inspelningen.
Ett tomt värde är null, inte noll
Ett mål utan ekonomiskt värde skriver null. I ett datalager skulle en nolla summeras till en total som aldrig funnits. Skillnaden mellan ”inget avtalat belopp” och ”ett belopp på noll” överlever exporten.
4. Om svaret är 403, läs detta först
Ett avvisat S3-anrop säger nästan ingenting. Det finns ett skäl till att vår fellogg säger mer än S3: regionen ingår i signaturen. Fel region och fel nyckel ger samma 403. Den uppenbara misstanken, nyckeln, stämmer därför bara hälften av gångerna.
Tre saker att kontrollera, i denna ordning:
- Regionen, exakt som bucketen anger den. R2 och Google Cloud Storage använder
autoutan att kontrollera värdet. Alla andra kontrollerar det. - Prefixbehörigheten. En nyckel begränsad till
mouseplayer/kan inte skriva tillmouseplayer-goals/– det avslutande snedstrecket spelar roll i ett resurs-ARN. - Slutpunkten, för R2 och S3-kompatibla lagringstjänster. Klistra in värden utan
https://. Vi tar bort det i båda fallen, men en tillagd sökväg betyder en annan bucket.
Åtkomstnyckelns ID lagras avsiktligt i klartext. Det skickas redan i varje signerat anrop, så kryptering skulle innebära arbete utan skydd. Hemligheten krypteras, visas aldrig igen och läggs aldrig i den interna kön som bär uppdraget.
Alla nämnda varumärken tillhör respektive ägare. MousePlayer har ingen affärsrelation med leverantörerna.