Забота о качестве данных часто кажется малопривлекательной, но, по иронии, именно на нее мы тратим большую часть времени. Возможно, Data Quality — важнейший компонент пайплайна данных, ведь дашборд и аналитика, сгенерированные на основе недостоверных и ненадежных данных, окажутся бесполезными. Команда VK Cloud Solutions перевела статью о том, что такое Data Quality на самом деле и как обеспечивать его на разных уровнях пайплайна.

В чем сложности с Data Quality

У нас нет простых и однозначных формул, чтобы определить, верны ли данные. Подобно заболоченному пруду без притока воды, данные могут быстро «застояться». А корректные вчера станут некорректными через месяц. К счастью, у нас в распоряжении есть фундаментальные приемы и подходы для валидации качества данных. Все дело в поиске аномалий, не соответствующих конкретным требованиям, и наборов записей, противоречащих логичным допущениям в рамках текущих процессов.

Стратегии Data Quality

Данные можно рассматривать на трех уровнях: ETL, бизнес-логики и отчетности. 

• Уровень ETL содержит код для приема данных и их перемещения между исходной и целевой системой. Например, из базы данных приложения в хранилище данных. 
  
• Уровень бизнеса занимает промежуточное положение между необработанными данными и финальными моделями данных. 
  
• Уровень отчетности — это дашборды, с которыми работают бизнес-пользователи. 
  

Ниже мы рассмотрим приемы, которые можно использовать на каждом уровне. Для примеров используем PostgreSQL. Мне понадобятся две таблицы: Clicks и Views. В Clicks содержатся данные о пользователях, которые кликнули по ссылке на веб-странице, а в таблице Views — данные о пользователях, которые посетили веб-страницу.

Data Quality на уровне ETL

Первый уровень пайплайна — уровень ETL. У разных компаний из разных отраслей проверки качества данных на этом уровне обычно похожи друг на друга. Их цель — убедиться, что при перемещении из исходной системы в целевую данные не потерялись и не испортились. 

Мы проверяем:

• разницу в количестве строк, чтобы выявить данные, которые были неправильно добавлены или потерялись;
  
• частично загруженные дата-сеты, обычно с большим количеством строк со значением null;
  
• дублированные записи.
  

Примеры с использованием SQL

Количество строк:

WITH
source_count as (Select count(*) as total_count from source) ,target_count as (Select count(*) as total_count from target)SELECT
   CASE WHEN 
     (select total_count from source_count) = (select total_count from target_count) 
    THEN True 
    ELSE False
END as valid_row_count
FROM 
  pipe_table_1

В примере выше мы проверяем, совпадает ли количество строк в исходной и целевой системах. В большинстве случаев количество строк должно оставаться одинаковым в обеих таблицах. Для этого нужно проверить, не привели ли преобразования между таблицами к неожиданному изменению этого параметра. К примеру, количество пользователей в приложении должно быть одинаковым и в базе, и в хранилище данных. 

Есть ситуации, когда количество строк ожидаемо должно измениться. В этом случае нужно проверять, попадает ли количество строк в ожидаемый диапазон. Кроме того, важно отметить, что здесь используются обобщенные табличные выражения для удобочитаемости оператора SQL.

Проверка результатов Join-операции:

WITH join_count AS ( 
SELECT    count(*) AS view_count 
FROM views
LEFT JOIN clicks ON clicks.view_id = views.id
)
SELECT
CASE 
     WHEN (SELECT view_count FROM join_count) = count(1) 
     THEN True
     ELSE False
END AS valid_join
FROM
views;

В примере выше мы проверяем, не изменилось ли количество строк в таблице по сравнению с исходной таблицей после операции left join. Здесь нужно убедиться, что в таблицах нет повторяющихся ключей — обычно такую проверку выполняет и сама база данных, но не тогда, когда мы имеем дело с производными таблицами или представлениями. 

Это ограничение не всегда применимо, поскольку в результате некоторых соединений количество строк в объединенной записи может увеличиваться или уменьшаться. В этом случае нужно представлять себе ожидаемый диапазон значений.

Data Quality на уровне бизнес-логики

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

Эти проверки — вторая преграда, не пускающая некорректные данные из уровня ETL. Ведь проверять качество данных на этом уровне по каждому параметру бывает достаточно долго и непрактично.

А на уровне бизнес-логики обычно проверяют, не выходят ли численные показатели за пределы диапазона, заданного бизнес-требованиями.

SELECT 
   count(*), 
   year
FROM
   views a
JOIN date b on a.date _id = b.date_id
GROUP BY 1,2
HAVING count(*) > [EXPECTED_RANGE];
--------------------------------------------------------
SELECT 
   count(*), 
   year, 
   month
FROM Views a
JOIN date b on a.date _id = b.date_id
GROUP BY 1 2,3
HAVING count(*) > [EXPECTED_RANGE];

Один из приемов — отслеживать изменение метрики или числового показателя за разные периоды времени. В этом примере мы изучаем количество просмотров за разные годы и месяцы.

Мы пытаемся выявить неожиданный рост или падение количества просмотров. Важно также различать ожидаемые и непредвиденные изменения. В нашем примере мы рассматриваем количество просмотров на сайте онлайн-магазина. Одна из ожидаемых тенденций — увеличение количества просмотров в праздничные дни.

SELECT
  CASE WHEN
    count(a.num_view) >= count(b.num_clicks)
  THEN True 
  ELSE False
  END as click_validation
FROM
views a
LEFT JOIN clicks b ON b.click_id = a.click_id

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

Data Quality на уровне отчетности

Это последний этап пайплайна, на нем конечные пользователи взаимодействуют с вашими данными. Но это не означает, что дата-инженерам и дата-аналитикам не нужно использовать уровень отчетности для поддержания качества данных.

Один простой прием — постройте график за год, месяц или день и глазами проверьте наличие выбросов и аномалий. Подобные ошибки легко увидеть на графике.

Другой отличный вариант для уровня отчетности — создавать дашборды с метриками и проверками качества. Сначала проверяйте эти дашборды, потом отправляйте данные пользователям.


Пример дашбордов
 

Заключение

Проверки качества данных нужно максимально автоматизировать. Их следует встраивать в код пайплайна, но так, чтобы его можно было без проблем изменить. В зависимости от критичности данных и валидации можно по-разному настроить результат проверки. Например, при наличии ошибок:

• работа полностью останавливается;
  
• выводится предупреждение о возникших проблемах;
  
• записи с ошибками перемещаются в отдельную область;
  
• обработка данных продолжается.
  

Разные инструменты, например Trifacta, помогают упростить и автоматизировать проверку качества данных. В некоторых ETL-инструментах, таких как Informatica, реализованы встроенные функции проверки Data Quality. И все же, чтобы ваша проверка имела смысл, важно понимать, как внедрить ее с нуля.

При проектировании пайплайнов данных именно качество данных должно быть той движущей силой, которая больше всего влияет на результаты разработки. Чтобы дата-инженеры могли устранять проблемы и повышать качество данных, им нужно отчетливо представлять себе эти данные. Важно помнить, что за качество не может отвечать один отдел или сотрудник.

В этой статье дан общий обзор темы качества данных, приемов его мониторинга и стратегий по активной работе с данными. Как мы уже упоминали, качество — это критически важный компонент системы по работе с данными. Не жалейте на него времени и ресурсов! Data Quality следует поставить на тот же уровень важности, что и модульное тестирование при разработке программного обеспечения.

Команда VK Cloud Solutions развивает собственные Big-Data-решения. Будем признательны, если вы их протестируете и дадите обратную связь. Для тестирования пользователям при регистрации начисляем 3000 бонусных рублей.

Что еще почитать:

• Архитектура реальной системы машинного обучения
  
• Data Quality: новые правила
  
• Что делать с дрейфом данных и концепций в продакшен-системах машинного обучения