Когда в X5 Group начали развивать BigData, то помимо самой DMP платформы и BI-аналитики, в компании стали активно запускать цифровые продукты, построенные на основе больших данных, использующие сложную аналитику и машинное обучение. Для примера можно привести продукты по прогнозированию спроса, управлению ассортиментной матрицей магазинов, предсказанию отсутствия товаров на полках, динамического ценообразования и т.п
Когда и зачем в продуктовой команде нужна компетенция по Data Engineering
Большинство продуктов были инновационные и требовали активного R&D, другими словами, требовалось проверить множество различных гипотез и подходов, прежде чем будет найдено оптимальное решение. Одним из ключевых факторов успешности R&D процесса является то, как быстро вы можете проводить эксперименты и проверять гипотезы. В Х5 Group для разработки продуктов формировали автономные и максимально независимые, кросс-функциональные команды, которые бы имели минимум внешних зависимостей и могли двигаться вперед с максимальной скоростью. При этом у продуктовых команд достаточно часто возникали два типа задач, связанных с данными:
найти среди множества источников данных и множества представлений именно те данные, которые нужны продукту и удостовериться в их корректности
построить сложный пайплайн по извлечению данных из разных витрин и источников, их нетривиальной обработке, зачастую с применением ML и предоставления результатов продуктовой команде для дальнейшей работы
Для эффективного решения первого типа задач в Х5 Group развивают компетенцию Data Quality, а для второго - компетенцию Data Engineer. Если вкратце, то различие между этими двумя компетенциями можно попробовать свести к следующему:
DQ гораздо глубже погружен в предметную область и бизнес, чем в программирование и распределенные системы, в то время как DE гораздо глубже погружен в программирование и нюансы работы распределенных систем обработки и хранения данных, чем в предметную область и бизнес.
DQ ищет в компании данные в различных системах, понимает какие из них нужны для конкретной задачи, может составить требования по их обработке и очистке, а также собрать простую витрину данных или прототип такой витрины. DE разрабатывает продуктивные версии витрин по требования, полученным от DQ, настраивает инфраструктуру, мониторинги и логирование, оптимизирует вычисления.
Появление в кросс-функциональной команде, которая строит продукт на основе больших данных, ролей Data Quality и/или Data Engineer позволило существенно ускорить процесс разработки продукта на начальном этапе, когда ядро команды может состоять из Product Owner, Data Scientist / Data Analyst, которые в паре с Data Quality / Data Engineer могу быстро и эффективно находить и готовить данные, на базе которых учатся модели машинного обучения и проверяются гипотезы.
После разработки MVP и проведения успешного пилота, когда продукт получает заключение о наличии подтвержденного экономического эффекта, команда сталкивается уже с задачами иного рода. Как правило возникает необходимость серьезного масштабирования продукта, например:
начать делать прогноз не для 100 магазинов, как на пилоте, а для более чем 17 магазинов по всей России.
начать выдерживать строгие SLA на время расчетов и скорость отклика
не допускать падения расчетов и неточности/несогласованности в витринах данных
На этом этапе продуктовой команде критически важно построить инженерное решение с требуемыми уровнями отказоустойчивости и масштабируемости. И привлечение компетенции DE для разработки витрин и пайплайнов по обработке данных становится уже не просто желательным, а просто жизненно необходимым для дальнейшего развития продукта.
Почему мы выдели и развиваем Data Engineering отдельно от других направлений
Первоначально в Х5 компетенция по Data Engineering в основном была сосредоточена в подразделении, отвечающем за разработку и развитие платформы больших данных и единого корпоративного хранилища. Но у DMP и EDW имелся свои roadmap развития и продуктовые команды со своими задачами вынуждены были подстраиваться под этот roadmap, что могло существенно замедлить их разработку.
Это стало приводить к тому, что задачи по обработке больших данных в продуктовых командах могли начинать решать backend-разработчики, осваивая новый технологический стек, либо ребята из Data Science, кто имел неплохой инженерный бэкграунд, начинали брать на себя больше задач по подготовке и обработке данных, построения сложных витрин.
Нанимаемые в продуктовые команды специалисты с профилем Data Engineer также оседали где придется: в команде, разрабатывающей DMP, в подразделениях, отвечающих за классический Software Engineering или среди Data Scientists и Data Analyst. Это приводило к следующим проблемам:
руководители продуктов не знали куда именно им нужно идти за ресурсом DE, и кто в компании отвечает за найм и развитие таких специалистов
найм DE зачастую проводился людьми, компетентными в смежных направлениях, но не особо разбирающихся именно в Data Engineering
не было единой среды общения, менторства и развития для DE, разбросанных по разным подразделениям, что осложняло распространение лучших практик и стандартизации подходов к разработке и используемым инструментам. Это приводило к тому, что в команды постоянно “изобретали велосипеды”, не зная, что их проблема уже давно и успешно решена в другом месте.
Выделение DE как отдельного центра компетенций в Х5 Group позволило в итоге существенно продвинуться в решении перечисленных проблем:
сделать единую точку входа для руководителей продуктов, а также быстрее и гибче выделять ресурсы в продуктовые команды за счет создания единого ресурсного пула
упростить найм и сделать его более системным за счет того, что наймом централизованно занимаются люди разбирающиеся именно в Data Engineering
начать внедрять в продуктовых командах типовые решения и стандартизировать подходы к разработке и инструментам, построить эффективную среду для коммуникации, менторства и развития инженеров
ускорить запуск новых продуктов, на основе больших данных и позволить успешно отпилотировавшимся продуктам развиваться в надежные инженерные решения, масштабируемые на более чем 17900 магазинов Х5 Group в 66 регионах России
Вот пара кейсов, которые мы уже реализовали.
Кейс 1 - масштабирование успешного пилота
Команда разработала MVP продукта, который на основе анализа терабайтов чековых данных предсказывает отсутствие товаров на полках магазинов (хотя на складе они есть) и рассылает алерты персоналу магазинов, чтобы они проверили наличие товаров на полках и, при необходимости, их пополнили. Был проведен пилот на 600 магазинах, который показал подтвержденный экономический эффект и перед командой встала задача масштабирования своего решения на более чем 16 тысяч магазинов.
Требовалось провести анализ всех имеющихся расчетов на предмет их возможного масштабирования и оптимизации: расчеты и подготовка данных должны укладываться в строго фиксированные временные рамки от момента заливки на кластер обновленных данных по чекам за прошедший день, до времени открытия первых магазинов следующим утром.
Наличие в команде специалистов с компетенцией по Data Engineering позволило выявить узкие места в пайплайнах продукта, протестировать их на 17 тысячах магазинов, изучить планы запросов и определить ботлнеки, проанализировать утилизацию ресурсов при их выполнении, понять какая конфигурация ресурсов будет наиболее уместна и сделать оценку количества дополнительного железа, которое потребуется для масштабирования.
Кейс 2 - стабилизация пайплайна под возросшей нагрузкой
В одном из продуктов был реализован пайплайн подготовки данных для пост-анализа промо-акций. Команда разработала пайплайн в виде множества скриптов на Hive и успешно вывела его в продуктивную эксплуатацию.
Со временем работа пайплайна стала нестабильной: могло в разы увеличится время выполнения, иногда пайплайн вообще падал с ошибками. Для диагностики проблем и выработки возможных решений потребовалось подключение Data Engineer, который провел глубокий анализ планов выполнения запросов и утилизации ресурсов кластера. В результате часть запросов была оптимизирована, для другой части разработаны и протестированы более эффективные реализации преобразований на Spark, что позволило в целом стабилизировать пайплайн и продолжить его промышленную эксплуатацию.
