API źródłowe
rynek + chain
- zasila
- Kafkaimport
Wszystkie case studies
Pipeline'y danychMetrykiBI3 miesiące
USDDub
Dashboardy były sześć godzin za rzeczywistością. Teraz są pięć minut za nią.
Aktualność danych
5 minut
Przetwarzanie strumieniowe z etapami do ponownego odtworzenia
Było
6 godzin
Zaplanowane ekstrakty wsadowe
Prostymi słowami
Czym to jest.
W tej sekcji nie ma żargonu. Opis techniczny jest niżej.
Co szło nie tak
Dane napływały szybciej, niż nocne zadania potrafiły je przetworzyć, więc każdy, kto otwierał dashboard, widział w najlepszym razie stan z rana. Gdy coś trzeba było przetworzyć ponownie, robił to ręcznie inżynier — często w weekend.
Co zbudowaliśmy
Zastąpiliśmy zaplanowane nocne zadania ciągłym przepływem, który można odtworzyć od dowolnego punktu, a każdą liczbę oparliśmy na jednej wspólnej definicji.
Co się zmieniło
Decyzje zapadają na danych sprzed minut, a nie godzin, ponowne przetwarzanie nie zabiera już nikomu weekendu, a wszystkie zespoły widzą te same liczby.
Architektura
Jak to się ze sobą łączy.
Proszę przewinąć etapy. Wszystko oznaczone jako dodane to komponent, który nie istniał przed tym projektem.
Kafka
partycjonowany
- otrzymuje z
- API źródłoweimport
- zasila
- ClickHouse
ClickHouse
kolumnowa
- otrzymuje z
- Kafka
- zasila
- modele dbttransformacja
modele dbt
przyrostowe
- otrzymuje z
- ClickHousetransformacja
- zasila
- Warstwa BI
Warstwa BI
zarządzane
- otrzymuje z
- modele dbt
API źródłowe
rynek + chain
- zasila
- Kafkaimport
Kafka
partycjonowany
To dodaliśmy- otrzymuje z
- API źródłoweimport
- zasila
- ClickHouse
ClickHouse
kolumnowa
To dodaliśmy- otrzymuje z
- Kafka
- zasila
- modele dbttransformacja
modele dbt
przyrostowe
To dodaliśmy- otrzymuje z
- ClickHousetransformacja
- zasila
- Warstwa BI
Warstwa BI
zarządzane
- otrzymuje z
- modele dbt
Opis
Jak by to zbudować.
Zbiór danych, podejście, docelowe metryki i stack. Napisane dla tego, kto będzie to weryfikował.
Pipeline'y danychMetrykiBI3 miesiące
USDDub
Kanoniczne dane rynkowe i sygnały, które pozostają spójne między źródłami i w czasie.
Problem
Dane rynkowe i dane o zdarzeniach napływały szybciej, niż istniejące zadania wsadowe potrafiły je przetworzyć, więc dashboardy były opóźnione o godziny, a backfille wymagały ręcznych ponownych uruchomień.
Zbiór danych
- wiersze
- 14 mln zdarzeń / dzień
- cechy
- 203
- źródła
- API rynkowe, on-chain, usługi wewnętrzne
- okno
- Kroczące 90 dni
Podejście
- 01Zastąpiliśmy ekstrakty wsadowe warstwą importu strumieniowego
- 02Zamodelowaliśmy kolumnową hurtownię dostrojoną do rzeczywistych wzorców zapytań
- 03Uczyniliśmy każdy etap idempotentnym, więc backfill to ponowne odtworzenie, a nie akcja ratunkowa
- 04Udostępniliśmy zarządzany zestaw metryk za warstwą BI
Metryki
- 14 mln+
- zdarzenia / dzień stale
- 5 min
- aktualność danych z 6 godzin
- 410ms
- zapytanie p95 -8.4s
- zautomatyzowany
- nakład na backfill zamiast ręcznego
Dowody
- źródło
- Projekt referencyjny
- liczby
- Poglądowe — typowe wartości dla tego projektu
- pomiar
- Nie mierzono. Typowe wartości dla projektu referencyjnego tego rodzaju, nie zaobserwowane w systemie klienta.
- referencje
- Niedostępne dla tego projektu
- ostatnia weryfikacja
- 2026-08-25
Wpływ na biznes
- Decyzje na danych sprzed minut zamiast godzin
- Backfille przestały zabierać inżynierom weekendy
- Jedna warstwa metryk wspólna dla wszystkich odbiorców wewnętrznych
Stack technologiczny
- Python
- TimescaleDB
- Kafka
- Prefect
- Grafana
- dbt
- Web3.py
Dalej
Potrzebują Państwo takiego systemu?
Proszę odpowiedzieć na sześć pytań, a powiemy, czy ten kształt pasuje do Państwa problemu — także wtedy, gdy nie pasuje.