Skip to content

Statistics process description

Jump to bottom
Dmitriy Popov edited this page Dec 20, 2020 · 21 revisions

Глоссарий

Как это работает

Общая high-level схема, без подробностей

  • Выполняются запросы к KG-API для заданного диапазона юзеров, например, playerId in [1; 625000].
  • Запросы из KG-API сохраняются в JSON-файлы
  • JSON-файлы преобразуются через MapStruct в JPA-сущности PlayerEntity.
  • PlayerEntity сохраняются в базу MySQL.
  • На основе данных из БД через FreeMarker-шаблоны генерируются статические html и js файлы, представляющие собой сайт статистики.
  • Все сгенерированные файлы, а также негенерируемая статическая часть (html + js + css) копируется в S3 Bucket, в котором хостится статистика.

Скачивание данных из KG-API

  • В PlayerSummaryDownloader запускаются GET запросы к API Клавогонок в заданном интервале [fromPlayerId; toPlayerId].
  • На текущий момент запускаются только запросы /get-summary и /get-index-data. Будут добавлены как минимум запросы на саммари статистики и на ачивки.
  • Запросы суперпрямолинейны, просто GET в духе curl. То есть запросы НЕ работают через какие-либо REST-клиенты.
  • Следует отметить, что и при ошибке методы KG-API возвращают статус 200, при этом там будет содержаться свойство "err", в котором будет содержаться текст ошибки.
  • В первой загрузке все запросы выполнялись последовательно, что длилось в районе 40 часов. Запросы нужно переделать на параллельные, что должно ускорить процесс.
  • Результаты запросов сохраняются в заданную папку на диске. Каждый тип запроса сохраняется в свою директорию.
    • ❗ ошибочные ответы (то есть ответы вида {"err": "error text"}) тоже сохраняются, чтобы была целостность данных и не было сомнений, выполнялся запрос по какому-то userId или нет.
    • Каждый ответ сохраняется в свой файл, то есть путь к файлу выглядит в духе <rootDir>/<importStartDateTime>/<queryType>/<playerId>.json.
  • Запросы выполнялись на AWS EC2 Instance, как на месте со стабильным интернетом
    • TODO: команда, запускающая. Описать, что собран über-jar для kgparserSrv.
  • После выполнения директория с файлами зипуется и загружатеся в AWS S3 Bucket. Пока вручную.
    • TODO: команды зипования и загрузки в S3.
    • EC2 инстанс обладает ролью, дающей права писать в S3 Bucket.

Преобразование из кучи json файлов в базу данных.

  • База данных MySQL.
  • На текущий момент там одна плоская таблица Player.
    • Таблице соответствует JPA-сущность PlayerEntity.
    • Далее будут уже другие таблицы для ачивок, словарей (возможно) и данных по словарям.
    • Ответы от /get-summary и /get-index-data парсятся через Jackson в Java-объекты и агрегируются в один объект PlayerJsonData в PlayerJsonParser.
      • ❗ PlayerJsonParser содержит валидацию данных, которая была ослаблена под текущий набор данных. Теоретически на новых проблемных случаях эта валидация может упасть.
    • PlayerJsonData преобразуется в PlayerEntity через MapStruct Mapper PlayerMapper.
  • Для работы с БД создан SpringBoot-модуль, причём это консольное приложение, без веба: KgParserApplication implements CommandLineRunner.
  • Схема БД авто-генерируется с помощью Hibernate. Если структура данных останется такой же простой, то теоретически можно достаточно безболезненно перезжать на другие БД при необходимости.

Как это должно работать в идеале

  • Весь процесс должен быть автоматизирован и запускаться в одну команду.
  • В супер-идеале вообще сделать автозапускаемую задачу по cron или подобному (например, в AWS можно по таймеру запускать Lambda).
  • EC2 instance должен создаваться перед экспортом и удаляться после него.
  • Нужно настроить CF (или более высокое API todo: как это называется? Создание CF программно.) для создания EC2. Это должно включать настройку окружения (установку java 11 etc.).
    • TODO: все команды, необходимые для запуска приложения на EC2.
  • Можно настроить пайплайн на AWS Code Build etc. Там поддерживается взятие исходников из GitHub.
Clone this wiki locally