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

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

Почему так происходит?

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

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

📕 Падает читаемость. Кор-дашборд должен закрывать 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳31622



tgoop.com/zasql_python/421
Create:
Last Update:

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

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

Почему так происходит?

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

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

📕 Падает читаемость. Кор-дашборд должен закрывать 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

BY Заскуль питона (Data Science)


Share with your friend now:
tgoop.com/zasql_python/421

View MORE
Open in Telegram


Telegram News

Date: |

Developing social channels based on exchanging a single message isn’t exactly new, of course. Back in 2014, the “Yo” app was launched with the sole purpose of enabling users to send each other the greeting “Yo.” Ng, who had pleaded not guilty to all charges, had been detained for more than 20 months. His channel was said to have contained around 120 messages and photos that incited others to vandalise pro-government shops and commit criminal damage targeting police stations. A Hong Kong protester with a petrol bomb. File photo: Dylan Hollingsworth/HKFP. Ng was convicted in April for conspiracy to incite a riot, public nuisance, arson, criminal damage, manufacturing of explosives, administering poison and wounding with intent to do grievous bodily harm between October 2019 and June 2020. You can invite up to 200 people from your contacts to join your channel as the next step. Select the users you want to add and click “Invite.” You can skip this step altogether.
from us


Telegram Заскуль питона (Data Science)
FROM American