Демократизация PySpark для публикации мобильных игр
Zynga Analytics на Spark Summit 2020
За последние два года аналитики Zynga все чаще используют PySpark, который представляет собой интерфейс Python для платформы больших данных Spark. У нас есть центральные и встроенные аналитические группы, которые используют PySpark для поддержки операций мобильной публикации, включая аналитику и отчетность, экспериментирование, услуги персонализации и оптимизацию маркетинга. Я рассказал на Spark Summit 2020 о том, как мы открыли эту мощную платформу для всей нашей аналитической организации, и обсудил некоторые проблемы, с которыми мы столкнулись, а также новые приложения, разработанные нашей командой. В этом посте представлена текстовая версия видеопрезентации, которая доступна здесь. Наша команда инженеров по машинному обучению (ML) также представила на саммите новые приложения обучения с подкреплением.
Я выдающийся специалист по обработке данных в Zynga, и моя роль заключается в изучении новых технологий и поддержке расширения технологического стека наших аналитических групп. Эта сессия соответствует теме конференции - демократизации инструментов для искусственного интеллекта и больших данных. В Zynga мы придерживаемся этой темы, открыв экосистему Spark для всей команды аналитиков. При таком подходе мы действительно столкнулись с проблемами роста и масштабирования, но мы обсудим, как мы преодолели эти препятствия, и предоставим некоторые передовые методы масштабирования Spark в вашей аналитической организации.
Мы живем в беспрецедентное время, и виртуальная конференция в этом году отражает эту реальность. Один из способов, которыми Zynga отреагировал на пандемию COVID, - это руководство инициативой Всемирной организации здравоохранения, где мы в партнерстве с десятками издателей игр и студий распространяли информацию о социальном дистанцировании через игры. Инициатива Играйте вместе расширила круг общения о том, как оставаться в безопасности в эти трудные времена, оставаясь при этом на связи с друзьями и семьей посредством игр. Наша миссия - соединить мир с помощью игр, и я горжусь, что Zynga сыграла жизненно важную роль в этой инициативе.
В нашей команде аналитиков Zynga сейчас более 50 человек, и мы открыли платформу PySpark для всей организации. Любой, кто участвует в аналитике Zynga, теперь имеет доступ к использованию этой платформы для масштабирования анализов и моделей машинного обучения до массивных наборов данных. Открытие этого мощного инструмента помогло ускорить работу нашей аналитической организации, но мы столкнулись с несколькими проблемами и проблемами роста, поскольку все больше членов команды приняли платформу для повседневных задач, и мы выделим несколько способов решения этих проблем. . Одним из ключевых способов решения этих проблем было создание широкого набора обучающих материалов и разработка политик, обеспечивающих удобство обслуживания кластеров и контроль затрат. Хотя для открытия PySpark и стимулирования внедрения платформы потребовалось немного усилий, мы обнаружили, что наши команды использовали Spark по-новому, что привело к полезному анализу и инструментам для наших игровых команд и живых сервисов.
Zynga имеет разнообразный портфель игр, в нее встроены аналитики и специалисты по обработке данных, которые поддерживают студии, разрабатывающие эти игры. Мы называем наши игры, которые приносят более 100 миллионов долларов в год и которые, как мы ожидаем, будут процветать в течение нескольких лет, «Forever Franchises». На момент записи этой сессии у нас было 6 игр, которые соответствовали этому критерию. С тех пор наше приобретение Peak Games увеличило это число до 8, добавив в наше портфолио Toy Blast и Toon Blast.
Одна из проблем, с которой мы сталкиваемся как аналитическая организация, заключается в том, что наше портфолио игр генерирует совершенно разные наборы данных. Например, у нас есть игры в казино, игровые автоматы для социальных сетей, гоночные игры и игры в жанре «три в ряд» с различными таксономиями событий. Хотя наборы данных значительно различаются в разных играх, одной из наших целей за последние пару лет была стандартизация инфраструктуры и инструментов, которые наши встроенные группы используют для обработки этих массивных наборов данных и поиска идей для наших студий. Мы обнаружили, что Spark отлично подходит для централизованной платформы, поскольку он хорошо интегрируется со всеми нашими источниками данных и может масштабироваться для обработки огромных рабочих нагрузок.
Что касается структуры Zynga Analytics, мы объединяем в себе наши аналитические инженеры, встроенную аналитику и центральную аналитическую группу. В то время как команда представляет собой сочетание разных дисциплин, у нас есть общая цель - помочь нашим игровым командам найти идеи и персонализировать игровой процесс.
Встроенные аналитики и специалисты по обработке данных размещаются вместе со студиями, которые они поддерживают, и в тесном сотрудничестве с менеджерами по продуктам и руководством студий поддерживают запуск игр и сервисы в реальном времени. Эти группы отвечают за мониторинг производительности игр, проведение экспериментов для персонализации и изучение способов улучшения взаимодействия с пользователями наших игр. Центральная аналитическая функция, частью которой я являюсь, ориентирована на создание инструментов, которые можно масштабировать для всех наших аналитических групп, а также на поддержку таких операций публикации, как привлечение пользователей и корпоративное развитие. Обе эти группы используют нашу платформу данных, которая предоставляет возможности для отслеживания данных о событиях, обработки различных наборов данных и создания продуктов данных, которые поддерживают наши живые сервисы. Наша команда инженеров-аналитиков отвечает за создание и поддержку этой платформы, которая является основой наших аналитических возможностей.
Несмотря на то, что наша аналитическая группа выполняет множество различных функций, есть несколько общих тем, которые мы видим в разных командах с точки зрения поддержки студий как издателей игр. Первая - это одна из основных функций аналитики в Zynga, которая использует нашу платформу данных для измерения производительности игр и предоставления информации для улучшения опыта наших игроков. Вторая распространенная тема, которую мы видим, - это проведение экспериментов в наших играх и тесное сотрудничество с менеджерами по продуктам для определения результатов экспериментов и способов их использования. Третья тема - создание продуктов для обработки данных, которые обеспечивают персонализированный опыт в наших играх. Например, мы создаем модели склонности, которые предсказывают, какие пользователи могут потерять игровой процесс, и могут настраивать опыт на основе этих сигналов. Последняя тема - это маркетинговая оптимизация, которая находится на пересечении товарного маркетинга и привлечения пользователей. Хотя это, как правило, функция центральной аналитической группы, полезно использовать знания предметной области, полученные от наших встроенных аналитиков и специалистов по обработке данных, при создании моделей машинного обучения, поддерживающих эту функцию.
Наша платформа данных претерпела несколько итераций с момента основания Zynga в 2007 году, но за последние пару лет мы увидели большие и полезные изменения, поскольку мы стандартизировали инструменты, которые используют наши аналитические группы. Мы используем Vertica в качестве хранилища данных более десяти лет, и эта база данных поддерживает наши основные аналитические функции, такие как отчетность, исследовательский анализ данных и A / B-тестирование в наших играх. Хотя эта база данных была неотъемлемой частью нашей платформы данных на протяжении последнего десятилетия, многие инструменты, используемые нашими аналитиками, со временем изменились. Я классифицирую эти различные изменения в инструментах как три эпохи аналитики в Zynga.
Я называю первую эру эрой SQL, потому что аналитики и специалисты по обработке данных тратили большую часть своего времени, работая непосредственно с нашей базой данных. Сюда входили такие задачи, как построение отчетов, изучение показателей новой пользовательской воронки, вычисление результатов экспериментов и преобразование данных в удобный формат для таких задач, как прогнозирование и моделирование склонностей. Основным инструментом, используемым аналитиками в то время, была IDE для подключения к нашему хранилищу данных и выполнения запросов к нему. Хотя некоторые аналитики и специалисты по обработке данных использовали язык программирования R для построения моделей машинного обучения, не было стандартизации между различными группами встроенных аналитиков.
В 2017 году мы сформировали центральную аналитическую команду, что стало поворотным моментом в нашей стандартизации инструментов. Мы решили продвинуться вперед с Python в качестве стандартного языка для аналитики, как Zynga, и создали размещенную среду записной книжки Jupyter, где аналитики могли бы совместно работать над проектами. Мы называем это эрой ноутбуков, потому что наши аналитики начали проводить больше времени в среде ноутбуков, чем работая непосредственно с нашей базой данных. Одним из замечательных результатов было то, что использование общей размещенной среды для записных книжек означало, что было намного проще обмениваться сценариями между командами, поскольку среда имела фиксированное количество библиотек с определенными версиями. Хотя нашим командам потребовалось немного времени, чтобы использовать Python в качестве общего языка для наших аналитических групп, выгода быстро перевесила затраты на обучение наших команд, потому что командам было легче сотрудничать и было намного проще проводить анализ. во всем нашем портфолио игр, а не в отдельных играх.
Нынешняя эра аналитики в Zynga называется производственной эрой, потому что наши аналитические группы теперь используют инструменты для внедрения моделей машинного обучения в производство. Наши аналитики теперь используют PySpark для создания конвейеров пакетного машинного обучения, которые масштабируются до десятков миллионов игроков, мы создаем конечные точки и веб-инструменты с помощью Flask для поддержки игровых и издательских команд, и мы сотрудничаем с разработчиками аналитики для создания приложений в реальном времени. прогнозные модели с использованием AWS SageMaker. Вместо того, чтобы находить идеи и передавать их игровым командам, наша аналитическая группа теперь гораздо более практична в создании систем, которые обеспечивают работу сервисов на основе этих данных.
Одно из изменений, произошедших за последние пару лет, заключается в том, что мы предоставили нашим аналитическим командам более широкий доступ к инструментам, чем то, что было доступно ранее. Теперь, когда мы открыли нашу среду Spark для всей команды, мы начали с ограниченного доступа и продемонстрировали полезность платформы перед масштабированием на все Zynga Analytics. Когда мы увидели, что наши аналитики и специалисты по обработке данных могут создавать сквозные модели машинного обучения, мы захотели расширить возможности наших команд для использования этой платформы.
Было несколько причин, по которым мы хотели открыть нашу экосистему Spark для всех наших аналитиков. Одна из основных мотиваций заключалась в том, что мы хотели предоставить нашим аналитикам возможность продолжать развивать свои технические навыки и повышать уровень своих навыков. Освоение Spark и создание сквозных конвейеров - один из способов, с помощью которого аналитики могут продолжить карьерный рост в Zynga.
Еще одна мотивация заключалась в том, что мы хотели стандартизировать инструменты, которые позволили бы нашим аналитикам работать с кластерами машин, а не с отдельными экземплярами, что было ограничением в нашей экосистеме ноутбуков Jupyter. Мы используем Databricks в качестве нашей платформы Spark, которая обеспечивает управление кластером, планирование заданий и совместные записные книжки. Подобно этой мотивации, мы хотели обновить нашу платформу, чтобы охватить больше типов задач, которые выполняют наши команды. Например, некоторым командам требовалось обрабатывать большие наборы данных, которые не были доступны в нашей базе данных, а Spark имеет множество коннекторов данных, что означает, что мы можем использовать эту платформу как единое решение. Также было связано то, что мы хотели, чтобы наши команды могли масштабироваться для решения более крупных задач, таких как создание моделей склонности для всей нашей пользовательской базы, а не для одной игры или группы игроков.
Последней причиной, по которой мы хотели открыть платформу для всех наших аналитиков, было разделение прав собственности на рабочие места, выполняемые на платформе. Вместо того, чтобы наша группа инженеров-аналитиков отвечала за весь мониторинг запланированных заданий, группа аналитиков, которая настраивает задание, также отвечает за мониторинг сбоев заданий, а также за обслуживание модели. Распределение прав собственности было критически важным, поскольку мы увеличили количество заданий и задач, выполняемых на платформе.
Первая растущая проблема, с которой мы столкнулись при переходе на PySpark в качестве нашей стандартизированной платформы для крупномасштабной аналитики, заключалась в том, что нашим командам нужно было изучить PySpark, который можно описать как диалект языка Python. Хотя PySpark может запускать любую команду Python, истинный потенциал PySpark раскрывается, когда вы используете фреймы данных и библиотеки Spark, которые используют эту распределенную структуру данных, которая позволяет командам запускаться на кластере машин, а не только на одном узле драйвера.
Чтобы ускорить процесс внедрения PySpark для выполнения повседневных задач, мы начали создавать коллекцию учебных материалов, чтобы помочь нашим командам быстро освоиться в этой новой экосистеме. Наши учебные материалы включали образцы записных книжек, в которых выполняются стандартные операции, материалы для адаптации, которые мы создали для начала работы на платформе, и учебные занятия, которые мы проводим в рамках выездных командных мероприятий. Мы хотели предоставить достаточно материала, чтобы наши команды могли выполнять свои повседневные задачи на этой новой платформе.
Следующим шагом на пути к обучению на этой платформе было наставничество. В дополнение к выездным мероприятиям, которые привели к записи тренировок, мы также предоставили более прямое наставничество. У нас были рабочие часы, когда более опытные пользователи PySpark могли отвечать на вопросы членов нашей команды, которые все еще изучали платформу. Этот подход дал неоднозначные результаты, но положительным было то, что наиболее активные участники были объединены с наставниками, которые могли предоставить направленную обратную связь.
Несмотря на то, что мы пытались опередить конкурентов с точки зрения учебных материалов, по-прежнему было непросто стимулировать внедрение платформы после ее развертывания для всей команды. Мы обнаружили, что одним из лучших способов стимулировать внедрение платформы было объединение в пары разных команд, которым необходимо было использовать платформу для завершения проекта, что привело к сотрудничеству между командами. Например, у нас была команда, которая выполняла проект обучения с подкреплением в нашей среде записной книжки Jupyter, и когда мы добавили в проект нашу команду инженеров машинного обучения, специалисты по данным узнали, как они могут масштабировать свои существующие рабочие процессы, портируя их в PySpark.
Еще один способ, которым мы работали для ускорения внедрения платформы, заключался в использовании функций экосистемы PySpark, которые знакомы программистам Python, но позволяют ноутбуку работать в распределенном режиме в кластере машин. Пользовательские функции Pandas - это способ создания функций в рамках подхода разделяй и властвуй, где вы определяете, как разделить набор данных, пишете стандартный код Python для работы с подмножеством данных, а затем объединяете результаты обратно в распределенный фрейм данных. . Я обсуждал, как Zynga использует этот подход на Spark Summit 2019.
Koalas - еще одна функция PySpark, которую мы исследовали, чтобы позволить нашим аналитикам и специалистам по обработке данных перейти от программирования на Python к PySpark. Он предоставляет тот же интерфейс, что и фреймы данных Pandas, но работает в распределенном режиме. Хотя в настоящее время невозможно просто заменить эти библиотеки, чтобы заставить существующий код Python работать в кластерной среде из-за ограничений в реализации, это действительно является полезным мостом для обучения работе с распределенными наборами данных.
Мы распределили право собственности на конвейеры данных для моделей машинного обучения, что позволило нашей команде аналитиков на порядок увеличить количество моделей, находящихся в производстве. В то время как наш предыдущий подход заключался в том, чтобы специалисты по обработке данных создавали спецификации моделей и передавали их нашей группе инженеров-аналитиков для производства, наша новая модель заключается в сотрудничестве между этими командами, а аналитики и специалисты по обработке данных должны владеть большим количеством аспектов DevOps для живых моделей машинного обучения. У нас есть несколько подходов к запуску моделей в производство, например создание пакетных конвейеров, которые отправляют прогнозы в нашу базу данных приложения, или партнерство с инженерами машинного обучения для настройки модели в качестве конечной веб-точки с помощью AWS SageMaker. Хотя наши аналитики и специалисты по данным не несут ответственности за мониторинг инфраструктуры, на которой работают эти модели, они несут ответственность за мониторинг времени безотказной работы и производительности моделей, обслуживающих прогнозы.
Еще один способ сделать платформу более доступной для нашей команды - создать внутреннюю библиотеку, которая выполняет общие функции, необходимые нашим аналитическим группам. Это включает в себя чтение и запись в различные источники данных, а также публикацию результатов машинного обучения в нашей базе данных приложения, где прогнозы могут использоваться нашими живыми службами. Мы также создали несколько инструментов для обслуживания моделей, но по мере развития библиотеки и расширения возможностей мы перешли на MLflow.
Когда мы открыли платформу для большего количества членов команды, одной из проблем, с которыми мы столкнулись, были конфликты в версиях библиотек в разных записных книжках. Мы также не хотели наращивать кластер для каждого пользователя, потому что затраты могли бесконтрольно расти. Мы выбрали политику, в которой интерактивные кластеры имеют фиксированные версии библиотек, а запланированные задания настроены для работы на эфемерных кластерах, то есть запланированные задания не мешают другим задачам. Кроме того, для групп, работающих над новыми рабочими процессами, группа может запросить кластер разработки для тестирования рабочего процесса перед переходом к запланированному заданию, выполняемому в эфемерном кластере.
Несмотря на то что мы передали право собственности встроенным командам, выполняющим задания, у нас все еще был пробел в определении владельцев рабочих мест. Прежде чем открыть платформу для всех команд, мы провели аудит существующих заданий и убедились, что все выполняемые задания производят результаты, которые используются нашими игровыми командами. После завершения аудита мы настраиваем процесс планирования новых заданий. Теперь для выполнения заданий требуются владелец, резервный владелец и псевдоним команды, и мы собираем журналы, в которых выходные данные модели активно используются игровыми студиями. Для задач, которые мы планируем выполнять в долгосрочной перспективе, мы переносим рабочий процесс в Airflow, где у нас есть надежный мониторинг.
Еще один урок, который мы усвоили, касался отслеживания затрат. Мы создали увлеченную команду на новой платформе, и наша команда стремилась использовать такие функции, как графические процессоры, для обучения сетей глубокого обучения. Хотя любой может подключать записные книжки и запускать скрипты PySpark, мы ограничили создание кластеров нашей группой инженеров машинного обучения, которая является частью аналитического инжиниринга. Чтобы контролировать расходы, мы помечаем все кластеры с помощью скриптов, чтобы убедиться, что мы можем отслеживать расходы. Мы также закрываем старые кластеры и отказываемся от кластеров для конкретных проектов по мере необходимости. Наша цель - избегать длительно работающих кластеров, требующих определенных библиотек, и вместо этого настраивать общие кластеры с современными библиотеками.
Мы открыли шлюзы для этой новой платформы, но потребовалось некоторое подталкивание, чтобы заставить команды исследовать эту платформу. Хотя это была среда для ноутбуков, похожая на Jupyter, у нее также были проблемы. Например, задержка выполнения задач в Spark привела к сложным упражнениям по отладке для нашей команды. Вместо немедленного сбоя задачи сценарий может выполнить несколько шагов до сбоя.
Хотя наш первоначальный подход заключался в том, чтобы использовать канал Slack в качестве универсального решения для вопросов Spark, мы обнаружили более высокое отношение сигнал / шум, когда объединили новых пользователей Spark с опытными пользователями Spark. Мы также сосредоточились на межкомандном сотрудничестве, чтобы убедиться, что у нас есть сочетание разных уровней опыта, которые мы работаем над проектами.
Одним из первых проектов, в которых мы добились успеха с внедрением PySpark, была система AutoModel, которая ежедневно строит сотни моделей склонностей. Это сквозной рабочий процесс, который извлекает данные из нашего озера данных, применяет автоматизированную разработку функций с помощью библиотеки Featuretools и обучает модели классификации с помощью библиотеки MLib, входящей в состав Spark. Результатом рабочего процесса являются прогнозные оценки, которые записываются в нашу базу данных приложения, которая построена на Couchbase. После публикации результатов в Couchbase наши игровые команды могут использовать прогнозируемые значения для проведения экспериментов и персонализации игрового процесса. Хотя у нас было несколько вариантов использования этой системы, которая создает вероятность отклонения и вероятность покупки прогнозов для всех наших игр, наши менеджеры по продукту придумали новые приложения для этих прогнозных значений, которых мы не ожидали.
Другой вариант использования PySpark в Zynga - использование наших данных для сегментирования игроков по разным архетипам, что позволяет нам лучше понять нашу базу игроков. Хотя некоторые встроенные аналитики выполняли такую работу для конкретных игр, обычно это выполнялось как разовое упражнение, а не как запланированная задача, которая предоставляет актуальные сегменты для наших игровых команд. Мы смогли использовать PySpark, чтобы запустить эти модели сегментации в производство, что позволило использовать эти сегменты в нашем экспериментальном стеке. Хотя у нас было меньше алгоритмов в MLlib по сравнению с scikit-learn для кластеризации игроков, мы смогли стандартизировать наш подход и применить этот конвейер к нескольким играм в нашем портфолио.
Наши аналитические группы участвовали в хакатонах за последние несколько лет, и это была прекрасная возможность для наших аналитиков опробовать проекты на PySpark. Одним из новых приложений, появившихся в результате этих проектов, была система обнаружения аномалий, в которой использовалось глубокое обучение. Система кодирует действия пользователя как одномерное изображение, использует автокодер для сжатия изображения до скрытого пространства, а затем использует автокодер для распаковки изображения. Игроки, у которых есть большие расхождения между входным и выходным изображениями, затем исследуются дополнительно. Хотя этот рабочий процесс был ограничен одной машиной, а не кластером, наша команда смогла воспользоваться преимуществами больших экземпляров, настроенных с помощью графических процессоров, для быстрого выполнения итераций по моделям Tensorflow. Это один из замечательных способов, благодаря которым открытие этой платформы действительно помогло в работе, которую мы изучаем.
С PySpark мы столкнулись с тем, что он позволяет проводить анализ в масштабе портфолио, когда подход, разработанный для конкретной игры, часто может быть применен к нескольким названиям. Одним из примеров этого был проект по моделированию экономики, который изначально был исследован нашими командами аналитиков игровых автоматов. Хотя первоначальная версия этого рабочего процесса была специфична для этого жанра игр, команда смогла обобщить моделирование игровой экономики в виде цепей Маркова и перенесла подход на использование фреймов данных Spark. В результате появился метод, который можно было использовать для моделирования в нескольких наших играх.
Хотя большинство обнаруженных нами новых приложений были ориентированы на построение конвейеров машинного обучения, мы также обнаружили, что PySpark был полезен для масштабирования рабочих нагрузок для других типов числовых вычислений. С помощью пользовательских функций Pandas мы смогли взять существующие записные книжки и использовать разделение и побеждающий подход, позволяющий запускать код одновременно на кластере машин. Это позволило нам выполнять распределенную работу с библиотеками scipy, numpy и statsmodels и помогло с задачами масштабирования, такими как измерения значимости для A / B-тестирования.
Я также хотел продемонстрировать один из других проектов в Zynga, это наш конвейер обучения с подкреплением под названием RL Bakery. Хотя этот рабочий процесс не использует PySpark напрямую, мы обнаружили, что некоторые из наших специалистов по обработке данных использовали Spark для автономного обучения моделей глубокого обучения, и нам нужен был конвейер для обслуживания этих моделей в режиме реального времени и для предоставления обновлений моделей в режиме онлайн. Мы использовали этот конвейер для обслуживания моделей обучения с подкреплением в производстве как для Word With Friends 2, так и для CSR Racing 2, а примеры приложений включают время уведомления.
Возвращаясь к выводам этого занятия, мы открыли нашу инфраструктуру Spark для всех наших аналитических групп, и в результате появились новые приложения для игровых студий, которые теперь поддерживают живые сервисы. Хотя для ускорения внедрения платформы потребовалось некоторое время, мы набрали обороты, поскольку все больше членов команды начали использовать платформу, и мы сосредоточились на межкомандных проектах, которые смогли использовать PySpark для быстрого масштабирования. Мы также столкнулись с проблемами при управлении кластерами машин и версиями библиотек, а также с удержанием затрат на одном уровне, но улучшение результатов окупилось. Демократизация PySpark в Zynga дала возможность нашей аналитической организации решать новые и крупномасштабные проблемы, а также дала возможность нашим аналитическим командам освоить больше инструментов для работы с большими данными.
Спасибо, что следили за этой сессией. Zynga analytics принимает на работу, и вы можете найти список открытых вакансий здесь.
