🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Как обеспечить качество данных
Выделяют такие критерии по Data Quality, как:
(по сути чек-лист, по которому можно пробежаться, уменьшив вероятость использования некачественных данных)
▶️Полнота данных. Основная цель - удостовериться, что нет пропусков в важных полях. Проверка осуществляется как правило простым SQL-запросом с фильтрацией NULL-значений или пустот. Можно искать пропуски как точечно, так и посчитать их в процентом соотношении ко всем строкам в исследуемом наборе данных, чтоб в общих чертах понимать масштаб проблемы.
Также подразумевает под собой в целом полноту набора данных: точечных пропусков может и не быть, но могут отсутствовать целые наборы строк. Или даже присутствовать лишние строки. Проверить можно обычным COUNT-ом, или группировкой с SUM по ключевым значениям, или создать Pivot-таблицу, зависит от ситуации. Главное - чтоб был эталон, с чем можно это все сверить.
▶️Точность и согласованность. Нужно удостовериться, что данные соответствуют реальности, или корректны, а также что одни и те же данные в разных источниках совпадают. Здесь под проверку может попадать что угодно: это может быть и наличие лишнего признака (например, данные могут принимать только значения А или Б, но внезапно присутствуют данные со значением С), и ошибки с датами (слишком давняя дата или будущая там, где это неуместно), и нарушение логики (например, дата заказа позже даты доставки), и несоответствие количественных значений (можно детально сверить выборку с первоисточником при помощи джоинов или вложенных запросов), и наличие аномальных статистических выбросов в выборке (можно проверить через STDDEV(amount)) и многое другое.
▶️Уникальность. Тут не должны встречаться дубликаты. Пример того, как может осуществляться такая проверка через группировку одного или нескольких столбцов с использованием HAVING COUNT:
SELECT customer_email, COUNT(*)
FROM customers
GROUP BY customer_email
HAVING COUNT(*) > 1
Также стоить отметить, что если вдруг по какой-нибудь бизнес-логике предусмотрено наличие полностью повторяющихся строк, то в этом случае необходимо создавать дополнительные ID, которые все равно будут обеспечивать уникальность данных. Еще при самой загрузке данных в таблицу можно вспомнить про UNIQUE INDEX чтобы избежать загрузки дублей.
▶️Актуальность. Данные должны обновляться вовремя. Обычно в DWH указывается дата обновления той или иной таблицы. И как вариант, чтобы это проверить - сравнить данные в столбце наподобие last_update с SYSDATE, учитывая некоторый временной интервал:
SELECT *
FROM products
WHERE last_update > SYSDATE - INTERVAL '1' MONTH
▶️Соответствие формату. Данные должны иметь определенный вид (например, e-mail должен содержать @__.ru). Проверка осуществляется через LIKE, либо через REGEXP_LIKE:
SELECT email
FROM users
WHERE NOT REGEXP_LIKE(email,
'^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$')
P.S. Автоматизировать процесс DQ можно через создание процедур/триггеров, желательно на нескольких этапах: сначала проверять данные на этапе загрузки, а потом проводить проверку уже загруженных данных.