Хочу поделиться привычкой, которую я бы очень советовал прокачивать всем, кто работает с данными: не верить витрине сразу после того, как запрос или DAG отработал.
Довольно легко увидеть результат, не обратить должного внимания и пойти дальше. Но часто в результате будет проблема: строки размножились после JOIN, дата уехала, NULL отрезал часть данных, grain поменялся, но вот итоговая цифра будет выглядеть очень правдоподобно.
Можно начать с простых проверок.
1️⃣ Сначала посмотреть количество строк, чтобы объём примерно совпадал с ожиданием. Если вчера было 120 тысяч строк, а сегодня внезапно 3 тысячи, это повод остановиться.
select count(*) as rows_cnt
from mart.sales_daily;
2️⃣ Потом проверить период. Очень часто данные есть, но лежат не за ту дату, которую ты открываешь в витрине или BI.select
min(dt) as min_dt,
max(dt) as max_dt
from mart.sales_daily;
3️⃣ Дальше посмотреть ключевые поля. Если в ключе появились NULL, дальше могут поехать JOIN, агрегации и связь с другими слоями.select
count(*) as rows_cnt,
count(order_id) as order_id_cnt,
count(dt) as dt_cnt
from mart.sales_daily;
4️⃣ Отдельно стоит проверить дубли на том уровне, на котором должна жить витрина. Если одна строка должна быть “один заказ за день”, значит это и нужно проверять. Если после JOIN строк стало больше, не всегда это ошибка, но это точно нужно понимать.select
order_id,
dt,
count(*) as cnt
from mart.sales_daily
group by order_id, dt
having count(*) > 1;
5️⃣ И уже после этого посмотреть контрольные суммы, не потерян ли большой кусок данных между слоями.select
sum(amount) as total_amount
from mart.sales_daily;
В итоге получился короткий чек-лист: строк стало ожидаемо, период правильный, ключевые поля не пустые, grain не сломан, суммы выглядят адекватно относительно предыдущего слоя.Это занимает несколько минут, но сильно экономит время, когда потом приходится разбираться, почему пайплайн отработал, но данные поехали.
📍 Сохраняй себе. Такие проверки скучные ровно до первого случая, когда они спасают несколько часов разбора.
#материалы