BI-аналитика для «Платферрум»: Рабочее решение для маркетплейса по продаже металлопроката за 10 дней

Заказчик

“Платферрум” — это первый маркетплейс в России, специализирующийся на продаже металлопроката.

Задача

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

«Платферрум» — это первый маркетплейс в России, специализирующийся на продаже металлопроката. Проект реализуется при поддержке компании «Северсталь». Пользователи платформы — строители, производители металлоконструкций, поставщики металлообработки, финансовые и логистические провайдеры, трейдеры и представители малого и среднего бизнеса. Задача маркетплейса — быстрое и безопасное заключение сделок, а также предоставление широкого спектра онлайн-услуг. Можно сказать, что «Платферрум» — это экосистема на рынке металлопроката.

Цели и задачи

Заказчику требовалось оперативно получать наглядную информацию о товарах, не попавших на витрину, с указанием причин. Проблема заключалась в том, что перед тем, как товар попадет в каталог маркетплейса, он проходит процесс верификации — система проверяет наличие цен, остатков, заполненность склада и другие параметры товара (их более 15). Если хотя бы одно из этих условий нарушается — товар не попадает на витрину маркетплейса.

Вместе с заказчиком мы выделили следующие задачи:

• обеспечить контроль передачи данных по подсистемам,
• создать инструмент для удобной отчетности,
• подготовить рабочие места для контент-менеджеров и техподдержки.

Реализация

Наша задача заключалась в разработке быстрого и эффективного решения, которое не повлияет на текущие процессы и не станет дополнительной нагрузкой для разработчиков.

Поскольку инфраструктура «Платферрум», включая базы данных, размещена в защищенном контуре Yandex Cloud, использование Yandex DataLens стало естественным решением.

Преимущества Yandex DataLens:

1. понятный интерфейс,
2. минимальный порог вхождения,
3. быстрый вывод данных на экран в 4 шага:

• создание подключения к источнику данных,
• создание датасета,
• оформление визуализаций,
• вывод в дашборд.

Что мы сделали

Подключили необходимые базы данных к DataLens. Первая интеграция с хранилищем данных PostgreSQL была настроена в несколько кликов. Для этого нужно было указать параметры БД и создать пользователя на чтение данных из DataLens;

Проверка. Проверили каждый товар на наличие необходимой информации для вывода на платформу с помощью SQL-запросов, которые можно написать в датасете;

Сделали наглядную визуализацию в чарте. В чарте настроили индикаторы, которые загораются красным, если все товары по поставщику пропали с платформы;

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

Пользователи DataLens

Далее мы начали делиться результатами с коллегами, а затем DataLens быстро освоили и другие члены команды.

Пользователей DataLens на «Платферрум» можно разделить на 3 типа:

• менеджеры, контент-менеджеры — пользуются готовой отчетностью,
• аналитики — строят отчеты по запросу от бизнеса для общего пользования,
• техподдержка, тестировщики, аналитики — самостоятельно строят отчеты
• под свои запросы.

Данное решение помогло нам быстро выполнить первые задачи, но у такого решения есть свои недостатки — в DataLens нельзя работать с таблицами из разных источников на уровне датасета.

Имея такое ограничение, мы не могли решать новые задачи:

• внедрение сквозной аналитики: бизнесу нужны данные не только из мастер-системы, но и данные из CRM, чтобы строить различные воронки по клиентам;
• мониторинг выполнения KPI по менеджерам в отделе продаж: данные по компании и ответственному менеджеру также хранятся в CRM;
• анализ процессов разработки, построение таких метрик как TTM, LT и др.

Чтобы решить поставленные задачи мы решили создать хранилище, где будут собраны эти данные. Так, мы настроили передачу данных в ClickHouse из нескольких источников:

• PostgreSQL: информация о заказах, товарах, покупателях и поставщиках;
• Yandex Tracker: данные о задачах и их истории передвижения по статусам;
• GitLab: данные о комитах;
• CRM: лиды, сделки, данные о сотрудниках отдела продаж для расчета KPI.

На текущий момент передача данных для PostgreSQL реализована с помощью сервиса Yandex Data Transfer:

• для каждой БД PostgreSQL поднят свой трансфер, который копирует таблицы из БД и переносит в базу ClickHouse с таким же названием;
• трансферы работают в режиме периодического копирования и запускают передачу данных с прода раз в час;
• Yandex Data трансферы создаются командой DevOps с помощью автоматизированной инфраструктуры.

Для получения данных мы создали самописные трансферы:

• для данных Yandex Tracker и GitLab — трансферы на Python (получаем нужную информацию с помощью API);
• для данных из Битрикс24 — трансфер, реализованный на Node.js.

После создания единого хранилища данных мы начали создавать дашборды:

• собрали дашборд по выполнению KPI по данным из CRM и фактическим продажам;

• построили сквозную аналитику, объединив данные из CRM и данные платформы;

• построили дашборды команде разработки по деплоям из данных GitLab;

• построили дашборд с производственными метриками по данным Yandex Tracker.

Реакция на изменение структуры баз данных

Наши базы данных часто меняются:

• добавляются новые таблицы и поля,
• удаляются поля из таблицы,
• удаляются таблицы,
• меняется тип данных у полей.

Последние изменения могут негативно отразиться на дашбордах — они ломаются с ошибкой о несуществующих объектах. Первое время разработчики узнавали об изменениях постфактум — либо мы видели, что дашборды упали с ошибкой «Не существует такого поля/таблицы», либо к нам приходили пользователи и спрашивали, почему дашборд сломался.

Как мы узнаем об изменениях сейчас

Мы настроили процесс через Yandex Tracker.

Системный аналитик после проработки своей задачи ставит чекбокс «Будут изменения в BI».

После релиза создается подзадача [CHGOBJ] + название Story в нашу очередь DL (класс обслуживания «Ускоренный»).

Задача BI-аналитика — ознакомиться с документацией и понять текущие изменения таблиц.

Результат

Решение от команды BI-аналитиков Digital Clouds оказалось быстрым, рабочим и масштабируемым — оно позволяет клиенту оперативно получать необходимую информацию без привлечения дополнительных ресурсов. Более того, благодаря Yandex Cloud мы обеспечили безопасность данных, что является ключевым аспектом в современном цифровом мире.

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

Развитие проекта

Сегодня BI-команда Digital Clouds работает над решением проблем миграции данных. Так как Yandex Data Transfer работают в режиме периодического полного копирования таблиц, перед каждым новым копированием таблицы в ClickHouse очищаются — в этот момент дашборды становятся недоступны пользователю на время копирования.

Первые полгода после запуска нашего решения это было некритично — дашборды обновлялись в течении 2-х минут. Но данных становится все больше, и сейчас таблицы могут обновляться по 10 минут, что неудобно для пользователей. К тому же для более качественной работы клиенту необходимо получать данные непрерывно.

Изучив способы, позволяющие осуществлять миграцию данных, сейчас команда строит новое DWH и активно тестирует Altinity Sink Connector.

Перейти на сайт