Инженерный подход к качеству данных в data lake

Что такое качество данных? Это что-то абсолютное или относительное для каждой задачи? В чём измерять качество данных?

Качество имеет несколько определений: — обладание определённым свойством (схоже с «характеристикой»); — стандарт чего-то, сравнимый с другими объектами того же типа, степень отличия.

Для разных ролей, вовлечённых в процесс разработки и использования аналитических платформ, важны разные определения качества: 1. Для data scientists важно, чтобы данные обладали свойством описать исследуемый феномен для разработки предсказывающей или классифицирующей модели; в такой постановке задач важны атрибуты с высокой информационной ценностью, и, например, абсолютная полнота данных уже не так важна. 2. Для software/data engineers важно второе определение, оно обеспечивает знание о том что данные «не стали хуже» во время загрузки и обработки в платформе; также для инженеров важна гранулярная измеримость качества, возможность рассуждать о качестве отдельной записи, партиции, датасета, чтобы информировать о плохом качестве как можно раньше.

Будучи инженером и архитектором хранилищ данных и data lake, в этой заметке я изложу свой подход к инженерной стороне качества данных.

Архитектурный концепт data lake

Ключевое свойство класса решений на data lake — это использование подхода schema-on-read: мы принимаем и храним все данные, и рассуждаем об их структуре только в момент чтения для конкретной задачи. Для реализации schema-on-read чаще всего используют следующую архитектуру, в очень общем виде:

1.Слой базовых или сырых данных: данные доставляются сюда в таком виде, в каком их выдал источник, например, если источник передаёт CSV-файл, то в слое сырых данных этот файл будет лежать в формате CSV.

2.Слой структурированных или курированных (curated) данных: в этом слое к данным применяют структуру, которую выяснили/предположили/согласовали инженеры, в нашем примере с CSV-файлом мы создадим его копию в формате Avro, и эта копия будет хранится в слое структурированных данных.

3.Слой дата продуктов/витрин/аналитических датасетов: в этом слое хранятся данные, преобразованные для решения конкретной бизнес-задачи, говоря языком разработчиков ПО, «здесь появляется бизнес-логика»; возвращаясь к нашему примеру, файл Avro является списком взаимодействий клиентов, и дата продуктом могут быть датасеты в формате ORC, представляющий граф взаимодействий клиентов.

Это очень абстрактный архитектурный концепт, он явно не описывает различные пограничные случаи, например, когда данные от источника сразу поступают в структурированном виде (Avro выгрузка из Apache Kafka) или работу с бинарными данными, но детальный разбор этого концепта лежит за рамками данной заметки, он служит нам для иллюстрации проблем и задач, связанных с качеством данных.

Качество на входе, качество на выходе

Разделим задачи качества на две части:

1. Техническое качество данных

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

С точки зрения основных задач аналитической платформы, техническое качество — это качество на входе, то есть до того как мы начали интегрировать и агрегировать данные соотнося их с бизнес-логикой. В применении к реляционным СУБД это будет означать, что данные соответствуют определениям типов колонок в таблицах и правилам ссылочной целостности (PK, FK).

Такое качество считается и контролируется без знания предметной области, всё, что нам нужно знать — это какая схема нужна для конкретного датасета, причём, так как это data lake, нам подойдет даже обоснованное (на примере тех данных что мы уже собрали) предположение – сырые данные у нас остаются, и в худшем случае нам нужно будет пересчитать какие-то результаты.

2. Бизнес-качество данных

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

Примеры: — у нас есть клиенты и договора обслуживания, у нас может быть правило, что у клиента всегда есть как минимум один договор обслуживания; — у клиента должен быть определенный статус для определённых видов продуктов; — клиент должен существовать в нашем клиентском каталоге (задача интеграции данных); — и многие другие.

Я привожу примеры из бизнес-процессов, и по аналогии мы называем такие условия достоверности бизнес-правилами. Таким образом, бизнес качество данных – это соответствие данных заданному множеству бизнес-правил. С точки зрения создателей data lake бизнес качество данных — это качество на выходе.

Контроль и управление качеством данных в data lake

Предлагаю вашему вниманию следующий подход к контролю и управлению качеством данных:

В слое сырых данных

Согласно принципу schema-on-read мы не форсируем свою схему при записи в data lake (хотя мы, конечно, не откажемся от структурированных данных сразу от источника). Поэтому в слое сырых данных мы можем сделать только следующие проверки: 1. Базовая проверка по формату: нужное количество разделителей в CSV, наличие схемы в Avro или Parquet. 2. Сверка с техническими метаданными, если такие поставляет источник: проверка контрольных сумм, числа строк, и прочее.

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

В слое структурированных данных

Напомню, что согласно общей концепции мы берём данные из сырого слоя, парсим их, и кладём версию с навязанной схемой в слой структурированных данных. В момент парсинга могут возникнуть атрибуты или целые записи, которые не могут быть распарсены: атрибут не соответствует типу, в строке недостаточное количество колонок/разделителей и так далее. Наша задача – выделить такие атрибуты и записи, и указать, почему они не прошли проверку.

К счастью, такая задача легко автоматизируема. Чаще всего один источник оперирует каким-то одним/двумя форматами для выгрузок, и нам достаточно реализовать логику парсинга этих форматов, управляемую параметрами или метаданными джоба. По моему опыту, в любом крупном data lake нужен парсер CSV, JSON и XML.

Пример такого джоба можно посмотреть тут. Он принимает на вход JSON-файл со схемой, разбирает CSV-датасет и формирует два результата: основной, куда попадают строчки, которые удалось привести к нужным типам, и INVALID, куда попадают строки, непрошедшие парсинг, с указанием на колонку и атрибут, которые не удалось привести к заданному типу.

Как реагировать на появление записей, которые не удалось структурировать? Это проектный вопрос, который решается в каждом конкретном случае: – для каких-то источников появление таких строк может быть признаком того, что наша логика парсинга устарела, и источник провёл изменения – тогда нам нужно обновить нашу схему и повторить парсинг (повторная выгрузка не требуется); – для других источников это может быть ошибка на стороне источника, и нам потребуется провести вторую выгрузку через сырой и структурированный слой.

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

В слое дата-продуктов

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

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

Проще всего думать о каждом бизнес-правиле, как об отчёте, он может быть агрегированным (количество клиентов Х не удовлетворяют бизнес правилу М), может быть детальным (все клиенты, которые не удовлетворяют правилу М), партицированным (все клиенты в партиции О, которые не удовлетворяют правилу М) или накопленным итогом.

Критерии успеха правил бизнес качества: они прозрачны для специалистов в предметной области, ими затребованы (или согласованы), и адресуют существующую проблему (помните о потреблении ресурсов на каждый тест качества данных).

Чаще всего отчёты о бизнес-качестве собраны в отдельную витрину/проект и подключены к системе отображения отчётности, а также чаще всего материализованы, чтобы была возможность сопоставить их с версиями до правок в логике (часто в слое дата-продуктов данные могут перезаписываться).

Итог

В этой заметке вы ознакомились с классификацией требований по качеству данных для инженеров, работающих с data lake, и подходом к их реализации: – техническое качество данных рассматривается как соответствие схеме/формату и реализуется в процессе структурирования данных; – бизнес-качество данных рассматривается как соответствие бизнес-правилам и реализуется как система отчетов в процессе создания дата-продуктов.