Комментарии 13
Почему у вас Spark в управлении данными, а не во фреймворках?
Spark вы используете активно, но Scala у вас в hold. Пишите на python или java?
both!

В смысле спарк конечно scala и питон. Фундаментально новые вещи на спарке пишутся на питоне. То что scala в hold вовсе не означает что на этом языке вообще нет новых коммитов, но область его применения уже.

На радаре есть и склад, и управление данными и просто расчёты, спарк это больше про данные чем про фреймворки (кажется даже официальный тэглайн это что они «analytics engine», но такого раздела на радаре нет :)
Почему мигрировали с luigi на airflow? И насколько гладко прошло все? Какие видите преимущества?
Нельзя сказать что мы прям мигирировали с luigi, он был не так сильно в инфраструктуре и хотя и использовался, делал это постольку-поскольку. Один из очевидных минусов это то что в luigi было сложнее перезапускать блок зафейленных задач за какой-то промежуток времени в прошлом из-за того что щедулер не является частью системы (ну и то что вроде бы (тут уж не уверен) какое-то время ходили слухи что luigi уже не поддерживается и не развивается и вообще там всё ещё тянется второй питон — вроде бы это всё не подтвердилось и сейчас с проектом всё хорошо). К тому же luigi-комьюинити сильно меньше и общее развитие проекта было под вопросом.

Вообще, astronomer отличный выпуск подкаста с автором luigi делали, советую послушать если вас интересуют детали soundcloud.com/the-airflow-podcast/episode-4-competitors

А про то, почему и как мы используем airflow есть в нашей другой статье: habr.com/ru/company/lamoda/blog/518620
какое-то время ходили слухи что luigi уже не поддерживается и не развивается

Т.е. лучше доверится слухам, чем заглянуть в github проекта?
:) Ваша буквальность восхищает! Нет, не только по слухам. Мы ещё составили расклад по картам Таро и так как это был январь то ещё и святочный расклад у той самой светской ведьмы.

Конечно же (и в моём комменте сообщении это, имхо, считывается) по гитхабу это видно: и поинт про «не подтвердились», и, что важнее, поинт про комьюнити. Если вам удобнее читать список буллетов, у того же астрономер есть небольшая статья на эту тему: www.astronomer.io/guides/airflow-vs-luigi
Roadrunner у нас в качестве эксперимента, в 1 системе на фреймворке Slim. По характеру, приложение — это большое количество довольно простых API, работающих с базой.

Самый главный вопрос, конечно, есть ли увеличение производительности. Достовернее всего было бы сравнить одно и то же приложение на roadrunner и php-fpm, но нам это пока только предстоит. Если грубо и быстро сравнить время ответа этого с сервиса с похожим приложением на php-fpm, то у rr 95-ая персентиль довольно ровно лежит в районе 0.090s, когда как у php-fpm приложения, колеблется в около 0.230s с скачками вверх. Звучит хорошо, но лучше, конечно, сравнивать сравнимое, мало ли почему так.

Из плюсов использования, например, из коробки prometheus-endpoint есть с пачкой метрик о прожорливости и вообще жизнедеятельности сервиса roadrunner.dev/docs/beep-beep-metrics

Из минусов, нельзя использовать stdout для логов, он нужен самому roadrunner для сборки response, приходится изворачиваться github.com/spiral/roadrunner/issues/208, ещё и внутренний механизм логирования не очень-то конфигурируется. Обещают в 2.0 переделать. Приходится дополнительно настраивать dev-режим, он отличается от привычного php-разработчику и поэтому не всем нравится. Ещё на этапе стабилизации смутно помню были какие-то нюансы с передачей правильных header'ов для json.

В общем, технология экзотичная, с нюансами. Справиться с ними можно, но хорошо бы понимать ради чего. Даст ли он для вашего приложения ощутимую производительность и действительно ли она вам нужна.
Если используете SlimPHP — посмотрите в сторону Comet, в который интегрирован Slim:

github.com/gotzmann/comet

Работает без Nginx / RoadRunner и в разы быстрее (бенчмарки в репозитории есть).
А чем гугл клауд не подошел? И для чего Azure, AWS используете?
Гугл клауд вполне себе подошел, мы там сделали отличный полугодовой пилот qa/dev окружения (для понимания масштабов это более сотни жирных инстансов), но по определенным причинам (спасибо ковид) были вынуждены вернуться обратно в онпрем.
В Azure у нас dev окружение нашей ERP MS Dynamics AX.
В AWS у нас есть кусочек прода — сервис, не обеспечивающий сбор персданных, и не сильно завязанный на latency между основным цодом.

Вообще вопрос клауд стратегии — это важная для нас тема.
Нельзя просто так взять и переехать в клауд (с) — думаю если бы в России был представлен хоть один из большой тройки — было бы все куда проще.
Нас волную такие вопросы как:
1. обработка и хранение при сборе персданных на территории РФ — это сложно обеспечить когда в силу специфики работы компонентов нашей платформы мы не можем просто выделить один сервис, отвечающий за сбор ПдН и оставить его в России.
2. latency — мы бьемся за каждую миллисекунду при обмене нашей сотни микросервисов, и к фрагментации по клаудам и онпрем мы пока не сильно готовы — это вызов для нас.
3. гравитация данных — сейчас наше ядро сети пропускает через себя более 120 гбит/сек — кусочки систем между клаудами могут стоить дороже по трафику, чем по compute ресурсам.
4. утилизация нашего онпрем — мы сейчас очень зрелы в нашем онпрем датацентре. миграция в клауд для ее экономической эффективности должна занять не менее срока жизненного цикла последней партии серверов.
Для некоторого бизнеса uptime очень важен, для Lamoda — критически важен.
Сравните SLA Yandex.Cloud и AWS
yandex.ru/legal/cloud_sla_compute
aws.amazon.com/ru/compute/sla

Текущий SLI Lamoda (аптайм онлайн магазина, кнопки «купить») — 99.95% (это 4 часа в год)
Бизнес не готов добавить еще столько же или больше просто за счет переезда в клауд.

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

5 апреля 2011

Местоположение

Россия

Численность

5 001–10 000 человек

Дата регистрации

20 сентября 2018

Блог на Хабре