системы и возник вопрос. Я от коммерческого DS далек достаточно, поизучал материал, состряпал CF модель, но не понимаю как принято строить пайплайн. Прогонять ETL в airflow и дальше запускать pipe с R скриптом или как ? Если поделить ссылкой или собственным рассуждением о best practices, то буду рад
не думаю, что на этот вопрос есть универсальный ответ, дело в том, что вы по сути говорите об MLOps и там по хорошему следует определить архитектуру исходя из того какая предметная область и идея использования модели рекомендации ... там вопросов масса... НО, если хочется по-простому т.е. без армии архитекторов и MLOps и также хочется остаться внутри R то рекомендую посмотреть R targets вместо Airflow https://books.ropensci.org/targets/
Меня смущает отсутствие драйвера для многих olap решений и выглядит как написать самому, поэтому я думал на одном стеке сделать весь ETL, а ML уже на другом
ну вам видимо известно какие OLAP решения нужно поддерживать и в каком виде , а следовательно можно это проверить т.е. сделать небольшой дизайн, но честно не очень понимаю зачем в рекомендациях вообще OLAP: модель генерит инференс и вы это отправляете целевой аудитории
Olap как лейк для событий на базе которых и будет cf строится. Дизайн: Абстракция: Нужно построить рекомендационку для заведений на базе user based collaborative filtering. 1. ETL пайплайном строю CSV в котором пользовательским рейтингом будет служить метрика кол-ва посещений, соответственно группирую и перекладываю в CSV в S3 2. С помощью tidyverse либ строю матрицу user item, заполняю нули и ранжирую по кол-вам посещений похожих пользователей и складываю в какое нибудь KV или document хранилище
простой cron очень часто работает на ура.
Похоже у вас модель работает батчем т.е. реал тайма у вас нет и следовательно уже можно смотреть варианты решения задачи попроще, если нет сложной логики подготовки данных , то и targets будет перебор. Опять же судя по использованию CSV и tidyverse объемы не очень значительные, но все таки лучше присмотреться к Arrow/parquet. Возможно, стоит сделать два докер контейнера: на подготовку данных и собственно модель для гибкости(в теории можно по разному готовить разные данные). Можно автоматизировать сборку и деплой на том же GitHub actions. Возможно, стоит инвестировать свое время в валидацию данных на входе и логирование. Также подумать о логике инкрементной загрузки данных из источников потому как полный батч в каждый раз - это не очень кошерно )))
Да. Насчет инкремента тоже думал и есть планы по реализации. Спасибо за помощь. Поизучаю arrow тогда еще и видимо действительно на кроне построю пайплайн для 2 докер контейнеров. 1 подготовит статистику просмотров, другой построит рекомендации )
Для небольших объемов fst быстрее порядка на два если данные все брать
Сам каркас "ETL" вообще может быть крошечным. Вот пример достаточно простой и надежной конструкции: https://t.me/r_in_action/186
Обсуждают сегодня