Авторы Шобана Нилакантан, Арид Четтали, Виньеш Радж, Снеха Прабху и Вивек Патхане
Вступление
В настоящее время PayPal переводит свои аналитические рабочие нагрузки на Google Cloud Processing (GCP). В этом посте я расскажу о различных подходах, которые мы оценили для миграции наших процессов из локальной среды в GCP.
Мы выполняем ряд заданий Spark для обработки аналитических данных в PayPal. Эти задания собирают поведенческие данные с веб-сайта и переупаковывают их в формат, пригодный для использования аналитиками и специалистами по данным. В рамках миграции GCP мы оценили различные подходы, такие как потоковая передача данных в BigQuery (BQ), перенос всей обработки в BigQuery, выполнение существующего искрового задания в кластере DataProc с использованием данных BigQuery и использование нашего облачного хранилища Google (GCS ) Данные. Давайте углубимся в различные подходы, оцениваемые для одного такого процесса - сеанса.
Что такое процесс сеанса?
Допустим, пользователь посещает веб-сайт PayPal, входит в свою учетную запись и переводит деньги другу. Они проверяют баланс своего счета и выходят из системы. Это некоторые действия (события) пользователя, которые происходят в сеансе, и для каждого из них запускается событие. Процесс создания сеансов объединяет все события из одного пользовательского сеанса и обеспечивает их сводное представление. Он состоит из такой информации, как время начала сеанса, время окончания сеанса и количество событий в сеансе.
Как это делается на месте?
Все обработанные данные о поведении доступны в распределенной файловой системе Hadoop (HDFS). Эти события группируются на почасовом уровне в зависимости от времени события. Искровое задание считывает пакетные данные на стороне клиента и выполняет групповую операцию на основе идентификатора пользователя и идентификатора сеанса. Идентификатор пользователя однозначно определяет пользователя, а идентификатор сеанса используется для идентификации каждого сеанса.
В зависимости от времени окончания сеанса сгруппированные события разделяются на завершенные сеансы и текущие сеансы. Все завершенные сеансы записываются в окончательный результат, а текущие сеансы записываются во временное место. В начале каждого запуска выполняется объединение для текущего набора данных и нового пакета поведенческих данных. База данных SQL используется для управления состоянием этого задания.
Варианты, рассматриваемые для GCP
Запуск задания Dataproc для данных BigQuery
Запуск задания Dataproc для данных GCS
Выполнение задания BigQuery SQL
Выполнение задания Dataproc для данных BigQuery
Все пользовательские данные доступны в таблицах BigQuery. Эти данные можно закачать в кластер DataProc с помощью библиотеки коннектора Spark-BigQuery (Github). То же самое искровое задание, которое выполнялось локально, можно переназначить для работы в кластере DataProc. Ту же библиотеку коннекторов можно использовать для записи данных обратно в BigQuery.
Преимущество этого варианта в том, что мы можем повторно использовать существующее искровое задание. Но есть дополнительный этап ввода / вывода и затраты, связанные с перемещением данных из BigQuery для обработки. Поскольку кластер DataProc недолговечен, для подготовки кластера для каждого запуска требуется дополнительное время.
Запуск задания Dataproc для данных GCS
Помимо BigQuery, пользовательские данные доступны и в GCS. Искровое задание можно запустить на этих данных GCS в кластере DataProc с помощью коннекторов DataProc Hadoop (Github). Обработанные данные можно записать обратно в BigQuery.
Этот вариант очень похож на предыдущий и имеет те же преимущества. Единственными затратами, связанными с этим подходом, будет выполнение задания DataProc.
Выполнение задания BigQuery SQL
Существующие задания Spark SQL необходимо переписать с использованием BQ SQL для этого параметра. BQ SQL использует преимущества существующей инфраструктуры BigQuery для обработки. Если за задания BigQuery выставляются счета по запросу, этот подход будет дороже, чем указанные выше варианты.
Сравнение производительности
Мы запустили три обсуждаемых выше варианта на разных пакетах данных. Каждый пакет данных содержит ~ 75 ГБ пользовательских данных, хранящихся в BigQuery или GCS. Время, затраченное на каждый подход, можно увидеть на графике ниже.
Выполнение задания BQ SQL обеспечивает лучшую производительность среди трех вариантов. В среднем обработка одного пакета данных с помощью BQ SQL занимает около 2 минут. DataProc в GCS имеет лучшую производительность, чем DataProc в BigQuery.
Сравнение затрат
Стоимость каждого из трех вариантов обработки одних и тех же данных можно увидеть на изображении ниже. Стоимость DataProc-BQ состоит из затрат, связанных как с запуском задания DataProc, так и с извлечением данных из BigQuery. Стоимость BQ SQL рассчитывается согласно расценкам по запросу. Если в BigQuery предусмотрены выделенные слоты, стоимость выполнения BQ SQL будет меньше.
Заключение
BQ SQL намного быстрее DataProc с точки зрения производительности, и было бы лучше, если бы выделенные слоты уже были выделены. Задание DataProc с чтением GCS может рассматриваться как жизнеспособный вариант, если стоимость является проблемой.
