В этом посте я обсуждаю свой проект Udacity Data Scientist Nanodegree Capstone. Udacity предлагает множество различных вариантов, включая проект «больших данных» с использованием Apache Spark.

Эта статья начинается с краткого обзора проблемы, рассматриваемой в проекте Capstone, включая краткое обсуждение того, почему прогнозирование или предотвращение оттока клиентов имеет значение, что такое (в очень кратком выражении) большие данные и как Apache Spark вписывается в мир больших данных. .

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

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

Введение

Для этого проекта Udacity в сотрудничестве с Insight Data Science предоставили смоделированные данные журнала пользователей, сгенерированные вымышленным сервисом потоковой передачи музыки под названием Sparkify. Цель этого проекта — использовать эти данные для обучения модели бинарной классификации, которая будет предсказывать на основе действий конкретного пользователя до сих пор, подвержены ли они высокому риску оттока.

Основные проблемы, которые подробно обсуждаются ниже в этом проекте, были связаны с использованием Spark (вместо Pandas, как в случае проекта с набором данных малого и среднего размера).

Зачем прогнозировать отток?

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

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

Согласно https://smallbiztrends.com/2016/10/customer-retention-statistics.html, снижение коэффициента оттока на 5 % может повысить прибыльность на 25–125 %, что, по общему признанию, довольно приблизительная оценка, но она предполагает, что удержание клиентов должно быть серьезной проблемой для бизнеса.

Другая проблема заключается в том, что, как отмечает Кейси Хилл в своем ответе на https://www.quora.com/Why-is-churn-so-important, высокий уровень оттока может сделать невозможным развивать бизнес и может рассматриваться как показатель того, что с продуктом что-то не так.

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

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

Краткий обзор больших данных и Spark

Число, часто цитируемое для иллюстрации огромных масштабов создания данных в настоящее время, заключается в том, что 90% сегодняшних данных были созданы за последние два года. По данным Domo, Inc., по состоянию на 2017 год в среднем за два последних года было сгенерировано 2,5 квинтиллиона байт данных. Очевидно, что такие цифры могут быть только оценочными, но они достаточно хорошо показывают, что в настоящее время генерируются огромные массивы данных.

Как показывает успех таких компаний, как Google, Facebook и Amazon, использование огромных объемов данных позволяет создавать новые интересные бизнес-модели. Особенно, когда вы думаете о сложных моделях машинного обучения, должно быть очевидно, что большие наборы данных могут иметь огромную ценность.

Что такое большие данные?

После всего сказанного у вас может возникнуть вопрос, что именно можно считать большими данными. Без сомнения, этот термин был таким же модным словом, как ИИ или блокчейн, которые, по-видимому, все так или иначе используют. Некоторое время назад я даже видел довольно забавное объявление о вакансии «аналитика больших данных», которое требовало от соискателей только знания Excel.

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

Самым простым не слишком техническим определением было бы «набор данных, который слишком велик, чтобы поместиться в память вашего обычного компьютера дома или на работе, и, следовательно, требует использования распределенных вычислений».

Gartner определяет большие данные следующим образом:

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

Это более формальное определение содержит первоначальные три V больших данных: объем, скорость и разнообразие. В наши дни вы, вероятно, столкнетесь с 5 или 6 Vs больших данных с достоверностью (надежностью данных), ценностью и изменчивостью. добавляются в качестве дополнительных измерений.

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

Ссылки и дополнительная информация о больших данных

Определение больших данных Gartner: https://www.gartner.com/en/information-technology/glossary/big-data

Отличное введение в большие данные с очень полезной диаграммой шести противоречий больших данных: https://searchdatamanagement.techtarget.com/definition/big-data.

Oracle также предлагает хорошее введение по теме: https://www.oracle.com/big-data/guide/what-is-big-data.html

Статья о переходе от первой эры больших данных к новой: https://www.kdnuggets.com/2019/07/death-big-data-multi-cloud-era.html

Как Spark вписывается в это?

Теперь, когда я в очень общих чертах определил, что такое большие данные и почему они должны вас интересовать, позвольте мне очень кратко рассказать о том, как Apache Spark вписывается во все это.

На официальном сайте Apache Spark определяется следующим образом:

Apache Spark™ – это унифицированный аналитический механизм для крупномасштабной обработки данных.

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

Официальный сайт называет его скорость, простоту использования, универсальность и способность работать «везде» как свои сильные стороны.

Что касается простоты использования, рассмотрим этот пример:

Вы можете видеть, что очень легко настроить сеанс Spark и прочитать файл. Spark также предоставляет чрезвычайно полезный API-интерфейс Spark SQL, который позволяет вам использовать фрейм данных SQL или Pandas, например фреймы данных Spark, для работы с вашими данными, подобным этому.

Apache Spark также позволяет вам использовать алгоритмы машинного обучения (ограниченные линейно масштабируемыми с объемом данных) в ваших больших наборах данных способом, очень похожим на scikit-learn.

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

Если вы хотите начать использовать Spark, обязательно ознакомьтесь с курсом Udacity по PySpark.

Работа над проектом Capstone.

Udacity и ее отраслевой партнер Insight Data Science (поставщик программ стипендий для науки о данных, инженерии данных и т. д.) предоставили смоделированные данные журнала пользователей вымышленного сервиса потоковой передачи музыки под названием Sparkify.

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

В следующих абзацах я расскажу вам, как я подошел к этому проекту.

Техническая настройка и проблемы

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

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

Поэтому я использовал Spark в локальном режиме на своем компьютере и провел исследовательский анализ, используя гораздо меньшую версию набора данных всего 128 МБ вместо 12 ГБ полного набора данных.

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

Убедившись, что весь код правильно работает на моем локальном компьютере, я настроил кластер Amazone Web Services (AWS) Elastic Map Reduce (EMR) и перенес свой локально созданный блокнот Jupyter в кластер.

Я решил использовать кластер AWS EMR, потому что это избавляет вас от необходимости вручную устанавливать Spark и все настраивать. Курс Udacity Spark также предоставляет пошаговую информацию о том, как зарегистрироваться в AWS и как настроить кластер EMR.

Как локальное использование Spark, так и его использование в кластере EMR сопровождалось некоторыми незначительными проблемами:

  • При локальном использовании с небольшим набором данных я сначала обнаружил, что Spark ужасно медленный. Хотя ясно, что из-за необходимой функции, такой как избыточность, он всегда будет медленнее, чем Pandas, оказалось, что, как объяснено на https://stackoverflow.com/questions/55721767/spark-streaming-job-is-running -very-slow, количество разделов по умолчанию может быть узким местом в локальном режиме.
  • При использовании блокнотов Jupyter в кластере AWS EMR графики будут отображаться только в том случае, если вы используете специальную волшебную команду «%matplot plt».
  • При работе на кластере некоторые операции могут выполняться довольно долго. Чтобы предотвратить умирание вашего сеанса, вы можете увеличить heartbeatInterval исполнителя Spark, как это предлагается в https://stackoverflow.com/questions/38417441/pyspark-socket-timeout-exception-after-application- бег на время.
  • В частности, поиск по сетке перекрестной проверки для настройки гиперпараметров может быть удручающе медленным при использовании большого набора данных. Поэтому я советую быть очень осторожным при установке достаточно высокого значения heartbeatInterval, чтобы ваша сессия Spark не умерла до того, как все ваши задания Spark будут выполнены.

Таким образом, несмотря на относительную простоту использования, использование Spark и его развертывание в кластере иногда может быть довольно утомительным и занимать много времени.

Загрузка и очистка данных

Используя код, показанный выше в разделе, посвященном Spark, я загрузил сокращенный набор данных.

Первоначальный взгляд на схему показывает, что есть 18 столбцов:

Одним из первых важных шагов, которые необходимо предпринять при очистке данных, является определение отсутствующих значений. PySpark SQL имеет как функцию isnan, так и функцию isnull. Кроме того, пустые значения могут быть еще одним очевидным способом кодирования отсутствующих значений. Таким образом, мой код для определения пропущенных значений выглядел так:

Результат был следующим:

Здесь было два типа отсутствующих значений:

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

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

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

В случае небольшого набора данных в среднем было 1236,24 взаимодействия (строки) на пользователя, а всего было 225 уникальных пользователей. Полный набор данных содержит информацию о 22 278 пользователях.

На следующем графике показано распределение количества взаимодействий на пользователя.

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

Чтобы получить общее представление о данных, я кратко рассмотрел распределение полов как на уровне взаимодействия, так и на уровне пользователя, количество посещений страниц и распределение дат в наборе данных:

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

Наконец, давайте кратко рассмотрим распределение дат в данных, измеренное в комбинациях год-месяц:

Получается, что данные журнала Sparkify состоят по сути из данных, собранных в октябре 2018 года и ноябре 2018 года почти в равных пропорциях (144 707 и 133 288 строк соответственно). Также имеется около 159 наблюдений за декабрь 2018 года.

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

Определение оттока для пользователей Sparkify

Учитывая, что сервис Sparkify предлагает два типа членства (бесплатное и платное), можно утверждать, что существует два типа оттока: те, кто сдал все вместе, и те, кто только понизил свой аккаунт с платного до бесплатного. .

Я решил рассмотреть только первое, потому что второе продолжало пользоваться сервисом. Следовательно, они по-прежнему приносят (хотя и меньшие) доходы и еще не теряются. Поэтому я бы сказал, что экономические потери, связанные с ними, значительно ниже. Кроме того, поскольку эти пользователи не покидают службу полностью, отправка им опроса с вопросом, почему они понижены, и обращение с ними таким образом также может быть жизнеспособной стратегией.

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

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

Используя UDF (определяемую пользователем функцию) и разбиение по идентификатору пользователя, мы можем идентифицировать churners следующим образом (при условии, что вы импортировали необходимые функции):

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

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

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

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

Чтобы решить эту проблему, нам потребуется создать агрегированные показатели, которые учитывают большое количество строк для каждого пользователя и объединяют их в одну строку.

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

В целом, я рассмотрел следующие совокупные характеристики:

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

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

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

Это можно легко сделать в Spark следующим образом:

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

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

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

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

Подготовка данных для машинного обучения

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

  • Удаление выбросов числовых признаков с использованием межквартильного диапазона в качестве моего критерия для выявления выбросов
  • Применение мин-макс масштабирования к числовым функциям
  • Применение одноразового кодирования к категориальным функциям
  • Сбор всех признаков в векторном столбце

Я решил использовать межквартильный диапазон в качестве критерия для выбросов, поскольку он позволяет легко идентифицировать. Что касается масштабирования числовых признаков, я выбрал мин-макс масштабатор, чтобы сохранить исходное распределение, как обсуждалось на https://stackoverflow.com/questions/51237635/difference-between-standard-scaler-and-minmaxscaler.

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

Разделение между поездами и тестами

Учитывая довольно большой набор данных, я решил использовать 90%-10% разделение данных для обучения поездов.

Выбор модели

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

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

Для выявления лучшей модели я решил сравнить следующие алгоритмы:

  • Логистическая регрессия
  • Случайный лесной классификатор
  • Классификатор деревьев с градиентным усилением
  • Классификатор опорных векторов (линейное ядро)
  • Классификатор дерева решений
  • Наивный байесовский классификатор

Создание и обучение этих моделей очень похоже на работу с scikit-learn:

Оценка F1 для разных моделей выглядит следующим образом:

  • Логистическая регрессия: 77,57%
  • Случайный лесной классификатор: 68,62%
  • Классификатор деревьев с градиентным усилением: 81,32%
  • Классификатор машин опорных векторов (линейное ядро): 68,49%
  • Классификатор дерева решений: 81,18%
  • Наивный байесовский классификатор: 68,49%

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

Настройка гиперпараметров

Чтобы еще больше повысить производительность выбранной модели, я выполнил настройку гиперпараметров с помощью поиска по сетке параметров. Это можно сделать так же легко в PySpark, как и в scikit-learn:

Это, к сожалению, привело к значительному ухудшению производительности модели: оценка F1 упала с 81,32% до 68,49%. Вероятно, это связано с недообучением, поскольку только 4 405 из 22 278 в полном наборе данных были изменены.

Поэтому я решил скорее использовать «неоптимизированную» версию модели, чем недостаточно приспособленную «оптимизированную».

Результаты и интерпретация

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

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

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

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

Возможные улучшения и дополнительные мысли

Хотя в целом я доволен тем, как получился проект, очевидно, что есть еще немало областей, которые потенциально можно улучшить.

Оказалось, что даже для полного набора данных было всего 22 278 пользователей, из которых только 4 405 ушли. Это, в свою очередь, приводило к недообучению при использовании перекрестной проверки. Следовательно, если возможно, следует собрать больше данных.

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

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

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

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

Вывод

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

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

Затем я представил пошаговое руководство по моему проекту Capstone, которое дало вам представление о том, как может выглядеть проект с PySpark, и с какими проблемами вы можете столкнуться при работе со Spark и данными журнала пользователей.

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

Несмотря на эти трудности, я нашел этот проект очень интересным. Я надеюсь, что этот пост также пробудил в вас интерес к началу работы с большими данными и Spark, а также к расширению вашего кругозора как специалиста по обработке и анализу данных, начиная с работы с наборами данных малого, среднего и большого размера.

Если вас интересуют более подробные сведения о моем проекте и весь код, загляните в мой репозиторий GitHub для этого проекта по адресу https://github.com/hendrik-sill/DSND-Sparkify-Capstone-Project.