Мы много пишем о создании торговых систем и создаем инструменты для их разработки (от API брокерской системы до конструктора роботов внутри торгового терминала). Сегодня речь пойдет о проектировании архитектуры алагоритмической торговой системы — именно этой теме посвящен материал из блога Turing Finance, написанный количественным аналитиком хедж-фонда NMRQL Стюартом Ридом.
В своей статье автор описывает принципы создания архитектуры для трейдинговой системы, которая бы отвечала требованиям ISO/IEC/IEEE 42010 и стандартам описания софта инжиниринговых архитектурных систем. Согласно этим стандартам описание архитектуры должно содержать различные стандартизированные архитектурные подходы и поддерживать связи между конструкторскими решениями и требованиями системы. Мы представляем вашему вниманию адаптированный перевод этой статьи.
Выбор софта
Споры о том, что есть системная архитектура, ведутся до сих пор. В контексте темы статьи автор предлагает понимать под этим внутреннюю инфраструктуру, компоненты приложения которой удовлетворяют функциональным требованиям, могут быть установлены, развернуты и запущены. Нефункциональные требования можно оценить через качество самой системы.
Даже если все функциональные требования выполнены, это еще не значит, что система собрана качественно. Нефункциональные требования также должны быть учтены. Проиллюстрируем эту мысль на примере. Представьте следующую картину: трейдинговая система, которую вы только что приобрели или самостоятельно выстроили, принимает правильные торговые решения. Но она устроена так, что на нее нельзя возложить ни организацию риск-менеджмента, ни бухгалтерские отчеты. Вряд ли такую систему можно назвать полностью удовлетворяющей запросам.
Концепция архитектуры
На абстрактном уровне описываются понятия и основные механизмы системы. Желательно с глубокой и детальной проработкой. На этом этапе трейдинговая система «упаковывается» в архитектуру управления событий (Event Driver Architecture). Та, в свою очередь, разбивается на 4 слоя и два отдельных подхода. Для каждого из них используются свои референсы и свои паттерны. Паттерны – общепринятые структуры для достижения конкретных задач.
Архитектура управления событиями – это архитектура, которая позволяет обнаруживать, производить и уничтожать события или реагировать на них. События могут быть: движениями рынка в реальном времени, комплексными событиями или трендами, торговыми сигналами, которые тем или иным образом упорядочены.
Концепция архитектуры торговой системы представлена на картинке:
Эталонная архитектура
Если использовать строительную метафору, то эталонная архитектура – это то же самое, что и проект несущей стены. Его можно использовать для создания помещения различного дизайна. Главное – он удовлетворяет базовым требованиям строительных стандартов. Эталонная архитектура – некий образец, описывающий общие структуры и механизмы, которые модно использовать для создания определенного архитектурного софта с конкретными требованиями.
Архитектура для алгоритмической трейдинговой системы использует в качестве референсов пространственную архитектуру (SBA) и фундаментальный паттерн «модель-вид-контроллер» (MVC). Подходят также практики типа операционного склада данных (ODS), паттерн «извлечение, преобразование, загрузка» (ETL) и корпоративное хранилище дынных (Data Warehouse).
- Модель-вид-контроллер – паттерн, который разделяет модель приложения, взаимодействия с пользователем и интерфейс на три отдельные части.
- Пространственная архитектура устанавливает инфраструктуру, в которой плохо связанные между собой элементы процесса взаимодействуют через выделенную ассоциативную память (картинка ниже).
Модель-вид-контроллер
Пространственная архитектура
Структурный подход
На этапе построения структуры определяются компоненты и суб-компоненты торговой системы. Структура определяет то, как эти компоненты будут развернуты в рамках физической инфраструктуры. UML-диаграмма (диаграмма на унифицированном языке моделирования) показывает, какие компоненты включены, и как они развертываются. На рисунках представлены диаграммы развертывания: общая и для каждого из слоев.
Архитектурные тактики
Тактика имеет дело с качественными атрибутами модели. Самый простой пример того, как система пытается подстроиться под качественные требования, — манипулирование операционным набором данных через непрерывные запросы. Эти компоненты способны непрерывно анализировать ODS, чтобы обнаруживать и извлекать комплексные события. Вот список тактик, которые используются в архитектуре:
- Паттерн дезинтегратора в очереди событий.
- Выделенная память для очереди и порядка событий.
- Язык непрерывный запросов (CQL) для ODS.
- Фильтр данных для входящей информации.
- Алгоритмы распределения входящих и экспортных соединений для обхода перегрузок.
- Активное управление очередями (AQM) и система уведомлений о перегрузках.
- Подсчет потребляемых ресурсов с возможностью масштабирования системы.
- Активное резервирование на каждую единичную неисправность.
- Индексация и оптимизация устойчивых структур в ODS.
- Расписание регулярных бэкапов и скриптов очистки для ODS.
- Транзакция историй на все базы данных.
- Проверочные суммы для каждого ряда для обнаружения ошибок.
- Аннотация событий с отметками времени для игнорирования устаревших событий.
- Установление правил подтверждения порядка для максимального числа трейдинговых событий.
- Автоматизированные компоненты торговли используют размещенные в памяти базы для анализа.
- Двухуровневая идентификация в пользовательском интерфейсе для активации соединения.
- Шифрование в пользовательском интерфейсе для подключения.
- Паттерн наблюдения для управления обзорами в MVC.
Этот список предлагает лишь небольшое число проектировочных решений, которые автор статьи смог идентифицировать в процессе разработки архитектуры для трейдинговой системы. Список далеко не полный. На каждом уровне детализации к ним добавляются новые тактики для удовлетворения функциональных и нефункциональных требований. На картинке представлены три диаграммы, описывающие паттерн дезинтегратора, паттерн фильтра и компоненты непрерывных запросов:
«Поведенческий» взгляд
Этот обзор архитектуры демонстрирует то, как должны взаимодействовать компоненты и слои системы. Он весьма полезен, когда вы разрабатываете сценарии для тестирования системы и понимания того, как все устроено от начала и до конца. Этот обзор состоит из диаграмм последовательности и диаграмм активностей. Последние показывают внутренние процессы работы трейдинговой системы и как сами трейдеры с ней взаимодействуют. Примеры таких диаграмм представлены ниже.
Техники и фреймворки
Финальный шаг в разработке архитектуры программной части торговой системы – найти подходящие техники и фреймворки, которые можно использовать для ее реализации. Общее правило здесь: постараться для начала выжать все, что возможно, из существующих техник, убедившись, что они отвечают функциональным и нефункциональным требованиям. Фреймворк в данном случае представляет собой эталонную архитектуру. Так, например, фреймворк JBoss реализует эталонную архитектуру JEE. Вот список нескольких техник и фреймворков, которые можно использовать для создания архитектуры трейдинговой системы:
- CUDA – продукт компании NVidia. У нее есть сразу несколько продуктов, которые поддерживают высокую производительность для вычислений в финансовом моделировании. Можно добиться 50-кратного увеличения производительности, к примеру, для симуляции Монте-Карло на GPU вместо CPU.
- Apache river – это набор инструментов для создания распределенных систем. Он нашел применения в качестве фреймворка для приложений, основанных на паттерне SBA.
- Apache Hadoop – этот инструмент предлагает интересные решения для проблем с большими данными. Может быть развернут в кластерном окружении для поддержки технологии CUDA.
- AlgoTrader – платформа алгоритмического трейдинга с открытым доступом. Ее можно развернуть там, где имеют место автоматизированные трейдерские компоненты.
- FIX Engine – самостоятельное приложение, поддерживающее протоколы финансового информационного обмена (FIX, FAST и FIXatdl).
Следует помнить, что любые компоненты (техники или фреймворки) должны иметь API, чтобы обеспечить их совместимость.
Заключение
Предложенный вариант архитектуры удовлетворяет самым общим требованиям алгоритмических трейдинговых систем. Для таких систем основную нагрузку несут три фактора, которые выступают на практике в разных комбинациях:
- Зависимость от внешней среды и систем обмена.
- Нефункциональные требования.
- Эволюция архитектурных ограничений.
Предложенная архитектура нуждается в адаптации на основе движения от кейса к кейсу. Она должна соответствовать специфичным организационным, регуляторным требованиям и региональным ограничениям. Проще говоря, в статье был представлен лишь список полезных ссылок, которые нужно еще настраивать под индивидуальные потребности.
Другие материалы по теме от ITinvest:
- Технологии фондового рынка: 10 заблуждений о нейронных сетях
Аналитические материалы о ситуации на финансовых рынках от экспертов ITinvest - Можно ли создать алгоритм для торговли на бирже с помощью анализа тональности сообщений в интернете
- Как определить наилучшее время для сделки на фондовом рынке: Алгоритмы следования тренду
- ИБ-стартап Palantir поможет инвестбанку Credit Suisse создать систему для выявления недобросовестных трейдеров
- Эксперимент: Использование Google Trends для прогнозирования обвалов фондового рынка
- Эксперимент: создание алгоритма для прогнозирования поведения фондовых индексов
Автор: ITinvest
