Steam — одна из крупнейших платформ цифровой дистрибуции игр, и одновременно огромный источник данных: каталоги игр, отзывы, достижения, ценовые метрики, активность игроков, региональные различия и многое другое. Однако прямого доступа к агрегированным данным у исследователей нет — их необходимо собирать вручную через Steam Web API и сторонние сервисы.

В этом проекте мы разработали полноценный программный комплекс для автоматизированного сбора, хранения и анализа данных Steam. Построили двухуровневую архитектуру хранилища, реализовали оркестрацию чанков, разработали пайплайны работы с API и конфигурацию параллельного масштабирования. На основе собранных данных сформирован датасет объёмом десятки тысяч игр и сотни тысяч пользователей — и проведён базовый аналитический обзор рынка.

Цели проекта

Мы хотели создать систему, которая:

• автоматически собирает данные из Steam Web API и SteamСharts;

• хранит их в структурированном аналитическом хранилище;

• предоставляет удобные инструменты для анализа: статистика, временные ряды, кластеризация, корреляции, рекомендации;

• масштабируется горизонтально за счёт параллельной обработки чанков.

Иными словами, инфраструктурный фундамент для дата-проекта на больших игровых данных.

Архитектура: две базы, фасады, медиаторы

Основная аналитическая база

База данных steam-analysis.db содержит доменную модель:

• игры, пользователи, друзья;

• жанры, категории, платформы, издатели;

• динамические метрики: цена, онлайн, отзывы;

• временные ряды и достижения.

Служебная база

База данных db-analytics.db управляет оркестрацией пайплайнов:

• чанки игр и пользователей (AnalysisChunk, AnalysisUserChunk);

• логирование результатов обработки;

• статусы ошибок.

Таким образом основная модель изолирована от технических аспектов ETL.

Паттерны

Проект использует Facade для изоляции модулей и Mediator для координации пайплайнов:

• DBFacade — единая точка доступа к аналитическим таблицам;

• AnalysisDbFacade — оркестрация обработки чанков;

• SteamAnalysisFacade — изолирует работу с API;

• GameService и PlayerService — слой API-клиентов.

Работа со Steam Web API и Steamcharts

Steam Web API накладывает ограничения:

• Ограничения по частоте запросов. Для ключа разработчика допускается только определённое количество запросов в минуту. Поэтому в сервисе реализованы пакетные вызовы и искусственные паузы между запросами, чтобы избежать блокировок.

• Неполнота данных. Не все игры имеют полный набор метрик: могут отсутствовать отзывы, достижения или статистика по игрокам. Пайплайн учитывает такие случаи и логирует ошибки в служебную базу.

• Изменчивость схемы API. Некоторые методы Steam Web API считаются устаревшими или меняют формат ответов. Для минимизации риска в коде использованы DTO-схемы и централизованный слой клиентов, позволяющий локализовать изменения.

• Региональные различия. Часть информации (цены, отзывы, языки) зависит от региона и локализации, что учитывается при разработке аналитических сценариев.

• Потенциальные ошибки в получаемых данных. Некоторые запросы могут возвращать неполные данные или возвращать ошибку. Для обеспечения отказоустойчивости и стабильности работы системы была реализована обработка ошибок в коде, позволяющая пропускать "битые"ответы и логировать проблему.

Работа со Steamcharts также имеет свой список ограничений, а именно:

• Отсутствие публичного API. Сайт собирает данные через внутренний сервис, но не предоставляет публичного API для сторонних разработчиков. Для автоматизированного сбора данных был реализован функционал парсинга HTML.

• Ограничения по частоте запросов. Активный парсинг с одного IP может быть расценен как DDoS-атака и привести к блокировке, поэтому возникает необходимость сбора данных с двух ip-адресов и соблюдения интервалов между запросами.

• Потенциальные ошибки на страницах. Некоторые страницы могут не загружаться или некорректно отображать данные. Для обеспечения отказоустойчивости и стабильности работы системы была реализована обработка ошибок в коде, позволяющая пропускать"битые"страницы и логировать проблему.

Горизонтальное масштабирование

Система масштабируется за счёт:

• Чанковая обработка. Все операции сбора данных выполняются над ограниченными диапазонами app_id или набором steam_id. Это позволяет запускать несколько экземпляров сервиса параллельно, распределяя чанки между машинами.

• Разделение хранилищ. Основная и служебная базы разделены, что позволяет независимо масштабировать слой оркестрации и слой аналитики, а при необходимости переносить их на разные физические узлы.

• Пакетная работа с API. Методы сервисов принимают списки идентификаторов, что позволяет эффективно использовать лимиты API (только для некоторых запросов).

• Промежуточное хранение в JSON. Данные сохраняются в формате JSON на этапе сбора, что обеспечивает отказоустойчивость, гибкость схемы и возможность повторной обработки. Файлы служат буфером между источниками и финальной базой, позволяя декомпозировать пайплайн на независимые этапы сбора и добавления данных в основное хранилище.

Характеристики датасета и описание модели данных

Аналитические результаты

Распределение продуктов Steam по типам

На рисунке видно, что основная масса продуктов Steam — игры, демоверсии и DLC.

Популярность категорий

По популярности лидируют следующие категории:

• Single-player

• Family Sharing

• Steam Achievements

Сезонность выхода игр

Динамика жанров

• бурный рост сегмента Indie;

• рост категорий Single-player и Family Sharing;

• заметный общий спад около 2019 года.

Кластеризация игр по набору признаков с целью выявления игровых сегментов

В индустрии и сообществе существует устоявшаяся парадигма деления продуктов на сегменты (Tier-1/AAA, Indie и т.д.). Мы решили проверить, будет ли такое разделение иметь четкое математическое отражение в пространстве объективных рыночных метрик (цена, вовлеченность, доступность).

Однако применение алгоритмов кластеризации и снижение размерности показало отсутствие устойчивых разделяемых кластеров. Объекты распределены в пространстве признаков диффузно. Таким образом, установлено, что фактически рынок игр имеет не кластерную структуры, а непрерывную структуру.

Карта региональных предпочтений

Для построения карты региональных предпочтений, сервис отдает список игр с координатами региона и количеством пользователей, которые играют в данную игру в конкретном регионе. Список игр может быть выгружен в формате json или в Google Таблицу. Для визуализации мы предлагаем использовать сервис Datawrapper.

Круги на карте - игры (или жанры), их размер пропорционален количеству человек, играющих в них в определенном регионе. В результате детального анализа такой карты можно с легкостью определить, какие игры наиболее популярны в разных регионах.

Граф с отображением наиболее популярных игр среди друзей для формирования рекомендаций

Для анализа наиболее популярных игр среди друзей пользователя был построен граф. Данные для графа сервис выгружает в формате json или в Google Таблицу. Для визуализации предлагаем воспользоваться сервисом Kumu.

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

Дистрибутив проекта

Состоит из:

• exe-файла пайплайна (через PyInstaller);

• двух БД с минимальным набором данных;

• конфигурации Steam API;

• скриптов для обновления данных;

• README с инструкциями.

Итоги

Мы разработали:

• масштабируемую архитектуру для сбора данных Steam;

• двухуровневое хранилище;

• ETL-процессы с оркестрацией чанков;

• средства анализа, визуализации и экспорта в внешние сервисы (Google Sheets, Datawrapper, Kumu);

• аналитический датасет и набор исследовательских результатов.

Проект может служить основой для:

• корреляционного анализа,

• регрессий,

• кластеризации,

• анализа временных рядов,

• рекомендательных моделей,

• бизнес-исследований рынка.