HighLoad++ 2013 Iosif Itkin Anton Sitnikov

5206c19df417b8876825b5561344c1a0?s=47 Exactpro
October 29, 2013

HighLoad++ 2013 Iosif Itkin Anton Sitnikov

Система для выявления манипуляций в условиях высокочастотной биржевой торговли

Основная задача системы мониторинга и контроля биржевой площадки — обеспечивать упорядоченное и стабильное функционирование рынка и, в частности, поддерживать аналитическую работу отделов, отвечающих за выявление возможных манипуляций.
Система мониторинга должна собирать информацию обо всех входящих заявках, ответах системы, данных, поступающих из внешних источников, а также о релевантных внутренних состояниях трейдинговой платформы. В условиях высокочастотной торговли объемы этой информации достаточно велики, и их обработка требует масштабируемой инфраструктуры.
Операторы биржевых площадок и участники торгов ожидают, что системы мониторинга и контроля рисков будут оказывать минимальное влияние на основную функциональность трейдинговой платформы и время отклика.
Недобросовестные участники рынка пытаются скрыть злоупотребления и манипуляции рынком под видом легитимных финансовых транзакций, а некоторые законные операции обладают многими признаками нарушений. Системам мониторинга и контроля рынков приходится делать аналитические заключения под высокой нагрузкой, на основе нечеткой логики, параметры которой приходится непрерывно адаптировать под новые трейдинговые ситуации и схемы поведения участников торгов.
Наш доклад содержит обзор предметной области и основных требований к системам мониторинга и контроля для биржевых площадок, а также описание разрабатываемой нами системы, ее архитектуры и выбранного технологического стека, включая Akka, LevelDB, Play, ZeroMQ и ExtJS.

5206c19df417b8876825b5561344c1a0?s=128

Exactpro

October 29, 2013
Tweet

Transcript

  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 быстрее
  12. Архитектура Dolphin Web-Интерфейс Источники данных Конверторы 10010 11101 11010 Сценарии

    Книжки События Потоки событий Web сервер Мультиплексор/демультиплексор потоков JSON Protobuf
  13. Сохранение событий • Уникальный идентификатор события (ИД источника + номер)

    • За кодирование/декодирование отвечает источник • Возможность сохранения иерархических событий • LevelDB – движок, передача по сети – ZeroMQ • Распределение нагрузки по нескольким узлам по ИД события • «Послал и забыл» - каждый узел может определить пропущенное сообщение и запросить его у дублирующего
  14. Сохранение потоков событий • Поток событий = индекс • ИД

    события в потоке – ИД потока + порядковый номер • Ключ в LevelDB – ИД потока + порядковый номер ( + время) • Одна запись в LevelDB включает несколько логических записей • Распределение нагрузки по нескольким узлам
  15. Web-интерфейс и потоки событий • Система создает и записывает множество

    дополнительных потоков (индексов), например • все события, связанные с одним ордером • все ордера, размещенные участником рынка • Сервер web-интерфейса запрашивает потоки из хранилища и предоставляет их пользователю
  16. Web-интерфейс Dolphin • Play framework на стороне сервера • Sencha

    Ext JS на стороне клиента • Динамические обновления: JSON + WebSocket/Comet
  17. Вопросы и ответы Спасибо! http://exactpro.com http://tmpaconf.org http://linkedin.com/in/iosifitkin