Один из самых распространенных вопросов, который задают люди, только начинающие интересоваться алгоритмической торговлей это «Какой язык программирования для этого подходит лучше всего?». Само собой, короткий ответ заключается в том, что никакого «лучшего» варианта не существует. При выборе инструмента следует учитывать параметры торговой стратегии, необходимую производительность, модульность, методологию разработки и требования к отказоустойчивости. В этой статье мы поговорим о главных компонентах архитектуры алгоритмической торговой системы и о том, как каждый из них влияет на выбор языка программирования.
Примечание переводчика: Мы очень часто сталкиваемся со скептическим отношением к алгоритмической торговли. Бытует мнение, что это сплошная спекуляция, которая несет исключительный вред и заниматься этим для технического специалиста, мягко, говоря, не комильфо. Предваряя некоторые вопросы в комметариях, мы хотели бы сразу дать ссылку на материал, в котором уделено много внимания описанию того, какие на фондовых рынках существуют типы торговцев и почем КАЖДЫЙ из них несет определенную пользу в определенный момент времени, а также на топик, в котором затрагивается более общая тема назначения самих бирж. А вот здесь можно почитать об опыте подобной торговли, который позволил человеку, обладающими познаниями в программировании заработать полмиллиона долларов (первая часть, вторая часть.) Приятного чтения!
Прежде всего мы рассмотрим главные элементы алгоритмической торговой системы, такие как аналитические средства, оптимизатор портфолио, риск-менедже и, собственно, торговый движок. Затем коснемся особенностей различных торговых стратегий и того, как выбор какой-либо из них влияет на разработку всей системы. В частности, мы обсудим предполагаемую частоту (скорость) и объем торгов.
После того, как вы выбрали какую-то торговую стратегию, необходимо спроектировать архитектуру всей системы. Сюда входит и выбор «железа», операционной системы (или нескольких систем) и устойчивость к редким, но потенциально катастрофическим поворотам событий. При проектировании архитектуры также следует уделять должное внимание производительности — причем, как быстроте работы аналитических инструментов системы, так и самого торгового движка.
Что делает торговая система?
Прежде чем выбирать «самый лучший» язык программирования, на котором будет работать наш робот, зарабатывающий миллионы, необходимо определиться с требованиями к этому языку. Будет ли система основана только лишь на выполнении задач или нам также потребуется риск-менеджмент или модуль конструктора портфолио? Понадобится ли для работы быстродействующий модуль бэк-тестинга? Для большинства стратегий торговые системы можно разделить на две категории: исследовательские и генерирующие сигналы.
Исследовательские стратегии фокусируются на тестировании качества работы на исторических данных. Тестирование на данных, собранных в прошлом, называется бэктестингом. На вычислительную мощность модуля бэктестинга влияют объем данных и алгоритмическая сложность стратегии. В деле оптимизации оптимизации скорости работы исследовательских стратегий в роли лимитирующих факторов часто выступают скорость процессора и число его ядер.
Если же говорить о генерировании торговых сигналов, то здесь алгоритм должен понимать, когда следует покупать или продавать и посылать соответствующие приказы (чаще всего через брокерскую систему) в рынок. Для некоторых стратегий требуется большой уровень производительности. Ограничивают скорость работы стратегии такие факторы как ширина канала данных и задержка, вносимая брокерской и биржевой системой (latency).
Таким образом, в зависимости от того, стратегия какой категории вам нужна, и выбор языка программирования для ее реализации может различаться.
Тип, ликвидность и объем стратегии
Тип торговой стратегии повлияет на все ее последующее устройство. Необходимо оценить то, на каких рынках планируется вести торговли, возможности подключения внешних поставщиков данных, а также частоту операций, совершаемых алгоритм, и их объем. Важными факторами станут и поиск баланса между простотой разработки и оптимизацией производительности, а также железо, включая серверы, которые потребуется разместить в брокерских или биржевых дата-центрах, и дополнительное оборудование, которое может понадобиться (GPU, FPGA и т.п.).
Для торговли низколиквидными акциями на американских рынках потребуется задействовать совсем другие технологии, чем в случае высокочастотной статистической арбитражной стратегии на рынке фьючерсов. Прежде чем приступать к выбору собственно языка программирования, следует заняться подбором поставщиков данных, с помощью которых будет работать ваша торговая стратегия.
Необходимо проанализировать существующие возможности подключения к системам поставщиков, структуру любых API, скорость поставки данных, и возможности по ее хранению, в случае сбоев. Мудрым решением будет и организация доступа к нескольким таким системам одновременно, что также потребует отдельно проработки, поскольку у каждого поставщика данных свои технологические требования (символы тикеров биржевых инструментов и т.п.).
Предполагаемая частота торговых окажет определяющее влияние на то, как будет реализован технологический стек вашей системы. Стратегии, которым требуется обновление данных чаще чем раз в минуту, потребуют больших ресурсов для своей работы.
В случае стратегий, которым требуются тиковые данные, необходимо разрабатывать всю систему согласно методологии performance driven design. Для этих задач часто используются HDF5 или kdb+.
Для обработки избыточных объемов данных, которые требуются для HFT-приложений, необходимо использовать и оптимизированный бэктестер и торговый движок. Главными кандидатами на роль языка программирования в такой системе будет С/С++ (возможно, кое-где Assembler). Высокочастотные стратегии часто потребуют и дополнительного оборудования, вроде программируемых матриц (FPGA), а также размещения серверов максимально близко к биржевому ядру и тюнинг сетевых интерфейсов самих серверов.
Исследовательские системы
При создании систем такого рода часто требуется прибегать к интерактивной разработке и автоматизации сценариев. Первое понятие имеет место в IDE вроде Visual Studio, MatLab или R Studio. Автоматизация сценариев связана с большим объемом расчетов для разных параметров и точек данных. Учитывая все это, необходимо выбирать такой язык, который дает отличные возможности по тестированию кода, а также позволяет добиваться приемлемого быстродействия при обасчитывании стратегий при разных параметрах.
На данном этапе часто используются такие IDE, как Microsoft Visual C++/C#, которая включает разнообразные средства для отладки, автозавершения кода и работы со всем проектным стеком (ORM, LINQ); MatLab, который разработан специально для задач численной линейной алгебры и векторных операций; R Studio, который реализован с помощью статистического языка R; Eclipse IDE для Linux Java и C++ и полупроприетарные IDE вроде Enthought Canopy для Python, который включает разнообразные библиотеки для анализа данных (NumPy, SciPy, scikit-learn и pandas).
Для численного бэктестинга подходят все упомянутые средства, хотя из-за того, что код будет запускаться «в фоновом режиме» вовсе не обязательно использоваться графические IDE. На данном этапе прежде всего следует думать о скорости работы системы. Компилируемые языки (вроде C++) полезны, когда число параметров при бэктестинга очень велико. В таком случае всегда следует очень внимательно подходить к каждому шагу при проектировании, поскольку ваша система изначально может быть не такой быстрой. В случае интепретируемых языков вроде Python для бэктестинга часто используют высокопроизводительные библиотеки (NumPy/pandas).
Выбор языка для реализации модуля бэктестинга будет определяться конкретными нуждами вашего алгоритма и количеством доступных для данного языка библиотек (подробнее об этом ниже). Не стоит, однако, забывать, что язык, использованный для бэктестера и исследовательской среды может отличаться от средств, выбранных для модулей конструктора портфолио, риск-менеджмента и торгового движка.
Конструктор портфолио и риск-менеджмент
Многие алгоритмические трейдеры часто недооценивают важность конструктора портфолио и риск-менеджмента. Это большая ошибка, поскольку эти средства позволят вам сохранить свои деньги на бирже. С их помощью можно не только уменьшить количество рискованных сделок, но и свести к минимуму затраты на совершение торговых операций, уменьшив транзакционные издержки.
Продуманные реализации этих компонентов могут оказать значительное влияние на качество и постоянность рентабельности. Без них очень сложно создать стабильную стратегию, потому что наличие механизма сбора портфолио и риск-менеджера позволяют легко модифицировать торговую систему.
Задача модуля конструктора портфолио заключается в том, чтобы намечать набор потенциально выгодных сделок и совершать те из них, которые принесут наибольшую выгоду — для этого анализируется множество факторов (например волатильности, класс актива и сектор компании, чьи акции торгуются). В соответствии с этим происходит распределение доступного капитала по разнообразным биржевым инструментам.
Конструирование портфолио часто сводится к задаче линейной алгебры (вроде матричной факторизации), а это значит, что производительность работы механизма в значительной степени зависит от эффективности реализации в системе средств линейной алгебры. Среди популярных библиотек uBLAS, LAPACK и NAG for C++. Обширными возможностями в плане операций с матрицами обладает MatLab. В Python для подобных вычислений используется NumPy/SciPy. Для того, чтобы система могла поддерживать качественное и сбалансированное портфолио вам понадобится скомпилированная (и хорошо оптимизированная) библиотека для работы с матрицами.
Еще одна крайне важная часть любой алгоритмической торгово системы — это модуль риск-менеджмента. Риск может иметь множество форм: повышенная волательность (для некоторых стратегий, правда, это даже желательно), увеличенные корреляции между классами активов, перебои на серверах, так называемые «черные лебеди» (события, которые невозможно предугадать) и необнаруженные баги в коде торговой программы — и это лишь малая часть возможных проблем.
Модуль риск-менеджмента пытается «предвидеть» последствия большинства вышеперечисленных рисков. Очень часто, для этого используется статистический анализ (например стресс-тесты по методу Монте-Карло). В подобных вычислениях большую роль играет параллелизм, и, в целом, проблемы производительности можно решить простым наращиванием вычислительных мощностей.
Торговый движок
Задача торгового движка системы заключается в получении отфильтрованных торговых сигналов от модулей конструктора портфолио и риск-менеджмента, генерирование на их основе торговых приказов, которые затем отправляются в брокерскую торговую систему. В случае «обычных» частных трейдеров, для этого скорее всего понадобится API или соединение по протоколу FIX. Соответственно, для выбора языка нужно проанализировать качество самого API, наличие/отсутствие программных оболочек для работы с ним, предполагаемую частоту совершения операций и ожидаемое «проскальзывание» между моментом отправки приказа в систему брокера и его появлением в ядре биржевой торговой системы.
«Качество» API складывается из нескольких элементов: качество документации, производительности, которую обеспечивает интерфейс, нужен ли для работы с ним отдельный софт или можно установить соединение без GUI и т.п.
Большинство брокерских API имеют интерфейсы на C++ и/или Java. Обычно вокруг каждого такого средства образуется сообщество пользователей-клиентов брокера, которые помогают его развивать и создают врапперы для C#, Python, R, Excel и MatLab. Необходимо, однако, помнить, что любой дополнительный плагин может содержать в себе различные ошибки, поэтому их всегда необходимо тщательно тестировать и убеждаться, что разработчики занимаются поддержкой своего творения. Лучше всего посмотреть, как часто выходили обновления в последние месяцы.
Частота совершения торговых операций — важнейший элемент алгоритма торгового движка. Робот может посылать сотни приказов в минуту, пожтому производительность системы крайне важна. Если система реализована не очень хорошо, то неизбежно возникновение значительного проскальзывания между ценой, когда приказ должен был быть выставлен и той, по которой он реально исполнился. Это может драматическим образом сказать на доходности.
Языки со статической типизации (см. ниже) вроде C++/Java обычно лучше всего подходят для написания торгового движка, но при их использовании возникают вопросы по времени разработки, легкости тестирования и поддержки кода. С другой стороны, языки с динамической типизацией такие как Python и Perl сейчас стали «достаточно быстрыми». Убедитесь в том, что все компоненты вашей системы разработаны с помощью модульного подхода, который позволяет легко убирать и добавлять в систему новые элементы с течением времени.
Планирование архитектуры и процесс разработки
Мы уже обсудили компоненты торговой системы, важность параметров частоты торговых операций и их объем, но пока что не коснулись инфраструктурных вопросов. Независимый частный трейдер или сотрудник небольшой HFT-компании или фонда, скорее всего, будет сталкиваться с множеством вызовов — анализ альфа-модели, риск-менеджмент и параметры выполнения, а также финальное развертывание системы — все это предстоит проделать самостоятельно. Все это важные моменты, поэтому, прежде чем с головой погрузиться в обсуждение языков программирования, неплохо будет обсудить оптимальную архитектуру системы.
Разделение интересов
Одной из важнейших задач при создании торгового робота является «разделение интересов» или, говоря языком разработки ПО, разделение различных аспектов торговой системы на модульные компоненты.
Такое разделение на компоненты поможет в будущем изменять/заменять/добавлять в систему новые модули для улушчения производительности, надежности или облегчающие ее сопровождение, без необходимости проверять все зависимости и «не сломалось ли чего» в других местах. Для торговых систем такой подход — это лучшая практика. Для систем, которые работают «на средних скоростях» ее реализация крайне желательна. В случае HFT-систем некоторые правила, возможно, придется проигнорировать для того, чтобы добиться еще более высокой скорости работы, но в общем и целом, стоит придерживаться этого подхода.
Создание компонентной карты алгоритмической торговой системы — это тема, заслуживающая отдельной статьи. Тем не менее, оптимальный подход здесь заключается в том, чтобы реализовать отдельные компонентны для исторических и реальных рыночной информации, хранения данных, API доступа, модуля бэктестинга, параметров стратегии, конструктора портфолио, а также модуля риск-менеджмента и самого торгового движка.
Например, если будут обнаружены проблемы с эффективностью работы с хранилищем данных (даже после работ по оптимизации), то такой модуль можно будет легко заменить при почти полном отсутствии необходимости переписывать что-либо в компонентах приема данных или доступа к API.
Еще один плюс модульной схемы в том, что она позволяет использовать в разных частях системы разные языки программирования. Нет никакой необходимости в жесткой привязке к конкретному средству, если метод коммуникации компонентов системы независим. Например, они могут взаимодействовать через TCP/IP, ZeroMQ или другие протоколы.
Конкретный пример: система бэктестинга может быть написана для C++ для достижения высокой производительности, в то время как менеджер портфолио и торговый движок могут быть написаны на Python с применением SciPy и IBPy.
Мысли о производительности
Производительность важна практически для любой торговой стратегии. Чем выше частота торговой истемы, тем более важную роль играет этот фактор. Под «производительностью» понимается множество вещей, включая скорость выполнения алгоритма, сетевая задержка (network latency), канал связи, ввод/вывод данных, мнопоточность/параллелизм и масштабирование. Каждому из этих аспектов посвящены отдельные книги, поэтому мы лишь слегка коснемся их. Теперь мы будем обсуждать архитектуру и конкретные языки программирования с точки зрения их влияния на общую производительность системы.
Дональ Кнут, один из отцов того, что мы называем Computer Science, сказал очень мудрую вещь: «корень всех зол — это преждевременная оптимизация». Это верно почти всегда, но не в случае разработки HFT-торгового алгоритма! Если же вы заинтересованы в создании менее высокочастотной стратегии, то общий подход в вашем случае будет заключаться в построении системы самым простым способом и начале ее оптимизации лишь при обнаружении узких мест.
Для их выявления используются разнообразные средства профайлинга. Можно создавать профили как в среде MS Windows так и в Linux. Для этого существует целая куча разнообразных средств. Теперь, как и договаривались, мы обсудим в контексте производительности конкретные языки программирования.
C++, Java, Python, R и MatLab — в каждом из них есть высокопроизводительные библиотеки (как внутренние, так и внешние) для базовых наоров данных и алгоритмической работы. С++ поставляется в комплекте с Standard Template Librar, а Python содержит NumPy/SciPy. В этих библиотеках можно найти стандартные математические задачи, и писать свою собственную реализацию — это путь, который редко когда можно назвать выгодным.
Исключением можно назвать случай, когда вам требуется уникальное оборудование и вы используете алгоритм, который работает с какими-то проприетарными расширениями (кроде кастомных кэшей). При этом, нужно помнить, что изобретение колеса часто отнимает время, которое можно потратить с куда большей пользой на разработку и оптимизацию всех частей торговой системы. Время на разработку — бесценно, особенно, если вы создаете свою систему в одиночку.
Для торгового движка часто возникает проблема задержек поскольку средства для анализа рынка обычно расположены на той же самой машине. Задержки могут возникать на любом шаге процесса выполнения: идут обращения к базам данных (дисковые/сетевые задержки), необходимо сгенерировать торговые сигналы (задержки ОС или ядра), отправить приказы на биржу (задержка каналов связи) и их должно обработать ядро торговой системы биржи (биржевые задержки).
Для создания эффективной HFT-системы вам придется разобраться с оптимизацией на уровне ядра и оптимизации процессов передачи данных.
Еще один полезный инструмент разработчика высокоскоростных биржевых роботов — это кэширование. Главная мысль кжширования заключается в хранении часто запрашиваемой информации таким образом, чтобы ее можно было получать без лишних затрат ресурсов. В веб-разработке, к примеру, кэширование может использоваться при загрузке данных из реляционной базы данных на диске в память. Все последующие запросы к этим данным уже не нужно будет направлять в базу, за счет чего можно значительно улучшить производительность систему.
Для онлайн-трейдинга кэширование также может быть очень полезной вещью. Например, в кэш можно сохранить текущее состояние портфеля и продержать там до момента «ребалансировки» инструментов в нем, что позволит избежать необходимости генерировать список купленных и проданных активов заново при каждом срабатывании алгоритма — его можно будет просто обновить. Подобная операция требует значительных процессорных и I/O-ресурсов.
К сожалеию, кэширование — это инструмент не без своих проблем. Перезагрузка данных в кэше из-за переменчивой природы кэш-хранилищ может также требовать немаленьких инфраструктурных ресурсов. Еще одна проблема — эффект домино, при котором при высокой загрузке по ошибке начинаетс генерация нескольких копий кэша, что влечет за собой череду сбоев.
Динамическое выделение памяти — это дорогая операция. Поэтому высокопроизводительные торговые приложения должны хорошо уметь работать с памятью и уметь выделять и забирать ее на всех этапах программного потока. В более новхе языках программирования, таких как Java, C# или Pythong есть автоматический garbage collection, благодаря которому выделение или высвобождение памяти происходит динамически.
Этот инструмент крайне полезен при разработке поскольку снижает число ошибок и повышает читабельность кода. Однако, для некоторых HFT-систем все же лучше не использовать стандартные средства по работе с памятью, а реализовать собственные. Например в Java с помощью некоторого тюнинга коллектора мусора и конфигурации куч можно повысить производительность HFT-стратегий.
В C++ нет нативных средств garbage collector поэтому управлять выделением и высвобождением памяти необходимо в ходе реализации объектов. Это, конечно, делает более вероятным возниковение ошибок, но при этом позволяет лучше контролировать объекты и кучи в конкретных приложениях. При выборе языка программирования потрудитесь подобронее узнать о том, как в нем работает garbage collection, и можно ли как-то оптимизировать работу этого механизма для конкретных сценариев.
Многие операции в алгоритмической торговле можно запараллелить, то есть сделать так, чтобы различные программные операции выполнялись одновременно. Так называемые «ошеломительно параллельные» алгоритмы включают шаги, которые могут быть выполнены полностью независимо от других шагов. Конкретные статистические операции, вроде симуляций Монте-Карло, являются хорошим примеров таких распараллеленных алгоритмов, поскольку каждая вероятность и ход событий при ее наступлении может быть вычислена без знания других возможных путей развития ситуации.
Другие алгоритмы лишь частично поддаются параллелизации. К алгоритмам такого типа можно отнести моделирование в гидродинамике, где область вычислений может быть разделена на отдельные домены, но они все равно должны быть связаны друг с другом. Параллелизуемые алгоритмы подчиняются закону Амдаля, который вводит теоретический верхний предел повышения производительности параллелизованного алгоритма в случа N отдельных процессов (например на ядре процессора или в потоке).
Параллелиация стала важным элементом оптимизации, поскольку тактовые скорости процессоров в последнее время не увеличиваются, а новые процессоры содержат все больше ядер, которые могут выполнять паралелльные вычисления. Развитие графического аппаратного обеспечения (в особенности для видео игр) привело и к улучшению GPU, которые теперь содержат сотни «ядер» для выполнения множества одновременных операций. И цена таких GPU стала куда более приемлемой. Высокоуровневые фреймворки вроде CUDA от Nvidia получили широкое распространение в науке и финансах.
Обычно подобные GPU-устройства подходят лишь для выполнения исследовательских задач, но есть и такие (включая программируемые матрицы FPGA), которые используются непосредственно для HFT. В настоящий момент подавляющее большинство современных языков программирования в той или иной степени поддерживают многопоточность, что позволит вам, к примеру, оптимизировать бэктестер, чтобы он использовал независящие друг от друга процессы.
Масштабирование в разработке программного обеспечения значит возможность системы справляться с постоянно возрастающими нагрузками в форме большего числа запросов, большей загрзки процессора и большего объема выделяемой памяти. В алгоритмической торговле стратегия «масштабируется», есть она может работать с большим объемом капитала и все равно последовательно давать положительный результат. Стек торговой технологии масштабируем, если он может обработать большие объемы и справиться с возросшей задержкой без возникновения узких мест.
Само собой системы должны разрабатываться так, чтобы их было можно масштабировать, однако предугадать возникновение проблем и узких мест довольно трудно. Строгое логгирование, профайлинг и мониторинг позволят сделать систему более масштабируемой. Некоторые языки программирования часто описывают как «немасштабируемые». На самом деле те, кто так говорят, просто «не умеют их готовить». Немасштабируемым может быть весь стек технологий, но никак не язык сам по себе. Естественно, какие-то языки имеют лучшую производительность, чем другие в конкретных случаях, но нельзя сказать, что какой-то язык «лучше» другого во всех смыслах.
Как мы говорили выше, нужно разделять интересы. Для того, чтобы система могла справляться с «шипами» (так называют внезапную волатильность, которая вызывает большое число сделок), полезно создать «архитектуру очереди сообщений». Это значит, что между компонентнами торговой системы располагается очередь сообщений, таким образом, чтобы система зависала, если определенный компонент не может обработать много запросов.
Железо и операционные системы
Железо на котором работает ваша торговая система может оказать значительное влияние на прибыльность алгоритма. Это даже не касается исключительно высокочастотных торговцев — плохие серверы могут дать сбой в любой момент, и будет неважно сколько сделок совершает ваш робот, если он не сможет по вине железа сделать одну, но очень важную операцию. Поэтому выбор аппаратного обеспечения для торговой системы крайне важен. Обычно выбор стоит между собственным компьютером пользователя, удаленным сервером, облачной виртуальной машиной или сервером на колокации (в дата-центре биржи или брокера).
Понятно, что вариант с десктопом самый простой и дешевый во многом благодаря существованию большого числа user friendly операционных систем (Windows, Mac OS, Ubuntu). Но у них есть и значительные минусы. Один из главных — каждый новый апгрейд ОС потребует патчинга торгового робота, плюс компьютер периодически придется перезагружать, что тоже не очень хорошо. Кроме того, вычислительные ресурсы персональной машины тратятся и на поддержание GUI, а ведь их можно было бы истратить на увеличение производительности торговой системы!
Кроме того, работа дома или в офисе чревата проблемами с аптаймом и интернет соединением. Главным плюсом десктоп-системы является тот факто, что дополнительные вычислительные мощности для нее можно приобрести за сумму, гораздо меньшую, чем потребуется для апгрейда аналогичного по скорости сервера.
или облачная машина выйдут вам дороже, чем настольный компьютер, но и позволят организовать куда более избыточную инфраструктуру — включая автоматизированные бэкапы данных, возможность настройки мониторинга аптайма и скорости работы. Их сложнее будет администрировать, поскольку для этого, как минимум, понадобится удаленное содинение.
Для Windows-серверов скорее всего будет использоваться RDP, а в Unix-based системах не бойтись без SSH — там вообще никуда не уйти от командной строки, что делает некоторые средства разработки вроде Excel или MatLab неприменимыми из-за их невозможности работы без графического интерфейса.
Сервер на колокации — значит просто, что вы ставите свой сервер как можно ближе к ядру биржи — в ее дата-центр, или в дата-центр брокера, который находится с биржевой системой в одной локальной сети. Для некоторых HFT-стратегий, это единственный приемлемый выход, несмотря на то, что он и наиболее дорогой.
Финальный аспект, который нужно рассмотреть при выборе программного обеспечения и языка программирования, это независимость от платформы. Есть ли необходимость выполнения кода на различных ОС? Или код разработан для запуска на конкретной архитектуре процессора — например, x86/x64, — или его можно будет запустить и на процессорах RISC от ARM? Ответы на эти вопросы будут напрямую зависеть от предполагаемой частоты и типа торговой стратегии.
Устойчивость и тестирование
Лучший способ потерять кучу денег на алгоритмической торговле, это создать неустойчивую систему. Устойчивость включает в себя способность системы реагировать на редкие события вроде сбоев в работе брокеров (или их банкротства), неожиданной повышенной волатильности, интернет-сбои провайдеров услуг (интернет, дата-центры), или случайное удаление всей торговой базы данных. Плохо реализованная архитектура может за пару секунд свести на нет годы успешной и прибыльной торговли. Ключевыми моментами вашей торговой системы должны стать отладка, тестирование, резервное копирование, доступность и мониторинг.
При разработке качественной торговой системы даже не расчитывайте тратить на отладку, тестирование и поддержку меньше 50% всего времени.
Практически все языки программирования поставляются в комплекте с отладчиком или имеют адекватные сторонние альтернативы. Благодаря отладчику вы можете расставлять в коде специальные точки прерывания, которые позволят изучить поведение программы до того момента, как происходит сбой.
Отладка — важный инструмент в анализе программных ошибок, но в основном она используется в компилируемых языках вроде C++ или Java, а интерпретируемые языки вроде Python отлаживать легче в принципе. Тем не менее, и этот язык поставляется с pdb — мощным инструментом отладки. В Microsoft Visual C++ IDE есть дополнительные средства отладки с GUI, а для Linux C++ придется использовать отладчик gdb.
Не обойтись и без тестирования. Наиболее соверменная парадигма тестирования — это TTD или Test Driven Development, в которой сначала пишется тест, покрывающий желаемое изменение в системе, а затем под него уже пишется код, который сможет пройти этот тест.
Разработка через тестирование — нелегкое занятие, требующее немалой дисциплины. Для C++ фреймворк модульного тестирования есть в Boost, в Java для тех же целей существует библиотека JUnit. В Python также есть модуль для подобного тестирования, который является частью стандартной библиотеки. Многие другие языки также обладают средствами и фреймворками для осуществления модульного тестирования.
В продуктивной среде абсолютно необходимо и продуманной логгирование. Необходимо наладить процесс выдачи разнообразных сообщений об ошибках и поведении системы. Логи — это первое, с чего вы будете начинать, разбираясь с проблемами и сбоями. При всей внешней простоте задачи — вывод сообщений в файл и его хранение — на самом деле все куда сложнее, и продумывать схему системы логгирования следует до того, как приступать к ее реализации.
И в Windows и в Linux есть разнообразные средства и возможности для логгирования, и языки программирования также поставляются с лог-библиотеками, которые подойдут в большинстве случаев. Разумным решением будет централизация всей отчетной информации — так ее будет удобнее анализировать в дальнейшем.
Логи дадут вам представление о том, что происходило в прошлом, а система мониторинга обеспечит понимание текущей ситуации. Монорить можно и нужно практически все аспекты вашей торговой системы: использование дискового пространства, доступная память, состояния каналов связи и загрузка процессора — все это полезные данные для базового понимания положения дел.
Помимо этого стоит мониторить и чисто торгоые метрики — ненормальные объемы или цены, внезапные просадки счета и новости, затрагивающие определенные сектора экономики или целые страны. В комплекте именно с монитором должен идти модуль, который будет оповещать вас в случае, если какой-либо из параметров нарушен. Можно использовать разный метод доставки сообщений (email, SMS, звонок от робота на телефон) в зависимости от серьезности конкретного события.
Обычно мониторингом системы занимается выделенный администратор, но если вы все делаете самостоятельно, то придется прибегать к использованию различных средств, которые облегчат разработку, благо существует множество как платных так и бесплатных, открытых решений для самых разных случаев.
Резервное копирование и доступность системы — это то, над чем прежде всего нужно работать. Подумайте над следующими вопросами: 1) если по какой-то (ужасной) причине вдруг будет удалена вся база данных (а бэкапов нет), то как это повлияет на алгоритм исследования и исполнения приказов? 2) Если торговая система будет «висеть» на протяжении длительного периода времени (при наличии открытых позиций) как это скажется на количестве денег на счету и портфеле? Ответы на эти вопросы обычно пугают.
Поэтому нужно обязательно разработать систему для бэкапа и дальнейшего развертывания данных — это чуть ли не важнее самого копирования. Многие трейдеры не тестируют сохраненные бэкапы, что влечет за собой отсутствие гарантий того, что в нужный момент эти данные удастся «накатить» и система заработает как положено.
Тоже самое касается и работ по доступности системы. Несмотря на дополнительные затраты обязательно позаботьтесь о наличии избыточной инфраструктуры и резервировании — стоимость простоя системы может превысить все издержки в десятки раз за несколько минут.
Выбор языка
Мы уже рассмотрели множество факторов и аспектов, влияющих на разработку торговой системы. Пора поговорить о языках программирвоания.
Система типов
При выборе языка программирования для торгового стека нельзя забывать о системе типов. Языки, представляющие интерес для алгоритмических торговцев могут быть как динамическими, так и статическими. К последним относятся C++ и Java — у них проверка типов осуществляется во время процесса компиляции. В динамических языках эта проверка происходит «на лету» без всякой компиляции. Таковы, к примеру, Python, Perl и JavaScript
Для высокоточных систем, к которым безусловно относятся торговые роботы, проверка типов в процессе компиляции может быть очень выгодным вариантом, поскольку он избавляет от большого количества ошибок, которые могли бы привести к численным ошибкам. С другой стороны — проверка типов не отлавливает все возможные баги, поэтому необходимо уделять время и обработке исключений. При использовании динамических языков часто встречаются ошибки запуска, которые бы не случились при проверки типов в статических языках. Если вы все же используете динамический язык, то стоит реализовать методологию TDD и модульного тестирования для снижения числа возможных ошибок.
Open source или проприетарный софт?
Одним из главных решений, которое придется принять разработчику алгоритмического торгового софта, это использовать ли коммерческое программное оебспечение или прибегнуть к открытым технологиями. Свои плюсы и минусы есть у каждого из этих путей. Необходимо изучить насколько хорошо поддерживается язык, насколько активно коммьюнити, развивающее его, проста ли установка и поддержка, насколько качественная документация представлена в сети и просчитать любые возможные затраты на лицензии и использование продукта.
Стек Microsoft .NET (включая Visual C++, Visual C#) и MathWorks от MatLab являются основными проприетарными средствами для разработки торговых систем. Обе системы оттестированы тысячами трейдеров по всему миру на различных биржевых площадках.
Данные программные продукты полно и качественно документированы и обладают обширным активным сообществом, заинтересованным в развитии этих средств. Программное обеспечение .NET позволяет осуществлять интеграцию с многими языками программирования вроде C++, C# и VB, а также довольно просто подключать другие продукты Microsoft вроде базы данных SQL Server (через LINQ). У MatLab также есть множество плагинов и библиотек (некоторые из них платные), которые можно применить практически в любой области финансовых вычислений.
Но есть и ограничения. Основное из них — цена, которая может оказаться неподъемной для трейдера-одиночки (хотя тот же Microsoft дает базовую версию Visual Studio бесплатно). Продукты Microsoft отлично сочетаются друг с другом, но интегрировать их с какими-либо сторонними системами совсем не так легко. Кроме того, Visual Studio работает только под WIndows, который можно обвинить в меньшей производительности по сравнению с аналогичным по мощности хорошо настроенным Linux-сервером. MatLab же недостает некоторых плагинов, которые могли бы сделать использование этого продукта легче.
Главный минус проприетарных продуктов — отсутствие доступа к исходному коду. Это значит, что когда вам понадобится ультра и мега производительность, то вы не сможете ничего в них подкрутить, а стало быть, будете ограничены.
В финансовой индустрии очень распространены и open source-продукты. Например Linux, MySQL/PostgreSQL, Python, R, C++ и Java используются там, где нужна высокая производительность. Однако, ни одно из этих средств нельзя назвать «заточенным» на этот конкретный рынок. В Python и R содержится множество избыточных библиотек, с помощью которых можно выполнять практически любые возможные вычисления на скоростях, сравнимых с компилируемыми языками (с определенными оговорками, конечно).
Главный плюс использования интерпретируемых языков — это скорость разработки. Python и R требуют куда меньше строк кода для достижения аналогичной функциональности. Кроме того, они также часто позволяют проводить инерактивную console based разработку, что значительно ускоряет процесс последовательной разработки.
Учитывая тот факт, что время разработчика (особенно если он одиночка) очень ценно, а скорость всего и вся в деле HFT всегда стоит на первом месте, то стоит присмотреться к стеку открытых технологий. Те же Python и R обладают внушительным коммьюнити, и, благодаря своей популярности, хорошо поддерживаются. Кроме того, по ним существует огромное количество документации.
Однако у open source софта часто нет коммерческой поддержки, как в случае проприетарных продуктов, да и работают они на куда менее дружелюбных пользователю интерфейсах. На Linux-сервере вы почти никогда не встретите графический интерфейс управления, все придется делать через консоль. Да и для некоторых задач языки вроде Python и R могут быть слишком медленными. Существуют механизмы для интеграции, например, с C++ для улучшения скорости, но это требует определенного опыта в мультиязычном программировании.
Несмотря на то, что и в мире проприетарного софта можно столкнуться с проблемами при обновлении версий продуктов, все же в случае открытого ПО подобные сложности встречаются куда чаще. В целом, открытые системы администрировать сложнее.
Что есть из коробки
Какие библиотеки содержит язык и насколько онр хороши? Здесь более старые языки имеют преимущество над новичками. C++, Java и Python развиваются далеко не первый год и обладают обширным набором библиотек для сетевого программирования, HTTP, взаимодействий с операционной системой, графическими интерфейсами, библиотеками для регулярных выражений и так далее.
C++ знаменит своей библиотекой STL (Standard Template Library), которая содержит множество высокопроизводительных структур данных. Python известен благодаря своей способности работать практически с любыми типами систем и протоколов (особенно в вебе), через свою собственную стандартную библиотеку. В R есть много статистических и эконометрических встроенных средств, а MatLab отлично подходит для написания кода линейной алгебры (это можно встретить, к примеру, в механизмах оптимизации портфолио и расчетах цен производных инструментов).
Помимо стандартной библиотеки в C++ есть Boost, которая заполняет области, не охваченные STL. Многие части Boost попали и в стандарт TR1, а значит доступны в спецификации C++11, включая нативную поддержку лямбда-выражений и многопоточности.
В Python есть высокопроизводительная комбинация библиотек NumPy/SciPy/Pandas, которая нашла широкое применение в алгоритмической торговли — особенно для исследовательских задач. Существуют и высокопроизводительные плагины для доступа к главным реляционным базам данных, таким как MySQL++ (MySQL/C++), JDBC (Java/MatLab), MySQLdb (MySQL/Python) и psychopg2 (PostgreSQL/Python). Python может даже «общаться» с R через плагин RPy!
Часто упускается из виду и такой аспект торговой системы, как соединение с брокерским API (у нас это SmartCOM — прим. перев.). Большинство API имеют нативную поддержку C++ и Java, но некоторые поддерживают и C# с Python.
Заключение
После всего вышесказанного, очевидно, что выбор языка (-ов) программирования для алгоритмической торговой системы — это отнюдь не такое легкое занятие, и он требует глубокого анализа всей системы. Главные аспекты для анализа включают в себя производительность, простоту разработки, устойчивость и тестирование, разделение интересов, распространенность, поддержку, доступность исходного кода, расходы на лицензирование и устойчивость библиотек для разработки.
Преимуществом разделенной архитектуры является тот факт, что она позволяет «подключать» разные языки программирования для решения конкретных задач, для которых они подходят лучше всего. Торговая система — это постоянно развивающийся и меняющийся проект, на протяжении жизни которого свою лепту может внести практически любой язык программирования.
Прим. перев: замечания по переводу и орфографии принимаются в личных сообщениях. Спасибо за внимание!
Автор: itinvest
