Кажется на рынке уже давно сформирован список базовых инструментов, которыми должны владеть плюс минус все, дальше уже нужно плясать от специфики задач, которыми человек занимается. Для Recsys ключевым инструментом возможно является implicit, а для NLP hugginface.

Из специфичных для нашей библиотеки могу выделить: statsmodels, optuna, hydra, pytorch-lightning, wandb, black, mypy, isort, flake8, pytest

Ключевые - Hadoop-стэк, особенно Spark. Также Flink, Kafka.
Для задач ML/MLops - CatBoost, TensorFlow, MLflow, Kubeflow. Также используются ClickHouse, Различные решения от Apache - Airflow, Superset, Nifi. Можно также назвать Trino, k8s, Greenplum, Redis.

Сам опенсорс в нашем случае представляет собой стек Python-библиотек, который функционирует без активного взаимодействия с сообществом.

В области глубокого обучения мы используем Torch. Для работы с данными применяются Apache Spark, Greenplum и ArenaData. В машинном обучении мы предпочитаем такие инструменты, как Optuna, LightGBM и CatBoost.

Проприетарный стек (Java / SAS) внутри компании был заменен на open-source на Python в 2013-2014 годах.

В качестве других примеров перехода на опенсорс можно отметить использование Greenplum вместо Teradata и Postgres вместо Oracle.

Для работы с данными мы используем YTsaurus, или, как он называется у нас внутри, — YT. Также, используем свои датасеты и модели, стараясь полагаться на собственные разработки. В рамках коллабораций мы анализируем, как наши модели работают по сравнению с чужими. Это позволяет нам выявить, какие решения показывают лучшие результаты.

Для хранения и обработки данных - обычный Kafka, Hadoop+Trino, Spark, Airflow. Для ML - обычный Python ML стек + PyTorch + Jupyter Hub + ClearML + DVC, для inference - Triton. Рекомендации и поиск написали сами, на Go (отдавать эти наработки в open source пока не планируем, как и внутренний ML Tools).

Ключевыми библиотеками в области машинного обучения являются Scikit-learn, Pandas и NumPy — это стандартный набор инструментов, используемый всеми специалистами. В этот набор также вошли специфичные библиотеки для градиентного бустинга; если раньше в топе находился XGBoost, то сейчас одним из самых популярных является CatBoost. Также везде, где решаются задачи с бустингом, активно используется LightGBM. Стандартом для большинства задач также стали AutoML фреймворки вида TPOT и PyCaret.

Сейчас становится важным добавление интерпретируемости в общий стек, и здесь на помощь приходит библиотека SHAP, которая уже стала стандартом. Также стоит отметить, что в DL-проектах почти всегда используются TensorFlow и PyTorch.

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

Большинство инструментов на виду, от себя могу назвать ключевые PyTorch, TensorFlow и CatBoost. MLOps и LLMOps инструментарий особо не назову, т.к. эти задачи мы решаем пока довольно простыми подходами. Математическое обеспечение - у каждого оно свое, инфраструктура - у каждого своя, где то она уходит в облака (это скорее корпоративный тренд), где-то нет.

Безусловно, среди используемых продуктов выделяются линейка продуктов Яндекса, ClickHouse, продукты Apache. Сейчас наблюдаю тренды на использование Trino. Neo4j тоже регулярно встречается. Многие живут с MongoDB.

Для задач связанных со сбором и анализом данных мы используем PostgreSQL, ClickHouse, Airflow. Это база. Для фронтенда используем качественный фреймворк ant.design, для бэкендов Django/FastAPI. Основную функциональность наших продуктовых решений разрабатываем самостоятельно.

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

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

Бывают и проблемы с пригодностью лицензий для корпоративного применения — так, решая задачу из области компьютерного зрения, пришлось перейти с модели YOLO (AGPL v. 3) на китайский фреймворк MMlab (с лицензией Apache 2.0).

Глобальных проблем нет, за исключением того, что, конечно, было бы хорошо, если бы был профессиональный саппорт. Для одного отдельного открытого продукта мы закупили премиум-поддержку, теперь наши тикеты и PR рассматриваются приоритетно. Раскрою секрет: качественной поддержки не хватает не только у коммерческих решений, но и у открытых. Если разработчики открытых решений будут брать деньги за саппорт, я буду только рад и это поддержу.

Мы сами активно занимаемся внесением тикетов и пулл-реквестов в чужие проекты ― где-то успешно, где-то нет. Если нет, патчим самостоятельно и синхронизируемся с апстримом.

Большинство опенсорс-проектов ориентированы на массовость, что подразумевает средний уровень как проблем, так и масштабов сервисов, а также уровень квалификации разработчиков. В нашей ситуации, как крупной компании, это создает определенные трудности.

Например, мы разработали систему контроля версий, основная задача которой — масштабирование на огромные монорепозитории. Когда мы принимали решение о переходе в опенсорс, у нас возникли сомнения: «Кому это нужно, кроме Яндекса с его обширным репозиторием?» Не каждая компания располагает таким объемом кода, и не все используют монорепозитории в своей модели разработки. В результате многие аспекты нашей системы оказываются избыточными для большинства пользователей.

Кроме того, сотрудничество с другими командами оказывается сложным из-за понятийного разрыва. Мы решаем задачи различного масштаба и типа, что затрудняет взаимодействие.

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

Бывает сложно договориться. Приведу пример: однажды у нас возник вопрос о возможности перехода на Playwright ― это опенсорс-инструмент для визуального тестирования интерфейсов. Мы провели обсуждения с командой Playwright, однако, к сожалению, наши взгляды на сотрудничество не совпали. Им не требовалось то, что было необходимо нам. Например, нам нужно тестировать в более широком диапазоне браузеров, чем это предусмотрено в самой системе Playwright, а также учитывать большой объем и поток изменений, с которыми мы работаем.

Типовые проблемы ― поддержка, обновление, безопасность, интеграция с корпоративными системами аутентификации/авторизации.

Вообще, важнее качество продукта и его зрелость, а не принадлежность к open source.

- Сложность установки (Kats): установка некоторых библиотек может быть затруднительной, что создает дополнительные барьеры для использования.

- Плохая документация (Faiss, PaxML, Praxis): документация этих библиотек оставляет желать лучшего, и разобраться в их работе без чтения исходного кода становится крайне сложно. Для библиотек-биндингов не всегда помогает даже изучение кода.

- Непрозрачность (CatBoost, Ruptures): хотя документация этих библиотек может быть качественной, она часто представлена на слишком высоком уровне абстракции. Это затрудняет понимание нюансов, что может быть критически важным при интеграции и настройке.

- Сложности в поиске ответов на вопросы: на таких платформах, как Stack Overflow или в GitHub Issues, обсуждения и решения проблем в основном сосредоточены вокруг крупных библиотек, что затрудняет поиск информации по менее популярным инструментам.

Поскольку мы сами разрабатываем библиотеку, у нас есть определенный уклон в сторону изучения чужого кода. Благодаря этому в большинстве случаев мы можем самостоятельно решать возникающие проблемы.

Тем не менее, были несколько случаев, когда мы обращались к команде разработки с просьбой внести небольшие изменения, такие как обновление версии зависимости или добавление лицензии. Однако такие ситуации скорее являются исключением, чем правилом.

Сложно обеспечивать кросс-платформенность, поддержку разных версий Python и обратной совместимости

Делать community и платные версии, закрывать код ― плохо. Делать, чтобы его можно было собирать и использовать только с платными «консультациями» ― это зло.

Сообщество библиотеки ETNA активно функционирует в Telegram, где пользователи могут задавать вопросы как по самой библиотеке, так и по временным рядам в целом. Также в этом канале мы анонсируем наши другие активности, такие как релизы, выступления и статьи.

Наша команда не организует семинары, но у нас есть планы по созданию курса на базе нашей библиотеки. Я слышал о курсе по LightAutoML на ODS, который может быть интересен.

Базовые навыки работы с опенсорсом я в основном получал в рамках курсов по машинному обучению и Data Science, где часто рассказывают о различных инструментах. Обычно достаточно изучить документацию и демо-ноутбуки, чтобы начать.

Я сам делал доклад на секции Open Source DataFest и посещал Yandex Open Source Jam. О других активностях не слышал, хотя в рамках PyData и подобных мероприятий проводятся доклады по опенсорсу.

В рамках русскоязычного сообщества было бы полезно внедрить такие форматы:

- Представление своих инструментов: про новые библиотеки от русскоязычного сообщества знают далеко не все даже из профсообщества. Было бы замечательно создать площадку, где можно было бы ознакомиться с этими инструментами. Yandex уже сделал шаг в этом направлении, предложив гранты.

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

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

Тем не менее, у нас есть позитивный опыт научно-исследовательской работы (НИР) с университетами, такими как ИТМО и Сколтех. Мы реализовали проекты (примеры ― SLAMA, GLAMA и PyBoost), которые включают в себя создание туториалов к библиотекам и обучающие курсы. Мы активно привлекаем студентов (и не только) к доработке проектов через НИР, стажировки и практики, что также включает командные проекты. Мотивацией для участия в таких инициативах служат научная деятельность и публикация статей.

Мы также развиваем партнерство с различными компаниями и командами, такими как Intel, JB, Acronyx, Arenadata, ИТМО и Яндекс, что позволяет нам продвигать технологии и расширять сотрудничество.

В России, к сожалению, очень мало опенсорсеров и разработчиков системного программного обеспечения, а также специалистов в области машинного обучения. Примером этой проблемы может служить отсутствие аналогов типовых CAD-решений, таких как SolidWorks, в инженерном ПО.

Мы готовим два курса по опенсорсу: по лицензированию опенсорс-компонентов и по композиционному анализу, про понимание из чего состоит программный продукт. Открытых русскоязычных «курсов про Open Source» я не встречал.

Что касается общества, то можно почитать канал «Open Source Россия», в котором тысяча мнений и все ищут общий язык. В этом отражение мирового опенсорса, это не только российская особенность.

Полезные курсы попадаются на Stepik и подобных платформах. В опенсорсе есть амбассадоры ― например, Никита Соболев, который делал значимые доклады на важные темы, или Денис Петухов, который делится опытом работы с опенсорсом и рассказывает о том, каково это на практике.

Как только появляются мероприятия, я всегда стараюсь их поддерживать ― например, Data Fest от ODS. Мы также занимаемся созданием отчетов по состоянию опенсорсных и активно подключаемся к различным «движухам» в этой области, в том числе в статусе партнеров.

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

В России, в основном, это энтузиазм отдельных сотрудников. Я знаю людей, которые выступают на специализированных конференциях, но в целом ситуация довольно плачевная. Такие инициативы не происходят систематически, и компании зачастую не развивают эти направления.

Я иногда выступаю на конференциях, посвященных теме data science, с основным акцентом на анализе временных рядов и применении методов data science в промышленности.

В России не хватает качественных научных конференций. Те конференции, которые существуют, зачастую ориентированы на студентов, которым нужно выполнить научно-исследовательскую работу, и их уровень оставляет желать лучшего. Также мало технических конференций, аналогичных PyCon. К сожалению, «маркетинговых» мероприятий— гораздо больше. Это может быть связано с тем, что деньги на науку не всегда остаются, а, чтобы создать с нуля и наладить процесс, особенно в науке, надо инвестировать, можно посмотреть на создание Сколтеха и на то, сколько инвестируют в науку топовые международные корпорации.

У нас самих есть курсы про наше Облако, есть курсы для YDB. В рамках летних школ освещаем темы, используем нашу инфраструктуру и делаем базовые курсы.

Не хватает глубоких форматов для опытных специалистов уровня Senior и выше, таких как тематические встречи, митапы по сложным вопросам, кворумы и открытые дискуссии, возможно, для меньшего числа участников. Нам нужны мероприятия, где можно в более живом формате пообщаться с авторами опенсорс-проектов и наладить контакт.

Мы организовали Open Source Jam, но эта тема нишевая, аудитория не так велика. Примеры международных конференций подобного уровня — FOSDEM и Open Source Summit — но, к сожалению, мы их пока не посещали.

Мы участвуем в основном в специализированных конференциях по конкретным технологиям (например, k8s conf), а не общеопенсорсных.

На мой взгляд, Яндекс является абсолютным “чемпионом” в этой области, т.к. кратно (кратно!) больше вкладывается. Я не утверждаю, что остальные не прилагают усилий — работа ведется, и это замечательно. Сбер также вносит значительный вкла - например, их платформа GitVerse является отличным вложением в опенсорс. Кроме того, в этом списке должен быть и GitFlic — самописный сервис, который появился еще до того, как такие решения стали мейнстримом.

За ClickHouse огромное спасибо Алексею Миловидову - это хороший инструмент, создание которого стало возможным именно в недрах Яндекса.

Я предпочитаю делить опенсорс на несколько уровней. На первом уровне находятся крупные проекты-гиганты, такие как ClickHouse, YDB, YTsaurus, Tarantool. На следующем уровне — более простые проекты с относительно небольшими командами разработчиков, но которые уже известны в определенных кругах, например, Testplane. И, наконец, существует так называемый "пушистый хвост опенсорса" — это мелкие опенсорсные проекты, которые, несмотря на свою скромность, имеют свою ценность и значимость. Они могут быть популярны и широко известны в узких сообществах, как, например, проект Типограф.

Хорошим критерием успешности является известность решений — многие инструменты, такие как CatBoost, ClickHouse, DataLens и LightAutoML, широко известны и активно используются в проектах. Однако на данный момент среди российских компаний сложно найти достаточное число претендентов, которые могли бы соперничать в контексте решений для машинного обучения и анализа данных. В основном используются “международные” решения.

На мой взгляд, Яндекс является абсолютным “чемпионом” в этой области, т.к. кратно (кратно!) больше вкладывается. Я не утверждаю, что остальные не прилагают усилий — работа ведется, и это замечательно. Сбер также вносит значительный вкла - например, их платформа GitVerse является отличным вложением в опенсорс. Кроме того, в этом списке должен быть и GitFlic — самописный сервис, который появился еще до того, как такие решения стали мейнстримом.

За ClickHouse огромное спасибо Алексею Миловидову - это хороший инструмент, создание которого стало возможным именно в недрах Яндекса.

Университеты во многом являются самой доминирующей силой в наукоёмком опенсорсе на российском рынке. В топ-5 входят ИТМО, Иннополис, Физтех, МФТИ и Сколтех.

Что касается корпоративного сектора, то Сбер заметно выделяется. Также в этой области активно участвует Т-банк. В сфере промышленности можно было упомянуть ГПН, но они уже сократили участие в открытых проектах, хотя раньше были довольно активны. Яндекс с CatBoost, безусловно, занимает одну из лидирующих позиций. ClickHouse также стал стандартом в стеке.

Компании, такие как Норникель, Полюс, Росатом и другие, никогда не выкладывают свои специфические продукты в опенсорс. В основном, это либо небольшие проекты от энтузиастов, либо неясные инициативы, которые представляют собой каплю в море.

Могу отметить ClickHouse - широко используется и является, стандартом в отрасли для решения специализированных задач.

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

Мы значительно отстаем в разработке собственных решений — известные российские разработки в области машинного обучения и анализа данных можно пересчитать по пальцам одной руки. Это, похоже, связано с тем, что мы привыкли использовать уже готовые решения, как закрытые, так и открытые, и у нас не хватает времени на создание сложных внутренних разработок, которые затем можно было бы выложить в опенсорс.

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

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

Существующие инициативы завязаны на конкретных людях. Поддержка исходит от верхнего и среднего звена, а также от отдельных техноэнтузиастов. Команды небольшие, и проблема заключается в отсутствии системы — все держится на горстке энтузиастов.

Такие компании, как Amazon, могут пользоваться решениями сотен, а то и тысяч организаций. В России же наблюдается тенденция: "не хотим использовать чужое, будем делать свое". Вместо того чтобы выделять ресурсы на стартапы, компании предпочитают разрабатывать собственные решения.

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

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

Также, мощные облачные платформы и маркетплейсы предоставляют разработчикам опенсорсного программного обеспечения возможность напрямую выйти к конечным потребителям.

Необходимо стимулировать развитие облачных сервисов для конечных пользователей. Это позволит компаниям и командам сотрудничать с аналогами AWS или Azure для машинного обучения, поставляя опенсорсные компоненты и предлагая их на продажу.

В настоящее время у нас отсутствуют полные "цепочки" создания открытого программного обеспечения, что затрудняет его развитие и внедрение.

На мой взгляд, опенсорс переживает настоящий ренессанс. Если 15 лет назад мы наблюдали подъем и воодушевление, затем последовал спад, вызванный трудностями, связанными с взаимодействием с пользователями, обработкой пулл-реквестов и объемом работы, то в последние годы мы видим осознанную любовь к этой сфере. Несмотря на существующие недостатки, плюсы также очевидны, и люди продолжают активно заниматься опенсорсом. Появились новые силы, и теперь подход к этой деятельности стал более зрелым и продуманным, без розовых очков.

В целом, в России есть все необходимое: большое количество русскоязычных специалистов, открытые сообщества, успешные кейсы создания топовых опенсорсных библиотек. Однако в области машинного обучения, особенно в промышленности, все еще отсутствует системность. Существуют лишь несколько объединений и консорциумов, и в этой сфере очень мало людей. Опенсорсом в промышленности занимаются в основном ИТМО, Сколтех, немного Иннополис и AIRI. Проблема заключается в нехватке финансирования и мер поддержки, заинтересованных кадров и качественного образования в данной области. В итоге, только отдельные группы и энтузиасты продолжают развивать эту тему.

В целом, вся Open Source среда - токсичненькая. Наша не исключение ;). Есть отдельные островки разума, а есть прямо и просветления. Вот и Яндекс тоже молодцы, но суммарно у нас пока ещё нет какой-то большой среды (даже экосистемы!), все по островкам сидят. Очень надеюсь на то, такая площадка в скором времени появится.

Я активно выступаю за создание нормальной площадки с адекватным спонсорством и диалогом, где будет понимание различий между корпоративным и частным опенсорсом. Компании зачастую не выкладывают свои ключевые разработки в открытый доступ.

При этом опенсорс — это глобальное явление, принадлежащее всему миру, и говорить о “российском опенсорсе” смысла нет.

Главная проблема опен-сорса в России - это отсутствие инфраструктуры для "проектов среднего размера". Компании радостно вкладываются во что-то большое и международное вроде Postgres. Маленькие проекты, которые делаются одним человеком хорошо растут силами отдельных разработчиков и студентов. А вот средние проекты, которые требуют команды в 3-4 человека, делать особенно негде. В Европе и Америке с этим справляются фонды вроде Apache и Eclipse, но в России ничего похожего нет. Роль таких фондов могли бы играть вузы, но даже в ведущих вузах финансирование опен-сорса крайне низкое.

Внутри компании мы используем GitLab, но в основном для внутренней разработки. На данный момент мы не рассматривали альтернативы GitHub для опенсорса. Вероятнее всего, мы займемся этим вопросом, когда возникнет острая необходимость и появится ясное понимание, какая платформа может стать нашей следующей флагманской.

Нет - уход от GitHub-а скорее обременение, снижающие эффективность.

В нашей компании мы активно используем GitLab для всей внутренней разработки, и это стало своего рода стандартом. Если говорить об опенсорсе, которым я пользуюсь, то 99% проектов размещены на GitHub. У Atlassian есть Bitbucket, и некоторое время я пользовался этой платформой, но в целом видел лишь несколько публичных проектов на GitLab. Подавляющее большинство находится именно на GitHub.