//Миграция хранилища данных PayPal на Google BigQuery

Миграция хранилища данных PayPal на Google BigQuery

Абстрактный

PayPal продемонстрировал рекордный рост с начала глобальной пандемии. Чтобы не отставать от растущего спроса, мы решили перенести платформы PayPal Analytics в общедоступное облако. Первая крупная миграция рабочей нагрузки хранилища на BigQuery в Google Cloud заняла менее года. Попутно команда PayPal создала платформу, которая будет поддерживать и многие другие варианты использования.

В этой записи описан опыт миграции. Мы перенесли половину наших данных и обработки из систем Teradata в BigQuery Google Cloud Platform.

Вступление

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

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

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

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

Контекст

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

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

PayPal локально управляет двумя кластерами хранилищ данных на основе поставщиков, с общим объемом хранилища 20+ петабайт, обслуживающим более 3000 пользователей. Требования к емкости постоянно росли, поскольку данные становились критически важными для бизнес-решений. Хранилище аналитики было ограничено хранилищем и ЦП, а основное хранилище было ограничено вводом-выводом и хранилищем.

Сценарии использования хранилища в целом можно разделить на интерактивные и пакетные рабочие нагрузки. Интерактивные рабочие нагрузки включают специальные запросы от пользователей, использующих Jupyter Notebooks, а также отчеты и информационные панели с использованием инструментов бизнес-аналитики, таких как Tableau и Qlikview. Пакетные рабочие нагрузки планируются с помощью Airflow и UC4. Рабочие нагрузки в основном написаны на SQL и выполняются с использованием сценариев оболочки или Python.

Из-за проблем, возникших по мере роста трафика, многие задания по преобразованию и пакетные загрузки выполнялись с отставанием от графика. Аналитики и специалисты по обработке данных PayPal видели, что данные далеко отставали от их соглашений об уровне обслуживания (SLA), что ухудшало качество обслуживания, и все это задерживало принятие решений. Из двух основных хранилищ PayPal решила сначала перенести хранилище аналитики на BigQuery, чтобы испытать использование сервиса в качестве замены Teradata, и в процессе создания платформы на основе сервисов Google Cloud Platform для пользователей данных PayPal. Основной склад будет перенесен позже на основе Усвоение и опыта со склада аналитики.

Технологические вызовы

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

  • Безопасность: поскольку PayPal обрабатывает данные PII и PCI, любая инфраструктура данных требует полного исправления, усиленной конфигурации системы, ключей шифрования и дешифрования, настроенных для конфиденциальных данных, доступа к данным через TLS и хорошего контроля доступа на основе ролей (RBAC) для доступа к данным.
  • Эластичное масштабирование по запросу. Своевременный доступ к емкости очень важен для удовлетворения ограничений рабочей нагрузки. Следовательно, инфраструктура аналитических данных должна масштабироваться вверх и вниз по мере роста и сокращения спроса.
  • Высокопроизводительный доступ к SQL:продуктивность аналитиков и специалистов по обработке данных была бы улучшена, если бы типы данных и шаблоны доступа были обеспечены высокопроизводительным интерфейсом ANSI SQL.
  • Доступ из инструментовбизнес-аналитики : поскольку бизнес-аналитика имеет решающее значение для обмена информацией, аналитическая инфраструктура должна хорошо взаимодействовать с существующими инструментами, такими как Jupyter Notebooks, Tableau и Qlikview, а также современными инструментами бизнес-аналитики, такими как Looker и ThoughtSpot. RBAC, применяемые в аналитической инфраструктуре, должны единообразно соответствовать инструментам бизнес-аналитики, чтобы упростить и стандартизировать управление доступом к данным.
  • Showback:пользователи данных не имеют четкого представления о потреблении их ресурсов. Любая новая инфраструктура должна позволять нашим командам предоставлять эту ценную информацию пользователям.

Проблемы усыновления

Изменения в инфраструктуре должны решить следующие проблемы внедрения:

  • Стандартизация: пользователи данных в прошлом подвергались воздействию нестандартной инфраструктуры, которая либо замедляла их, либо ограничивала шаблоны использования. Пользователи предпочитают что-то стандартизованное, чтобы они могли использовать свой существующий кадровый резерв и свои любимые инструменты.
  • Путь к миграции: пользователи данных предпочитают технологию, с помощью которой можно легко перенести существующие артефакты в записные книжки, информационные панели, пакетные и запланированные задания. Переназначение их рабочих нагрузок на новую цель рассматривалось как крупное вложение средств и могло обернуться неудачей с самого начала.
  • Простота обучения:пользователи предпочитают технологию, которую легко изучить самостоятельно в режиме онлайн, в отличие от специальной адаптации, которая может потребовать специального обучения и времени на обучение.
  • Гибкость доступа: инструменты для исследования данных и моделирования претерпевают различные изменения. Пользователи предпочитают инфраструктуру, которая развивается по мере развития технологий. Показательный пример : хотя большинство потребителей PayPal используют SQL, есть много пользователей, которые используют Python, Spark, PySpark и R для анализа и сценариев использования машинного обучения. Кроме того, пользователи хотели бы, чтобы инфраструктура постоянно обновлялась, чтобы использовать новые функции или обрабатывать данные по-разному в зависимости от отраслевых тенденций.
  • Аварийное восстановление: любая инфраструктура должна иметь четкие параметры аварийного восстановления, которые можно запустить в течение 30 минут, чтобы пользователи могли приступить к своей работе.

Учитывая список проблем, которые необходимо решить PayPal, было совершенно ясно, что создание новых локальных решений будет проблемой. Строительные блоки для надежных решений были сосредоточены вокруг облака с меньшей поддержкой локальной инфраструктуры. Кроме того, для масштабирования требуется покупка оборудования, а длительное время выполнения заказа мешало развитию бизнеса. PayPal уже переносил значительные рабочие нагрузки на Google Cloud Platform, что упростило выбор перевода аналитической платформы на Google Cloud Platform. Мы оценили различных поставщиков, предлагающих свои услуги на платформе Google Cloud Platform, чтобы увидеть, могут ли они решить некоторые из технологических проблем, упомянутых ранее, и сузили выбор до BigQuery.. Мы провели 12-недельную оценку BigQuery, чтобы охватить различные типы использования. Он показал хорошие результаты в соответствии с заданными нами критериями успеха. Краткое изложение результатов оценки представлено ниже.