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

Почему order book pipeline теряет данные на пиках

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

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

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

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

Что даёт выстроенный конвейер книги заявок

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

• Воспроизводимость. Любой набор собирается по версии исходных записей и версии правил подготовки признаков. Повторный прогон даёт те же значения метрик, а расхождение между обучением и проверкой перестаёт быть загадкой.
• Качество данных на входе. Проверки ловят пропущенные снимки, дубликаты, разрывы временного ряда и нарушенный порядок уровней. Доля отбракованных сессий видна в отчёте, а не выясняется по аномальным метрикам модели.
• Исторические данные. Снимки книги сохраняются в колоночном формате Parquet с разбиением по датам и инструментам: выборка за нужный период читается минутами, а не часами полного перебора.
• Подготовка признаков. Дисбаланс сторон, спред, интенсивность отмен, скорость восстановления после импульса считаются одним проходом. Ручная подготовка сокращается с дней до минут и перестаёт зависеть от конкретного аналитика.
• Единый формат. Расхождения в единицах, метках времени и точности между площадками нормализуются на входе — класс отказов «данные пришли, но не в том виде» уходит.
• Устойчивость к всплескам. Буферизация и обратное давление удерживают поток на пиках активности: сообщения не теряются, а очередь разбирается после нагрузки.

Способы сбора и хранения котировок: сравнение

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

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

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

Как мы строим конвейер обработки котировок

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

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

На выходе — воспроизводимый order book pipeline: от сырых сообщений до признаков для модели. Любой этап перезапускается и сверяется с эталоном, а качество данных видно по метрикам, а не по ощущениям.

Артефакты: схемы, регламенты и конфигурации

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

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

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

Кейс: восстановление потока котировок после сбоя

Сбои на стороне источника данных и обрывы подписки ломали поток котировок: после переподключения часть обновлений приходила заново, часть не приходила вовсе. Доля потерянных обновлений доходила до 5–7% в сутки, в стакане появлялись дыры в порядковых номерах, а повторная подписка добавляла дубли — на обучение уходила история, которой нельзя доверять.

Что было до

Восстановление после разрыва делали руками: инженер переподнимал сессию, запрашивал полный снимок книги заявок из Databento, сопоставлял его с накопленным потоком и вычищал пересечения. Одна такая операция занимала 30–40 минут, за сутки их набиралось до десяти, а сверка наборов данных расходилась в трёх запусках из десяти. Модель училась на смещённой выборке, и деградация была незаметной: метрики на валидации плавали от прогона к прогону.

Что сделали

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

Что стало

Доля потерянных обновлений — 0,02%, пропуски в порядковых номерах закрываются в том же окне, где обнаружены. Восстановление после разрыва связи занимает 1,5 минуты против 30–40 минут ручной работы, ручных операций в сутки — ноль. Сверка наборов данных перестала расходиться: расхождения ловятся на входе и не доезжают до обучающей выборки, поэтому метрики на валидации стали воспроизводимыми.

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

Чем отличается order book от потока сделок?

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

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

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

Выбор источника — это вопрос горизонта прогноза и типа признаков, а не вкуса. Для части задач нужны оба источника вместе: отдельная сделка без состояния книги не объяснима, а книга без сделок не показывает, кто именно сдвинул цену. Поэтому оба потока синхронизируют по времени, а рассинхрон и пропуски обрабатывают отдельно — иначе признаки на выходе разъедутся.

На входе оба источника пишутся раздельно, с метками времени и идентификаторами инструмента, чтобы признаки можно было пересчитать задним числом на историческом окне.

Технические сомнения перед началом работ

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

Конвейер строится вокруг нормализованной схемы события: инструмент, метка времени, сторона, уровень цены, объём. Любой источник приводится к ней адаптером, поэтому контроль качества, восстановление стакана и витрины для моделей работают одинаково — независимо от того, чьи данные поступают.

Что делать с пропусками в старых данных?

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

Не задвоятся ли данные при повторной обработке?

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

Придётся ли перестраивать действующее хранилище?

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

Что с поддержкой после сдачи?

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

Обсудим вашу задачу обработки котировок

Оценка объёма работ по конвейеру обработки order book зависит не от числа бирж, а от того, как устроены первичные данные и что нужно получить на выходе. Если сразу видеть пример выгрузки и описание целевого признака, мы возвращаемся с разбивкой по этапам и требованиями к данным, а не с диапазоном «от и до».

Что полезно прислать заранее:

• Источники: биржи, инструменты, глубина истории и требуемая частота снимков книги заявок.
• Формат потока: только снимки или снимки плюс дельта-обновления, как помечаются разрывы и повторы последовательностей.
• Требования к данным: схема событий, работа с метками времени, синхронизация, правила восстановления пропущенных интервалов.
• Целевые признаки: дисбаланс сторон, спред, интенсивность отмен, профиль ликвидности — и горизонт, на котором модель должна работать.
• Режим работы: историческое воспроизведение, поток в реальном времени или оба варианта, какая задержка допустима.
• Инфраструктура: где размещаем обработку, какие доступы и объёмы хранилища есть, нужна ли воспроизводимость сборки набора данных.

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