В одной из сдач по DE-практикуму в итоговой таблице получилось 112 650 строк. На первый взгляд всё нормально: загрузка прошла, таблица заполнилась, можно идти дальше и собирать витрину.
Но сначала нужно понять, что означает одна строка в этой таблице. В нашем случае это одна позиция заказа, а её уникальность определяется парой
order_id и order_item_id.Допустим, при сборке факта к позиции заказа присоединились две версии одного клиента. Запрос выполнится без ошибки, таблица заполнится, но строк станет больше, а выручка в отчёте окажется завышенной. Скорее всего, проблему заметят уже в BI, где искать её будет гораздо сложнее.
➡️ Поэтому отдельно проверяем, нет ли в факте повторяющихся позиций:
select
order_id,
order_item_id,
count(*) as row_count
from core.fct_order_items
group by
order_id,
order_item_id
having count(*) > 1;
Пустой результат означает, что дублей по выбранной гранулярности нет. Дальше проверяем внешние ключи товара, продавца и клиента, а также убеждаемся, что для одного клиента не осталось несколько актуальных версий.
↘️ На втором скрине эти проверки уже собраны в
pipeline_smoke_check в Airflow. Количество дублей, пустых ключей и конфликтующих версий равно нулю, а размер текущей загрузки составляет те самые 112 650 строк.Теперь эти проверки не нужно каждый раз повторять руками. При следующем запуске пайплайн выполнит их сам и сохранит результат для конкретной загрузки.
В работе инженер данных отвечает за то, чтобы аналитики и другие потребители получили данные, которым можно доверять. Поэтому на собеседованиях регулярно спрашивают про уникальность, полноту, связи между таблицами и корректность загрузки.
👍 Можно начинать с двух простых вопросов: что означает одна строка в таблице фактов и какие поля делают её уникальной? Если на них есть внятный ответ, дальше уже понятно, какие проверки нужно встроить в пайплайн.
#кейсы