Почему в X5 Group выделили Data Engineering в отдельный центр компетенций

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

и как это помогло ускорить продуктовую разработку

Когда в 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, что позволило в целом стабилизировать пайплайн и продолжить его промышленную эксплуатацию.

→ Вакансии Data scientists и Data Engineer в Х5

Источник: https://habr.com/ru/company/X5RetailGroup/blog/563142/


Интересные статьи

Интересные статьи

Пол Букхайт — 23-й сотрудник Google, автор слогана «Don’t be evil», создатель Gmail. Основатель стартапа FriendFeed. Инвестировал более чем в 150 стартапов (60 экзитов), партнер Y Com...
Работу в ИТ-отделе средней по московским понятиям торговой конторе я получил сразу после диплома. Она мне досталась в наследство от приятеля, который дождался приличного ...
На "Постнауке" недавно вышел объемистый и красочный гид по квантовой механике. Наверное, самый замечательный момент заключается в том, что интервью брались у разноплановы...
Путь LED-самурая Немного предыстории — около года назад я опубликовал обзорную статью, где была описана минимальная отладочная плата для микроконтроллера серии STM32F405. Особого инт...
Пластинки покупают все чаще. Аналитики из Американской ассоциации звукозаписывающих компаний (RIAA) отмечают, что к концу года доходы от продажи винила превысят показатели CD — такого не случалос...