1. Система для выявления манипуляций
в условиях высокочастотной биржевой
торговли
Иосиф Иткин, Антон Ситников
Exactpro Systems
2. Чем мы занимаемся
• Критикуем хорошие
программы написанные
умными людьми
• Создаем своих монстров для
проверки высоконагруженных
трейдинговых систем
3. Как делать деньги
There are three ways to make a living in this business: be first,
be smarter, or cheat
4. Что бы такого сделать плохого
• Манипуляция ценами
• Переигрывание объемами
• Уход от налогов
• Финансирование зла
• Инсайдерская торговля
• Проскальзывание перед клиентом
• Многое другое…
5. Что бы такого сделать плохого
• Манипуляция ценами
• Переигрывание объемами
• Уход от налогов
• Финансирование зла
• Инсайдерская торговля
• Проскальзывание перед клиентом
• Многое другое…
Часто легитимная активность выглядит как
злоупотребление, и наоборот
6. Функциональность системы
• Поток сообщений
• Незаметность
• Агрегация данных
• Гибкая настройка правил
• Помощь в обследовании
места преступления и
сборе доказательств
• Хранение данных
7. Система для мониторинга Шша
• Перехват сетевых пакетов
• Разобрать и сложить все сообщения в MySQL
• Сделать логику проверок на SQL запросах
• Хороший инструмент для тестирования
• Но тянет не более 30 млн. сообщений в день
8. Холодный ветер с дождем
• Возникло желание усилить ее хотя бы десятикратно
• Получилась боевая системуа похожая на Market Surveillance
• Теперь мы используем ее как модель для проверки ее собратьев
9. Красивое название
• Возникло желание усилить ее хотя бы десятикратно
• Получилась боевая системуа похожая на Market Surveillance
• Теперь мы используем ее как модель для проверки ее собратьев
10. Complex Event Processing и Akka
• Surveillance-система является подмножеством CEP
• Surveillance-система должна иметь состояние (книжка)
• Коммерческие решения слишком дороги
• Esper не позволяет хранить состояние
• Akka – средство для написания событийных систем
•
•
•
•
высокая производительность
распределенность
удобная модель параллельной обработки
работает на JVM
11. Система хранения
• Много операций добавления, мало операций чтения
• SQL базы данных плохо масштабируются и не позволяют
сохранять большой поток данных
• NoSQL базы данных как Riak, Cassandra, Voldemort требуют
создание большого кластера для достижения 100k msg/sec
• БД движки (Kyoto Cabinet, Krati, LevelDB). Быстрые. Позволяют
написать систему хранения, максимально адаптированную для
задачи. LevelDB быстрее
13. Сохранение событий
• Уникальный идентификатор события (ИД источника + номер)
• За кодирование/декодирование отвечает источник
• Возможность сохранения иерархических событий
• LevelDB – движок, передача по сети – ZeroMQ
• Распределение нагрузки по нескольким узлам по ИД события
• «Послал и забыл» - каждый узел может определить пропущенное
сообщение и запросить его у дублирующего
14. Сохранение потоков событий
• Поток событий = индекс
• ИД события в потоке – ИД потока + порядковый номер
• Ключ в LevelDB – ИД потока + порядковый номер ( + время)
• Одна запись в LevelDB включает несколько логических записей
• Распределение нагрузки по нескольким узлам
15. Web-интерфейс и потоки событий
• Система создает и записывает множество
дополнительных потоков (индексов), например
• все события, связанные с одним ордером
• все ордера, размещенные участником рынка
• Сервер web-интерфейса запрашивает потоки из
хранилища и представляет их пользователю
