Один месяц в Splyce - выбор технологий и первые вызовы
Как ведущий член нашей ветви анализа данных, мне пришлось построить нашу систему с нуля и выбрать, какие технологии использовать для каждой части стека. Я думаю, что изучение процесса, которому я следовал, чтобы создать эффективную рабочую среду, может быть полезно для людей, интересующихся наукой о данных и желающих открыть ее с помощью данных, которые им нравятся!
Доступные данные
Первый шаг при настройке вашей среды - это посмотреть, какие данные вы можете собирать. В частности, что касается League of Legends, мне очень повезло, что Riot Games разработала отличный API. Riot API Discord также был огромным подарком для настройки всего и поиска помощи, когда я боролся.
Вот небольшой пример того, что вы можете получить от API:
- Список лучших игроков из каждого региона
- Список их последних 100 игр
- Информация о каждой игре
Вот какие данные об отдельных играх вы можете получить:
- Результат и продолжительность игры, выбор чемпиона, использованные руны и купленные предметы
- Статистика в конце игры, такая как общий урон, нанесенный чемпионам, K / D / A и золото.
- Детализированные данные в 1-минутных срезах, например CS или XP, а также их разница с оппонентом игрока в той же роли.
- Индивидуальные события, начиная от эпического убийства монстра и заканчивая использованием варда.
Как видите, в нашем распоряжении имеется огромное количество информации по рейтинговым играм LoL, которую мы просим найти с пользой.
Хотя Riot не так общедоступен, как рейтинговый API, он также поддерживает киберспортивный API с аналогичными объектами для киберспортивных игр. Я вернусь к этому позже, поскольку сначала я сосредоточился на настройке структуры с использованием хорошо задокументированного ранжированного API.
Ограничения и использование данных
Данные, которые мы получаем от Riot, имеют форму нескольких JSON, при этом поля регулярно меняются, чтобы адаптироваться к изменениям в игре. Первым шагом было собственное хранение этой информации, чтобы иметь возможность запрашивать ее более эффективно.
Для этого мне нужно было базовое понимание того, что я буду делать с данными. Насколько я понимаю, я хотел бы запросить определенные данные из игр в моей базе данных с возможностью фильтрации их по любому полю. Это может быть предмет, чемпион или тип события. Моя база данных должна быть надежной и быстрой.
Итак, сначала я сделал то, что сделал бы любой ленивый, и изучил решения NoSQL. Я попробовал MongoDB, затем попробовал DynamoDB, но они мне не показались удовлетворительными.
Несмотря на мой очень ограниченный опыт работы с SQL, я понял, что это подходящий инструмент для этой работы, и начал с учебных пособий SQL Zoo, чтобы лучше понять его.
Первое решение
Изучение API и опробование решений NoSQL уже заняло у меня несколько дней, и я хотел быстро продвигаться вперед, чтобы как можно раньше передать результаты команде.
Поэтому я взглянул на существующие библиотеки сообщества. Я выбрал Python в качестве своего языка из-за его популярности в области науки о данных. Я выбрал PyCharm (бесплатно) в качестве своей IDE, потому что мне нравится IntelliJ, аналогичная IDE для Java.
Именно тогда я обнаружил Cassiopeia, библиотеку, созданную сообществом, включающую решение для хранения SQL. Это выглядело как находка, и я потратил некоторое время на то, чтобы заставить ее работать, прежде чем понял, что хранилище SQL не обновлено для последней версии API.
К счастью, человек, стоящий за решением для хранения SQL, мне очень помог и рассказал, что мне нужно изменить, чтобы оно работало. Я дошел до этого и с гордостью добавил логотип Splyce в список участников. Не буду лгать, было неплохо, когда я не занимался серьезной разработкой в течение 4 лет и в первую неделю использования языка - это было неплохо! Но мне жаль людей, которые помогли мне, потому что, черт возьми, я плохой ...
Что касается аппаратного обеспечения, я решил попробовать Amazon Web Services, потому что хотел использовать его один раз и посмотреть, о чем идет речь. Благодаря их щедрому бесплатному уровню я мог бесплатно установить экземпляр Linux и сервер MySQL. В будущем я могу попробовать облачное решение Google, так как в настоящее время я использую TensorFlow для анализа выбора и запрета и могу использовать для этого их оптимизированное оборудование.
Начало использования данных
К этому моменту я был хорошо настроен. На моем экземпляре t2.micro запускался парсер, вызывающий match.load () и match.timeline.load () в каждой игре, которую я хотел сохранить. Конечно, было много проблем с настройкой автоматизации и проверкой правильности работы при добавлении тысяч совпадений в час, но это было хорошее начало.
Данные в моей базе данных были хорошо организованы, и я начал их анализировать. Я написал отчет об анализе патча 9.2 для своей команды, сосредоточив внимание на данных, которые не являются общедоступными, такими как общее количество побед по рунам и предметам. Я использовал базовую реализацию алхимии SQL в Cassiopeia для прямого запроса базы данных.
Эти данные помогли нам лучше понять игру. Руна, используемая только подмножеством чемпионов с высоким процентом побед, означает, что эта группа чемпионов сильна, и повлияла на наши пики и баны на сцене. Предупреждение о спойлере: афтершок - ОП.
Используя эти данные, я быстро понял, что зеркальное отображение структуры Riot затрудняет мне анализ. Например, элементы были в полях, пронумерованных от 0 до 6, а не в отдельной таблице, а это означает, что для поиска определенного элемента мне потребовалось выполнить запрос по 7 полям. Это сделало очень тяжелые и неэффективные SQL-запросы. А поскольку имя чемпиона было отделено от статистики игрока, я постоянно присоединялся к столам с одними и теми же первичными ключами, что не имеет большого смысла.
Но я продолжал двигаться вперед, потому что хотел показать команде свою ценность и быстро предоставить данные, требующие принятия мер. Специалист по обработке данных живет и умирает из-за своего авторитета, и я думаю, что важно не потеряться в своей инфраструктуре и заставить себя регулярно доставлять полезную информацию своей команде, чтобы они понимали, что вы НЕ ПРОСТО все время злитесь на свой компьютер.
В частности, я потратил некоторое время на анализ изменений предметов стрелков, которые произошли в патче 9.3, используя простой алгоритм машинного обучения, чтобы найти оптимизированные сборки стрелков. Я не буду вдаваться в подробности здесь, так как это будет в центре моего второго сообщения в блоге, но давайте просто скажем, что я отвечал за эту сборку Коббе.
Надежность данных и киберспорт
Очень быстро я понял, что данные API не совсем надежны. API помечает игроков с ролью, и это неверно более чем в 30% случаев. Кроме того, API использует эти данные для определения дифференциалов CS и XP, поэтому эти числа тоже были ненадежными. Я быстро решил не использовать эти данные ни в одном из своих отчетов, но продолжал думать о способах исправить эту важную информацию. Спойлер, это будет сообщение в блоге №4.
Еще мне было поручено включить данные о киберспортивных играх в базу данных, так как они очень важны для тренеров.
К сожалению, API киберспорта не наделен такой же поддержкой, как рейтинговый. Есть довольно обширная неофициальная документация, но даже с ней все равно довольно сложно пользоваться. Я быстро отказался от включения любых дополнительных данных для моей первой реализации и просто использовал существующую структуру в новой базе данных для сохранения отдельных киберспортивных игр.
Еще раз, обеспечение быстрых результатов было ключевым моментом в закреплении за мной роли полезного члена команды, но я уже знал, что мне придется сделать второй проход в структуре данных.
Текущее решение
Закончив разработку скриптов для передачи данных команде, я решил начать всю разработку с нуля!
Я действительно хочу подчеркнуть, насколько важно для меня было начать с прототипирования и прочувствовать свой рабочий процесс, чтобы лучше понять инструменты, имеющиеся в моем распоряжении. Месяц назад я не имел ни малейшего представления ни о чем, связанном с Python или SQL, но непосредственное использование этих инструментов и принуждение себя к предоставлению результатов помогло мне быстро стать лучше.
На этот раз я начал с выбора правильной структуры данных для информации, которую хранил, а затем привел к ней JSON Riot. Поскольку рейтинговые и киберспортивные игры имеют очень похожую структуру, я создал абстрактные классы для общих полей и методов. Я также провел несколько тестов, чтобы убедиться, что знаю, куда иду.
Я использовал SQL Alchemy для представления всех таблиц и их взаимосвязей для упрощения запросов в Python. После создания запроса с помощью SQL Alchemy его безболезненно использовать в виде таблицы с методом pandas.read_sql ().
Имея полный контроль над процессом, я нашел много оптимизаций для своего парсера и довел скорость с 30 парсеров за минуту до 180.
Заключение
Вот инструменты, которые я использую в настоящее время:
- PyCharm как моя IDE
- SQL как моя база данных
- Sequel Pro в качестве моей программы просмотра баз данных MySQL
- Алхимия SQL как способ извлечения данных
- Pandas как мой модуль для обработки таблиц и анализа данных
- AWS в качестве моего поставщика серверов (что требует базовых знаний Bash)
- Git как моя система контроля версий
Если вы интересуетесь видеоиграми и наукой о данных, просто присоединяйтесь! Изучение этих инструментов потребует их использования для извлечения важных для вас данных. Нет лучшего учителя, чем экспериментирование.
Со своей стороны, мои следующие сообщения в блоге будут посвящены использованию машинного обучения для решения проблем, связанных с киберспортом. У меня уже было два очень интересных проекта, и они будут темой моих следующих постов!
