Каждый человек по мере взросления встречает множество вызовов на своём жизненном пути. Ответы на эти вызовы формируют его личность. То же самое происходит и с командой.
Для нас, офиса CDO X5, пожалуй, определяющим был 2022 год. В том году мы выполнили проект такого масштаба и уровня сложности, какими мало кто может похвастаться. В него была вовлечена вся команда. А главное, что он не просто завершился успешным внедрением, но и дал нам вместе больше, чем каждому из нас по отдельности. За 9 месяцев мы выполнили миграцию аналитики и данных из SAP BW на ClickHouse и GreenPlum.
В серии статей, которую мы открываем этой публикацией, мы расскажем о 17-ти эпизодах, имевших место по ходу этого проекта. Поделимся своим опытом в том, как реализуются масштабные проекты в крупных компаниях, какие технологические решения используются для аналитики, как принимаются ключевые управленческие решения, как на деле выглядит гибкая антикризисная стратегия. В этой статье представлены первые пять эпизодов.
1. Первая планёрка
3 марта 2022 года, четверг, 08:30
По четвергам у нас в офисе обычно людно. За время гибридного режима сама собой выработалась практика: четверг и вторник – офисные дни. Этот четверг не такой как обычно. Всю последнюю неделю людей мало: почти все по домам, рядом с близкими, осознают новую реальность.
Тем не менее, одна переговорка на 15 человек занята полностью с самого утра. Собравшиеся – руководители и эксперты, отвечающие за работу с данными в Х5. На повестке – вчерашнее заявление SAP о приостановке бизнеса в России. В Х5 Group, как и во многих крупных компаниях Европы, системы SAP составляют значительную часть IT-ландшафта: SAP ERP, SAP HCM, SAP CAR. Но одна система у нас стоит особняком – SAP BW on HANA. Только она расположена в облаке SAP – Hana Enterprise Cloud (HEC), то есть физически использует инфраструктуру немецкого вендора.
SAP BW – одно из двух хранилищ данных в Х5, более старое. С 2018 года мы постепенно переводим пользователей на новое хранилище – EDW на GreenPlum. Но в данный момент около половины всех потребителей отчётности (чуть больше 5 тысяч MAU) используют BW. А главное – BW используется для закрытия финансового периода, а это задача уровня mission critical. Остановка SAP BW означает невозможность сформировать обязательную финансовую отчётность. По меньшей мере, это грозит штрафами со стороны регулятора, а про более негативные последствия даже говорить не хочется.
С начала кризиса прошло 4 рабочих дня и 2 выходных. Нам ещё неизвестно, что SAP даст нам возможность забрать наши данные из их облака. Неизвестно также, что SAP даст достаточно времени, чтобы мы нашли хоть сколько-нибудь подходящее железо.
Вопрос, поставленный директором по управлению данными, подталкивает собравшихся к переходу из состояния "замри" в состояние "беги": “Если завтра SAP BW “превратится в тыкву”, какую аналитику мы сможем дать бизнесу?”.
Поднимаем статистику запусков аналитических отчётов на BW. Видим, что все ключевые данные у нас уже есть в новом EDW: справочники, продажи, чеки, движения, остатки (остатки – актив данных с наиболее сложным алгоритмом расчёта, на отладку которого у нас ушли многие месяцы). Значит, не всё потеряно.
Со встречи расходимся с пониманием первоочередных задач:
провести аудит всех каналов доставки данных из BW пользователям;
определить те 80% нагрузки, которые можно перевести с BW на EDW, затратив 20% усилий;
установить, какие сервисы на данных BW для бизнеса важные, а какие критически важные.
Открытыми остаются два вопроса, переоценить которые невозможно:
Чем заменить SAP HANA, которая на лету обрабатывала в параллель тысячи ad-hoc запросов конечных пользователей? GreenPlum на такое точно не способен…
Как спасать модель финансового закрытия – наиболее сложную и важную часть BW?
Нет, жизнь за стенами офиса не наладилась в тот же момент, как мы наметили первые шаги. Но у нашей команды появилась точка приложения усилий. А вместе с ней и возможность сфокусировать своё внимание и силы на конструктивной деятельности.
В ближайший год у нашей команды будет много вызовов, “нерешаемых” проблем, оригинальных решений "нерешаемых" проблем. Будет тяжело, досадно, сложно и почти всегда интересно. Но сейчас мы только-только нащупали почву под ногами.
2. Отключение отчётов и рассылок
5 марта 2022 года, суббота, 11:00.
Сегодня суббота, но весь штаб опять в офисе. Нет, работать по выходным мы начнём чуть позже, а сейчас – перенос рабочего дня из-за 8 марта. День начался с поздравлений девушек. У нас, в офисе CDO, гендерное соотношение примерно 2-к-1 в пользу парней. 20 лет назад в российских вузах на прикладной математике в группе из 25 человек было не больше трёх девушек. Стереотипное представление о том, что ИТ – мужская профессия, уходит медленно, но верно. И это не может не радовать!
За два дня, которые прошли с даты неформального старта нашего проекта по спасению аналитики в Х5 Group, мы попытались осознать масштабы задачи. И главное, что мы поняли: для того, чтобы оценить реальную востребованность данных SAP BW, придётся провести настоящее расследование.
Вот в чём дело. Основных каналов распространения данных из BW четыре: отчёты SAP BO, подключение к кубам BW из Excel, выгрузки данных в Data Lake и рассылки отчётов на почту. Первые три канала находятся под контролем – по ним есть полный набор метаданных, необходимых, чтобы выделить самую востребованную функциональность и сфокусироваться на переносе её на целевую платформу.
По рассылкам всё гораздо сложнее. Во-первых, понять, открывает ли пользователь письма с отчётом или копит непрочитанными в отдельной папке, невозможно. Во-вторых, рассылки ведутся через группы, которые создавались в течение долгого времени без какой-то внятной системы – группы пересекаются по составу адресов, часть из которых неактуальны, а также имеют произвольный уровень вложенности. В-третьих, многие рассылки идут не напрямую из BW, а через БД-прокладки в MS Access. То есть на отдельном сервере, иногда даже на рабочей машине сотрудника, скриптом данные выгружаются из BW, по какой-то произвольной неявной логике преобразуются и улетают файликами в письмах. Клубок очень запутанный, но даже невооруженным глазом видно, что именно здесь – основной потенциал для оптимизации нагрузки.
За сбор и упорядочивание описаний отчётов и витрин в офисе CDO X5 отвечает команда управления методологией. Для этих целей был создан каталог данных, который со временем эволюционировал в целый портал по работе с данными. Сегодня работа с данными в Х5 немыслима без него для 5,5 тысяч пользователей (MAU – Monthly Average Users), про него можно написать не одну статью. Но сегодня у нас другая повестка.
Методологи подготовились ко встрече: собрали информацию по всем рассылкам. Вывели сводную таблицу на экран в переговорке и стали проматывать её, чтобы оценить масштаб задачи. С каждой прокруткой мышки участники встречи всё сильнее предавались греху уныния. На каждый отчёт приходились десятки всевозможных комбинаций гранулярности, фильтров, проекций показателей и групп адресатов. Эти “авгиевы конюшни” можно разгребать до бесконечности. А ведь мы работаем в режиме "завтра может быть поздно".
К счастью, в CDO X5 умеют работать и с данными, и с метаданными и испугать нас большим их объёмом очень сложно. Сперва прозвучал вопрос: "А как так получилось?". Действительно, такой винегрет мог получиться только в отсутствие политик управления рассылками и связанных с ними процессов. Поэтому первым делом было решено “перекрыть входной вентиль”, а именно:
составить перечень учётных записей, из-под которых возможно создание рассылок;
отозвать у них доступ;
завести все запросы на добавление и изменение рассылок через методологов.
Несмотря на очевидную избыточность исследуемого способа доставки отчётности до пользователей, никто не сомневался, что часть рассылок действительно важна для корректной работы бизнес-процессов. Поэтому мы решили их ранжировать на основе уровня должности адресатов каждой рассылки. Потребность в данных адресатов, начиная с CEO и до CEO-3, решили не подвергать сомнению. По остальным нужно будет проводить более глубокое расследование.
Наконец, наш архитектор BI обратил внимание на то, что сам механизм отправки данных неэффективен и избыточен. Каждый день на основе каждого отчёта генерились и отправлялись по почте сотни файлов двум тысячам пользователей, вне зависимости от того, нужен ли конкретному пользователю конкретный файл именно в этот день или нет. К началу 2022 года мы консолидировали значительную часть отчётов на платформе Qlik, отказавшись от Tableau, что, кстати, было провидческим решением, учитывая то, как Tableau "потушил" свои лицензии через пару недель. Но главное – у нас выросла сильная внутренняя экспертиза по Qlik.
Поэтому мы знали, что такое Qlik NPrinting и умели им пользоваться. А значит, могли:
реализовать "печать" отчётов в форматах Excel, PDF, PowerPoint и др.;
запускать "печать" по запросу (функция On-Demand);
диверсифицировать каналы доставки файлов – в дополнение к отправке по почте добавилось размещение файлов на Sharepoint;
создать единый пайплайн формирования итогового файла с ожиданием готовности данных и завершения проверок качества данных;
задать оптимальное расписание "печати" отчётов, предотвратив ежедневную отправку недельных и месячных отчётов.
Запутанный пасьянс начал складываться: пресекаем неконтролируемый рост числа рассылок, оставляем только наиболее востребованные из них и переводим их на современный технологичный движок. В качестве результата имеем win-win-win: пользователи получают отчётность в удобном формате с гарантированным качеством и визуализацией, при том без лишнего спама; CDO получает дополнительную информацию о том, каким бизнес-пользователям какие данные нужны; а для SAP BW высвобождаются вычислительные мощности, необходимые для mission-critical задачи закрытия финансового периода.
Конечно, на реализацию каждого из трёх пунктов намеченного плана было положено очень много сил. Количество "дыр" в управлении рассылками мы на тот момент сильно недооценивали – много раз казалось, что все "входы" перекрыты, но вдруг ранее отключенные рассылки запускались вновь. Пользователи держались за привычные им файлики крепко, несмотря на красочную рекламу новых возможностей. А NPrinting, как и любая более сложная технология, была богата на инциденты на этапе внедрения, что дало возможность менеджеру, отвечающему за это направление, наслаждаться московскими рассветами всю весну и лето 2022 года. Но поставленная задача была выполнена, а без этого спасти аналитику в Х5 вряд ли получилось бы.
3. Перенос аналитической отчётности
15 марта 2022 года, вторник, 11:30
В первом приближении скоуп очерчен, концепт решения определён. Теперь необходимо сверстать план и собрать команду для его выполнения. Драфт плана подготовлен, но ожидания с реальностью расходятся значительно.
Дима: Паш, я построил сводный план на основе оценки архитекторов. Посмотрим?
Паша: Давай. Какой там итоговый срок получился?
Дима: По большей части витрин – декабрь, по каким-то – январь.
Паша: Дим, ты понимаешь, что такой план смысла не имеет? Проще сразу заявление написать.
Дима: А что ты предлагаешь? Там витрин на 900 показателей, которые рассчитываются по логике, эволюционировавшей лет 5, не меньше.
Паша: Я знаю. Но у нас есть время, в лучшем случае, до июня. Всё, что мы не успеем перенести до этого момента, пропадёт.
Дима: Надеюсь, ты в курсе, что там просто названия показателей, без документации? И реверс-инжиниринг ни SAP-овцы с их загрузкой, ни, тем более, мы не успеем провести.
Паша: Понимаю. Давай оценивать то, что мы успеем сделать за 2 месяца. Считаем, что у нас неограниченный ресурс, а требования к сходимости данных – "лучше как-то, чем никак".
В то время мы искренне верили, что на всё про всё у нас считанные недели. Мы понимали, что нужен принципиально другой подход к работе, нежели тот, к которому мы привыкли. Это касалось всех направлений проекта, контуры которого проступали всё четче. Пожалуй, самой объёмной задачей по количеству человеко-дней был перенос аналитической отчётности из BW на целевой, безопасный в новых условиях, стек: GreenPlum + ClickHouse + Qlik. Все отчеты BW, которые не относились к контуру финансового закрытия, должны были быть из BW вынесены.
С бизнес-пользователей быстро была собрана информация о том, какие отчёты BW для них критичны. Эти данные мы наложили на статистику востребованности. Отчёты, которые находилось на пересечении, мы развернули в список показателей и получили таблицу из 900+ строк.
Для без малого тысячи показателей нужно было создать витрины данных. К счастью, в EDW (GreenPlum) у нас были все необходимые базовые витрины, в которых исходные показатели рассчитывались в самых мелких разрезах. Но на пути между базовыми витринами и отчётами должно было произойти много нетривиальных вычислений, чтобы, например, из "Остатки в разрезе <магазин, товар, день>, штуки" получить "Товарный запас (магазины) SF (свежие товары повседневного спроса), дни".
Если попытаться понять, в чём мы прокачались в ходе проекта, то навык решать противоречивые задачи в условиях неопределённости будет точно не на последнем месте. Во-первых, мы обнаружили, что многие показатели в разных отчётах называются по-разному, но по сути идентичны. Трое суток со сном по 4 часа, умноженные на четверых архитекторов данных – и список из 900+ показателей сокращается на треть. На оставшиеся 600 мы посмотрели повнимательнее и поняли, что некоторые показатели являются "невыносимыми", то есть нужны для финансового закрытия, а значит, могут оставаться в BW.
В одном известном фильме попавшийся жулик говорит: "Самая дорогая вещь на земле – это глупость. Потому как за неё дороже всего приходится платить". Чтобы хоть как-то снизить цену, которую нам пришлось заплатить за отсутствие документации по кубам и отчётам, подлежащим выносу из BW, мы решили определить допустимую погрешность в значениях аналитических показателей. Канонически правильный подход, при котором сперва проводится бизнес-анализ, разрабатывается методология, и лишь затем следует разработка алгоритма, не нашёл поддержки у тех, без кого это сделать было невозможно. Потребители справедливо требовали переноса существующих отчётов "как есть", а разработку методологии просили оставить на потом.
Чтобы хоть как-то начать выдавать результат, мы определили допустимую погрешность в 1%. Конечно, на объёмах Х5 Group 1% – это очень много в денежном выражении. Но для первого шага такой точности оказалось достаточно. В конце проекта приёмка показателей, например по РТО, происходила из расчёта "не больше 50 тысяч рублей на магазин в месяц", что в относительном выражении составляет < 0.01%. К счастью, ситуация с миграцией SAP BW из облака складывалась для нас тоже благоприятно – мы не раз получали возможность пролонгировать исходные два месяца срока. Это дало возможность привести аналитику в состояние, близкое к идеальному и, насколько это было возможно, минимизировать дискомфорт от переезда для бизнеса.
4. Kick-off проекта
30 марта 2022 года, среда, 09:30
Проект утверждён инвестиционным комитетом, деньги выделены, нужно начинать работать. Весь проект разделён на три стрима:
Миграция существующей сборки SAP BW из HEC на внутреннюю инфраструктуру X5 Tech.
Перенос аналитической и операционной отчётности из SAP BW на целевую аналитическую платформу DMP.
Перевод продуктов, основанных на данных, с кубов SAP BW на витрины DMP.
Все три подпроекта тесно связаны, несмотря на то, что каждый из них имеет свои цели, беклог, критерии успешности, команду и РП. Переезд SAP BW на наше оборудование возможен только при снижении нагрузки на систему. Снижение нагрузки достигается за счёт части отключения потребителей. Невозможно просто отключить 10 тысяч пользователей от их ежедневного источника информации, без которой бизнес-процессы остановятся. То же самое верно и для десятков внутренних продуктов, аналитические модели которых позволяют выбирать оптимальные цены, сокращать потери, оптимизировать логистические цепочки, формировать богатый ассортимент, а также решать многие другие задачи, стоимость невыполнения которых измеряется девятизначными суммами.
Kick-off носит формальный характер. Времени, прошедшего с момента первого обсуждения задачи, хватило, чтобы нарисовать целевую картину и сформировать стартовый беклог проекта. Теперь необходимо максимально быстро сформировать команду, запустить процессы и площадки и начать поставки. К счастью, изобретать велосипед нет нужды: у нас есть отлаженные процессы, стандарты проектирования и разработки, отлаженная система адаптации новых сотрудников, большой портфель контрагентов, которые, во-первых, знают особенности нашего ландшафта, а во-вторых, доказали свою компетентность на прошлых проектах.
Ответственность за стримы разнесена по нескольким дирекциям. Во многих компаниях такая схема была бы чревата рассинхроном между подпроектами и сложностями в достижении главной конечной цели. Но в нашем случае это совсем не так. Взаимопонимание и общие ценности присутствуют на каждом из уровней взаимодействия: от директоров до экспертов. Наш проект, сложный и по уровню поставленных целей, и по своей структуре, не только впоследствии подтвердит этот факт, но и повысит эффективность взаимодействия и уровень взаимного доверия между подразделениями.
5. Вендор ClickHouse
20 июня 2022, понедельник, 17:30
Наступило лето. Мы “бежим” уже три с половиной месяца. Уже открылось второе дыхание – понемногу начинает складываться ощущение, что у нас получается. Вопрос распространения данных (один из двух ключевых) решается – ClickHouse себя оправдывает. Но мы всё ещё находимся в ситуации самолёта, у которого топлива хватает только на один заход на посадку – право на ошибку отсутствует.
Поэтому при внедрении ClickHouse мы решили “разложить яйца по трём корзинам” и понаблюдать, в какой из них они будут сохраннее. Под два самых нагруженных дашборда (потери и продажи) мы развернули три кластера.
Первым был кластер QuickMarts от Arenadata (ADQM), на котором мы разместили витрины по потерям. Коллеги из Arenadata быстро откликнулись, когда мы попросили их помочь с запуском пилота. К началу пилота экспертиза по ClickHouse у нас в Х5 уже была. Но сервисов с таким уровнем проникновения (тысячи пользователей), работающих на десятках терабайт данных с SLA времени обработки запросов, измеряемым в секундах, у нас не было.
То есть задача была из ряда вон во всех её аспектах: инфраструктурном, операционном и программном. Поэтому экспертиза лидера российского рынка аналитических СУБД была очень кстати. Тем более, подкупала перспектива лёгкой интеграции EDW и HLDM (High Load Data Marts – так мы назвали наш ClickHouse), если они будут на ПО одного вендора.
Два других кластера мы собрали на ванильной версии ClickHouse и привлекли к работам по внедрению двух партнёров-интеграторов, которые в параллель решали одну и ту же задачу – подготовку данных для отчёта по продажам.
Первый ванильный кластер с продажами вышел из гонки достаточно быстро – команда контрагента наш темп не выдержала. А вот второй и ADQM удалось довести до состояния MVP: данные загружаются, дашборды отстраиваются и главное – БД держит нагрузку не хуже атланта. Впереди ещё много работы по отладке и внедрению, но сейчас нужно принять решение: идём в open source или покупаем сборку Arenadata.
На встрече узкий состав участников, представлены две вертикали – архитектурная и проектная. Плюс, разумеется, CDO. Мнения разделились. В пользу решения от вендора: поддержка, коннектор с весёлым названием Tkhemali для интеграции ClickHouse с GreenPlum, гарантия безопасности дистрибутива. В пользу ванильной сборки: дешевизна, отсутствие вендор-лока, инвестиции во внутреннюю экспертизу.
Почти весь пилот казалось, что ADQM – безусловный лидер, и альтернатива нужна только для подстраховки. А сейчас, при подведении итогов видно, что Tkhemali пока слишком кислый. Наверняка Arenadata рано или поздно доведёт его до кондиции. Но мы не можем позволить себе экспериментировать и отлаживать решения, от которых зависят корпоративные сервисы с таким высоким уровнем проникновения. К тому же, последняя версия ClickHouse даёт больше возможностей для управления подключениями к кластеру, а ADQM до этой версии ещё не обновился.
Выходит, надо идти в open source? Это значит – взять на себя полную ответственность за поддержку и развитие БД с сотнями миллиардов записей и десятками тысяч запросов ежедневно. Ответственность за создание интеграций с хранилищем и озером данных на терабайты ежедневного инкремента. За то, что в устанавливаемых патчах не окажется вредоносных "закладок". За прочих "чёрных лебедей", которые встречаются в природе.
Главный арбитр принимает решение – использовать эту возможность для качественного перехода нашей команды от покупателей технологии к интеграторам. Сторонники более безопасного "вендорского" варианта умолкают в соответствии с принципом disagree & commit.
Пройдёт полгода. HDLM полностью закроет вопрос ad-hoc отчётности. Но не менее важным будут "побочные" результаты принятого решения. На этот же кластер по лямбда-архитектуре будет заведён realtime поток чеков, что позволит запустить в мобильном приложении “Пятёрочки” фичу отображения всех покупок клиента с минимальной задержкой по времени. И, конечно, у нас прибавилось веры в собственные силы.
Продолжение следует…
