Опубликовано: 15.09.2026 | Источник: CNews (новости)

Поддомен: Data Engineering / мобильная аналитика. Роль: Data/ML-инженер. Схема структуры: C (Введение → FAQ → Темы ВКР карточками → Основная часть → Чек-лист → Ошибки → CTA → Эксперт → Источник).

Аналитика мобильного рынка в ВКР: пайплайн данных и метрики, которые защитит комиссия

RuStore оценил: за первые месяцы 2026 года россияне покупали в среднем более 500 тыс. смартфонов в неделю. Для выпускника это не новость из ленты, а готовая предметная область с честными числами. Каждое устройство — это первичная активация, установки, сессии, покупки, ошибки. Если на один аппарат приходится хотя бы 20–25 событий, получается порядка 12 млн записей в неделю, то есть 20+ событий в секунду. Такой поток нельзя «посчитать в Excel» — его нужно проектировать: хранилище, конвейер загрузки, витрины, метрики качества.

Именно поэтому тема выигрышно ложится в ВКР по Data Engineering, аналитике или системному анализу. В работе появляется реальный масштаб, обоснованная актуальность и защищаемые числовые результаты — а не абстрактное «приложение для учёта чего-нибудь».

Частые вопросы студентов по этой теме

Где брать данные, если нет доступа к закрытой статистике магазина приложений?

Три законных пути. Первый — открытые агрегаторы и публичные отчёты (в том числе новость CNews как источник вторичных данных для главы 1). Второй — собственный генератор синтетических событий, повторяющий распределение из отчёта: это стандартная практика, если в работе честно указано, что датасет синтетический и параметры распределения обоснованы. Третий — публичные наборы об установках мобильных приложений (Kaggle, Google Play Store dataset) с пересчётом масштаба под российский рынок.

Какой стек выбрать, чтобы комиссия не задала вопрос «а почему не …»?

Выбирайте не модное, а объяснимое. Для учебного проекта хватает связки: Python + Airflow (оркестрация), PostgreSQL или ClickHouse (хранение и агрегаты), Grafana или Metabase (визуализация), Docker Compose (воспроизводимость). Ключевой аргумент на защите — не названия инструментов, а почему именно они: ClickHouse даёт агрегаты по 12 млн строк за доли секунды, Airflow делает пересчёт идемпотентным и перезапускаемым.

Как считать эффективность системы, если это не «ускорение алгоритма»?

Через набор характеристик по ISO/IEC 25010: производительность (время сборки витрины, p95 отклика дашборда), надёжность (доля успешных запусков DAG), сопровождаемость (время добавления нового источника), функциональная полнота (доля метрик из ТЗ, доведённых до витрины). Плюс экономический блок: сравнение с ручной обработкой по трудозатратам и стоимости облачных ресурсов.

Обязательно ли строить UML, если работа про данные?

Нет, но схема нужна обязательно. Для потоков данных уместны C4 (уровни Context и Container) и DFD, для логики загрузки — BPMN или схема DAG. ГОСТ 34.601-90 задаёт стадии создания системы, и привязка разделов работы к этим стадиям снимает половину замечаний нормоконтроля.

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

• 1. Конвейер агрегации рыночных данных о продажах мобильных устройств.
  Актуальность: поток в 500 тыс. устройств в неделю требует автоматической загрузки и пересчёта витрин, ручная обработка не масштабируется.
  Цель: спроектировать и реализовать ETL/ELT-пайплайн, дающий аналитику по рынку с задержкой не более суток.
  Задачи: обзор источников и форматов; проектирование модели хранения (звезда); реализация DAG в Airflow; контроль качества данных и метрики свежести.
  Структура: Глава 1 — анализ рынка и требований (ГОСТ 34.601-90); Глава 2 — проектирование хранилища и пайплайна (C4, схема БД); Глава 3 — реализация, тестирование, замеры производительности.

• 2. Рекомендательная система приложений на основе поведения владельцев устройств.
  Актуальность: рост парка смартфонов увеличивает спрос на персонализацию выдачи в магазинах приложений.
  Цель: построить модель рекомендаций и оценить её качество на событийных данных.
  Задачи: формирование признаков из логов; сравнение коллаборативной фильтрации и градиентного бустинга; off-line оценка (Precision@K, Recall@K); анализ холодного старта.
  Структура: Глава 1 — обзор подходов; Глава 2 — подготовка данных и архитектура сервиса; Глава 3 — эксперименты и интерпретация метрик.

• 3. Мониторинг мобильного приложения на OpenTelemetry: SLO и разбор инцидентов.
  Актуальность: массовый парк устройств означает разнородные модели, версии ОС и сети — без наблюдаемости деградацию не поймать.
  Цель: внедрить сквозную телеметрию и связать её с SLO приложения.
  Задачи: инструментирование клиента и бэкенда; сбор трейсов, метрик, логов; настройка алертов по burn rate; расчёт MTTR до и после.
  Структура: Глава 1 — теория наблюдаемости; Глава 2 — архитектура сбора телеметрии; Глава 3 — эксперименты и оценка сокращения времени реакции.

• 4. Витрина данных рынка смартфонов с контролем качества.
  Актуальность: решения о закупках и маркетинге опираются на цифры, а несогласованные данные дороже их отсутствия.
  Цель: разработать витрину и набор проверок Data Quality с формализованными правилами.
  Задачи: описание бизнес-метрик; реализация проверок полноты, уникальности, своевременности; дашборд; регламент реагирования на инциденты данных.
  Структура: Глава 1 — анализ предметной области и метрик; Глава 2 — проектирование витрины и правил; Глава 3 — внедрение, тесты, оценка эффекта.

Как встроить материал статьи в главы работы

Глава 1: цифра из отчёта как обоснование масштаба

Не пересказывайте новость — переводите её в требования. Из «более 500 тыс. устройств в неделю» выводятся: ориентировочная интенсивность входного потока, требования к частоте обновления витрины, класс хранилища. Оформите таблицу «Параметр рынка → Требование к системе», и актуальность перестанет быть декларативной.

Глава 2: проектирование конвейера и схема данных

Здесь пригодятся C4 (контекст и контейнеры) и модель «звезда» для витрины. Ниже — рабочий скелет DAG, который можно ставить в приложение к пояснительной записке: он показывает идемпотентность, ретраи и разделение слоёв raw / staging / mart.

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

def extract_raw(ds, **_):
    """Загрузка выгрузки о продажах устройств за сутки в слой raw."""
    ...

def build_mart(ds, **_):
    """Пересчёт витрины mart_device_sales (идемпотентно, партиция = ds)."""
    ...

default_args = {
    "owner": "diploma",
    "retries": 2,
    "retry_delay": timedelta(minutes=5),
}

with DAG(
    dag_id="device_sales_mart",
    start_date=datetime(2026, 1, 1),
    schedule="0 3 * * *",          # ежедневный пересчёт в 03:00
    catchup=True,
    max_active_runs=1,
    default_args=default_args,
    tags=["diploma", "data-engineering"],
) as dag:

    raw = PythonOperator(task_id="extract_raw", python_callable=extract_raw)
    mart = PythonOperator(task_id="build_mart", python_callable=build_mart)

    raw >> mart

Схему хранения опишите словами и ASCII-диаграммой, если в шаблоне не поддерживается SVG:

[Источник: отчёты, выгрузки]
        |
        v
   raw.events_raw      (сырые данные, партиции по дате)
        |
        v
   staging.events_clean (дедупликация, типизация)
        |
        v
   mart.device_sales    (агрегаты: неделя, модель, регион)
        |
        v
   BI (Grafana/Metabase) + Data Quality checks

Глава 3: метрики, по которым вас будут спрашивать

Разделите метрики на три группы и приведите формулу для каждой. Комиссия любит, когда число можно воспроизвести.

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

• Переводить отраслевую статистику в измеримые требования к системе, а не в пересказ новости.
• Проектировать слоистое хранилище (raw → staging → mart) и обосновывать выбор СУБД под нагрузку.
• Писать идемпотентные конвейеры с ретраями и партиционированием — воспроизводимо на чужой машине.
• Считать характеристики качества по ISO/IEC 25010 и защищать их числами, а не словами.
• Оформлять архитектурные схемы (C4, BPMN, DFD) в соответствии с требованиями нормоконтроля.

Источник: Россияне покупают от полумиллиона смартфонов в неделю (опубликовано 2026-03-24)