---
# System prepended metadata

title: ML infrastructure V2

---

# 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 

