Eksports uz objektu krātuvi
Viens JSON objekts katram sasniegtam mērķim jums piederošā konteinerā. Tas ir ceļš uz ikvienu datu noliktavu, kas nav BigQuery.
1. Kādu trūkumu tas novērš
Līdz šim no MousePlayer uz datu noliktavu bija tieši viens ceļš, un tas veda uz Google. Ja izmantojat Snowflake, Redshift vai ClickHouse, ceļa nebija — lai gan visi trīs bez grūtībām lasa no objektu krātuves.
Tāpēc tilts raksta objektu krātuvē, nevis pēc kārtas katrā datu noliktavā. Snowflake ielasa no S3, Redshift ielasa no S3, ClickHouse ielasa no S3 un BigQuery ielasa no Google Cloud Storage. Viens eksports sasniedz tos visus.
| Kur | Kā tiek adresēts |
|---|---|
| Amazon S3 | Signature Version 4, konteiners resursdatorā |
| Cloudflare R2 | Signature Version 4 pret jūsu konta galapunktu |
| Google Cloud Storage | caur tā ar S3 saderīgo API, izmantojot HMAC atslēgu |
| MinIO, Wasabi, Backblaze B2 un citi | Signature Version 4 pret jūsu galapunktu |
| Azure Blob Storage | konteinera SAS saite — mūsu pusē parakstīšana vispār nenotiek |
2. Kāpēc Azure ir atšķirīgs un kāpēc tas ir labāk
Azure Blob neizmanto Signature Version 4; tas paraksta ar SharedKey. Mēs varējām izveidot otru parakstīšanas shēmu. Tā vietā tilts pieņem konteinera SAS saiti — URL, ko ģenerējat savā krātuves kontā un kurā jau ir paraksts.
Tas nozīmē mazāk koda mūsu pusē un mazāku vajadzību uzticēties jūsu pusē. Mēs nekad neredzam konta atslēgu: jūs nododat pašu ierobežotu atļauju vienam konteineram ar pašu izvēlētu derīguma termiņu, ko var atsaukt jebkurā brīdī, neko citu neaiztiekot.
Tāda pati ierobežošana ir noderīga S3 pusē: piešķiriet piekļuves atslēgai atļauju rakstīt tikai šajā vienā prefiksā un nekur citur. Atslēga, kas var tikai papildināt mouseplayer/goals/, nevar nolasīt pārējos konteinerus pat noplūdes gadījumā.
3. Viens objekts katram mērķim, un atslēga ir datums
Objektu krātuvē nevar pievienot datus esošā objekta beigās. Dienas fails katru reizi būtu jāpārraksta pilnībā, un divi vienlaikus pienākuši mērķi pārrakstītu viens otru. Tāpēc katrs sasniegtais mērķis kļūst par atsevišķu objektu.
Cena ir daudz mazu objektu; to padara praktiski lietojamu atslēgu struktūra:
prefix/YYYY/MM/DD/channel/session-goal.json
Datu noliktava nolasa vienu dienu kā vienu nodalījumu, un vēsturisko datu papildināšana ir prefiksa skenēšana, nevis vaicājums. Ja vēlaties dalīt pēc projekta, nevis datuma, ievietojiet prefiksā kanāla ID.
Katrs objekts ir viena JSON rinda
Apzināti bez atkāpēm, lai visu prefiksu varētu lasīt kā NDJSON, neatverot objektus pa vienam. Laikspiedols, projekts, sesija, klienta ID, mērķis, vērtība, valūta un saite ieraksta atskaņošanai.
Tukša vērtība ir null, nevis nulle
Mērķis bez naudas vērtības ieraksta null. Datu noliktavā nulle tiktu ieskaitīta kopsummā, kas nekad nav pastāvējusi, — atšķirība starp „summa nav noteikta“ un „summa ir nulle“ saglabājas arī eksportā.
4. Ja atbilde ir 403, vispirms izlasiet šo
Noraidīts S3 pieprasījums pasaka gandrīz neko, un ir iemesls, kāpēc kļūdas paziņojums mūsu žurnālā pasaka vairāk nekā S3: reģions tiek iekļauts parakstā. Nepareizs reģions un nepareiza atslēga rada vienu un to pašu 403, tāpēc acīmredzamās aizdomas par atslēgu ir pareizas tikai pusē gadījumu.
Trīs lietas, kas jāpārbauda šādā secībā:
- Reģions tieši tāds, kādu norāda konteiners. R2 un Google Cloud Storage izmanto
autoun to nepārbauda; visi pārējie pārbauda. - Prefiksa atļauja. Atslēga ar tvērumu
mouseplayer/nevar rakstītmouseplayer-goals/— noslēdzošajai slīpsvītrai resursa ARN ir nozīme. - Galapunkts R2 un ar S3 saderīgām krātuvēm. Ielīmējiet resursdatoru bez
https://; mēs to noņemam abos gadījumos, taču pievienots ceļš nozīmē citu konteineru.
Piekļuves atslēgas ID apzināti tiek glabāts atklātā tekstā. Tas pēc būtības tiek sūtīts katrā parakstītajā pieprasījumā, tāpēc tā šifrēšana būtu darbs bez aizsardzības ieguvuma. Noslēpums tiek šifrēts, vairs netiek parādīts un nekad nenonāk iekšējā rindā, kas pārvadā uzdevumu.
Visas šeit minētās preču zīmes pieder to attiecīgajiem īpašniekiem. MousePlayer nav darījumu attiecību ar šiem nodrošinātājiem.