Сбор trades с бирж: где рвётся поток сделок
Сбор trades в постановке звучит как «подключиться к API и писать в базу». На практике это два независимых источника: поток сделок в реальном времени и историческая догрузка за период. Первый даёт низкую задержку, второй — полноту, и расхождения возникают именно на их стыке.
Самый частый сбой — обрыв соединения с биржей. Пока канал восстанавливается, сделки не приходят: у площадок есть окно, в котором поток не буферизуется, поэтому после переподключения историю догружают по идентификаторам сделок, а не по времени. Если догрузка идёт «с запасом» по часам, в базе появляются дубли сделок; если без запаса — пропуски сделок. Контроль по номеру последней принятой записи, как, например, на Binance, закрывает и то, и другое, но требует хранения состояния по каждому потоку.
Рассинхрон витрин проявляется позже и тише. Витрина аналитики, витрина отчётности и кэш оповещений обновляются с разной периодичностью и на одном интервале дают разные объёмы — расхождение с отчётностью площадки всплывает на сверке, когда восстановить пропущенное уже дорого.
Разбираем, как это закрывается: контроль целостности на приёме, постоянная сверка витрин между собой и регулярная проверка против отчётных данных биржи.
Что даёт налаженный приём сделок: полнота, скорость, сверка
Приём сделок выглядит простой задачей: подписка на поток и запись в таблицу. Ломается он на переподключениях — в окно разрыва соединения теряются сделки, а повторная подписка приносит дубликаты и искажает объёмы. Поэтому поток проектируется как восстанавливаемый журнал, а не как «запись того, что успело прилететь».
| Класс сбоя | Что происходит | Как закрываем | Метрика |
|---|---|---|---|
| Разрыв потока | пропуск сделок за окно отключения | догрузка по диапазону времени и идентификаторов | восстановлено > 99,9% сделок |
| Повтор после переподключения | дубли в витрине | вставка по ключу сделки отбрасывает повторы | дублей — ноль |
| Задержка поступления | витрина отстаёт от рынка | буферизация и пакетная запись | до аналитической витрины — секунды |
| Расхождение с отчётом | объём по инструменту не сходится | ежедневная сверка с отчётностью биржи | расхождение локализуется в тот же день |
Сверка с отчётностью идёт отдельным контуром: агрегаты по инструментам и часам сравниваются с выгрузками площадки — открытые данные отдают Binance и другие биржи в сопоставимом виде. Расхождение выше порога автоматически ставит задачу на восстановление пропусков за конкретное окно, а не на полную перекачку истории.
В результате уходит целый класс отказов — «дырка в истории». Ручные догрузки заменяются регламентом, полнота рыночных данных подтверждается цифрами сверки, а не доверием к логу приложения.
Способы сбора trades: потоковые подписки и пакетные выгрузки
Оба режима решают разные задачи, и попытка закрыть одним из них обе почти всегда упирается в лимиты. Потоковая подписка отдаёт сделки по мере появления — её берут для онлайн-мониторинга, расчёта котировок, контроля риска и арбитражных сценариев. Пакетная выгрузка истории нужна там, где важен полный ряд за прошлые периоды: аналитика, проверка стратегий на исторических данных, сверка отчётности с биржевой.
Ограничения у режимов тоже разные. В потоке ключевое — удержать соединение и не потерять события при разрыве: нужен автоматический переподключ и добор с последнего подтверждённого идентификатора сделки. В пакетном режиме всё упирается в лимиты запросов и глубину исторических данных: площадка отдаёт окно назад, дальше — только архивы.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Потоковая подписка на события | Онлайн-мониторинг, расчёт котировок, контроль риска, арбитраж | Работает только «вперёд»; разрывы требуют добора; глубокой истории не отдаёт |
| Постраничная выгрузка по API | Догон пропущенного интервала, точечная выборка по инструменту | Лимиты запросов, пагинация, ограниченное окно хранения на стороне площадки |
| Архивные дампы сделок | Проверка стратегий на длинной истории, аналитика за периоды, аудит | Задержка публикации, свой формат у каждой площадки, объём и распаковка |
На практике режимы комбинируют: архив закрывает прошлое, поток — текущее, а на стыке ставят дедупликацию и проверку непрерывности ряда по идентификатору сделки. Тогда набор данных остаётся полным и без дыр после перезапусков сервиса.
От аудита источников до передачи конвейера сделок
Сбор trades с бирж начинается не с кода, а с разбора источников. Порядок работ фиксирован: аудит площадок, схема конвейера, настройка, проверка на истории, приёмка. Такая последовательность экономит недели — правка на этапе схемы дешевле, чем пересбор уже накопленного архива.
- Аудит источников данных. Разбираем, что отдаёт площадка: поток сделок в реальном времени, архивные выгрузки, программный интерфейс с ограничением частоты запросов. Фиксируем глубину доступной истории, стабильность каналов и правила площадки по дальнейшему использованию этих данных.
- Схема конвейера. Проектируем единую модель сделки: нормализованное имя инструмента, сторона, цена, объём, метка времени в одном часовом поясе, признак источника. Здесь же определяется, как разные написания одного инструмента сводятся к одной записи.
- Настройка сбора и хранения. Подписка на поток плюс загрузка истории, дедупликация, буфер на случай обрыва связи и повторные попытки. Запись в хранилище с разбивкой по датам — выборка за нужный период не требует полного перебора.
- Проверка на исторических данных. Прогоняем конвейер на восстановленном отрезке и сверяем с эталонной выборкой: число сделок, цены, объёмы, доля пропусков и дублей, задержка между сделкой и её появлением у нас.
- Контроль и приёмка решения. Настраиваем метрики и оповещения об остановке потока, росте задержки и расхождении объёмов. Приёмка идёт по согласованным сценариям: доступы, схема хранения, регламент перезапуска.
- Передача и обучение. Показываем команде, как подключить новую площадку или инструмент, как читать метрики и что проверять при обрыве потока.
Комплект передачи: конфигурации, схемы, регламенты
Сдаём не «доступ к серверу и контакты инженера», а комплект, по которому ваша команда сможет поднять сбор заново или принять его на сопровождение без нас. Ниже — что именно остаётся у заказчика и зачем каждый элемент нужен в работе.
- Матрица источников. По каждой бирже: какие пары и каналы включены, потоковая подписка или периодический опрос, глубина исторической загрузки, лимиты частоты запросов и запас до них.
- Схема потоков данных. Путь сделки от подписки до записи: где нормализация, где буфер на случай обрыва связи, где точка отказа и как запускается повторная выгрузка пропущенного интервала.
- Модель данных. Словарь полей сделки — идентификатор, время биржи и время приёма, цена, объём, сторона — плюс правила дедупликации и идемпотентной записи, чтобы повторный проход не удваивал объёмы.
- Разграничение доступа к данным. Роли сервисов и людей, отдельные учётные записи на чтение и запись, ключи бирж в хранилище секретов, журнал обращений к архиву сделок.
- Конфигурации контуров. Описания стенда и промышленного окружения, повторы при сбоях, отсечки по объёму и правила хранения «горячих» и архивных данных.
- Документация решения. Карта сервисов и зависимостей, порядок действий при типовых отказах, восстановление из архива, контактные точки эскалации.
- Регламент сопровождения. Что проверяется ежедневно — лаг приёма, пропуски интервалов, расхождения объёмов с эталонной выборкой — кто реагирует, в какие сроки и когда переключаются на резервный источник.
- Приёмочные материалы. Контрольные суммы за эталонный период, сверка выборки с выгрузкой биржи и протокол проверки, по которому можно повторить приёмку.
Комплект передаём вместе с разбором: проходим по схеме потоков и регламенту с вашими инженерами, отвечаем на вопросы по конфигурациям. Опишите задачу — вернёмся с оценкой и планом передачи.
Кейс: убрали пропуски сделок и рассинхрон витрин
Сбор сделок (trades) на Kraken шёл потоковым каналом, и каждый разрыв соединения оставлял дыру в истории: после переподключения подтягивались только свежие записи, а середина интервала исчезала. Витрины расходились с площадкой на десятки минут, объёмы и количество сделок в отчётах не бились, и дежурный инженер вручную догружал пропущенные интервалы по выгрузкам.
Мы перестроили контур сбора: поток пишется в буфер с сохранением порядка, каждая сделка получает идентификатор биржи и метку времени площадки, а запись делается идемпотентно — повторная доставка не создаёт дублей. Параллельно идёт сверка с историческими срезами площадки по интервалам, и расхождение автоматически ставит интервал в очередь на повторный добор.
Метрики до и после
- Доля потерянных сделок: 0,3–0,5% записей → ноль расхождений на контрольных сверках.
- Время сходимости витрин с площадкой: 40–60 минут → 2–3 минуты.
- Доля ручных догрузок: 12–15% интервалов → менее 1%, и только по инициативе аналитика.
- Сходимость по количеству и объёму сделок: расхождение в пределах 0,01% на суточном окне.
Дальше контур живёт в режиме сопровождения: контрольные сверки по расписанию, оповещение при выходе отклонения за порог, обновление разборщиков при изменении формата ответов площадки. Заказчик получает историю сделок, на которую можно опираться в расчётах, без ручных догрузок и «доверия на глаз».
Что делать, если своя выгрузка уже работает, но данные расходятся?
Расхождение почти никогда не в самом сборе, а в том, что считается источником истины. Своя выгрузка данных писалась под одну задачу — отчёт, сигнал, проверку торговой идеи — и незаметно накопила допущения: локальное время вместо биржевого, округление объёма, отбрасывание частично исполненных заявок. Пока потребитель один, это не видно; как только их становится два, цифры перестают сходиться, и спор идёт не о данных, а о том, чей расчёт верный.
Аудит текущего решения начинается со сверки, а не с чтения кода. Берём эталонный интервал, сопоставляем записи по ключу «символ + время сделки + идентификатор» и разбираем, где строки лишние, где пропущены, где смещены по времени. Затем смотрим журналы: разрывы соединения, повторы после переподключения, отсутствие дедупликации на границе окна. На практике две-три такие причины объясняют основную долю расхождений.
Дальше — параллельный запуск. Новый контур пишет в отдельную схему и ничего не меняет в работающем процессе: оба потока идут одновременно, ежедневно сверяются, а расхождения раскладываются по категориям — потеря окна, дубль, разная нормализация. Пока доля расхождений не сойдёт к нулю на нескольких полных торговых днях, переключать потребителей смысла нет.
Поэтапная замена идёт от краёв к центру: сначала на новый контур переводятся второстепенные читатели — отчёты, аналитика, — потом основные. Старая выгрузка остаётся доступной только на чтение как страховка и отключается после того, как новый контур отработал спорные ситуации: делистинг пары, дробление символа, рестарт биржевого движка. Сбор trades при этом не останавливается ни на день, а каждое расхождение закрывается подтверждением, а не на глаз.
Технические сомнения: задержки, дубли, лимиты запросов
Три вещи ломают сбор сделок с биржи: обрыв соединения, дубли при переподключении и лимиты на число обращений к площадке. Все три закрываются на уровне приёма данных, а не постфактум при разборе отчёта — иначе в витрине остаются дыры, о которых узнают через неделю.
Приём строится двумя каналами: потоковый отдаёт сделки в реальном времени, периодический опрос добирает пропущенное за окно. Каждая запись получает составной ключ — площадка, инструмент, идентификатор сделки — и попадает в хранилище строго один раз. Повторная выдача сделок после переподключения не создаёт дублей, а расхождение между каналами закрывает сверка.
Что происходит при обрыве связи?
Соединение поднимается автоматически с нарастающей паузой, чтобы не бить по площадке. После восстановления сбор идёт не с текущего момента, а с последней обработанной позиции — пропущенный интервал догоняется историческими данными, а расхождение между потоком и историей сверяется по объёму и времени сделок.
Как вы держитесь в лимитах запросов биржи?
На каждое направление считаем вес обращения и ограничиваем частоту квотами, живой поток всегда приоритетнее добора истории. При ответе об ограничении сбор уходит в паузу и продолжает с той же позиции, а не перезапускается — данные не теряются и не дублируются.
Как вы понимаете, что данные точные?
Работает детектор разрывов: он помечает интервалы, где поток молчал дольше обычного, и запускает сверку с независимым источником. На выходе — измеримые показатели: доля пропущенных сделок, задержка между сделкой и записью, доля отсечённых дублей.
Обсудим задачу: источники, объёмы, режим поступления
Чтобы вернуться с оценкой проекта и планом работ по этапам, нужны вводные — не в формате «нужны сделки с бирж», а достаточные, чтобы посчитать нагрузку на приём, хранение и обработку. Ниже чек-лист: чем точнее ответите по пунктам, тем меньше допущений заложим в расчёт и тем меньше расхождений всплывёт на приёмке.
- какие площадки в приоритете: централизованные биржи, децентрализованные пулы или оба класса сразу;
- какие инструменты и пары нужны: спотовые, срочные, стейблкоиновые;
- глубина истории: разовая загрузка архива за период или непрерывный приём с текущего момента;
- режим поступления данных: поток в реальном времени, периодические выгрузки или смешанный сценарий;
- ожидаемый объём: сколько пар и событий в сутки, какие часы дают пик нагрузки;
- поля сделки: время, цена, объём, направление агрессора, идентификаторы, комиссия;
- как планируете забирать данные: база, файловые выгрузки, программный интерфейс, готовые отчёты;
- требования к качеству: дедупликация, обработка пропусков, сверка с историей биржи, хранение сырых ответов.
Если часть вводных пока открыта — это нормально: сформулируем допущения и вынесем их отдельным блоком, чтобы они обсуждались на проектировании, а не всплывали при запуске.
После разбора состава источников присылаем схему сбора, требования к хранилищу и план работ по этапам с указанием, что именно делается на каждом шаге. Опишите задачу — вернёмся с оценкой и планом.
