3) Вот. Посредством конструктивной дискуссии мы с Вами приближаемся к какому-то консенсусу, который в моем представлении звучит так: пусть за 0.25 секунды произошла продажа 1000 лотов. Да, не видя структуры этой продажи - считаю наивным делать предположения о причинах этой продажи в столь краткий промежуток времени (поэтому этот момент в статье отражен в шутливой форме). Однако - считаю, что это признак локального всплеска активности участников рынка. А вот как интерпретировать этот признак и интерпретировать ли - этот вопрос я оставляю на усмотрение исследователя/читателя.
Сожалею, что мой текст вызвал у вас такую реакцию. Отвечу последовательно: 1) По поводу использования протоколов на моексе- ключевое слово "за деньги". Мне известны тарифы, полагаю они не доступны большинству пользователей физиков. 2) Цель статьи - описание инструментов и подходов к анализу больших данных на примере расчетного фьючерса на нефть. Точка. Мне не интересны спекуляции, распознавание работы маркетмейкеров, айсберги и т.п.; 3) Считаю использование агрегированной информации вполне приемлемым для своих целей. Исхожу из простой мысли - в конкретный момент времени куплен/продан существенный объем. Определение же участников сделок, их количества и прочих деталей в рамках этого объема в этот момент времени - зависит от целей Вашей работы.
Спасибо за ссылку на лекцию. Что касается учета в расчетах факторов что вы описали выше - лично для себя их не рассматриваю, т.к. все эти моменты закладываю в свой риск-менеджмент.
Согласен лишь с тем, что все не просто :) Уверен, что к счастью, т.к. лично мне интересны такие сложные задачи. Что касается Вашего мнения - мне нужно некоторое время для размышления, чтобы конструктивно Вам возразить.
Спасибо большое за Ваш развернутый ответ, сохранил себе. я, в свою очередь, тоже начал с ODBC для выгрузки в Clickhouse. Нашел и установил драйвера. Но в моем случае все осложнилось тем, что у меня кликхаус крутится отдельно на старом компьютере, а Quik - на ноутбуке. В итоге, да грешен, не добил до конца и бросил это мероприятие :) Но в целом - данному этапу "Варианты получения данных из Quik" - можно смело посвятить одну статью точно и то она будет весьма объемной.
Спасибо большое за интересный комментарий, пометил себе Ваши идеи. Что касается ALGOPACK - не знаю как у Вас, но я зарегистрировался в начале января - а доступа так и нет. Хотя именно мосбиржа как первоисточник данных должна диктовать моду. Но что-то у них пока не очень получается.
Отвечу немного в лирическом стиле - потому что в силу объективных обстоятельств большинство из нас в ближайшие годы будет уходить на отечественное ПО ну или opensource как альтернативу или уже перешли. И я пока не вижу аналогов Excel-я с учетом его мощи. Ну точнее вижу, но не считаю их полноценной заменой. Поэтому opensource, извините.
Александр, спасибо большое за полезную информацию, не знал что NiFi и Pentaho разворачиваются так просто. Talend нет, не зашел в свое время, правда пробовал его около двух лет назад.
я описал этот момент, возможно не так подробно. ETL надо разворачивать (ну или они уже должны присутствовать в инфраструктуре), если речь идет о корпоративной сети. Даже если эти системы уже присутствуют и используются - регулярно встречаю ситуацию, когда потребность в добавлении своего дага - это достаточно трудоемкий процесс. Идея проекта - использование ETL - здесь и сейчас. Запустил, внес параметры и работает. Возможно для отладки чего-то серьезного, возможно для выполнения каких-то разовых задач или регулярных задач в течение дня, не более того.
Если Вы не против, я бы прокомментировал Ваши выводы:
Ну, прецеденты с обращением (в том числе и групповым) были, верно ? Когда у нас нефть уходила за -36$, и часть инвесторов позакрывали с огромными убытками и пострадавшие подавали индивидуальные/групповые иски против брокеров. А в суде их разворачивали с простой формулировкой - "брокерский договор это по своей сути - кредитный договор". К сожалению, не могу дать Вам ссылки (прувы), не отслеживал. Но, можно поискать на том же смартлабе.
Вы вполне уместно в этом выводе дважды упомянули термин "игрок". Просто попробуйте подменить термин "рынок" на "казино" и все встанет на свои места :) Прошу прощения, если моя шутка кому-то показалась циничной.
Правила не дырявые. Просто есть ряд факторов которые непрозрачны для физиков. Например внебиржевые сделки. Или то обстоятельство или скажем так "традиция" по которой по расчетным фьючерсам в день экспирации происходит перекладка на дальний фьючерс. Кто-то в надежде что его цели реализуются на текущем фьюче - ждет до последнего дня. Поэтому по ликвидным инструментам срочного рынка (подчеркиваю ликвидным) такой "расколбас" в последний день - вполне обычное явление.
Спасибо за совет. По поводу фронтенда, хотите интересное наблюдение ? Сравните внешний вид AdminLTE и вот например https://coreui.io/
Вам не кажется, что они очень похожи ? Да, оба написаны с использованием bootstrap. И такие родственные интерфейсы встречаю регулярно. Но мне все они не нравятся, т.к. они визуально "не достаточно компактны".
Спасибо, пробовал в свое время этот шаблон. Меня не устроил сам Django, в каком смысле: любой фреймворк задает свои правила игры и в плане расположения папок, структуры проекта и прочее. Где-то больше как в Джанго, где-то меньше как в Flask или в FastAPI. Для примера: попробуйте переделать стандартную админку Джанго ну хотя бы так, чтобы на страницу выводились данные не с одной модели, а с нескольких, не связанных между собой. Я не утверждаю, что это нереально, но это неудобно.
Ааааа, зачем мне Zabbix ? Во-первых zabbix написан на php, а я люблю python. Во вторых разворачивая zabbix я разве получу API-сервис для чего угодно с возможностью авто-документирования ? В третьих - я уже разворачивал zabbix - мне не понравилось, извините :)
Верно, я об этом явно написал в статье. Но: 1) В торговой системе при запуске робота есть возможность ставить «предельное количество в лонг» — ну т.е. предельное число акций, которые робот в принципе может купить. 2) Именно поэтому и нужно тестирование — тесты можно прогнать в периоды, когда было сильное падение цен акций, например 2008 год или март 2020 — и оценить, какими должны быть проценты падения для «дозакупки», чтобы робот «не выел» весь Ваш депозит.
Вау. Признаюсь искренне, мне очень понравился Ваш комментарий. Вы правы, я лишь добавлю как долгие периоды ожидания легко «скрасить», чтобы не наступило разочарование: а) работать по нескольким акциям одновременно б) Хорошо знать акцию(инструмент) с которой работаешь, т.е. не ждать от нее результатов выше среднестатистического.
3) Вот. Посредством конструктивной дискуссии мы с Вами приближаемся к какому-то консенсусу, который в моем представлении звучит так: пусть за 0.25 секунды произошла продажа 1000 лотов. Да, не видя структуры этой продажи - считаю наивным делать предположения о причинах этой продажи в столь краткий промежуток времени (поэтому этот момент в статье отражен в шутливой форме). Однако - считаю, что это признак локального всплеска активности участников рынка. А вот как интерпретировать этот признак и интерпретировать ли - этот вопрос я оставляю на усмотрение исследователя/читателя.
Сожалею, что мой текст вызвал у вас такую реакцию. Отвечу последовательно: 1) По поводу использования протоколов на моексе- ключевое слово "за деньги". Мне известны тарифы, полагаю они не доступны большинству пользователей физиков. 2) Цель статьи - описание инструментов и подходов к анализу больших данных на примере расчетного фьючерса на нефть. Точка. Мне не интересны спекуляции, распознавание работы маркетмейкеров, айсберги и т.п.; 3) Считаю использование агрегированной информации вполне приемлемым для своих целей. Исхожу из простой мысли - в конкретный момент времени куплен/продан существенный объем. Определение же участников сделок, их количества и прочих деталей в рамках этого объема в этот момент времени - зависит от целей Вашей работы.
Спасибо за ссылку на лекцию. Что касается учета в расчетах факторов что вы описали выше - лично для себя их не рассматриваю, т.к. все эти моменты закладываю в свой риск-менеджмент.
Согласен лишь с тем, что все не просто :) Уверен, что к счастью, т.к. лично мне интересны такие сложные задачи. Что касается Вашего мнения - мне нужно некоторое время для размышления, чтобы конструктивно Вам возразить.
Спасибо большое за Ваш развернутый ответ, сохранил себе. я, в свою очередь, тоже начал с ODBC для выгрузки в Clickhouse. Нашел и установил драйвера. Но в моем случае все осложнилось тем, что у меня кликхаус крутится отдельно на старом компьютере, а Quik - на ноутбуке. В итоге, да грешен, не добил до конца и бросил это мероприятие :) Но в целом - данному этапу "Варианты получения данных из Quik" - можно смело посвятить одну статью точно и то она будет весьма объемной.
Спасибо большое за интересный комментарий, пометил себе Ваши идеи. Что касается ALGOPACK - не знаю как у Вас, но я зарегистрировался в начале января - а доступа так и нет. Хотя именно мосбиржа как первоисточник данных должна диктовать моду. Но что-то у них пока не очень получается.
Отвечу немного в лирическом стиле - потому что в силу объективных обстоятельств большинство из нас в ближайшие годы будет уходить на отечественное ПО ну или opensource как альтернативу или уже перешли. И я пока не вижу аналогов Excel-я с учетом его мощи. Ну точнее вижу, но не считаю их полноценной заменой. Поэтому opensource, извините.
Александр, спасибо большое за полезную информацию, не знал что NiFi и Pentaho разворачиваются так просто. Talend нет, не зашел в свое время, правда пробовал его около двух лет назад.
я описал этот момент, возможно не так подробно. ETL надо разворачивать (ну или они уже должны присутствовать в инфраструктуре), если речь идет о корпоративной сети. Даже если эти системы уже присутствуют и используются - регулярно встречаю ситуацию, когда потребность в добавлении своего дага - это достаточно трудоемкий процесс. Идея проекта - использование ETL - здесь и сейчас. Запустил, внес параметры и работает. Возможно для отладки чего-то серьезного, возможно для выполнения каких-то разовых задач или регулярных задач в течение дня, не более того.
я бы как минимум еще DBeaver добавил :) Как говорится "Без бобра - мы ни туда и ни сюда" :)
Если Вы не против, я бы прокомментировал Ваши выводы:
Ну, прецеденты с обращением (в том числе и групповым) были, верно ? Когда у нас нефть уходила за -36$, и часть инвесторов позакрывали с огромными убытками и пострадавшие подавали индивидуальные/групповые иски против брокеров. А в суде их разворачивали с простой формулировкой - "брокерский договор это по своей сути - кредитный договор". К сожалению, не могу дать Вам ссылки (прувы), не отслеживал. Но, можно поискать на том же смартлабе.
Вы вполне уместно в этом выводе дважды упомянули термин "игрок". Просто попробуйте подменить термин "рынок" на "казино" и все встанет на свои места :) Прошу прощения, если моя шутка кому-то показалась циничной.
Правила не дырявые. Просто есть ряд факторов которые непрозрачны для физиков. Например внебиржевые сделки. Или то обстоятельство или скажем так "традиция" по которой по расчетным фьючерсам в день экспирации происходит перекладка на дальний фьючерс. Кто-то в надежде что его цели реализуются на текущем фьюче - ждет до последнего дня. Поэтому по ликвидным инструментам срочного рынка (подчеркиваю ликвидным) такой "расколбас" в последний день - вполне обычное явление.
Без комментариев, извините.
Буду Вам очень признателен, если расставите отступы к примерах кода :)
Написано здорово и очень интересно читать. Но, мало :) Автор пишите еще, у Вас здорово получается!
Согласен с Вами. Но ведь речь идет о шаблоне, ну т.е. о наборе компонентов + необходимый минимум функционала, с которого начинается проект.
Что на Ваш взгляд было бы здорово добавить ?
Спасибо за совет. По поводу фронтенда, хотите интересное наблюдение ? Сравните внешний вид AdminLTE и вот например https://coreui.io/
Вам не кажется, что они очень похожи ? Да, оба написаны с использованием bootstrap. И такие родственные интерфейсы встречаю регулярно. Но мне все они не нравятся, т.к. они визуально "не достаточно компактны".
Спасибо, пробовал в свое время этот шаблон. Меня не устроил сам Django, в каком смысле: любой фреймворк задает свои правила игры и в плане расположения папок, структуры проекта и прочее. Где-то больше как в Джанго, где-то меньше как в Flask или в FastAPI. Для примера: попробуйте переделать стандартную админку Джанго ну хотя бы так, чтобы на страницу выводились данные не с одной модели, а с нескольких, не связанных между собой. Я не утверждаю, что это нереально, но это неудобно.
Ааааа, зачем мне Zabbix ? Во-первых zabbix написан на php, а я люблю python. Во вторых разворачивая zabbix я разве получу API-сервис для чего угодно с возможностью авто-документирования ? В третьих - я уже разворачивал zabbix - мне не понравилось, извините :)