Objektspeicher-Export

1. Die Lücke, die das schließt

Bis jetzt gab es genau einen Weg von MousePlayer in ein Datenlager, und er führte zu Google. Wer Snowflake, Redshift oder ClickHouse betreibt, hatte keinen - obwohl alle drei anstandslos aus Objektspeicher lesen.

Die Brücke schreibt deshalb in Objektspeicher statt der Reihe nach in jedes Datenlager. Snowflake liest aus S3, Redshift liest aus S3, ClickHouse liest aus S3, und BigQuery liest aus Google Cloud Storage. Ein Export erreicht sie alle.

Wohin	Wie es angesprochen wird
Amazon S3	Signature Version 4, Bucket im Host
Cloudflare R2	Signature Version 4 gegen den Endpunkt Ihres Kontos
Google Cloud Storage	über die S3-kompatible API, mit einem HMAC-Schlüssel
MinIO, Wasabi, Backblaze B2 und andere	Signature Version 4 gegen Ihren Endpunkt
Azure Blob Storage	ein Container-SAS-Link - gar keine Signierung auf unserer Seite

2. Warum Azure die Ausnahme ist - und warum das besser ist

Azure Blob spricht kein Signature Version 4; es signiert mit SharedKey. Wir hätten ein zweites Signierverfahren bauen können. Stattdessen nimmt die Brücke einen Container-SAS-Link - eine Adresse, die Sie in Ihrem eigenen Speicherkonto erzeugen und in der die Signatur bereits steckt.

Das ist weniger Code auf unserer Seite und weniger Vertrauen auf Ihrer. Wir bekommen überhaupt keinen Kontoschlüssel zu sehen: was Sie übergeben, ist eine Berechtigung, die Sie selbst zugeschnitten haben - auf einen Container, mit einem Ablaufdatum Ihrer Wahl, jederzeit zurückzunehmen, ohne sonst etwas anzufassen.

3. Ein Objekt je Ziel, und der Schlüssel ist ein Datum

Objektspeicher kennt kein Anhängen. Eine Tagesdatei müsste jedes Mal ganz neu geschrieben werden, und zwei gleichzeitig eintreffende Ziele überschrieben einander. Jedes erreichte Ziel wird deshalb ein eigenes Objekt.

Der Preis sind viele kleine Objekte; brauchbar macht das der Aufbau des Schlüssels:

praefix/JJJJ/MM/TT/kanal/sitzung-ziel.json

Ein Datenlager liest einen Tag als eine Partition, und ein Nachladen ist ein Präfix-Durchlauf statt einer Abfrage. Wer nach Projekt statt nach Datum partitionieren will, setzt die Kanalkennung ins Präfix.

Jedes Objekt ist eine Zeile JSON

Bewusst nicht eingerückt, damit sich ein ganzes Präfix als NDJSON lesen lässt, ohne die Objekte einzeln zu öffnen. Zeitpunkt, Projekt, Sitzung, Kundenkennung, Ziel, Wert, Währung und der Link, der die Aufzeichnung abspielt.

Ein fehlender Wert ist null, nicht null Euro

Ein Ziel ohne Geldwert schreibt null. In einem Datenlager summierte sich eine Null zu einem Gesamtwert auf, den es nie gab - der Unterschied zwischen „kein Betrag vereinbart" und „ein Betrag von null" überlebt den Export.

4. Wenn ein 403 kommt, zuerst das hier lesen

Eine abgelehnte S3-Anfrage sagt fast nichts, und es hat einen Grund, dass die Meldung in unserem Protokoll mehr sagt als S3 selbst: die Region geht in die Signatur ein. Eine falsche Region und ein falscher Schlüssel erzeugen denselben 403 - der naheliegende Verdacht, der Schlüssel, stimmt also nur in der Hälfte der Fälle.

Drei Dinge zu prüfen, in dieser Reihenfolge:

• Die Region, genau so, wie der Bucket sie meldet. R2 und Google Cloud Storage nehmen auto und prüfen sie nicht; alle übrigen schon.
• Die Präfix-Berechtigung. Ein Schlüssel für mouseplayer/ darf nicht nach mouseplayer-goals/ schreiben - der abschließende Schrägstrich zählt in einer Ressourcen-ARN.
• Den Endpunkt, bei R2 und S3-kompatiblen Speichern. Fügen Sie den Host ohne https:// ein; wir schneiden es ohnehin ab, aber ein angehängter Pfad ist ein anderer Bucket.