Статьи

Базы данных для алготрейдинга

Подробности
Категория: Алготрейдинг

Работа с базами данных в количественном/алгоритмическом трейдинге. Виды данных на финансовых рынках. Получение, хранение, очистка и экспорт. Ключевые IT-продукты, интернет-ресурсы и термины. Адаптированный перевод[1] статьи “Securities Master Databases for Algorithmic Trading”.

 

Содержание:

  1. Хранилище плоских файлов (Flat-File Storage)
  2. Хранилище документов / NoSQL
  3. Системы управления реляционными базами данных (RDBMS)

      Краткое резюме по системам хранения данных

 

Предисловие переводчика

Материал продолжает серию публикаций ресурса Quantstart по инструментарию, стратегиям, математической и IT-составляющей алгоритмического трейдинга.

В этом цикле смотрите:

Тема данной статьи - базы данных в алгоритмической торговле.

Базы данных в трейдинге затрагиваются в следующих постах Rusforexclub:

и в ряде других.

 

Введение

<Изложение по тексту - от первого лица>

Главное внимание в алгоритмической торговле направлено на компонент альфа-модели полной торговой системы. Она генерирует торговые сигналы до их фильтрации с помощью модулей управления рисками или построения портфеля. 

Перед запуском торговой системы на реальном счете алготрейдеры тратят немало времени на доводку альфа-модели для выхода на достойный коэффициент Шарпа.

Однако альфа-модель хороша ровно настолько, насколько хороши передаваемые в нее данные. Концепцию емко резюмирует старая поговорка в информатике: “мусор на входе, мусор на выходе”. Крайне важно, чтобы альфа-модель использовала точные и актуальные данные. Если это не так, то результаты будут в лучшем случае плохими, а в худшем - очень плохими, и большие потери в “боевых условиях” неизбежны.

В публикации я хочу обсудить вопросы, связанные с получением и обработкой корректных данных для тестирования алгоритмической стратегии и механизма выполнения торговых операций. Мы изучим, как получать, очищать, хранить и экспортировать финансовые данные. 

СУБД (система управления базами данных) в финансовой индустрии именуется Securities Master Database - “Основные базы данных по ценным бумагам”[2]. 

<В дальнейшем по тексту, может применяться краткая запись термина - “основные базы данных”>[3].

 

Что такое “Основные базы данных” (Securities Master)?

Securities Master Database - структурированная база данных, где хранятся фундаментальная, ценовая <котировочная> и транзакционная информация по различным финансовым инструментам в разрезе классов активов. В инвестбанке/хедж-фонде она используется службами риск-менеджмента, клиринга, трейдинга и иными подразделениями.

Ниже приведен (неполный) перечень инструментов <версия автора>, данные по которым представляют интерес для участников финансовых рынков:

В крупных компаниях основные базы данных сопровождаются отдельной группой специалистов, обеспечивающих их высокую доступность (High Availability).

На розничном уровне или в неглобальном фонде Securities Master устроен намного проще. В то время как массивные Securities Master применяют дорогие корпоративные базы данных и системы анализа, стандартное программное обеспечение с открытым исходным кодом вполне способно вывести на сопоставимые уровни функциональности при условии хорошей оптимизации системы.

 

Какие наборы данных используются?

Для розничного алгоритмического трейдера или небольшого количественного фонда наиболее востребованными наборами данных являются исторические цены на конец и внутри дня на акции, индексы, фьючерсы (прежде всего, на товары или фиксированный доход) и иностранную валюту (форекс). Чтобы упростить обсуждение, мы сосредоточимся исключительно на данных по концу дня (End-Of-Day, EOD) для акций, ETF и фондовых индексов. 

EOD по акциям получить легко. Ряд сервисов предоставляют бесплатный доступ через веб-API:

Вручную загрузить информацию по отдельным ценным бумагам нетрудно, но при значительных ежедневных объемах скачивания, процедура отнимет много времени. 

Ключевая опция Securities Master - автоматическое обновление данных.

Важный момент - глубина ретроспективы (Look-Back Period). Насколько далеко в прошлое необходимо заходить в поиске сведений? Это зависит от вашей торговой методики, но есть и общие правила. Например, смена нормативного режима, периоды высокой/низкой волатильности и другие долгосрочные рыночные тенденции. Так, стратегия следования за трендом / моментум была хороша в 2000-03 и 2007-09 гг., но в 2003-07 и с 2009 г. <на дату подготовки исходного материала> ее последователям пришлось бы несладко. 

Мой совет - получить побольше данных, особенно EOD, хранение которых дешево. Нет надобности использовать данные вашего Securities Master все и сразу. Широкие массивы баз данных требуют время на обработку. Но, обычно, преимущество внушительного количества точек выборки перевешивают любые проблемы с производительностью.

Будьте внимательным к таким вещам, как экстремально неправильные высокие/низкие цены <выбросы, флуктуации цены> или “систематическая ошибка выжившего” (Survivorship Bias)[6].

 

Что применяется для хранения данных?

Выделяют три ключевых способа хранения финансовых данных. Все они обладают разной степенью доступа, производительности и структурных характеристик.

1. Хранилище плоских файлов (Flat-File Storage)

Наиболее доступный метод хранения финансовых данных, поддерживаемый почти всеми поставщиками - формат плоских файлов (Flat-File Format). Он использует запись Comma-Separated Variable (CSV) - данные разделяются запятой. Двумерная матрица значений представляется в виде серии строк с данными столбца, разделенными запятой (иногда табуляцией[7] или точкой с запятой). Для данных о ценах EOD каждая строка - торговый день по OHLC (Open, High, Low and Close), цены на открытии, максимум, минимум и на закрытии таймфрейма (торгового дня).

Достоинство плоских файлов - простота и способность сильно сжиматься для архивирования или загрузки. Основные минусы - нет опции запросов и низкая производительность при итерации больших наборов данных. SQLite и Excel несколько смягчают трудности, предоставляя определенные возможности по запросам.

2. Хранилище документов / NoSQL

Хранилища документов / базы данных NoSQL (Not only SQL) не новая концепция, но в последние годы они стали очень известными благодаря применению в Google, Facebook и Twitter. Они отличаются от реляционных СУБД (RDBMS) отсутствием схем таблиц. Вместо этого есть коллекции и документы, являющиеся ближайшими аналогами таблиц и записей соответственно. Обсуждение обширной таксономии[8] хранилищ документов выходит за рамки данной статьи. Перечислим лишь MongoDB, Cassandra и CouchDB.

Хранилища документов в финансовых приложениях подходят преимущественно для фундаментальных или метаданных[9]. Фундаментальная информация о финансовых активах формируется в разных видах - корпоративные действия, отчеты о прибылях и убытках, отчеты в SEC и т.д. Сюда хорошо вписывается бессхемный характер NoSQL. Однако, NoSQL плохо спроектированы для временных рядов, в частности, по данным о ценах с высоким разрешением, и рассматривать их глубже мы не будем.

3. Системы управления реляционными базами данных (RDBMS)

Система управления реляционными базами данных (RDBMS) задействует реляционную модель[10] хранения данных. RDBMS “любят” финансовые данные, поскольку различные “объекты” (биржи, источники данных, цены) могут быть разделены на связанные между собой таблицы.

RDBMS использует язык структурированных запросов (Structured Query Language, SQL) для генерирования сложных запросов к финансовым данным. Примеры RDBMS - Oracle, MySQL, SQLServer и PostgreSQL.

Плюсы RDBMS - быстрота установки, независимость от платформы, легкость запросов, интеграция с основным программным обеспечением для тестирования на исторических данных и широкие возможности высокой производительности (хотя некоторые утверждают, что последнее не так!). 

Недостатки нередко связаны со сложностью настройки и трудностями достижения указанной производительности без базовых знаний о функционировании RDBMS. Кроме того, им присущи полужесткие схемы, поэтому данные часто приходится под них модифицировать. Минус RDBMS относительно NoSQL, где подобных схем нет.

Краткое резюме по системам хранения данных

Я рекомендую MySQL. Он бесплатный, с открытым исходным кодом, кроссплатформенный[11] (Cross-Platform), очень надежный и c хорошо задокументированным масштабируемым режимом. Разумный выбор для количественной торговли.

 

Как структурированы исторические данные?

Информатика уделяет большое внимание исследованиям в области оптимального проектирования хранилищ данных.Мы не будем вдаваться в подробности - в них несложно и заблудиться! Вместо этого я обрисую рамочную процедуру создания основных баз данных по акциям, настраиваемый с учетом ваших предпочтений.

Первая задача - наметить главные элементы финансовой информации, которые, в конечном итоге, будут отображаться в таблицах баз данных. 

Для Securities Master по акциям я выделяю следующее:

  • Какая биржа / торговая площадка выступает первичным источником данных.
  • Поставщик/продавец торговых данных.
  • Инструмент/тикер - символ акции или индекса, а также корпоративная информация выбранной компании или ETF.
  • Цена - фактическая цена ценной бумаги в тот или иной день <EOD>.
  • Корпоративные действия - список всех сплитов (дроблений) акций и выплат дивидендов по ним, корректирующие рыночные цены.
  • Перечень национальных праздников для вычленения неторговых дней.

Как ни покажется странным, но с хранением канонических тикеров бывают проблемы. Ручаюсь собственным опытом работы в хедж-фонде! Разные поставщики используют различные методы определения тикеров. Для точности необходимо комбинировать несколько источников. 

Компании объявляют банкротство, становятся объектами слияний и поглощений. Старые тикеры меняются на новые или уходят вообще. Возможно обращение нескольких классов (видов) акций под одним символом.

Неприятности не возникают, когда трейдер работает с акциями, входящими в корзины ведущих фондовых индексов - S&P 500, промышленного индекса Доу Джонса (DJIA) и др.

 

Как оценивается точность данных?

Исторические данные о ценах, увы, могут страдать большим количеством ошибок.

Причин множество, в том числе:

  • Корпоративные действия - неправильная обработка сплита акций и учета дивидендов <смотрите выше>. 
  • Пики (выбросы) - точки ценообразования, значительно превышающие определенные исторические уровни волатильности. Здесь нужно проявлять осторожность, сумасшедшие всплески иногда действительно случаются - смотрите 2010 Flash Crash. Скачки также могут вызываться игнорированием сплитов акций. Тут вам поможет Spike Filter.
  • Агрегация OHLC. Бесплатные данные OHLC от Yahoo/Google особенно подвержены проблеме “плохой агрегации тиков”, когда малые биржи обрабатывают небольшие сделки, цены по которым существенно отличаются от “основных” биржевых цен внутри дня. И после агрегирования максимумы/минимумы искажаются. Это не “ошибка” как таковая, а скорее “узкое место”, и к нему следует относиться с осторожностью.
  • Пропущенные данные. Причины пробелов в информации - отсутствие сделок в конкретный период времени (не редкость для секундных и минутных таймфреймов по неликвидным акциям компаний с малой капитализацией), праздничные дни или ошибка в ​​системе обмена. Пропущенные данные могут быть дополнены (заполнены предыдущим значением, интерполированы линейно или как-то иначе) или проигнорированы, в зависимости от торговой системы.

К сожалению, многие подобные нестыковки надо устранять вручную. Уведомление о них можно автоматизировать, но автоматизировать их устранение намного сложнее. Например, как выбрать порог для выбросов - сколько стандартных отклонений использовать и за какой период ретроспективного анализа? Слишком высокое стандартное отклонение пропустит некоторые всплески, а слишком низкое и необычные новости приведут к ложным срабатываниям. Количественный трейдер должен заранее определиться, что делать.

Необходимо решить, что делать с ошибками. Исправлять ли их немедленно, как только они становятся известны, и если да, вести ли контрольный журнал? Если да - потребуется дополнительная таблица в БД. 

Это подводит нас к теме обратного заполнения (Back-Filling), особо коварной при тестировании на исторических данных. Имеется в виду автоматическое исправление неверных данных в восходящем направлении (upstream). Предположим, поставщик данных вдруг исправляет историческую ошибку (ошибки), а ваша торговая стратегия отлажена под набор старых (неисправленных) значений.

 

Как автоматизированы процессы?

Преимущество написания программных сценариев для загрузки, хранения и очистки данных заключается в том, что они автоматизируются инструментами операционных систем. В ОС на основе UNIX (таких как Mac OSX или Linux) можно использовать crontab, позволяющий исполнять необходимые сценарии в определенное время или через фиксированные промежутки времени. В MS Windows за подобную функцию отвечает Планировщик заданий (Task Scheduler).

Например, значения S&P 500 автоматически загружаются сразу, едва они публикуются у поставщика данных. Запускаются скрипты фильтрации недостающих данных и всплесков, с уведомлением трейдера по электронной почте или по прочим каналам. На данном этапе любые инструменты тестирования на истории получают доступ к последним данным, трейдеру не нужно и пальцем шевельнуть! В зависимости от того, где расположена ваша торговая система - на рабочем столе или на удаленном сервере, вы выбираете частично или полностью автоматизированный процесс для выполнения этих задач.

 

Как данные передаются во внешнее программное обеспечение?

Как только данные будут автоматически обновлены и сохранены в RDBMS, их надо загрузить в программное обеспечение для проверки на истории. Процедура во многом зависит от того, как установлена база данных и является ли ваша торговая система локальной (на настольном компьютере) или удаленной (с совмещенным сервером обмена).

Очень важно свести к минимуму чрезмерный ввод/вывод (Input/Output, I/O). Он может стать дорогим удовольствием как с точки зрения времени, так и денег (на удаленном подключении). Лучший способ решить проблему - перемещать данные через сетевое соединение (посредством выборочного запроса) или экспортировать и сжимать информацию.

Многие RDBMS поддерживают технологию репликации, позволяющую (с некой задержкой) клонировать базу данных в другую удаленную систему. В зависимости от настроек и количества информации задержка составляет порядка минут или секунд. Представляется логичным реплицировать удаленную базу данных на локальный рабочий стол. Однако имейте в виду, что возникнут трудности с синхронизацией, а преодоление их требует времени!

 

MySQL и MS SQLServer

Если вы используете MySQL, то для подключения к базе данных и запросов к ней  применяйте язык сценариев с открытым исходным кодом, допустим, Python (через библиотеку MySQLdb или SQLAlchemy ORM) 

Более поздние библиотеки анализа данных, типа pandas, дают прямой доступ к MySQL.

Можно задействовать C++, C #, Matlab с подключением к MySQL через ODBC (Open Database Connectivity). 

SQLServer предназначен для простого подключения к языкам MS.NET, таким как C # и Visual Basic, через LINQ ORM. Вы также можете подключиться к SQLServer с помощью Python через pyODBC.

 

перевод, обработка, комментарии и примечания

 Владимир Наливайский

 

В основе изложения статья “Securities Master Databases for Algorithmic Trading”, опубликованная на сайте Quantstart.

Источник изображения на заставке - статья “Что такое дамп базы данных и как его создать”, И. Смолин, 02.10.2020, Timeweb.com

Первоисточниками определений, терминов, понятий, явлений, вводимых по тексту, являются профильные статьи Википедии/Wikipedia, указанные в Списке источников к публикации (для переводов - возможны трактовки автора исходного материала), если не оговорено иное.

Примечания

  1. Под адаптированным переводом понимается достаточно точное следование исходному материалу, с возможными отступлениями и пояснениями.  Конкретные вещи - формулы, скрипты, графики и пр. (а также авторские комментарии к ним) изложены максимально близко к оригиналу (часто скопированы). Ответственность за их корректность и ясность интерпретации несет автор исходника. 
  2. Несмотря на свою “ценнобумажную” (securities) направленность, термин Securities Master распространяют на торговые данные по любым финансовым инструментам, в том числе (кроме акций и облигаций), на валютные пары, процентные ставки, деривативы и пр.
  3. Записью <курсив> обозначены вставки и комментарии переводчика.
  4. Дериватив на процентные ставки, смотрите источник 1.
  5. На дату подготовки материала QuantQuote не обновляет свои базы. Последняя дата обновления 31.12.2020.
  6. Систематическая ошибка выжившего (Survivorship Bias) - разновидность систематической ошибки отбора, когда по одной группе объектов (“выжившим”) данных много, а по другой (“погибшим”) - практически нет. В результате исследователи пытаются искать общие черты среди “выживших” и упускают из вида, что не менее важная информация скрывается среди “погибших”. Смотрите источник 2.
  7. Табуляция при разделении данных - формат TSV. Смотрите источник 3.
  8. Таксономия - учение о принципах и практике классификации и систематизации сложноорганизованных иерархически соотносящихся сущностей. Смотрите источник 5.
  9. Метаданные - информация о другой информации, или данные, относящиеся к дополнительной информации о содержимом или объекте. Метаданные раскрывают сведения о признаках и свойствах, характеризующих какие-либо сущности, позволяющие автоматически искать и управлять ими в больших информационных потоках. Смотрите источник 6.
  10. Реляционная модель данных (РМД) - логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики, как теория множеств и логика первого порядка. Подробнее смотрите источник 7.
  11. Кроссплатформенность (межплатформенность) - способность программного обеспечения работать с несколькими аппаратными платформами или операционными системами. Смотрите источник 8.

 

Список источников (Википедия/Wikipedia, если не оговорено иное)

  1. “Interest rate cap and floor”.
  2. “Систематическая ошибка выжившего”.
  3. “CSV” (русс.)
  4. “NoSQL” (русс.)
  5. “Таксономия”.
  6. “Метаданные”.
  7. “Реляционная модель данных”.
  8. “Кроссплатформенность”.
  9. “Open Database Connectivity”.

Используемые сокращения

API - Application Programming Interface, программный интерфейс подключения приложений

EOD - End-Of-Day, аббревиатура, применяемая для обозначения цены финансового инструмента на конец торгового дня

ETF - Exchange Traded Fund, биржевой инвестиционный фонд

OHLC - Open, High, Low and Close, аббревиатура, применяемая для обозначения цен фининструмента на открытии, максимум, минимум, и на закрытии торгового дня

RDBMS - Relational DataBase Management System, система управления реляционными базами данных

SEC  - The United States Securities and Exchange Commission, Комиссия по ценным бумагам и биржам США

SQL - Structured Query Language, язык структурированных запросов

ОС - операционная система

СУБД - система управления базами данных