Комментарии 16
При расчётах на Hadoop каждый узел обрабатывает те данные, которые на нём лежат, обмена информацией между узлами практически нет.
Это вам сильно повезло. Попробуйте сделать JOIN, и вы быстро поймете, что такая ситуация — лишь удачный частный случай.
Отлично, что компания готова инвестировать в исследования и эксперименты.
Подскажите, какие SQL решения рассматривали, прежде чем отказаться от их применения?
Много работал с полным логом заявок в свое время на C#. И, для задач бектестинга, тоже приходилось считать множество метрик на стакане за весь день по топ5 ликвидных фьючерсов, причём по много раз подряд, ибо при подборе параметров стратегии, я каждый раз запускал симуляцию заново.
И выходило, что радикальное ускорение дают именно алгоритмические оптимизации и правильная работа с массивами.
Поясню на примере. По одному инструменту день - это последовательность, условно, 10 миллионов уникальных стаканов. Если каждый из них создать, как отдельный объект, то быстро работать не будет, и будет требовать массу RAM. Но, если работать последовательно, держа в памяти один мутабельный объект на один стакан за один день, поочередно в цикле просчитывая метрики, после чего применять изменение согласно логу заявок, и снова считая метрики на нем же, то сразу получаем огромное ускорение. Ряд метрик можно считать итеративно, не пересчитывая все с 0 при приходе новой заявки, а лишь рассчитывая дельту метрики от этой заявки. Тот же стакан можно хранить, не как 2 списка или сортированных объектов, а как массив, где индекс подразумевает price/min_step. Метрики тоже можно аггрегировать на лету в памяти, отдавая готовый аггрегат после дневного прогона.
Интересно, пробовали ли оптимизировать в эту сторону? Из моей памяти, просчитать ряд метрик для каждого стакана за день по топ 5 фьючерсов у меня за меньше минуты, использовав одно ядро.
Добрый день! Да, пробовали. По сути, мы с этого начинали еще на pl/sql - там мы в цикле по логу заявок меняли стакан, рассчитывали метрики и формировали потоки для агрегации. Это работало быстро, но не обеспечивало полный функционал.
Держать весь стакан в RAM. конечно, не надо, но здесь основной вопрос в метриках. Насколько мы поняли, у вас все метрики считались на одном срезе стакана, как у нас в начале проекта. Сейчас у нас ситуация другая: нам проходится держать несколько срезов и работать с ними, не как с потоком. Так что задачки у нас немного разные.
Спасибо за ответ. Интересно. Не знаю полностью Ваших требований, но задачи вида "сравнить текущий стакан со стаканами 100 миллисекунд и 10 секунд назад" тоже решал. Для этого создавал n стаканов и пускал n итераторов по массиву изменений ордер лога и двигал их синхронно. Расскажете чуть больше, интересно, все же, можно ли так извернуться, чтобы разложить бизнес логику в поток, или, реально, приходит момент, когда экономически целесообразнее использовать грубую силу?
А что под капотом у https://cloud.yandex.ru/services/data-proc?
Для Yandex Cloud есть готовые VM-образы с Либерикой https://cloud.yandex.ru/marketplace?type=compute&search=Liberica но там вроде не они
Как Hadoop-кластер помогает нам выполнять триллионы вычислений в день и выводить аналитику на новый уровень