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

Технологии хранилищ данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

средства проектирования/разработки;

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

СУБД;

средства доступа и анализа данных;

средства администрирования.

Средства хранения данных

Сердцем хранилища данных является, безусловно, СУБД, обеспечивающая надежное и производительное хранение и обработку данных. Как правило, данные из оперативных БД перемещаются в реляционное хранилище, где они становятся доступными для анализа. В дальнейшем, при использовании OLAP-средств, они могут быть перемещены в многомерную СУБД либо будут выбираться процессором многомерных запросов прямо из реляционных таблиц. Microsoft SQL Server 7.0 обеспечивает как реляционный, так и многомерный вид хранения. Подробную информацию о Microsoft SQL Server можно найти в разделе "Microsoft SQL Server". Ниже кратко перечислены его основные характеристики: сначала возможности реляционной СУБД, а затем - многомерной.

Microsoft SQL Server 7.0 обладает целым рядом свойств, делающих его превосходной платформой для построения хранилищ данных:

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

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

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

средства параллельного выполнения сложных запросов;

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

распределенные запросы, позволяющие выбирать связанные данные из различных ОLE DB-источников;

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

Кроме того, средства тиражирования по-прежнему остаются одним из механизмов перемещения данных из оперативной БД в хранилище. Ниже рассматривается ряд механизмов, входящих в состав SQL Server 7.0.

1. Введение

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

В течение последнего десятилетия термин Data Warehouse, или хранилище данных, стал одной из самых популярных тем для обсуждения. Любая система, хранящая собираемые данные, претендует на название хранилища данных. Ведутся ожесточенные теоретические споры по поводу, что называть хранилищем данных, чем оно отличается от OLTP систем и какое определение более точно описывает его сущность. Мы попробуем подойти с другой стороны – практической.

2. Методология

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

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

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

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

Рис. 1. Основные стадии построения хранилища данных

2.1. Оценка проекта

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

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

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

2.2. Сбор требований

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

Структура данных в источниках

Основные предметные области, связанные с задачей

Требования пользователей

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

2.3. Проектирование хранилища данных

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

Логическая и физическая модели данных

Схемы процессов загрузки

Модели приложений

2.4. Разработка хранилища данных

Эта стадия включает следующие шаги:

Разработка процедур начальной загрузки

Проведение начальной загрузки

Разработка процедур регулярной загрузки

Разработка приложений

Проведение тестовых испытаний

2.5. Ввод в эксплуатацию

Ввод в эксплуатацию включает в себя:

Обучение пользователей

Перевод проекта в стадию эксплуатации (определение администраторов, регламентов и т.д.)

2.6. Оценка результатов

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

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

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

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

Загрузка данных из источников, в число которых входят различные СУБД, ERP (Enterprise Resource Planning) системы, а также электронные таблицы, текстовые файлы, ленты новостей и т.д.

Хранение данных в специально спроектированных структурах, отражающих их предметную специфику и обеспечивающих эффективный доступ

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

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

Логическая и физическая структура хранилища

Процессы загрузки и их регламент

Приложения и возможные способы представления информации

Общая схема информационной системы в технологии хранилищ данных представлена на рис. 2.

Рис. 2. Общая схема информационной системы в технологии хранилищ данных