Exportálás objektumtárba
Teljesült célonként egy JSON-objektum, saját bucketjében. Ez az út minden olyan adattárházhoz, amely nem BigQuery.
1. Milyen hiányt pótol
Eddig pontosan egy út vezetett a MousePlayerből adattárházba, mégpedig a Google-höz. Snowflake, Redshift vagy ClickHouse használatakor nem volt ilyen — noha mindhárom gond nélkül olvas objektumtárból.
Ezért a híd nem egyenként az adattárházakba, hanem objektumtárba ír. A Snowflake, a Redshift és a ClickHouse S3-ból, a BigQuery Google Cloud Storage-ból fogad adatokat. Egyetlen export mindegyiket eléri.
| Hová | Hogyan címezzük |
|---|---|
| Amazon S3 | Signature Version 4, a bucket a kiszolgálónévben |
| Cloudflare R2 | Signature Version 4 az Ön fiókvégpontján |
| Google Cloud Storage | az S3-kompatibilis API-ján át, HMAC-kulccsal |
| MinIO, Wasabi, Backblaze B2 és mások | Signature Version 4 az Ön végpontján |
| Azure Blob Storage | konténerhez tartozó SAS-link — nálunk egyáltalán nincs aláírás |
2. Miért különleges az Azure, és miért jobb ez
Az Azure Blob nem Signature Version 4-et használ, hanem SharedKey-aláírást. Építhettünk volna második aláírási rendszert. Ehelyett a híd egy konténerhez tartozó SAS-linket fogad — ezt az URL-t saját tárfiókjában generálja, és már tartalmazza az aláírást.
Ez nálunk kevesebb kódot, Önnél kisebb bizalmi igényt jelent. Fiókkulcsot egyáltalán nem látunk: Ön saját maga által egyetlen konténerre korlátozott, saját lejárati idejű engedélyt ad át, amely bármi más érintése nélkül bármikor visszavonható.
Ugyanezt a visszafogottságot érdemes az S3-nál is alkalmazni: a hozzáférési kulcsnak csak ebbe az egy előtagba adjon írási jogot, semmi másra. Egy kizárólag a mouseplayer/goals/ útvonalhoz hozzáadni képes kulcs kiszivárgás esetén sem olvashatja más bucketjeit.
3. Célonként egy objektum, a kulcs pedig dátum
Az objektumtár nem tud hozzáfűzni. A napi fájlt minden alkalommal teljesen újra kellene írni, két egyszerre érkező cél pedig felülírná egymást. Ezért minden teljesült cél külön objektum lesz.
Ennek ára a sok kis objektum; a kulcsok elrendezése teszi használhatóvá:
prefix/YYYY/MM/DD/channel/session-goal.json
Az adattárház egy napot egy partícióként olvas, az utólagos feltöltés pedig előtag szerinti bejárás, nem lekérdezés. Ha dátum helyett projekt szerint particionálna, tegye a csatornaazonosítót az előtagba.
Minden objektum egyetlen JSON-sor
Szándékosan behúzás nélkül, hogy egy teljes előtag NDJSON-ként legyen olvasható az objektumok egyenkénti megnyitása nélkül. Időbélyeg, projekt, munkamenet, ügyfélazonosító, cél, érték, pénznem és a felvételt visszajátszó link.
Az üres érték null, nem nulla
A pénzérték nélküli cél ezt írja: null. Az adattárházban a nulla egy soha nem létezett összegbe számítana bele — a „nincs megállapított összeg” és a „nulla összeg” közötti különbség az exportban is megmarad.
4. Ha 403-mal válaszol, ezt olvassa először
Az elutasított S3-kérés szinte semmit nem mond; oka van, hogy naplónk hibaüzenete többet árul el az S3-nál: a régió az aláírás része. A hibás régió és a hibás kulcs ugyanazt a 403-at adja, ezért a kézenfekvő gyanú — a kulcs — csak az esetek felében helyes.
Három ellenőrizendő dolog, ebben a sorrendben:
- A régió, pontosan a bucket által jelzett alakban. Az R2 és a Google Cloud Storage az
autoértéket fogadja el, és nem ellenőrzi; mindenki más igen. - Az előtag jogosultsága. A kizárólag a
mouseplayer/útvonalra jogosított kulcs nem írhat ide:mouseplayer-goals/— az erőforrás ARN-jében a záró perjel számít. - A végpont, R2 és S3-kompatibilis tárak esetén. A kiszolgálónevet a
https://rész nélkül illessze be; ezt mindenképp eltávolítjuk, de a hozzáfűzött útvonal már másik bucketet jelent.
A hozzáférési kulcs azonosítóját szándékosan nyíltan tároljuk. Eleve minden aláírt kérésben továbbítódik, ezért titkosítása védelem nélküli erőfeszítés lenne. A titkos kulcs titkosított, többé nem mutatjuk meg, és soha nem kerül a feladatot hordozó belső várólistába.
Az itt említett védjegyek a tulajdonosaikhoz tartoznak. A MousePlayer nem áll üzleti kapcsolatban ezekkel a szolgáltatókkal.