Управление качеством данных с помощью IBM Information Server

Сабир Асадуллаев, исполнительный архитектор решений SWG IBM EE/A

08.12.2010 http://www. ibm. com/developerworks/ru/library/sabir/inf_s/index. html

Резюме

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

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

Введение

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

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

Некоторые исследователи выделяют до 200 характеристик качества данных [2], поэтому отсутствие точных критериев качества также препятствует развертыванию работ по повышению качества данных.

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

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

Суммируя, можно сказать, что для достижения требуемого качества данных необходимо создание адекватной инфраструктуры и организация соответствующих мероприятий. То есть, заказчику передаются не «качественные данные в коробке» (аналог – бутылка питьевой воды), а процессы, средства и методы их получения (аналог – водопровод).

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

Метаданные и успех проекта

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

В связи с этим был проведена проверка на непротиворечивость входных и выходных форм и алгоритмов обработки данных. Каково же было наше удивление, когда мы обнаружили, что одни и те же данные имеют разные названия во входных и выходных формах. Это «открытие» вынудило изменить архитектуру разрабатываемой системы (вынести все наименования в сначала в отдельный файл, а затем и в отдельную таблицу базы данных), и перепроверить разработанные алгоритмы обработки данных. И действительно, разные названия одних и тех же данных привели к разному пониманию их смысла и к разным алгоритмам их обработки.

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

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

Парадокс метаданных и НСИ

Необходимость ведения метаданных подчеркивалась уже в самых ранних публикациях по хранилищам данных [3]. При этом ведение нормативно-справочной информации (НСИ) как составная часть процесса создания ХД не рассматривалось до недавнего времени.

Парадоксально, но ведение НСИ было вполне удовлетворительным, тогда как ведение метаданных попросту игнорировалось. Возможно, парадокс объясняется тем, что ХД, как правило, реализуются на основе реляционных баз данных, где третья нормальная форма автоматически приводит к необходимости управления НСИ. Отсутствие на рынке готовых инструментов также приводило к тому, что компании испытывали затруднения при внедрении корпоративных средств ведения метаданных.

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

Влияние метаданных на качество данных

Много лет тому назад, читая Дейкстру, я встретил его утверждение: «Я знаю одну весьма успешную фирму, в которой заведено правило, согласно которому для проекта, рассчитанного на один год, запрещено начинать кодировать ранее, чем к началу девятого месяца! В этой организации знают, что окончательный код – не более чем залог вашего понимания» [4]. В тот момент я никак не мог понять, чем можно заниматься восемь месяцев, не

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

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

Одно из лучших, на мой взгляд, определений, что такое спецификация разрабатываемой системы, дано в книге [5]: «Спецификация — это описание того, как система — некий набор запланированных реакций — отвечает на события, которые происходят непосредственно за ее пределами». Это определение показывает, насколько тесно связаны метаданные и спецификация системы. В свою очередь, существуют тесные взаимосвязи между метаданными, данными и НСИ [6]. Это дает основания утверждать, что чем лучше проработаны метаданные, тем выше качество спецификации системы и, при определенных обстоятельствах, тем выше качество данных.

Качество данных и этапы проекта

Качество данных должно обеспечиваться на всех этапах постановки задачи, разработки,

реализации и эксплуатации информационной системы.

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

Разработка ИТ системы связана с наименованием сущностей (например, имена таблиц и названия столбцов в базе данных) и выявлением связей между ними, программированием алгоритмов обработки данных в соответствии с бизнес-правилами. То есть, насколько справедливо утверждение, что технические метаданные появляются на этапе разработки системы, настолько же верно, что разработка системы – это определение технических метаданных.

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

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

Управление качеством в жизненном цикле метаданных Расширенный жизненный цикл ведения метаданных [7] состоит из следующих этапов: анализ и понимание, моделирование, разработка, преобразование, публикация,

потребление, отчетность и аудит, управление, управление качеством, владение (Рис.1).

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

Анализ и понимание

Отчетность и аудит

Управление

Моделирование

Потребление

Управление качеством

Разработка

Владение

Публикация

Преобразование

Рис.1. Расширенный жизненный цикл ведения метаданных

Потоки работ и обеспечение качества

На первый взгляд, роль этапа «Управление качеством» ничем не примечательна. Однако, если воспользоваться описанием ролей [7, 8] и построить таблицу 1, которая показывает содержание работ каждой роли на каждом этапе жизненного цикла ведения метаданных, то видно, что вся совокупность проектных работ разделяется на два потока.

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

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

Рассмотрим поток работ по повышению качества данных более детально. На практике обычно говорят о четырех показателях качества данных: полнота данных, точность, непротиворечивость и актуальность [9].

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

Точность данных означает, что представленные значения не содержат ошибок: номер паспорта, или срок кредита, или дата вылета.

Таблица 2. Потоки работ и обеспечение качества

Руководитель

проекта

Подпись:

Бизнес аналитик

Подпись: Бизнес аналитик

Эксперт

предметной области

Подпись:

Аналитик

данных

Подпись: Аналитик данных

ИТ разработчик

Подпись: ИТ разработчик

Стюард

Подпись: Стюард

Бизнес

пользователи

Подпись:Анализ и понимание

Картирование потоков данных Исходная классификация

Бизнес классификация

Анализ систем

Моделирование Логическая и физическая

модели

Разработка Логика обработки и

преобразования

Преобразование Задания на преобразование

Публикация Размещение сервисов

Публикация метаданных

Потребление Доступ на чтение

Отчетность и аудит Управление качеством

Анализ воздействия изменений

Выявление противоречий метаданных

Обновление бизнес классификации

Устранение противоречий метаданных

Управление ресурсами данных

Подготовка отчетов Поддержка единого смысла данных

Выявление рассогласований

Управление Назначение стюардов

Владение Определение права доступа

83

Непротиворечивость тесно связана с метаданными и влияет на понимание данных. Это могут быть даты в разных форматах, или такое понятие как «прибыль», которое в разных странах исчисляется по разному.

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

Изменения требований, неизбежно связанные с развитием ИТ системы, могут привести,

как всякие перемены, к результату, противоположному желаемому.

Полнота данных может пострадать из-за неточной постановки задачи.

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

Непротиворечивость может быть ухудшена вследствие подключения новой системы с иным пониманием данных (метаданных).

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

Поэтому ИТ — специалисты, ответственные за управление изменениями, например, руководитель проекта, должны анализировать воздействие изменений на информационную среду.

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

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

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

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

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

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

Роли, взаимодействия и инструменты управление качеством

На Рис.2 представлена схема взаимодействия между ролями и используемые инструменты из работы [8]. Работы, связанные с повышением качества данных, обсуждавшиеся в предыдущем разделе, выделены цветом.

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

Руко

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

Непротиворечивость может быть ухудшена вследствие подключения новой системы с иным пониманием данных (метаданных).

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

Поэтому ИТ — специалисты, ответственные за управление изменениями, например, руководитель проекта, должны анализировать воздействие изменений на информационную среду.

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

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

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

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

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

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

Роли, взаимодействия и инструменты управление качеством

На Рис.2 представлена схема взаимодействия между ролями и используемые инструменты из работы [8]. Работы, связанные с повышением качества данных, обсуждавшиеся в предыдущем разделе, выделены цветом.

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

Руководитель проекта, ответственный за управление процессом обработки изменений, с помощью Metadata Workbench анализирует воздействие изменений на информационную среду.

Бизнес-аналитик выявляет противоречия между глоссарием и столбцами базы данных, и оповещает авторов метаданных с помощью функционала Business Glossary и FastTrack. Инструменты анализа, встроенные в QualityStage, помогают бизнес-аналитику достичь полной видимости действительного состояния данных.

Эксперт предметной области (автор метаданных) использует Business Glossary для обновления бизнес — классификации (таксономии), которая поддерживает иерархическую структуру терминов. Термин представляет собой слово или фразу, которая может быть использована для классификации и группирования объектов в репозитории метаданных. В случае необходимости совместной работы экспертов, Business Glossary предоставляет экспертам предметной области средства коллективной работы для аннотирования определений данных, редактирования описаний и их категоризации.

Аналитик данных устраняет выявленные бизнес-аналитиком противоречия между глоссарием и таблицами и столбцами баз данных с помощью Business Glossary и Rational Data Architect

Metadata Workbench предоставляет ИТ – разработчикам средства просмотра, анализа, проектирования и обогащения метаданных для управления и понимания информационных активов, созданных и доступных посредством IBM Information Server

Бизнес — пользователи, ответственные за соблюдение законодательных требований, имеют возможность отслеживать происхождение данных с помощью соответствующих инструментов Metadata Workbench.

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

Необходимость и достаточность инструментария

Как следует из выполненного анализа, семейство продуктов IBM Information Server предоставляет всем участникам проекта необходимый инструментарий обеспечения качества данных.

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

1. Стадия исследования производится с целью полного понимания информации.

2. Стадия стандартизации переформатирует данные из разных систем, приводя их к необходимому содержанию и формату.

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

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

Таким образом семейство продуктов IBM Information Server является необходимым инструментом для обеспечения качества данных, но не всегда достаточным, так как в ряде случаев необходимы дополнительные средства для качественного ведения НСИ. Более подробно вопросы обеспечения качества НСИ будут рассмотрены в следующих статьях.

Заключение

Обеспечев ИТ карьеру в качестве программиста банковских задач в ВЦ Внешторгбанка, в дальнейшем руководил проектами в нефтегазовой отрасли, в банковской сфере, на транспорте, в науке и других областях в Европе и в Северной Америке. Обладает опытом организации коллективной разработки программного обеспечения и создания офиса управления проектами (PMO). Работая в IBM c 2006г,

подготовил ряд ключевых архитектурных решений по интеграции данных (хранилища), интеграции доступа (порталы) и интеграции приложений (сервис — ориентированная архитектура) для крупнейших клиентов IBM. Окончил физический факультет МГУ (1979), кандидат физ-мат. наук (1986), сертифицированный руководитель проектов (2001), лучший архитектор CEMAAS IBM (2006), сертифицированный архитектор корпоративных решений IBM (2008), исполнительный архитектор, OpenGroup Distinguished Architect (2010). Автор более 30 публикаций в ИТ, астрономии и биологии.

Блог Сабира Асадуллаева:

https://www. ibm. com/developerworks/mydeveloperworks/blogs/Sabir/

Материал взят из: Архитектуры хранилищ данных Стратегия создания хранилищ данных Управление метаданными и НСИ — Сборник статей