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);
аналитический датасет и набор исследовательских результатов.
Проект может служить основой для:
корреляционного анализа,
регрессий,
кластеризации,
анализа временных рядов,
рекомендательных моделей,
бизнес-исследований рынка.
