Структурированный вид здесь https://docs.google.com/document/d/1HWmmtHCSxuxDmkHXk7rrYgwpv6W43F-fA3Jf5fHWQNA/edit?usp=sharing


Название доклада
Переход от легаси к построению своего Feature Store: Активные действия

Описание доклада
Мы хотим рассказать о том, почему решили идти в построение своего решения feature store. Текущий легаси проект содержит большие количество пайплайнов обработки и подготовки данных для моделей, данные используются как для трейна, так и для инференса моделей, а все это хранится в одной бд. Шаги внедрения feature store в нашей команде - как это сделать от плана к проектированию и реализации.


Тезисный план доклада (30 минут, зеленым выделены интересные для обсуждения темы)

2m Предисловие - кто мы и чего хотим
Мы - Домклик команда оценки недвижимости
Хотим - Построить решение которое ускорит разработку наших моделей, добавит прозрачность, качество и надежность в работе с данными.

2m Почему именно feature store
здесь кратко расскажем почему такой выбор - поинты указывающие на то, что нам он нужен: большие пайплайны, много моделей

5m Выбор технологий в нашем случае.
Расскажем про выбор на котором мы остановились - технологии: greenplum, airflow, clickhouse, kafka, dbt, trino, python, postgres, s3, openmetadata, soda)

17m Шаги внедрения feature store в нашей команде - здесь расскажем и покажем какой план и как мы его придерживаемся. Так чтобы не уйти в долгострой и показать первые результаты. Шаги внедрения feature store в нашей команде:
детальный разбор запросов и источников, формирование детального слоя хранилища, проектирование холодного хранилища
- проработка архитектуры пайплайнов
- проектирование концепции горячего хранилища
- доставка данных
- проработка доставки данных в горячее хранилище из холодного
- рефакторинг моделей и переобучение
- внедрение soda с блокирующим этапом
- внедрение каталога данных - openmetadata
- внедрение data lineage и отображение всех наших источников данных
- проектирование метаданных для фичей и feature-sdk для нарезки хранилища
- автогенерация фичей через sdk

4m Вспоминаем как было и что стало - быстрые запросы и высокие латенси при нагрузке в 250 rps, быстрые пайплайны с большим объемом данных