Мониторинг цен маркетплейсов в ВКР: ETL-конвейер, прогноз скидок и аналитика промо
Поддомен: Data Engineering. Роль: Data/ML-инженер.
Семантический анализ (кратко). Основной запрос: система мониторинга цен маркетплейсов для ВКР. LSI: ETL-конвейер, Apache Airflow, Playwright, TimescaleDB, REST API, rate limiting, анти-бот защита, Prophet/ARIMA, MAPE, freshness данных, OpenTelemetry, ISO/IEC 25010, ГОСТ 34.601. Сущности: ГОСТ 34.601, ISO/IEC 25010, OpenTelemetry, C4/UML, метрики домена (freshness, p95 latency, MAPE). Схема структуры — B.
Введение
28 марта 2026 года ZDNet выпустил подборку скидок на технику Apple в рамках Amazon Big Spring Sale — площадка на выходные выкатила десятки промо-предложений, и редакция вручную «собрала» их в один список. С точки зрения инженерии это классический кейс data-driven retail: сотни товарных позиций, динамические цены, сезонные окна скидок и острая потребность в свежих данных. Именно поэтому новость — отличный повод для ВКР по Data Engineering. Вы получаете живую предметную область с понятными источниками, измеримыми метриками и прикладным результатом: конвейер сбора, нормализации и анализа цен, который можно защитить как самостоятельный программный продукт. Ниже — как этот сюжет развернуть в диплом и не утонуть в парсинге.
Основная часть: три темы ВКР и как их оформить
Мы объединили блок тем с практической частью — так проще показать комиссии связку «анализ → проектирование → реализация → оценка». Каждая тема опирается на один и тот же кейс из статьи, но с разным акцентом.
Тема 1. ETL-конвейер сбора и нормализации цен с маркетплейсов
- Актуальность: подборки вроде «Best Amazon Spring Sale Apple deals 2026» собираются вручную; автоматизированный сбор и дедупликация предложений заменяет редакционный труд и даёт основу для аналитики.
- Цель: спроектировать отказоустойчивый конвейер «источник → сырое хранилище → нормализованная витрина» с контролем качества данных.
- Задачи: (1) обзор источников и ограничений robots.txt/ToS; (2) проектирование DAG в Airflow; (3) реализация парсеров с ротацией User-Agent и rate limiting; (4) валидация данных по правилам Great Expectations; (5) расчёт метрик freshness и completeness.
- Структура: Гл. 1 — анализ источников и требований; Гл. 2 — архитектура (C4-диаграмма, схема БД в TimescaleDB); Гл. 3 — нагрузочные тесты и оценка качества по ISO/IEC 25010.
Тема 2. Прогнозная модель сезонных скидок
- Актуальность: Amazon Spring Sale — сезонный пик; прогноз размера скидки и оптимального момента покупки — прямая бизнес-ценность.
- Цель: построить модель краткосрочного прогноза цены с оценкой качества (MAPE, RMSE) и сравнением с базовыми эвристиками.
- Задачи: (1) формирование временных рядов по категории Apple; (2) сравнение Prophet, SARIMA и градиентного бустинга; (3) фичеинжиниринг (день недели, история дисконтов, длительность промо); (4) A/B-валидация через walk-forward cross-validation.
- Структура: Гл. 1 — обзор методов и метрик; Гл. 2 — пайплайн подготовки признаков и обучение; Гл. 3 — сравнение моделей и выводы по применимости.
Тема 3. Сервис алертов о скидках с наблюдаемостью по OpenTelemetry
- Актуальность: покупателю нужен сигнал «цена упала ниже порога» за минуту, а не за сутки; сервис требует измеримого SLA.
- Цель: разработать бэкенд-сервис с REST API, подписками и телеметрией (метрики, трейсы, логи).
- Задачи: (1) спроектировать API и очередь (Kafka/Redis Streams); (2) инструментировать OpenTelemetry; (3) настроить SLO по p95 latency; (4) построить дашборд в Grafana.
- Структура: Гл. 1 — анализ SLA и требований; Гл. 2 — проектирование сервиса (UML-диаграммы последовательности); Гл. 3 — стресс-тесты и отчёт по SLO.
H3. Что кладём в Главу 1
Здесь размещается обзор предметной области: типы маркетплейсов, механики промо-акций, риски парсинга. Обязательно зафиксируйте юридическую рамку — публикация данных не означает разрешение на их массовый сбор. Полезно построить диаграмму BPMN «как редактор собирает подборку вручную» и рядом — целевую BPMN «как это делает конвейер»: комиссия любит наглядную разницу AS-IS/TO-BE.
H3. Что кладём в Главу 2
Здесь — архитектура. C4-диаграмма уровней Context и Container (источники → оркестратор → сырое S3-хранилище → нормализация → витрина → BI), схема БД, контракты API по OpenAPI 3.1. Ниже — пример DDL для хранилища временных рядов.
CREATE TABLE price_observation (
observed_at TIMESTAMPTZ NOT NULL,
product_id BIGINT NOT NULL,
marketplace TEXT NOT NULL,
price_usd NUMERIC(10,2) NOT NULL,
discount_pct NUMERIC(5,2),
source_hash CHAR(64) NOT NULL
);
SELECT create_hypertable('price_observation', 'observed_at');
CREATE INDEX ON price_observation (product_id, observed_at DESC);
Фрагмент парсера с уважением к источнику — ротация User-Agent, экспоненциальный backoff и приведение цены к числовому виду. Такого куска достаточно, чтобы в Главе 2 показать «инженерную гигиену».
from playwright.sync_api import sync_playwright
from tenacity import retry, wait_exponential, stop_after_attempt
RATE_LIMIT_RPS = 0.5 # один запрос в 2 секунды
@retry(wait=wait_exponential(multiplier=2, max=60),
stop=stop_after_attempt(5))
def fetch_price(page, url: str) -> str:
page.goto(url, timeout=30_000)
return page.inner_text("div[data-testid='price']")
def normalize(raw: str) -> float:
return float(raw.replace("$", "").replace(" ", "").replace(",", ""))
H3. Что кладём в Главу 3
Тестирование и оценка. Для конвейера считаем freshness (лаг между публикацией цены и её появлением в витрине), completeness (доля товаров с заполненными полями) и p95 latency записи. Для модели — MAPE и стабильность весов по walk-forward. Для сервиса — SLO по p95 ≤ 300 мс и доля успешных доставок алертов ≥ 99,5%. Результаты удобно свести в таблицу ниже.
| Компонент | Метрика | Целевое значение | Инструмент |
|---|---|---|---|
| ETL | Freshness | < 15 мин | Airflow SLAs, Metabase |
| Хранилище | Completeness | ≥ 99% | Great Expectations |
| Модель | MAPE | ≤ 8% | scikit-learn, Prophet |
| API | p95 latency | ≤ 300 мс | OpenTelemetry + Grafana |
Чему вы научитесь на этой теме
- Проектировать ETL-конвейеры с идемпотентностью и воспроизводимыми перезапусками.
- Собирать данные легально и устойчиво: rate limiting, backoff, соблюдение ограничений источника.
- Оценивать качество данных и моделей по ISO/IEC 25010 и доменным метрикам, а не «на глазок».
- Инструментировать сервисы OpenTelemetry и защищать SLO цифрами, а не обещаниями.
- Оформлять проектную документацию по ГОСТ 34.601 (стадии создания АС) — обязательный пункт нормоконтроля.
FAQ
Можно ли парсить реальные маркетплейсы в дипломной работе?
Технически — да, юридически — осторожно. Публичная доступность не равно разрешению на массовый сбор. В ВКР зафиксируйте ограничения: снижение частоты, кэширование, использование официальных API там, где они есть. Излишняя «наглость» парсера — прямой путь к бану IP и замечанию рецензента. Если тема не про парсинг как таковой, честно замените источник на синтетический генератор с сохранением структуры данных.
Сколько данных нужно собрать, чтобы защитить главу 3?
Для ETL-конвейера хватит 30–60 дней наблюдений по 300–500 товарам — это даёт до 20 тыс. записей на позицию. Для модели прогноза — минимум два сезонных цикла (весенний и летний пики), чтобы walk-forward дал осмысленный MAPE. Синтетические данные допустимы, если вы описываете генератор и его допущения.
Как посчитать экономическую эффективность системы?
Сравните трудозатраты ручного сбора подборки (часы редактора × ставка) с ресурсами конвейера (часы VPS/облака + разработка). Точка окупаемости считается в Excel и прикладывается в приложении. Не пытайтесь вывести «ROI на диплом» из воздуха — приводите источник ставок и тарифов.
Какие схемы обязательно включить?
C4 Context + Container, диаграмму последовательности UML для алерта, ER-модель хранилища, BPMN AS-IS/TO-BE и графики метрик (freshness, MAPE, p95). Этого набора достаточно, чтобы нормоконтроль и комиссия остались довольны.
- Задачи из введения дословно повторяются в выводах по главам.
- Все источники в списке литературы имеют DOI или дату обращения.
- Схемы C4/UML/BPMN подписаны и связаны ссылками с текстом.
- Метрики (freshness, MAPE, p95) посчитаны и вынесены в таблицы.
- Оформление кода и таблиц соответствует ГОСТ 19.201/34.601.
- Уникальность текста — не ниже требований кафедры, код и приложения проверяются отдельно.
- Приложения содержат листинги, структуру репозитория и инструкцию по запуску.
1. «Сырой» парсер как центральный результат. В ВКР по Data Engineering фрагмент кода без нормализации, валидации и метрик качества — это не результат, а черновик. Опирайтесь на кейс из статьи: там собранные данные годами кто-то приводил к единому виду.
2. Метрика ради метрики. Accuracy в задаче прогноза цены бесполезна. Считайте MAPE/RMSE и сравнивайте с baseline-эвристикой «завтра = сегодня». Только тогда цифра что-то значит.
3. Игнор наблюдаемости. Сервис без трейсов и логов нечем защищать по SLA. Даже минимальная инструментация через OpenTelemetry спасает на защите, когда спросят «а сколько живёт инцидент?».
Источник: Best Amazon Spring Sale Apple deals 2026 (опубликовано 2026-03-28)