Привет, Хабр! Мы команда ММ (Marketing Management) компании Glowbyte, занимаемся автоматизацией маркетинговых процессов в крупных кампаниях. В рамках данной статьи хотим поделиться опытом применения Massive Parallel Processing (MPP) РСУБД на примере GreenPlum для решения задач целевого маркетинга (в aCRM системе). Статья основана на реальных событиях опыте проекта внедрения платформы Campaign Management для автоматизации маркетинговых процессов в крупном Retail.

Проблематика

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

Выбирая СУБД, мы решаем сразу несколько задач: как соответствие потребностям бизнеса, так и экономическую целесообразность. Особенно остро вопрос стоит для крупных кампаний, где количество активных клиентов измеряется десятками миллионов, количество маркетинговых кампаний – сотнями, а количество коммуникаций с клиентами – сотнями миллионов в месяц. Добавим сюда устоявшийся тренд подхода к маркетинговым коммуникациям “от Клиента”, который пришёл на смену подходу “от Продукта” и в свою очередь неминуемо ведёт к увеличению количества запускаемых маркетинговых кампаний, их сложности, включая расширение количества каналов коммуникации, смещение в сторону Digital, а следовательно повышение требований к аппаратным ресурсам, в частности – в рамках БД.

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

• технологиям Open-source – чтобы решить вопросы экономической целесообразности,

• технологиям MPP – чтобы решить вопросы производительности и хранения быстрорастущих объёмов данных,

• доступным решениям в контексте геополитической ситуации.

MPP РСУБД “на слуху” достаточно давно, однако одновременно и open-source и enterprise-ready решение появилось совсем недавно: например, выход GreenPlum версии 6 состоялся в октябре 2019 года. 

История одного заказчика

Вводные

Один из наших заказчиков из сферы крупного Retail запустил проект внедрения новой платформы aCRM. Ниже представлены ключевые исходные маркетинговые показатели:

Важно отметить, что на момент старта проекта у заказчика уже было построено аналитическое хранилище данных на базе MPP РСУБД GreenPlum.

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

Выбранная архитектура системы

С учётом требований заказчика к системе, помимо процессов, генерирующих аналитическую (OLAP) нагрузку на СУБД, в ходе внедрения появлялись и OLTP-процессы. Логически они были разнесены, поэтому рассматривалось использование 2 раздельных экземпляров БД.

Вариант архитектуры с GreenPlum нёс определенные риски:

• Использовавшаяся у заказчика и получившая распространение в промышленных масштабах версия Greenplum v5 вышла в сентябре 2017. Версия v6 зарекомендовала себя намного лучше, но стартовать проект пришлось на “пятёрке”.

• Вендорские решения Campaign Management от лидеров рынка не поддерживали работу с MPP. Например, SAS начал поддерживать GreenPlum в 2015 году с версии Customer Intelligence Platform 6.4; другие MPP РСУБД до сих пор не нашли широкого распространения с точки зрения поддержки вендорами.

• Недостаток на рынке senior-специалистов с экспертизой по MPP РСУБД в целом и по GreenPlum в частности. Без таких специалистов на стороне заказчика невозможно сопровождение системы, что для enterprise-решения неприемлемо.

• Все известные нам крупные заказчики оставались на классических СУБД (Oracle, MS SQL, PostgreSQL) и решали проблему путём обновления инфраструктуры в основном вертикальным масштабированием, которое, как известно, имеет предел и стоит значительных средств.

• Как следствие пункта выше, вендорские решения Campaign Management от лидеров рынка, несмотря на поддержку MPP РСУБД и GreenPlum в частности, не имеют широкого применения и потенциально содержат подводные камни или уступают в функциональных возможностях классическим РСУБД.

Несмотря на это, выбор был сделан в пользу GreenPlum, а архитектуру было решено выстроить следующим образом:

• Для решения задач сегментации и аналитики (OLAP-нагрузка) предусмотрен GreenPlum с расчётом на то, что параллельные вычисления позволят значительно ускорить время выполнения запросов.

• Для решения интеграционных задач (OLTP-нагрузка) предусмотрена классическая СУБД PostgreSQL – “прародитель” GreenPlum. При отсутствии затрат на лицензии и минимальных затратах на аппаратные ресурсы эта СУБД обеспечивает минимальное latency при OLTP-нагрузке, что позволяет эффективно решать задачи сбора технических статусов коммуникаций и откликов с минимальными задержками относительно получения данных со стороны каналов коммуникаций. Подход позволил реализовать на PostgreSQL такие дополнительные “фичи” как: 

  • управление размерами пакетов коммуникаций, 

  • распределение коммуникаций по времени, 

  • управление скоростью отправки коммуникаций,

  • реализация отложенной отправки коммуникаций.

В то же время использование 2 СУБД имеет свои недостатки – главным образом, необходимость в добавлении потоков синхронизации между ними. Решить это получилось с помощью следующих приёмов:

1. При генерации маркетинговых данных (предложения/контакты) запись осуществлялась сразу в 2 СУБД: в GreenPlum – для возможности использовать в сегментации и аналитике в параллельно запускаемых кампаниях; в PostgreSQL – для их отправки.

2. Для каждой сущности была однозначно определена мастер-БД, что позволило сделать потоки синхронизации односторонними.

3. Потоки синхронизации были реализованы инкрементальными ETL-процессами с минимальным регламентом (15-60 минут в зависимости от данных).

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

5. Использование партицирования для синхронизируемых таблиц позволило практически избавиться от блокировок на время синхронизации.

Концептуальная архитектура системы:

Построение сегментов

Проектирование любой маркетинговой кампании начинается с построения сегмента.

Логика рассуждений маркетингового менеджера примерно следующая: сначала отбираем eligible-клиентов, потом учитываем другие данные (чеки/модели/предложения), проверяем контактную политику, в конце – делим на A-, B-выборки и контрольную и тестовую группы.

Таким образом, шагов сегментации в типовых кампаниях может быть от 2–3 до 20, а в редких случаях – до 100. Для бизнес-пользователя критически необходимо видеть “счётчик” на каждом шаге – это означает, что расчёт одного такого сегмента приводит к 20 последовательно выполняемым SQL-запросам, и эта последовательность должна выполняться быстро.

При этом критерии построения могут меняться на ходу – в зависимости от того, что видит пользователь на счётчиках воронки. Например, если выборка составила всего лишь 1% активной клиентской базы при ожидаемых 10–15%, бизнес-пользователь может начать менять критерии на шагах, где отсекается наибольший процент. То есть, чтобы получить итоговый набор шагов построения сегмента, может быть пройдено множество итераций, каждая из которых будет сопровождаться большим количеством аналитических запросов в БД.

Именно построение сегмента занимает бОльшую часть времени работы бизнес-пользователя с инструментом.

Как итог, процесс построения сегмента – это не просто один из рутинных шагов построения кампании, а процесс, вокруг которого выстраивается всё остальное. И скорость расчёта сегмента, соответственно, – не просто нефункциональное требование, красиво звучащее для спонсоров в контексте снижения time-to-market, а то, что формирует у бизнес-пользователя отношение к инструменту и напрямую влияет на эффективность работы.

Здесь и раскрываются преимущества MPP и GreenPlum в частности:

1. Обработка и хранение данных на автономных узлах параллельно, что позволяет максимально эффективно производить расчёты. 

2. Хранение данных в колоночном формате, то есть при чтении используются только те данные (столбцы), которые указаны в запросе, что также даёт прирост производительности. 

3. Сжатие данных легковесными алгоритмами компрессии, что делает чтение ещё  эффективнее.

Нюансы “приготовления” GreenPlum

Использование MPP РСУБД вместо классических РСУБД может ускорить систему и дать дополнительные преимущества в части масштабирования. Но ошибки в конфигурации могут замедлить её настолько, что бизнес-процессы остановятся. Во избежание второго сценария необходимо правильно “готовить” MPP РСУБД, то есть на этапе внедрения сконфигурировать и спроектировать базу с учётом особенностей хранения и обработки данных. 

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

При использовании GreenPlum и проектировании процессов и модели данных важно обратить внимание на следующие аспекты:

1. В контексте автоматизации маркетинга GreenPlum целесообразен только под OLAP-нагрузку, поэтому если система предполагает OLTP или смешанную с OLTP нагрузку, то имеет смысл рассмотреть либо разделение БД (как в нашем проекте), либо просто классическую РСУБД – тот же PostgreSQL. 

2. Ключ дистрибуции отвечает за логику распределения данных по сегментам (нодам). GreenPlum позволяет его задавать на уровне отдельной таблицы. При этом нужно учесть следующие аспекты:

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

   2. Ключи дистрибуции для таблиц, которые должны пересекаться/соединяться при построении сегментов. Если при джойне данные первой таблицы распределены иначе, чем данные второй таблицы, возникает необходимость переливки данных между сегментами для этой операции (redistribution). Такой процесс кардинально замедляет систему в случае джойна объёмных сущностей. 

   3. С версии 6 есть возможность помечать таблицы для загрузки копии на каждый сегмент (то есть не распределять данные, а копировать полностью), что в случае с небольшими таблицами (справочниками/dimension-таблицами) позволяет снизить количество переливок и тоже положительно сказывается на производительности.

3. Партицирование – обязательно для “глубоких” таблиц, позволяет снять головную боль в будущем при соблюдении условий:

   1. В таблицах предусмотрен ключ партицирования (неизменяемый атрибут, по которому возможно замерить “глубину” таблицы) – как правило, дата, например дата вставки записи.

   2. Размер партиции адекватно подобран под объём данных и типовую нагрузку в рамках системы: единственный 100% способ определить, что размер подобран хорошо, – это провести корректное нагрузочное тестирование.

      • Важно помнить: при N партициях и M колонках в "колоночной" таблице в ОС создаётся NxM файлов даже для пустой таблицы.

   3. Автоматизированы процессы создания будущих партиций.

   4. Автоматизированы процессы архивации (удаления) данных – по партициям.

4. Массовая загрузка данных. Необходимо учесть нюансы способов загрузки данных в кластер и выбирать среди них, исходя из источников данных/предполагаемой нагрузки/предполагаемого увеличения количества нод в кластере и т. д. Мы рассматривали 2 вариант заливки данных в GreenPlum:

   1. С помощью pxf – способа подключения сторонних БД/хранилищ (Hadoop: HDFS, Hive, HBase; объектные: S3, Azure, Google Cloud Storage; классические РСУБД через jdbc) к GreenPlum. Прожорливый на количество коннектов, причём прожорливость растёт с увеличением числа сегментов в кластере.

   2. С помощью gpfdist – способа подключения внешних файлов к GreenPlum. Требует установленного пакета greenplum-loader на сервере, с которого затягиваются файлы.

5. Единый кластер под разные системы. Одной из идей заказчика была экономия в виде возможности переиспользовать существующий кластер GreenPlum, который обеспечивал нужды аналитических процессов другой системы. Для разграничения нагрузки были настроены ресурсные группы (aka Oracle Resource Manager). Ресурсные группы позволяют разграничивать CPU/RAM, но нагрузка на диски не разделяется. Поэтому для гарантии нормальной работы нескольких систем необходимо – по аналогии с традиционными СУБД: 

   1. расселять потребителей в отдельные tablespace на разных дисковых массивах,

   2. в крайнем случае, разворачивать отдельные кластеры СУБД под отдельные системы.

6. HouseKeeping. Следить за пользовательской нагрузкой и карать за плохие запросы. Токсичная нагрузка вызывает деградацию всего кластера из-за неразделимости некоторых ресурсов. В случае с операционными СУБД и аналитическими запросами от пользователей – выносить их с операционной БД системы в контур для аналитики/отчётности или как минимум загонять в менее приоритетную ресурсную группу.

7. Ресурсные группы. Сами по себе ресурсные группы – отличный инструмент для разграничения нагрузки в рамках одной системы. К примеру, в контексте маркетинговой системы не избежать наложения процессов наполнения витрины, создания внутренних сущностей (предложений/контактов), а также построения сегментов. В реальности это всё сопровождается пользовательскими ad-hoc-запросами. Исходя из требований бизнеса ко времени работы кампаний/времени загрузки витрины и т. д., ресурсные группы позволят затюнить БД нужным образом. 

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

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

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

      • днём основная нагрузка от маркетинговых кампаний: поменяем настройки так, чтобы больше ресурсов было у пользователей Campaign Management.

8. Сайзинг/инфраструктура – обязательно необходимо учесть следующее:

   1. заложить быстрые диски (ssd/nvme) под temp/spill, которые в любом случае понадобятся;

   2. предусмотреть максимально близкое расположение нод кластера GreenPlum – в том числе физически, так как GreenPlum чувствителен к сетевой инфраструктуре и требует высокой скорости интерконнекта между нодами кластера.

9. Коннекты к GreenPlum. Аналогично PostgreSQL может потребоваться пулер соединений, если приложение генерит их много/не имеет встроенного пулера. Самый популярный пулер для PostgreSQL – pgBouncer – поддерживает и GreenPlum.

10. Незакрытые (idle/idle in transaction) сессии. Регламентно закрывать такие сессии, так как они держат коннект и могут блокировать объекты. 

Результаты проекта

Одна из главных целей проекта внедрения системы Campaign Management – возможность быстро и удобно строить сегменты для проведения маркетинговых кампаний – была полностью выполнена с использованием СУБД GreenPlum. 

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

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

1. Построением сегмента (с промежуточными расчётами отдельных частей сегмента).

2. Тестовым запуском кампании – на тестовой выборке для проверки коммуникации.

3. Боевым запуском кампании.

Ниже приведены полученные метрики для типовых запусков кампаний. 

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

Если бы система была запущена на классической РСУБД, то подобных результатов, скорее всего, удалось бы достичь с помощью “жирного” сайзинга под базой и использования платных advanced-фичей (например, Real Application Cluster от Oracle). Но такой вариант не позволяет масштабироваться “быстро и дёшево”: с минимальными затратами времени, ресурсов и, самое главное, с минимальным влиянием на бизнес-процессы. Использование РСУБД GreenPlum, в свою очередь, позволяет достаточно просто добавлять новые ноды в кластер, обеспечивая горизонтальное масштабирование. Именно это было важно для заказчика, бизнес которого растёт ударными темпами. 

Выводы

Как итог, MPP РСУБД в целом и GreenPlum в частности не является панацеей, но может быть отличным решением:

• для организаций, у которых:

  • генерируется большой объём данных и есть требование хранить их в витрине;

  • быстро растёт/ожидается быстрый рост объёма данных, что требует возможностей минимально затратного масштабирования “из коробки”;

  • вертикальное масштабирование затруднено/очень дорого.

• если уметь правильно его “готовить”.

Важно помнить и о рисках, связанных с MPP РСУБД, и быть готовыми с ними работать. Например:

• помнить о нюансах “готовки”, 

• заполучить в команду senior-экспертов по выбранной СУБД,

• Подготовить TEST-/PREPROD-контур, максимально близкий к PROD, чтобы иметь возможность тестировать и проверять “тонкие” настройки СУБД в релевантных условиях, а не экспериментировать “в продакшене”,

• предусмотреть работы на реализацию регламентных технических процессов.

Материал подготовили: @dikirilov, @Madmess, Сергей Харченко, Антон Стрельников, Андрей Баранов, Дмитрий Инокентьев и Марк Лебедев.

Список использованных терминов и сокращений