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.

KamJak se přistupuje
Amazon S3Signature Version 4, bucket v názvu hostitele
Cloudflare R2Signature Version 4 vůči endpointu vašeho účtu
Google Cloud Storagepř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 Storageodkaz 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 auto a nekontrolují ho; ostatní ano.
  • Oprávnění prefixu. Klíč omezený na mouseplayer/ nemůže zapisovat do mouseplayer-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.