#tmh_статья📖 Привет! Давно не виделись, навалилось много задач. И как раз об одной интересной задаче я расскажу сегодня. А именно, о переносе целого дашборда из одной версии Superset в другую. Я поделюсь основными ошибками созданного дашборда, так что информация будет полезна как новичкам, так и опытным аналитикам.

Как и многие другие IT специалисты я очень люблю в скобочках НЕТ рефачить чужой код. Так вышло, что дашборд, который мне нужно было переносить, был сделан до моего прихода в компанию, а тот, кто его делал, благополучно свалил перед самым моим приходом. Естественно, никакой документации мне не оставили, на что советую тебе обратить внимание - обязательно оставляй хотя бы небольшое описание того, что натворил создал.

Делать нечего, я начал разбираться в этом Франкенштейне. А дашборд действительно был таковым, и сейчас ты узнаешь почему. Представляю основные ошибки, которые мне пришлось исправлять, и которые ты, я надеюсь, допускать не станешь:

1 чарт = 1 датасет. Ужасная концепция, которая превращает дашборд в чудовище. На первом же листе меня встретили 17 чартов, написанных на 11-ти!!! датасетах. Помимо необходимости создания под эти датасеты 11-ти отдельных обновляемых таблиц в хранилище данных, такая аппликация лишает дашборд главного качества - его гибкости. При изменении параметра одного чарта другие чарты не будут подстраиваться под выбранный фильтр, ведь они никак не связаны на уровне данных. Поэтому, старайся минимизировать количество датасетов, в идеале 1 лист = 1 датасет. Это не касается, наверно, только части ad-hoc отчетов. В этой задаче 9 из 11 датасетов использовали один и тот же источник данных, так что я просто взял все 9 запросов и объединил в один. Новичку может быть сложно, но поверь, оно того стоит.

Неверная глубина детализации. При первом открытии дашборда я обратил внимание, что он достаточно долго загружался. Познакомившись с ним поближе я понял, в чем причина. Многие датасеты были выполнены с детализацией до дня или до конкретного пользователя, что делает итоговую таблицу очень тяжелой. При этом сами чарты, основанные на таких датасетах, использовали агрегацию данных. Значит, агрегировать их можно на уровне датасета, что уменьшит объем данных и снизит нагрузку на систему. Осталось решить, как агрегировать. Первым делом, я изменил детализацию даты до недель. На дистанции года сравнивать недели вместо каждого дня удобнее и информативнее. Для специфичных чартов, где необходима ежедневная детализация, я создал отдельный датасет, ограничив его при этом последним месяцем. Детализацию до пользователя я полностью убрал, просто посчитав их количество в нужных мне разрезах. Итог: таблица стала легче в несколько раз, я могу сравнивать дни между собой в пределах месяца, на дистанции года я сравниваю недели, а моя система летает и чувствует себя хорошо.

Датасет на основе Legacy-таблиц. Когда я открыл второй лист дашборда я подумал, что датасет снова очень тяжелый - страница загружалась неимоверно долго. Спустя 5 минут (а именно на 300 сек настроен таймаут db engine) я не увидел надписи, говорящей о тайм-ауте загрузки. Тогда я открыл редактор чарта и увидел заветную надпись о том, что датасет удален! Но как это возможно? Все просто, его удалил наш дата инженер. Все дело в том, что датасет был основан на устаревшей Legacy-таблице, которая была в списке на удаление. Проведя дальнейший разбор дашборда я обнаружил 5 таких таблиц. Отличный подарок, кто бы ты ни был, спасибо. Мораль: строй датасет только на актуальных данных.

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

А нравится ли тебе рефачить чужой код? Пиши в комментах и обязательно подписывайся на канал, совсем скоро я выкачу обещанный roadmap в IT.