Инженерная задача на надёжность пайплайна. Каждый час забираем события заказов из внешнего API и грузим в таблицу-хранилище. Проблема: API иногда отдаёт одно и то же событие дважды (at-least-once доставка), а пайплайн может перезапуститься и повторно обработать батч. Нужно, чтобы повторная загрузка не создавала дублей и не ломала агрегаты. Опиши, как сделать загрузку идемпотентной.
Целевая таблица `orders_fact`:
| order_id | status | amount | updated_at |
|----------|----------|--------|---------------------|
| 1001 | paid | 500 | 2026-06-01 10:00:00 |
В батче может прийти обновление того же order_id (status сменился на refunded) и/или полный дубль строки.
Структура для ориентира — реальные значения из эталонного решения.
INSERT INTO orders_fact (order_id, status, amount, updated_at)
VALUES (:order_id, :status, :amount, :updated_at)
ON CONFLICT (order_id) DO UPDATE
SET status = EXCLUDED.status,
amount = EXCLUDED.amount,
updated_at = EXCLUDED.updated_at
WHERE EXCLUDED.updated_at > orders_fact.updated_at; -- только более свежееЭто задание для уровня medium. Senior-уровень — глубокое понимание темы, опыт решения нестандартных задач, обсуждение trade-off на собеседовании.
Подобные задания в категории «Data Engineering» регулярно дают на собеседованиях аналитика данных в Яндекс, Сбер, Ozon, Авито, Тинькофф, Wildberries, T-Bank, X5, ВТБ и других крупных IT-компаниях.
На реальном собеседовании на подобную задачу отводится 30-60 минут с обсуждением подходов, оптимизаций и trade-off. Для тренировки рекомендуем сначала решить самостоятельно, потом сверить с эталонным решением и подсказками.
На zasqlpython.ru есть другие задания в категории «Data Engineering», продуктовые кейсы, справочник метрик, AI мок-собеседование с разбором ваших ответов.
← Все задания