Semantik der Zustellung von Events
Auf dieser Seite wird beschrieben und definiert, wie Currents die Flat-File-Event-Daten verwaltet, die wir an Data Warehouse-Speicherpartner senden.
„Currents für Datenspeicher“ ist ein kontinuierlicher Datenstrom von unserer Plattform zu einem Speicher-Bucket auf einer unserer Data Warehouse-Partnerverbindungen. Currents schreibt Avro-Dateien in regelmäßigen Abständen in Ihren Speicher-Bucket, sodass Sie die Event-Daten mit Ihrem eigenen Business-Intelligence-Toolset (BI) verarbeiten und analysieren können.

Dieser Inhalt gilt nur für die Flat-File-Event-Daten, die wir an Data Warehouse-Speicherpartner (Google Cloud Storage, Amazon S3 und Microsoft Azure Blob Storage) senden.
Inhalte, die für andere Partner gelten, finden Sie in unserer Liste der verfügbaren Partner und auf den jeweiligen Seiten.
Test-Events
Wenn Sie eine Currents-Integration einrichten, klicken Sie auf Test-Events senden, um die Verbindung mit Ihrem Speicher-Bucket zu überprüfen. Diese Test-Events bestätigen, dass Ihre Integration Daten korrekt empfangen und verarbeiten kann.

Datenformat von Test-Events: Test-Events enthalten Platzhalterwerte, die den korrekten Datentypen für jedes Feld entsprechen, jedoch keine realistischen oder genauen Daten enthalten. Beispielsweise kann ein timezone-Feld einen UUID-ähnlichen String anstelle eines gültigen Zeitzonen-Bezeichners (wie „America/Chicago“) enthalten, und andere Felder wie campaign_name und ip_pool können ebenfalls Platzhalterwerte anstelle tatsächlicher Daten enthalten.
Dies ist das erwartete Verhalten. Test-Events dienen in erster Linie zum Testen der Verbindung und des Integrations-Setups, nicht zur Validierung der Datengenauigkeit. Um echte Events mit genauen Daten zu sehen, verwenden Sie eine Test-Currents-Integration, um tatsächliche Event-Daten durch Ihre Pipeline zu senden.
„At-least-once“-Zustellung
Als Hochdurchsatzsystem bietet Currents eine „At-least-once“-Zustellung von Events, was bedeutet, dass gelegentlich doppelte Events in Ihren Speicher-Bucket geschrieben werden können. Dies kann passieren, wenn Events aus unserer Warteschlange aus irgendeinem Grund erneut verarbeitet werden.
Wenn Ihre Anwendungsfälle eine „Exactly-once“-Zustellung erfordern, können Sie das eindeutige Bezeichnerfeld, das mit jedem Event gesendet wird (id), zur Deduplizierung von Events verwenden. Da die Datei unserer Kontrolle entgeht, sobald sie in Ihren Speicher-Bucket geschrieben wird, können wir keine Deduplizierung von unserer Seite garantieren.
Zeitstempel
Alle von Currents exportierten Zeitstempel werden in der UTC-Zeitzone gesendet. Für einige Events, bei denen es verfügbar ist, wird auch ein Zeitzonen-Feld mitgeliefert, das die Ortszeit der Nutzer:innen zum Zeitpunkt des Events im IANA-Format (Internet Assigned Numbers Authority) enthält.
Latenz
Events, die über SDK oder API an Braze gesendet werden, können einen Zeitstempel aus der Vergangenheit enthalten. Das häufigste Beispiel ist, wenn SDK-Daten in eine Warteschlange gestellt werden, etwa wenn keine mobile Konnektivität besteht. In diesem Fall spiegelt der Event-Zeitstempel wider, wann das Event generiert wurde. Das bedeutet, dass ein gewisser Prozentsatz der Events eine hohe Latenz aufweisen wird.
Apache-Avro-Format
Die Braze-Currents-Datenspeicher-Integrationen geben Daten im .avro-Format aus. Wir haben Apache Avro gewählt, weil es ein flexibles Datenformat ist, das nativ Schema-Evolution unterstützt und von einer Vielzahl von Datenprodukten unterstützt wird:
- Avro wird von nahezu jedem großen Data Warehouse unterstützt.
- Falls Sie Ihre Daten in S3 belassen möchten, komprimiert Avro besser als CSV und JSON, sodass Sie weniger für Speicher bezahlen und potenziell weniger CPU zum Parsen der Daten benötigen.
- Avro erfordert Schemas beim Schreiben oder Lesen von Daten. Schemas können im Laufe der Zeit weiterentwickelt werden, um das Hinzufügen von Feldern zu handhaben, ohne dass etwas kaputtgeht.
Currents erstellt für jeden Event-Typ eine Datei im folgenden Format:
1
<your-bucket-prefix>/dataexport.<cluster-identifier>.<connection-type-identifier>.integration.<integration-id>/event_type=<event-type>/date=<date>/version=<currents_version>/<environment>/dataexport.<cluster-identifier>.<connection-type-identifier>.integration.<integration-id>+<partition>+<offset>.avro

Sie können den Code wegen der Scrollleiste nicht sehen? Erfahren Sie hier, wie Sie das beheben können.
Beispielsweise kann ein Pfad für ein Push-Sende-Event so aussehen:
1
currents-export/dataexport.prod-01.S3.integration.69cadaaed2d51b7c75b1a3e5/event_type=users.messages.pushnotification.Send/date=2025-04-01-17/version=6/us-01/dataexport.prod-01.S3.integration.69cadaaed2d51b7c75b1a3e5+0+123456.avro
Das Pfadsegment version ist ein einfacher ganzzahliger Currents-Versionswert, z. B. version=6.
| Dateinamensegment | Definition |
|---|---|
<your-bucket-prefix> |
Das für diese Currents-Integration festgelegte Präfix. |
<cluster-identifier> |
Für den internen Gebrauch durch Braze. Ist ein String wie „prod-01“, „prod-02“, „prod-03“ oder „prod-04“. Alle Dateien haben denselben Cluster-Bezeichner. |
<connection-type-identifier> |
Der Bezeichner für den Verbindungstyp. Optionen sind „S3“, „AzureBlob“ oder „GCS“. |
<integration-id> |
Die eindeutige ID für diese Currents-Integration. |
<event-type> |
Der Typ des Events in der Datei. |
<date> |
Die Stunde, in der Events in unserem System zur Verarbeitung in der UTC-Zeitzone in die Warteschlange gestellt werden. Format: JJJJ-MM-TT-HH. |
version=<currents_version> |
Die Currents-Version für den Pipeline-Pfad. Dieser Wert ist eine einfache Ganzzahl wie 6. |
<environment> |
Für den internen Gebrauch durch Braze. |
<partition> |
Für den internen Gebrauch durch Braze. Ganzzahl. |
<offset> |
Für den internen Gebrauch durch Braze. Ganzzahl. Beachten Sie, dass verschiedene Dateien, die innerhalb derselben Stunde gesendet werden, einen unterschiedlichen <offset>-Parameter haben. |

Dateibenennungskonventionen können sich ändern. Braze empfiehlt, alle Schlüssel in Ihrem Bucket zu durchsuchen, die das Präfix <your-bucket-prefix> haben.
Avro-Schreibschwellenwert
Unter normalen Umständen schreibt Braze alle 5 Minuten oder alle 15.000 Events Datendateien in Ihren Speicher-Bucket – je nachdem, was zuerst eintritt. Bei hoher Last können wir größere Datendateien mit bis zu 100.000 Events pro Datei schreiben.

Currents schreibt niemals leere Dateien.
Avro-Schema-Änderungen
Von Zeit zu Zeit kann Braze Änderungen am Avro-Schema vornehmen, wenn Felder hinzugefügt, geändert oder entfernt werden. Für unsere Zwecke gibt es hier zwei Arten von Änderungen: nicht-brechende und brechende. Alle Schema-Änderungen werden in Currents-Releases gebündelt, und jedes Release erhöht das Segment version=<currents_version> im Speicherpfad (z. B. von version=6 auf version=7). Currents-Events, die in Azure Blob Storage, Google Cloud Storage und Amazon S3 geschrieben werden, verwenden das folgende Pfadformat:
1
<your-bucket-prefix>/<currents-integration-id>/event_type=<event-type>/date=<date>/version=<currents_version>/<environment>/<avro-file>
Nicht-brechende Änderungen
Wenn ein Feld zum Avro-Schema hinzugefügt wird, betrachten wir dies als nicht-brechende Änderung. Hinzugefügte Felder sind immer „optionale“ Avro-Felder (z. B. mit einem Standardwert von null), sodass sie gemäß der Avro-Schema-Auflösungsspezifikation mit älteren Schemas „übereinstimmen“. Diese Ergänzungen sollten bestehende ETL-Prozesse (Extract, Transform, Load) nicht beeinträchtigen, da das Feld einfach ignoriert wird, bis es zu Ihrem ETL-Prozess hinzugefügt wird.

Wir empfehlen, dass Ihr ETL-Setup explizit die zu verarbeitenden Felder angibt, um zu vermeiden, dass der Ablauf beim Hinzufügen neuer Felder unterbrochen wird.
Brechende Änderungen
Wenn ein Feld aus dem Avro-Schema entfernt oder darin geändert wird, betrachten wir dies als brechende Änderung. Brechende Änderungen können Anpassungen an bestehenden ETL-Prozessen erfordern, da Felder, die zuvor verwendet wurden, möglicherweise nicht mehr wie erwartet aufgezeichnet werden.
Alle brechenden Änderungen werden vor dem Release im Voraus kommuniziert.
Eine vollständige Änderungshistorie nach Version finden Sie im Currents-Changelog.