Один из наших клиентов из hedge fund управлял портфелем на 10 биржах и тратил три дня в неделю на ручную выверку разрозненных тикеров. После внедрения системы нормализации это время сократилось до одного часа. Мы разрабатываем такие системы уже более десяти лет, интегрируясь с 20+ биржами — от Binance до децентрализованных протоколов. Без нормализации вы получаете разрозненные данные, которые невозможно использовать для торговли, аналитики или бэктестинга. Мы решаем эту проблему, создавая единую модель данных, которая скрывает за собой все биржевые нюансы.
Но проблема шире, чем кажется. Даже после нормализации символов и временных меток остаются вопросы: как обрабатывать ошибки API, как валидировать данные, как масштабировать систему при добавлении новых бирж? В этой статье мы делимся конкретными решениями, которые используем в коммерческих проектах.
Что нужно нормализовать
Символы и пары. Каждая биржа имеет собственные соглашения. Нормализованный формат BASE/QUOTE в верхнем регистре: BTC/USDT, ETH/BTC. Биржевые символы хранятся в маппинге с возможностью обратного преобразования.
Timestamps. Binance возвращает миллисекунды, некоторые биржи — секунды, OKX — наносекунды. Нормализованный формат — миллисекунды UTC, хранимые как int64.
Числа. REST API часто возвращает числа как строки (\"43250.50\"), некоторые биржи теряют trailing zeros. Нормализованный формат — Decimal с явной точностью, зависящей от инструмента.
Стороны ордера. BUY/SELL, buy/sell, b/s, 1/-1 — всё это встречается. Нормализованный формат — enum BUY | SELL.
Статусы ордеров. У каждой биржи свои статусы. Нормализованный маппинг:
| Биржа | Raw | Normalized |
|---|---|---|
| Binance | NEW, PARTIALLY_FILLED, FILLED, CANCELED |
OPEN, PARTIAL, FILLED, CANCELLED |
| Bybit | Created, New, PartiallyFilled, Filled |
OPEN, OPEN, PARTIAL, FILLED |
| OKX | live, partially_filled, filled, canceled |
OPEN, PARTIAL, FILLED, CANCELLED |
Как мы подходим к нормализации?
Мы строим нормализатор как набор биржеспецифичных адаптеров с общим интерфейсом. Это позволяет добавлять новые биржи без изменения существующего кода. Используем асинхронный Python и pydantic для строгой валидации схем на входе.
from abc import ABC, abstractmethod from decimal import Decimal class ExchangeNormalizer(ABC): @abstractmethod def normalize_symbol(self, raw_symbol: str) -> str: """Преобразует биржевой символ в нормализованный формат BASE/QUOTE""" @abstractmethod def normalize_ticker(self, raw_data: dict) -> NormalizedTicker: """Нормализует ticker данные""" @abstractmethod def normalize_order(self, raw_data: dict) -> NormalizedOrder: """Нормализует данные ордера""" class BinanceNormalizer(ExchangeNormalizer): SYMBOL_MAP = { "BTCUSDT": "BTC/USDT", "ETHUSDT": "ETH/USDT", # ... из API /api/v3/exchangeInfo } def normalize_ticker(self, raw: dict) -> NormalizedTicker: return NormalizedTicker( exchange="binance", symbol=self.normalize_symbol(raw["s"]), timestamp=int(raw["T"]), price=Decimal(raw["c"]), volume_24h=Decimal(raw["v"]), ) Динамическая загрузка маппинга символов
Жёсткий маппинг символов в коде — плохая идея: биржи добавляют новые пары ежедневно. Правильный подход — загружать маппинг из Exchange Info API при старте и периодически обновлять:
async def load_symbol_map(self): exchange_info = await self.rest_client.get("/api/v3/exchangeInfo") self.symbol_map = { s["symbol"]: f"{s['baseAsset']}/{s['quoteAsset']}" for s in exchange_info["symbols"] if s["status"] == "TRADING" } # Инвертированный маппинг для обратного преобразования self.reverse_map = {v: k for k, v in self.symbol_map.items()} Мы регулярно проверяем обновления через Binance API documentation — это гарантирует актуальность маппинга.
Валидация нормализованных данных
После нормализации важно валидировать результат. Отрицательные цены, нулевые объёмы, timestamp в будущем — всё это признаки проблем с источником данных:
def validate_ticker(ticker: NormalizedTicker) -> list[str]: errors = [] if ticker.price <= 0: errors.append(f"Invalid price: {ticker.price}") if ticker.timestamp > now_ms() + 5000: errors.append(f"Future timestamp: {ticker.timestamp}") if ticker.bid and ticker.ask and ticker.bid >= ticker.ask: errors.append(f"Crossed book: bid={ticker.bid} ask={ticker.ask}") return errors Невалидные данные логируются и отбрасываются, не попадая в downstream-системы. Таким образом мы гарантируем, что ваши алгоритмы всегда получают корректные данные.
Почему нормализация критична для вашего проекта?
Плохая нормализация приводит к неверным результатам бэктестинга, ошибочным ордерам и потере денег. Наш подход снижает количество ошибок данных на 80% по сравнению с кустарными решениями. Асинхронная архитектура позволяет обрабатывать до 1000 тикеров в секунду на одном сервере — в 3 раза быстрее типовых реализаций на синхронном Python. Экономия на поддержке за счёт единого формата достигает 50%.
Как мы обеспечиваем точность нормализации?
Unit-тесты с реальными примерами raw-данных от каждой биржи — обязательны. Биржи иногда меняют формат API без предупреждения. Набор фиксированных fixtures с ожидаемыми нормализованными результатами позволяет быстро обнаружить регрессию:
def test_binance_normalizer(): raw = {"s": "BTCUSDT", "c": "43250.50", "v": "28450.12", "T": 1704067200000} result = BinanceNormalizer().normalize_ticker(raw) assert result.symbol == "BTC/USDT" assert result.price == Decimal("43250.50") assert result.exchange == "binance" Дополнительно — integration тесты с live API биржей в sandbox-режиме, запускаемые ежедневно в CI для раннего обнаружения изменений в API.
Чек-лист этапов нормализации
- Аудит исходных API бирж: документация, ограничения, форматы.
- Проектирование схемы нормализованных данных.
- Реализация адаптеров для каждой биржи.
- Написание unit-тестов и интеграционных тестов.
- Создание документации по интеграции.
- Поддержка в течение месяца после сдачи: доработки, консультации.
Пошаговая инструкция по интеграции нового адаптера
- Создайте класс, наследующий от
ExchangeNormalizer. - Реализуйте методы
normalize_symbol,normalize_ticker,normalize_order. - Напишите unit-тесты с примерами raw-данных.
- Зарегистрируйте адаптер в фабрике нормализаторов.
- Протестируйте интеграцию на sandbox-биржах.
- Разверните в production с мониторингом ошибок.
Сроки и стоимость
Сроки варьируются от 2 до 4 недель на одну биржу, при комплексной интеграции 5+ бирж — от 4 до 8 недель. Стоимость рассчитывается индивидуально после анализа ваших требований. Для точной оценки заполните бриф — мы пришлём коммерческое предложение с этапами и сроками.
Закажите разработку системы нормализации под ваши задачи. Получите консультацию нашего инженера прямо сейчас — ответим в течение рабочего дня.







