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.

KurKā tiek adresēts
Amazon S3Signature Version 4, konteiners resursdatorā
Cloudflare R2Signature Version 4 pret jūsu konta galapunktu
Google Cloud Storagecaur tā ar S3 saderīgo API, izmantojot HMAC atslēgu
MinIO, Wasabi, Backblaze B2 un citiSignature Version 4 pret jūsu galapunktu
Azure Blob Storagekonteinera 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 auto un to nepārbauda; visi pārējie pārbauda.
  • Prefiksa atļauja. Atslēga ar tvērumu mouseplayer/ nevar rakstīt mouseplayer-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.