Eksportas į objektų saugyklą
Vienas JSON objektas kiekvienam pasiektam tikslui jūsų konteineryje. Tai kelias į bet kurį duomenų sandėlį, išskyrus BigQuery.
1. Kokią spragą tai užpildo
Iki šiol iš MousePlayer į duomenų sandėlį vedė tik vienas kelias, ir jis vedė į Google. Jei naudojate Snowflake, Redshift ar ClickHouse, kelio nebuvo, nors visos trys sistemos be problemų skaito objektų saugyklas.
Todėl tiltas rašo į objektų saugyklą, o ne atskirai į kiekvieną sandėlį. Snowflake, Redshift ir ClickHouse priima iš S3, o BigQuery iš Google Cloud Storage. Vienas eksportas pasiekia visus.
| Kur | Kaip adresuojama |
|---|---|
| Amazon S3 | Signature Version 4, konteineris serverio adrese |
| Cloudflare R2 | Signature Version 4 jūsų paskyros galiniu adresu |
| Google Cloud Storage | per su S3 suderinamą API, su HMAC raktu |
| MinIO, Wasabi, Backblaze B2 ir kitos | Signature Version 4 jūsų galiniu adresu |
| Azure Blob Storage | konteinerio SAS nuoroda; mūsų pusėje visai nepasirašoma |
2. Kodėl Azure išsiskiria ir kodėl taip geriau
Azure Blob nepalaiko Signature Version 4; pasirašo naudodamas SharedKey. Galėjome sukurti antrą pasirašymo schemą. Vietoje to tiltas priima konteinerio SAS nuorodą – URL, kurį sugeneruojate savo saugyklos paskyroje ir kuriame parašas jau yra.
Taip mūsų pusėje mažiau kodo, jūsų – mažiau būtino pasitikėjimo. Paskyros rakto visai nematome: perduodate savo apribotą teisę vienam konteineriui su pasirinkta galiojimo data, bet kada atšaukiamą nieko kito nekeičiant.
Taip pat verta riboti S3 pusę: suteikite prieigos raktui teisę rašyti tik į šį vieną prefiksą ir niekur kitur. Raktas, galintis tik pridėti prie mouseplayer/goals/, negalės skaityti kitų jūsų konteinerių net nutekėjęs.
3. Vienas objektas tikslui, o raktas – data
Objektų saugykla neturi papildymo operacijos. Dienos failą reikėtų kaskart perrašyti visą, o du vienu metu pasiekti tikslai perrašytų vienas kitą. Todėl kiekvienas pasiektas tikslas tampa atskiru objektu.
Kaina – daug mažų objektų; tai praktiška dėl raktų struktūros:
prefix/YYYY/MM/DD/channel/session-goal.json
Sandėlis skaito vieną dieną kaip vieną skaidinį, o ankstesnių duomenų papildymas yra prefikso peržiūra, ne užklausa. Jei norite skaidyti pagal projektą, o ne datą, į prefiksą įtraukite kanalo ID.
Kiekvienas objektas yra viena JSON eilutė
Sąmoningai be įtraukų, kad visas prefiksas būtų skaitomas kaip NDJSON neatidarant kiekvieno objekto atskirai. Laiko žyma, projektas, seansas, kliento ID, tikslas, vertė, valiuta ir įrašą atkurianti nuoroda.
Tuščia vertė yra null, o ne nulis
Tikslas be piniginės vertės įrašo null. Sandėlyje nulis būtų susumuotas į niekada neegzistavusią sumą; skirtumas tarp „suma nenustatyta“ ir „nulinė suma“ išlieka eksporte.
4. Jei atsakymas 403, pirmiausia skaitykite čia
Atmesta S3 užklausa beveik nieko nepasako; mūsų žurnalo klaida išsamesnė už S3 ne be priežasties: regionas įtraukiamas į parašą. Neteisingas regionas ir neteisingas raktas sukelia tą patį 403, todėl akivaizdus įtariamasis, raktas, teisus tik pusę atvejų.
Trys tikrintini dalykai tokia tvarka:
- Regionas, tiksliai toks, kokį pateikia konteineris. R2 ir Google Cloud Storage priima
autoir netikrina; visi kiti tikrina. - Prefikso teisė. Raktas, apribotas
mouseplayer/, negali rašyti įmouseplayer-goals/; pasvirasis brūkšnys pabaigoje svarbus ištekliaus ARN. - Galinis adresas, R2 ir su S3 suderinamoms saugykloms. Įklijuokite serverio adresą be
https://; vis tiek pašaliname, bet pridėtas kelias reiškia kitą konteinerį.
Prieigos rakto ID sąmoningai saugomas atvirai. Pagal paskirtį jis keliauja kiekvienoje pasirašytoje užklausoje, todėl jo šifravimas būtų pastangos be apsaugos. Paslaptis šifruojama, daugiau nerodoma ir niekada nepatenka į vidinę užduočių eilę.
Visi čia paminėti prekių ženklai priklauso jų savininkams. MousePlayer su šiais teikėjais neturi verslo ryšių.