Что такое контроль качества
Контроль качества данных представляет собой комплекс методов и инструментов, направленных на поддержание точности, полноты, согласованности и актуальности информации, используемой в организационных процессах. Управление качеством данных — это непрерывный процесс, обеспечивающий соблюдение установленных стандартов на всех этапах их жизненного цикла, от первоначального сбора до хранения и дальнейшего использования. Высокий уровень качества данных критически важен для успешного функционирования любой организации.
Arenadata Catalog понимает, что только достоверные и полные данные обеспечивают точный анализ и, следовательно, помогают принимать надёжные бизнес-решения. Возможности контроля качества данных в ADC можно условно разделить на пять взаимодополняющих направлений, формирующих надёжный и всесторонний фундамент для управления данными на протяжении всего их жизненного цикла.
No-code-проверки
Самый простой способ обеспечить качество данных в форматах СУБД — использовать встроенные no-code-тесты (коробочные). Этот метод доступен для специалистов без глубоких технических знаний и подходит для предприятий, внедряющих self-service-подходы. Коробочные no-code-тесты охватывают различные проверки таблиц баз данных, включая:
- проверку количества строк на конкретное значение или в заданном диапазоне;
- проверку количества столбцов на соответствие заданным значениям или диапазонам;
- проверку наличия столбцов с определёнными наименованиями;
- проверку уникальности и непустоты значений столбцов;
- проверку соответствия значений регулярным выражениям или наборам;
- проверки длины, максимума, минимума, медианы, среднего, суммы и стандартного отклонения значений столбца;
- и другие виды тестов.
No-code-проверки запускаются прямо из интерфейса ADC и не требуют специальных знаний для настройки. Их можно запускать как по расписанию, так и по необходимости.
SQL-проверки
Более гибким и функциональным способом проверки данных являются тесты, написанные на известном языке SQL. Для каждого теста можно выбрать стратегию проверки: Rows — проверка содержимого строк или Count — проверка количества строк таблицы. SQL-проверки удобны для качественного контроля данных в табличной форме.
Python-проверки
Дополнительно пользователи могут расширять набор предустановленных тестов, создавая пользовательские проверки на Python. Такие тесты доступны в общей библиотеке тестов для всех пользователей.
Low-code-модуль Arenadata Catalog DQF
Самым гибким способом проверки качества данных является модуль Arenadata Catalog DQF (Arenadata Catalog Data Quality Framework, ADС.DQF), который значительно расширяет возможности первых трёх методов. Этот модуль поддерживает архитектурную стратегию PUSH-up и проверяет данные не только на уровне СУБД, но и в бизнес-логике приложений и на фронтенде. Модуль позволяет:
- создавать сложные настраиваемые проверки как для массивов, так и для отдельных записей;
- выявлять ошибки в реальном времени, обнаруживая противоречия между историческими и новыми данными (при доступе DQF к хранилищу исторических данных);
- проводить межсистемные сверки данных между разными источниками через HTTP, SOAP, GraphQL, gRPC, JDBC (синхронно и асинхронно);
- обеспечивать постоянный мониторинг качества через автоматическую оценку полноты, достоверности и непротиворечивости данных;
- выполнять потоковые проверки в режиме Firewall.
Использование ADС.DQF даёт возможность создавать проверки по индивидуальным правилам с консолидацией результатов и формированием инцидентов качества. Проверки можно создавать как через интерфейс, так и в low-code-режиме для продвинутых пользователей.
API-интеграция с внешними системами контроля качества (DQ)
Arenadata Catalog интегрируется с внешними системами контроля качества данных через API. При использовании сторонних приложений результаты проверок автоматически передаются и сохраняются в ADC.
Пользователю Arenadata Catalog не нужно ограничиваться одним способом проверки — все пять перечисленных методов можно использовать одновременно, выбирая наилучшие инструменты в зависимости от опыта, целей и специфики бизнес-правил. Все проверки единообразно описываются в бизнес-глоссарии и визуализируются на светофоре качества данных ADC. Доступны количественные показатели по пройденным тестам: успешные, прерванные и неудачные — а также гибкие фильтры и поиск по статусам и названиям тестов. Тесты можно объединять в логические группы для удобства мониторинга и анализа.
Новые возможности в релизе 0.8.5
С версии 0.8.5 Arenadata Catalog позволяет сохранять детализированные результаты тестов качества данных. Пользователь может сохранять результаты проверок в историческом хранилище для анализа ошибок, выгружать данные в формате CSV и других для дальнейшего анализа, а также передавать их в Jira для создания задач на исправление ошибок.
При настройке проверки можно выбрать, какие данные экспортировать — успешно прошедшие тесты или неуспешные. Результаты отправляются в Apache Kafka, откуда пользователи сами извлекают данные с помощью подходящего ПО. Эта функциональность входит в стандартный пакет обновлений для ADC и Arenadata Catalog DQF.
Пример № 1
Рассмотрим таблицу orders в СУБД Greenplum, содержащую данные о заказах и клиентах. Метаданные таблицы были отсканированы при подключении сервиса Greenplum и отображены в интерфейсе ADC.
Пользователю необходимо контролировать структуру таблицы по расписанию — проверять количество и наименования столбцов. Для этого использовались коробочные проверки:
- наличие столбца с определённым наименованием;
- соответствие количества столбцов заданному значению.
Тесты объединены в логический набор для удобства управления. Определён ответственный за управление таблицей orders. При выявлении проблем с данными пользователи смогут быстро определить, кто отвечает за этот объект, и обратиться к нему.
Дополнительно тестам был назначен владелец, в чьей зоне ответственности находится управление таблицей orders. В случае возникновения проблем с данными, хранящимися в данной таблице, пользователи, являющиеся потребителями этих данных, смогут чётко и быстро идентифицировать, в чьей зоне ответственности находится данный объект, и обратиться к нему.
Пользователи могут «подписываться» на объекты, чтобы получать уведомления по результатам тестов качества данных. В личном кабинете доступна история запусков тестов и их статусы. Можно настроить оповещения по типу объекта, событию, каналу отправки и получателям — например, при статусе «Ошибка» теста.
Однако эти уведомления служат прежде всего для информирования о запуске тестов и инцидентах. Новая функциональность сохранения результатов позволяет проводить детальный анализ строк, прошедших тесты как успешно, так и с ошибками.
Для сохранения результатов настраиваются проверки определённых типов, например: длина значения, соответствие диапазону, вход в набор / исключение из набора, ненулевые и уникальные значения, регулярные выражения и др. Также доступен пользовательский SQL-тест стратегии ROWS.
В интерфейсе ADC для каждого теста задаётся, сколько строк сохранять успешно прошедших и не прошедших проверку, — до 10 000 строк по каждому параметру.
Для каждой проверки качества данных в Apache Kafka посылается сигнальное сообщение, информирующее о начале выполнения проверки. Доступны промежуточные сообщения в процессе проверки, а также конечное сигнальное сообщение, информирующее об окончании проверки.
В Kafka присутствуют топики: для сигнальных сообщений, для записей, прошедших проверку, для записей, не прошедших проверку. Каждая проверка качества данных включает в себя один тест качества данных к столбцу таблицы баз данных. Если тест качества данных завершился со статусом «Ошибка», в соответствующих топиках будет сохранена информация о записях, прошедших проверку, если таковые имеются, и о записях, не прошедших проверку качества данных.
В случае возникновения ошибки обработки данных базовая функциональность Arenadata Catalog DQF отправит сигнальное сообщение типа TASK_FINISHED в сигнальный топик и не сохранит промежуточные результаты. Если используется Arenadata Catalog DQF, то строки будут сложены в топик для результатов, для которых исполнение проверки прервано.
Ниже представлен пример сигнального сообщения типа TASK_CREATED, пришедший со стороны Arenadata Catalog DQF:
testCaseRunId: 25e7885c-a926-4432-9dac-45b3315a3e09
signalType: TASK_CREATED
{
"dataType": "UNSTRUCTURED",
"dqPlatform": "DQF",
"config": {
"StorageSaver": {
"success": 5,
"failed": 10000,
"exception": -1,
"filesCount": 100500
}
}
}
Или сигнальное сообщение этого же типа от ADC DQ:
{
"signalType": "TASK_CREATED",
"testCaseRunId": "78251f6f-bbea-4fad-92b7-5200645c1521",
"dataType": "table",
"dqPlatform": "ADC",
"testSuiteId": "886d8403-122f-4698-b3b8-574dfdbd4d6b",
"testSuiteFQN": "\"Test-PG.sensors.pxf.humidity.testSuite\"",
"testCaseId": "d65ebf0c-6e95-46f4-a978-671e2918c657",
"testCaseFQN": "Test-PG.sensors.pxf.humidity.sensor_id.фыыфвфв",
"testCaseRunTimestamp": 1761300554,
"testCaseEntityFQN": "Test-PG.sensors.pxf.humidity.sensor_id"
}
Для Arenadata Catalog Data Quality Framework сохранение результатов возможно по любой проверке, так как данные фиксируются в неструктурированном формате. В случае использования ADС.DQF результаты пройденных тестов сохраняются в структурированном виде.
Независимо от того, применяется ли базовая функциональность ADС.DQF или интегрированный с ним Data Quality Framework, процесс записи результатов тестов качества данных остаётся единым и унифицированным.
Это позволяет пользователям проводить детальный анализ как успешно пройденных, так и неудачных проверок, а также исследовать данные, вызвавшие ошибки обработки. При этом возможность выбора организацией места хранения результатов обеспечивает гибкое и индивидуальное удовлетворение потребностей в контроле качества данных.
Пример № 2
Рассмотрим пример с таблицей CRM, содержащей персональные данные клиентов. Эти данные используются таблицей Orders, в которой хранятся сведения о сформированных заказах, их составе, статусе и клиентах. Для корректного оформления заказов крайне важно, чтобы информация о клиентах была полной и достоверной.
Для таблицы CRM была настроена проверка качества данных с использованием пользовательского SQL-теста. Цель — убедиться, что такие столбцы, как пол клиента, дата рождения и сведения об ИНН, заполнены значениями. Пороговое значение по умолчанию установлено на уровне 0. Для каждого параметра задан объём сохраняемых строк — 5000.
Проверка качества данных прошла успешно: сохранены строки, соответствующие установленным критериям.
В Kafka доступна информация по строкам, успешно прошедшим проверку качества данных. Пример типового сообщения выглядит так:
testCaseRunId: 25e7885c-a926-4432-9dac-45b3315a3e09
{
"columns": [
{
"name": "CustomerID",
"dataType": "INT"
},
{
"name": "name",
"dataType": "varchar(200)"
},
{
"name": "gender",
"dataType": "varchar(200)"
},
{
"name": "birthdate",
"dataType": "text"
},
{
"name": "inn",
"dataType": "text"
}
],
"records": [
[8, "Коля", "мужчина", "11.12.1987", "123456789012"],
[9, "Николь", "Ж", "12.11.1997", "123456789013"]
]
}
Роль Arenadata Catalog
Кроме управления качеством, Arenadata Catalog служит централизованным хранилищем метаданных об информационных активах организации. С помощью ADC можно не только просматривать данные, но и описывать их, закреплять зоны ответственности, связывать с концептуальной моделью и обозначать на бизнес-глоссарии. Пять перечисленных методов тестирования охватывают широкий спектр сценариев контроля данных.
Новая функциональность сохранения детализированных результатов органично дополняет существующий функционал и удовлетворяет потребность в глубоком анализе и проработке результатов тестов — как положительных, так и отрицательных — для обеспечения соответствия индивидуальным стандартам качества каждой организации.
В будущих релизах планируется расширение данного функционала: появится готовый модуль для переноса подробных результатов из Kafka в S3-совместимые хранилища.