Файл: Технологии хранилищ данных.pdf

Введение

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

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

Цель работы: изучение понятия Технологии хранилищ данных

Задачи работы:

Поставленная цель предопределила выполнение следующих задач:

-Узнать потребность в анализе данных

-Выяснить архитектуру и компоненты хранилища данных

-Какова среда Microsoft Data Warehousing Framework

1.Потребность в анализе данных

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

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

2.Хранилища данных

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

• Предметная ориентированность. Информация в хранилище данных организована в соответствии с основными аспектами деятельности предприятия (заказчики, продажи, склад и т.п.); это отличает хранилище данных от оперативной БД, где данные организованы в соответствии с процессами (выписка счетов, отгрузка товара и т.п.). Предметная организация данных в хранилище способствует как значительному упрощению анализа, так и повышению скорости выполнения аналитических запросов. Выражается она, в частности, в использовании иных, чем в оперативных системах, схемах организации данных. В случае хранения данных в реляционной СУБД применяется схема «звезды» (star) или «снежинки» (snowflake). Кроме того, данные могут храниться в специальной многомерной СУБД в n-мерных кубах.
• Интегрированность. Исходные данные извлекаются из оперативных БД, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются (то есть вычисляются суммарные показатели) и загружаются в хранилище. Такие интегрированные данные намного проще анализировать.
• Привязка ко времени. Данные в хранилище всегда напрямую связаны с определенным периодом времени. Данные, выбранные их оперативных БД, накапливаются в хранилище в виде «исторических слоев», каждый из которых относится к конкретному периоду времени. Это позволяет анализировать тенденции в развитии бизнеса.
• Неизменяемость. Попав в определенный «исторический слой» хранилища, данные уже никогда не будут изменены. Это также отличает хранилище от оперативной БД, в которой данные все время меняются, «дышат», и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может дать разные результаты. Стабильность данных также облегчает их анализ.

Вышеприведенные особенности были впервые сформулированы в 1992 году «отцом-основателем» хранилищ данных Биллом Инмоном (Bill Inmon) в его книге «Building the Data Warehouse».

3. Архитектура и компоненты хранилища данных

3.1.Непрерывный процесс

Англоязычный термин «Data Warehousing», который сложно перевести лаконично на русский язык, означает «создание, поддержку, управление и использование хранилища данных» и хорошо подтверждает тот факт, что речь идет о процессе. Цель этого процесса — непрерывная поставка необходимой информации нужным сотрудникам организации. Этот процесс подразумевает постоянное развитие, совершенствование, решение все новых задач и практически никогда не кончается, поэтому его нельзя уместить в более или менее четкие временные рамки, как это можно сделать для разработки традиционных систем оперативного доступа к данным.

3.2.Хранилища и киоски данных

Хранилища данных могут быть разбиты на два типа: корпоративные хранилища данных (enterprise data warehouses) и киоски данных (data marts).

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

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

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

3.3.Основные компоненты

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

• оперативные источники данных;
• средства проектирования/разработки;
• средства переноса и трансформации данных;
• СУБД;
• средства доступа и анализа данных;
• средства администрирования.

4.Среда Microsoft Data Warehousing Framework

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

Корпорация Microsoft давно осознала важность направления, связанного с хранилищами данных, и необходимость принятия мер по созданию инструментальной и технологической среды, которая позволила бы минимизировать затраты на создание хранилищ данных и сделала бы этот процесс доступным для массового пользователя. Это привело к созданию Microsoft Data Warehousing Framework (рис. 4) — спецификации среды создания и использования хранилищ данных. Данная спецификация определяет развитие не только новой линии продуктов Microsoft (например, Microsoft SQL Server 7.0), но и технологий, обеспечивающих интеграцию продуктов различных производителей. Открытость среды Microsoft Data Warehousing Framework обеспечила ее поддержку многими производителями ПО, что, в свою очередь, дает возможность конечным пользователям выбирать наиболее понравившиеся им инструменты для построения своих решений.

Рис. 4. Microsoft Data Warehousing Framework

Цель Microsoft Data Warehousing Framework — упростить разработку, внедрение и администрирование решений на основе хранилищ данных. Эта спецификация призвана обеспечить:

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

5.Основные компоненты Microsoft Data Warehousing Framework

5.1.OLE DB — стандарт обмена данными

Построение хранилищ данных требует, с одной стороны, взаимодействия с различными оперативными БД для извлечения данных, а с другой — обмена данными и метаданными между различными компонентами. И та и другая задача решается крайне сложно — при отсутствии единого интерфейса для доступа к разнородным данным. Но такой интерфейс существует — это OLE DB. OLE DB целиком основан на открытой модели COM (Component Object Model) и представляет собой набор интерфейсов, которые могут быть использованы, например, в приложениях на Visual C++. Для упрощения использования OLE DB создан набор ActiveX-компонентов — ActiveX Data Objects (ADO). Эти компоненты могут вызываться из приложений на Visual Basic, Access, Excel, встраиваться в активные Web-страницы и т.п.

Практически все компоненты, которые мы будем обсуждать ниже, используют OLE DB для доступа к данным.

OLE DB обеспечивает доступ не только к реляционным данным, но и к таким ресурсам, как почтовые сообщения, файловые каталоги, полнотекстовые индексы и т.п.

5.2.Метаданные

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

Центральным компонентом Data Warehousing Framework является хранилище метаданных (репозитарий) — Microsoft Repository, поставляемое как один из компонентов Microsoft SQL Server 7.0. Microsoft Repository — это база данных, которая хранит описательную информацию о компонентах программного обеспечения и об их отношениях. Microsoft Repository состоит из набора Открытых информационных моделей (Open Information Model, OIM), а также набора опубликованных COM-интерфейсов. Открытые информационные модели — это объектные модели определенного типа информации, при этом они достаточно гибки, чтобы обеспечить поддержку новых типов информации. Корпорация Microsoft, опираясь на сотрудничество с представителями отрасли, уже разработала модели (OIM) для схемы баз данных (Database Schema), преобразования данных (Data Transformations) и OLAP. Последующие модели будут поддерживать репликацию, планирование задач, семантические модели и информационный справочник, который предназначен для обеспечения метаданными конечного пользователя.