Export do objektového úložiště
Jeden objekt JSON na splněný cíl, v bucketu, který patří vám. Tudy vede cesta do každého datového skladu mimo BigQuery.
1. Jakou mezeru to vyplňuje
Dosud vedla z MousePlayer do datového skladu právě jedna cesta, a to ke Googlu. Pro Snowflake, Redshift nebo ClickHouse žádná nebyla, přestože všechny tři bez problémů čtou z objektového úložiště.
Most proto zapisuje do objektového úložiště místo zvlášť do každého skladu. Snowflake, Redshift a ClickHouse načítají ze S3, BigQuery z Google Cloud Storage. Jeden export obslouží všechny.
| Kam | Jak se přistupuje |
|---|---|
| Amazon S3 | Signature Version 4, bucket v názvu hostitele |
| Cloudflare R2 | Signature Version 4 vůči endpointu vašeho účtu |
| Google Cloud Storage | přes API kompatibilní se S3, s klíčem HMAC |
| MinIO, Wasabi, Backblaze B2 a další | Signature Version 4 vůči vašemu endpointu |
| Azure Blob Storage | odkaz SAS na kontejner - bez podepisování na naší straně |
2. Proč je Azure výjimka a proč je to lepší
Azure Blob nepoužívá Signature Version 4, ale podepisuje pomocí SharedKey. Mohli jsme vytvořit druhé podpisové schéma. Most však místo toho přijímá odkaz SAS na kontejner - adresu URL, kterou vygenerujete ve vlastním účtu úložiště a která už obsahuje podpis.
Znamená to méně kódu u nás a méně důvěry, kterou nám musíte dát. Klíč účtu nikdy nevidíme: předáváte oprávnění, které sami omezíte na jeden kontejner, s vlastním datem vypršení, kdykoli odvolatelné bez zásahu do čehokoli dalšího.
Stejná zdrženlivost se hodí i na straně S3: povolte přístupovému klíči zápis pouze pod tento jediný prefix a nikam jinam. Klíč s možností přidávat pouze do mouseplayer/goals/ nemůže číst vaše ostatní buckety, ani když unikne.
3. Jeden objekt na cíl, klíčem je datum
Objektové úložiště neumí připojovat obsah ke stávajícímu objektu. Denní soubor by se musel pokaždé celý přepsat a dva současně přijaté cíle by se navzájem přepsaly. Každý splněný cíl se proto stane samostatným objektem.
Cenou je mnoho malých objektů; použitelnost zajišťuje struktura klíčů:
prefix/YYYY/MM/DD/channel/session-goal.json
Datový sklad načítá jeden den jako jeden oddíl a zpětné doplnění je prohledání prefixu místo dotazu. Pokud chcete dělit podle projektu namísto data, vložte do prefixu ID kanálu.
Každý objekt je jeden řádek JSON
Záměrně bez odsazení, aby bylo možné celý prefix číst jako NDJSON bez otevírání objektů po jednom. Časové razítko, projekt, relace, ID zákazníka, cíl, hodnota, měna a odkaz pro přehrání záznamu.
Prázdná hodnota je null, ne nula
Cíl bez peněžní hodnoty zapisuje null. V datovém skladu by se nula započítala do součtu, který nikdy neexistoval - rozdíl mezi „částka nebyla dohodnuta“ a „částka je nula“ se při exportu zachová.
4. Při odpovědi 403 si nejprve přečtěte toto
Odmítnutý požadavek S3 téměř nic neříká a existuje důvod, proč naše chybová zpráva v protokolu vysvětlí více než S3: region je součástí podpisu. Nesprávný region i klíč vrátí stejnou chybu 403, takže nejzřejmější podezření - klíč - je správné jen v polovině případů.
Zkontrolujte tři věci v tomto pořadí:
- Region, přesně podle údajů bucketu. R2 a Google Cloud Storage přijmou
autoa nekontrolují ho; ostatní ano. - Oprávnění prefixu. Klíč omezený na
mouseplayer/nemůže zapisovat domouseplayer-goals/- koncové lomítko je v ARN prostředku důležité. - Endpoint, pro R2 a úložiště kompatibilní se S3. Vložte hostitele bez
https://; tuto část sice odstraníme i sami, ale připojená cesta označuje jiný bucket.
ID přístupového klíče se záměrně ukládá v otevřené podobě. Ze své podstaty cestuje v každém podepsaném požadavku, takže jeho šifrování by byla práce bez přidané ochrany. Tajný klíč je zašifrovaný, nikdy se znovu nezobrazí a nevstupuje do interní fronty úloh.
Všechny uvedené ochranné známky patří příslušným vlastníkům. MousePlayer s těmito poskytovateli nemá obchodní vztah.