Как упражнение - звучит прикольно, но прикладного смысла примерно 0. Во-первых, потому что фондовые рынки - эффективны, а значит что таких умников чуть больше чем дофига, т.е возможности для арбитража схлопываются (даже если на каком то промежутке удалось получить сверхприбыль, в долгосроке этого сделать не получится). Если обратите внимание, то серьёзные кванты в основном заняты низкоуровневыми языками и размещением дата центров поближе к бирже, чтобы снижать latency т.е буквально борются за миллисекунды.
Но в общем и целом, может быть прикольным дополнением, если прибавить больше знаний доменной области.
В долгосрочной перспективе - это еще одно внутреннее легаси, плюс люди остаются без релевантного опыта работы с DBT.
Если написать SQL-код на 10К строк для итоговой таблицы с 400 колонками - ну т.е сейчас они эти аннотации так же руками пишут ? В дбт есть копайлот который помогает аннотации писать
Это просто дублирование того, что уже написано. Чем аннотация SQL настолько принципиально отличается от аннотаций yaml файла? Типа вы собственный "фреймворк" делали только чтобы аннотации в другом месте /виде были? Почему человеко-часы были потрачены на какие то костыли, когда решение уже существовало?
Зачем нужен ваш фреймворк если , dbt работает со Spark и с Clickhouse? Важные отличия вообще неубедительно звучат. По факту изобретения велосипеда, вместо использования готовых продуктов и современного стека , где люди решили эту задачу в общем виде. А тесты ваш фреймворк тоже гоняет?
А это как это преподносилось бизнесу? Типа смотрите какое мы ноу хау сделали?
Статья довольно баянистая, хотя мне данная иллюстрация нравится) мне кажется стоило добавить оценку погрешности , обычно такое рассматривается в численных методах
У нас в универе один парень, парсил новости для построения предсказательной модели для ценных бумаг на основе текстовой информации.Он затем создавал словарь, где тем или иным терминам ставились положительне или отрицательные значения, как вариант, можно применить и в таком случае, на мой взгляд. (Впрочем тот парень тоже не добился предсказательной точности, но там и характер данных другой).
Как упражнение - звучит прикольно, но прикладного смысла примерно 0. Во-первых, потому что фондовые рынки - эффективны, а значит что таких умников чуть больше чем дофига, т.е возможности для арбитража схлопываются (даже если на каком то промежутке удалось получить сверхприбыль, в долгосроке этого сделать не получится). Если обратите внимание, то серьёзные кванты в основном заняты низкоуровневыми языками и размещением дата центров поближе к бирже, чтобы снижать latency т.е буквально борются за миллисекунды.
Но в общем и целом, может быть прикольным дополнением, если прибавить больше знаний доменной области.
Это лукавство да и не проверить никак со стороны, такого рода легаси деградируют в долгосроке. По факту функционал DBT просто под ковёр загнали
1)Кто владеет парсером ?
2)Вы не упростили систему — вы заменили стандартный стек на внутренний , увеличив платформенный долг и стоимость поддержки.
В долгосрочной перспективе - это еще одно внутреннее легаси, плюс люди остаются без релевантного опыта работы с DBT.
Если написать SQL-код на 10К строк для итоговой таблицы с 400 колонками - ну т.е сейчас они эти аннотации так же руками пишут ? В дбт есть копайлот который помогает аннотации писать
Это просто дублирование того, что уже написано. Чем аннотация SQL настолько принципиально отличается от аннотаций yaml файла? Типа вы собственный "фреймворк" делали только чтобы аннотации в другом месте /виде были? Почему человеко-часы были потрачены на какие то костыли, когда решение уже существовало?
Зачем нужен ваш фреймворк если , dbt работает со Spark и с Clickhouse? Важные отличия вообще неубедительно звучат. По факту изобретения велосипеда, вместо использования готовых продуктов и современного стека , где люди решили эту задачу в общем виде. А тесты ваш фреймворк тоже гоняет?
А это как это преподносилось бизнесу? Типа смотрите какое мы ноу хау сделали?
Это прекрасно , но где мой капучино в конце концов?
Пробежал по диагонали, спасибо за свежие мысли относительно того, как можно монетизировать свои навыки)
Что то чтение Кунта и Таненбаума тут как то обесценили, типа ты можешь прочитать всего Кунта и Таненбаума - нет не можешь)
Во-вторых, сложность ИТ как раз в том, что ты постоянно вынужден впитывать в себя новые знания и технологии , чтобы оставаться на плаву.
Статья довольно баянистая, хотя мне данная иллюстрация нравится) мне кажется стоило добавить оценку погрешности , обычно такое рассматривается в численных методах