Data warehouse architectures and development strategy guidebook (rus) by Sabir Asadullaev

Сборник статей

Архитектуры хранилищ данных Стратегия создания хранилищ данных Управление метаданными и НСИ Сабир Асадуллаев исполнительный архитектор SWG IBM EE/A Distinguished IT Architect, Open Group

Содержание АРХИТЕКТУРЫ ХРАНИЛИЩ ДАННЫХ - I .....................................................................................................5 РЕЗЮМЕ ....................................................................................................................................................................5 OLAP И OLTP..........................................................................................................................................................5 ШЕСТЬ УРОВНЕЙ АРХИТЕКТУР ХРАНИЛИЩА ДАННЫХ ............................................................................................6 ВИРТУАЛЬНЫЕ ХРАНИЛИЩА ДАННЫХ .....................................................................................................................9 НЕЗАВИСИМЫЕ ВИТРИНЫ ДАННЫХ ........................................................................................................................10 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................12 ЛИТЕРАТУРА ...........................................................................................................................................................12 ОБ АВТОРЕ ..............................................................................................................................................................12 АРХИТЕКТУРЫ ХРАНИЛИЩ ДАННЫХ - II..................................................................................................13 РЕЗЮМЕ ..................................................................................................................................................................13 ЦЕНТРАЛИЗОВАННОЕ ХРАНИЛИЩЕ ДАННЫХ С ETL ..............................................................................................13 ЦЕНТРАЛИЗОВАННОЕ ХРАНИЛИЩЕ ДАННЫХ С ELT ..............................................................................................15 ЦЕНТРАЛИЗОВАННОЕ ХД С ОCД ...........................................................................................................................17 РАСШИРЕННАЯ МОДЕЛЬ ХД С ВИТРИНАМИ ДАННЫХ ............................................................................................18 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................20 ЛИТЕРАТУРА ...........................................................................................................................................................20 ОБ АВТОРЕ ..............................................................................................................................................................20 АРХИТЕКТУРЫ ХРАНИЛИЩ ДАННЫХ - III ................................................................................................21 РЕЗЮМЕ ..................................................................................................................................................................21 ЦЕНТРАЛИЗОВАННАЯ ETL С ПАРАЛЛЕЛЬНЫМИ ХРАНИЛИЩАМИ И ВИТРИНАМИ ДАННЫХ ...................................21 ХРАНИЛИЩЕ С НАКОПЛЕНИЕМ ДАННЫХ В ВИТРИНАХ...........................................................................................22 ХРАНИЛИЩЕ ДАННЫХ С ИНТЕГРАЦИОННОЙ ШИНОЙ .............................................................................................24 РЕКОМЕНДОВАННАЯ АРХИТЕКТУРА КХД..............................................................................................................26 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................27 ЛИТЕРАТУРА ...........................................................................................................................................................28 ОБ АВТОРЕ ..............................................................................................................................................................28 ДАННЫЕ, МЕТАДАННЫЕ И НСИ: ТРОЙНАЯ СТРАТЕГИЯ СОЗДАНИЯ ХРАНИЛИЩ ДАННЫХ29 РЕЗЮМЕ ..................................................................................................................................................................29 ВВЕДЕНИЕ...............................................................................................................................................................29 ВЕДЕНИЕ НСИ........................................................................................................................................................30 ВЕДЕНИЕ МЕТАДАННЫХ .........................................................................................................................................30 СВЯЗЬ МЕЖДУ ДАННЫМИ, НСИ И МЕТАДАННЫМИ ...............................................................................................31 СОСТАВ КОРПОРАТИВНОГО ХРАНИЛИЩА ДАННЫХ ...............................................................................................35 ПРИМЕР РЕАЛИЗАЦИИ СУЩЕСТВУЮЩИХ ПОДХОДОВ ............................................................................................36 ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ ТРОЙНОЙ СТРАТЕГИИ .............................................................................................37 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................39 ЛИТЕРАТУРА ...........................................................................................................................................................40 ОБ АВТОРЕ ..............................................................................................................................................................40 УПРАВЛЕНИЕ МЕТАДАННЫМИ СРЕДСТВАМИ IBM INFORMATION SERVER ..............................41 РЕЗЮМЕ ..................................................................................................................................................................41 ТИПЫ МЕТАДАННЫХ ..............................................................................................................................................41 КРИТЕРИИ УСПЕХА ПРОЕКТА ВЕДЕНИЯ МЕТАДАННЫХ ..........................................................................................41 ЖИЗНЕННЫЙ ЦИКЛ ВЕДЕНИЯ МЕТАДАННЫХ .........................................................................................................42 ИНСТРУМЕНТЫ ВЕДЕНИЯ МЕТАДАННЫХ IBM INFORMATION SERVER ..................................................................44 РОЛИ В ПРОЕКТНОЙ КОМАНДЕ ВЕДЕНИЯ МЕТАДАННЫХ ........................................................................................45 ПОДДЕРЖКА РОЛЕЙ ИНСТРУМЕНТАМИ IBM INFORMATION SERVER .....................................................................46 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................49 ГЛОССАРИЙ ............................................................................................................................................................50 ОБ АВТОРЕ ..............................................................................................................................................................50 ПОШАГОВОЕ ВНЕДРЕНИЕ СРЕДСТВ УПРАВЛЕНИЯ МЕТАДАННЫМИ IBM INFORMATION SERVER.....................................................................................................................................................................51 РЕЗЮМЕ ..................................................................................................................................................................51

ОПИСАНИЕ СЦЕНАРИЯ ............................................................................................................................................51 ТЕКУЩАЯ ЛОГИЧЕСКАЯ ТОПОЛОГИЯ .....................................................................................................................51 АРХИТЕКТУРА СИСТЕМЫ УПРАВЛЕНИЯ МЕТАДАННЫМИ .......................................................................................52 АРХИТЕКТУРА СРЕДЫ УПРАВЛЕНИЯ МЕТАДАННЫМИ ............................................................................................54 АРХИТЕКТУРА РЕПОЗИТОРИЯ МЕТАДАННЫХ .........................................................................................................54 ЦЕЛЕВАЯ ЛОГИЧЕСКАЯ ТОПОЛОГИЯ ......................................................................................................................55 ДВЕ ФАЗЫ РАСШИРЕННОГО ЖИЗНЕННОГО ЦИКЛА МЕТАДАННЫХ..........................................................................57 ФАЗА «ПРОЕКТИРОВАНИЕ МЕТАДАННЫХ»............................................................................................................57 ФАЗА «ПРОИЗВОДСТВО МЕТАДАННЫХ» ................................................................................................................59 РОЛИ И ВЗАИМОДЕЙСТВИЯ НА ФАЗЕ ПРОЕКТИРОВАНИЯ МЕТАДАННЫХ ................................................................59 РОЛИ И ВЗАИМОДЕЙСТВИЯ НА ФАЗЕ ПРОИЗВОДСТВА МЕТАДАННЫХ ....................................................................62 ПУТЬ ВНЕДРЕНИЯ – 1. ПРОЕКТИРОВАНИЕ..............................................................................................................64 ПУТЬ ВНЕДРЕНИЯ – 2. ПРОИЗВОДСТВО. .................................................................................................................66 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................68 ЛИТЕРАТУРА ...........................................................................................................................................................68 ОБ АВТОРЕ ..............................................................................................................................................................68 ВЕДЕНИЕ НСИ НА ПРАКТИЧЕСКИХ ПРИМЕРАХ.....................................................................................69 РЕЗЮМЕ ..................................................................................................................................................................69 ОСНОВНЫЕ ПОНЯТИЯ И ТЕРМИНОЛОГИЯ ...............................................................................................................69 НСИ И МАСТЕР – ДАННЫЕ......................................................................................................................................70 ОБЩИЕ НЕДОСТАТКИ ТРАДИЦИОННОГО ВЕДЕНИЯ НСИ И МД..............................................................................71 ТЕХНОЛОГИЧЕСКИЕ НЕДОСТАТКИ ВЕДЕНИЯ НСИ И МД.......................................................................................72 ПРИМЕРЫ ПРОБЛЕМ ТРАДИЦИОННОГО ВЕДЕНИЯ НСИ И МД................................................................................74 ПРЕИМУЩЕСТВА КОРПОРАТИВНОГО ВЕДЕНИЯ НСИ И МД...................................................................................75 АРХИТЕКТУРНЫЕ ПРИНЦИПЫ СИСТЕМЫ ВЕДЕНИЯ НСИ И МД .............................................................................76 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................78 ЛИТЕРАТУРА ...........................................................................................................................................................78 ОБ АВТОРАХ............................................................................................................................................................78 УПРАВЛЕНИЕ КАЧЕСТВОМ ДАННЫХ С ПОМОЩЬЮ IBM INFORMATION SERVER....................79 РЕЗЮМЕ ..................................................................................................................................................................79 ВВЕДЕНИЕ...............................................................................................................................................................79 МЕТАДАННЫЕ И УСПЕХ ПРОЕКТА ..........................................................................................................................80 ПАРАДОКС МЕТАДАННЫХ И НСИ ..........................................................................................................................80 ВЛИЯНИЕ МЕТАДАННЫХ НА КАЧЕСТВО ДАННЫХ ..................................................................................................80 КАЧЕСТВО ДАННЫХ И ЭТАПЫ ПРОЕКТА .................................................................................................................81 УПРАВЛЕНИЕ КАЧЕСТВОМ В ЖИЗНЕННОМ ЦИКЛЕ МЕТАДАННЫХ ..........................................................................81 ПОТОКИ РАБОТ И ОБЕСПЕЧЕНИЕ КАЧЕСТВА ...........................................................................................................82 РОЛИ, ВЗАИМОДЕЙСТВИЯ И ИНСТРУМЕНТЫ УПРАВЛЕНИЕ КАЧЕСТВОМ ................................................................84 НЕОБХОДИМОСТЬ И ДОСТАТОЧНОСТЬ ИНСТРУМЕНТАРИЯ .....................................................................................86 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................87 ЛИТЕРАТУРА ...........................................................................................................................................................87 ОБ АВТОРЕ ..............................................................................................................................................................87 СИСТЕМА СБОРА И АНАЛИЗА ПЕРВИЧНЫХ ДАННЫХ - I ....................................................................89 РЕЗЮМЕ ..................................................................................................................................................................89 ТРЕБОВАНИЯ К СИСТЕМЕ ........................................................................................................................................90 ЗАДАЧИ ПРОЕКТА ...................................................................................................................................................91 АРХИТЕКТУРЫ СИСТЕМЫ СБОРА, ХРАНЕНИЯ И АНАЛИЗА ДАННЫХ .......................................................................93 СБОР ДАННЫХ.........................................................................................................................................................95 ХРАНЕНИЕ ДАННЫХ ...............................................................................................................................................96 ЗАКЛЮЧЕНИЕ..........................................................................................................................................................98 ЛИТЕРАТУРА ...........................................................................................................................................................98 ОБ АВТОРЕ ..............................................................................................................................................................98 СИСТЕМА СБОРА И АНАЛИЗА ПЕРВИЧНЫХ ДАННЫХ - II...................................................................99 РЕЗЮМЕ ..................................................................................................................................................................99 АНАЛИЗ ДАННЫХ СРЕДСТВАМИ IBM INFOSPHERE WAREHOUSE ...........................................................................99 АНАЛИЗ ДАННЫХ СРЕДСТВАМИ IBM COGNOS BUSINESS INTELLIGENCE ............................................................104 КОРПОРАТИВНОЕ ПЛАНИРОВАНИЕ С ПОМОЩЬЮ COGNOS TM1..........................................................................108 ЗАКЛЮЧЕНИЕ........................................................................................................................................................109 ГЛОССАРИЙ ..........................................................................................................................................................109

ЛИТЕРАТУРА .........................................................................................................................................................109 ОБ АВТОРЕ ............................................................................................................................................................109 ХРАНИЛИЩА ДАННЫХ: ТРОЙНАЯ СТРАТЕГИЯ НА ПРАКТИКЕ .....................................................110 РЕЗЮМЕ ................................................................................................................................................................110 ВВЕДЕНИЕ.............................................................................................................................................................110 АРХИТЕКТУРА СИСТЕМЫ СБОРА И АНАЛИЗА ПЕРВИЧНЫХ ДАННЫХ ....................................................................111 МЕСТО ПРОЕКТОВ ВЕДЕНИЯ МЕТАДАННЫХ И НСИ.............................................................................................113 РЕКОМЕНДОВАННАЯ АРХИТЕКТУРА КХД............................................................................................................114 СВЯЗЬ АРХИТЕКТУРЫ РЕШЕНИЯ С РЕКОМЕНДОВАННОЙ АРХИТЕКТУРОЙ ............................................................115 СРАВНЕНИЕ ПРЕДЛАГАЕМОГО И СУЩЕСТВУЮЩИХ ПОДХОДОВ ..........................................................................117 ИТОГОВАЯ АРХИТЕКТУРА РЕАЛИЗАЦИИ СУЩЕСТВУЮЩИХ ПОДХОДОВ ..............................................................118 ТРОЙНАЯ СТРАТЕГИЯ И ПЛАНИРОВАНИЕ СОЗДАНИЯ КХД ..................................................................................119 ЗАКЛЮЧЕНИЕ........................................................................................................................................................122 ЛИТЕРАТУРА .........................................................................................................................................................122 ОБ АВТОРЕ ............................................................................................................................................................123

Архитектуры хранилищ данных - I Сабир Асадуллаев, архитектор решений SWG IBM EE/A 19.10.2009 http://www.ibm.com/developerworks/ru/library/sabir/axd_1/index.html

Резюме Эта работа открывает цикл из трех статей, посвященных архитектурам хранилищ данных (ХД) и их предшественников. Обилие различных подходов, методов и рекомендаций приводят к некоторой путанице понятий, достоинств, недостатков и границ применимости тех или иных архитектурных решений. В первой статье рассмотрены эволюция понимания места OLAP, компоненты архитектуры ХД, виртуальные ХД и независимые витрины данных. В двух следующих публикациях будут рассмотрены централизованное ХД с системой извлечения, преобразования и загрузки данных (ETL), хранилище данных с системой извлечения, загрузки и преобразования данных (ELT), ЦХД с оперативным складом данных (ОCД), расширенная модель с витринами данных (ВД), хранилище с накоплением данных в ВД, централизованная ETL с параллельными ХД и ВД, а также рекомендованная архитектура хранилища данных

OLAP и OLTP Любая транзакционная система, как правило, содержит два типа таблиц. Один из них отвечает за быстрые транзакции. Например, при продаже билетов необходимо обеспечить работу большого числа кассиров, которые обмениваются с системой короткими сообщениями. Действительно, вводимая и распечатываемая информация, касающаяся фамилии пассажира, даты вылета, рейса, места, пункта назначения, может быть оценена в 1000 байт. Таким образом, для обслуживания пассажиров необходима быстрая обработка коротких записей. Другой тип таблиц содержит итоговые данные о продажах за указанный срок, по направлениям, по категориям пассажиров. Эти таблицы используются аналитиками и финансовыми специалистами раз в месяц, или в конце года, когда необходимо подвести итоги деятельности компании. И если количество аналитиков в десятки раз меньше числа кассиров, то объемы данных, необходимых для анализа, превышают размер средней транзакции на несколько порядков величины. Естественно, что во время выполнения аналитических работ время отклика системы на запрос о наличии билета увеличивается. Создание систем с резервом вычислительной мощности может сгладить негативное воздействие аналитической нагрузки на транзакционную активность, но приводит к значительному удорожанию комплекса, при том, что избыточная мощность большую часть времени остается невостребованной. Вторым фактором, приведшим к разделению аналитических и транзакционных систем, являются разные требования, которые предъявляют аналитические и транзакционные системы к вычислительным комплексам. История OLAP начинается в 1993, когда была опубликована статья [1] «Обеспечение OLAP (оперативной аналитической обработки) для пользователей - аналитиков». Первоначально казалось, что разделения транзакционных и аналитических систем (OLTP – OLAP) вполне достаточно. Однако вскоре выяснилось, что OLAP – системы очень плохо справляются с ролью посредника между различными транзакционными системами - источниками данных и клиентскими приложениями. Стало ясно, что необходима среда хранения аналитических данных. И поначалу на эту роль претендовали единые базы данных, в которые предлагалось копировать исходную информацию из источников данных. Эта идея оказалась не вполне жизнеспособной, 5

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

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

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

Еще забавнее многослойные витрины данных при наличии единого хранилища. Почему нельзя построить новую витрину поверх хранилища? Видите ли, пользователям захотелось объединить некоторые данные из двух витрин в третью. Это, может быть, имело бы смысл, если бы в витринах содержалась информация, которой нет в хранилище, например, если бы пользователи обогащали витрину своими расчетами и данными. Даже если так, то какова ценность этих обогащенных данных по сравнению с теми, что прошли через сито очистки в соответствии с корпоративными правилами? Кто отвечает за качество этих данных? Как они появились в системе? Никто не знает, но всем хочется получить доступ к информации, которой нет в хранилище. Хранилища данных чем-то похожи на системы очистки воды. Вода собирается из разных источников с различным химическим составом. Поэтому в каждом конкретном случае применяются свои методы очистки и обеззараживания воды. Вода, отвечающая строгим стандартам качества, поступает к потребителям. И как бы мы ни жаловались на качество воды, именно такой подход предотвращает распространение эпидемий в большом городе. И никому не приходит в голову (я очень на это надеюсь) очищенную воду обогащать водой из ближайшей лужи. Но в ИТ свои законы. В дальнейшем будут рассмотрены различные архитектуры хранилищ данных, кроме совсем экзотичных вариантов. Мы будем рассматривать архитектуры корпоративного хранилища данных на шести уровнях, так как, несмотря на то, что сами компоненты могут отсутствовать, уровни в том или ином виде сохраняются.

Рис.2. Шесть уровней архитектуры хранилища данных Первый уровень представлен источниками данных, в качестве которых выступают транзакционные и унаследованные системы, архивы, разрозненные файлы известных форматов, документы MS Office, а также любые иные источники структурированных данных. 7

На втором уровне размещается система извлечения, преобразования и загрузки данных (ETL - Extract, Transformation and Load). Основная задача ETL – извлечь данные из разных систем, привести их к согласованному виду и загрузить в хранилище. Программноаппаратный комплекс, на котором реализована система ETL, должен обладать значительной пропускной способностью. Но еще важнее для него – это высокая вычислительная производительность. Поэтому лучшие из систем ETL способны обеспечивать высокую степень параллелизма вычислений, и даже работать с кластерами и вычислительными гридами. Роль следующего уровня – надежное, защищенное от несанкционированного доступа, хранение данных. В соответствии с предлагаемой тройной стратегией [2], мы полагаем, что на этом уровне должны размещаться также системы ведения метаданных и нормативно-справочной информации (НСИ). Оперативный склад данных (Operational Data Store) необходим тогда, когда требуется как можно более оперативный доступ к пусть неполным, не до конца согласованным данным, доступным с наименьшей возможной задержкой. Зоны временного хранения (Staging area) нужны для реализации специфического бизнес – процесса, например, когда перед загрузкой данных контролер данных должен просмотреть их и дать разрешение на их загрузку в хранилище. Иногда зонами временного хранения называют буферные базы данных, необходимые для выполнения внутренних технологических операций, например, ETL выбирает данные из источника, записывает их во внутреннюю БД, обрабатывает и предает в хранилище. В данной работе под зонами временного хранения понимаются области хранения данных, предназначенные для выполнения операций внешними пользователями или системами в соответствии с бизнес требованиями обработки данных. Выделение зон временного хранения в отдельный компонент ХД необходим, так как для этих зон требуется создание дополнительных средств администрирования, мониторинга, обеспечения безопасности и аудита. Информационные системы на уровне распределения данных все еще не имеют общепринятого названия. Они могут называться просто ETL, так же, как и система извлечения, преобразования и загрузки данных на втором уровне. Или, чтобы подчеркнуть отличия от ETL, их иногда называют ETL-2. При этом системы уровня распределения данных выполняют задачи, значительно отличающиеся от задач ETL, а именно, выборку реструктуризацию и доставку данных (SRD – Sample, Restructure, Deliver) ETL извлекает данные из множества внешних систем. SRD выполняет выборку из единого хранилища данных. ETL получает несогласованные данные, которые надо преобразовать к единому формату. SRD имеет дело с очищенными данными, структуры которых должны быть приведены в соответствие с требованиями различных приложений. ETL загружает данные в центральное хранилище. SRD должно доставить данные в различные витрины в соответствии с правами доступа, графиком доставки и требованиями к составу информации. Уровень предоставления данных предназначен для разделения функций хранения и функций обслуживания различных задач. Витрины данных должны имеет структуры данных, максимально отвечающие потребностям обслуживаемых задач. Поскольку не существует универсальных структур данных, оптимальных для любой задачи, витрины данных следует группировать по территориальным, тематическим, организационным, прикладным, функциональным и иным признакам. Уровень бизнес-приложений представлен сценарными расчетами и статистическим анализом, многомерным анализом, средствами планирования и подготовки отчетности. Естественно, что список бизнес-приложений этим не исчерпывается. 8

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

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

Появился новый источник данных? Все замечательно. Мы перепишем все наши программы с учетом особенностей этого источника. Изменился формат данных? Прекрасно. Мы перепишем все наши программы с учетом нового формата. Все хорошо, все при деле, надо расширять отдел программирования. Да, еще пользователи систем-источников данных жалуются, что с некоторых пор их системы очень медленно работают по той причине, что при каждом, даже повторном запросе наше универсальное клиентское приложение снова и снова обращается к источнику данных. Поэтому надо приобрести новые, более мощные серверы. Где сокращение расходов? Его нет. Наоборот, расходы только растут. Нужно больше разработчиков, больше серверов, больше электричества, больше площадей под серверные помещения. Может, все же есть выгода от такой архитектуры? Мы получили жесткую связь между источниками данных и аналитическими приложениями. Любое изменение в источнике данных должно согласовываться с разработчиками универсального клиента с тем, чтобы избежать передачи искаженных и неверно интерпретируемых данных в аналитические программы. На каждом рабочем месте необходимо поддерживать набор интерфейсов доступа к различным системам – источникам. Иногда говорят, что все это очевидно и не стоит тратить время на разъяснение того, что и так всем понятно. Но почему эти же разработчики на запрос пользователя «Мне нужны данные из витрин А, Б и В» пишут клиентское приложение, которое обращается к сразу к нескольким витринам, вновь и вновь воспроизводя умершую архитектуру виртуального хранилища данных?

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

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

•

Длина записей в OLTP обычно не превышает 1000 символов. Аналитический запрос может потребовать мегабайты данных за одно обращение для анализа.

•

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

•

Характерными требованиями для транзакционных систем является круглосуточная бесперебойная работа 365 дней в году (24 х 365). Аналитическая обработка не выдвигает столь четко сформулированных требований к готовности аналитических комплексов, но не подготовленная в срок отчетность может привести к серьезным неприятностям, как для аналитиков, так и для предприятия.

•

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

•

Транзакционная обработка осуществляется, в основном над текущими данными. Аналитические вычисления производятся над историческими данными. 10

•

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

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

Рис.4. Независимые витрины данных Значит, нужен единый репозиторий – хранилище данных. Но информация в витринах не согласована. Каждая витрина унаследовала от транзакционной системы свою 11

терминологию, свою модель данных, свою нормативно-справочную информацию, в том числе, кодировку данных. Например, в одной системе дата выполнения операции может быть закодирована в российском формате ДД.ММ.ГГГГ (день, месяц, год), а в другой в американском формате ММ.ДД. ГГГГ (месяц, день, год). Значит, при слиянии данных необходимо понимать, что означает дата 06.05.2009 – это 5 июня, или 6 мая. Итак, нам нужна система извлечения, преобразования и загрузки данных. Таким образом, все преимущества независимых витрин данных исчезают при первом же требовании пользователей работать с данными из нескольких витрин.

Заключение В статье рассмотрены эволюция понимания места OLAP, компоненты архитектуры ХД, виртуальные ХД и независимые витрины данных. В двух следующих публикациях будут обсуждены достоинства и ограничения следующих архитектур: централизованное ХД с системой извлечения, преобразования и загрузки данных (ETL), хранилище данных с системой извлечения, загрузки и преобразования данных (ELT), ЦХД с оперативным складом данных (ОCД), расширенная модель с витринами данных (ВД), хранилище с накоплением данных в ВД, централизованная ETL с параллельными ХД И ВД и рекомендованная архитектура хранилища данных.

Литература 1. Codd E.F., Codd S.B., and Salley C.T. "Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate". Codd & Date, Inc. 1993. 2. Асадуллаев С. "Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных". http://www.ibm.com/developerworks/ru/library/r-nci/index.html, 2009.

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

Архитектуры хранилищ данных - II Сабир Асадуллаев, архитектор решений SWG IBM EE/A 23.10.2009 http://www.ibm.com/developerworks/ru/library/sabir/axd_2/index.html

Резюме Вторая работа продолжает цикл из трех статей, посвященных архитектурам хранилищ данных (ХД) и их предшественников. Обилие различных подходов, методов и рекомендаций приводят к некоторой путанице понятий, достоинств, недостатков и границ применимости тех или иных архитектурных решений. В первой статье [1] рассмотрены эволюция понимания места OLAP, компоненты архитектуры ХД, виртуальные ХД и независимые витрины данных. Эта публикация посвящена таким архитектурам, как централизованное ХД с системой извлечения, преобразования и загрузки данных (ETL), хранилище данных с системой извлечения, загрузки и преобразования данных (ELT), ЦХД с оперативным складом данных (ОCД), расширенная модель с витринами данных (ВД). В третьей, завершающей работе будут рассмотрены хранилище с накоплением данных в ВД, централизованная ETL с параллельными ХД и ВД, ХД с интеграционной шиной, а также рекомендованная архитектура хранилища данных

Централизованное хранилище данных с ETL Виртуальные хранилища данных и независимые витрины показали, что для эффективной работы аналитических систем необходим единый репозитарий данных. Для наполнения этого репозитория необходимо извлечь, согласовать разнородные данные из различных источников и загрузить эти данные в репозиторий. Средства извлечения, преобразования и загрузки данных (ETL) должны знать все об источниках данных: структуры хранящихся данных и их форматы, различия в алгоритмах обработки данных, смысл хранящихся данных, график выполнения обработки информации в транзакционных системах. Игнорирование этих данных о данных (метаданных) неизбежно приводит к ухудшению качества информации, загружаемой в хранилище. В результате пользователи теряют доверие к хранилищу данных, стараются получать информацию напрямую из источников, что приводит к неоправданным временным затратам специалистов, эксплуатирующих системы – источники данных. Таким образом, информация об источниках данных должна использоваться средствами ETL. Поэтому средства ETL должны работать в тесной связке со средствами ведения метаданных. При обработке извлеченных данных необходимо преобразовать их к единому виду. Поскольку основные данные хранятся в реляционных базах данных, нужно учесть различие в кодировке данных. Даты могут кодироваться в разных формата; адреса могут использовать различные сокращения; кодировка продуктов может следовать различным номенклатурам. Первоначально информация о нормативно справочной информации (НСИ) заносилась в алгоритмы преобразования данных ETL. По мере роста числа источников данных объема обрабатываемых данных (он может достигать терабайтов в сутки), стало ясно, что необходимо отделить средства управления НСИ от средств ETL, и обеспечить их эффективное взаимодействие. Таким образом, средства ETL извлекают данные из источников, во взаимодействии со средствами ведения метаданных и НСИ преобразуют их к требуемым форматам и загружают в репозиторий данных. В качестве репозитория чаще всего выступает репозиторий хранилища данных, но также может быть и оперативный склад данных 13

(ОСД), и зоны временного хранения, и даже витрины данных. Поэтому одним из ключевых требований к средствам ETL является их способность взаимодействовать с различными системами.

Рис. 1. Централизованное хранилище данных с ETL

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

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

•

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

•

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

•

Средства ETL должны иметь высокую пропускную способность с тем, чтобы собирать и выгружать все возрастающие объемы данных.

•

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

•

Средства ETL должны предоставлять разнообразные инструменты извлечения данных в различных режимах работы – от пакетного сбора для систем, 14

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

Централизованное хранилище данных с ELT Традиционную систему извлечения, преобразования и загрузки данных (ETL) нередко упрекают в низкой производительности и высокой стоимости из-за необходимости создания выделенного программно-аппаратного комплекса. В качестве альтернативы предлагаются средства извлечения, загрузки и преобразования данных (ELT), которым приписываются высокая производительность и эффективное использование оборудования. С тем, чтобы понять, каковы сравнительные преимущества и недостатки систем ETL и ELT, обратимся к трем основным функциям корпоративного хранилища данных (КХД): 1. Полный и своевременный сбор и обработка информации от источников данных; 2. Надежное и защищенное хранение данных; 3. Предоставление данных для аналитических работ. На вход систем ETL / ELT поступают разнородные данные, которые необходимо сравнить, очистить, привести к единым форматам, обработать по требуемым вычислительным алгоритмам. С одной стороны, в системах ETL / ELT данные практически не задерживаются, с другой – через эти системы в хранилище втекает основной поток информации. Поэтому требования к обеспечению защиты информации могут быть умеренными.

Рис. 2. Централизованное хранилище данных с ELT

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

безопасности. Структуры данных в хранилище должны быть оптимизированы под требования долговременного, надежного и защищенного хранения. Применение схемы ELT означает, что ЦХД должно осуществлять и трансформацию данных. Предоставление данных для аналитических работ требует реорганизации структур данных под каждую специфическую задачу. Многомерный анализу необходимы кубы данных; статистический анализ, как правило, работает с рядами данных; сценарный анализ и моделирование могут использовать файлы MS Excel. В рассматриваемой архитектуре бизнес - приложения используют данные непосредственно из ЦХД. В такой архитектуре в ЦХД должны храниться данные в структурах, оптимизированных как под текущие, так и под будущие бизнес – приложения. Более того, подобный прямой доступ повышает вероятность несанкционированного доступа ко всем данным в хранилище. Таким образом, мы видим, что в данной архитектуре на ЦХД возложены функции трансформации данных и обслуживания аналитических приложений. Обе эти функции несвойственны ЦХД, которое в таком виде превращается в устройство «все в одном», в котором, как правило, составляющие компоненты хуже, чем если бы они были реализованы отдельно (например, фотоаппарат в мобильном телефоне). Как решается вопрос разделения функций хранения данных и предоставления данных для аналитических приложений, мы рассмотрим позже. Применение схемы ETL позволяет полностью разнести функции обработки и хранения данных. Схема ELT нагружает центральное хранилище данных несвойственными ей функциями преобразования данных. В результате переноса функциональности от ETL в ЦХД нам необходимо не только обеспечить ту же вычислительную производительность, но и спроектировать универсальную платформу, способную равно эффективно обрабатывать данные и хранить их. Этот подход, может быть, применим для сегмента SOHO, но для корпоративных решений требуются профессиональные устройства. Несмотря на декларируемые преимущества производительности схемы ELT, на практике выясняется, что 1. Качество данных влияет на время их загрузки. Например, ETL при очистке и преобразовании данных может отбрасывать до 90% повторяющихся данных. ELT в этом случае загрузит все данные в ЦХД, где и будет происходить очистка. 2. Скорость преобразования данных в хранилище сильно зависит от алгоритмов обработки и структур данных. В некоторых случаях более эффективна SQL – обработка внутри базы данных хранилища, в других – быстрее будут работать внешние программы, извлекающие данные для обработки и загружающие результаты обработки в хранилище. 3. Некоторые алгоритмы очень сложно реализовать, используя средства SQL. Это накладывает ограничения на использование схемы ELT, тогда как ETL может использовать более эффективные инструменты обработки данных 4. ETL является единой областью, где сконцентрированы правила извлечения, обработки и загрузки данных, что упрощает эксплуатацию, доработку и тестирование алгоритмов. ELT, напротив, разносит алгоритмы сбора и загрузки с алгоритмами преобразования данных. То есть, для тестирования новых алгоритмов преобразования нужно либо рисковать целостностью данных в хранилище, находящемся в промышленном производстве, либо создавать тестовую копию хранилища, что является весьма дорогостоящим мероприятием. Таким образом, сравнивая ETL и ELT, мы видим, что преимущества при загрузке и преобразовании данных неочевидны, что ELT сталкивается с ограничениями SQL при преобразовании данных, и что экономия на программно - аппаратном комплексе ELT 16

приводит к финансовым затратам на создание программно-аппаратной тестовой копии ЦХД. Применение ELT, возможно, оправдано, если: 1. Нет жестких требований к надежности, производительности и защищенности хранилища. 2. Бюджетные ограничения вынуждают идти на риск утраты данных. 3. Хранилище данных и источники данных взаимодействуют через сервисную шину (SOA). Последний случай наиболее экзотичен, но и он имеет право на существование в определенных условиях. В этом случае на шину возложена интеграция источников с ХД на уровне обмена сообщениями, и минимальное (по меркам хранилища) преобразование данных и их загрузка хранилище.

Централизованное ХД с ОCД Процессы извлечения, преобразования и загрузки данных, безусловно, требуют некоторого времени для завершения своей работы. Дополнительная задержка вызвана необходимостью проверки загруженных в хранилище данных на непротиворечивость с уже имеющимися данными, на консолидацию данных, на перевычисления итоговых значений с учетом новых данных. Оперативный склад данных (ОСД) был предложен в 1998 г. [2] с тем, чтобы сократить время задержки между поступлением информации из ETL и аналитическими системами. Операционный склад данных располагает менее точной информацией из-за отсутствия внутренних проверок, и более детальными данными из-за отсутствия этапа консолидации данных. Поэтому данные из ОСД предназначены для принятия тактических решений, тогда как информация из центрального хранилища данных (ЦХД) лучше подходит для решения стратегических задач [3].

Рис. 3. Централизованное ХД с ОCД

Представим себе компанию, которая занимается продажей напитков и пакетиков с орешками через торговые автоматы на территории всей страны. Простой пустого автомата в течение 15 мин. означает потерю возможной прибыли, поэтому важно своевременно отслеживать состояние автомата и заполнять его отсутствующим товаром. Сбор и обработка всей информации в масштабе всей страны может потребовать несколько часов, тогда как развоз продуктов осуществляется локально – в каждом крупном населенном пункте есть склад, откуда продукты развозятся по ближайшим торговым точкам. С другой стороны, заполнение складов осуществляется через централизованные закупки. Таким образом, есть два различных типа задач тактического (заполнение торговых автоматов) и стратегического планирования (заполнение складов). Действительно, если в результате неполных и неточных данных, содержащихся в ОСД, будет привезена лишняя бутылка воды, то это не приведет к серьезным потерям. Однако ошибка планирования из-за низкого качества данных в ЦХД может оказать негативное воздействие на принятие решения о номенклатуре и объемах оптовых закупок. Требования к защите информации в ОСД и ЦХД также различаются. В нашем примере в ОСД размещаются данные с горизонтом времени, не превышающим нескольких часов. В ЦХД может храниться историческая информация, охватывающая период в несколько лет для более надежного прогнозирования необходимых объемов закупок. И эта историческая информация может представлять значительный коммерческий интерес для конкурентов. Поэтому аналитики-тактики могут напрямую работать с ОСД, тогда как аналитикистратеги должны работать с ЦХД через витрины данных для разграничения ответственности. Отсутствие витрин данных помогает тактикам быстрее получить доступ к данным. Наличие витрин данных не препятствует стратегическому анализу, так как такой анализ осуществляется ежемесячно, или даже ежеквартально. Архитектура, представленная на Рис. 3, предполагает прямую работу бизнес-приложений с ЦХД. Разбор достоинств и ограничений подобного подхода будет выполнен в разделе «Расширенная модель ХД с витринами данных». Сейчас необходимо отметить, что при последовательном перемещении данных ОСД фактически выполняет еще одну роль зоны временного хранения. Аналитики-тактики, работая с данными из ОСД, вольно или невольно выявляют ошибки и противоречия в данных, тем самым, повышая их качество. Исправленные данные из ОСД в данной схеме перегружаются в ЦХД. Однако возможны и иные схемы, например, когда данные из ETL поступают одновременно в ОСД и ЦХД. После использования в ОСД ненужные данные просто стираются. Эта схема применима в тех случаях, когда человеческое вмешательство в данные может только исказить их, вольно, или невольно.

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

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

Рис. 4. Расширенная модель с витринами данных

Разные пользовательские приложения нуждаются в различных форматах данных: многомерные кубы, ряды данных, двумерные массивы, реляционные таблицы, файлы в формате MS Excel, текстовые файлы с разделителями, XML-файлы и т.д. Никакая структура данных в КХД не может удовлетворить этим требованиям. Выходом является создание витрин, чьи структуры данных оптимизированы под специфические требования отдельных приложений. Еще одной причиной необходимости создания витрин данных является требование к надежности КХД, которое часто определяется, как пять или четыре девятки. Это означает, что КХД может простаивать не более 5 минут в год (99,999%) или не более часа в год (99,99%). Создание комплекса с такими характеристиками является сложной и весьма недешевой инженерной задачей. Требования к защите от терактов, саботажа и стихийных бедствий еще более усложняют построение программно-технического комплекса и осуществление соответствующих организационных мероприятий. Чем сложнее такой комплекс, чем больше данных он хранит, тем выше его стоимость и сложнее его поддержка. Наличие витрин данных резко снижает нагрузку на КХД, как по количеству пользователей, так и по объему данных в хранилище, так как эти данные могут быть оптимизированы под хранение, а не под обслуживание запросов. Если витрины наполняются напрямую из КХД, то фактическое количество пользователей снижается с сотен и тысяч до десятков витрин, которые и являются пользователями КХД. 19

При использовании средств SRD (Sample, Restructure, Delivery - выборка, реструктуризация, доставка) количество пользователей сокращается до 1. В этом случае вся логика информационного снабжения витрин сосредотачивается в SRD. Витрины могут быть оптимизированы под обслуживание пользовательских запросов. Программнотехнический комплекс КХД может быть оптимизирован исключительно под надежное, защищенное хранение данных. Средства SRD также смягчают нагрузку на КХД за счет того, что разные витрины могут обращаться к одним и тем же данным, тогда как SRD извлекает данные один раз, преобразует к различным форматам и доставляет в разные витрины данных.

Заключение В статье рассмотрены такие архитектуры, как централизованное ХД с системой извлечения, преобразования и загрузки данных (ETL), хранилище данных с системой извлечения, загрузки и преобразования данных (ELT), ЦХД с оперативным складом данных (ОCД), расширенная модель с витринами данных (ВД). В завершающей работе будут обсуждены достоинства и ограничения следующих архитектур: ХД с накоплением данных в ВД, централизованная ETL с параллельными ХД и ВД, ХД с интеграционной шиной, а также рекомендованная архитектура хранилища данных.

Литература 1. Асадуллаев С. «Архитектуры хранилищ данных – http://www.ibm.com/developerworks/ru/library/sabir/axd_1/index.html

I»,

19.10.2009,

2. Inmon, W. “The Operational Data Store. Designing the Operational Data Store”. Information Management Magazine, July 1998. 3. Building the Operational Data Store on DB2 UDB Using IBM Data Replication, WebSphere MQ Family, and DB2 Warehouse Manager, SG24-6513-00, IBM Redbooks, 19 December 2001, http://www.redbooks.ibm.com/abstracts/sg246513.html?Open

Архитектуры хранилищ данных - III Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A 03.11.2009 http://www.ibm.com/developerworks/ru/library/sabir/axd_3/index.html

Резюме Третья работа завершает цикл из трех статей, посвященных архитектурам хранилищ данных (ХД) и их предшественников. Обилие различных подходов, методов и рекомендаций приводят к некоторой путанице понятий, достоинств, недостатков и границ применимости тех или иных архитектурных решений. В первой статье [1] рассмотрены эволюция понимания места OLAP, компоненты архитектуры ХД, виртуальные ХД и независимые витрины данных. Вторая публикация [2] посвящена таким архитектурам, как централизованное ХД с системой извлечения, преобразования и загрузки данных (ETL), хранилище данных с системой извлечения, загрузки и преобразования данных (ELT), ЦХД с оперативным складом данных (ОCД), расширенная модель с витринами данных (ВД). В этой статье рассмотрены хранилище с накоплением данных в ВД, централизованная ETL с параллельными ХД и ВД, ХД с интеграционной шиной, а также рекомендованная архитектура хранилища данных

Централизованная ETL с параллельными хранилищами и витринами данных В данном случае система извлечения, преобразования и загрузки данных (ETL) является центром, вокруг которого строится вся архитектура КХД. Информация из разнородных источников поступает в ETL, которая загружает очищенные и согласованные данные в центральное хранилище данных (ЦХД), в оперативный склад данных (ОСД), если он есть, и, при необходимости, в зоны временного хранения. Это обычная практика для КХД. Необычным является загрузка данных из ETL напрямую в витрины данных. На практике такая архитектура возникает из-за требований скорейшего, без временных задержек, доступа к аналитическим данным. Использование оперативного склада данных не решает задачи, так как пользователи могут находиться в другом регионе, и им требуется территориальная витрина данных. Другой причиной может стать запрет на размещение разнотипной информации в ОСД по соображениям безопасности. По тем или иным причинам, подобные архитектуры встречаются, и одной из проблем их эксплуатации являются сложности с восстановлением данных после краха витрин, напрямую снабжающихся из ETL. Дело в том, что средства ETL не предназначены для долговременного хранения извлеченных и очищенных данных. Транзакционные системы, как правило, ориентированы на выполнение текущих операций. Поэтому при потере данных в витринах, связанных с ETL, приходится либо поднимать информацию из средств резервного копирования (backup) транзакционных систем, либо организовывать исторические архивы систем - источников данных. Подобные архивы не только требуют средств на свое создание и поддержку в эксплуатации, но и являются, с корпоративной точки зрения, избыточными, так как дублируют функции корпоративного хранилища, но предназначены для ограниченного количества витрин данных. Еще одним решением является двойное подключение подобных витрин – напрямую к средствам ETL и к хранилищу данных, что приводит к недоразумениям и рассогласованиям результатов аналитических работ. Причина кроется в том, что данные, поступающие в хранилище, как правило, проходят дополнительные проверки на непротиворечивость с уже загруженными данными. Например, может прийти финансовый документ с реквизитами, почти совпадающими с документом, поступившим в ЦХД ранее. 21

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

Рис. 5. Централизованная ETL с параллельными ХД И ВД

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

Хранилище с накоплением данных в витринах Основанием для появления этой архитектуры явились следующие предпосылки. 1. Некоторые компании до сих пор внедряют и эксплуатируют разрозненные прикладные витрины данных. Качество данных в этих витринах удовлетворяет аналитиков, работающих с витринами. 2. В некоторых компаниях сложилось мнение, что создание корпоративного хранилища данных (КХД) подобно смертельному трюку с непредсказуемыми 22

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

Рис. 6. Хранилище с накоплением данных в витринах

Диагноз – пользователи независимых прикладных витрин говорят на разных языках бизнеса, и каждая витрина содержит собственные метаданные. Другая проблема заключается в различии нормативно-справочной информации (НСИ), используемых в независимых витринах данных. Разница в кодировке данных, в используемых кодификаторах, справочниках, классификаторах, идентификаторах, нормативах и словарях делает невозможным объединение этих данных без серьезного анализа, проектирования и разработки средств ведения НСИ. Однако в организации уже существуют планы, бюджет и сроки создания КХД на основе независимых витрин данных. Руководство ожидает получить результат быстро и недорого. Разработчики, обещавшие экономию ресурсов, вынуждены сделать хоть что23

нибудь. Так создаются хранилища несогласованных отчетов, что в корне противоречит самой идее создания хранилищ данных как единого и единственного источника очищенных, согласованных и непротиворечивых исторических данных. Понятно, что ни руководство, ни пользователи подобного хранилища не склонны доверять информации, содержащейся в нем. Поэтому на следующем этапе встает необходимость радикальной переработки, а по сути, создания заново, хранилища, ориентированного на хранение не отчетов, а показателей, из которых будут собираться отчеты. Эта работа невозможна без использования средств ведения метаданных и НСИ, область действия которых будет распространяться только на центральное хранилище (ЦХД), так как независимые витрины данных содержат свои метаданные и НСИ. В результате руководство и эксперты могут получить согласованные и непротиворечивые отчеты, но они не смогут проследить происхождение данных сквозным образом, так как между независимыми витринами и ЦХД есть разрыв в ведении метаданных. Таким образом, стремление к достижению сиюминутных результатов и к демонстрации быстрых успехов приводит к отказу от единого, сквозного управления метаданными и НСИ. Итогом такого подхода является наличие семантических островов, где сотрудники говорят на разных бизнес – языках. Тем не менее, эта архитектура имеет право на существование, там, где единая модель данных или не нужна, или невозможна, и где в ЦХД передается сравнительно небольшой объем данных без необходимости детализации их происхождения и исходных составляющих. Например, если компания, оперирующая в разных странах, уже внедрила национальные хранилища данных, которые следуют локальным требованиям законодательства и правилам ведения бизнеса и финансового учета. Центральное хранилище данных может забирать из национальных ХД только часть информации для корпоративной отчетности. Создавать единую модель данных нет необходимости, поскольку она не будет востребована на национальном уровне. Естественно, что такая схема требует высокой степени доверия к национальным данным, и может быть использована, если умышленное или неумышленное искажение этих данных не приведет к тяжелым финансовым последствиям для всей организации.

Хранилище данных с интеграционной шиной Широкое распространение сервис - ориентированной архитектуры (СОА) [3] привело к желанию использовать ее в решениях для корпоративных хранилищ данных (КХД) вместо средств извлечения, преобразования и загрузки данных (ETL) в центральное хранилище (ЦХД) и вместо средств выборки, реструктуризации и доставки данных (SRD) в витрины данных. Интеграционная шина, которая лежит в основе СОА, предназначена для интеграции веб сервисов и приложений и выполняет следующие задачи: •

Определяет сервис, соответствующий запросу от источника, и направляет запрос к сервису.

•

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

•

Преобразует форматы сообщений между источником запроса и сервисом.

•

Управляет бизнес - событиями различных источников.

Рис. 7. Хранилище данных с интеграционной шиной

На первый взгляд функциональные возможности СОА позволяют применить ее для замены ETL и SRD. Действительно, ETL выполняет посреднические функции между ЦХД и источниками данных, а SRD является посредником между ЦХД и витринами данных. Если заменить ETL и SRD на интеграционную шину, то, казалось бы, можно воспользоваться гибкостью, предоставляемой шиной для интеграции приложений. Представим себе, что ЦХД, оперативный склад данных (ОСД), зоны временного хранения, системы ведения метаданных и НСИ обращаются к шине как независимые приложения с запросами к источникам данных на обновление данных. Прежде всего, в разы возрастет нагрузка на системы-источники данных, так как одна и та же информация будет многократно передаваться по запросам в ЦХД, ОСД, зоны временного хранения и системы управления метаданными и НСИ. Очевидное решение – создать собственное хранилище данных при шине для кеширования запросов. Во-вторых, регламент сбора информации, ранее централизованный в ETL, теперь рассеян по приложениям, запрашивающим данных. Рано или поздно возникнут рассогласования в регламентах сбора данных для ЦХД, ОСД, систем ведения НСИ и метаданных. Данные, собранные по разным методикам, в разные отрезки времени, обработанные по разным алгоритмам, будут несогласованны друг с другом. Тем самым будет разрушена основная цель создания ЦХД как единого источника согласованных непротиворечивых данных. В случае замены SRD на интеграционную шину последствия не столь драматичны. Но для того, чтобы ЦХД могло отвечать на запросы витрин данных, направленных через шину, оно должно быть преобразовано в сервис. Это значит, что хранилище должно соответствовать наиболее распространенному стилю web – сервисов, и поддерживать протоколы HTTP/ HTTPS и SOAP и XML – формат сообщений. Такой подход работает для коротких сообщений, но в витрины необходимо передавать большой объем данных, что может быть решено с помощью передачи двоичных объектов. Необходимая реструктуризация данных не может быть возложена на шину, и должна выполняться либо в ЦХД, либо в витрине. Эта функция может быть решена с помощью сервиса-посредника, принимающего данные, и передающего их в витрины данных после реструктуризации. То есть, мы возвращаемся к идее средства SRD с шинным интерфейсом. 25

Таким образом, интеграционная шина может быть использована в архитектуре КХД как транспортная среда между источниками данных и ETL и между SRD и витринами данных в тех случаях, когда компоненты КХД территориально разнесены и находятся за межсетевыми экранами в соответствии со строгими требованиями к защите информации. В этом случае для обеспечения взаимодействия достаточно, чтобы был разрешен обмен по протоколам HTTP/ HTTPS. Вся логика сбора и преобразования информации должна быть по-прежнему сосредоточена в ETL и SRD.

Рекомендованная архитектура КХД Архитектура корпоративного хранилища данных (КХД) должна удовлетворять многим функциональным и нефункциональным требованиям, которые зависят от конкретных задач, решаемых КХД. Как нет универсального банка, авиакомпании, или нефтяного концерна, так нет и единого решения КХД, пригодного на все случаи жизни. Но основные принципы, которым должно следовать КХД, все же можно сформулировать. Прежде всего, это качество данных, которое можно понимать, как полные, точные и воспроизводимые данные, доставленные в срок туда, где они нужны. Качество данных трудно измерить напрямую, но о нем можно судить по принимаемым решениям. То есть, качество данных требует инвестиций, но и само способно приносить прибыль. Во-вторых, это защищенность и надежность хранения данных. Ценность информации, накопленной в КХД, может быть сравнима с рыночной стоимостью компании. Несанкционированный доступ к КХД чреват серьезными последствиями, поэтому должны быть приняты меры, адекватные ценности данных. В-третьих, данные должны быть доступны сотрудникам в объеме, необходимом и достаточном для выполнения своих функциональных обязанностей. В-четвертых, сотрудники должны иметь единое понимание данных, то есть должно быть установлено единое смысловое пространство. В-пятых, необходимо, по возможности, устранить конфликты в кодировках данных в системах источниках.

Рис. 8. Рекомендованная архитектура КХД

Предлагаемая архитектура следует проверенным принципам модульного конструирования «непотопляемых отсеков». Стратегия «Разделяй и властвуй» применима не только в политике. Разделяя архитектуру на модули, мы одновременно концентрируем в них определенную функциональность, получая власть над неуправляемой ИТ стихией. Средства ETL обеспечивают полный, надежный, точный сбор информации из источников данных благодаря сосредоточенной в ETL логике сбора, обработки и преобразования данных и взаимодействию с системами ведения метаданных и НСИ. Система ведения метаданных является главным «хранителем мудрости», к которому можно обратиться за советом. Система ведения метаданных поддерживает актуальность бизнес-метаданных, технических, операционных и проектных метаданных. Система ведения НСИ является третейским судьей при разрешении конфликтов кодировок данных. Центральное хранилище данных (ЦХД) несет только нагрузку по надежному защищенному хранению данных. В зависимости от поставленных задач, надежность программно-технического комплекса (ПТК) ЦХД может достигать 99,999%, то есть обеспечивать бесперебойную работу с простоем не более 5 мин в год. ПТК ЦХД может обеспечивать защиту данных от несанкционированного доступа, саботажа и стихийных бедствий. Структура данных в ЦХД оптимизирована исключительно с целью обеспечения эффективного хранения данных. Средства выборки, реструктуризации и доставки данных (SRD) в такой архитектуре являются единственным пользователем ЦХД, беря на себя всю работу по заполнению витрин данных и, тем самым, снижая нагрузку на ЦХД по обслуживанию запросов пользователей. Витрины данных содержат данные в структурах и форматах, оптимальных для решения задач пользователей данной витрины. В настоящее время, когда даже ноутбук может быть оснащен терабайтным диском, проблемы, связанные с многократным повторением данных в витринах, не имеют значения. Главное преимущество этой архитектуры – предоставление доступа для удобной работы пользователей с необходимым объемом данных, возможность быстрого восстановления содержимого витрин из ЦХД при сбое витрины, обеспечение работы пользователей при отсутствии связи с ЦХД. Достоинство этой архитектуры заключается в возможности раздельного проектирования, создания, эксплуатации и доработки отдельных компонентов без радикальной перестройки всей системы. Это означает, что начало работ по созданию КХД не требует сверхусилий или сверхинвестиций. Достаточно начать с ограниченного по своим возможностям программно-технического комплекса, и следуя предложенным принципам, создать работающий и действительно полезный для пользователей прототип. Далее необходимо выявить узкие места и развивать соответствующие компоненты. Применение этой архитектуры вместе с тройной стратегией интеграции данных, метаданных и НСИ [4], позволяет сократить сроки и бюджет проекта внедрения КХД и развивать его в соответствии с изменяющимися требованиями бизнеса.

Заключение В статье обсуждаются достоинства и ограничения следующих архитектур: ХД с накоплением данных в ВД, централизованная ETL с параллельными ХД и ВД, ХД с интеграционной шиной, а также рекомендованная архитектура хранилища данных. Рекомендованная архитектура корпоративного хранилища данных позволяет создать в короткие сроки и с минимальными инвестициями работоспособный прототип, полезный для бизнес-пользователей. Ключевым моментом этой архитектуры, обеспечивающим 27

эволюционное развитие КХД, является внедрение на ранних этапах систем ведения метаданных и НСИ.

Литература 1. Асадуллаев С. «Архитектуры хранилищ данных – I», 19.10.2009, http://www.ibm.com/developerworks/ru/library/sabir/axd_1/index.html 2. Асадуллаев С. «Архитектуры хранилищ данных – II», 23.10.2009. http://www.ibm.com/developerworks/ru/library/sabir/axd_2/index.html 3. Bieberstein N., Bose S., Fiammante M, Jones K., Shah R. “Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap”, IBM Press, 2005. (Русский перевод: Биберштейн Н., Боуз С., Фиаммант М., Джонс К., Ша Р. “Компас в мире сервисориентированной архитектуры (SOA)”. М.: КУДИЦ-ПРЕСС, 2007). 4. Асадуллаев С. «Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных», 09.07.2009, http://www.ibm.com/developerworks/ru/library/r-nci/index.html

Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A 09.07.2009 http://www.ibm.com/developerworks/ru/library/r-nci/index.html

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

Введение Крупнейшие компании России внедряют хранилища с середины 90х годов. Предыдущие проекты нельзя назвать неуспешными, так как они решали текущие задачи, в частности, обеспечить руководство компании достоверной непротиворечивой информацией хотя бы по некоторым направлениям деятельности. Однако рост компаний, изменение законодательства и возросшие требования к стратегическому анализу и планированию требуют дальнейшего развития стратегий построения хранилища данных. К этому времени в компаниях уже сформировалось понимание, что для успешного создания хранилища данных необходимо создание системы централизованного ведения НСИ и системы управления метаданными. К сожалению, эти проекты все еще рассматриваются по отдельности. Принято считать, что создание корпоративных хранилищ данных (КХД) является проектом интеграции данных из разрозненных источников. В то же время, источники содержат не только данные, но и НСИ, а также элементы метаданных. Как правило, крупные компании начинают проект построения хранилищ данных без выделения средств и ресурсов на ведение метаданных или НСИ. Спонсоры проекта, комитет управления и другие ответственные за принятие решений обычно стараются выделять средства на реализацию проекта поэтапно и склоняются к последовательному выполнению трех проектов. В итоге, бюджет проектов, сроки их исполнения и качество не соответствуют исходным требованиям из-за необходимости внесения изменений и доработок информационных систем, построенный в рамках предыдущего проекта. Причиной построения хранилищ данных в большинстве случаев являются требования бизнес - пользователей, которые более не в состоянии сводить воедино данные из различных информационных систем. То есть, именно требования бизнес - пользователей определяют, в первую очередь, информационное содержание будущего хранилища данных. Источниками данных для будущего хранилища являются транзакционные базы данных (OLTP), унаследованные системы, файловые хранилища, интранет-сайты, разрозненные локальные аналитические приложения. Прежде всего, необходимо определить, где находятся требуемые данные. Поскольку, как правило, эти данные хранятся в различных форматах, необходимо их привести к единому виду, для чего применяются довольно сложные системы извлечения, преобразования и загрузки (Extract, Transformation, Load ETL) в хранилище данных. 29

Эта работа не может быть выполнена без сопутствующего анализа метаданных и НСИ. Более того, практика внедрения хранилищ данных показала [1], что метаданные, созданные и импортированные из различных источников, фактически управляют всем процессом сбора данных.

Ведение НСИ В состав нормативно-справочной информации, которую иногда называют на западный манер мастер данными, входят словари (например, сокращений), справочники (например, телефонный справочник), классификаторы (БИК ОКПО, ОКАТО и даже ОКОК), нормативы, идентификаторы и кодификаторы. Кроме стандартных словарей, справочников и классификаторов, каждая информационная система обладает собственной НСИ, необходимой для ее функционирования. До тех пор, пока немногочисленные информационные системы работают изолированно друг от друга, проблем, вызванных различием в НСИ, как правило, не возникает. Однако если приходится объединить отчетные данные двух и более разных систем, расхождение в НСИ делает невозможным прямое слияние таблиц. В подобных случаях требуется наличие «переводчика» кодов, содержащихся в разных таблицах, к единому виду. Кроме того, нормативно-справочная информация нечасто, но изменяется, и согласованное обновление НСИ во всех информационных системах является непростой задачей. Таким образом, появляется необходимость в создании системы ведения НСИ, которая облегчает согласованное внесение изменений НСИ в различных информационных системах и упрощает интеграцию данных из этих систем.

Ведение метаданных Прототипом системы управления метаданными являлись системы словарей-справочников данных, которые были предназначены для логической централизации сведений об информационных ресурсах предприятия и должны были выполнять функции инструмента управления информационными ресурсами предприятия [2]. Источники данных, в том числе транзакционные системы, содержат метаданные в неявном виде. Например, названия таблиц и имена столбцов в таблицах являются техническими метаданными, а определения сущностей, хранящихся в таблицах, представляют собой бизнес метаданные. Статистика работы приложений, которая может вестись в системах мониторинга, должна быть отнесена к операционным метаданным. Связь между ролями в проекте и правами доступа к базе данных, в том числе правами администрирования, а также данные для аудита и управления изменениями, обычно относятся к проектным метаданным. И, наконец, самая важная часть метаданных – это бизнес метаданные, которые включают в себя бизнес-правила, определения, терминологию, глоссарии, происхождение данных и алгоритмы их обработки. Многие источники содержат в себе элементы метаданных, но практически никогда не несут их полный набор. Результатом является рассогласование в отчетах, предоставляемых разными системами - источниками. Например, в одном отчете объем продукции может исчисляться в рублях, в другом – в штуках, в третьем – в суммарном весовом исчислении. То есть, одно и то же поле «Объем продукции» может содержать в разных отчетах самые разные данные. Подобное рассогласование смысла данных в отчетности вынуждают компании разрабатывать и вводить единую систему унифицированных показателей, отчетов и терминов.

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

НСИ

Данные

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

данные – метаданные

•

данные – НСИ

•

метаданные – НСИ

Рассмотрим каждую пару более подробно.

Данные и метаданные Взаимозависимость данных и метаданных демонстрирует следующий пример. Можно считать, что любая книга содержит данные. Библиографическая карточка к книге – это метаданные, описывающие книгу. Совокупность карточек – это библиотечный каталог, с которым можно работать как с набором данных (базой данных). Карточка заполняется по определенным правилам, которые изложены в книге по библиотечному делу (метамета данные). Эта книга также должна быть размещена в библиотеке, и к ней должна быть подготовлена каталожная карточка, которая должна быть уложена в соответствующий ящик каталожного шкафа, на котором можно найти правила пользования каталогом. Вопрос, являются ли эти правила метаметамета данными, оставим читателю в качестве самостоятельного задания. Если у вас в руках уже есть необходимая книга, вам не нужна каталожная карточка к книге. Большинство домашних библиотек не имеет каталогов потому, что хозяин хорошо знает свою библиотеку и является ее создателем и пользователем. И библиотекарем, если кто-нибудь посторонний попросит книгу из его библиотеки. Но большая общественная библиотека обойтись без каталога не сможет. В корпоративных информационных системах все не так просто и очевидно. Несмотря на то, что первые публикации о необходимости создания систем словарей-справочников появились в середине 80-х годов, корпоративные ресурсы все еще проектируются, разрабатываются и эксплуатируются обособленно, без создания единого смыслового 31

пространства. Подобная ситуация в библиотечном деле означала бы, что читатель одной библиотеки даже не смог бы узнать, есть ли необходимая ему книга в другой библиотеке. В 1995г. была опубликована статья [4], в которой было указано, что для успешной интеграции данных необходимо организовать и поддерживать поток метаданных. На языке пользователей библиотек это открытие звучит приблизительно так: «Библиотеки должны обмениваться информацией о книгах в едином формате». Сейчас стало ясно, что это требование нуждается в уточнении, так как метаданные порождаются на всех этапах создания и эксплуатации информационных систем. На начальном этапе проектирования системы порождаются бизнес метаданные, которые включают в себя бизнес-правила, определения, терминологию, глоссарии, происхождение данных и алгоритмы их обработки, описанные на языке бизнеса. На следующем этапе логического проектирования появляются технические метаданные, такие, как названия сущностей и связи между ними. Имена таблиц и названия столбцов также относятся к техническим метаданным и определяются на этапе физической разработки системы. Метаданные времени эксплуатации – это операционные метаданные, которые включают в себя статистику использования вычислительных ресурсов, активность пользователей и статистику работы приложений (например, частоту исполнения, количество записей, покомпонентный анализ), Метаданные, которые документируют усилия по разработке и предоставляют данные для аудита проекта, присваивают стюардов метаданных, и поддерживают управление изменениями, относятся к проектным метаданным. Врезка Операционные метаданные являются самыми недооцененными. О важности ведения операционных метаданных может свидетельствовать пример крупной компании, оказывающей клиентам различные Web-услуги. В центре ИТ- инфраструктуры компании находится многотерабайтное хранилище данных, вокруг которого строятся заказные локальные клиентские базы данных и приложения. Заказы получает отдел маркетинга, договоры ведет юридический отдел, архитектурная группа разрабатывает и предоставляет документацию руководителям проектов для передачи на аутсорсинговую разработку. Через определенное время контракт с заказчиком заканчивается, все заняты поиском новых клиентов, и нет времени сообщить администраторам, что приложения и базы данных ушедшего клиента можно удалить. В результате растут накладные расходы на архивирование данных и приложений. Кроме того, значительно затрудняется разработка новых версий, поскольку приходится поддерживать протоколы и интерфейсы, которые, возможно, уже никто не использует. Ведение операционных метаданных обеспечивает администраторов и разработчиков системы информацией о том, как часто используются приложения. На основании этой информации можно определить неиспользуемые приложения, данные и интерфейсы, устранение которых из системы значительно снизит стоимость ее сопровождения и дальнейшей модернизации.

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

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

Метаданные и НСИ Существуют различные определения и классификации НСИ по источникам, по способу ведения, по классифицируемым данным. Для целей данной работы можно считать, что нормативно-справочная информация включает в себя словари, справочники, классификаторы, кодификаторы, нормативы и идентификаторы. Классификатор, например, банковский идентификационный код БИК, ведется централизованно внешней организацией (Банком России) и содержит правила формирования кода. Кроме того, классификатор может определять правила использования кода. Так, повторное использование банковских идентификационных кодов участников расчётов разрешается по истечении календарного года после даты их исключения из Справочника БИК РФ, но не ранее выхода на сводный баланс Банка России по расчётам с применением авизо за указанный календарный год. Код БИК не содержит контрольного числа. В Общероссийском классификаторе управленческой документации (ОКУД) принята иерархическая трехступенчатая классификация: класс форм (первые две цифры), подкласс форм (вторые две цифры), регистрационный номер (следующие три цифры), контрольное число (последняя цифра). Классификатор может содержать правила расчета контрольного числа или алгоритмы проверки кода (ОКПО, ОКУД). Метаданные в классификаторах – это правила расчета контрольного числа, описание иерархической классификации и правила использования идентификационных кодов. Идентификатор (ИНН, ISBN) ведется децентрализованно уполномоченными организациями. В отличие от случая классификатора, коды идентификатора обязательно подчиняются правилам расчета контрольного числа. Правила составления идентификатора разрабатываются централизованно и поддерживаются требованиями стандартов или иных распорядительных документов. Основное отличие от классификатора заключается в том, что идентификатор как полный список либо недоступен, либо в нем нет необходимости на этапе проектирования системы. Рабочий список пополняется индивидуальными кодами в процессе эксплуатации системы. Отличие метаданных идентификаторов от метаданных классификаторов заключается в разном поведении на различных этапах жизненного цикла системы. Метаданные идентификаторов должны быть описаны на этапе проектирования, когда самих идентификаторов еще в системе нет или мало. В процессе эксплуатации могут появиться новые идентификаторы, не соответствующие имеющимся метаданным, которые должны

быть пересмотрены для устранения возможного неверной интерпретации новых идентификаторов. Справочник (например, телефонный) ведется сторонней организацией. Нумерация кодов (номеров телефонов) не подчиняется каким-либо правилам. Метаданные справочника менее структурированы, как и сам справочник. Тем не менее, они так же необходимы. Например, могут быть описаны правила отправки сообщения администратору системы при ее сбое, если организация обеспечивает несколько разных способов связи (служебный, домашний, мобильный телефоны, электронная почта, средства обмена сообщениями и др.). Кодификатор создается разработчиками конкретной базы данных для внутренних нужд. Как правило, для кода не разрабатываются ни алгоритмы расчета контрольной суммы, ни правила кодирования. В качестве простого примера можно привести кодирование номеров месяцев в году. Несмотря на внешнее отсутствие правил, кодировка осуществляется в соответствии с замыслом проектировщика и зачастую содержит правила (метаданные) в неявном виде. Например, для проведения расчетов через Новый год в справочник может быть введен повторно месяц январь под 13-м номером. Норматив может представлять собой просто некоторое числовое значение (например, ставка налогообложения), который получен из неструктурированного документа (приказа, закона, акта). Было бы крайне нерационально включать это числовое значение непосредственно в алгоритм расчета, так как при изменении его значения необходимо найти все его вхождения в текст программы и заменить старое значение на новое. Поэтому нормативы, выделенные в отдельные таблицы, являются важной частью НСИ. Метаданные для нормативов определяют область их применения, сроки действия и ограничения. Словари содержат сокращения, термины и другие строковые значения, которые необходимы на этапе генерации отчетов и форм. Наличие таких словарей в системе обеспечивает единую терминологию во всех входных и выходных документах. Словари так близки по своей сути к метаданным, что иной раз затруднительно провести между ними четкую грань. Таблица 1. Виды НСИ Примеры

Ведение

Алгоритм проверки

Правила кодирования

Кодификатор

Код месяца

Локальное

Нет

Возможны

Справочник

Телефонные номера

Централизованное

Нет

Возможны

Классификатор

БИК, ОКУД

Централизованное

Нет / Есть

Есть

Идентификатор

ИНН, ISBN

Децентрализованное Есть

Норматив

Ставка Регулирующие налогообложения органы

Нет

Числовое значение

Словарь

Термины

Нет

Возможны

Бизнеспользователи

Есть

Таким образом, НСИ всегда содержит бизнес - метаданные и технические метаданные. 34

Основная часть технических и бизнес - метаданных создается на этапе «Понимание» жизненного цикла управления метаданными [5]. Проектные метаданные возникают на этапе разработки и, в меньшей степени, на этапе эксплуатации (например, назначение ответственных за метаданные). Операционные метаданные создаются и накапливаются в процессе эксплуатации системы.

Состав корпоративного хранилища данных Корпоративное хранилище данных (КХД) преобразует данные, метаданные и НСИ из разнородных источников и предоставляет их пользователям аналитических систем как единую версию правды. Под источниками данных обычно понимают транзакционные базы данных, унаследованные системы, файлы различных форматов, а также иные источники, данные из которых должны быть предоставлены пользователям. В состав КХД входят: 1. средства ETL извлечения, преобразования и загрузки данных в центральное хранилище данных; 2. центральное хранилище данных (ЦХД), предназначенное и оптимизированное для надежного и защищенного хранения данных; 3. витрины данных, обеспечивающие эффективный доступ пользователей к данным, которые хранятся в структурах, оптимальных для решения конкретных задач пользователей. Центральное хранилище включает в себя, прежде всего, три репозитория: 1. репозиторий нормативно - справочной информации (НСИ); 2. репозиторий данных; 3. репозиторий метаданных. В рассмотренную схему не входят оперативный склад данных, зоны промежуточного хранения (staging area), средства доставки данных и доступа к ним, приложения и другие компоненты КХД, несущественные для данного уровня детализации. Источники ETL

ВД

ЦХД

ВД

ЦХД

ETL НСИ

НСИ

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

КХД

Данные

Мета

Данные

Метаданные

Рис.2. Состав корпоративного хранилища данных Необходимость в репозитории данных стала бесспорной после ряда неудачных попыток создать виртуальные хранилища данных. В этой архитектуре клиентская программа 35

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

Пример реализации существующих подходов В качестве иллюстрации существующих подходов к интеграции данных можно привести статью [6] о внедрении системы НСИ в банке. Банк затратил более шести месяцев на реинжиниринг процессов планирования и прогнозирования для управления эффективностью деятельности. Успех внедрения инициативы управления НСИ вицепрезидент банка объясняет тем, что команда сосредоточилась на решении локальной задачи, избегая «большого взрыва», под которым понимается создание корпоративного хранилища данных. По его мнению, создание корпоративных мастер данных является долгой, сложной и рискованной работой. В качестве следующего этапа планируется создание системы банковской отчетности на основе интеграции всех основных банковских систем с целью использования более детальных данных, согласованных с главной бухгалтерской книгой. В результате будет создан репозиторий финансовых данных, который должен стать основным источником для всех финансовых отчетных систем, и будет поддерживать технологию детализированного (drill-down) анализа. Внимательное прочтение статьи приводит к следующим выводам. Прежде всего, этот проект не предусматривал интеграцию корпоративных данных и охватывал только реинжиниринг процессов планирования и прогнозирования. Созданный репозиторий данных, по-видимому, является узко тематической витриной, и не способен поддерживать распространенные аналитические методы, например, технологию детализированного (drill-down) анализа. В противоположность этому, корпоративное хранилище данных предоставляет согласованные корпоративные данные для широкого ряда аналитических приложений. На практике, единую версию данных способно обеспечить только корпоративное хранилище данных, работающее в одной связке с корпоративными системами ведения НСИ и метаданных. В статье же описывается создание единой версии правды лишь для метаданных, ограниченных областью финансовой отчетности. Таким образом, проектная команда внедрила системы ведения метаданными и НСИ для одной специфической области деятельности. Команда сознательно избегала решений уровня предприятия – не было внедрено ни корпоративное хранилище данных, ни системы ведения метаданными или НСИ компании. Утверждения о практической невозможности внедрения корпоративного хранилища данных опровергаются проектами, ведущимися сотрудниками IBM на регулярной основе. Это проект – типичный “fast win”, основная цель которого – демонстрация быстрого маленького успеха. На данном этапе никто не задумывается о том, какова будет цена переработки созданных приложений и их включения в корпоративную инфраструктуру. К 36

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

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

Результаты: - Окружение ХД - Архитектура ХД - Жизненный цикл данных - Ключевые возможности ХД

Интеграция данных

Результаты: - Окружение ХД и метаданных - Архитектура ХД и метаданных - Жизненный цикл данных и метаданных - Ключевые возможности ХД и метаданных

Задачи

Интеграция метаданных Новые требования

Интеграция НСИ Результаты: - Согласованная среда - Скоординированная архитектура - Совместимые жизненные циклы - Взаимоувязанные возможности

Новые требования

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

существующих процессов интеграции данных в соответствие с требованиями новых систем управления метаданными и/или НСИ. В результате заказчик получает неэффективную работу трех систем управления данными, метаданными и НСИ, сосуществование модулей с близкой функциональностью, растущую стоимость разработки, высокую стоимость владения и разочарование пользователей из-за расхождения данных, метаданных и НСИ. Проекты по интеграции данных, метаданных и НСИ, выполненные последовательно в любом порядке, не могут обеспечить пользователям требуемое качество информации. Чтобы решить эту задачу при построении хранилища данных, три взаимосвязанных проекта интеграции данных, метаданных и НСИ должны выполняться одновременно (рис.4). 1. Интеграция корпоративных метаданных устанавливает единое понимание смысла данных и метаданных. 2. Интеграция НСИ исключает конфликты в кодировке данных и метаданных. 3. Интеграция данных предоставляет конечным пользователям единую версию правды на основе согласованных метаданных и НСИ Корпоративное хранилище данных, построенное в результате скоординированного исполнения этих трех проектов, имеет более высокое качество при пониженной стоимости и сокращенном времени разработки. Предлагаемая стратегия повышает качество информации, предоставляемой хранилищем данных для бизнес - пользователей, и, следовательно, обеспечивает лучшую поддержку принятия решений на основе более точной информации. Эти три интеграционных проекта (для данных, метаданных и НСИ), выполненные параллельно, позволяют реализовать согласованные архитектуры, окружение, жизненные циклы и ключевые возможности для хранилища данных и систем ведения метаданных и НСИ. Проекты могут начинаться с небольшой задержкой относительно друг друга, с тем, чтобы основная часть всех работ выполнялась параллельно.

Завершение проектов

Интеграция данных

Задачи

Интеграция метаданных Интеграция НСИ

Результаты: - Согласованная среда - Скоординированная архитектура - Совместимые жизненные циклы - Взаимоувязанные возможности

Время Рис.4. Предлагаемая последовательность действий

На практике существует множество способов, методов и подходов, обеспечивающих успех параллельного скоординированного исполнения трех крупных проектов интеграции данных, метаданных и НСИ. 1. Три проекта желательно (но не обязательно) объединить в единую программу. 2. Необходимо придерживаться одного из всемирных или национальных стандартов в области управления проектами (напр., Guide to Project Management Body of Knowledge или PRINCE2). 3. Следует выбрать соответствующий жизненный цикл разработки (каскадная модель, спиральная, инкрементальная и так далее). 4. Выбрать подходящее окружение (среду) a. Для хранилища данных (возможно, источники данных, ETL / ELT, репозитории данных, зоны промежуточного хранения, операционные склады данных, прикладные витрины данных, тематические и региональные витрины данных, аналитические средства, генераторы отчетов и другие приложения) b. для метаданных (напр., Управляемая среда метаданных с 6 уровнями: уровни источников, интеграции, репозиториев, управления, витрин метаданных и доставки) c. для НСИ (как вариант, зона восходящих потоков НСИ, ядро управления НСИ, зона нисходящих потоков НСИ) 5. Выбрать пригодную архитектуру a. Для хранилища данных (существует около 20 вариантов архитектур хранилищ данных) b. для метаданных (централизованная, децентрализованная, распределенная)) c. для НСИ (реестр, репозиторий или веерная архитектура) 6. Выбрать уместный жизненный цикл a. для данных (вариант цикла: понимание, извлечение, преобразование, загрузка, консолидация, архивирование, доставка) b. для метаданных (вариант цикла: разработка, публикация, владение, потребление, управление метаданными) c. Для НСИ (вариант цикла: отождествление, создание, обзор, публикация, обновление, выведение из использования) 7. Выбрать ключевые характеристики a. Для хранилища данных (зависят от функциональных и нефункциональных требований) b. для метаданных (определить типы метаданных и их характеристики) c. Для НСИ (вариант характеристик: доступ к данным, отождествление ключей, управление записями, управление иерархиями, модель данных, управление данными, технологические операции и безопасность, интероперабльность) Следует определить набор ролей и специалистов в трех проектах и выбрать рабочие инструменты для каждой роли в команде. Особенностью, которая абсолютно необходима для реализации предлагаемой стратегии, является координация этих проектов. В общем случае, такая координация является предметом управления программами. Специфические детали межпроектного взаимодействия (кто, что, когда, где, как, почему) зависят от проектного окружения, которое было описано выше.

Заключение В настоящее время IBM является единственной компанией, которая предлагает почти полный набор продуктов для осуществления предлагаемой идеи. К ним относятся 39

средства извлечения данных из разнородных источников, средства ведения глоссария метаданных, инструменты проектирования структур данных, средства извлечения и ведения НСИ, современные методологии проектирования среды бизнес - разведки (BI), индустриальные модели данных, а также ПО промежуточного слоя, позволяющее связать компоненты в единую среду информационного обслуживания пользователей. Идея тройной стратегии, изложенная в данной работе, могла возникнуть в 90-х годах прошлого века. Но ее осуществление было практически невозможно из-за огромных временных, финансовых и трудовых затрат на разработку необходимого инструментария, который стал доступен в последнее время. Готовые программные инструментальные средства интеграции данных, метаданных и НСИ поддерживают тройную стратегию и вместе позволяют уменьшить проектные риски, сократить время разработки КХД и предоставить бизнес – аналитикам новые возможности для повышения эффективности деятельности предприятия. Автор благодарит М.Баринштейна, Р.Иванова, Д.Макоеда, А.Карпова, А.Спирина и О.Третьяка за полезные обсуждения.

Литература 1. Асадуллаев C. “Фирменные архитектуры хранилищ данных”, PC Week / RE, 1998, № 32-33, стр. 156-157 2. Leong-Hong B.W., Plagman B.K. Data Dictionary / Directory Systems. John Wiley & Sons. 1982. (Леонг-Хонг Б., Плагман Б. “Системы словарей-справочников данных”, М.: Финансы и статистика, 1986) 3. Inmon, W. H., Zachman, J. A., Geiger, J. G. “Data Stores, Data Warehousing and the Zachman Framework”, McGraw-Hill, 1997 4. Hackathorn R. “Data Warehousing Energizes Your Enterprise,” Datamation, Feb.1, 1995, p. 39. 5. Асадуллаев C. “Управление метаданными средствами IBM Information Server”, 2008, http://www.ibm.com/developerworks/ru/library/sabir/meta/index.html 6. Financial Service Technology. «Mastering financial systems success», 2009, http://www.usfst.com/article/Issue-2/Business-Process/Mastering-financial-systems-success/

Управление метаданными средствами IBM Information Server Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A 30.09.2008 http://www.ibm.com/developerworks/ru/library/sabir/meta/index.html

Резюме При выборе стратегии внедрения системы ведения метаданных в проектах BI необходимо ответить на ряд критически важных вопросов. Какими метаданными необходимо управлять? Каков жизненный цикл этих метаданных? Какие специалисты нужны для успеха проекта ведения метаданных? Какие инструменты могут поддержать работу специалистов на протяжении всего жизненного цикла необходимого набора метаданных? В статье дается взгляд на систему ведения метаданных в проектах по интеграции данных с указанных четырех разных точек зрения.

Типы метаданных Продукт IBM Information Server оперирует четырьмя типами метаданных. Эти метаданные обслуживают задачи интеграции данных, решаемые с помощью Information Server. Бизнес метаданные предназначены для бизнес - пользователей и включают в себя: бизнес-правила, определения, терминологию, глоссарии, происхождение данных и алгоритмы их обработки, описанные на языке бизнеса. Технические метаданные необходимы пользователям инструментальных средств профилирования, моделирования и разработки ETL и BI. Операционные метаданные, включающие статистику работы приложений (например, частоту исполнения, количество записей, покомпонентный анализ), востребованы бизнес пользователями, управляющим и операционным персоналом. Проектные метаданные документируют усилия по разработке и предоставляют данные для аудита проекта, присваивают стюардов метаданных, и поддерживают управление изменениями. Используются стюардами (ответственными за метаданные), руководством, пользователями инструментальных средств и операционным персоналом.

Критерии успеха проекта ведения метаданных Далеко не все компании почувствовали необходимость ведения метаданных в проектах по интеграции данных (например, при создании хранилищ данных). Те же, кто начал внедрять системы управления метаданными, столкнулись с рядом проблем. Требования к системе ведения метаданных в среде BI могут быть четко и своевременно сформулированы, например: •

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

•

Система ведения метаданных пространство в компании.

•

Влияние изменений должно быть выявлено и запланировано.

•

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

•

Новая разработка должна иметь информацию об эксплуатируемых системах

должна установить единое терминологическое

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

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

•

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

•

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

•

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

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

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

Публикация

Использование

Владение Рис.1. Упрощенный жизненный цикл ведения метаданных 42

Расширенный жизненный цикл ведения метаданных состоит из следующих этапов (Рис.2). Анализ и понимание включают в себя профилирование и анализ данных, определение качества наборов и структур данных, понимание смысла и содержания входных данных, выявление связей между столбцами таблиц БД, анализ зависимости и связи информации, исследование данных для их интеграции.

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

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

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

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

Разработка

Потребление Владение

Публикация

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

Рис.2. Расширенный жизненный цикл ведения метаданных Моделирование подразумевает выявление схем объединения данных, выявление и отображение взаимосвязей в метаданных, моделирование структур данных и схем объединения данных, анализ влияния и синхронизация между моделями Разработка обеспечивает коллективное создание и управление бизнес – словарем, поддержку бизнес контекста для ИТ активов, разработка потоков извлечения, трансформации и доставки данных Преобразование заключается в автоматическом создании заданий сложного преобразования данных, в связывании источников и целевых систем с помощью правил преобразования данных Публикация предоставляет унифицированный механизм размещения метаданных и оповещения об обновлениях. Потребление – это визуальная навигация и отображение метаданных и их взаимосвязей; доступ к метаданным, их интеграция, импорт и экспорт; анализ влияния изменений; поиск и запросы. Управление качеством метаданных решает задачи выверки разнородных данных в рамках интеграционных процессов, повышения качества информационных активов, мониторинга качества входных данных и позволяет устранять проблемы со структурами данных и их пригодностью до того, как они повлияют на проект. 43

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

Инструменты ведения метаданных IBM Information Server В состав IBM Information Server входит ряд инструментов ведения метаданных. Business Glossary является Web-инструментом, который обеспечивает коллективное создание и управление бизнес – словарем (глоссарием). Этот инструмент позволяет вести категории метаданных, строить их отношения и связывать физическими источниками. Business Glossary поддерживает управление, настройку и просмотр метаданных, назначение ответственных (стюардов) Business Glossary Anywhere это маленькая фоновая программа, которая предоставляет быстрый доступ «на чтение» к содержимому бизнес – глоссария через буфер обмена операционной системы. Пользователю достаточно выделить термин на экране любого приложения и во всплывающем окне появится бизнес - определение термина. Business Glossary Browser предоставляет доступ «только на чтение» к содержимому бизнес – глоссария в отдельном окне web-браузера. Information Analyzer автоматически сканирует наборы данных для определения их качества и структуры. Этот анализ помогает понять, что поступает на входы интеграционных процессов, начиная от отдельных полей до сущностей высокого уровня. Анализ позволяет устранять проблемы со структурами данных и их пригодностью до того, как они повлияют на проект. Information Analyzer обеспечивает постоянный мониторинг качества входных данных и осуществляет профилирование и анализ данных как непрерывный процесс повышения надежности данных. QualityStage предоставляет средства исследования, улучшения, консолидации, стандартизации и выверки разнородных данных в рамках интеграционных процессов и повышает качество информационных активов. DataStage обеспечивает разработку потоков данных, которые извлекают информацию из множественных источников, трансформируют ее по заданным правилам и затем доставляют ее в целевые базы данных или приложения.

Information Analyzer выполняет анализ систем-источников и передает их в QualityStage, который, в свою очередь, поддерживает DataStage, отвечающий за преобразование данных. При совместном использовании Information Analyzer, QualityStage и DataStage позволяют автоматизировать процессы обеспечения качества данных, то есть устранить ручную трудоемкую или даже невыполнимую работу по интеграции данных. FastTrack выявляет связи между столбцами таблиц БД, связывает колонки с бизнес – терминами, автоматически создает задания для сложного преобразования данных в DataStage и QualityStage Designer, связывает источники и целевые систем с помощью правил преобразования данных, значительно сокращая, таким образом, сроки разработки приложений. Metadata Workbench предоставляет средства визуализация и навигации по метаданным, обеспечивает визуальное отображение взаимосвязей метаданных, предоставляет возможность анализа зависимости и связи информации между разными инструментами, обеспечивает связывание метаданных, создает отчеты о связи бизнес-терминов с ИТ активами, обеспечивает управление метаданными, навигацию и запросы по метамодели; позволяет исследовать ключевые данные для интеграции: Задания, Отчеты, БД, Модели, Термины, Стюарды, Системы. Web Console предоставляет администраторам средства управления доступом к шаблонам, отчетам и результатам, обеспечивает исполнение отчетов по расписанию, сохранение и просмотр множественных версий результатов того же отчета, создание папок для отчетов и указание папок для хранения отчета, определение опций форматирования результатов отчета. Information Services Director предоставляет унифицированный механизм публикации и управления сервисами качества данных и преобразования данных, позволяя ИТ специалистам размещать и управлять сервисами для любой интеграционной задачи. Общие сервисы включают в себя сервисы метаданных, которые обеспечивают стандартный сервис - ориентированный сквозной доступ к метаданным и их анализ Rational Data Architect поддерживает моделирование структур данных и схем объединения данных; обеспечивает выявление схем объединения данных и отображение взаимосвязей в метаданных, анализ влияния и синхронизация между моделями. Metadata Server обеспечивает взаимодействие репозитария метаданных с остальными компонентами и поддерживает следующие сервисы: доступ к метаданным; интеграцию метаданных, анализ влияния, импорт и экспорт метаданных, а также поиск и запросы. Общий репозитарий – это J2EE-приложение. Для постоянного хранения данных репозитарий использует стандартную реляционную СУБД (например, DB2 или Oracle). Резервное копирование, администрирование, масштабирование, проведение транзакций и многопользовательский доступ обеспечивается средствами СУБД. Таким образом, инструменты ведения метаданных IBM Information Server покрывают расширенный жизненный цикл ведения метаданных.

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

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

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

Остальные участники проекта нуждаются в доступе к метаданным «только на чтение», и их потребности покрываются двумя инструментами: Business Glossary Browser и Business Glossary Anywhere. Information Analyzer играет важную роль на этапе анализа интеграции, который необходим для оценки наличия данных и их текущего состояния. Результатам выполнения этого этапа является понимание систем - источников информации и, как следствие, адекватное проектирование целевых систем. Вместо трудоемкого ручного процесса анализа устаревшей или утраченной документации, Information Analyzer предоставляет бизнес-аналитику и аналитику данных возможности анализа эксплуатируемых систем. Бизнес-аналитик использует Information Analyzer для принятия решений по проектированию интеграции на основе изучения таблиц, столбцов, ключей, и их взаимоотношений. Анализ данных помогает понять содержание и структуру данных еще до начала проекта, а впоследствии позволяет делать полезные для интеграционного процесса выводы. Аналитик данных получает в качестве Information Analyzer инструмент для полного анализа систем-источников информации и целевых систем, оценки структуры, содержимого и качества данных на уровне отдельных столбцов, на уровне нескольких столбцов, на уровне таблиц, на уровне файлов, на межтабличном уровне и на уровне нескольких источников. Стюарды могут использовать Information Analyzer для дого, чтобы обеспечить единое понимание смысла данных всеми участниками. С помощью Information Analyzer бизнес-аналитик и бизнес-пользователи могут создавать дополнительные правила для оценки и измерения данных и их качества с течением времени. Эти правила являются либо простыми критериями оценки столбцов по результатам профилирования данных, либо комплексными условиями, проверяющими несколько полей. Правила проверки помогают создавать показатели, изменение которых можно контролировать с течением времени. QualityStage применяется для подготовки интеграции (очистки) данных. ИТразработчик использует QualityStage для автоматизации стандартизации данных, преобразования данных в проверенные стандартные форматы, для проектирования и тестирования циклов сопоставления и подготовки операций по очистке данных. Информация извлекается из системы-источника, после чего оценивается, очищается, обогащается, консолидируется и загружается в целевую систему. Повышение качества данных осуществляется в четыре этапа. Этап исследования производится бизнес-аналитиком с целью полного понимания информации и может быть выполнен как с помощью Information Analyzer, так и на основе встроенных стредств анализа QualityStage. Этап стандартизации переформатирует данные из разных систем, приводя их к необходимому содержанию и формату. Этап сопоставления обеспечивает целостность данных посредством связывания записей из одного или более источников данных, соответствующих одной и той же сущности. Производится с целью создания семантических ключей, позволяющих выявлять информационные взаимоотношения. Этап выживания обеспечивает сохранение наилучших из имеющихся данных и их правильную подготовку для передачи в целевую систему. Производится с целью получения наилучшего представления взаимосвязанной информации.

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

преимущественно,

инструментом

бизнес-аналитика

ИТ-

С помощью редактора картирования, входящего в состав FastTrack, бизнес-аналитик создает спецификации картирования (сопоставления, отображения) потоков от источников к потребителям информации. Каждое картирование может содержать несколько источников и несколько потребителей. Спецификации картирования используются для документирования бизнес - требований. Картирование может быть уточнено благодаря использованию правил преобразования. Сквозное картирование от источников до потребителей может содержать правила преобразования данных, которые являются частью функциональных требований и определяют, как должно создаваться прикладное приложение. ИТ- разработчик использует FastTrack в процессе разработки логики заданий сквозной обработки информации. FastTrack преобразует артефакты, полученные из различных источников, в понятные описания. Эта информация имеет внутренние связи, что позволяет разработчику получать описания из репозитория метаданных и сосредоточиться на разработке сложной логики, не теряя времени на поиск среди множества документов и файлов. FastTrack интегрирован в IBM Information Server так, что спецификации, метаданные и задания становятся доступны всем участникам проекта, которые используют Information Server, Information Analyzer, DataStage Server и Business Glossary. Metadata Workbench предоставляет средства для просмотра, анализа и обогащения метаданных, благодаря чему ИТ - разработчики применяют встроенные в Metadata Workbench инструменты проектирования для управления и понимания информационных активов, созданных и используемых в IBM Information Server. Бизнес-аналитики и эксперты предметной области могут использовать Metadata Workbench для управления метаданными, которые хранятся в IBM Information Server. Сотрудники, ответственные за соблюдение законодательных требований (таких, как акт Сарбейн-Оксли или Базель-II), имеют возможность отслеживать происхождение данных с помощью соответствующих инструментов Metadata Workbench. ИТ - специалисты, ответственные за управление изменениями, например, руководитель проекта, с помощью Metadata Workbench получают возможность провести анализ воздействия изменений на информационную среду.

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

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

Администратор БД

Бизнес пользователи

x x

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

Стюарды

Аналитик данных

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

Business Glossary Business Glossary Browser Business Glossary Anywhere Information Analyzer QualityStage DataStage FastTrack Metadata Workbench Web Console Information Services Director Rational Data Architect

Руководитель проекта

Таблица 1. Роли в проекте ведения метаданных и инструменты IBM Information Server

x x x x x

x x

Администраторы применяют Web Console для глобального администрирования на основе общей инфраструктуры. Например, для доступа ко всем компонентам Information Server пользователю достаточно всего одной учетной записи, что обеспечивает единый вход в систему. ИТ - разработчик использует Information Services Director как основу для развертывания интеграционных задач в форме непротиворечивых и многократно используемых информационных сервисов. Тем самым ИТ - разработчик может использовать сервис - ориентированные задания ведения метаданных совместно с интеграцией корпоративных приложений, управлением бизнес-процессами, с корпоративной сервисной шиной и серверами приложений. Аналитики и архитекторы данных могут применять Rational Data Architect для проектирования баз данных, в том числе, федерированных баз данных, способных взаимодействовать с DataStage и другими компонентами IBM Information Server. Исследуя и анализируя метаданные с помощью Rational Data Architect, аналитики данных выявляют структуру гетерогенных источников данных и создают модели физических данных на основе эскизов, на основе логических моделей с помощью преобразования или на основе баз данных с помощью инженерного анализа.

Заключение Выполненный многосторонний анализ (типы метаданных, жизненный цикл метаданных, участники проекта, инструменты ведения метаданных) позволил сделать следующие выводы. Инструменты ведения метаданных IBM Information Server покрывают расширенный жизненный цикл ведения метаданных в проектах по интеграции данных. 49

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

Глоссарий Глоссарий — это небольшой словарь, в котором собраны слова на определённую тему. Содержит термины и текстовые определения на естественном языке, как, например, вот этот глоссарий. Тезаурус (сокровище) - разновидность словарей, в которых указаны семантические отношения между лексическими единицами (синонимы, антонимы, паронимы, гипонимы, гиперонимы...). Управляемый словарь требует использования предопределенных авторизованных терминов, которые были отобраны создателями словаря. Таксономия моделирует связи между широкими и узкими терминами с помощью управляемых словарей с иерархическими связями между терминами. Онтология расширяет таксономию с помощью моделирования связей, ограничений и функций

Пошаговое внедрение средств управления метаданными IBM Information Server Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A 21.09.2009 http://www.ibm.com/developerworks/ru/library/sabir/Information_Server/index.html

Резюме Всего 10 лет назад рынок предлагал для создания хранилищ данных (ХД) только серверы, СУБД и ограниченный набор инструментов. Разработчикам ХД приходилось самостоятельно разрабатывать средства извлечения и загрузки данных (ETL), средства управления метаданными и нормативно-справочной информацией (НСИ) и многое другое. В настоящее время многие компании предлагают интегрированные средства создания ХД, однако эти инструментальные наборы столь обширны, что иной раз их внедрение представляет собой непростую задачу. Данная статья предлагает пошаговый сценарий внедрения средств управления метаданными IBM Information Server в проектах по созданию ХД на примере типичной нефтедобывающей компании.

Описание сценария Предлагаемый сценарий отражает ситуацию, сложившуюся в крупной нефтедобывающей компании, которая вложила значительные средства в сотни установленных и эксплуатируемых SAP приложений. Вскоре Компания обнаружила, что кажущаяся однородность ИТ среды не обеспечивает автоматически единого понимания бизнес терминов. Одна из крупнейших в мире нефтедобывающих компаний оперирует в четырех основных направлениях деятельности: разведка и эксплуатация месторождений, переработка нефтепродуктов и газа, и сбыт. Дочерние организации разбросаны по всему миру: они действуют в различных странах с разным законодательством, на разных языках, используя различную терминологию. Каждая дочерняя организация имеет свою учетную систему. Отраслевые хранилища данных собирают информацию из учетных систем дочерних организаций. Отчеты, созданные отраслевыми ХД не согласованны друг с другом из-за различного толкования полей (атрибутов) этих отчетов. Компания решила построить систему отчетов, построенную на атрибутах (показателях), и обнаружила, что отсутствие единого бизнес–языка препятствует корпоративной интеграции данных. В этом сценарии нефтедобывающая компания решила установить единое понимание бизнес–терминов, устранив, таким образом, противоречия в понимании реквизитов в отчетах и документах. В соответствии с выявленными проблемами были сформулированы следующие бизнес – цели: •

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

•

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

•

Устранить препятствия для создания корпоративного хранилища данных.

Текущая логическая топология Существующая ИТ среда включает в себя информационные системы дочерних организаций, Отраслевые информационные системы, отраслевые хранилища данных, 51

информационные системы центрального офиса, витрины данных и перспективное корпоративное хранилище данных. Информационные системы дочерних организаций реализованы на различных платформах и находятся вне рассмотрения данной работы. Отраслевые информационные системы основаны, в основном, на SAP R/3. Отраслевые хранилища данных разработаны на платформе SAP BW. Информационные системы центрального офиса (ЦО) разработаны с применением технологий Oracle. Витрины данных в настоящее время работают поверх информационных систем центрального офиса и используют SAP BW. В качестве платформы для корпоративного хранилища данных принята DB2. На Рис. 1 слева представлены информационные системы дочерних компаний четырех основных направлений деятельности Компании: разведки и эксплуатации месторождений, переработки и сбыта нефтепродуктов и газа. Сотни таких систем, включающие в себя модули управления материалами, кадровые, финансовые и другие модули, на данном этапе не будут подключены к системе управления метаданными. В центре Рис. 1 расположена централизованная часть ИТ инфраструктуры Компании. Она включает в себя несколько отраслевых хранилищ данных на платформе SAP/BW и информационные системы центрального офиса на базе СУБД Oracle. Исторически сложилось так, эти две группы используют различные средства и методы сбора данных, поэтому данные, хранимые в этих системах, несогласованны друг с другом. В результате отчеты, создаваемые OLAP-системами не обеспечивают единого понимания атрибутов (показателей) отчетов. Поскольку управление метаданными устраняет рассогласование данных, повышает эффективность интеграции бизнес – процессов и устраняет препятствия для разработки корпоративного хранилища данных, была поставлена задача внедрения системы корпоративного управления метаданными.

Архитектура системы управления метаданными Существуют три основных архитектурных шаблона для системы управления метаданными: двухточечный шаблон, двухточечный с единой метамоделью и «звезда» [1]. Традиционным способом интеграции метаданных является двухточечное связывание систем, при котором устанавливаются «мостики метаданных» между любыми парами информационных систем. Сравнительная легкость и простота парной интеграции приводит к неконтролируемому росту числа соединений между системами, что оборачивается значительными расходами на поддержание единого смыслового пространства при внесении изменений хотя бы в одну систему. Двухточечный шаблон с единой метамоделью значительно сокращает стоимость и сложность разработки и сопровождения двухточечной модели. Использование единой метамодели устраняет необходимость конструирования «мостиков метаданных» и устанавливает полную семантическую эквивалентность на уровне метаданных между различными системами и инструментами, включенными в цепочку доставки данных к пользователям. Архитектурный шаблон «звезда» представляет собой репозиторий, к которому могут обращаться все системы и инструменты. Репозиторий метаданных содержит как единую метамодель, так и метаданные, устанавливающие единый бизнес – язык для всех интегрируемых систем. Централизованная структура информационных систем нефтегазовой компании диктует необходимость выбора архитектурного шаблона «звезда», как наиболее адекватно реализующего необходимые связи между интегрируемыми системами. 52

Рис. 1. Текущая логическая топология 53

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

Архитектура репозитория метаданных Репозиторий метаданных, в свою очередь, может иметь централизованную, децентрализованную или распределенную архитектуру. Каждая из архитектур имеет свои особенности и назначения. Централизованная архитектура предполагает наличие глобального репозитория, который построен на основе единой модели метаданных и обслуживает все корпоративные системы. Локальные репозитории отсутствуют. В системе имеется единственная, единообразная и согласованная модель метаданных. Необходимость доступа всех систем к единому центральному репозиторию метаданных может привести к деградации производительности удаленных программно-аппаратных комплексов из-за возможных проблем связи. В распределенной архитектуре глобальный репозиторий содержит корпоративные метаданные для центральных информационных систем, а локальные репозитории, содержащие подмножество метаданных, обслуживают периферийные системы. Модель метаданных является единообразной и согласованной. Все метаданные проходят обработку и согласование в центральном репозитории, но доступ к ним осуществляется через локальные репозитории. Достоинства локальных репозиториев компенсируются требованиями к их синхронизации с центральным репозиторием метаданных. Распределенная архитектура предпочтительна для географически распределенных предприятий. Децентрализованная архитектура предполагает, что центральный репозиторий содержит только ссылки на метаданные, которые ведутся независимо в локальных репозиториях. Отсутствие затрат на согласование терминов и понятий значительно сокращает стоимость разработки, но приводит к множественным и разнообразным моделям, несовместимых друг с другом. Применимость этой архитектуры ограничена случаем, когда интегрируются системы внутри непересекающихся направлений производственной деятельности компании. 54

Поскольку одной из наиболее значимых целей Компании является установление единого бизнес–языка, то децентрализованная архитектура неприменима. Выбор между централизованной и распределенной архитектурой основан на том, что все интегрируемые системы расположены в Центральном офисе, и проблем с устойчивой связью нет. Таким образом, наиболее применимой для данной задачи является централизованная архитектура репозитория метаданных. Таблица 1. Сравнение архитектур репозиториев метаданных Архитектура Централизованная Распределенная

Децентрализованная

Метамодель

Единственная, единая и единообразная

Единственная, единая и Множественные, единообразная разнообразные, несовместимые модели

Глобальный репозиторий

Полный набор метаданных

Подмножество глобальных метаданных

Локальный репозиторий

Нет локальных репозиторив

Метаданные локальных Собственные систем метамодели, метаданные и их организация

Консолидированное Управление метаданными Доставка метаданных

Корпоративная

Ссылки на метаданные в локальных репозиториях

Обработка централизованная, доступ локальный

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

Корпоративная

Фрагментированная

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

Целевая логическая топология Выбранные архитектуры среды управления метаданными, системы управления метаданными и репозитория метаданных приводят к целевой логической топологии, представленной на Рис. 2. По сравнению с текущей логической топологией видны два основных изменения. 1. Планируется создание корпоративного хранилища данных и использование IBM Information Server в качестве средства извлечения, преобразования и загрузки данных (ETL). Эта задача находится вне рамок текущей работы. 2. Второе, наиболее важное изменение – это централизованное управление метаданными, которое позволить установить в Компании единый бизнес-язык для всех систем, эксплуатируемых в центральном офисе. Поэтому на клиентской стороне требуется только программа-клиент метаданных.

Рис. 2. Целевая логическая топология

Две фазы расширенного жизненного цикла метаданных Расширенный жизненный цикл ведения метаданных (Рис. 3), предложенный в работе [3], состоит из следующих этапов: анализ и понимание, разработка, преобразование, публикация, потребление, владение, управление качеством, управление метаданными, отчетность и аудит. Жизненный цикл с точки зрения пошагового внедрения удобно разделить на две фазы: 1. Фаза «Проектирование метаданных»: преобразование, публикация.

анализ

понимание,

разработка,

2. Фаза «Производство метаданных»: потребление, владение, управление качеством, управление метаданными, отчетность и аудит. Как следует из названий, на первой фазе осуществляется, преимущественно, анализ, проектирование и разработка метаданных, тогда как вторая фаза более тесно связана с эксплуатацией системы управления метаданными. Для наглядности этапы фазы «Проектирование метаданных» сгруппированы в левой части Рис. 3, тогда как этапы фазы «Производство метаданных» размещены справа.

Фаза «Проектирование метаданных» Профилирование и анализ данных, определение качества наборов и структур данных, понимание смысла и содержания входных данных, выявление связей между столбцами таблиц БД, анализ зависимости и связи информации, исследование данных для их интеграции выполняются на этапе Анализ и понимание. •

Бизнес-аналитик осуществляет картирование потоков данных и готовит исходную классификацию.

•

Эксперт предметной области должен разработать бизнес классификацию.

•

Аналитик данных выполняет анализ систем.

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

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

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

ИТ разработчик создает логику обработки, преобразования и перемещения.

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

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

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

ИТ разработчик обеспечивает размещение сервисов, с помощью которых

•

Стюард метаданных осуществляет публикацию метаданных 57

Анализ и понимание Бизнес-аналитик Картирование потоков данных Исходная классификация Эксперт предметной области Бизнес классификация Аналитик данных Анализ систем

Отчетность и аудит Стюард метаданных Проведение аудита Подготовка отчетов

Управление Руководитель проекта Назначение стюардов Определение ответственности и управляемости Моделирование Аналитик данных Логическая и физическая модели Синхронизация моделей

Разработка ИТ разработчик Логика обработки, преобразования и перемещения

Преобразование ИТ разработчик Задания на преобразования и перемещение данных

Управление качеством Руководитель проекта Анализ воздействия изменений Бизнес-аналитик Выявление противоречий в метаданных Эксперт предметной области Обновление бизнес классификации Аналитик данных Устранение противоречий ИТ разработчик Управление ресурсами данных Стюард метаданных Поддержка единого понимания Бизнес - пользователи Выявление рассогласований

Владение Стюард метаданных Права использования метаданных Публикация ИТ разработчик Размещение сервисов Стюард метаданных Публикация метаданных

Потребление Бизнес - пользователи Использование метаданных Выявление рассогласований

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

Фаза «Производство метаданных» Визуальная навигация и отображение метаданных и их взаимосвязей; доступ к метаданным, их интеграция, импорт и экспорт; анализ влияния изменений; поиск и запросы осуществляются на этапе Потребление (Рис.3). •

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

Права доступа к метаданным определяются на этапе Владение. •

Стюард метаданных определяет права использования метаданных

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

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

•

Бизнес-аналитик выявляет противоречия в метаданных

•

Эксперт предметной области обновляет бизнес классификацию

•

Аналитик данных устраняет противоречия между метаданными и классификацией

•

ИТ разработчик управляет ресурсами данных

•

Стюард метаданных поддерживает единое понимания смысла метаданных

•

Бизнес – пользователи в свое работе неизбежно выявляют рассогласование метаданных

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

Руководитель проекта должен назначить стюардов и распределить ответственность между членами команды.

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

Стюард метаданных осуществляет проведение аудита и подготовку отчетов

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

Роли и взаимодействия на фазе проектирования метаданных С помощью редактора картирования, входящего в состав FastTrack, бизнес-аналитик создает спецификации картирования (сопоставления, отображения) потоков от источников к потребителям информации (Рис.4). Каждое картирование может содержать несколько источников и несколько потребителей. Спецификации картирования используются для документирования бизнес - требований. Картирование может быть уточнено благодаря использованию правил преобразования. Сквозное картирование от источников до потребителей может содержать правила преобразования данных, которые являются частью функциональных требований и определяют, как должно создаваться прикладное приложение. Бизнес-аналитик использует Information Analyzer для принятия решений по проектированию интеграции на основе изучения таблиц, столбцов, ключей, и их 59

взаимоотношений. Анализ данных помогает понять содержание и структуру данных еще до начала проекта, а впоследствии позволяет делать полезные для интеграционного процесса выводы. Эксперт предметной области (автор метаданных) использует Business Glossary для создания бизнес-классификации (таксономии), которая обеспечивает иерархическую структуру терминов. Термин представляет собой слово или фразу, которая может быть использована для классификации и группирования объектов в репозитарии метаданных. Business Glossary представляет экспертам предметной области средства коллективной работы для аннотирования определений данных, редактирования описаний и их категоризации. Аналитик данных получает в качестве Information Analyzer инструмент для полного анализа систем-источников информации и целевых систем, оценки структуры, содержимого и качества данных на уровне отдельных столбцов, на уровне нескольких столбцов, на уровне таблиц, на уровне файлов, на межтабличном уровне и на уровне нескольких источников. Аналитики данных и архитекторы могут вызывать Rational Data Architect для проектированы баз данных, в том числе, федеративных, которые могут взаимодействовать с DataStage и другими компонентами Information Server. Rational Data Architect анализ данных на основе исследования и анализа метаданных. Аналитики данных могут выявлять, моделировать, визуализировать и связывать разнородные активы данных, и могут создавать физические модели с нуля, из логических моделей с помощью преобразования, или с помощью обратного проектирования эксплуатируемых баз данных. ИТ- разработчик использует FastTrack в процессе разработки логики заданий сквозной обработки информации. FastTrack преобразует артефакты, полученные из различных источников, в понятные описания. Эта информация имеет внутренние связи, что позволяет разработчику получать описания из репозитория метаданных и сосредоточиться на разработке сложной логики, не теряя времени на поиск среди множества документов и файлов. FastTrack интегрирован в IBM Information Server так, что спецификации, метаданные и задания становятся доступны всем участникам проекта, которые используют Information Server, Information Analyzer, DataStage Server и Business Glossary. ИТ-разработчик использует QualityStage для автоматизации стандартизации данных, преобразования данных в проверенные стандартные форматы, для проектирования и тестирования циклов сопоставления и подготовки операций по очистке данных. Информация извлекается из системы-источника, после чего оценивается, очищается, обогащается, консолидируется и загружается в целевую систему. ИТ - разработчик использует DataStage для преобразования и перемещения данных из источника в целевую систему в соответствии с правилами бизнеса, предметной области и целостности или в соответствии с остальными данными целевой среды. Используя метаданные для анализа и сопровождения, а также встроенные правила проверки данных, ИТ-разработчик проектирует и реализует процессы интеграции данных, получаемых от широкого набора внутрикорпоративных и внешних источников, обработки и преобразования больших массивов данных с использованием масштабируемых параллельных технологий. ИТ-разработчик может выбрать пакетный режим функционирования DataStage, режим реального времени, или Web-сервис.

Рис. 4. Роли и взаимодействия на фазе жизненного цикла «Проектирование метаданных» 61

ИТ - разработчик привлекает Information Services Director как основу для размещения интеграционных задач в качестве согласованных и многократно используемых сервисов. Затем ИТ - разработчик может использовать сервис - ориентированные задания управления метаданными для интеграции корпоративных приложений, для управления бизнес – процессами, вместе с корпоративной интеграционной шиной и серверами приложений. Бизнес-пользователи нуждаются в доступе к метаданным «только на чтение», и их потребности покрываются двумя инструментами: Business Glossary Browser и Business Glossary Anywhere.

Роли и взаимодействия на фазе производства метаданных ИТ - специалисты, ответственные за управление изменениями, например, руководитель проекта, с помощью Metadata Workbench может анализировать воздействие изменений на информационную среду (Рис.5). Business Glossary позволяет назначать роли стюардов, ответственных за метаданные, пользователю или группе пользователей, а также связывать роли стюардов с одним или несколькими объектами метаданных. Ответственность стюардов включает в себя эффективное управление и интеграцию с соответствующими данными, и обеспечение доступа к данным для авторизованных пользователей. Стюарды должны убедиться, что все данные правильно описаны, и что все пользователи данных понимают смысл этих данных. Если бизнес-аналитик выявляет противоречия между глоссарием и столбцами базы данных, он может оповестить авторов метаданных с помощью функционала Business Glossary. Стадия исследования выполняется бизнес - аналитиком с тем, чтобы достичь полной видимости действительного состояния данных и в этом ему могут помочь инструменты анализа, встроенные в QualityStage. Аналитик данных устраняет противоречия между глоссарием и таблицами и столбцами баз данных с помощью Business Glossary и Rational Data Architect Metadata Workbench предоставляет ИТ – разработчикам средства просмотра, анализа и обогащения метаданных. Таким образом, ИТ – разработчики могут использовать средства проектирования, встроенные в Metadata Workbench для управления и понимания информационных активов, созданных и доступных посредством IBM Information Server Бизнес - пользователи, ответственные за соблюдение законодательных требований (таких, как акт Сарбейн-Оксли или Базель-II), имеют возможность отслеживать происхождение данных с помощью соответствующих инструментов Metadata Workbench. Стюарды могут использовать Information Analyzer для поддержки единого понимания смысла данных всеми пользователями и участниками проекта. Стюарды могут привлекать Metadata Workbench для хранящимися в IBM Information Server.

управления метаданными,

Администраторы применяют Web Console для глобального администрирования на основе общей инфраструктуры Information Server. Например, для доступа ко всем компонентам Information Server пользователю достаточно всего одной учетной записи, что обеспечивает единый вход в систему. Для каждого пользователя хранится набор полномочий, который обеспечивает единую и однократную регистрацию ко всем зарегистрированным ресурсам.

Рис. 5. Роли и взаимодействия на фазе жизненного цикла «Производство метаданных»

Путь внедрения – 1. Проектирование. Итак, мы имеем два пути внедрения метаданных: Первый путь: Проектирование метаданных, Второй путь: Производство. Эти два маршрута начинаются в одной исходной точке. На Рис. 6 представлен путь внедрения метаданных, который связан, в основном, с первой частью жизненного цикла метаданных – «Проектирование». Имеются в виду этапы Анализ и проектирования, Моделирование, Разработка, Преобразование, Публикация и Потребление. Прежде всего, необходимо установить Metadata Server, репозиторий метаданных, и обслуживает сервисы метаданных.

который

поддерживает

В качестве второго шага надо установить Information Analyzer для выполнения автоматизированного анализа информационных систем, находящихся в эксплуатации, и для определения первоначальной классификации. Третий шаг – это добавление продукта FastTrack, который позволит создать спецификации картирования для потоков данных от источника к системе назначения. В качестве четвертого шага мы можем добавить Business Glossary для создания бизнес классификации. С тем, чтобы разработать логические и физические модели на пятом шаге может быть добавлен Rational Data Architect. Шестой шаг – это расширенное использование установленного ранее Information Analyzer для создания правил выверки данных. На седьмом шаге мы планируем расширенное использование FastTrack для программирования сквозной обработки информации от источников до систем назначения. На седьмом шаге можно установить QualityStage и DataStage для разработки и выполнения процедур преобразования данных. Для размещения интеграционных заданий как сервисов на девятом шаге следует добавить Information Services Director. На последнем, десятом шаге, необходимо дать пользователям права доступа к метаданным, и для этого следует добавить Business Glossary Browser and Business Glossary Anywhere.

Рис. 6. Путь внедрения метаданных на этапах жизненного цикла «Проектирование метаданных»

Путь внедрения – 2. Производство. Этот путь внедрения покрывает производственную часть жизненного цикла управления метаданными, и включает в себя Отчетность и аудит, Владение, Управление качеством и управление. Он начинается в той же начальной точке, что и первый путь внедрения. Практически все продукты были внедрены во время первого пути, поэтому второй путь в основном связан с расширенным использованием программного обеспечения, установленного ранее. Web-консоль является одним из двух продуктов, которые будут добавлены во время этого пути внедрения. Она обеспечивает возможности управления полномочиями пользователей, и следовательно, должна быть установлена в самом начале. Следующий шаг «Расширенное использование Business Glossary» должен быть выполнен как можно раньше для того, чтобы назначить стюардов, ответственных за метаданные. Для выполнения анализа воздействия изменений необходимо добавить Metadata Workbench. Расширенное использование продуктов FastTrack и QualityStage позволяет выявить противоречия между словарем и столбцами баз данных. Расширенное использование Rational Data Architect поможет устранить выявленные противоречия между глоссарием и столбцами баз данных. Применение программного пакета Metadata Workbench способствует пониманию и управлению информационными активами. С помощью Business Glossary пользователи могут обновлять бизнес – классификацию в соответствии с новыми требованиями. Для подготовки отчетов о выявленных рассогласованиях метаданных и других недостатков, желательно использовать Metadata Workbench. Information Analyzer следует использовать для поддержки единого понимания смысла метаданных. Для поддержки метаданных и подготовки отчетов о состоянии метаданных могут быть использованы и Metadata Workbench и Web Console.

Рис. 7. Путь внедрения метаданных на этапах жизненного цикла «Производство метаданных»

Заключение Предложенные пути внедрения покрывают жизненный цикл ведения метаданных в проектах по созданию хранилищ данных. Участники проекта ведения метаданных пошагово обеспечиваются набором инструментов IBM Information Server управления метаданных. Программное обеспечение, внедренное инкрементальным образом, в конечном итоге реализует заранее выбранные архитектуры среды управления метаданными, системы управления метаданными и репозитория метаданных в соответствии с целевой логической топологией. Пошаговое внедрение средств управления метаданными IBM Information Server снижает сроки и трудоемкость реализации проекта, позволяет бизнес – пользователем раньше воспользоваться преимущества управления метаданными, и повышает вероятность успешного внедрения среды управления метаданными. Эта работа выполнена в рамках инициативы plusOne. Автор выражает благодарность Anshu Kak за приглашение в проект plusOne и поддержку.

Литература 1. Poole J., Chang D., Tolbert D, Mellor D. Common Warehouse Metamodel: An Introduction to the Standard for Data Warehouse Integration, Wiley, 2003. 2. Marco D., Jennings M. Universal Meta Data Models, Wiley, 2004. 3. Асадуллаев C. “Управление метаданными средствами IBM Information Server”, 2008, http://www.ibm.com/developerworks/ru/library/sabir/meta/index.html

Ведение НСИ на практических примерах Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A Александр Карпов, архитектор решений SWG IBM EE/A 09.11.2010 http://www.ibm.com/developerworks/ru/library/sabir/nsi/index.html

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

Основные понятия и терминология Мастер - данные (МД) включают в себя информацию о клиентах, сотрудниках, продуктах, товарах, поставщиках, которая, как правило не является транзакционной по своей природе. Нормативно-справочная информация (НСИ) включает в себя словари, справочники, классификаторы, кодификаторы, нормативы и идентификаторы. Это – базовый уровень транзакционных систем, который в ряде случаев ведется внешними уполномоченными организациями. В работе [1] было показано, что нормативно-справочная информация включает в себя словари, справочники, классификаторы, кодификаторы, нормативы и идентификаторы. Классификатор ведется централизованно внешней организацией, содержит правила формирования кода и имеет трех- или четырехступенчатую иерархическую структуру. Классификатор может определять правила использования кода. Классификатор не всегда содержит правила расчета контрольного числа или алгоритмы проверки кода. Примером классификатора является банковский идентификационный код БИК, которой ведется Банком России, не содержит контрольного числа, имеет четырехуровневую иерархическую структуру: код Российской Федерации, код территории Российской Федерации, условный номер подразделения расчетной сети Банка России, условный номер кредитной организации. Общероссийский классификатор предприятий и организаций (ОКПО) ведется централизованно Росстатом и, в отличие от БИК, содержит методику расчета контрольного числа для кода ОКПО. Идентификатор (ИНН, ISBN) ведется уполномоченными организациями децентрализованно. В отличие от классификатора, коды идентификатора обязательно подчиняются правилам расчета контрольного числа. Правила составления идентификатора разрабатываются централизованно и поддерживаются требованиями стандартов или иных распорядительных документов. Основное отличие от классификатора заключается в том, что идентификатор как полный список либо недоступен, либо в нем нет необходимости на этапе проектирования системы. Рабочий список пополняется индивидуальными кодами в процессе эксплуатации системы. Справочник (например, телефонный) ведется сторонней организацией. Нумерация кодов (номеров телефонов) не подчиняется каким-либо правилам.

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

НСИ и мастер – данные В отечественной литературе давно устоялось понятие «нормативно-справочная информация», которое появилось в дисциплинах, касающихся управления народным хозяйством еще в докомпьютерные времена [2]. Термин «мастер-данные» пришел к нам из англоязычной документации и, к сожалению, стал использоваться как синоним НСИ. На самом деле между НСИ и мастер-данными есть значительные различия.

Рис. 8. Пример данных, мастер-данных и НСИ

Рис. 8 в упрощенном виде иллюстрирует отличие НСИ, мастер-данных и транзакционных данных. В условной системе продажи авиабилетов роль НСИ выполняет кодификатор аэропортов, созданный разработчиками системы с учетом неких специфических требований. Но для взаимодействия с другими международными информационными системами код аэропорта должен быть понятен всем. Этой цели служит трехбуквенный уникальный код аэропорта, присваиваемый аэропортам Международной ассоциацией воздушного транспорта (IATA). Данные пассажира являются не столь стабильными, как коды аэропорта. В тоже время, будучи один раз введенные в систему, данные пассажира могут быть в дальнейшем 70

использованы для различных маркетинговых акций, например, для скидок при достижении определенного суммарного полетного расстояния. Такая информация обычно относится к мастер – данным. К ним же можно отнести данные об экипажах, о самолетном парке компании, о грузовых и пассажирских терминалах, и о многих других сущностях, участвующих в процессе авиаперевозок, но не рассматриваемых в рамках нашего упрощенного примера. Последняя, верхняя строка на Рис. 8 схематично изображает условную транзакцию, связанную с продажей билета. Аэропортов в мире сравнительно немного, клиентов намного больше, но они могут многократно пользоваться услугами этой компании, а билет не может и не должен быть использован повторно. Таким образом, для авиакомпании данные о продажах билетов являются наиболее часто меняющимися транзакционными данными. Суммируя можно сказать, что НСИ составляет базовый уровень автоматизированных информационных систем, а мастер-данные хранят информацию о клиентах и сотрудниках, о поставщиках продукции, оборудовании, материалах и о других бизнес – сущностях. При этом НСИ и МД имеют много общего, поэтому в тех случаях, когда рассматриваемые факторы касаются и НСИ, и МД, мы будем упоминать их как «НСИ и МД», например, «система ведения НСИ и МД».

Общие недостатки традиционного ведения НСИ и МД Наиболее распространенной и очевидной проблемой традиционного ведения НСИ и МД является отсутствие поддержки временных изменений. Адрес, как правило, является одной из важнейших компонент НСИ и МД. К сожалению, адреса меняются. Клиент может переехать, но может «переехать» целый дом и даже улица. Так, в 2009 году адрес комплекса зданий «Башня на набережной» изменился с «Краснопресненская набережная, дом 18» на «Пресненская набережная, дом 10». Таким образом, запрос “Какое количество корреспонденции было доставлено в офис компании, арендующей помещения в «Башне на набережной» в 2009 году?” должен корректно обрабатывать записи о доставках с двумя разными адресами. Однако, для того чтобы изменения в жизни были отражены в ИТ системе, мало иметь технологические (программно-аппаратные) средства ведения НСИ и МД. Необходим ктото, или что-то, для отслеживания изменений. То есть, требуется организационные меры, например, штат сотрудников с должностными обязанностями, соответствующими принятой методологии ведения НСИ. Таким образом, корпоративное ведение НСИ и МД мероприятий:

включает в себя три категории

1. Методологические мероприятия, определяющие методы, регламенты, стандарты, процессы и роли, поддерживающие весь жизненный цикл ведения НСИ и МД 2. Организационные мероприятия определяющие в соответствии с методологическими требованиями организационную структуру, функциональные подразделения и их задачи, роли и должностные обязанности сотрудников. 3. Технологические мероприятия, лежащие на уровне ИТ и обеспечивающие исполнение организационных и методологических мероприятий. В данной статье мы рассмотрим, в первую очередь, технологические мероприятия, которые включают в себя создание единой модели данных НСИ и МД, ведение и архивацию исторической НСИ и МД, идентификацию объектов НСИ и МД, устранение дубликатов, выявление противоречий, обеспечение ссылочной целостности, поддержку жизненного цикла объекта НСИ и МД, выработку правил очистки, создание системы 71

ведения НСИ и МД и ее интеграцию с эксплуатируемыми информационными системами предприятия.

Технологические недостатки ведения НСИ и МД Рассмотрим более детально технологическую область создания инфраструктуры НСИ и МД и связанные с ней недостатки традиционного ведения НСИ и МД.

Нет единой модели данных НСИ и МД Единая модель данных НСИ и МД отсутствует, или она не формализована, что не позволяет эффективно использовать объекты НСИ и МД и затрудняет любую автоматизацию работы с данными. Модель данных является основной и самой важной частью ведения НСИ и МД, отвечая, к примеру, на следующие вопросы: •

что включать в идентифицирующие атрибуты объекта НСИ и МД?

•

что из всех атрибутов объекта НСИ и МД хранить в модели данных и отнести к НСИ и МД, а что отнести к операционным данным и оставить в эксплуатируемой информационной системе?

•

как провести интеграцию по модели с внешними идентификаторами и классификаторами (ОКПО, ОКУД)?

•

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

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

Сложность отождествления объектов НСИ и МД В различных ИТ системах объекты НСИ и МД имеют собственные идентификаторы – наборы атрибутов. Ситуация осложняется тем, когда для одних и тех же объектов в различных системах не удается выделить один общий набор атрибутов, сочетание которых уникально и идентифицирует объект в информационной системе – аналог составного ключевого поля в базах данных. В этом случае задача отождествления и сравнения объектов в различных ИТ системах переходит из детерминистической области в область вероятностной. Качественно провести идентификацию объектов НСИ и МД без специализированных средств анализа и обработки данных в этом случае затруднительно.

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

за границы возможностей ИТ систем и требуют участия оператора. Следует отметить, что возникновение дубликатов является системной ошибкой, появляющейся на самых ранних шагах бизнес-процессов, использующих объект НСИ и МД. Далее по ходу исполнения бизнес процесса дубликат обрастает связями, атрибутным составом и ситуация еще более усложняется.

Несогласованность метаданных НСИ и МД Каждая информационная система, поддерживающая линию бизнеса предприятия, и в которой зарождаются специфичные для этого бизнеса объекты НСИ и МД, определяет свой набор бизнес правил и ограничений, накладываемых как на атрибутный состав (метаданные), так и на значение атрибутов. В результате часто возникает ситуация, когда эти правила и ограничения, заданные в различных информационных системах, входят в противоречие друг с другом, таким образом сводя на нет даже теоретические попытки привести все объекты НСИ к одному виду. Ситуация усугубляется, когда при внешне совпадающей модели данных, данные имеют одно и тоже смысловое значение, но различное значение с точки зрения представления: различное написание, перестановки в адресах, сокращения ФИО, различные кодировки, сокращения.

Ссылочная целостность и синхронизация модели НСИ и МД В реальной жизни все объекты НСИ и МД, находящиеся в пространстве своей IT системы, содержат в себе не только значения, но и ссылки на другие НСИ и МД, которые могут находиться (и вестись) в отдельных внешних системах. Здесь в полный рост встает проблема синхронизации и поддержки целостности всей модели НСИ и МД организации. Одним из общепринятых путей решения такого рода проблем является переход к использованию НСИ и МД которые ведутся и импортируются в организацию извне (к примеру, справочники КЛАДР, ОКВЭД, ТН ВЭД, ФСКП и ЕКПС).

Рассогласование жизненного цикла объекта НСИ и МД В результате наличия одного и того же объекта НСИ и МД в различных корпоративных системах, ввод и изменение этого объекта в этих системах несогласован, и зачастую растянут во времени. Возможна ситуация, когда объект находится в различных системах во взаимоисключающих статусах (активен в одной системе, архивирован в другой, удален в третьей), что затрудняет поддержку целостности объектов НСИ. Несвязанные и «размазанные» во времени объекты сложно использовать как в транзакционных, так и в аналитических процессах.

Выработка правил очистки Правила очистки НСИ и МД зачастую вполне справедливо относят к методологическим аспектам. Безусловно, ИТ специалисты нуждаются в постановке задачи от бизнес – пользователей, например, в каких случаях необходимо обновлять коды аэропортов, или какая из двух платежек имеет правильную кодировку реквизитов. Но бизнес специалисты не знакомы с тонкостями реализации эксплуатируемых ИТ систем. Более того, документация на эти системы или неполна, или отсутствует. Поэтому необходим анализ информационных систем с целью уточнения правил очистки и выявления новых правил.

Неверный выбор мастер-системы ведения НСИ и МД Чаще всего самыми значимыми источниками и потребителями НСИ и МД являются крупные унаследованные корпоративные информационные системы, являющиеся ядром бизнеса предприятия. В реальной жизни такую систему зачастую выбирают в качестве «мастер системы» для ведения НСИ и МД вместо создания специализированного 73

репозитория НСИ и МД. При этом не принимается о внимание, что подобный функционал, как правило, является несвойственным этой ИТ системе. В результате любые доработки таких систем, связанные с НСИ и МД, выливаются в крупные и необоснованные траты. Ситуация усугубляется, когда по мере развития подсистемы ведения НСИ и МД необходимо ввести качественно новый функционал: пакетную обработку данных, форматирование и очистку, назначить стюардов данных.

Неготовность ИТ систем к интеграции НСИ и МД Для того, чтобы полноценно внедрить ведение НСИ и МД в существующие ИТ системы предприятия, необходимо провести интеграцию этих систем и, чаще всего, эта интеграция необходима не как единовременный и локализованный акт, а как изменение процессов, живущих внутри ИТ систем. Помимо интеграции для работы в операционном режиме (online), необходимо провести интеграцию для проведения первоначальной пакетной загрузки данных (ETL), а также для проведения процедур ручной сверки (реконсиляции). Не все автоматизированные информационные системы готовы к таким изменениям, не все системы предоставляют такие интерфейсы, а чаще всего, это совершенно новый функционал для таких систем. При внедрении системы возникают архитектурные вопросы, связанные с выбором из различных вариантов внедрения системы НСИ и МД и интеграции её с технологическим ландшафтом предприятия. В подтверждение важности этого момента заметим, что существуют разработанные и проверенные архитектурные шаблоны и подходы, нацеленные на правильное развертывание и интеграцию системы НСИ и МД.

Примеры проблем традиционного ведения НСИ и МД Таким образом, основные проблемы ведения НСИ проистекают из-за децентрализации и фрагментации НСИ на предприятии и проявляются на практике в конкретных примерах.

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

Адрес как уникальный идентификатор В другом случае страховая компания проводила слияние анкетных данных клиентов, где в качестве идентифицирующего атрибута использовался, в том числе, адрес. Выяснилось, что больше всего клиентов было зарегистрировано на адреса «тот же», «там же». Данные низкого качества шли из прикладной системы, поддерживающей деятельность страховых агентов, которая позволяла агентам вольно интерпретировать значения полей клиентской анкеты. Более того, в этой системе отсутствовали любые форматные и логические проверки введенных данных. 74

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

Расхождение согласованных данных Четвертый пример описывает типичную ситуацию для многих организаций. В результате бурного развития бизнеса предприятия было решено открыть новое направление, поддерживающее работу с клиентами в стиле B2C / B2B через Интернет. Для этого была приобретена новая ИТ система, поддерживающая автоматизацию нового направления бизнеса компании. При развертывании возникла необходимость провести интеграцию с существующими НСИ и мастер-данными предприятия и расширить их специфичными атрибутами, что оказалось не так просто, в первую очередь из-за отсутствия выделенной системы НСИ и МД. В результате НСИ были однократно загружены в новую систему безо всякой обратной связи с существующим ИТ ландшафтом компании, что через некоторое привело к двум независимым версиям клиентских справочников. Поначалу проблема решалась путем ручной обработки клиентских данных в электронных таблицах, однако через некоторое время количество клиентов значительно возросло, справочники «разошлись», и ручная обработка оказалась неэффективной и дорогой. В результате ситуация привела к серьезной эскалации проблемы на уровне бизнес - пользователей, не имеющих общей картины о своих клиентах для проведения маркетинговых акций.

Преимущества корпоративного ведения НСИ и МД Корпоративное ведение НСИ и МД обеспечивает следующие преимущества: •

Выполнение требований закона и снижение рисков

•

Рост прибылей и удержание клиентов

•

Снижение затрат

•

Повышение гибкости для поддержки новых бизнес стратегий.

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

Выполнение требований закона и снижение рисков Следственные органы потребовали от крупной компании предоставить данные за предыдущие 10 лет. Задача казалась несложной и выполнимой: компания задолго до этого ввела процедуры регулярного архивного и резервного сохранения данных и прикладных программ, носители данных хранились в защищенном помещении, аппаратура для чтения носителей еще не успела устареть. Однако после восстановления исторических данных из архива обнаружилось, что данные не имеют практического смысла – НСИ за это время неоднократно менялась, и теперь невозможно установить, к чему относились те или иные данные. Никто не предусмотрел архивирование НСИ – казалось, что это устойчивая ко времени информация. На компанию были наложены значительные штрафные санкции, в компании были сделаны серьезные организационные выводы в отношении руководителей. Кроме того, было создано подразделение, отвечающее за ведение НСИ, чтобы избежать повторения неприятной ситуации. 75

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

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

Повышение гибкости для поддержки новых бизнес стратегий Устранение фрагментации и децентрализации ведения НСИ и МД позволяет предоставлять информацию как сервис. Это означает, что любая ИТ система, соблюдая установленные протоколы обмена и права доступа, может обращаться к системе корпоративного ведения НСИ и МД и получать необходимые данные. Сервис ориентированный подход позволят гибко выстраивать информационные сервисы в соответствии с изменяющимися бизнес – процессами, обеспечивая таким образом своевременную реакцию ИТ служб и систем в условиях изменяющихся требований.

Архитектурные принципы системы ведения НСИ и МД В работе [3] приведены основные архитектурные принципы построения системы управления мастер-данными. Кратко перечислим их: •

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

•

Система ведения мастер-данных должна быть единым корпоративных источником мастер-данных, поддерживать целостность данных и управлять распространением мастер-данных по всем корпоративным приложениям.

•

Система ведения мастер-данных должна гибко реагировать на изменения модели мастер-данных и требований законодательства и бизнеса, а также поддерживать добавление новых мастер-данных. 76

•

Система ведения мастер-данных должна отвечать требованиям безопасности и защиты данных.

•

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

На основании рассмотренных практических примеров мы можем расширить список архитектурных принципов дополнительными требованиями к системе ведения НСИ и МД: •

Система ведения мастер-данных должна строиться на основании единой модели НСИ и МД. Без единой модели данных невозможны создание и эксплуатация системы ведения мастер-данных в качестве единого корпоративного источника мастер-данных.

•

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

•

Должна быть обеспечена возможность отождествления объектов НСИ и МД и устранение их дубликатов. Без отождествления невозможно построение единой модели НСИ и МД и затруднительно выявление дубликатов, которые ведут дублированию «точек входа», к росту расходов на обработку объектов и на поддержание жизненных циклов объектов.

•

Метаданные НСИ и МД должны быть согласованы. Рассогласование приводит к тому, что даже если удается создать единую модель НСИ и МД, на самом деле эта модель не является качественной из-за того, что разные объекты могут в действительности оказаться дубликатами из-за разных описаний и представлений.

•

Должна поддерживаться ссылочная целостность и синхронизация модели НСИ и МД. В зависимости от выбранной архитектуры модель НСИ и МД может содержать как объекты, так и ссылки на них. То есть, отсутствие синхронизации и поддержка целостности необходимы для создания единой модели НСИ и МД.

•

Должен поддерживаться согласованный жизненный цикл объекта НСИ и МД. Объект, находящийся в разных ИТ системах на разных этапах своего жизненного цикла (например, создан, согласован, активен, заморожен, архивный, уничтожен), по сути разрушает единую модель НСИ и МД. Жизненный цикл объектов НСИ и МД должен быть выражен в виде набора процедур, методологических и регламентных документов, утвержденных в организации.

•

Необходима поддержка выработки правил очистки НСИ и МД и их коррекции. Тем самым обеспечиваются актуальность единой модели НСИ и МД, которая может нарушаться из-за изменяющихся требований бизнеса и законодательства.

•

Необходимо создание специализированного репозитория НСИ и МД вместо использование существующих информационных систем в качестве «мастерсистемы» НСИ и МД. Результатом является обеспечение гибкости и производительности системы ведения НСИ и МД, безопасности и защиты данных, бесперебойность ее работы.

•

Система ведения НСИ и МД должна учитывать неготовность ИТ систем к интеграции НСИ и МД. Интеграция систем требует встречных действий: существующие системы должны быть доработаны с учетом требований централизованного ведения НСИ и МД. 77

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

Литература 1. Асадуллаев С., «Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных», 09.07.2009, http://www.ibm.com/developerworks/ru/library/r-nci/index.html 2. Колесов А., «Технология управления НСИ корпоративного уровня», PC Week/RE, № 18(480) 24 - 30 Мая 2005 г., http://www.pcweek.ru/themes/detail.php?ID=70392 3. Oberhofer M., Dreibelbis A., «An introduction to the Master Data Management Reference Architecture», 24.04.2008, http://www.ibm.com/developerworks/data/library/techarticle/dm0804oberhofer/

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

Управление качеством данных с помощью 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. Потоки работ и обеспечение качества

Публикация метаданных Доступ на чтение

Анализ воздействия изменений Назначение стюардов

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

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

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

Владение

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

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

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

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

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

•

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

•

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

•

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

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

устранения

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

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

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

Группы работ, относящиеся к одной роли, заключены в пунктирный прямоугольник. Взаимодействия между ролями отнесены к потокам работ, направление которых отмечены дугами со стрелками. Рассмотрим более подробно инструменты и работы, выполняемые ролями. Руководитель проекта, ответственный за управление процессом обработки изменений, с помощью 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. Стадия выживания обеспечивает сохранение наилучших из имеющихся данных и их правильную подготовку для передачи в целевую систему. Производится с целью получения наилучшего представления взаимосвязанной информации. 86

Таким образом семейство продуктов 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 30.09.2008. http://www.ibm.com/developerworks/ru/library/sabir/meta/index.html

Server”,

управления метаданными IBM 8. Асадуллаев С. “Пошаговое внедрение средств 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.informationmanagement.com/specialreports/2009_157/business_intelligence_bi_data_quality_governanc e_decision_making-10015888-1.html

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

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

Система сбора и анализа первичных данных - I Постановка задачи, сбор и хранение данных Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A 17.02.2011 http://www.ibm.com/developerworks/ru/library/sabir/warehouse-1/index.html

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

Введение Компания-дистрибутор закупает товар и распределяет его по своим региональным потребителям. Для планирования новых закупок необходима информация с мест об остатках товара. Данные вводятся на местах вручную. Это приводит к тому, что, несмотря на обучения, распоряжения, напоминания, данные вводятся не так, как ожидалось. В результате, в центральном офисе компании целый отдел выверяет данные, перезваниваясь с региональными представителями. Транспортная компания располагает обширным парком грузовых перевозочных средств. Несмотря на наличие автоматической диагностики, данные о техническом состоянии подвижного состава ведутся вручную на бумажных бланках и затем заносятся в компьютер. За время между обнаружением неисправности и занесением с бумажного носителя в информационную систему возможна случайная или намеренная подача неисправного транспортного средства под погрузку. Штрафы, предусмотренные за подобную ситуацию, ведут к убыткам транспортной компании и обеспечивают фирму отгрузчик прибылью, заработанной не вполне корректным образом. Федеральное ведомство на регулярной основе собирает отчетность из регионов. Специалисты на местах прошли обучение, и используют полученные знания для того, чтобы предоставлять в центр данные так, чтобы регион выглядел достойно. Реальная картина, естественно, размывается, и центр оперирует недостоверной информацией. Список подобных примеров может быть продолжен. Например, злоумышленник может угнать автомобиль в одном регионе, совершить ограбление во втором, незаконно приобрести оружие в третьем, и его преступления могут быть не объединены в одно дело из-за мелких ошибок при регистрации инцидентов. Или предприниматель может проживать в одном регионе, открыть предприятие в другом, а налоги платить в третьем. Эти примеры объединяют одинаковые функциональные требования: •

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

•

необходима проверка данных на рабочем месте до отправки в центр.

•

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

•

для выявления закономерностей и принятия управленческих решений необходимо выполнение аналитических вычислений на основе собранной статистики;

•

для оценки состояния дел в регионах необходимо формирование управленческой отчетности. 89

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

Требования к системе Рассмотрим наиболее общие требования, характерные для подобных систем. Безусловно, такая постановка задачи является несколько искусственной, но в то же время позволяет избавиться от подробностей, характерных для реальных систем, но не являющихся ключевыми для типовой задачи сбора, хранения и анализа первичных данных. Информационные системы, эксплуатируемые в регионах, являются внешними по отношению к разрабатываемой системе «Сбор и анализ первичных данных» и не взаимодействуют с ней. Требуемая информация должна вводиться вручную с помощью экранных форм. Формы должны максимально точно отражать существующие и утвержденные бумажные формы сбора данных. Должна быть возможность проверки ошибок заполнения до отсылки формы. Заполненная форма из региона всегда отправляется в центральный офис. В случае выявления ошибки в заполнении, форма отправляется повторно целиком. Заполненную форму не требуется сохранять целиком для аудита или следования требованиям законодательства. Сохраняются только данные, содержащиеся в полях формы. Поэтому нет необходимости отправлять в центр всю форму, можно отсылать только извлеченные из нее данные. Внутренними потребителями управленческой отчетности являются сотрудники и руководители компании. Управленческая отчетность предоставляется в электронной и бумажной формах. Внешними потребителями отчетности являются сотрудники и руководство вышестоящих и смежных организаций и ведомств. Отчетность для внешних организаций предоставляется в печатной форме на бумажных носителях. Количество пользователей в каждом регионе ограничено одним пользователем (оператор ввода данных) в каждый момент времени (то есть, для функционирования системы в каждом регионе достаточно одно рабочее место). Количество регионов примем равным 1000. Количество пользователей системы в центральном офисе компании на текущий момент до 100 аналитиков. Количество утвержденных входных форм: 10 ежедневных форм по 100 полей каждая. Для оценки потоков данных можно ограничиться следующими приблизительными значениями. Как показывает опыт, в среднем на одно поле приходится 3 – 5 Кбайт форм. Таким образом, размер одной формы можно оценить в 300 - 500 Кбайт, а ежедневный поток с одного рабочего места составляет 3 - 5 Мбайт/сут. Учитывая, что формы заполняются вручную в течение рабочего дня, минимально необходимая пропускная способность канала связи должна обеспечивать передачу примерно 1 формы в час, то есть, около 1 кбит/с. Суммарный ежедневный поток от регионов составляет 3 – 5 Гбайт/сут. Пиковый часовой объем передачи данных в случае недостаточной полосы пропускания может быть снижен за счет разности в часовых поясах регионов и утвержденного графика передачи данных. 90

Длительность хранения данных для оперативного доступа составляет 5 лет, после чего данные переносятся в архив. Продолжительность хранения информации в архивах 50 лет. Необходимо предусмотреть возможность резервного копирования и восстановления данных (backup – restore). Инфраструктура передачи данных (активное и пассивное сетевое оборудование, коммуникационные линии и каналы) находится за рамками проекта. Предлагаемое решение должны быть расширяемым и масштабируемым. Например, в будущем необходимо предусмотреть интеграцию системы «Сбор и анализ первичных данных» с системой документооборота.

Задачи проекта В процессе выполнения проекта должны быть решены следующие задачи: • • • • • • • • •

Разработка экранных форм для утвержденных форм Разработка экранных форм для новых форм Разработка средств хранения детализированных показателей Разработка аналитических средств Разработка средств отчетности и визуализации Обеспечение информационной безопасности Резервное копирование данных Архивирование информации Журналирование событий в системе

Разработка экранных форм для утвержденных форм Должны быть разработаны экранные формы, соответствующие утвержденным формам сбора статистических показателей. Должны быть предоставлены возможности ввода форм как в автономном (offline), так и в неавтономном (online) режимах. Основной режим ввода данных – неавтономный (online).

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

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

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

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

собранной статистики должны

•

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

•

сценарные и прогнозные расчеты.

Например,

расчет

Разработка средств отчетности и визуализации Средства отчетности и визуализации должны обеспечивать • • • •

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

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

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

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

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

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

ввода

информации

для

Достоверность информации должна быть не хуже качества собранных данных.

Архитектуры системы сбора, хранения и анализа данных В данной работе мы рассматриваем типовую задачу без учета специфических требований различных проектов. Поэтому предлагаемая архитектура основана на максимально простой конфигурации программного обеспечения. Сбор данных осуществляется с помощью IBM Lotus Forms. Хранение, анализ и предоставление отчетов реализованы на IBM InfoSphere Warehouse. Для управления корпоративной эффективностью и интерпретации данных необходимо включение в архитектуру продукта Cognos. Разделение подсистем на ввод данных, их сбор, хранение и анализ позволяет строить различные архитектуры в зависимости от потребностей задачи и требований к корпоративной инфраструктуре. На Рис.1. представлена централизованная архитектура системы сбора, хранения и анализа данных, которая предполагает, что ввод данных может осуществляться удаленно, а все серверы сбора данных Lotus Forms, хранения данных InfoSphere Warehouse и анализа и интерпретации данных Cognos установлены в едином центре обработки данных. Аналитики могут работать как локально, так и дистанционно, благодаря тому, что Cognos предоставляет Веб-интерфейс для подготовки и выполнения аналитических расчетов. В случаях, когда существует потребность в заполнении множества региональных форм, возможно создание распределенной архитектуры серверов Lotus Forms. В этом случае обработка форм осуществляется на региональном уровне, а данные пересылаются в центральный офис, где расположены серверы хранилища данных. Сочетание больших объемов региональных данных и плохих каналов связи может потребовать решения, при котором децентрализована не только обработка форм, но и системы хранения данных. Большой объеме произвольных (ad hoc) запросов при выполнении аналитических работ может потребовать создания распределенной инфраструктуры серверов Cognos. В этом случае данные из централизованного хранилища могут заблаговременно передаваться в региональные центры, где размещены серверы Cognos. Такая архитектура обеспечивает приемлемое время отклика и высокую производительность выполнения аналитических работ на местах, даже при отсутствии высокоскоростных каналов связи. Более подробно различные варианты архитектуры системы сбора, хранения и анализа данных будет рассмотрена в отдельной статье. Другим преимуществом предлагаемого модульного построения системы является возможность расширения ее функциональности. Поскольку все модули взаимодействуют по стандартным общепринятым протоколам, возможно подключение систем документооборота, ведения метаданных и НСИ, корпоративного планирования ресурсов, а также различных аналитических и статистических пакетов. 93

Рис.1. Централизованная архитектура системы сбора, хранения и анализа данных

Сбор данных Lotus Forms - это набор продуктов, который позволяет организациям использовать электронные формы для ручного ввода данных и передавать собранные данные в другие системы [2]. Сервер приложений Lotus Forms может быть в дальнейшем интегрирован с репозиториями данных (например, IBM DB2, Oracle, MS SQL Server), различными системами документооборота и с репозиториями документов (например, IBM File Net). Архитектура сбора первичных данных на основе Lotus Forms представлена на Рис. 2.

Рис. 2. Сбор первичных данных на основе Lotus Forms Разработчик форм, используя продукт Lotus Forms Designer, готовит формы для ввода данных. Формы сохраняются в репозитории форм в формате XFDL [3, 4], который является утвержденным стандартом W3C. Разработчик приложений разрабатывает логику приложений Forms, сервлеты Webform Server Servlet и картирование для Transformation Extender (TX), который ставит в соответствие поля форм и значения в базе данных. Транслятор переводит формы из формата XFDL на язык HTML и JavaScript для пользователей, использующих тонкий клиент (браузер). 95

Пользователи, у которых установлен Lotus Form Viewer (толстый клиент) могут работать с формами в формате XFDL, минуя трансляцию на HTML. Пользователи в регионах вводят данные с помощью Lotus Form Viewer или браузера. Данные могут проходить несколько этапов верификации: •

на компьютере пользователя во время подготовки формы с использованием логики встроенной в форму

•

на сервере Lotus Forms с помощью логики приложений

•

при загрузке данных в базу данных.

Данные передаются в базу данных InfoSphere Warehouse по протоколам CLI, ODBC, JDBC.

Хранение данных В состав IBM InfoSphere Warehouse Enterprise Edition [4,5] входят следующие продукты: •

InfoSphere Warehouse Design Studio, который включает IBM Data Server Developer Workbench - подмножество компонент IBM Rational Data Architect.

•

InfoSphere Warehouse SQL Warehousing Tool

•

InfoSphere Warehouse Administration Console, являющийся частью Integrated Solutions Console.

•

DB2 Enterprise Server Edition для Linux, UNIX и Windows

•

InfoSphere Warehouse Cubing Services

•

DB2 Query Patroller

•

InfoSphere Warehouse Intelligent Miner

•

IBM Alphablox и сопутствующая документация

•

WebSphere Application Server

Архитектура хранения данных в IBM InfoSphere Warehouse представлена на Рис. 3. Design Studio предоставляет общую среду проектирования для создания физических моделей, кубов OLAP и моделей интеллектуального анализа данных, проектирования потоков данных и управляющих потоков SQL, а также для аналитических приложений Alphablox Blox Builder. Design Studio разработан на платформе Eclipse. Разработчик приложений с помощью InfoSphere Warehouse Design Studio разрабатывает и размещает на сервере приложения, обеспечивающие обработку данных в соответствии с требуемой бизнес - логикой. The SQL Warehousing Tool (SQW) – это графический инструмент, который, заменяя ручное кодирование SQL, генерирует SQL код для поддержки и администрирования хранилища данных. На основе визуальных потоков операторов, смоделированных в Design Studio, SQW автоматически создает SQL код, специфичный для DB2. Интеграция SQW с IBM WebSphere DataStage расширяет возможности создания аналитических систем на базе DB2. В данном проекте единственным источником данных являются формы, заполняемые по строгим правилам, поэтому на данном этапе нет необходимости в средствах ETL выборки, преобразования и загрузки данных (например, DataStage). Однако, по мере развития проекта, ожидается подключение других источников. Возможность использования

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

Рис. 3. Хранение данных в IBM InfoSphere Warehouse Администратор использует Administration Console, которая является приложением WebSphere, для размещения и управления приложениями, созданными в Design Studio. Administration Console позволяет: •

создавать и управлять ресурсами базы данных, просматривать журналы и управлять процессами SQW.

•

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

•

Управлять сервисами кубов, импортировать и экспортировать кубы и их модели, а также исполнять OLAP Metadata Optimization Advisor.

•

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

DB2, IBM Alphablox, и WebSphere Application Server располагают собственными средствами администрирования, но оно может быть исполнено из той же Integrated Solutions Console. Администратор использует DB2 Query Patroller для динамического управления потоками запросов к базе данных DB2. Query Patroller позволяет регулировать нагрузку на базу данных так, что короткие запросы, или запросы с высоким приоритетом, будут исполняться в первую очередь, обеспечивая эффективное использование ресурсов. Кроме 97

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

Заключение Предложенное решение является масштабируемым и функционально расширяемым. В дальнейшем возможно подключение различных систем документооборота, корпоративного планирования, систем управления метаданными и НСИ. Система сбора и анализа первичных данных может быть легко интегрирована в существующую корпоративную ИТ инфраструктуру. В других условиях она может стать первым этапом реализации корпоративной системы сбора, хранения и анализа данных. Варианты решений для анализа данных с помощью средств IBM InfoSphere Warehouse и IBM Cognos BI будет выполнен во второй части статьи. Автор благодарит М.Баринштейна, В.Иванова, М.Озерову, Д.Савустьяна, А.Сона и Е.Фищукову за полезные обсуждения.

Литература 1. Асадуллаев C. “Система сбора и анализа первичных данных – II. Анализ первичных данных”, 2011, developerWorks 2. IBM Forms documentation, https://www.ibm.com/developerworks/lotus/documentation/forms/ 3. Boyer J., Bray T., Gordon M. “Extensible Forms Description Language (XFDL) 4.0”. 1998, http://www.w3.org/TR/1998/NOTE-XFDL-19980902 4. IBM, “XFDL 8 Specification”, 2010, http://www10.lotus.com/ldd/lfwiki.nsf/xpViewCategories.xsp?lookupName=XFDL%208%20Specificati on 5. IBM, “InfoSphere Warehouse overview 9.7”, 2010, http://publib.boulder.ibm.com/infocenter/idm/v2r2/index.jsp?topic=/com.ibm.isw.release.doc /helpindex_isw.html 6. IBM, “IBM DB2 Database for Linux, UNIX, and Windows Information Center”, 2011, http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.do c/welcome.html

Система сбора и анализа первичных данных - II Анализ первичных данных Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A 17.02.2011 http://www.ibm.com/developerworks/ru/library/sabir/warehouse-2/index.html

Резюме В первой части статьи [1] рассмотрено типовое решение для системы сбора, хранения и анализа первичных данных ручного ввода на основе IBM Forms для ручного ввода форм и IBM InfoSphere Warehouse для хранения данных. В данной работе рассмотрены варианты решений для анализа собранных данных с использованием аналитических средств IBM InfoSphere Warehouse и IBM Cognos. Предлагаемый подход может быть использован в качестве основы разнообразных решений для разных отраслей и предприятий.

Анализ данных средствами IBM InfoSphere Warehouse Реализация OLAP на основе Cubing Services и Alphablox Для обеспечения прямого доступа к данным из InfoSphere Warehouse используются IBM Alphablox и компоненты Cubing Services, которые включают в себя средства моделирования метаданных OLAP кубов, оптимизатор материализованных таблиц запросов (materialized query tables, MQT) и сервер кубов для доступа к многомерным данным (Рис. 1).

Рис. 1. Реализация OLAP на основе Cubing Services и Alphablox 99

Благодаря полной интеграции компонентов Cubing Services с пользовательским интерфейсом InfoSphere Warehouse, проектирование выполняется с помощью Design Studio, а администрирование и поддержка осуществляется через Administration Console. Сервер кубов Cubing Services обрабатывает многомерные запросы, выраженные на языке запросов MDX и выдает результаты многомерных запросов. В ответ на MDX запросы сервер кубов извлекает данные из DB2 посредством запросов SQL. Материализованные таблицы запросов MQT используются оптимизатором DB2, который переписывает входящие SQL запросы и направляет их к соответствующей MQT для обеспечения высокой производительности исполнения запросов. Использование IBM Alphablox обеспечивает быстрое создание аналитических Вебприложений, которые удовлетворяют требованиям корпоративной инфраструктуры и доступны как в интранет - сети, так и за корпоративным межсетевым экраном. Приложения Alphablox позволяют проводить многомерный анализ данных в реальном времени, используя в качестве клиента обычный браузер. Приложения Alphablox могут работать с данными из множества источников, в том числе, DB2 и Cubing Services, создавать структурированные отчеты и предоставлять данные в требуемом виде с помощью фильтров и средств детализации данных (drill-down). Аналитические приложения Alphablox направлены на повышение качества принятия решений и позволяют оптимизировать выполнение работ в области финансовой отчетности и аналитики, планирования, оперативного анализа, отчетности и анализа работ, анализа производительности и ключевых показателей эффективности (KPI).

Интеллектуальный анализ (data mining) данных и текста Алгоритмы интеллектуального анализа данных, встроенные в InfoSphere Warehouse, используются для понимания поведения клиентов, или хозяйствующих субъектов. Средства выявления скрытых взаимосвязей данных (data discovery) позволяют профилировать данные, просматривать содержимое таблиц и визуализировать коррелированные статистики для выявления данных, пригодных для анализа. InfoSphere Warehouse содержит следующие средства интеллектуального анализа: • • • • • •

Miningblox Intelligent Miner Easy Mining Intelligent Miner Modeling Intelligent Miner Scoring Intelligent Miner Visualization анализ неструктурированного текста

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

Выбор данных для анализа

•

Начало анализа и отслеживание его продвижения

•

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

•

Выбор, управление или контроль заданий интеллектуального анализа

Библиотека тегов Miningblox обеспечивает теги для каждого шага и предназначена для выполнения интеллектуального анализа с использованием функций Alphablox. В этой конфигурации сервер приложений J2EE включает приложения Miningblox, Alphablox и 100

библиотеку тегов Miningblox, приложения хранилища данных, а также консоль администрирования Administration console (Рис. 2). Веб приложения Miningblox состоят из JSP (Java Server Pages) страниц, которые используют Alphablox и JSP библиотеку тегов Miningblox. JSP-страницы, вызывающие функции Alphablox, компилируются во время исполнения на сервере приложений. Alphablox управляет запросами, и Веб сервер возвращает динамическое содержание. Приложение хранилища данных содержит управляющие потоки, которые вызываются Веб приложением Miningblox. Управляющие потоки содержат потоки данных и потоки интеллектуального анализа. База данных DB2 содержит данные, анализируемые потоками интеллектуального анализа, и его результаты в виде моделей данных или результирующих таблиц.

Рис. 2. Реализация интеллектуального анализа на основе MiningBlox и Alphablox Консоль администрирования Administration Console может быть использована для размещения и администрирования приложений хранилища данных, относящихся к приложениям Miningblox. Design Studio применяется для визуального проектирования потоков операторов интеллектуального анализа данных, или текста, операторов предобработки и текстовых операторов. Сгенерированный SQL запрос может быть встроен в приложение Alphablox или иное приложение для вызова потока интеллектуального анализа.

101

Интеллектуальный анализ данных на основе Intelligent Miner Для решения задач интеллектуального анализа данных и текста необходима разработка приложений с использованием специализированного прикладного интерфейса SQL API, который состоит из двух уровней с разной степенью детализации и абстракции. •

прикладной интерфейс задач Easy Mining является проблемно-ориентированным и используется для выполнения базовых задач интеллектуального анализа;

•

прикладной интерфейс IM Scoring / Modeling SQL/MM API соответствует стандарту ISO/IEC 13249-6:Data Mining и позволяет создавать приложения интеллектуального анализа под конкретные индивидуальные требования пользователя. Этот интерфейс может быть использован через скрипты SQL, или из любого JDBC, CLI, ODBC, или SQLJ приложения.

Процедуры Easy Mining обеспечивают базовую функциональность типичных задач интеллектуального анализа. Для этого пользователь должен обладать знаниями о своей предметной области и не обязан глубоко разбираться в тонкостях интеллектуального анализа. IM Scoring и IM Modeling представляют собой набор инструментальных средств разработки программ (software development kit, SDK). Они являются расширениями DB2 и включают прикладной программный интерфейс языка SQL API, который позволяет вызывать функции интеллектуального анализа из приложений. С помощью средств моделирования IM Modeling можно использовать следующие функции для разработки аналитических моделей PMML (Predictive Model Markup Language): ассоциативные правила, правила последовательностей, кластерные модели, регрессионные модели, классификация. Созданные PMML-модели могут быть использованы в модулях IM Visualization или IM Scoring. Средство оценивания IM Scoring позволяет прикладным программам применять PMMLмодели к большим базам данных, их подмножеству, или к отдельным строкам. IM Scoring может работать со следующими PMML моделями: ассоциативные правила, правила последовательностей, кластерные модели, регрессионные модели, классификация, наивнобайесовский подход, нейронные сети, дерево решений. Модели прогнозирования, созданные с помощью Intelligent Miner for Data, не являются частью PMML. Эти модели могут быть экспортированы из IM for Data в формате XML и использованы в IM Scoring. Результаты моделирования данных (ассоциации, последовательности, классификации, кластеризации и регрессии) могут быть просмотрены с помощью готовых Java средств визуализации IM Visualization. Для представления результатов моделирования эти визуализаторы могут вызываться приложениями, или как апплеты браузера. Инструмент Design Studio содержит интегрированные в среду Eclipse редакторы и визуальные средства разработки приложений интеллектуального анализа. Разработчик приложений может визуально моделировать задачи интеллектуального анализа и генерировать SQL код для включения функциональности Intelligent Miner SQL в аналитические приложения. Для создания прототипов можно использовать расширение табличного процессора Excel, что позволяет подтвердить правильность концепции, избегая сложностей SQL API. Администраторы через Веб-интерфейс административной консоли могут настраивать базу данных для интеллектуального анализа, администрировать модели интеллектуального анализа данных, оптимизировать производительность выполнения аналитических запросов. 102

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

Автоматическая классификация документов по группам подобных документов (кластеризация, или неуправляемая классификация)

•

Автоматическая классификация документов по предопределенным категориям (управляемая классификация)

•

Извлечение структурированных данных из неструктурированного текста.

Функции анализа текста в InfoSphere Warehouse нацелены на извлечение данных, которое создает структурные данные для анализа вместе с иной структурированной информацией с помощью таких инструментов, как средства многомерного или интеллектуального анализа и подготовки отчетов. Для анализа текстов в InfoSphere Warehouse используется программное обеспечение на основе архитектуры управления неструктурированными данными UIMA (Unstructured Information Management Architecture) [2], которая является открытой, индустриальноориентированной, масштабируемой и расширяемой платформой для создания интегрирования и развертывания решений анализа текста. Функции анализа текста InfoSphere Warehouse позволяют выполнять следующие работы: •

исследовать таблицы с текстовыми столбцами;

•

извлекать данные с применением регулярных выражений, например, телефонные номера, адреса электронной почты, идентификационные номера налогоплательщиков (ИНН), или единые указатели ресурсов (URL);

•

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

•

извлекать данные с применением UIMA совместимых компонентов.

Разработка приложений интеллектуального анализа данных Можно выбрать один из подходов к разработке приложений в зависимости от сложности задачи и от опыта, предпочтений и навыков специалиста,: •

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

•

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

•

использовать процедуры Easy Mining для базовой функциональности типичных задач интеллектуального анализа.

•

использовать генератор скриптов командной строки idmmkSQL в качестве отправной точки для создания операторов оценивания (Scoring).

•

использовать мощный низкоуровневый прикладной интерфейс SQL/MM API из SQL скриптов или из любого приложения JDBC, CLI, ODBC, или SQLJ.

103

На Рис.3 представлен типичный сценарий использования Intelligent Miner для выполнения задач интеллектуального анализа данных. Разработчик приложений интегрирует SQL функциональность Intelligent Miner в прикладные программы с помощью инструментальных средств разработки Design Studio. Аналитик применяет средства интеллектуального анализа данных из прикладных программ.

Рис. 3. Сценарий использования Intelligent Miner

Анализ данных средствами IBM Cognos Business Intelligence Предлагаемый вариант (Рис. 4) основан на предыдущей архитектуре с расширением аналитической функциональности с помощью продукта IBM Cognos 10 Business Intelligence [3]. IBM Cognos 10 Business Intelligence (BI) - это интегрированный программный комплекс для управления корпоративной эффективностью и предназначенный для помощи в интерпретации данных, возникающих в процессе деятельности организации. Cognos 10 BI позволяет построить графики, сравнить план и факт, создать различные типы регламентных отчетов, встроить отчеты в удобный портал и создать персонализированные панели управления (dashboard). Любой сотрудник организации может использовать IBM Cognos 10 BI для создания бизнес - отчетов, анализа данных и мониторинга событий и метрик с целью выработки эффективных бизнес – решений.

104

Рис. 4. Архитектура решения на основе Lotus Forms, InfoSphere Warehouse и Cognos BI 105

Cognos 10 BI включает в себя следующие компоненты: •

Cognos Connection – публикация, управление и просмотр контента.

•

Cognos Administration console – просмотр, организация и диспетчеризация контента, администрирование и защита данных

•

Cognos Business Insight – интерактивные информационные панели

•

Cognos Business Insight Advanced - простая отчетность и исследование данных

•

Cognos Query Studio – произвольные запросы

•

Cognos Report Studio – управляемые отчеты

•

Cognos Event Studio – управление событиями и оповещениями

•

Cognos Metric Studio – метрики и система сбалансированных показателей

•

Cognos Analysis Studio – анализ состояния бизнеса

•

Cognos for Microsoft Office – работа с данными Cognos BI в Microsoft Office

•

Framework Manager - управление бизнес метаданными для подключения к кубу.

•

Metric Designer – извлечение данных (выписок).

•

Transformer - моделирование многомерных кубов данных PowerCubes

•

Map Manager - импорт карт и обновление меток

•

Cognos Software Development Kit – разработка приложений Cognos BI

Cognos Connection - это портал, который обеспечивает единую точку доступа ко всем корпоративным данным, доступным в Cognos 10 BI. Пользователи используют портал для публикации, поиска, организации и просмотра данных. При наличии соответствующих прав пользователи могут работать через портал с различными приложениями, а также управлять содержанием (контентом) портала, включая управления расписаниями подготовки и распространения отчетов. Cognos Administration console совместно с модулем Cognos Connection предоставляет системным администраторам возможности администрирования серверов Cognos, настройки производительности и управления правами доступа пользователей. Cognos Business Insight позволяет пользователям создавать сложные интерактивные панели управления (dashboard) с использование данных Cognos и внешних источников, таких, как TM1 Websheets и CubeViews. Пользователь может открывать персональные панели, управлять отчетами и пересылать панели по электронной почте, а также участвовать в коллективном принятии решений. Cognos Business Insight Advanced позволяет пользователям самостоятельно создавать простые отчеты и исследовать данные из внешних и внутренних источников данных, как реляционных, так и многомерных. Аналитик, открыв персональную панель управления и желая выполнить более подробное исследование данных, может перейти в Business Insight Advanced, где есть возможность добавить новые измерения, условное форматирование и сложные вычисления. Пользователь может вызвать Business Insight Advanced напрямую из портала Cognos Connection. Query Studio предоставляет интерфейс для создания простых запросов и отчетов Cognos 10 BI. Пользователь без специальной подготовки может использовать Query Studio для создания отчетов, отвечающих на простые бизнес вопросы. Затратив минимальные усилия, он может изменять расположение полей в отчете, фильтровать и сортировать данные, добавлять форматирование и создавать графики. 106

Report Studio является инструментом, используемым профессиональными авторами отчетов для создания сложных, многостраничных отчетов с составными запросами с применением нескольких баз данных (реляционных или многомерных). С помощью Report Studio можно создать любые отчеты, которые требуются организации, такие как счет - фактуры, сметы, или недельные отчеты о деятельности любой сложности. Event Studio - это инструмент управления событиями в IBM Cognos 10. Он позволяет напоминать о событиях по мере их приближения для принятия своевременных и эффективных решений. Event Studio можно использовать для создания агентов, отслеживающих изменения различных состояний, финансовых и производственных показателей компании и ключевых клиентов для выявления любых важных событий. Когда событие происходит, агент может отправить сообщение по электронной почте, опубликовать информацию на портале, или подготовить отчет. Metric Studio позволяет пользователям создавать и использовать сбалансированную систему показателей для отслеживания и анализа ключевых показателей эффективности (KPI) деятельности организации. Возможно использование стандартной или собственной сбалансированной системы показателей, если она уже внедрена в компании. Metric Studio переводит стратегию организации в измеряемые цели, которые позволяют каждому сотруднику соотнести свои действия со стратегическим планом компании. Среда сбалансированной системы показателей выявляет как успешные направления деятельности компании, так и те, что нуждаются в улучшении. Она отслеживает успехи в достижении поставленных целей и показывает текущее состояние бизнеса. Поэтому все сотрудники и руководители предприятия могут принимать требуемые решения и планировать свою работу. Analysis Studio является инструментом для исследования, анализа и сравнения многомерных данных и обеспечивает аналитическую обработку в реальном времени (OLAP) различных источников многомерных данных. Результаты анализа доступны в Report Studio для создания отчетов профессионального качества. Руководители и аналитики используют Analysis Studio для быстрого анализа причин происшедших событий и необходимых действий для улучшения производительности. Анализ позволяет пользователям выявить неочевидные, но влияющие на бизнес закономерности и отклонения в больших объемах данных. Другие виды отчетов не дают такой возможности. Cognos for Microsoft Office позволяет работать с данными отчетов Cognos прямо из программ Microsoft Office и предлагает два вида клиентского программного обеспечения: 1. «Умный клиент» не требует установки, администрирования и обновляется автоматически. 2. Клиентское ПО - надстройка COM требует установки. Обновления выполняются путем переустановки ПО. Возможна работа с отчетами, созданными в Query Studio, Analysis Studio, или Report Studio, причем пользователь получает полный доступ к содержанию отчета, включая данные, метаданные, колонтитулы и рисунки. Framework Manager является средством моделирования, которое предназначено для создания и управления бизнес метаданными для использования в средствах анализа и подготовки отчетов Cognos BI. Метаданные обеспечивают единое понимание данных из различных источников. OLAP кубы содержат метаданные для бизнес анализа и подготовки отчетов. Поскольку метаданные кубов могут изменяться, Framework Manager моделирует минимальное количество информации, требующейся для подключения к кубу.

107

Metric Designer – это инструмент моделирования для извлечения данных (выписок). Выписки используются для картирования и переноса данных в сбалансированную систему показателей из существующих источников метаданных, таких, как файлы Framework Manager и Impromptu Query Definition. Как правило, модели данных оптимизированы для хранения, а не подготовки отчетов. Поэтому разработчик моделей данных использует Framework Manager для создания моделей данных, оптимизированных под нужды бизнес пользователей. Например, модель может определять бизнес правила, описания данных и их связи, размерности и иерархии с точки зрения бизнеса. Transformer является средством моделирования многомерных кубов данных PowerCubes для бизнес представление информации в Cognos BI. После добавления всех необходимых метаданных из различных источников данных, моделирования размерностей, определения измерений и применения фильтров, возможно создание PowerCubes, основанных на этой модели. Эти кубы используются для поддержки OLAP отчетности и анализа. Map Manager позволяет администраторам и специалистам по моделированию импортировать карты и обновлять метки на картах в Report Studio, а также добавлять альтернативные названия стран и городов для создания многоязычных текстов, появляющихся на картах. IBM Cognos Software Development Kit – набор инструментальных средств разработки программ, который предназначен для создания заказных отчетов, управления развертыванием компонент Cognos BI, для обеспечения безопасности портала и его функциональности в соответствии с требованиями пользователей, местного законодательства и существующей ИТ инфраструктуры. В состав Cognos SDK входят кросс - платформенные Веб - сервисы, библиотеки и интерфейсы программирования.

Корпоративное планирование с помощью Cognos TM1 Аналитический инструментарий может быть дополнен средством корпоративного планирования IBM Cognos TM1 [4], которое предоставляет полную, надежную и динамическую среду планирования для своевременной подготовки персонализированных бюджетов и прогнозов. 64-битное OLAP ядро обеспечивает высокую производительность при анализе сложных моделей, больших объемов данных и даже потоковых данных. Поддерживается полный набор требований к корпоративному планированию – от расчета рентабельности, финансовой аналитики и гибкого моделирования до определения вклада каждого подразделения. Возможность создания неограниченного числа индивидуальных сценариев позволяет сотрудникам, группам, подразделениям и компании в целом быстрее реагировать на изменяющиеся условия. Лучшие практики, основанные на факторном планировании и скользящем прогнозе, могут стать частью корпоративного процесса планирования. Средства настройки моделей и доступа к данным позволяют предоставлять данные в знакомых форматах. Управляемая коллективная работа обеспечивает быстрый и автоматизированный сбор результатов от разных систем и подразделений, их сборку в единый корпоративный процесс планирования и предоставление результатов. Интегрированные сбалансированная система показателей и отчетность Cognos BI дают полную картину планирования и определения целей, а также определения степени их достижения и подготовки отчетов. Финансовые и производственные подразделения получают полный контроль над процессами планирования, бюджетирования и прогнозирования. 108

Возможность работать с привычным интерфейсом (Microsoft Excel и клиентское ПО Cognos TM1 Web или Contributor.

Заключение Предложенное решение является масштабируемым и функционально расширяемым. В дальнейшем возможно подключение различных систем документооборота, корпоративного планирования, систем управления метаданными и НСИ. Система сбора и анализа первичных данных может быть легко интегрирована в существующую корпоративную ИТ инфраструктуру. В других условиях она может стать первым этапом реализации корпоративной системы сбора, хранения и анализа данных. Автор благодарит М.Баринштейна, В.Иванова, М.Озерову, Д.Савустьяна, А.Сона и Е.Фищукову за полезные обсуждения.

Глоссарий data mining data discovery drill-down scorecarding dashboard key performance indices scoring OLAP software development kit

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

Литература 1. Асадуллаев C. “Система сбора и анализа первичных данных – I. Постановка задачи, сбор и хранение данных ”, 2011, developerWorks 2. Apache Software Foundations, “Apache UIMA”, 2010, http://uima.apache.org/ 3. IBM, “Cognos Business Intelligence”, 2010, http://publib.boulder.ibm.com/infocenter/cfpm/v10r1m0/index.jsp?topic=/com.ibm.swg.im.c ognos.wig_cr.10.1.0.doc/wig_cr_id111gtstd_c8_bi.html 4. IBM, “Cognos TM1”, 2010, http://www-01.ibm.com/software/data/cognos/products/tm1/

УДК 004.65:004.413:005.8

Хранилища данных: тройная стратегия на практике Сабир Асадуллаев, исполнительный архитектор SWG IBM EE «Программная инженерия», 2011, №4, стр. 26-32 Data Warehousing: Triple Strategy on Practice Sabir Asadullaev, Execitive IT Architect, SWG IBM EE/A “Program Engineering”, 2011, v4, pp 26-33

Резюме На практическом примере системы сбора и анализа первичных данных показано, как тройная стратегия и рекомендованная архитектура корпоративного хранилища данных (КХД) позволяют предоставить более высокое качество информационного аналитического обслуживания при сокращении стоимости и времени разработки КХД. Ключевые слова: Корпоративное хранилище данных, стратегия разработки, архитектура Abstract This paper uses a practical example of a system for collecting and analyzing primary data to show how triple strategy and recommended architecture of enterprise data warehouse (EDW) can provide higher quality of the information analysis service while reducing costs and time of EDW development. Key word: Enterprise data warehouse, development strategy, architecture

Введение Многие успешные компании обнаруживают, что раздельное управление по линиям бизнеса не дает целостной картины положения компании на рынке. Для принятия точных своевременных решений эксперты, аналитики и руководство компании нуждаются в единой, непротиворечивой информации, которую должны предоставлять корпоративные хранилища данных. На практике стоимость и сроки создания корпоративных хранилищ данных оказываются выше ожидаемых. При этом аналитические отчеты зачастую по-прежнему содержат противоречивую информацию. В работе показано, что следование рекомендованным архитектурным решениям, использование апробированной стратегии создания КХД и правильный выбор программных средств способны снизить стоимость разработки КХД и повысить качество его услуг. На основании тройной стратегии, рекомендованной архитектуры, сформулированных принципов и лучших практик построения КХД предложен план управления проектом разработки программного обеспечения корпоративного хранилища данных. Компания IBM предлагает полный набор средств для интеграции данных, метаданных и нормативно-справочной информации (НСИ) на всех этапах жизненного цикла проекта создания КХД. Целью данной статьи является анализ упрощенного решения на основе программного обеспечения IBM Forms, IBM InfoSphere Warehouse и IBM Cognos BI. Решение должно быть масштабируемым и функционально расширяемым, легко интегрируемым в корпоративную ИТ инфраструктуру и способным стать основой для корпоративного хранилища данных.

110

Архитектура системы сбора и анализа первичных данных В работах [1,2] предложено типовое решение для системы сбора, хранения и анализа первичных данных ручного ввода. Напомним основные требования к системе: •

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

•

необходима проверка данных на рабочем месте до отправки в центр;

•

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

Решение должно быть расширяемым и масштабируемым. Например, необходимо предусмотреть последующую интеграцию системы «Сбор и анализ первичных данных» с системой документооборота. На Рис. 1 представлена централизованная архитектура системы сбора, хранения и анализа данных, которая предполагает, что ввод данных может осуществляться удаленно, а все серверы сбора данных IBM Forms [3], хранения данных InfoSphere Warehouse [4] и анализа и интерпретации данных Cognos [5,6] установлены в едином центре обработки данных. Аналитики могут работать как локально, так и дистанционно, благодаря тому, что Cognos предоставляет Веб-интерфейс для подготовки и выполнения аналитических расчетов. Предложенная архитектура была основана на максимально простой конфигурации программного обеспечения для типовой задачи без учета специфических требований различных проектов. Несмотря на очевидные ограничения, предложенный подход может быть использован в качестве основы самых разных решений для различных отраслей и предприятий. Разделение подсистем на ввод данных, их сбор, хранение и анализ позволяет строить различные архитектуры в зависимости от потребностей задачи и требований к корпоративной инфраструктуре. Другим преимуществом предлагаемого модульного построения системы является возможность расширения ее функциональности. Поскольку все модули взаимодействуют по стандартным общепринятым протоколам, возможна интеграция с системами документооборота, ведения метаданных и НСИ, корпоративного планирования ресурсов, а также с различными аналитическими и статистическими пакетами. Система сбора и анализа первичных данных может быть легко включена в существующую корпоративную ИТ инфраструктуру. В других условиях она может стать первым этапом реализации корпоративной системы сбора, хранения и анализа данных. Как можно заметить, рассматриваемая архитектура системы сбора, хранения и анализа данных (Рис. 1) не содержит средств ведения метаданных или НСИ. На первый взгляд, это противоречит предложенной тройной стратегии создания хранилищ данных [7], которая предполагает интеграцию данных, метаданных и НСИ. С другой стороны, не ясно, как решение соотносится с рекомендованной архитектурой хранилищ данных [8], и чем отличается предложенный подход от многочисленных проектов, основная цель которых демонстрация быстрого маленького успеха.

111

Рис. 1. Архитектура решения на основе IBM Forms, InfoSphere Warehouse и Cognos BI

112

Место проектов ведения метаданных и НСИ Задача ввода первичных данных, их сбор, хранение и анализ обладает несколькими особенностями. Прежде всего, первичные данные вводятся вручную в поля утвержденных экранных форм. Поля форм согласованы между собой, как внутри формы, так и между формами. Это означает, что разные сущности имеют разные названия и разные поля. Поэтому заказчик уже на ранних этапах планировал хранение не форм, или отчетов, а показателей, из которых в дальнейшем собираются формы и отчеты. Непротиворечивый набор показателей – это отличный первый шаг к управлению метаданными, даже если это требование не было сформулировано в явном виде. В данных условиях первый этап ведения метаданных не требует использования специфического программного обеспечения и может быть выполнен с помощью карандаша, ластика и ученической тетради. Основная сложность этого этапа – достижение согласия всех экспертов о терминах, сущностях, об их названиях и способах расчета. Иногда пользователям приходится отказываться от привычных, но неоднозначных наименований, и достижение согласия может потребовать значительных усилий и времени. К счастью, эта работа была выполнена заказчиком до обращения к внешним исполнителям проекта. Наименования полей форм ручного ввода, методы их выверки и расчета являются необходимыми бизнес – метаданными. На основе собранных метаданных строится архитектура решения, в том числе, модель хранилища данных, создаются и именуются таблицы в КХД и столбцы в таблицах. Тем самым положено начало формирования технических метаданных. В процессе сопровождения построенной системы неизбежна необходимость внесения изменений. В этот момент разработчики нуждаются в ведении глоссария терминов. Если он не был создан ранее, самое время задуматься о его реализации, поскольку процесс сопровождения системы вынуждает начать централизованное ведение метаданных в явном виде. Данный сценарий подразумевает минимальные накладные расходы на внедрение централизованной системы управления метаданными, поскольку предварительно было создано ядро будущей системы. Это ядро, пусть маленькое и не имеющее достаточной функциональности, обладает важнейшим активом – непротиворечивыми метаданными. Централизованное ведение нормативно-справочной информации должно быть начато одновременно с ведением метаданных. Причина проста – НСИ и метаданные тесно связаны [7], и ведение одного проекта без другого, как правило, не приводит к успеху. Основой для системы ведения НСИ может стать совокупность кодификаторов, справочников, классификаторов, идентификаторов, нормативов и словарей, ведущихся при хранилище данных. Гарантией качества для НСИ в данном случае является проработанность метаданных, что исключает конфликты кодировки данных при условии квалифицированной разработки ХД. Таким образом, систематизация бизнес метаданных на основе полей форм, выполненная на предпроектном этапе, обеспечила возможность беспроблемного создания систем ведения метаданных и НСИ. Это позволило сократить бюджет проекта внедрения системы сбора, хранения и анализа первичных данных. При этом проектная команда отдавала себе отчет, что проекты ведения метаданных и НСИ ведутся неявным образом, требуя на данном этапе только стратегического видения от проектировщиков и аккуратности от разработчиков.

113

Рекомендованная архитектура КХД Рекомендованная архитектура корпоративного хранилища данных, предложенная в работе [8] построена в соответствии со следующими основными принципами. •

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

•

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

•

Сотрудники должны иметь единое понимание данных, то есть, должно быть установлено единое смысловое пространство.

•

Необходимо устранить конфликты в кодировках данных в системах - источниках.

•

Аналитические вычисления должны быть отделены от оперативной обработки данных.

•

Необходимо обеспечить и поддерживать многоуровневую организацию данных

•

Необходимо следовать эволюционному подходу, позволяющему обеспечить непрерывность бизнеса и сохранить инвестиции в ИТ.

•

Информационное наполнение будущего хранилища данных, этапность построения КХД и ввода функциональных моделей в эксплуатацию определяются, в первую очередь, требованиями бизнес - пользователей.

•

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

Архитектура, построенная в соответствии с этими принципами, следует принципам модульного конструирования «непотопляемых отсеков». Разделяя архитектуру на модули, мы одновременно концентрируем в них определенную функциональность (Рис. 2). Средства очистки, преобразования и загрузки данных ETL (Extract, Trasform, Load) обеспечивают полный, надежный, точный сбор информации из источников данных благодаря сосредоточенной в ETL логике сбора, обработки и преобразования данных и взаимодействию с системами ведения метаданных и НСИ. Система ведения метаданных является основным источником информации о данных в КХД. Система ведения метаданных поддерживает актуальность бизнес - метаданных, технических, операционных и проектных метаданных. Система ведения НСИ позволяет устранить конфликты в кодировках исходных данных в системах - источниках. Центральное хранилище данных (ЦХД) несет только нагрузку по надежному защищенному хранению данных. Структура данных в ЦХД оптимизирована исключительно с целью обеспечения эффективного хранения данных. Средства выборки, реструктуризации и доставки данных (SRD) в такой архитектуре являются единственным пользователем ЦХД, беря на себя всю работу по заполнению витрин данных и снижая нагрузку на ЦХД по обслуживанию запросов пользователей. Витрины данных содержат данные в структурах и форматах, оптимальных для решения задач пользователей данной витрины. Таким образом достигается удобная работа пользователей с необходимым объемом данных даже при отсутствии связи с ЦХД, возможность быстрого восстановления содержимого витрин из ЦХД при сбое витрины. 114

Рис. 2. Рекомендованная архитектура КХД

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

Связь архитектуры решения с рекомендованной архитектурой Архитектура решения для системы сбора, хранения и анализа первичных данных на Рис. 3 переведена в термины рекомендованной архитектуры КХД и совмещена с ней. Сбор данных осуществляется с помощью набора продуктов IBM Forms, который использует электронные формы для ручного ввода данных и позволяет передавать собранные данные в другие системы. Сервер приложений IBM Forms может быть в дальнейшем интегрирован с репозиториями структурированных и неструктурированных данных. Единственным источником данных в проекте являются формы, заполняемые по строгим правилам, поэтому на текущем этапе нет необходимости в средствах ETL выборки, преобразования и загрузки данных (например, DataStage). Однако, по мере развития проекта ожидается подключение других источников. Возможность использования средств ETL обеспечивает функциональную расширяемость системы без необходимости ее радикальной переработки. Хранение данных реализовано с помощью IBM InfoSphere Warehouse. Анализ данных может быть выполнен средствами IBM InfoSphere Warehouse и IBM Cognos Business Intelligence (BI). IBM InfoSphere Warehouse предоставляет следующие инструменты анализа данных: реализация аналитической обработки OLAP на основе инструментов Cubing Services и Alphablox, интеллектуальный анализ данных с помощью программных средств Miningblox

115

и Alphablox, интеллектуальный обеспечения Intelligent Miner.

анализ

данных

привлечением

программного

Рис. 3. Рекомендованная архитектура КХД и архитектура системы сбора и анализа первичных данных

Интегрированный программный комплекс для управления корпоративной эффективностью IBM Cognos 10 BI помогает аналитикам интерпретировать данные, возникающие в процессе деятельности компании. Используя IBM Cognos 10 BI, любой сотрудник организации может построить графики, сравнить план и факт, создать различные типы отчетов и встроить их в удобный портал; создать персонализированные панели управления (dashboard), выполнить анализ данных и провести мониторинг событий и метрик с целью выработки эффективных бизнес – решений. Аналитический инструментарий может быть дополнен высокопроизводительным средством корпоративного планирования IBM Cognos TM1, которое предоставляет полную среду планирования для подготовки персонализированных бюджетов и прогнозов. Метаданные, полученные как побочный продукт согласования форм, и НСИ, как результат приведения данных к нормальной форме в реляционной базе данных КХД, являются прототипами будущих корпоративных систем управления метаданными и НСИ (Рис. 4). Первые публикации о необходимости создания систем словарей-справочников появились в середине 80-х годов [9]. В 1995г. была опубликована статья [10], в которой было указано, что для успешной интеграции данных необходимо организовать и поддерживать поток метаданных. Современная практика показывает, что это требование нуждается в уточнении, так как метаданные порождаются на всех этапах создания и эксплуатации информационных систем. Связь между данными, НСИ и метаданными подробно рассмотрена в работе [8], в которой было показано, что НСИ содержит бизнес метаданные и технические метаданные.

116

Рис. 4. Переход к корпоративному ведению метаданных и НСИ

Загрузка данных в КХД не может быть корректно выполнена без метаданных и НСИ, которые явно, или неявно, но интенсивно используются на этом этапе. Очищенные и согласованные данные сохраняются, но метаданные и НСИ, как правило, игнорируются. Создание репозиториев метаданных и НСИ значительно сокращает издержки на реализацию КХД, позволяет перейти от хранения несогласованных форм к хранению непротиворечивых показателей и повышает качество информационного обслуживания бизнес – пользователей [11].

Сравнение предлагаемого и существующих подходов Для того, чтобы ответить на вопрос, в чем отличие предлагаемого подхода от общепринятой практики, рассмотрим типичный пример проекта создания финансовой аналитической системы в банке [12]. Проектная команда исходила из того, что создание корпоративных мастер данных является долгой, сложной и рискованной работой. Поэтому проект был ограничен решением локальной задачи реинжиниринга процессов планирования и прогнозирования, которые должны подготовить почву для создание системы банковской отчетности на основе интеграции всех основных банковских систем с целью использования более детальных данных, согласованных с главной бухгалтерской книгой. Разработка корпоративного хранилища данных в глазах проектной команды была равносильна «большому взрыву», создавшему Вселенную. Проектная команда, избегая решений уровня предприятия, внедрила системы ведения метаданными и НСИ для одной специфической области деятельности. Поэтому репозиторий финансовых данных является узкотематической витриной для финансовой отчетности (Рис. 5). В противоположность этому, корпоративное хранилище данных предоставляет согласованные корпоративные данные для широкого ряда аналитических приложений. Как показывает практика, единую версию данных способно обеспечить только КХД, взаимоувязанное с корпоративными системами ведения НСИ и метаданных. 117

Как видим, основная цель этого проекта - демонстрация быстрого маленького успеха. Многие из нас были поставлены в такую же ситуацию, когда было необходимо срочно продемонстрировать пусть маленькую, но работающую систему. Опытный разработчик понимает, что ему придется последовать совету Брукса [13] и выбросить эту первую версию. Причина заключается в том, что цена переработки созданных приложений и их включения в корпоративную инфраструктуру будет чрезмерно высока из-за отсутствия согласованных метаданных и НСИ.

Рис. 5. Пример реализации существующих подходов

Итоговая архитектура реализации существующих подходов Коротко суммируем итоги выполненного анализа. 1. Существующие подходы фактически внедряют разрозненные прикладные витрины данных. Данные в витринах могут иметь ценность внутри подразделений, но не для компании в целом, из-за невозможности их сведения вследствие разного смысла данных и их кодировки. 2. Распространено убеждение, что создание корпоративного хранилища данных подобно смертельному трюку с непредсказуемыми последствиями, поэтому зачастую выбирается создание локальных витрин без учета развития КХД в целом. 3. Требование мгновенных результатов вызывает стремление разработать и внедрить какое-нибудь ограниченное решение без связи с остальными задачами. Следуя этим принципам, компании сначала внедряют разрозненные независимые витрины. Информация в витринах не согласована с данными из других витрин, поэтому на стол руководству ложатся противоречивые отчеты. Показатели в этих отчетах с одинаковыми названиями могут скрывать разные сущности, и наоборот, одинаковые сущности могут иметь разные наименования, могут вычисляться по разным алгоритмам, на основании разного набора данных, за разные сроки. В результате пользователи независимых прикладных витрин говорят на разных языках бизнеса, и каждая витрина содержит собственные метаданные.

118

Другая проблема заключается в различии нормативно-справочной информации, используемых в независимых витринах данных. Разница в кодировке данных, в используемых кодификаторах, справочниках, классификаторах, идентификаторах, нормативах и словарях делает невозможным объединение этих данных без серьезного анализа, проектирования и разработки средств ведения НСИ. Так в компании создаются несколько хранилищ несогласованных данных, что в корне противоречит самой идее создания КХД как единого и единственного источника очищенных, согласованных и непротиворечивых исторических данных. Отсутствие корпоративного ведения метаданных и НСИ (затенены на Рис. 6) еще более затрудняют возможность согласовать данные между собой. Понятно, что ни руководство, ни пользователи подобного хранилища не склонны доверять информации, содержащейся в нем. Поэтому на следующем этапе встает необходимость радикальной переработки, а по сути, создания заново хранилища, ориентированного на хранение не отчетов, а согласованных показателей, из которых будут собираться отчеты. Таким образом, стремление к достижению сиюминутных результатов и к демонстрации быстрых успехов приводит к отказу от единого, сквозного управления метаданными и НСИ. Итогом такого подхода является наличие семантических островов, где сотрудники говорят на разных бизнес – языках. Полная переработка корпоративной архитектуры интеграции данных становится настоятельной необходимостью и приводит к повторному расходу средств и времени на создание полноценного КХД (Рис. 6).

Рис. 6. Результат реализации существующих подходов - ХД с накоплением данных в витринах

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

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

Рис. 9. План создания КХД

Как известно, большое путешествие начинается и заканчивается маленьким шагом. Создание централизованной среды управления данными, метаданными и НСИ является приоритетной задачей. Но бизнес – пользователи не видят мгновенной выгоды для себя от этой среды, и руководство предпочитает избегать длительных проектов без осязаемых результатов для основного бизнеса компании. Поэтому на первой фазе следует выбрать 2-3 пилотных проекта. Основными критериями выбора этих проектов являются поддержка руководства и готовность пользователей и экспертов участвовать в постановке задачи. Проекты должны обеспечить минимально приемлемую функциональность будущего КХД. В качестве условного примера на Рис. 7 выбраны следующие пилотные проекты для реализации на первой фазе: 1. интеллектуальный анализ данных (data mining) на основе Intelligent Miner (IM); 2. многомерный анализ (OLAP) с помощью Cubing Services и Alphablox; 3. анализ неструктурированного текста с использованием программных инструментов Unstructured Text Analysis Tools (UTAT). 120

Все перечисленные инструменты, используемые на первой фазе пилотных проектов, входят в состав IBM InfoSphere Warehouse. Очень важно, чтобы в результате реализации этих коротких проектов пользователи ощутили реальные преимущества КХД. Совместно с пользователями необходимо выполнить анализ результатов внедрения проектов и определить, при необходимости, меры по изменению среды КХД и внести коррективы в мероприятия по интеграции данных, метаданных и НСИ. Следующим шагом необходимо отобрать 3-4 новых проекта, которые бы продвинули компанию к созданию базовой функциональности перспективного КХД. Желательно, чтобы в отборе участвовали все заинтересованные стороны – руководство компании, пользователи, эксперты, проектная команда и специалисты по эксплуатации и поддержки КХД. Централизованная среда управления данными, метаданными и НСИ должна быть достаточна развита, чтобы соответствовать требованиям базовой функциональности КХД. Допустим, что на второй фазе выбраны для реализации следующие проекты и инструменты: 1. построение отчетов и исследование данных с помощью Cognos Business Insight Advanced и Report Studio; 2. создание сложных интерактивных панелей управления (dashboard) на основе Cognos Business Insight; 3. Сценарный анализ с использованием Cognos TM1; 4. Корпоративное планирование с помощью Cognos TM1. После завершения второй фазы пилотных проектов необходимо вновь выполнить анализ результатов выполнения проектов. Следующим шагом должно быть создание полнофункционального КХД, что невозможно без полноценной поддержки со стороны централизованной среды управления данными, метаданными и НСИ. Итак, примерный план по созданию КХД может выглядеть следующим образом: •

Стратегические задачи: o Скоординированная интеграция данных, метаданных и НСИ

•

Тактические задачи: o Выбор 2-3 проектов для демонстрации преимуществ КХД o Создание централизованной среды управления данными, метаданными и НСИ o Анализ результатов и изменение среды КХД при необходимости o Внедрение 3-4 проектов с учетом полученного опыта o В случае успеха – развитие КХД в масштабах компании o Промышленная эксплуатация КХД и создание новых задач, постановка и решение которых стало возможным благодаря накопленному опыту эксплуатации КХД

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

121

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

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

Литература 1. Асадуллаев C. “Система сбора и анализа первичных данных – I. Постановка задачи, сбор и хранение данных ”, 2011, http://www.ibm.com/developerworks/ru/library/sabir/warehouse-1/index.html 2. Асадуллаев C. “Система сбора и анализа первичных данных – II. Анализ первичных данных”, 2011, http://www.ibm.com/developerworks/ru/library/sabir/warehouse-2/index.html 3. IBM, “IBM Forms documentation”, 2010, https://www.ibm.com/developerworks/lotus/documentation/forms/ 4. IBM, “InfoSphere Warehouse overview 9.7”, 2010, http://publib.boulder.ibm.com/infocenter/idm/v2r2/index.jsp?topic=/com.ibm.isw.release.doc /helpindex_isw.html 5. IBM, “Cognos Business Intelligence”, 2010, http://publib.boulder.ibm.com/infocenter/cfpm/v10r1m0/index.jsp?topic=/com.ibm.swg.im.c ognos.wig_cr.10.1.0.doc/wig_cr_id111gtstd_c8_bi.html 6. IBM, “Cognos TM1”, 2010, http://www-01.ibm.com/software/data/cognos/products/tm1/ 7. Асадуллаев С. “Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных”. http://www.ibm.com/developerworks/ru/library/r-nci/index.html, 2009. 8. Асадуллаев С. “Архитектуры хранилищ данных – III”, http://www.ibm.com/developerworks/ru/library/sabir/axd_3/index.html, 2009. 9. Leong-Hong B.W., Plagman B.K. “Data Dictionary / Directory Systems”. John Wiley & Sons. 1982. (Леонг-Хонг Б., Плагман Б. “Системы словарей-справочников данных”, М.: Финансы и статистика, 1986) 10. Hackathorn R. “Data Warehousing Energizes Your Enterprise”, Datamation, Feb.1, 1995, p. 39. 122

11. Асадуллаев С. “Управление качеством данных с помощью IBM Information Server”, 2010, http://www.ibm.com/developerworks/ru/library/sabir/inf_s/index.html 12. Financial Service Technology. «Mastering financial systems success», 2009, http://www.usfst.com/article/Issue-2/Business-Process/Mastering-financial-systems-success/ 13. Brooks F. P. “The Mythical Man-Month: Essays on Software Engineering”, AddisonWesley Professional; Anniversary edition, 1995. (Брукс Ф., «Мифический человеко-месяц или Как создаются программные системы», Символ-Плюс, 2010).

123