OLAP технологии

33

ВВЕДЕНИЕ

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

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

1 ХРАНИЛИЩА ДАННЫХ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4) СУБД;

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

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

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

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

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

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

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

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

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

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

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

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

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

2 СРЕДСТВА OLAP-АНАЛИЗА

OLAP (On-Line Analytical Processing, оперативная аналитическая обработка) - все более популярная технология, которая может коренным образом усовершенствовать анализ данных. Microsoft SQL Server OLAP Services - это новый, полнофункциональный OLAP-сервер, поставляемый в составе SQL Server 7.0. OLAP Services включает в себя собственно сервер, доступный по протоколу OLE DB for OLAP, а также клиентский компонент, являющийся поставщиком протокола OLE DB for OLAP и обеспечивающий эффективное кэширование и возможность локального сохранения многомерных выборок для их дальнейшего анализа без подключения к OLAP-серверу.

Традиционно OLAP характеризовался дорогим инструментарием и сложным процессом реализации. Включение OLAP-функциональности в Microsoft SQL Server сделает многомерный анализ значительно более приемлемым с точки зрения затрат для небольших и средних организаций. Кроме того, небольшие группы или отделы в крупных организациях также смогут в полной мере воспользоваться новыми возможностями анализа - от сложной отчетности до продвинутых систем принятия решений.

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

Организация извлечения данных из оперативных БД, их очистки, интеграции и помещения в хранилище может потребовать значительных усилий и затрат, если не пользоваться встроенной в Microsoft SQL Server службой - Data Transformation Services (DTS). DTS обладает следующими свойствами:

1) Он на 100 % использует OLE DB для доступа, как к источнику, так и к приемнику данных. Благодаря этому DTS может извлекать и преобразовывать данные практически из любых источников (и, соответственно, помещать их в любые приемники данных).

2) Для переноса и трансформации данных используется расширяемый набор ActiveX-объектов, которыми легко управлять при помощи языка сценариев, например VBScript или JavaScript. Таким образом, имеются практически неограниченные возможности управления переносом и преобразованием данных.

3) DTS способен интегрироваться с Microsoft Repository для использования метаданных об источнике, приемнике и схеме преобразования данных.

4) Задания по переносу и преобразованию данных, которые могут включать в себя множество последовательных шагов, оформляются в виде пакетов (DTS Package), которые могут быть сохранены в хранилище метаданных (Repository), в базе SQL Server или в файле. Пакеты могут затем автоматически выполняться по расписанию при помощи сервиса SQL Server Agent.

2.2 Средства представления и анализа данных

Именно в сфере средства представления и анализа данных следует ожидать (и уже можно видеть) наибольшее количество продуктов, предлагаемых третьими фирмами, хотя и Microsoft предлагает здесь не только базовые технологии, но и средства для конечного пользователя. К ним относятся компоненты нового поколения Microsoft Office - Office 2007, прежде всего Microsoft Excel. Его популярное средство анализа данных PivotTable теперь сможет задействовать всю мощь OLAP-сервера, подключаясь к нему через упоминавшийся выше клиентский компонент PivotTable Services.

Еще одно средство от Microsoft - English Query - позволяет строить запросы к SQL Server на естественном языке (по-английски).

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

Существенной составляющей расходов на внедрение хранилища данных являются расходы на текущее сопровождение и администрирование хранилища. Средства администрирования, в том числе средства автоматизации выполнения административных задач, предусмотренные Data Warehousing Framework и включенные в состав Microsoft SQL Server 7.0, позволяют значительно сократить эти расходы.

Единой средой администрирования различных компонентов является Microsoft Management Console. Средства управления каждым конкретным компонентом (например, SQL Server или OLAP Services) представляют собой, так называемый snap-in, то есть модуль администрирования, использующий единые средства пользовательского интерфейса.

Средство управления SQL Server 7.0 - SQL Enterprise Manager включает в себя более 25 программ-мастеров (Wizards), помогающих не слишком искушенному администратору решать самые важные задачи, в том числе создавать и копировать базы данных, производить настройку тиражирования, импорт/экспорт данных, управлять правами пользователей и т.п.

Кроме того, в SQL Enterprise Manager входят средства создания и редактирования графических диаграмм баз данных, значительно облегчающих создание и модификацию структуры хранилища.

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

3 КОНЦЕПЦИЯ ХРАНИЛИЩ ДАННЫХ

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

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

В основе концепции хранилища данных лежат две основные идеи:

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

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

Рисунок 1- Общая архитектура аналитических ИС

Рисунок 2-  Потоки данных в информационном хранилище

3.1 Свойства информационных хранилищ

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

1) Предметная ориентация.

2) Интегрированность данных.

3) Инвариантность во времени.

4) Неразрушаемость - стабильность информации.

5) Минимизация избыточности информации.

6) Предметная ориентация.

В отличие от БД в традиционных OLTP-системах, где данные подобраны в соответствии с конкретными приложениями, информация в DW ориентирована на задачи поддержки принятия решений.. Для системы поддержки принятия решений требуются «исторические» данные - факты продаж за определенные интервалы времени. Хорошо спроектированные структуры данных DW отражают развитие всех направлений бизнеса компании во времени.

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

Интегрированность данных

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

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

Инвариантность во времени

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

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

Не разрушаемость - стабильность информации

В OLTP-системах записи могут регулярно добавляться, удаляться и редактироваться. В DW-системах, как следует из требования временной инвариантности, однажды загруженные данные теоретически никогда не меняются. По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для DW. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны - перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным.

Минимизация избыточности информации

Поскольку информация в DW загружается из OLTP-систем, возникает вопрос, не ведет ли это к чрезмерной избыточности данных? Нет, утверждает Билл Инмон. На самом деле избыточность минимальна (около 1%!), что объясняется следующими причинами:

1) при загрузке информации из OLTP-cистем в DW данные фильтруются. Многие из них вообще не попадают в DW, поскольку лишены смысла с точки зрения использования в системах поддержки принятия решений;

2) информация в OLTP-системах носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В DW, напротив, хранится историческая информация, и с этой точки зрения перекрытие содержимого DW данными OLTP- систем оказывается весьма незначительным;

3) в DW хранится некая итоговая информация, которая в базах данных OLTP-систем вообще отсутствует;

4) во время загрузки в DW записи сортируются, очищаются от ненужной информации и приводят к единому формату. После такой обработки это уже совсем другие данные.

3.2 Основные компоненты информационного хранилища

ПО промежуточного слоя

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

Транзакционные БД и внешние источники информации

Базы данных OLTP-систем исторически предназначались для эффективной обработки структур данных в относительно небольшом числе четко определенных транзакций. Из-за ограниченной целевой направленности «учетных» систем применяемые в них структуры данных плохо подходят для систем поддержки принятия решений. Кроме того, возраст многих установленных OLTP-систем достигает 10 - 15 лет.

Уровень доступа к данным

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

Загрузка и предварительная обработка

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

Информационное хранилище

Представляет собой ядро всей системы - один или несколько серверов БД.

Метаданные

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

Уровень информационного доступа

Обеспечивает непосредственное общение пользователя с данным DW посредством стандартных систем манипулирования, анализа и предоставления, данных типа MS Excel, MS Access, Lotus 1-2-3 и др.

Уровень управления (администрирования)

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

3.3 Проблемы интеграции данных

Остановимся на некоторых проблемах реализации хранилища данных: 1) Неоднородность программной среды.

2) Распределенный характер организации.

3) Повышенные требования к безопасности данных.

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

5) Потребность в эффективном хранении и обработке очень больших объемов информации.

3.4 Неоднородность программной среды

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

3.5 Распределенный характер организации

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

3.6 Повышение требований к безопасности данных

Собранная вместе согласованная информация об истории развития корпорации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории и состоянии рынка дает возможность анализа прошлой и текущей деятельности корпорации и построения прогнозов для будущего. Эта информация настолько ценна для корпорации, что нельзя допустить возможности ее утечки (на самом деле, если хранилище данных одной корпорации попадет в руки аналитиков другой корпорации, то все аналитические прогнозы первой корпорации сразу станут неверными). В системах, основанных на хранилищах данных, оказывается недостаточной защита данных в стиле языка SQL, которую обеспечивают обычные коммерческие СУБД (этот уровень защиты соответствует классу C2 в соответствии с классификацией Оранжевой Книги Министерства обороны США). Для обеспечения должного уровня защиты доступ к данным должен контролироваться не только на уровне таблиц и их столбцов, но и на уровне отдельных строк (это уже соответствует классу B1 Оранжевой Книги). Приходится также решать вопросы аутентификации пользователей, защиты данных при их перемещении в хранилище данных из оперативных баз данных и внешних источников, защиты данных при их передаче по сети.

4 АРХИТЕКТУРА ХРАНИЛИЩА ДАННЫХ

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

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

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

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

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

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

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

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

Рисунок 3- Общая схема информационной системы в технологии хранилищ данных