Аналитика вторичного рынка комплектующих в ВКР: от парсинга объявлений до прогноза дефицита

Аналитики «Авито» зафиксировали резкий рост продаж оперативной памяти и SSD: спрос на комплектующие подскочил в несколько раз относительно прошлых периодов. Причины привычные — рост цен на новые модули, дефицит отдельных позиций, массовый апгрейд старых машин и активный вторичный рынок, куда уходят снятые с эксплуатации планки и накопители. Для выпускника ИТ-направления это не просто новость, а готовый полигон данных: тысячи разнородных объявлений, меняющиеся цены, категории, регионы, состояние товара.

Именно на таком материале удобно строить ВКР, где есть и сбор данных, и хранилище, и модель прогноза, и веб-интерфейс. Тема защищаемая: у неё есть измеримая польза (точность прогноза, скорость обработки, экономия на закупке) и понятная бизнес-логика. Ниже — как разложить это на главы, какие метрики показать комиссии и где чаще всего «сыпятся» студенты.

Три темы ВКР, которые вырастают из этой новости

1. Система мониторинга и прогнозирования цен на вторичном рынке

Актуальность: волатильность цен на ОЗУ и SSD подтверждена рыночными данными; покупателю и сборщику нужен инструмент, который скажет «брать сейчас или подождать».

Цель: разработать информационную систему сбора, хранения и прогнозирования цен на комплектующие.

Задачи:

• проанализировать источники данных и правовые ограничения на парсинг;
• спроектировать хранилище и ETL-конвейер (Apache Airflow + PostgreSQL/ClickHouse);
• построить и сравнить модели прогноза (ARIMA, Prophet, градиентный бустинг);
• реализовать дашборд и REST API для выдачи прогноза.

Структура: Глава 1 — обзор рынка, методов прогнозирования и аналогов; Глава 2 — архитектура, схема БД, диаграммы UML и DAG-и; Глава 3 — нагрузочное тестирование, оценка точности (MAPE, RMSE), расчёт экономического эффекта.

2. Оценка остаточной стоимости техники методами машинного обучения

Актуальность: рост оборота б/у комплектующих делает оценку справедливой цены самостоятельной прикладной задачей.

Цель: построить модель регрессии, оценивающую рыночную стоимость лота по его признакам.

Задачи: подготовка признаков (объём, тип памяти, частота, ресурс SSD, регион), борьба с выбросами и дублями, обучение и валидация, объяснение предсказаний (SHAP), интеграция модели в сервис.

Структура: Глава 1 — теория регрессии и метрик; Глава 2 — датасет, признаки, пайплайн обучения; Глава 3 — эксперименты, сравнение моделей, A/B-оценка полезности.

3. Аналитическая платформа спроса на комплектующие с визуализацией трендов

Актуальность: дефицит и ажиотажный спрос — типовой сценарий для систем мониторинга; новость даёт свежий кейс и цифры для первого раздела.

Цель: создать OLAP-хранилище и BI-слой для анализа динамики спроса по категориям и регионам.

Задачи: нормализация категорий (классификатор по названию объявления), построение витрин данных, настройка Grafana/Superset, описание регламента обновления.

Структура: Глава 1 — анализ предметной области и стандартов (ГОСТ 34.602-89 на ТЗ); Глава 2 — модель данных «снежинка», конвейеры загрузки; Глава 3 — тестирование производительности запросов, оценка по ISO/IEC 25010.

Аналитическая глава: чем обосновывать выбор, а не «мне так удобно»

Первая глава — не пересказ учебника. Комиссия читает её как доказательство, что вы понимаете альтернативы. Сравнивайте не абстрактные «плюсы и минусы», а критерии под вашу задачу: объём данных, частота обновления, требования к аналитическим запросам.

Отдельно обоснуйте СУБД. Для потоковой записи объявлений и агрегатов по категориям связка «PostgreSQL для операционных данных + ClickHouse для аналитики» защищается лучше, чем один универсальный сервер: у вас появляется аргумент про колоночное хранение и скорость сканирования. Не забудьте про нормативную часть — ТЗ по ГОСТ 34.602-89 и перечень характеристик качества по ISO/IEC 25010 закрывают вопросы оформления.

Проектная часть: архитектура и то, что реально рисуют в главе 2

Здесь нужны схемы: контекстная диаграмма системы, диаграмма компонентов, ER-модель, последовательность обработки объявления. Минимальный рабочий контур выглядит так: планировщик запускает задачи сбора → сырые данные падают в staging-слой → нормализация и дедупликация → витрина → модель прогноза → API и дашборд. Планировщик удобно показать на Airflow: комиссии нравится, когда виден DAG, а не абстрактное «данные собираются регулярно».

from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta

default_args = {
    "owner": "vkr",
    "retries": 3,
    "retry_delay": timedelta(minutes=10),
}

with DAG(
    dag_id="marketplace_components_etl",
    start_date=datetime(2026, 3, 1),
    schedule="0 */4 * * *",
    catchup=False,
    default_args=default_args,
) as dag:
    collect = PythonOperator(task_id="collect_listings", python_callable=collect)
    clean = PythonOperator(task_id="normalize_and_dedupe", python_callable=clean)
    load = PythonOperator(task_id="load_to_dwh", python_callable=load)
    train = PythonOperator(task_id="retrain_price_model", python_callable=train)

    collect >> clean >> load >> train

Обратите внимание на идемпотентность: повторный запуск задачи не должен плодить дубли объявлений. Это ровно тот нюанс, за который на защите ставят плюс — он показывает инженерное мышление, а не только умение писать код.

Тестирование и метрики: где берутся цифры для третьей главы

Универсальная ошибка — отчёт вида «система работает, всё хорошо». Нужны измерения. Разбейте их на три группы и сведите в одну таблицу результатов.

Производительность и надёжность

• время полного цикла ETL на N объявлений (например, 100 000 записей);
• среднее время отклика API прогноза при 50–200 одновременных запросах;
• RTO/RPO для хранилища: как быстро поднимаете узел и сколько данных теряете;
• поведение при отказе источника — сработали ли retry-политики.

Качество модели

Для регрессии — MAE, RMSE, MAPE, обязательное сравнение с базовой моделью (наивный прогноз «завтра как сегодня»). Если ваша модель не бьёт наивный прогноз, честно об этом напишите: комиссия ценит адекватность выше красивых цифр.

Наблюдаемость

Метрики, логи и трассировки — стандартный набор. Свяжите сервисы через OpenTelemetry, соберите метрики в Prometheus, постройте дашборд в Grafana. Один экран с графиком задержек ETL и ошибок сбора выглядит на защите убедительнее десяти страниц текста.

Чему вы научитесь на такой теме

• проектировать конвейеры данных и обосновывать выбор хранилища под нагрузку;
• работать с реальными «грязными» данными: дубли, выбросы, разные форматы записи объёма памяти;
• оценивать качество модели на бизнес-метриках, а не только на accuracy;
• оформлять ТЗ и проектную документацию в рамках ГОСТ 34 и ISO/IEC 25010;
• защищать архитектурные решения аргументами, а не ссылкой «так принято».

Вопросы, которые задают на консультациях

Источник: «Авито»: продажи оперативной памяти и SSD выросли в несколько раз (опубликовано 2026-03-24)