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

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

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

Photo sabirСабир Асадуллаев более 25 лет работает в информационных технологиях. Является специалистом в области проектирования хранилищ данных и ведения корпоративных метаданных. Руководил ИТ проектами в нефтегазовой отрасли, в банковской сфере, на транспорте, в науке и других областях в Европе и в Северной Америке. Обладает опытом организации коллективной разработки программного обеспечения и создания офиса управления проектами (PMO). Работая в IBM c 2006г, подготовил ряд ключевых архитектурных решений для крупнейших клиентов IBM. Окончил физический факультет МГУ (1979), кандидат физ-мат. наук (1986), сертифицированный руководитель проектов (2001), лучший архитектор CEMAAS IBM (2006), сертифицированный архитектор корпоративных решений IBM (2008), исполнительный архитектор (2010). Автор более 30 публикаций в ИТ, астрономии и биологии.



08.12.2010

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление качеством в жизненном цикле метаданных

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

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

Рис. 1. Расширенный жизненный цикл ведения метаданных.
Рис. 1. Треугольник взаимных связей между данными, метаданными и НСИ.

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

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

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

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

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

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

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

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

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

Посмотреть в увеличенном варианте.

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

При отсутствии своевременных обновлений данные могут быть полными, точными, непротиворечивыми, но устаревшими.

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

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

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

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

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

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

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

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

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

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

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

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

Посмотреть в увеличенном варианте.

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

Руководитель проекта, ответственный за управление процессом обработки изменений, с помощью 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 является необходимым инструментом для обеспечения качества данных, но не всегда достаточным, так как в ряде случаев необходимы дополнительные средства для качественного ведения НСИ. Более подробно вопросы обеспечения качества НСИ будут рассмотрены в следующих статьях.

Заключение

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

Литература

1 Redman T.C. “Data: An Unfolding Quality Disaster”. Information Management Magazine, August 2004. http://www.information-management.com/issues/20040801/1007211-1.html

2 Wang, R., Kon, H. & Madnick, S. “Data Quality Requirements Analysis and Modeling”, Ninth International Conference of Data Engineering, 1993, Vienna, Austria.

3 Hackathorn R. “Data Warehousing Energizes Your Enterprise,” Datamation, Feb.1, 1995, p. 39.

4 Dijkstra E.W. “Why is software so expensive?'”, in "Selected Writings on Computing: A Personal Perspective", Springer-Verlag, 1982, pp. 338-348

5 DeMarco Т. “The Deadline: A Novel About Project Management”, Dorset House Publishing Company, Incorporated, 1997 (Русский перевод: Том ДеМарко. “Deadline. Роман об управлении проектами”. Изд-во «Вершина», 2008)

6 Асадуллаев С. “Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных”, 09.07.2009. http://www.ibm.com/developerworks/ru/library/r-nci/index.html

7 Асадуллаев С. “Управление метаданными средствами IBM Information Server”, 30.09.2008. http://www.ibm.com/developerworks/ru/library/sabir/meta/index.html

8 8. Асадуллаев С. “Пошаговое внедрение средств управления метаданными IBM Information Server”, 21.09.2009, http://www.ibm.com/developerworks/ru/library/sabir/Information_Server/index.html

9 Giovinazzo W. “BI: Only as Good as its Data Quality”, Information Management Special Reports, August 18, 2009. http://www.information-management.com/specialreports/2009_157/business_intelligence_bi_data_quality_governance_decision_making-10015888-1.html

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=599367
ArticleTitle=Управление качеством данных с помощью IBM Information Server
publish-date=12082010