Wunderfund HFT: market data quality и latency

Нужно проверить временной интервал, задержку local - exchange, дубли primary/secondary, пропуски, нулевые/невозможные цены, out-of-order события и периоды, где один feed деградирует.

Сначала фиксируем схему: exchange timestamp - время события на бирже, local timestamp - время получения на нашей стороне, feed - primary или secondary. Основная derived-фича - latency = local - exchange. Она не должна быть отрицательной и должна иметь ожидаемое распределение по каждому feed.

Дальше идут проверки полноты: за какой период данные, нет ли дыр во времени, сколько событий в минуту, есть ли дубликаты одного биржевого события в primary и secondary, совпадают ли price и exchange timestamp у парных событий. Для HFT важно не просто "есть строки", а корректный порядок и задержки.

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

Нужно сопоставить одно и то же биржевое событие между feeds и сравнить local timestamps. Просто сравнивать среднюю latency по всем строкам можно, но лучше делать paired comparison.

Правильнее всего матчить одинаковые события: например по exchange timestamp, price и другим идентификаторам события, если они есть. Для каждой пары primary/secondary считаем разницу arrival_delta = local_secondary - local_primary. Если delta > 0, primary пришел раньше; если delta < 0, secondary раньше.

После этого смотрим распределение delta: median, p95/p99, долю случаев, где secondary быстрее, и зависимость от времени. Отдельно проверяем, что пары действительно соответствуют одному событию, иначе сравнение latency будет шумным.

Если полных пар нет, можно сравнить распределения latency по feed, но это менее надежно: разные feeds могли доставить разный набор событий.

Нужно выделить пары, где secondary быстрее, и сравнить их с нормальными парами по времени, burst-rate, exchange timestamp, цене, количеству событий и задержке primary.

Сначала строим признак secondary_faster = local_secondary < local_primary для matched events. Дальше не надо сразу гадать причину: нужно сравнить эти строки с обычными по нескольким срезам.

Полезные срезы: время дня, интервалы с большим числом тиков, latency primary, latency secondary, конкретные инструменты, price anomalies, пропуски в primary, out-of-order события. Если secondary быстрее только во время bursts, вероятная причина - primary начинает задерживаться при высокой нагрузке. Если это происходит в конкретные минуты, возможен сетевой или pipeline incident.

В production это превращается в мониторинг: доля secondary_faster по окнам, p95 latency по feed, missing paired events, zero/invalid price и alert на резкие отклонения.

Ищем дыры во времени, нулевые цены, дубликаты, out-of-order events, отрицательную latency, нестыковки между feeds и резкие скачки частоты событий.

Хороший список аномалий для market data:

• пропуски во времени: минуты или секунды без событий, хотя рынок активен;
• price = 0, отрицательные цены или невозможные скачки;
• дубликаты одного события;
• exchange timestamp идет назад или события приходят out of order;
• local timestamp раньше exchange timestamp;
• primary и secondary расходятся по price для одного события;
• один feed систематически теряет события;
• latency резко меняется в конкретных окнах.

Важно не просто перечислить, а сказать, как искать: график event count per minute, histogram latency by feed, paired feed diff, min/max price by window, duplicate key counts и отдельный отчет по anomalies.