Skip to content

Statistics process description

Jump to bottom
Dmitriy Popov edited this page Jan 10, 2021 · 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, в котором хостится статистика.
  • После загрузки в S3 нужно сделать Invalidate для обоих AWS CloudFront distribution, чтобы сайт обновился в CDN. Если не обновить, то закэшированная версия будет выдаваться во время TTL. Насколько я понял, TTL составляет порядка суток.

Скачивание данных из 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. Если структура данных останется такой же простой, то теоретически можно достаточно безболезненно перезжать на другие БД при необходимости.

Генерация статических страниц в Spring Boot приложении через FreeMarker шаблоны

TODO:

Копирование статического сайта в S3 bucket

TODO:

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

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