Apache Superset. Первый взгляд на BI инструмент.
Ни для кого не секрет, что для того, чтобы в полной мере познакомиться с возможностями нового инструмента, нужно решить какой-либо кейс, приближенный к боевым задачам. Демонстрационные примеры из раздела “Быстрый старт” хотя и позволяют в максимально сжатые сроки составить первое впечатление, но не позволяют оценить размер и количество подводных камней, которые могут быть у платформы. Эти примеры составлены так, что на показ выставлены лишь сильные стороны, при этом моменты, в которых инструмент слаб, вуалируются.
Я понимаю, какая проблема в настоящее время стоит перед частью руководителей отделов BI аналитики: выбор оптимального бесплатного решения для миграции с платной платформы. Но повторю мысль, которую озвучивал ранее: сравнивать бесплатные и платные BI программы не корректно. Я решил пойти следующим образом, сначала собрать управленческую панель с помощью уже знакомого мне решения, а потом повторить тот же путь с помощью нового. Так можно уйти от прямого сравнения в лоб. Нужно было лишь вдохновение, и оно не заставило себя долго ждать. При очередном посещении гипермаркета со строительными материалами, решил провести “ревизию” секции с электроинструментом. После ознакомления с текущим ассортиментом и ценами на товары, стало очень грустно, но для себя решил, что буду делать дашборд по этой тематике.
Фундамент любой аналитики - данные. Качественного датасета в Интернете я не нашел (возможно, плохо искал). Собрать такой массив информации самостоятельно не представляется возможным, так как надо получить маркетинговые данные от большого числа производителей, распределить продажи по основным торговым сетям, то есть получить доступ к коммерческой тайне многих хозяйствующих субъектов. Поэтому пошел проторенной дорожкой – генерация рандомного датасета. Продажи электрического инструмента в абсолютном выражении в нашей стране за год измеряются миллионами штук. Я решил ограничиться выборкой в 300 тыс. записей и добавить в датасет только города-миллионики. Так как число жителей населенных пунктов разнится, то и продажи по городам должны распределяться с определенной вероятностью. В Python написать такой цикл не составит большого труда, но и в табличном редакторе Excel можно найти выход. Для каждого города указываем число жителей, находим сколько это будет в процентах от общей суммы по столбцу и вычисляем сумму по доле нарастающим итогом. Для рандомного выбора города используем формулу: =ИНДЕКС(диапазон с названиями городов;СЧЁТЕСЛИ(диапазон с долями нарастающим итогом;"<="&СЛЧИС())+1).
Цену на товар можно задать как случайное число из диапазона. Для придания максимального правдоподобия ценообразованию следует учитывать следующий факт: цены на профессиональный, полупрофессиональный инструмент и инструмент для домашнего использования могут различаться кратно, поэтому прежде, чем моделировать данный раздел для какой-либо торговой сети, нужно сделать предположение о структуре покупателей. Я не стал так усложнять расчеты, так как обыгрывал ситуацию сразу с рядом ритейлеров.
Теперь настала пора самого интересного момента – определиться с долей разных инструментов в общей массе продаж. Сразу вспоминается головоломка с собеседования: “Сколько настройщиков пианино в мире?” Ответить на вопрос про долевое распределение инструментов без ознакомления с официальной статистикой не представляется возможным, поэтому остается лишь теоретизировать. Если зайти на сайты основных интернет-магазинов, торгующих инструментом, то можно увидеть количество представленных моделей по каждой группе товаров. Конечно, между количеством представленных моделей и объемом продаж не может быть прямой корреляции, но косвенная взаимосвязь имеется, и в качестве базы распределения такая величина вполне может подойди. В итоге получаем ситуацию, как на приведенном рисунке.
Красивые изображения в итоге пришлось убрать, чтобы не разбираться с авторскими правами на фото
Если внимательно рассмотреть распределение товаров, может показаться, что доля продаж в абсолютном выражении шуруповертов, перфораторов и болгарок несколько завышена. Отчасти это правда, так как под одной категорией в интернет-магазинах могут быть представлены аппараты разных типов, но для тестового датасета это не критично.
Теперь пару слов о дашборде собранном на платной BI платформе. Я использовал картинки для иллюстрации товарных категорий. В целом данный подход всегда спорный, так как графика лишь крадет полезное пространство управленческой панели. С другой стороны, рисунки можно сделать кликабельными, и тогда они станут гиперссылками для перехода на страницы отчета с детализаций по производителям.
По задумке на стартовой странице хотелось отобразить не только валовую выручку по электроинструменту, но и объем продаж в абсолютном выражении, минимальную/максимальную цену единицы инструмента, а также среднюю цену продажи. Если вывести все эти значения в качестве отдельных карточек, то будет занято слишком много места. Я выбрал подход с возможностью выбирать четыре последних показателя посредством фильтра. Реализовано это путем добавления в модель вспомогательной таблицы. В ней два столбца: названия мер и их код. Столбец с названиями мер становится срезом, а фильтруемый столбец с кодами попадает в формулу, которая работает как функция выбора, подставляя в расчет одну из четырех мер.
Пути доработки такого графического отчета. Во-первых, расположить товарные группы в порядке их значимости для бизнеса. Во-вторых, необходимо добавить листы с детализацией продаж инструмента в разрезе производителей. Можно добавить разбивку на профессиональный, полупрофессиональный сегмент, а также модели для домашнего использования. В-третьих, в модель данных необходимо интегрировать данные о планах продаж за указанный период. В-четвертых, неплохо сделать сравнение с 2020 годом. Следовательно, нам нужен не только датасет за 2020 год, но и техническая таблица соответствия торговых недель в двух годах. В-пятых, нужно учесть переходящие праздники. Одним словом, работы еще много.
А теперь настала пора перейти к обсуждению решения на платформе Apache Superset.
ETL. Функционал по предпроцессингу сырых данных отсутствует, поэтому все этапы нужно выполнять сторонними программами либо с помощью языков программирования.
База данных. Для хранения итоговых датасетов, которые станут основой для витрин данных, нужно разворачивать БД. У аналитиков, которые будут работать с БД, должны быть права на создание таблиц, представлений и пользовательских функций. На этапе прототипирования для заливки данных можно использовать DBeaver. Графический режим импорта данных позволит сократить время на предварительное создание таблиц. Если таблиц очень много, то лучше сразу подготовить представления. В идеале: один дашборд – одно представление.
Получение данных. Датасеты, меры, расчетные столбцы – все sql-запросы. Помните это, планируя работу над будущим проектом. Если выберите в качестве основного хранилища данных не реляционную, а аналитическую БД, то сможете здорово упростить себе жизнь за счет расширенного диалекта sql. Плюс можно будет получить выигрыш в скорости выполнения запросов по выборке данных.
Расширение возможностей SQL. Возможно применять Jinja Templates. Более подробно что это такое и с чем это едят, можно прочитать в официальной документации. По умолчанию поддержка шаблонов отключена. Для активации данного функционала нужно отредактировать файл superset_config.py Но если вы зайдете в работающий контейнер с помощью команды docker exec -it superset bash, то по адресу /app/superset/superset_config.py вы его не найдете (по крайней мере у меня с dockerhub скачивается именно такой образ). Редактировать нужно файл config.py. В контейнере нет предустановленных редакторов nano или vim. Конечно, познакомиться с содержанием указанного файла можно и с помощью стандартной команды Linux – more, но без подсветки синтаксиса читаемость просто нулевая. Поэтому лучше пойти другим путем. В редакторе VS Code открываем раздел с контейнерами, находим config.py и параметру ENABLE_TEMPLATE_PROCESSING устанавливаем значение True.
Рисунки. Рисунки подтягивают на холст по url, поэтому мало подготовить иконки, нужно еще разместить их на сервере. Как правильно прописать ссылки на изображения можно прочитать в руководстве по Markdown.
Верстка макета. Собирать макет проще всего, если платформа поддерживает режим свободного перемещения объектов по холсту (как в редакторе векторной графики). С Apache Superset ситуация несколько иная, в инструменте реализована верстка по сетке, как во фреймворке по созданию сайтов Bootstrap. Вы можете добавлять на лист строки и столбцы. В них, как в контейнеры, можно помещать визуальные компоненты будущего отчета. При этом разработчик ограничен 12 колонками по горизонтали. Распределить их между графиками и таблицами можно, но вот создать пропорциональную композицию из 5 или 7 одинаковых элементов уже не получится. Поэтому хотя в данном BI инструменте и реализована возможность создавать карточки, от данного подхода пришлось отказаться в пользу единой таблицы со сводным метриками.
Механика визуальных эффектов. Еще одна причина почему я отказался от идеи использовать карточки, это невозможность простым способом добиться вывода различных мер в один контейнер. То есть получить по отдельности количество продаж в штуках, минимальную, среднюю и максимальную цену в качестве мер не проблема, так как это простейшие sql-запросы, но вот реализовать переключение этих мер на холсте через фильтр сходу у меня не получилось. Продолжать эксперименты по данному вопросу не стал, так как бизнесовой отдачи это не принесет.
Таблицы. По данному пункту все сравнительно нормально. Типовой функционал реализован, только не хватает более гибкой настройки итоговых результатов.
Графики и диаграммы. Ситуация аналогичная. В арсенале Apache Superset присутствуют визуализации на все случаи жизни, но вот добиться оформления согласно вашей дизайнерской задумки стандартными командами не получится.
Английский язык. Часть моментов отображается на языке Шекспира. Как выкручиваться из данной ситуации решать только вам. Я руководствовался принципом: “Пусть безобразие, но единообразие” и не стал присваивать алисы колонкам на кириллице. Сам текст записей в БД оставил как есть.
Трудоемкость разработки отчета. Оставим за скобками разговора моменты с первоначальным развертыванием платформы и ее технической поддержкой. Если достаточно шаблонной верстки и все метрики можно вытащить простым sql-запросом, то мы в плюсе, так как не нужно осваивать дополнительный инструментарий, так как абсолютное большинство аналитиков знает язык запросов. Если требуется провести миграцию существующего пакета регулярных дашбордов, то трудозатраты будут расти как снежный ком. От части моментов в макетах придется отказаться, где-то нужно будет тратить время на поиск лайфхаков, в крайнем случае, обращаться за помощью к разработчикам.
