Привет, Хабр. Периодически в этом блоге мы рассказываем о новых продуктах, которые разрабатываем для наших бизнес‑юнитов. История нашего продуктового подхода продолжается. На связи команда продукта «Запасы» М.Видео‑Эльдорадо: я, руководитель этого продукта Артём Ковальский, наш системный архитектор Сергей Алаев, технический руководитель продукта Евгений Хавалджи, бэк‑разработчики Михаил Кириллов и Олимджон Косымов, DevOps разработчик Дмитрий Потамошнев, фронт‑разработчик Роман Ильичев, продукт‑менеджер Дарья Красильщикова, а также автотестировщики Светлана Иванова и Сергей Песцов. На этот раз поговорим о системе, которая позволяет управлять товарными запасами разветвлённой сети из почти 1300 магазинов с техникой и электроникой в 369 городах страны.
Эту систему мы делали для себя. Но оказалось, что еще немного, и она превратится в тиражируемый продукт. Если планы осуществятся, то «Титан» (так называется система) станет еще одним программным продуктом, который «М.Тех» вывела на рынок (в прошлом году мы запустили B2B Altis, о котором можно почитать тут).
Как появился “Титан”
Когда речь идет о ритейлере таких масштабов, как М.Видео‑Эльдорадо, то нужно обладать не только возможностями, но и чутьем — важно не допускать перестока или, напротив, нехватки востребованных товаров, сохранять высокий сервис по всей стране и обеспечивать доставку 80–85% товаров в течение 24 часов. Необходимо в режиме реального времени анализировать потребности в товарных запасах, которые будут сформированы на всех уровнях — в магазинах, где хранится около 60% запасов для доставки уже через 15 минут, в 11 распределительных центрах по всей стране и 59 региональных складах. В 1300 магазинах и складах, осуществляющих потребности разных клиентов в существенно отличающихся регионах.
Как вы понимаете, ключевой фактор доступности товаров и скорости доставки в регионах — плотность логистической инфраструктуры. Огромные партии техники отправляются как на крупный склад в Чехов, так и на другой конец страны — во Владивосток. А еще мы пилотируем городские «урбан‑склады», которые аккумулируют востребованный товар в черте города. Даже у самих объектов разные модели.
До сих пор прогнозирование и управление товарными запасами остается сферой, в которой не существует господствующего решения. Чаще всего ритейлеры используют некий микс — коробку и собственные разработки. Так было раньше и у нас. С 2008 года, больше десятилетия, группа применяла коробочное SaaS‑решение. Стоит ли напоминать, что в 2008 году у М.Видео было почти в 10 раз меньше магазинов и всего в 64 городах. Да и рынок был другим, как с точки зрения технологий, так и конкуренции: iPhone существовал на рынке только год и только получил поддержку 3G, а Samsung только показала первый в мире 31-дюймовый OLED‑телевизор. Со временем, как говорят в таких случаях, решение для логистики «перестало соответствовать потребностям бизнеса». Старое решение долгое время не актуализировалось и не изменялось по существу.
Итак, чем же детально нам не подходила «коробка» вендора? Во‑первых, чтобы чего‑то добиться с новым релизом или оперативно «пофиксить» имеющиеся баги, команде приходилось подключать высшую математику, внешнюю политику и международные связи чуть ли не в Дубае. Вся эта схема напоминала черную комедию. Вендор не раскрывал промежуточные расчеты и детали разработки, да и о кастомизации под реалии российского ритейл‑бизнеса можно было только мечтать.
Во‑вторых, контракт на использование решения был долларовым. Если в 2008 году цена в рублях компанию вполне устраивала, то через 10 лет она стала слишком большой.
А, в‑третьих, и это самое важное, сильно тормозилась наша собственная разработка. Если нам удавалось выпустить пару релизов в год, то это уже был праздник. К тому же, как мы уже упоминали, платформа разработки у этого решения была очень сложной, — настоящий черный ящик, который не поддавался корректировке.
Большее меньшими силами
Разработка «Титана» стала даже не перспективной идеей, а необходимостью. А начали мы ее еще в феврале 2021 года. Поэтому санкции и возможное отключение старого сервиса нас только ускорили (примерно, как приближающийся поезд). Изначальная оценка объема работ по переносу функционала старой системы предполагала в 2 раза больше людей и в 3 раза больше времени. Но когда стало понятно, что старую систему нам отключат максимум через год, оказалось, что можно не копировать многолетние наслоения бизнес-процессов, а переосмыслить логику с нуля, выбрав самое важное, и сделать первый релиз за полгода.
В январе 2022 года был выпущен первый релиз и состоялся демо-запуск. К июлю прошлого года мы доделали основную функциональность, выпустили второй релиз, и в июле подключили первых пользователей. В сентябре (к началу высокого сезона продаж нужно внедрить все “рискованные” разработки) мы перешли на «Титан» полностью.
«Титан» и бизнес-архитектура
Как все это встраивается в бизнес Группы? В «М.Видео‑Эльдорадо» используется коммерческо‑логистическая платформа, которая состоит их четырех продуктов, которые мы разрабатывали самостоятельно. Называется платформа ComSpace. В ближайшее время мы планируем рассказать о ней подробнее, но пока общие сведения.
Первое решение — «Оптимизатор» управляет ассортиментом. Оно анализирует активность покупателей на сайтах и в приложениях и автоматически формирует ассортимент для каждой товарной группы.
Еще две системы — «Ценообразование» и «Промопланирование». Они отвечают за предиктивное управления регулярными и акционными ценами. Источниками данных для этих систем служит анализ цен конкурентов и прогнозная модель ценовой эластичности (оптимального соотношения цены каждого товара и спроса на него). Цену каждого товара эти системы формируют отдельно для каждого географического кластера (всего их 50). При этом сегодня чаще всего это происходит автоматически, без участия экспертов коммерческого блока.
«Титан» — четвертый продукт платформы, система для прогнозирования продаж и планирования закупок. Он использует операционные данные, «Оптимизатора», «Ценообразования» и «Промопланирования», добавляет к ним мастер‑данные по товарам и объектам, планы продаж (верхнеуровневый и адаптированный по магазинам), и на их основе просчитывает целевой товарный запас. Выдает информацию для управления дистрибуцией товарных запасов и их закупке на склады компании (алгоритмы моделирования прописаны в самом «Титане»).
Если говорить упрощенно, то «Титан» с помощью ML‑алгоритмов должен дать ответ логистам компании на вопрос о том, сколько товара каждой категории должно быть подготовлено на каждом объекте по всей стране.
Титаническая работа
Расчеты «Титан» ведет на основе товарных матриц, исторических данных и прогнозов продаж. При этом учитывается сезонный трафик, география. Причем система учитывает не только частотность заказов, географию и план продаж, но и прогноз погоды. Он важен и для предсказания повышенного спроса на сезонные товары, обогреватели, вентиляторы или кондиционеры, и для планирования перевозок. И дело не только в трафике и его зависимости от снега или дождя. В мороз осложняется не только перевозка жидкостей и продуктов, но и техники. Конденсирование с последующей кристаллизацией, разрушение резины, порча аккумулятора — всего этого мы допустить никак не можем.
Во внимание система принимает еще такие факторы, как динамика онлайн‑продаж, ожидаемый уровень сервиса (как быстро клиенты в том или ином регионе желают получить заказ), популярность самовывоза (как часто клиенты предпочитают забирать покупки в магазине).
Вариативность данных, которые «Титан» учитывает, очень высока. И работать с ними было бы сложно, не будь он полноценным «кубом», OLAP‑системой. Это означает, что «Титан» позволяет создавать самые разнообразные запросы и «вертеть» данными в самых разных плоскостях.
Титан не просто умеет показывать и изменять данные, он «живой». Расчет отгрузки 100 тыс. товаров для 1300 магазинов происходит ночью. Но, если кто‑то из пользователей днем изменит любой параметр, влияющий на расчет целевых показателей, то результат изменения будет виден онлайн, сразу же. Для оперативного расчета изменений система использует тот же микросервис и тот же код, который ведет основной расчет, при этом пересчитывается только небольшой «кусочек» данных. В итоге пользователь видит результат уже через несколько секунд.
64 мегабайта оперативки
Первое преимущество «Титана», конечно, цена. Стоимость каждого релиза этой in‑house системы на 85% ниже, чем стоимость релиза SaaS‑решения, которое мы использовали раньше. Здесь же нужно учесть стоимость развития решения и его поддержки (на 10% меньше, чем раньше). Качество поддержки, кстати, тоже значительно возросло: в 5 раз увеличилась скорость решения инцидентов.
Во‑вторых, собственная система не имеет ограничений по числу выпускаемых релизов. Раньше из‑за ограничений на стороне вендора мы могли вывести в продуктив только два релиза в год, сегодня можем выпускать их каждые несколько недель, постепенно добавляя новую функциональность.
Третье преимущество — точность и скорость расчетов. Легкая интеграция и ежедневный бизнес‑ритм! «Титан» обрабатывает весь массив данных по всем объектам за полтора‑два часа. Это позволяет не допустить дефицита или, наоборот, перестока. Сроки доставки для некоторых регионов при таком подходе могут сократиться в два раза. Общая скорость работы новой системы в 4 раза выше предыдущей.
Понятно, что «Титан» работает с огромными массивами данных. За один запрос система может получить ответ в сотни миллионов строк. При этом для работы «Титан» использует всего 64 Мбайт оперативки — система асинхронная и потоковая, использует фиксированное количество ресурсов для любых объемов данных. Секрет в том, что данные не загружаются в память целиком, а обрабатываются построчно. На практике возможности «Титана» позволяют обработать до миллиона строк в секунду на каждую ноду.
Титан построен на потоках данных. Мы умеем получать потоки из базы, фильтровать, джойнить и сплиттить потоки за О(1) по памяти. Однако алгоритмическую сложность не обманешь — сортировку данных приходится делать в Clickhouse, тратя дефицитные ресурсы СУБД. Читая про потоки данных, неизбежно воображаешь разнообразные очереди, но нет — это слишком медленно для Титана. Наши потоки — это обыкновенные REST запросы, возвращающие гигабайты строк данных, пожатые gzip, чтобы не перегружать сеть. Конечно, не каждый фреймворк подойдёт для такой нагрузки. Мы пробовали спринг, Ktor, jdk‑http, и в итоге остановились на фреймворке Finagle от Twitter (да, они не только раздают твиты, но и являются серьезным контрибьютором в OpenSource). Он не самый быстрый, но единственный работающий корректно в нужных нам сценариях. Но мы не оставляем надежд на лучшее, и иногда подумываем написать свой сервер и клиент на netty:‑).
Системы класса «Титана» используют специализированные базы данных с большим memory‑cache на запись, например — SAP HANA. Мы применяем Clickhouse от «Яндекса». Это — очень быстрая колоночная база для аналитики, у которой есть богатый функционал. Но «из коробки» она уверенно работает только с большими вставками. Дело в том, что каждая вставка создает новый файл на диске, и его содержимое нужно включать в основной массив данных. Поэтому нам пришлось использовать дополнительные возможности Clickhouse, чтобы своими силами организовать in‑memory cache, в итоге добившись и высокой пропускной способности на больших объемах данных, и низкого времени отклика на точечных изменениях через веб‑морду AKA интерфейс пользователя..
Ну и главное, согласно опросам пользователей, их удовлетворенность решением теперь составляет 95%.
Что мы планируем делать дальше
«Титан» — очень быстрая система, но она может стать еще быстрее. Для этого мы планируем поработать над усовершенствованием запросов к Clickhouse. Имеется и возможность сетевой оптимизации — за счет оптимизации сетевых клиентов и переход на двоичные форматы данных. Наконец, нам предстоит поработать над OLAP: у нас она поддерживает только иерархические справочники. Но самый важный пункт нашего плана дальнейших действий — превратить «Титан» в тиражируемое решение, продукт.
«Титан» как тиражируемое решение
Мы уже многое сделали, чтобы превратить «Титан» в коробочное решение, которое будет актуально для ритейлеров и дистрибьюторов. Пользовательский интерфейс OLAP позволяет отображать любые данные, опирающиеся на классификаторы. Для работы с любыми данными пригодно и ядро «Титана». Микросервисная архитектура, которую мы используем и развиваем, позволила реализовать бизнес‑логику на уровне самой системы.
Кстати, за последний год мы несколько раз меняли структуру хранения данных в базе. А микросервисы с бизнес‑логикой, написанные полгода назад, продолжают работать без изменений. Значит, у нас есть все, чтобы сделать «Титан» универсальной тиражируемой системой для построения отчетов и процессинга любых данных.
Мы планируем сделать API, который позволит полностью настраивать конфигурацию данных, обрабатываемых системой и классификаторов, доработать интерфейс — это позволит выпустить «Титан» как тиражируемое решение, которое можно будет продвигать и как коробку, и как облачный продукт.
