Обзор проекта

Sparkify – это музыкальное приложение. Этот набор данных содержит журнал поведения пользователей sparkify за два месяца. Журнал содержит некоторую основную информацию о пользователе, а также информацию об его действиях. Пользователь может содержать много записей. В данных часть пользователя сбивается через аннулирование учетной записи.

Я загрузил детали своего анализа в репозиторий GitHub.

Посмотреть код на GitHub: здесь

Чему вы научитесь

Основная цель этой статьи — проиллюстрировать интерфейс SQL, который предоставляет PySpark, и его возможности машинного обучения. Здесь мы пытаемся проиллюстрировать, что если вы уже знакомы с SQL и библиотекой scikit-learn, вы можете легко расширить свой анализ машинного обучения на более крупные наборы данных (т. е. наборы данных, которые не помещаются в память одного машина).

Постановка задачи

Задача проекта — найти характеристики ушедших пользователей по поведенческим данным этих пользователей и принять меры для удержания потенциально потерянных пользователей как можно раньше.

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

Давайте запустим сеанс Spark и загрузим его в рабочее пространство Jupyter Notebook.

Ниже приведен код, который я использовал для локального создания искрового сеанса.

Для загрузки данных из файла json с помощью искры я использовал следующий код.

Предварительная обработка данных

Поведенческие данные отличаются от окончательных обучающих данных, и нам нужно очистить некоторые значения, которые мы не рассматриваем. Если UserId и sessionId равны нулю, становится трудно анализировать. Поэтому нулевое значение необходимо удалить.

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

Это строки, которые я использовал для удаления значений NaN и пустых строк в userId.

Исследовательский анализ данных

Когда мы изучаем данные, мы можем обнаружить, что все данные о событиях регистрируются в атрибуте `page`, который является одной из наиболее важных функций в нашем анализе. мы можем сказать, что отток пользователей может произойти, когда пользователь посещает страницу подтверждения отмены. поэтому мы определим нашу целевую переменную, используя событие «подтверждение отмены» на странице, поэтому, если он сбивает пользователя (1), иначе нет (0).

Давайте рассмотрим функцию страницы, которая имеет переменную «Подтверждение отмены», из которой мы можем получить нашу целевую переменную, т. е. отток или нет?

Мы рассмотрели каждое распределение функций, и большинство из них искажены. Наша целевая переменная (отток) несбалансирована. И так обстоит дело с большинством реальных наборов данных.

Разработка функций

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

Как мы видели, большинство переменных перекошены и несбалансированы по отношению к классу или целевой переменной. Мы придумали некоторые из перечисленных ниже функций, которые мы использовали в нашей модели.

  • Добавить в плейлист
  • Время использования (с использованием длины и следующей песни)
  • Добавлено больше друзей
  • Пользователь, который использовал опцию Thumbs Up или Down
  • Попросил о помощи
  • Платный пользователь или бесплатный пользователь
  • Пониженная версия и пол
  • Среднее количество зарегистрированных сеансов.

Ниже представлена ​​визуализация функций, которые мы рассмотрели.

Мы получили функцию, которая, по нашему мнению, в основном хорошо предсказывает цель, то есть отток, и будем использовать эту функцию для тестирования/обучения нашей модели.

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

Я объединил все таблицы и создал новую таблицу, чтобы использовать ее для окончательного обучения модели.

Проверим корреляцию между всеми выбранными столбцами перед обучением модели

Моделирование

В процессе своего многократного обучения я думал, что после перезапуска ядра и повторного чтения данных скорость обучения будет существенно выше.

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

Хотя это не влияет на древовидную модель, стандартизация важна для линейных моделей. Я решил стандартизировать данные.

Для обучения я использовал линейную модель и древовидную модель, включая логистическую модель, случайный лес и классификатор GBT. Я выбираю модель с наилучшей производительностью, делю тестовый набор с помощью 3-кратной перекрестной проверки и поиска по сетке, чтобы определить параметры модели для обучающего набора. Наконец, я использую проверочный набор для оценки производительности модели.

Мы разделили набор данных функций и целевых переменных на обучение, тестирование, построили конвейер и внедрили различные модели машинного обучения. Поскольку удаленные пользователи представляют собой довольно небольшое подмножество, мы использовали показатель F1 в качестве метрики для оптимизации и обнаружили, что классификатор GBT является лучшей моделью по сравнению с другими.

Результат

Мы разделили набор данных функций и целевых переменных на обучение, тестирование, а затем построили конвейер и, наконец, внедрили 3 модели машинного обучения.

Я использовал приведенные ниже функции для определения оценки F1 и точности моделей.

Точность и оценка F-1 прикреплены к изображению.

Код, используемый для определения точности тестового набора данных.

Точность каждой модели в тестовом наборе данных.

Logistic Regression Classifier Accuracy:0.8430953322074095
Random Forest  Classifier Accuracy:0.9638506593840958
GBT-Classifier  Classifier Accuracy:0.9915196377879191

Код, используемый для нахождения оценки f-1 в тестовом наборе данных.

Оценка F1 каждой модели в тестовом наборе данных:

Logistic Regression Classifier F1-Score:0.7765470592259909
Random Forest  Classifier F1-Score:0.9619697735890758
GBTClassifier  Classifier F1-Score:0.9914322037770119

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

Вывод

Резюме

В этой записной книжке я реализовал модель для прогнозирования оттока клиентов. В процессе очистки данных я удалил строки без user_Id, преобразовал пол в двоичный числовой столбец. Для нашей модели было построено 10 функций. Мы выбрали 3 модели: логистическая регрессия, случайный лес и классификатор GBT для прогнозирования оттока, и, наконец, мы выбрали классификатор GBT в качестве окончательной модели, реализованной для прогнозирования конечного результата, из-за его хорошей оценки F1. Для подготовки данных и отправки в модель я использовал VectorAssembler, который представляет собой преобразователь, объединяющий заданный список столбцов в один векторный столбец. Поскольку удаленные пользователи представляют собой довольно небольшое подмножество, мы используем показатель F1 в качестве метрики для оптимизации.

Отражения от этого финального проекта.

Этот проект предоставил доступ к среде PySpark для анализа большого объема данных, который персональный ноутбук может не проанализировать. Выявляя клиентов с высокой вероятностью оттока до фактической потери, компании могут использовать минимальные затраты для сохранения клиентов, используя целевые сообщения и предложения.

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

Чтобы избежать оттока в будущем, необходимо следовать следующим инструкциям.

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

  • Запуск некоторых рекламных предложений для привлечения целевых пользователей.
  • И выяснить, в чем основная причина того, что этим пользователям не нравится приложение «Музыка» и они пытаются импровизировать. Пример: например, изменения пользовательского интерфейса, цена подписки и т. д.

Улучшения

Функции могут быть значительно улучшены после рассмотрения большего количества факторов, добавления дополнительных знаний и опыта в предметной области. Хотя для анализа объема данных могут потребоваться такие инструменты, как PySpark, мы можем использовать больше данных, чтобы получать лучшие результаты по мере роста пользовательской базы.

На данный момент у нас есть около 223106 записей уникальных пользователей, и мы используем только 80% из них для обучения. Тем не менее, модель имеет огромный потенциал для улучшения, если размер выборки увеличится, и ожидаемая производительность также возрастет.

Я загрузил данные своего анализа в репозиторий GitHub.

Ознакомьтесь с кодом на GitHub: здесь