Розробка системи зберігання знімків order book

Ми — команда Web3-інженерів з 10+ річним досвідом розробки криптоінфраструктури. Нами реалізовано понад 20 проєктів для бірж і трейдингових фірм, включаючи системи зберігання order book з навантаженням до 5000 оновлень за секунду. У криптобіржах order book — одне з найбільш навантажених джерел даних. Трейдери вимагають низьку затримку, а аналітики — повну історію. Неправильне зберігання призводить до величезних витрат на інфраструктуру.

Order book — найбільш інформативні та найскладніші в зберіганні біржові дані. Повний стакан BTC/USDT на Binance містить 5000 рівнів з обох сторін, оновлюється 5–10 разів на секунду і генерує сотні мегабайт даних на годину. При наївному підході (зберігання кожного зрізу) обсяг сягає 100 ГБ на добу тільки для одного символу. Правильна система балансує повноту даних з практичними обмеженнями. Наше рішення використовує комбінацію повних знімків і дельт (diff), що дає стиснення в 50 разів без втрати роздільної здатності.

Який формат зберігання order book обрати?

Перш ніж проєктувати сховище, важливо зрозуміти, які дані реально потрібні. У таблиці нижче — порівняння основних форматів.

На практиці системи зберігають комбінацію: повні знімки для відновлення та дельти для історичної точності.

Формат зберігання: Delta Encoding

Delta encoding — критичний елемент для зменшення обсягів. Замість повного стакана ми зберігаємо лише зміни відносно попереднього стану.

Snapshot @ T=0: bids: [(43250.0, 1.5), (43249.5, 2.0), (43249.0, 0.8)] asks: [(43251.0, 1.2), (43251.5, 3.0), (43252.0, 0.5)] Diff @ T=1 (лише зміни): bids_updated: [(43250.0, 2.1)] # обсяг змінився bids_removed: [(43249.5, 0)] # рівень зник bids_added: [(43248.5, 1.0)] # новий рівень asks_updated: [] asks_removed: [] asks_added: [(43251.75, 0.3)] 

Повний знімок: ~8 KB. Diff: ~200 байт. При 5 оновленнях на секунду та знімку раз на 60 секунд — 300 diffs + 1 snapshot = ~60 KB/хв замість 3 MB/хв. Виграш — 50 разів.

Чому ClickHouse — оптимальний вибір?

Використовуємо ClickHouse з custom serialization. Колонкове зберігання та підтримка масивів кортежів ідеально підходять для структури стакана. ZSTD-стиснення дає додаткове скорочення обсягу. Згідно з документацією ClickHouse, колонкове зберігання та ZSTD можуть стискати числові дані в 2-3 рази ефективніше за LZ4.

CREATE TABLE orderbook_snapshots ( exchange LowCardinality(String), symbol LowCardinality(String), snapshot_time DateTime64(3, 'UTC'), depth UInt16, bids Array(Tuple(Decimal(24,8), Decimal(24,8))), asks Array(Tuple(Decimal(24,8), Decimal(24,8))) ) ENGINE = MergeTree() PARTITION BY (exchange, toYYYYMM(snapshot_time)) ORDER BY (exchange, symbol, snapshot_time); CREATE TABLE orderbook_diffs ( exchange LowCardinality(String), symbol LowCardinality(String), diff_time DateTime64(3, 'UTC'), first_update_id UInt64, last_update_id UInt64, bids_changes Array(Tuple(Decimal(24,8), Decimal(24,8))), asks_changes Array(Tuple(Decimal(24,8), Decimal(24,8))) ) ENGINE = MergeTree() PARTITION BY (exchange, toYYYYMM(diff_time)) ORDER BY (exchange, symbol, diff_time); CREATE TABLE orderbook_metrics ( exchange LowCardinality(String), symbol LowCardinality(String), ts DateTime64(3, 'UTC'), mid_price Decimal(24,8), spread Decimal(24,8), spread_bps Decimal(10,4), bid_1 Decimal(24,8), ask_1 Decimal(24,8), bid_vol_10 Decimal(24,8), ask_vol_10 Decimal(24,8), imbalance Decimal(10,6) ) ENGINE = MergeTree() PARTITION BY (exchange, toYYYYMM(ts)) ORDER BY (exchange, symbol, ts) SETTINGS default_codec = ZSTD(3); 

Відновлення стану стакана

Ключова операція — відновлення стакана на довільний момент часу. Реалізується через послідовне застосування дельт від останнього знімка.

class OrderBookReplay: def __init__(self, storage: OrderBookStorage): self.storage = storage async def reconstruct_at(self, exchange: str, symbol: str, target_ts: int) -> OrderBook: snapshot = await self.storage.get_last_snapshot_before(exchange, symbol, target_ts) if not snapshot: raise ValueError("No snapshot available before target timestamp") diffs = await self.storage.get_diffs(exchange, symbol, from_ts=snapshot.timestamp, to_ts=target_ts) book = OrderBook.from_snapshot(snapshot) for diff in diffs: book.apply_diff(diff) return book class OrderBook: def apply_diff(self, diff: OrderBookDiff): for price, qty in diff.bids_changes: if qty == 0: self.bids.pop(price, None) else: self.bids[price] = qty for price, qty in diff.asks_changes: if qty == 0: self.asks.pop(price, None) else: self.asks[price] = qty 

Важливий порядок застосування дельт та перевірка через update_id — у Binance кожен diff має lastUpdateId, наступний повинен починатися з lastUpdateId+1. Розрив означає пропущені дані.

Стиснення та оптимізація

Перед записом у ClickHouse застосовуємо:

• Delta encoding для цін: зберігаємо різницю від кращого bid/ask у базисних пунктах (bps). Цілі числа стискаються краще.
• Binary serialization: Protocol Buffers або MessagePack замість JSON. Виграш 3–5x за розміром та швидкістю.
• ClickHouse compression: алгоритм ZSTD(3) для даних Decimal і Float — на 20% ефективніший за дефолтний LZ4.

Потоковий запис

Ingestion pipeline працює паралельно: знімки кожні 60 секунд, дельти буферизуються та зберігаються батчами по 100 штук.

class OrderBookIngester: SNAPSHOT_INTERVAL = 60 DIFF_BATCH_SIZE = 100 def __init__(self, storage): self.storage = storage self.diff_buffer = [] self.last_snapshot_time = 0 async def on_orderbook_update(self, book: OrderBook, diff: OrderBookDiff): now = time.time() if now - self.last_snapshot_time >= self.SNAPSHOT_INTERVAL: await self.storage.save_snapshot(book.to_snapshot()) self.last_snapshot_time = now self.diff_buffer.append(diff) if len(self.diff_buffer) >= self.DIFF_BATCH_SIZE: await self.storage.save_diffs(self.diff_buffer) self.diff_buffer.clear() 

Аналітичні запити

Після накопичення даних відкриваються можливості для аналізу. Наприклад, середній спред по годинах або кореляція imbalance з рухом ціни.

-- Середній спред BTC/USDT по годинах за вибраний місяць SELECT toStartOfHour(ts) AS hour, avg(spread_bps) AS avg_spread_bps, avg(imbalance) AS avg_imbalance FROM orderbook_metrics WHERE exchange = 'binance' AND symbol = 'BTC/USDT' AND ts BETWEEN '2024-01-01' AND '2024-02-01' GROUP BY hour ORDER BY hour; -- Кореляція imbalance з наступним рухом ціни WITH book AS ( SELECT ts, imbalance, mid_price FROM orderbook_metrics WHERE exchange = 'binance' AND symbol = 'BTC/USDT' ), future AS ( SELECT b.ts, b.imbalance, (f.mid_price - b.mid_price) / b.mid_price * 10000 AS fwd_return_bps FROM book b ASOF JOIN book f ON b.symbol = f.symbol AND f.ts BETWEEN b.ts + INTERVAL 1 MINUTE AND b.ts + INTERVAL 2 MINUTE ) SELECT round(imbalance, 1) AS imbalance_bucket, avg(fwd_return_bps) AS avg_1min_return_bps, count() AS count FROM future GROUP BY imbalance_bucket ORDER BY imbalance_bucket; 

Моніторинг та якість даних

Критично важливо відстежувати розриви в послідовностях дельт. Система валідації порівнює lastUpdateId кожного diff з firstUpdateId наступного та алертує при прогалинах. Розрив між знімками робить відновлення неможливим.

Метрики для моніторингу: частота запису знімків на символ, затримка від біржового timestamp до запису в ClickHouse, розмір буфера дельт, відсоток пропущених оновлень.

Процес роботи

Орієнтовні строки — від 2 до 4 тижнів залежно від складності. Вартість розраховується індивідуально після ознайомлення із завданням.

Що входить у роботу

• Проектування схеми зберігання під ваше навантаження (частота оновлень, кількість символів, вимоги до затримки).
• Реалізація ingestion pipeline на Python з інтеграцією через WebSocket або REST API.
• Розробка API для доступу до історичних даних (відновлення стакана, вибірка дельт, агрегати).
• Документація з відновлення та аналітичних запитів.
• Навчання команди.
• Підтримка протягом місяця після запуску.

Якщо вас цікавить оптимізація зберігання біржових даних — зверніться до нас для попередньої оцінки. Зв'яжіться з нами для оцінки вашого проекту. Замовте розробку системи зберігання ордербука під ключ — отримайте консультацію з архітектури та строків.