Zum Inhalt springen
SwankyForge
SwankyForge
Alle Fallstudien
DatenpipelinesMetrikenBI3 Monate

USDDub

Die Dashboards hinkten der Realität sechs Stunden hinterher. Jetzt sind es fünf Minuten.

Datenaktualität

5 Minuten

Streaming mit wiederholbaren Stufen

Vorher

6 Stunden

Geplante Batch-Extrakte

In einfachen Worten

Worum es geht.

In diesem Abschnitt kein Fachjargon. Die technische Beschreibung folgt weiter unten.

Was schieflief

Die Daten kamen schneller an, als die nächtlichen Jobs sie verarbeiten konnten, sodass man beim Öffnen eines Dashboards bestenfalls den Stand von heute Morgen sah. Musste etwas neu verarbeitet werden, erledigte das ein Engineer von Hand – oft am Wochenende.

Was wir gebaut haben

Wir haben die geplanten nächtlichen Jobs durch einen kontinuierlichen Fluss ersetzt, der sich ab jedem Punkt erneut abspielen lässt, und jede Zahl an eine gemeinsame Definition gebunden.

Was sich geändert hat

Entscheidungen werden auf Daten getroffen, die Minuten statt Stunden alt sind, Neuverarbeitung kostet niemanden mehr ein Wochenende, und alle Teams lesen dieselben Zahlen.

Architektur

Wie alles zusammenpasst.

Scrollen Sie durch die Phasen. Alles, was als hinzugefügt markiert ist, ist eine Komponente, die es vor diesem Projekt nicht gab.

AUFNAHMETRANSFORMATIONQuell-APIsMARKT + CHAINKafkaPARTITIONIERTClickHouseSPALTENORIENTIERTdbt-ModelleINKREMENTELLBI-SchichtKONTROLLIERT

  1. Quell-APIs

    Markt + Chain

    speist
    KafkaAufnahme

  2. Kafka

    partitioniert

    Das haben wir hinzugefügt
    erhält von
    Quell-APIsAufnahme
    speist
    ClickHouse

  3. ClickHouse

    spaltenorientiert

    Das haben wir hinzugefügt
    erhält von
    Kafka
    speist
    dbt-ModelleTransformation

  4. dbt-Modelle

    inkrementell

    Das haben wir hinzugefügt
    erhält von
    ClickHouseTransformation
    speist
    BI-Schicht

  5. BI-Schicht

    kontrolliert

    erhält von
    dbt-Modelle
Die Beschreibung

Wie es gebaut würde.

Datensatz, Vorgehen, Zielmetriken und der Stack. Geschrieben für die Person, die es prüfen muss.

DatenpipelinesMetrikenBI3 Monate

USDDub

Kanonische Marktdaten und Signale, die über Quellen und Zeit hinweg konsistent bleiben.

Problem

Markt- und Ereignisdaten kamen schneller an, als die bestehenden Batch-Jobs sie verarbeiten konnten, sodass die Dashboards stundenlang veraltet waren und Backfills manuelle Neuläufe erforderten.

Datensatz

Zeilen
14 Mio. Events / Tag
Features
203
Quellen
Markt-APIs, On-Chain, interne Dienste
Zeitraum
Rollierend 90 Tage

Vorgehen

  1. 01Batch-Extrakte durch eine Streaming-Ingestion-Schicht ersetzt
  2. 02Ein spaltenorientiertes Warehouse modelliert, abgestimmt auf die tatsächlichen Abfragemuster
  3. 03Jede Stufe idempotent gemacht, sodass Backfills ein Replay sind und keine Rettungsaktion
  4. 04Einen kontrollierten Metriksatz hinter einer BI-Schicht veröffentlicht

Metriken

14 Mio.+
Events / Tag
dauerhaft
5 Min.
Datenaktualität
statt 6 Stunden
410 ms
Query p95
-8,4 s
automatisiert
Backfill-Aufwand
statt manuell

Evidenz

Quelle
Referenzdesign
Zahlen
Illustrativ – typische Werte für dieses Design
Messung
Nicht gemessen. Typische Werte für ein Referenzdesign dieser Art, nicht auf einem Kundensystem beobachtet.
Referenz
Für dieses Projekt nicht verfügbar
zuletzt geprüft
2026-08-25

Geschäftlicher Effekt

  • Entscheidungen auf Daten, die Minuten statt Stunden alt sind
  • Backfills kosten das Engineering keine Wochenenden mehr
  • Ein Metrik-Layer, den alle internen Nutzer teilen

Tech-Stack

  • Python
  • TimescaleDB
  • Kafka
  • Prefect
  • Grafana
  • dbt
  • Web3.py
ZurückPlug-and-Play Commerce AnalyticsWeiterDocument Intelligence (OCR, Extraktion, RAG)

Weiter

Brauchen Sie ein System wie dieses?

Beantworten Sie sechs Fragen, und wir sagen Ihnen, ob diese Form zu Ihrem Problem passt – auch wenn sie es nicht tut.

Mein Produkt prüfenDiese Form schätzen