Export naar objectopslag

1. Het gat dat dit opvult

Tot nu toe was er precies één route van MousePlayer naar een datawarehouse, en die leidde naar Google. Voor Snowflake, Redshift of ClickHouse was er geen, hoewel alle drie probleemloos uit objectopslag lezen.

Daarom schrijft de koppeling naar objectopslag in plaats van elk datawarehouse afzonderlijk te bedienen. Snowflake, Redshift en ClickHouse lezen uit S3; BigQuery leest uit Google Cloud Storage. Eén export bereikt ze allemaal.

Waar	Hoe het wordt aangesproken
Amazon S3	Signature Version 4, bucket in de hostnaam
Cloudflare R2	Signature Version 4 via uw accountendpoint
Google Cloud Storage	via de S3-compatibele API, met een HMAC-sleutel
MinIO, Wasabi, Backblaze B2 en andere	Signature Version 4 via uw endpoint
Azure Blob Storage	een SAS-link voor de container, zonder ondertekening aan onze kant

2. Waarom Azure anders is en waarom dat beter is

Azure Blob gebruikt geen Signature Version 4, maar ondertekent met SharedKey. We hadden een tweede ondertekeningsmethode kunnen bouwen. In plaats daarvan gebruikt de koppeling een SAS-link voor de container : een URL die u in uw eigen opslagaccount genereert en die de handtekening al bevat.

Dat betekent minder code bij ons en minder vertrouwen dat u ons hoeft te geven. We zien helemaal geen accountsleutel: u verstrekt een machtiging die u zelf hebt afgebakend, voor één container, met een zelfgekozen vervaldatum, op elk moment intrekbaar zonder iets anders te veranderen.

3. Eén object per doel, met een datum als sleutel

Objectopslag ondersteunt geen toevoegingen aan een bestaand object. Een dagelijks bestand zou elke keer volledig moeten worden herschreven, en twee doelen die tegelijk binnenkomen, zouden elkaar overschrijven. Daarom wordt elk bereikt doel een eigen object.

De prijs is een groot aantal kleine objecten; de sleutelstructuur maakt dat werkbaar:

prefix/YYYY/MM/DD/channel/session-goal.json

Een datawarehouse leest één dag als één partitie, en achteraf aanvullen gebeurt via een scan van een prefix in plaats van een query. Als u per project wilt partitioneren in plaats van per datum, neemt u de kanaal-ID in het prefix op.

Elk object is één regel JSON

Bewust zonder inspringing, zodat een volledig prefix als NDJSON kan worden gelezen zonder de objecten één voor één te openen. Tijdstempel, project, sessie, klant-ID, doel, waarde, valuta en de link om de opname af te spelen.

Een lege waarde is null, niet nul

Een doel zonder geldwaarde schrijft null. In een datawarehouse zou een nul meetellen in een totaal dat nooit heeft bestaan. Het verschil tussen “geen bedrag afgesproken” en “een bedrag van nul” blijft bij de export behouden.

4. Lees dit eerst bij een 403-antwoord

Een geweigerd S3-verzoek vertelt bijna niets. Er is een reden waarom de foutmelding in ons logboek meer zegt dan S3 zelf: de regio maakt deel uit van de handtekening. Een verkeerde regio en een verkeerde sleutel leveren dezelfde 403 op, dus de voor de hand liggende verdachte, de sleutel, is maar in de helft van de gevallen de oorzaak.

Controleer drie dingen, in deze volgorde:

• De regio, precies zoals de bucket die opgeeft. R2 en Google Cloud Storage accepteren auto en controleren dit niet; alle andere doen dat wel.
• De rechten voor het prefix. Een sleutel die beperkt is tot mouseplayer/ kan niet schrijven naar mouseplayer-goals/ ; de afsluitende slash is van belang in een resource-ARN.
• Het endpoint, voor R2 en S3-compatibele opslag. Plak de host zonder https://; we verwijderen dat deel hoe dan ook, maar een toegevoegd pad verwijst naar een andere bucket.