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 S3Signature Version 4, a bucket a kiszolgálónévben
Cloudflare R2Signature Version 4 az Ön fiókvégpontján
Google Cloud Storageaz S3-kompatibilis API-ján át, HMAC-kulccsal
MinIO, Wasabi, Backblaze B2 és másokSignature Version 4 az Ön végpontján
Azure Blob Storagekonté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.