Зачем это нужно
Многие признаки живут в реляционных таблицах: пользователи, заказы, события, платежи. 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.