Метрика на дашборде выросла на 15%, но в исходной таблице-источнике такого роста не видно. Как будешь расследовать расхождение между дашбордом и источником?

Короткий ответ

Сверяю SQL-определение метрики на дашборде (фильтры, джойны, дедупликацию, период агрегации и часовой пояс) построчно с ручным запросом к источнику и ищу первую точку, где числа расходятся — там и причина.

Как это работает подробнее

расхождение дашборда и источника почти всегда объясняется различием в логике расчёта (другой фильтр, другой JOIN, кэш, другой часовой пояс), а не «ошибкой» одной из сторон — поэтому расследование идёт через сравнение логики запросов, а не цифр.

Пример кода

Пример SQLКопировать

-- шаг 1: построчно воспроизвести логику дашборда
SELECT count(DISTINCT o.order_id)
FROM orders o
JOIN order_status s ON s.order_id = o.order_id
WHERE s.status = 'completed'
  AND o.order_date >= date_trunc('month', current_date);
-- шаг 2: проверить, не размножает ли JOIN строки
SELECT o.order_id, count(*)
FROM orders o JOIN order_status s ON s.order_id = o.order_id
GROUP BY o.order_id HAVING count(*) > 1;

Что использовать на практике

• Порядок действий. 1) достаю точный SQL/конфиг метрики, который использует BI-инструмент; 2) воспроизвожу его вручную против «сырого» источника на том же периоде; 3) сверяю промежуточные числа (число строк после каждого фильтра/джойна); 4) проверяю, не закэширован ли дашборд (старые данные) и совпадает ли часовой пояс агрегации; 5) проверяю, не задвоение ли из-за JOIN один-ко-многим.

Подводные камни

• Частые ошибки. сразу считать правильным дашборд (или наоборот источник), не разобрав логику обоих; не проверять кэш/расписание обновления дашборда — «рост» может быть из-за устаревших данных; игнорировать различия часовых поясов между BI-инструментом и базой данных.