У каждого аналитика есть дашборд, в который когда-то было вложено много сил. Он мог нравиться, в нём были визуальные приколы, кастомные графички. Но со временем выясняется, что это превращается в заброшенное место: загрузка занимает вечность, данные некорректные, а поддержки нет.
Почему так происходит?
❓ Меняется логика в источниках. Источник, на который завязан дашборд, может стать неподдерживаемым. Автоматизация может падать, события меняются, а узнаём мы об этом только спустя дни, когда метрики уже просели. Обычно это происходит так, что продукт сам находит проблему и приходит к аналитику.
💻 Неоптимальные запросы. Скрипт, формирующий таблицу, становится медленным. Чарты грузятся по миллион лет, появляются ошибки при построении графиков, таймауты, ошибка в источнике данных и тд.
📕 Падает читаемость. Кор-дашборд должен закрывать 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