Разработка системы граббинга order book в реальном времени

Почему граббинг order book scraping срывается на пиковых нагрузках

Пиковые нагрузки в order book scraping — это момент, когда биржа отдаёт в разы больше сообщений, чем в спокойном рынке: стакан на десяток уровней превращается в сотни обновлений в секунду. Сбор стакана заявок в реальном времени перестаёт укладываться в бюджет по задержке — обработчик не успевает применять изменения, очередь растёт, и данные приходят уже неактуальными.

Первое, что ломается, — соединение. На волатильности поток растёт, буферы переполняются, и разрыв приходится на самый нужный момент. После переподключения поток продолжают «как есть», без сверки снапшота и номера последовательности, — и в локальной книге остаются уровни, которых на бирже уже нет.

Второе — глубина. Многие источники отдают только верхние уровни, поэтому на резком движении нужной глубины просто нет, а агрегированные срезы не дают восстановить её задним числом. Третий сбой — рассинхрон между источниками: разные метки времени, разный порядок применения изменений, и арбитражные сигналы считаются по двум несовпадающим состояниям книги.

Поэтому граббинг ордербука — это в первую очередь про корректность состояния, а не про скорость чтения: сверка снапшота, буферизация обновлений на время реконнекта, контроль отставания и явная фиксация потерь. Разбираем, как это закрывается.

Непрерывный сбор рыночных данных: скорость и полнота картины

Сбор стакана заявок (order book) — это непрерывный поток, а не разовый запрос: десятки обновлений в секунду по каждой паре, и один пропущенный пакет делает дальнейшую картину неверной. Хуже всего, что потеря обнаруживается не в момент сбоя, а при разборе истории, когда данные уже лежат в хранилище с дырой.

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

Устойчивость сбора держится на автоматическом переподключении, догрузке пропущенного окна из среза и дедупликации повторов при обрыве связи. Так уходит целый класс отказов — тихая потеря обновлений, когда система формально работает, но отдаёт данные, уже не соответствующие рынку.

Задержку доставки мы измеряем на всём пути — от события на бирже до записи и до подписчика. Буферизация и пакетная запись сокращают время реакции на рыночное событие до долей секунды, а заполненность минутных интервалов в истории доходит до 100% вместо прежних 70–80%. Непрерывный сбор здесь не самоцель: на полноте данных держатся стратегии, риск-контроль и отчётность.

Сравнение подходов к сбору котировок: что выбрать под задачу

Сбор котировок из книги заявок укладывается в три режима: потоковая подписка, опрос по расписанию и их комбинация. Выбор определяет не «продвинутость» канала, а требования к полноте данных, допустимой задержке и стоимости поддержки.

Потоковый сбор даёт полную картину событий, но любой разрыв связи оставляет «дыру» в истории — её закрывают повторной выгрузкой снимка и подтягиванием изменений за пропущенный интервал. Опрос по расписанию проще и надёжнее в поддержке, зато теряет микроструктуру: всплески ликвидности между тактами просто не попадают в накопленные данные.

Гибридная схема берёт снимок опросом и дальше ведёт поток, а при обрыве восстанавливается по опорной точке. Мы прогоняем режимы на реальном потоке заказчика — считаем долю пропущенных изменений и время восстановления после разрыва, и только потом фиксируем схему.

Этапы внедрения системы сбора и нормализации данных

Сбор стакана заявок (order book scraping) ломается не на старте, а через недели работы — когда площадка меняет формат, рвётся соединение или расходится нумерация обновлений. Поэтому внедрение идёт последовательностью этапов, и каждый закрывается проверяемым артефактом: без него следующий шаг не имеет смысла.

1. Аудит источников. По каждой площадке фиксируем состав полей, глубину стакана, частоту обновлений, лимиты подключений и правила переподключения. На выходе — таблица источников с приоритетами и оговорками.
2. Схема потоков. Размечаем слои: сырые сообщения, нормализованные записи, хранилище истории. Сырьё держим отдельно, чтобы переиграть обработку без повторного сбора.
3. Настройка сбора. Коннекторы с автовосстановлением после разрыва: снапшот плюс проигрывание дельт от последнего подтверждённого номера, контроль лага и синхронизация часов.
4. Нормализация. Единая схема — инструмент, сторона, уровень, объём, точность цены, время в UTC. Расхождения в тикерах и форматах чисел закрываем словарём соответствий.
5. Проверка полноты данных. Сверяем поток с контрольным срезом, ищем пропущенные последовательности и разрывы. Доля восстановленных разрывов и время реакции уходят в мониторинг.
6. Передача в эксплуатацию. Регламенты перезапуска, дашборды, алерты на пропуски и рост лага, доступы, разбор типовых сбоев — с гарантийным периодом сопровождения.

Что передаём в эксплуатацию: конфигурации, схемы, регламенты

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

Артефакты закрываем на приёмке: ваш инженер разворачивает сбор на своём контуре, подключает новый источник и восстанавливает данные после разрыва без нашей помощи. Ниже — что именно уходит в комплект.

• Конфигурации источников — биржи и каналы, лимиты по частоте запросов, схемы авторизации, приоритеты при обрывах; новый источник добавляется правкой одного файла.
• Схемы потоков — топология подписок, буферизация на пиках нагрузки, порядок повторного подключения и сборки снапшота с последующими обновлениями.
• Правила доступа — роли, разделение ключей, ротация, журнал обращений; исторические архивы изолированы от боевого контура.
• Словарь данных — единые имена полей, привязка тикеров к инструментам, правила дедупликации и обработки неполных снапшотов.
• Документация — формат сообщений, порядок разбора сбоев, типовые сценарии диагностики, перечень метрик здоровья потока.
• Регламенты сопровождения — целевые времена восстановления после разрыва, порядок подключения и отключения источников, политика хранения архивов.

Кейс: как сбор стакана перестал терять данные на пиках

Заказчик — команда маркет-мейкера, которая выставляет котировки на нескольких площадках, включая Bybit. Сбор стакана заявок (order book) вели четыре независимых скрипта: каждый писал в свой файл, запускался вручную и ничего не знал о соседях. На спокойном рынке данные сходились, но в моменты резких движений потоки разъезжались, и часть событий пропадала бесследно.

Что было до

Пропущенный фрагмент ломал не только график: он искажал расчёт спреда и перекосов, на которых строились торговые решения, а замечали это уже постфактум. Сверить потери было не с чем — полного слепка книги за момент сбоя не сохранялось. Разбор каждого случая занимал часы ручной работы и всё равно не давал уверенности, что потерян ровно один участок, а не три подряд.

Что изменили и что получили

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

Чем потоковый сбор order book отличается от периодического опроса?

Периодический опрос берёт снимок стакана по расписанию: клиент запрашивает глубину с заданным шагом, получает срез и на этом всё. Между двумя запросами жизнь стакана не видна — заявка, поставленная и снятая внутри окна, в данных не остаётся. Чем реже опрос, тем дешевле сбор и тем сильнее выборка расходится с реальным потоком событий.

Потоковый сбор держит постоянный канал и принимает каждое изменение: приходит начальный снапшот, дальше — только дельты с порядковыми номерами. Номера дают сквозную проверку: разрыв последовательности означает потерю данных, соединение пересобирается, снапшот запрашивается заново. Так получается восстановимый стакан, пригодный для расчёта микроструктуры, а не только средних уровней.

Режимы по-разному упираются в инфраструктуру. Опрос ограничен лимитами площадок на частоту обращений — у публичных источников вроде Coinbase они привязаны к ключу и адресу, поэтому сбор по сотням инструментов требует шардирования запросов. Поток дешевле по числу соединений, но дороже по обработке: нужен слой, который переживает обрывы и не теряет дельты.

Выбор режима определяется задачей: там, где важен порядок событий и время жизни заявки, работает только поток, а регулярные срезы ликвидности закрывает опрос. Поэтому мы чаще собираем гибрид и описываем, как он разворачивается под ваш набор инструментов.

Технические сомнения: разрывы, дубли, лимиты источников

Поток ордербука — снапшот стакана плюс дельты с номерами последовательности. Стоит соединению разорваться, и часть изменений теряется: локальная книга расходится с источником, а торговые сигналы начинают опираться на несуществующую ликвидность. Поэтому сборщик строится вокруг сверки последовательностей и контрольных точек, а не вокруг простой подписки.

Ниже — ответы на инженерные возражения, которые всплывают на этапе оценки архитектуры.

Как исключаете дубли записей?

Ключ идемпотентности — источник, инструмент и номер изменения. Запись идёт как вставка с обновлением по уникальному индексу, поэтому повторная доставка после переподключения не создаёт вторых строк. Для сделок тот же приём работает по идентификатору сделки.

Источник ограничивает число запросов — что тогда?

Ограничения закладываются заранее: запросы идут через очередь с бюджетом на интервал, при отказах включается адаптивная пауза между повторами, инструменты делятся на приоритетные и фоновые. Исторические выгрузки выносим в отдельное окно, чтобы они не конкурировали с потоком в реальном времени.

Как понять, что данные не разошлись?

Следим за лагом до источника, долей пересборок книги, числом пропущенных последовательностей и скоростью наполнения очереди. Порог по любой метрике поднимает оповещение раньше, чем расхождение дойдёт до торговой логики.

Обсудим задачу и вернёмся с оценкой и планом работ

Чтобы вернуться с оценкой сроков и рабочим планом, а не с общими соображениями, нам нужен минимум вводных по задаче. Сбор стакана в реальном времени держится на деталях: набор площадок, глубина истории, требования к задержке и правила восстановления после разрывов. Ниже — что стоит подготовить до старта работ.

• Площадки и инструменты. Какие биржи и пары нужны, что важнее по приоритету — от этого зависит число параллельных потоков и объём хранения.
• Глубина и состав данных. Только лучшие цены или заданное число уровней, нужны ли снимки стакана целиком и последующие изменения, сделки и метки времени события.
• Требования к задержке. От появления изменения в стакане до записи в ваше хранилище — и допустимая доля пропущенных обновлений.
• Доступы. Публичные каналы или приватные ключи с ограниченными правами, ограничения площадок по частоте обращений и числу соединений.
• Куда отдавать данные. Поток в вашу шину, запись в базу, файлы, витрина для аналитики; нужен ли пересчёт истории и сверка с биржевыми данными.
• Инфраструктура. Свои серверы или облако, регионы размещения, запас по каналу связи и диску под историю.
• Отказы и наблюдение. Что делаем при разрыве соединения, как ловим рассинхрон стакана, кому уходит сигнал и кто реагирует.

Опишите задачу в свободной форме — вернёмся с оценкой сроков, планом работ и схемой сбора, где отмечены точки контроля, порядок восстановления и состав отчётности.