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

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

Типовая модель бизнес-процессов разработки хранилища данных

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

Проект разработки ХД начинается после того, как выбраны инструменты разработки и сформирована команда проекта. Как видно из рис. 3.7, в проектный цикл разработки ХД обычно включаются следующие типовые процессы (этапы):

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

Рис. 3.7. Укрупненная бизнес-модель (IDEF0) процесса разработки хранилища данных

Опишем каждый типовой этап разработки ХД по следующей схеме.

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

Теперь перейдем к рассмотрению отдельных компонентов представленной бизнес-модели.

Формулирование требований

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

На этом этапе определяются:

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

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

Временные требования. Время выполнения этапа — от двух недель до двух месяцев.

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

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

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

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

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

Создание вычислительной среды для хранилища данных

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

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

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

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

Временные требования.

• Закупка и установка серверов — до двух недель.
• Монтажные работы на установке компьютерной сети — две-четыре недели.

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

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

В этом случае могут возникнуть конфликты между различными участниками проекта создания ХД и ИТ-службой организации в случае непредусмотренной остановки сервера БД.

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

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

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

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

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

Временные требования. Время выполнения этого этапа — от двух недель до двух месяцев.

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

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

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

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

Определение процедур извлечения, преобразования и загрузки данных

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

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

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

Временные требования. Время выполнения этапа — от одной недели до полутора месяцев.

Результатом выполнения этапа являются схема соответствия данных подающих систем и ХД, программы или ETL-инструменты.

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

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

Проектирование аналитических отчетов

Задача этапа. Главной задачей выполнения этого этапа является проектирование и разработка аналитических отчетов на спроектированной структуре данных. Это также специфичный этап для проекта ХД.

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

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

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

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

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

Разработка приложений хранилища данных

Задача этапа. Главной задачей данного этапа является формирование программной среды, в которой пользователи будут извлекать данные из ХД и просматривать предопределенные отчеты.

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

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

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

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

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

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

Задача этапа. Главная задача выполнения этого этапа — добиться оптимальной производительности ETL-процессов, производства отчетов и их доставки конечному пользователю.

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

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

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

Временные требования. Время выполнения этого этапа не должно превышать одну-две недели.

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

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

Проверка качества

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

Временные требования. Срок выполнения этого этапа — от одной до четырех недель.

Результатом выполнения этапа являются план тестирования ХД и заключение о готовности ХД к эксплуатации.

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

Разумным решением при выполнении этого этапа является привлечение организацией сторонних специалистов высокой квалификации по проверке качества ХД.

Передача системы складирования данных в эксплуатацию

Задача этапа. Главная задача этапа — передача системы складирования данных заказчику и представление ее конечным пользователям.

Временные требования. Срок выполнения этого этапа — от одного дня до нескольких недель.

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

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

Сопровождение и модификация хранилища данных

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

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

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

Резюме

Процесс разработки ХД может быть представлен в виде модели бизнес-процессов. Обычно руководители ИТ-проектов не создают бизнес-модель процесса разработки ХД. А напрасно! Бизнес-модель процесса разработки позволяет:

• отобразить субъективное мнение руководителя ИТ и некоторых участников команды на процесс проектирования конкретного ХД;
• учесть особенности ИТ-проекта, в рамках которого проектируется ХД;
• достаточно быстро составить план проектирования конкретного ХД;
• просчитать длительность проектных работ (создать временную модель проектирования).

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