# ML infrastructure V2

Компоненты: model-service, data lake, data lake collector, feature API

## Feature API

GET https://features.rociapi.com/credit-risk/avg_borrow_amount/0x001491b82646d06a6f82e7c1ce4444fa9bdf530c -> 0.123, возвращает значение фич для адреса
- Умеет принимать на вход пачки адресов
- Умеет принимать на вход диапазон по времени from..to
- Разбито по фичам, каждая фича это отдельный модуль, со своими тестами и так далее
- aggregator.py и WEModel.py будут частью этого API
- В нём сидит бизнес логика обработки данных из data lake
- DS team будет запускать его, генерить тренировочные данные
- должен быть быстрый, чтобы генерить 20.000 записей для перетренировки за часы, а не за дни
- Если мы уже на лайве отдаём ответ по фичам для адреса за ~5 секунд, то 20000 адресов это 27 часов в один поток, ну и типа час если в 30 потоков

## Data lake, SQL

- Это по сути наш кэш внешних источников с максимально общей структурой, его должно быть легко перезаполнить.
- Речь примерно о 30GB за год, то есть 100GB если брать с 2020 года. Если я правильно понимаю Сашин анализ, то для BigQeury 12 USD в месяц (1200 за 50TB), надо посчитать для PostgresSQL
- Кто угодно может туда ходить за аналитикой

## Сборщик данных

Data-collector, набор скриптов-пайпалайнов, набирающих данные в data lake

- Периодически дёргает все наши графы-койнгеко, сырые данные оттуда сливаются в самом общем формате в data lake.
- При дозаполнении на новых данных в лейке запускается smoke тест на их консистентность TBD
- Эта часть должна быть настолько же надёжна, насколько внешние источники данных.
- Версионирование этих данных и соответствие версий feature API -- открытый вопрос, субграфы меняются, меняются их схемы, эту тему надо обдумать

## Model service

Сервис, который умеет отдавать модель, то есть по некому инпуту отдавать результат модели. Никакого кода для трансформации данных не содержит, пользуется только feature API

- Endpoint per model version, e.g. model-service/v7/0x12345 -> 4 или model-service/v8/0x12345
- Новая модель релизится на лайв вместе со старой
- После тестов UW переключает эндпойнт со старой модели на новую

Такая архитектура позволит пофазовую миграцию на новую архитектуру. Для каждой фичи в старый ball of mud постепенно будем добавлять вызов feature API. Параллельно будем наполнять data lake данными, нужными для той или иной фичи.

В дальнейшем добавление новых источников данных для фичи или новых фич будет выглядеть так:
- Исследование кандидатов API, создание схемы данных (data-collector)
- Заполнение data lake
- Добавление нового эндпойнта в feature API (для новых фич)
- Тестирование эндпойнта для тренировки модели и на лайве
- Выкатывание на лайв новой версии модели
- Тестирование на лайве всей связки
- Переключение на новую версию в конфигурации UW