От проверок в Excel к Data Quality Monitor: как работает система контроля качества данных в RUDATA?

Особенно чувствительны к таким проблемам рыночные котировки, процентные ставки, валютные курсы, макроэкономические индикаторы, индексы и справочная информация по финансовым инструментам.

При работе с этими показателями контроль должен быть:

● воспроизводимым;

● формализованным;

● детализированным;

● исторически отслеживаемым;

● пригодным для последующей аналитики.

Именно эту задачу решает разработанный на VBA (Visual Basic for Applications) Data Quality Monitor.

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

Что именно контролирует Data Quality Monitor?

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

Для каждого архива выполняется несколько независимых групп проверок:

● полнота;

● своевременность;

● уникальность;

● диапазоны и количество наблюдений;

● специальные контрольные правила;

● итоговая классификация запуска.

В результате формируются два уровня отчетности:

● Отчет QualityReport отвечает на вопрос: «Что именно произошло в текущем запуске?»

● Отчет AuditLog отвечает на вопрос: «Как менялось качество данных от запуска к запуску?»

Разделение этих двух уровней позволяет одновременно контролировать текущее состояние данных и отслеживать его изменения во времени.

Далее разберем ключевые группы проверок более подробно.

1. Контроль полноты

Первая группа проверок отвечает на один из базовых вопросов качества данных: «Есть ли в записи все обязательные значения?»

Для архивных данных определен набор обязательных полей, например:

● RequestedCode – идентификатор инструмента в базе данных;

● time – время сделки/котировки по инструменту;

● last – цена последней сделки;

● tradeSite – идентификатор торговой площадки/источника и т.д.

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

Если обязательный заголовок отсутствует вообще, формируется ошибка:

FAIL – Не найден обязательный заголовок.

Если заголовок существует, но конкретная запись не заполнена, выводится иное сообщение:

FAIL – Обязательное поле не заполнено.

Это принципиально отличается от ручной проверки данных в Excel.

Аналитик или оператор уже не должен самостоятельно искать пустые значения в данных. Контрольное правило делает это автоматически и фиксирует результат в структурированном виде.

Например:

Такая запись одновременно служит диагностикой проблемы и источником данных для последующего анализа качества.

2. Контроль своевременности

Для данных финансового сектора важна не только полнота, но и своевременность поступления.

В системе сравниваются:

● дата наблюдения;

● дата загрузки в базу данных.

Разница между ними рассчитывается в днях.

Если данные были загружены более чем через день после соответствующей даты наблюдения, система формирует предупреждение WARN.

Таким образом, мониторинг позволяет отличать две разные ситуации:

FAIL – данные отсутствуют или нарушено критическое контрольное условие.

WARN – данные присутствуют, но существует потенциальная проблема качества, например, задержка загрузки.

Это важно для контроля данных в RUDATA: не каждое отклонение одинаково критично.

3. Контроль уникальности

Следующая группа правил ищет среди данных дубли.

В данном случае ключ формируется из компонентов: дата запрашиваемых данных + идентификатор финансового инструмента в базе.

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

FAIL – Найден дубликат.

Данные могут поступать повторно из-за дополнительной выгрузки, повторной загрузки файла или ошибки ETL-процесса.

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

4. Контроль ожидаемого количества архивных значений

Для каждого архива данных существует индивидуальный порог.

Например, для архивов валютных курсов центральных банков:

● Банка Англии – 25;

● Европейского центрального банка – 29 и т.д.

Эти значения отражают специфику конкретного источника. Система группирует данные по календарному дню и считает количество валют. Если фактическое количество оказывается меньше ожидаемого, то в отчет фиксируется статус FAIL.

Именно такие проверки наиболее ценны для финансовых данных: иногда все отдельные записи выглядят корректно, однако объем наблюдений за день значительно меньше исторической нормы.

5. Контроль структуры данных хранилища

Data Quality Monitor также проверяет наличие обязательных заголовков. Это кажется простой проверкой, но на практике она критична для исторических архивов данных. Если внешний источник изменил:

● название поля;

● структуру выгрузки;

● порядок данных;

● формат файла.

Обычный расчет может продолжить работать, но выдавать неправильный результат. Data Quality Monitor в таком случае должен остановить дальнейшую обработку или сформировать FAIL.

Например:

Это фактически контроль стабильности интерфейса между источником данных и Excel-моделью.

PASS, WARN и FAIL как единый язык контроля

Одна из сильных сторон архитектуры Data Quality Monitor – унификация результатов. Каждое правило возвращает один из трех статусов:

● PASS – контроль пройден;

● WARN – есть потенциальное отклонение;

● FAIL – ошибка/нарушение.

Такой подход позволяет использовать результаты не только в Excel, но и в BI.

QualityReport: детальный уровень контроля

Отчет QualityReport является детальным журналом текущего запуска. Каждая проблема записывается отдельной строкой:

● RunId: идентификатор запуска;

● Sheet: архив;

● Check: тип проверки;

● Row: номер строки;

● Status: PASS/WARN/FAIL;

● Field: поле;

● Value: фактическое значение;

● Message: описание проблемы.

Это превращает результаты VBA-проверок в нормализованный набор данных.

Журнал аудита AuditLog: история качества данных

AuditLog уже не хранит каждую проблему, а фиксирует результат запуска в целом.

В журнал записываются:

● номер запуска;

● время запуска;

● пользователь;

● период проверки;

● количество сообщений FAIL;

● количество сообщений WARN;

● итоговый статус.

Например:

Именно здесь VBA-процедура превращается из запущенной проверки в систему наблюдения за качеством. QualityReport показывает актуальное состояние данных, а AuditLog позволяет анализировать тренд.

Например, вопрос: «Почему сегодня качество данных хуже?» можно исследовать с помощью QualityReport.

Однако другая проблема: «Становится ли процесс загрузки данных надежнее за последние три месяца?» уже требует истории журнала AuditLog.

Поэтому журнал AuditLog следует рассматривать не как технический лог VBA, а как операционную «историю качества данных».

Пользовательская форма как интерфейс контроля

Пользовательская форма служит интерфейсом для запуска проверки:

● пользователь выбирает дату начала периода контроля;

● выбирает дату окончания;

● запускает проверку;

● получает сообщение о завершении.И далее наблюдает результаты проверки:

В результате ключевые преимущества Data Quality Monitor можно свести к следующим:

● автоматизация контроля;

● единый формат результатов проверок;

● воспроизводимость;

● раннее выявление проблем.

Хотите лично протестировать возможности RUDATA и проверить качество наших данных? Оставьте заявку на тестовый доступ на нашем официальном сайте. Специалисты RUDATA ответят на возникшие вопросы и помогут подобрать данные и сервисы под ваши задачи.