Использование кастомизированных компонент в средствах интеграции для контроля ошибок данных

DWH, DATAMART  Использование Категория:  DWH, DATAMART ETL, ИНТЕГРАЦИЯ ДАННЫХ
Опубликовал:         19.05.2019        К списку статей        print

Требования к качеству данных являются неотъемлемой частью Data Governance. Мастер данные (Master Data System, MDS) должны быть обязательным разделом, опорой корпоративного хранилища данных. Метаданные также можно и нужно хранить в MDS, активно используя для прикладных решений. Управлять качеством данных следует на всем их жизненном цикле, начиная от зарождения до продажи / вывода из эксплуатации. Особенно в момент появления данных к ним стоит применять строгие правила проверки и далее контролировать потоки и трансформации данных.
Но бывают сценарии, когда на источники данных (особенно внешние) или архивные данные трудно или невозможно влиять. В таких случаях тем более надлежит осуществлять мониторинг качества данных (желательно в автоматическом режиме).
В ETL-проектах разработчики включают (не всегда!) механизмы, которые перехватывают критические ошибки и настраивают процедуры автоматической рассылки уведомлений по электронной почте. Однако эти сообщения специфичны, ориентированы, как правило, на технических специалистов и только тех из них, кто помнит изначальный контекст.


А что если:

  • • систематизировать работу по мониторингу данных,
  • • сделать интеграционные процессы настраиваемыми, гибкими,
  • • сообщения об инцидентах в данных - структурированными, информативными, понятными как бизнес-пользователям, так и IT-специалистам,
  • • вовлечь в ответственность за качество данных заинтересованных людей из бизнеса и IT ?


Примоленный Роман Современные средства интеграции данных представляют достаточно широкий набор компонент, которые можно использовать в процессе извлечения, преобразования данных, улучшения качества данных.
Однако в связи с повсеместным использованием современных технологий – Интернета, web-сервисов, облачных решений, различных сервисов по обмену информацией перед нами возникают все новые и новые вызовы и требуются новые, гибкие подходы в реализации решения задач. Конечно, все современные средства интеграции, как правило, имеют встроенные скриптовые языки программирования, которые позволяют реализовать нестандартные решения и имеют практически неограниченные возможности.


Тем не менее, скриптовые компоненты обладают рядом недостатков:

  1. Проигрывают в производительности по сравнению со стандартным набором компонентов;
  2. Трудности использования, так как не все участники процесса обладают необходимыми знаниями и навыками использования;
  3. Сложности переноса логики между различными пакетами, рабочими потоками данных. Различие в метаданных требует вмешательства разработчика и доработку существующего кода;
  4. Отсутствие удобного интерфейса редактирования компонента.


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


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


Для этой цели мною был разработан компонент Microsoft SQL Server Integration Services, который обеспечивает рассылку оповещений по email с читабельным примером ошибочных данных и настраиваемым текстом сообщений. Компонент интегрирован с Microsoft SQL Server Master Data Services (MDS), что позволяет гибко использовать возможности службы мастер данных и ETL-решений на платформе компании Microsoft.
По сути, компонент перехватывает существующий поток данных, выделяет из него ограниченный набор записей (либо все записи в зависимости от настройки), формирует сообщение для отправки по почте и оповещает соответствующих бизнес-пользователей о проблеме.


После установки компонент доступен на вкладке Data Flow, при разработке пакета SSIS в среде Visual Studio:



Настройка и использование компоненты SendError

По умолчанию, компонента использует следующие сущности MDS:

  • _error_list – реестр отслеживаемых ошибок;
  • _tables_registry – перечень таблиц в хранилище данных;
  • _error_log – отдельная таблица логгирования ошибок.


Следует пояснить структуру справочника _error_list:
code – уникальный код записи в справочнике _error_list;
error_category – категория ошибки; ссылочное поле на справочник _error_category;
error_description – содержательное описание ошибки;
error_in_table – таблица хранилища данных, для которой осуществляется мониторинг ошибки; ссылочное поле на справочник _tables_registry, в поле emails_list_for_notification которого перечислены через запятую адреса электронной почты сотрудников / заинтересованных лиц, ответственных за качество данных;
error_in_external_table – внешняя таблица по отношению к хранилищу данных (источник данных), для которой осуществляется мониторинг ошибки; ссылочное поле на справочник _tables_external_registry;
error_message_subject – тема email-сообщения об ошибке;
error_message_header – заголовок содержания email-сообщения об ошибке, это может быть HTML-текст;
error_message_body – тело, содержание email-сообщения об ошибке, это может быть HTML-текст;
error_message_summary – резюмирующая часть email-сообщения об ошибке, это может быть HTML-текст;
error_business_severity – уровень серьезности влияния ошибки на бизнес-процессы;
business_impact – описание влияния ошибки на бизнес-процессы;
error_severity – технический уровень серьезности ошибки;
error_system_code – системный код ошибки, технический код ошибки ETL-процесса;
sql_code – пример sql-запроса, посредством которого можно выявить, обнаружить, воспроизвести ошибку в данных; полезно, удобно зафиксировать проверочные запросы для повторного использования, для [совместного] "разбора полетов";
error_check_disabled – проверка ошибки выключена (=1) из автоматического процесса.

Пример MDS-справочников приведен в Excel-файле в конце данной статьи.



На вход компоненты необходимо подать набор записей, которые отфильтрованы по условию ошибки. Можно использовать компоненту в общем потоке данных пакета, либо создать отдельный Data Flow для предварительных проверок.


При настройке необходимо выбрать Connection Manager для SMTP сервера и для SQL сервера, где хранятся указанные выше таблицы модели данных. В списке _tables_registry содержатся все таблицы базы данных, у которых есть хотя бы одна запись с описанием ошибки в _error_list и которые требуют дополнительной обработки.

Поля “toAddress”, “Subject”, “Body” подгружаются из соответствующих атрибутов _error_list справочника MDS. Поле Body содержит HTML-текст, который является составным из полей “error_message_header”, “error_message_body”, “error_message_summary” справочника MDS.
Также “Body” может содержать переменную {ErrorTable}, которая замещается таблицей из набора записей и выбранных полей потока данных DataFlow. Поле “toAddress” содержит [emails_list_for_notification] из справочника _tables_registry MDS.

Поле “Subject” заполняется из поля [error_message_subject] из справочника _error_list. Значения справочников извлекаются из базы в момент настройки компоненты, а также динамически подхватываются во время работы dtsx-пакета.


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

Поле “Rows to send” определяет максимальное количество строк, которые берутся в обработку.

“Send on first” – определяет количество строк, после которого сработает либо отправка email либо запись в лог и при этом будет приостановлено выполнение пакета с выдачей сообщения об ошибке. Данный функционал можно использовать для обработки критических ошибок, после которых дальнейшее выполнение пакета не имеет смысла.

“Keep mail param” – позволяет переопределить поля “toAddress”, “Subject”, “Body”, при этом значения, введенные в форме настройки компоненты, сохраняются и перекрывают значения из MDS-справочника _error_list. Флажок можно использовать для отправки служебных сообщений либо для отладки пакета.

“ccAddress, bccAddress” – поля, которые отсутствуют в _error_list, но которыми можно пользоваться для служебных целей.

“Send Mail” – отправлять только по почте

“Save to log” – писать только в лог-таблицу _error_log

“Both” – отправлять уведомления по эл.почте и писать в лог

Также в MDS-справочнике _error_list есть поле [error_check_disabled], которое если включить, то приостанавливается (выключается) отправка сообщений об ошибке.




Пример сообщения о выявленной ошибке в данных, направляемого ответственным, заинтересованным бизнес-пользователям по email:



Вопросы по статье и предложения можете присылать на email: roman_primolenny@mail.ru.



Энергия идеи   dvbi.ru                    Последнее изменение: 2021-12-13 05:55:12Z         Возрастная аудитория: 14-70         Комментариев:  0
Теги:   Примеры
Пожалуйста, проголосуйте и ниже поставьте лайк:   rating


  Комментарии



Следующая статья:    Модель зрелости Системы Управления Знаниями
Предыдущая статья:  Обеспечение качества данных и информационных систем
К списку статей