Разработка системы хранения order book snapshots

Мы — команда 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 следующего и алертит при пробелах. Gap между снапшотами делает восстановление невозможным.

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

Процесс работы

Ориентировочные сроки — от 2 до 4 недель в зависимости от сложности. Стоимость рассчитывается индивидуально после ознакомления с задачей.

Что входит в работу

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

Если вас интересует оптимизация хранения биржевых данных — обратитесь к нам за предварительной оценкой. Свяжитесь с нами для оценки вашего проекта. Закажите разработку системы хранения ордербука под ключ — получите консультацию по архитектуре и срокам.