Рефакторинг дашбордов

У каждого аналитика есть дашборд, в который когда-то было вложено много сил. Он мог нравиться, в нём были визуальные приколы, кастомные графички. Но со временем выясняется, что это превращается в заброшенное место: загрузка занимает вечность, данные некорректные, а поддержки нет.

Почему так происходит? ❓ Меняется логика в источниках. Источник, на который завязан дашборд, может стать неподдерживаемым. Автоматизация может падать, события меняются, а узнаём мы об этом только спустя дни, когда метрики уже просели. Обычно это происходит так, что продукт сам находит проблему и приходит к аналитику.

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

📕 Падает читаемость. Кор-дашборд должен закрывать 80% потребностей парой метрик и фильтрами. Но как только бизнес начинает добавлять всё подряд, дашборд превращается в мусорку. Читаемость и смысл теряются, а основной вопрос, на который хотел ответить бизнес отчетностью размывается.

🤗🤗🤗 Нет поддержки. Часто аналитики забивают на отчётность, вспоминают о ней только при баге или новой хотелке бизнеса. Хотелка бизнеса: а что, если нам посмотреть на срез тех людей, кто кушал пиццу вчера утром?

😝 Что делать? 🍪🍪 Оптимизировать скрипты заранее. Использовать планы запросов в БД, избегать лишних джойнов. Если работаете со вьюхами, подумайте о том, чтобы перекладывать данные в материализованную таблицу. Это позволит ускорить построение.

⚠ Ставить алерты и сенсоры. Если данные не доехали, доверие к отчётности подрывается. Решение простое: алерты + сенсоры.

🔽 Пример сенсора в Airflow: `python from airflow import DAG from airflow.providers.postgres.sensors.postgres import PostgresSensor from airflow.utils.dates import days_ago

with DAG( dag_id="example_postgres_sensor", start_date=days_ago(1), schedule_interval="@daily", catchup=False, ) as dag:

wait_for_data = PostgresSensor( task_id="wait_for_data", postgres_conn_id="zasql_python", sql=""" SELECT 1 FROM my_schema.my_table WHERE date = '{{ ds }}' LIMIT 1; """, poke_interval=60, # проверка раз в минуту timeout=60 * 60, # максимум час soft_fail=False, # если True — скипнет таску, а не упадёт ) Плюс: в Superset (и других BI-системах) есть логи просмотров. Если графики никто не открывает, их стоит убрать, чтобы не перегружать дашборд. В Superset есть еще можно настроить правило: Если данных за сегодня по условию нет, то высылаем алерт на почту. Не реклама, честно. 🙊 Договариваться с бизнесом про цель дашборда. Аналитик не должен тратить недели на отчётность, которая решается цепочкой задач. Сначала фиксируем цель: что именно нужно отслеживать и зачем. Всё остальное — вторично. Кроме того, не нужно перегружать дашборд лишней информацией. Определяем четко смысл. Что связано с графиком может отдельно выноситься ссылкой.

Когда я только выходил на одно из своих предыдущих мест, первой задачей было сделать рефакторинг имеющегося дашборда, так как в источнике поменялась логика, а предыдущий сотрудник уволился. В итоге пришлось полностью пересобирать дашборд, так как это в моменте было нужно, но затем выяснилось, что этим дашбордом никто не пользуется (посмотрел по логам просмотрам), вот было мое удивление конечно, хотя задача была в приоритете изначально. В этом посте я собрал то, с чем сталкивался, надеюсь я не один такой 😏 *Рефакторинг дашбордов — это всегда больно. Приходится возвращаться к работе, которая уже сделана. Но если заранее оптимизировать запросы, следить за источниками и активностью, договариваться с бизнесом о целях, то дашборд не превратится в заброшку, а останется рабочим инструментом.

Ну а чтобы закрывать потребности бизнеса в специфичных срезах, обычно создается бот с выгрузкой Excel (в MatterMost, Telegram). Про это думаю написать дальше* Ставьте 🐳****, если пост был полезен, и делитесь своим опытом в комментариях.

@zasql_python`