trade-doc/dlob-retention-feature-store-plan.md

DLOB Retention And Feature Store Plan

Status na 2026-03-29.

Ten dokument zapisuje robocze ustalenia o:

• retencji danych DLOB na mevnode_bot
• ryzyku zajetosci dysku
• tym, co warto trzymac dlugo pod modele / "economic transformers"

Aktualny stan operacyjny

Dysk

• root / na mevnode_bot: 3.6T
• zajete: ok. 471G
• wolne: ok. 3.0T
• biezace uzycie: ok. 14%

Najwiekszy konsument miejsca:

• PostgreSQL / TimescaleDB na local volume poda postgres-0
• rozmiar bazy crypto: ok. 457 GB

Najwieksze hypertable:

• public.dlob_all_derived_ts: ok. 260 GB
• public.dlob_hot_snapshot_ts: ok. 177 GB
• public.dlob_hot_derived_ts: ok. 19 GB

Wniosek:

• miejsca nie brakuje teraz
• ale storage DLOB jest juz na tyle duzy, ze trzeba nim zarzadzac swiadomie

Od kiedy sa dane

• dlob_hot_snapshot_ts: od 2026-03-17 00:23:36.013+00
• dlob_hot_derived_ts: od 2026-03-17 00:23:36.013+00
• dlob_all_derived_ts: od 2026-03-17 00:44:42.386+00

Aktualna retencja TimescaleDB

Na 2026-03-29 retencja jest juz ustawiona i joby sa Success.

• dlob_hot_snapshot_ts: 30 days
• dlob_all_derived_ts: 30 days
• dlob_hot_derived_ts: 180 days
• legacy dlob_stats_ts / dlob_depth_bps_ts / dlob_slippage_ts*: 7 days

Wazne doprecyzowanie:

• stare rekordy nie beda "nadpisywane"
• stare chunki beda usuwane przez polityki retencji

Praktycznie:

• tabele 30-day zaczna byc realnie przycinane okolo 2026-04-16
• dlob_hot_derived_ts zacznie byc realnie przycinane dopiero po osiagnieciu ok. 180 days

Czy trzeba juz robic ring buffer

Nie pilnie.

Lepsza kolejnosc:

1. Zostawic obecna retencje.
2. Sprawdzic po 2026-04-16, czy 30-day tabele rzeczywiscie zaczely sie wyplaszczac rozmiarowo.
3. Wlaczyc kompresje TimescaleDB dla duzych hypertabli.
4. Dopiero potem decydowac, czy potrzebny jest dodatkowy custom ring buffer.

Powod:

• miejsca jest duzo
• retencja juz istnieje
• najwiekszy zysk teraz da kompresja, nie customowa logika bufora

Wazna obserwacja

Na 2026-03-29 kompresja TimescaleDB dla tabel dlob_* jest wylaczona:

• public.dlob_all_derived_ts: compression_enabled = false
• public.dlob_hot_snapshot_ts: compression_enabled = false
• public.dlob_hot_derived_ts: compression_enabled = false

To jest najprostszy kandydat na kolejny krok oszczedzania miejsca.

Co warto trzymac dlugo dla modeli

Nie warto trzymac wszystkiego w raw snapshotach.

Do treningu modeli bardziej oplacalne jest trzymanie:

• stalych cech numerycznych
• etykiet future outcome
• kilku skal czasowych

Zamiast:

• pelnego payload JSON
• wszystkich poziomow bids/asks dla kazdego ticka
• duplikowania raw i derived w dlugim horyzoncie

Rekomendowana piramida danych

Warstwa 1. Short-term raw

Przechowywac krotko jako source of truth:

• dlob_hot_snapshot_ts
• dlob_all_derived_ts

Cel:

• debugging
• replay
• reprocessing
• walidacja feature engineering

Warstwa 2. Feature bars

Z raw / derived budowac stale, numeryczne wektory cech:

• 1s feature bars na 180d+
• 5s albo 15s feature bars na 1y+
• 1m regime bars bardzo dlugo

To powinno byc glownym wejsciem do modeli.

Warstwa 3. Labels

Osobno trzymac etykiety przyszlego wyniku:

• fwd_ret_1s
• fwd_ret_5s
• fwd_ret_30s
• fwd_ret_5m
• max_up
• max_down
• adverse selection
• fill probability proxy
• edge net of fees / funding / slippage

Jakie cechy warto trzymac

Mikrostruktura

• mid
• microprice
• spread_bps
• mark - oracle
• mid - oracle
• basis

Plynnosc i ksiega

• best_bid_size
• best_ask_size
• imbalance
• depth w koszykach 1/2/5/10/20/50 bps
• slope / curvature booka

Aktywnosc i jakosc feedu

• liczba update'ow w bucketcie
• udział indicative vs normalnych snapshotow
• staleness feedu
• luki czasowe

Statystyki krotkoterminowe

• realized vol 5s
• realized vol 30s
• realized vol 5m
• momentum score
• mean reversion score
• spread capture proxy
• slippage dla stalych notionals

Proponowane tabele docelowe

Minimalny zestaw:

• dlob_features_1s
• dlob_features_5s
• dlob_regime_1m
• bot_labels_horizons

Kazda z tych tabel powinna miec:

• event_ts
• source
• market_type
• market_index
• zestaw cech numerycznych
• opcjonalnie meta

To da:

• staly rozmiar rekordu
• tansze trenowanie
• latwiejsze sample / batch / join
• mniej miejsca niz raw JSON

Dlaczego to jest lepsze od trzymania wszystkiego

Bo modele nie potrzebuja pelnego surowego payloadu do kazdego kroku.

Dla modeli wazniejsze sa:

• stabilne, stale-wymiarowe wejscia
• konsekwentne etykiety
• latwe agregowanie po oknach czasu

Raw trzeba trzymac krotko. Feature store i labels trzeba trzymac dlugo.

Rekomendacja na kolejny tydzien

1. Nie wdrazac jeszcze custom ring buffer.
2. Zweryfikowac po 2026-04-16, czy 30-day retencja rzeczywiscie przycina hot_snapshot i all_derived.
3. Przygotowac plan wlaczenia kompresji TimescaleDB dla:
   • dlob_all_derived_ts
   • dlob_hot_snapshot_ts
   • dlob_hot_derived_ts
4. Zaprojektowac schemat dlob_features_1s, dlob_features_5s, dlob_regime_1m, bot_labels_horizons.
5. Uznac raw DLOB za short-term storage, a feature bars + labels za long-term storage pod modele.

Decyzja robocza

Obecny kierunek:

• retencja raw zostaje
• kompresja powinna byc kolejnym krokiem
• dlugoterminowo nie trzymac wszystkiego jako raw snapshots
• dla modeli przejsc na warstwy cech i etykiet o nizszej skali