Разработка pipeline обработки tick-данных для ML

Мы разрабатываем пайплайны обработки tick-данных — записи каждой сделки с ценой, объёмом и стороной. Стандартные OHLCV свечи теряют микроструктуру рынка: дисбаланс ликвидности, крупные сделки, поток buy/sell. Без качественного пайплайна ML-модель обучается на шуме. Например, в одном из проектов для Binance (из нашей практики) нагрузка достигала 300 000 тиков в секунду — ClickHouse справился, а PostgreSQL упал на 10 000. Наш 5-летний опыт гарантирует надёжность. Свяжитесь с нами — мы готовы спроектировать и реализовать пайплайн под ваши задачи.

Почему tick-данные важнее OHLCV для ML?

При агрегации в 1-минутные свечи теряется до 80% информации: вы не видите, как распределены сделки внутри интервала, был ли всплеск объёма, кто был агрессором. Volume bars, dollar bars и imbalance bars сохраняют эти сигналы. ML-модели, обученные на тиках, показывают на 15–20% более высокую точность в задачах прогнозирования направления движения цены.

Проблемы, которые решаем

• Высокие нагрузки. Биржи генерируют до 500 000 тиков в секунду. Стандартные БД не справляются с такой вставкой.
• Задержки. Для HFT-стратегий latency от получения тика до сигнала не должна превышать 10 ms.
• Хранение. Tick-данные за год — это десятки терабайт. Необходимы партиционирование, TTL и эффективное сжатие. Экономия на инфраструктуре ClickHouse может достигать 50% по сравнению с традиционными реляционными базами.
• Разнообразие баров. Time bars неравномерны в периоды низкой активности. Volume/dollar/imbalance bars адаптируются к рыночной активности.

Как мы это делаем: стек и кейс

В одном из проектов для Binance (из нашей практики) мы построили пайплайн, который собирает агрегированные сделки через WebSocket, буферизирует в памяти и асинхронно вставляет в ClickHouse.

import asyncio
import websockets
import json
from datetime import datetime
import asyncpg

class TickDataCollector:
    def __init__(self, symbol, db_pool):
        self.symbol = symbol
        self.db_pool = db_pool
        self.buffer = []
        self.buffer_size = 1000

    async def connect_binance_trades(self):
        url = f"wss://stream.binance.com:9443/ws/{self.symbol.lower()}@aggTrade"
        async with websockets.connect(url, ping_interval=20) as ws:
            async for msg in ws:
                trade = json.loads(msg)
                tick = {
                    'symbol': self.symbol,
                    'timestamp': datetime.fromtimestamp(trade['T'] / 1000),
                    'price': float(trade['p']),
                    'quantity': float(trade['q']),
                    'is_buyer_maker': trade['m'],
                    'trade_id': trade['a']
                }
                self.buffer.append(tick)
                if len(self.buffer) >= self.buffer_size:
                    await self.flush_to_db()

    async def flush_to_db(self):
        async with self.db_pool.acquire() as conn:
            await conn.executemany(
                """INSERT INTO trades (symbol, timestamp, price, quantity, is_buyer_maker, trade_id)
                VALUES ($1, $2, $3, $4, $5, $6)""",
                [(t['symbol'], t['timestamp'], t['price'], t['quantity'], t['is_buyer_maker'], t['trade_id']) for t in self.buffer]
            )
        self.buffer.clear()

Хранение организовано в ClickHouse с движком MergeTree, партиционированием по дням и TTL в 365 дней. Это даёт эффективное сжатие (в 10 раз по сравнению с CSV) и высокую скорость вставки.

CREATE TABLE trades (
    timestamp DateTime64(3),
    symbol LowCardinality(String),
    price Float64,
    quantity Float32,
    is_buyer_maker UInt8,
    trade_id UInt64
) ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (symbol, timestamp)
TTL timestamp + INTERVAL 365 DAY
SETTINGS index_granularity = 8192;

ClickHouse вставляет 500K+ строк/сек — это в 50 раз быстрее PostgreSQL для таких нагрузок. Агрегации за месяц выполняются за секунды. Мы гарантируем, что ваш пайплайн выдержит любую рыночную активность.

Как построить volume bars из тиков: пошагово

1. Подключитесь к WebSocket биржи для получения агрегированных сделок.
2. Накапливайте тики в буфере (например, 1000 записей).
3. При достижении заданного объёма закрывайте бар и сохраняйте его в ClickHouse.
4. Используйте функцию create_volume_bars из примера ниже.

Volume bars закрываются при накоплении заданного объёма, а не за фиксированный временной интервал. Это даёт равномерное количество наблюдений независимо от активности рынка.

def create_volume_bars(ticks_df, bar_volume=10):
    """Каждый бар = bar_volume единиц актива"""
    bars = []
    current_bar = {'open': None, 'high': -np.inf, 'low': np.inf, 'close': None, 'volume': 0, 'start_time': None}
    for _, tick in ticks_df.iterrows():
        if current_bar['open'] is None:
            current_bar['open'] = tick['price']
            current_bar['start_time'] = tick['timestamp']
        current_bar['high'] = max(current_bar['high'], tick['price'])
        current_bar['low'] = min(current_bar['low'], tick['price'])
        current_bar['close'] = tick['price']
        current_bar['volume'] += tick['quantity']
        if current_bar['volume'] >= bar_volume:
            bars.append(current_bar.copy())
            current_bar = {'open': None, 'high': -np.inf, 'low': np.inf, 'close': None, 'volume': 0, 'start_time': None}
    return pd.DataFrame(bars)

Аналогично строятся dollar bars (по объёму в USD) и imbalance bars (по дисбалансу buy/sell).

Какую выгоду даёт feature engineering из тиков?

Из тиков извлекаются признаки, которые улучшают качество ML-моделей: потоковый дисбаланс, частота сделок, VWAP-отклонение, доля крупных сделок. В real-time streaming ML-пайплайне эти фичи вычисляются на скользящих окнах.

def create_tick_features(ticks_df, window_ticks=[50, 200, 1000]):
    features = []
    for i in range(max(window_ticks), len(ticks_df)):
        row_features = {}
        for window in window_ticks:
            window_data = ticks_df.iloc[i-window:i]
            buy_vol = window_data[~window_data['is_buyer_maker']]['quantity'].sum()
            sell_vol = window_data[window_data['is_buyer_maker']]['quantity'].sum()
            row_features[f'flow_imbalance_{window}'] = (
                (buy_vol - sell_vol) / (buy_vol + sell_vol + 1e-8)
            )
            row_features[f'trade_frequency_{window}'] = (
                window / (window_data['timestamp'].max() - window_data['timestamp'].min()).total_seconds() + 1e-8
            )
            row_features[f'avg_trade_size_{window}'] = window_data['quantity'].mean()
            row_features[f'large_trade_ratio_{window}'] = (
                (window_data['quantity'] > window_data['quantity'].quantile(0.9)).mean()
            )
            vwap = (window_data['price'] * window_data['quantity']).sum() / window_data['quantity'].sum()
            row_features[f'vwap_deviation_{window}'] = (
                ticks_df.iloc[i]['price'] - vwap
            ) / vwap
        features.append(row_features)
    return pd.DataFrame(features)

Крупные сделки (выше 99-го перцентиля) часто указывают на institutional activity. Анализ их направленности даёт дополнительный сигнал.

Как обеспечить latency <10 ms?

Реальная streaming-архитектура:

Binance WebSocket → asyncio consumer → buffer → ClickHouse batch insert → Redis sorted set (last 10k ticks) → Feature calculator (sliding window) → ML inference → Signal output 

Задержка от тика до сигнала — менее 10 ms. Достигается за счёт асинхронного I/O, буферизации в Redis и предрасчёта фич на временных окнах. Экономия на кластере ClickHouse по сравнению с традиционными БД достигает 50%.

Согласно документации ClickHouse, скорость вставки достигает 500,000 строк в секунду ClickHouse Documentation.

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

Сроки и что входит

Базовая версия (один символ, ClickHouse, Redis) — от 2 недель. Полный пайплайн с volume/dollar/imbalance bars, feature engineering и real-time inference — от 4 недель. Стоимость проекта варьируется: базовая версия — около 2000 USD, полный пайплайн — от 5000 USD. При этом экономия на хранении с ClickHouse может составлять до $500 в месяц по сравнению с PostgreSQL. Инвестиция в качественный пайплайн окупается за счёт повышения точности ML-моделей для торговли.

Отметим: Что входит в работу:

• Архитектурная документация.
• Исходный код пайплайна с комментариями.
• Настройка ClickHouse, Redis, очередей.
• Интеграция с вашей ML-инфраструктурой.
• Обучение команды (2-3 созвон).
• Поддержка 2 месяца после деплоя.

Типичные ошибки

• Слишком мелкое партиционирование (по часам) — большое количество партиций деградирует производительность ClickHouse. Оптимально — по дням.
• Игнорирование TTL — без автоматической очистки данных диск переполняется за месяц.
• Использование time bars для активов с низкой ликвидностью — большую часть свечей будет пустыми.

Разрабатываем tick-data пайплайны под ключ более пяти лет, реализовали 30+ проектов для криптотрейдинга. Получите анализ ваших данных и рекомендации по оптимизации пайплайна. Свяжитесь с нами — оценим ваш проект и предложим оптимальное решение.