0.2.1 · блок 0
SQL для ML-инженера
SQL для ML-инженера
Зачем это нужно
Многие признаки живут в реляционных таблицах: пользователи, заказы, события, платежи. ML-инженеру не нужно быть DBA, но нужно уметь безопасно собрать feature query, проверить результат и не прочитать будущее при подготовке данных.
Основные идеи
JOIN соединяет сущности по ключам. Явно выбирайте тип: INNER JOIN оставляет совпавшие строки, LEFT JOIN сохраняет все объекты слева — обычно это важно для клиентов без заказов.
Агрегации создают признаки: COUNT, SUM, AVG, MAX с GROUP BY. Всегда проверяйте grain: одна строка результата должна соответствовать одной сущности, например user_id.
Window functions вычисляют значение в группе, не склеивая строки: row_number(), lag(), sum() over (...). Это удобно для последнего заказа и накопительных метрик.
Транзакции дают согласованное чтение и запись. Не запускайте тяжёлый feature query на production-реплике без лимитов, индексов и согласования с владельцами базы.
Как это выглядит на практике
Признак «сумма завершённых заказов за 30 дней на дату скоринга»:
SELECT
u.user_id,
COALESCE(SUM(o.amount), 0) AS spend_30d
FROM users AS u
LEFT JOIN orders AS o
ON o.user_id = u.user_id
AND o.status = 'completed'
AND o.created_at >= :as_of_date - INTERVAL '30 days'
AND o.created_at < :as_of_date
GROUP BY u.user_id;
Параметр :as_of_date защищает от leakage: для исторической строки мы не используем заказы, появившиеся после момента предсказания.
Что сделать после занятия
- [ ] Напишите
LEFT JOINпользователей и заказов, сохранив пользователей без заказов. - [ ] Добавьте агрегат-признак и проверьте, что строк столько же, сколько пользователей.
- [ ] Сформулируйте, какое условие по времени защищает ваш query от leakage.