Коллеги из команды ModelOps GlowByte Advanced Analytics написали небольшой пост
🐓🐓🐓 Как и зачем управлять ML-моделями?
(Про кур не спрашивайте, кто не понял тот поймёт🐣)

MLOps - то что захватывает меня последнее время, но у меня много претензий к текущим решениям и продуктам.

Расскажите про ваши открытия и библиотеки, даже если они давно известны, в комментарии к этому посту.

А в четверг будет онлайн-митап. Если у вас нет MLOps или вы уже опытный в этом, подключайтесь посмотреть. Уверен, что будет интересно. А мой коллега, Роман, расскажет про MLOps в Lamoda.

Про правильный ответ на вопрос, есть ли разница между терминами MLOps и ModelOps.
Если конечно можно так говорить, в конце концов это лишь игра определений.

В своих материалах Gartner все таки разделяет эти понятия, область ModelOps более широкая чем MLOps:
“AI model operationalization (ModelOps) is primarily focused on the governance and life cycle management of all AI and decision models (including models based on machine learning, knowledge graphs, rules, optimization, linguistics and agents). In contrast to MLOps, which focuses only on the operationalization of ML models, and AIOps which is AI for IT Operations, ModelOps focuses on the operationalization of all AI and decision models.”
Источник цитаты, а также целый вебинар на эту тему
ModelOps vs MLOps – What’s the difference and why should you care

Кстати, на сайте компании ModelOp достаточно много интересных и полезных ресурсов по теме ModelOps/MLOps:
📄 Статьи
📺 Вебинары
📕 Всевозможные отчеты о состоянии MLOps
❗️ и даже (хороший ход) пример ModelOps RFP Requirements
Чувствую после этого поста придется потом самому и отрабатывать эти требования😅🤦👨‍💻

Ну и еще пара текстов про ModelOps vs MLOps
📌 At last, a way to build artificial intelligence with business results in mind: ModelOps
📌 ModelOps vs. MLOps
📌 И конечно же истина всех истин - Wikipedia🎓🎓🎓

С самого начала становления области анализа данных и его применения для индустриальных задач появилась потребность формализовать подходы аналитики. Результатом стали разнообразные методологии управления процессом, который сейчас приянато называть Data Science.

Например, про такие методологии, как KDD, CRISP-DM SEMMA и их сравнение можно почитать здесь:
📌 Data Science project management methodologies
а еще есть TDSP:
📌 How to run a Data Science Team: TDSP and CRISP Methodologies
и другая экзотика, например, ASUM-DM.

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

А еще полученная методология DS должна вкладываться в методологию проектного управления реализации конечного ML/AI решения. Хороший пример - подход LeanDS:
📌 Гибкое управление DS продуктами

На этой неделе случилась накладка с темой, а потом еще одна накладка с запасной темой, а потом … Ну вы поняли) Поэтому придется импровизировать

Недавно натыкался на такой текст
AI For Business: Myths And Realities
и возникла мысль устроить завтра обсуждение на тему мифы и реальность в ML/DS проектах.

На мой внезапный призыв любезно откликнулся Максим Гончаров (руководитель направления прогнозной и оптимизационной аналитики, GlowByte AA), так что нас уже двое и дискуссии быть)

А с какими мифами ML/DS сталкивались вы?
Пишите в чат и приходите завтра (8 июля) дискутировать, как обычно в 21:00 МСК в голосовом чате.

В этот четверг, 15 июля, в 21:00 МСК нас ждет эпичная битва за Царство ML/DS: R vs. Python💥

В повестке встречи:
🔥 Стоит ли изучать R для DS/ML в 2021?
🔥 Известен такой тезис: “Если ML и AI то Python, если статистика и анализ данных то R”. Попробуем разобраться поподробнее что лучше в каких задачах.
🔥 Действительно ли вопрос стоит как R vs. Python? Или оптимальным вариантом является построение гетерогенной среды, в которой для решения одной задачи используется и Python, и R и даже Julia?
🔥 Какие организационные и технические вызовы возникают в связи с предыдущим пунктом? Как достичь воспроизводимости результатов внутри команды DS и выстроить унифицированные MLOps процессы совместно с IT в условиях такой гетерогенной среды моделирования?

Учатсники дискуссии:
🥷Андрей Макеев, бизнес-архитектор по аналитике, Комус;
🥷Максим Гончаров, руководитель направления прогнозной и оптимизационной аналитики, GlowByte Advanced Analytics;
🥷🥷🥷А также все желающие

Встречаемся, как обычно, здесь в голосовом чате.

Продублирую статью от Ирины в канал
Совмещение R и Python: зачем, когда и как?

Data Warehouse, Data Lake, Data Vault, Data Lakehouse, Data Fabric, Data Mesh, Data Lab, Data Hub, DataOps, Data Governance ... ну и конечно же Big Data=)

В следующий четверг, 22 июля в 21:00 МСК совместно с авторами канала Клуб CDO будем разбираться, что означают все эти слова, и как заложить крепкий фундамент для успешных ML/DS проектов в виде современной Data Management платформы. В повестке встречи следующее:
📌 Эволюция подходов в технологиях построения Data Management систем и методологиях Data Governance.
📌 Плюсы и минус централизации и децентрализации управления корпоративными данными, как обычно будем искать истину где-то посередине)
📌 Технологические аспекты и грани децентрализованной обработки и хранения данных, вспомним про Data Federation и обсудим новомодный Data Fabric.
📌 Как Ops добрался до данных и аналитики: процессы, роли и инструменты DataOps.
📌 Без качественных данных качественную ML модель не построить. Как решается задачи Data Quality с точки зрения современных технологий и методологий.

Наши эксперты-спикеры:
😎 Денис Афанасьев, Head of TechPlatforms в SberDevices, основатель CleverDATA
😎 Дмитрий Инокентьев, Архитектор Data платформ, GlowByte Consulting
😎 Сергей Абрамов, Head of Feature&ML Engineering, GlowByte Advanced Analytics
😎 Дмитрий Бутаков, Архитектор Data&ML платформ GlowByte Advanced Analytics

Встречаемся как всегда в голосовом чате нашего сообщества.

небольшая обхорная статья по теме Federated Learning, не менее популярная сейчас тема чем Data Mesh

https://towardsdatascience.com/federated-learning-a-new-ai-business-model-ec6b4141b1bf

Подборка статей из блога GlowByte от команд практики Data Management

📌 Про кейс DWH в Газпромбанке: Как построить современное аналитическое хранилище данных на базе Cloudera Hadoop
📌 Про гибкие хранилища, а именно, про подходы Data Vault и Anchor Model: Обзор гибких методологий проектирования DWH
📌 Про стриминг на Kafka: Почему стриминг на KSQL и Kafka Streams - это непросто

И еще немного про Data Mesh

Немного мыслей тут родилось про Data Mesh. Тема популярная, все начинают вокруг говорить о том, что они применяют этот подход, реализуют проекты и тд. Тем не менее все время не могу уловить какую “суть” этого подхода, какую то формулировку, которая в простой форме объяснит основное отличие от предыдущих концепций, типа Data Lake и тп. Читаешь статьи, вроде много букв везде, а вот понимание не складывается. И вот проштудировал еще раз основной источник на сайте Мартина Фаулера (см ниже) и вот родилось такое понимание:

Data Mesh в первую очередь это организационная концепция, а не техническая. Она говорит о том, что мы децентрализуем ОТВЕТСТВЕННОСТЬ за данные между разными командами, обеспечивая их нужным (даже централизованным) техническим инструментарием, для того, что бы они эту ответственность могли осуществлять.

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

Реализации этой концепции требует:
⁃ В первую очередь организации изменения - изменения культуры, формирования новых KPI, поддержки со стороны руководства и тд.
⁃ Во вторую очередь процессные изменения - процессы Data Goverence, обеспечивающие “правила игры” общие для всех команд
⁃ В третью очередь технические изменения - нужно эти команды обеспечить технической возможностью выполнять новую функцию (хранить данные обрабатывать), а так же поддержать технически функции типа Data Discovery и прочие из пункта 2. И это очень важно сделать при реализации данного подхода.

И еще раз подчеркну, что технические решения из третьего пункта могут быть вполне себе централизованными Data Lake, если это экономически и технически обосновано.

Вот такие у меня сложились персональные выводы на текущий момент.

https://martinfowler.com/articles/data-monolith-to-mesh.html

В прошлый четверг в экспертной комнате упоминали про Data Mesh в Леруа Мерлен. Небольшая подборка по этой теме.

Про опыт построения Data платформы и путь к Data Mesh - интервью с CDO Леруа Мерлен Дмитрием Шостко:
📌 Data Mesh в «Леруа Мерлен»: DIY в работе с данными

Доклад Дмитрия Шостко на Data Fest 2020:
📺 Как построить Data Mesh в организации

Про архитектурный стек платформы данных в Леруа Мерлен:
1️⃣ Платформа данных в Леруа Мерлен – 2 года, сотни источников и более 2.000 пользователей
2️⃣ Платформа данных в Леруа Мерлен. Part 2. Обновления 2021 года: Flink и Superset



P.S.: А еще про путь к Data Mesh в Dodo Pizza:
🍕 Data Mesh: как работать с данными без монолита

В этот четверг продолжим обсуждать тему управления данными, но в более узком смысле, а именно, поговорим про платформы данных непосредственно для ML/DS и такую тему как Feature Store.

В повестке обсуждения следующие вопросы
❓ Feature Store определяют как интерфейс между моделями и данными. Почему бурный рост интереса к теме наблюдается именно сейчас?
❓ Почему Feature Store - необходимая часть современной ML/MLOps платформы, и как технологии и подходы Feature Store позволяют ускорить продуктивизацию ML/AI решений?
❓ Каталогизация переменных, управление производными переменными, консистентность данных разработки и применения, версионирование датасетов и переменных, операционализация переменных… Какие еще задачи должен решать идеальный Feature Store?
❓ Как выглядит типовая архитектура Feature Store и его место в ML & Data платформе?
❓ Снова про качество данных, как организовать мониторинг переменных и пайплайнов данных для ML?
❓ Рынок решений Feature Store 2021: какие есть инструменты от вендоров и с открытым исходным кодом?

Участники дискуссии:
Команда GlowByte Advanced Analytics
😎 Сергей Абрамов
😎 Михаил Зайцев
😎 Павел Снурницын
И все, кто захочет присоединиться
🧐🧐🧐

Встречаемся 29 июля в 21:00 МСК в голосовом чате сообщества.

Отличная статья от tecton.ai с описанием типового, если так уже можно говорить, Feature Store: What is a Feature Store?

Небольшая выжимка про основные 5 компонентов FS с мыслями и дополнениями:

Storage - компонент отвечающий за управление хранением, я бы добавил что именно управление, потому что хочется иметь возможность гибко хранить датасеты и фичи в различных СХД (в том числе в нескольких одновременно). Одна из самых важных фишек FS - версионировании не только на уровне датасетов, но и на уровне индивидуальных переменных, чтобы когда мы корректировали расчет какого-то атрибута, не приходилось сразу переобучать все десятки моделей в проде которые на него завязаны, это можно делать постепенно.

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

Serving - собственно публикация и внедрение переменных. Важная функция этого компонента: сохранение консистентности переменных между данными обучения и применения моделей, это достигается как раз за счет введения уровня абстракций для алгоритмов формирования фич на уровне FS.
Единственно что, как и со Storage, не очень соглашусь с предлагаемой концепцией о том, что FS именно сёрвит хранящиеся внутри него фичи. С одной стороны это хороший тренд, как раз та самая микросервисная архитектура данных о которой говорили в прошлый четверг, за счет которой достигается консистентность данных. С другой стороны всегда будет возникать потребность именно раскатать расчет фич в отдельно стоящую систему применения, например, в случаях IoT и Edge, а от FS хочется возможности управлять этим процессом для различных систем применения и иметь возможно сравнительно просто добавлять новые адаптеры для новых систем.

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

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


Вообще про Feature Store и его место в платформе данных видится некий локально-глобальный принцип: по сути Feature Store решает задачу Data Governance локально для данных для ML, есть и lineage, и каталог, и качество данных. Также есть и децентрализации управления этими данными, опять же на локальном уровне, участники команды готовят, публикуют и поддерживают фичи каждый в своем домене и сравнительно независимо друг от друга. И тут возникает такая мысль: все таки и задачу DG очень тяжело решить глобально на уровне большой организации, также тяжело реализовать глобально подходы децентрализации, такие как Data Mesh, но эти задачи выглядят вполне обозримо и решаемо в концепции Feature Store, то есть только в части данных для ML/DS, может быть эта та часть платформы данных с которой можно начать этот путь.

Решения класса Feature Store, за которыми мы в команде GlowByte Advanced Analytics активно следим:
🔸 Feast
🔸 Tecton
🔸 Hopsworks
🔸 Rasgo
🔸 Iguazio
🔸 Kaskada
🔸 Amazon SageMaker Feature Store
🔸 dotData, правда в какой-то момент они переобулись в термин AutoFE - Automated Feature Engineering
🔸 Butterfree - фреймворк для разработки FS

11 августа намечается митап по теме ML Data Engineering: apply(meetup), организованный Tecton.ai. Заявленные темы выглядят интересно.