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

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

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

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

Концепция DW была предложена и в 1992 г. Биллом Инмоном в его книге "Building the Data Warehouse" и стала одной из доминирующих в разработке информационных технологий обработки данных 90–х годов. Англоязычный термин Data Warehousing, который сложно перевести лаконично на русский язык, означает создание, поддержку, управление и использование хранилища данных, что говорит о том, что речь идет о процессе. Цель этого процесса – непрерывная поставка необходимой информации нужным сотрудникам организации. Этот процесс подразумевает постоянное развитие, совершенствование, решение все новых задач и практически никогда не кончается, поэтому его нельзя уместить в более или менее четкие временные рамки, как это можно сделать для разработки традиционных систем оперативного доступа к данным.

Хранилища данных становятся основой для построения систем принятия решений.

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

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

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

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

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

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

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

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

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

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

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

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

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

· СУБД;

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

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

Сферы применения DW:

· Сегментация рынка.

· Планирование продаж, прогнозирование и управление.

· Забота о клиенте.

· Разработка схем лояльности.

· Проектирование и разработка новых видов продукции.

· Интеграция цепочки поставок.

· Интеллектуальные технологии в организации бизнеса.

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

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

Основные поставщики ПО хранилищ данных: Arbor; Hewlett–Packard; IBM; Informix; Microsoft; Oracle; Platinum Technology; SAS Institute; Software AG; Sybase и др.

Все эти фирмы имеют страницы в Internet, где приводятся подробные сведения об их продуктах и услугах.

Технология анализа OLAP

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

Двенадцать определяющих принципов OLAP были сформулированы в 1993 году Е.Ф.Коддом, "изобретателем" реляционных баз данных. OLAP – это OnLine Analytical Processing, то есть оперативный анализ данных. Позже определение Кодда было переработано в так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information – быстрый анализ разделяемой многомерной информации), который требует, чтобы OLAP–приложение предоставляло следующие возможности быстрого анализа разделяемой многомерной информации: высокая скорость; анализ; разделение доступа; многомерность; работа с информацией..

1. Высокая скорость. Анализ должен производиться одинаково быстро по всем аспектам информации. При этом допустимое время отклика составляет не более 5 секунд.

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

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

4. Многомерность. Основная, наиболее существенная характеристика OLAP.

5. Работа с информацией. Приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.

Многомерное представление. OLAP предоставляет организациям максимально удобные и быстрые средства доступа, просмотра и анализа деловой информации. Что наиболее важно – OLAP обеспечивает пользователя естественной, интуитивно понятной моделью данных, организуя их в виде многомерных кубов (Cubes). Осями [L1][L2](dimensions) многомерной системы координат служат основные атрибуты анализируемого бизнес–процесса. Например, для процесса продаж это может быть категория товара, регион, тип покупателя. Практически всегда в качестве одного из измерений используется время. Внутри куба находятся данные, количественно характеризующие процесс, – так называемые меры (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т.п. Пользователь, анализирующий информацию, может "нарезать" куб по разным направлениям, получать сводные (например, по годам) или, наоборот, детальные (по неделям) данные и осуществлять прочие операции, которые необходимы ему для анализа.

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

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

Другой проблемой хранения OLAP–данных является разреженность многомерных данных. Например, если в 2000 году продаж в некотором регионе не было, то на пересечении соответствующих измерений куба не будет никакого значения. Если OLAP–сервер будет хранить в таком случае некое отсутствующее значение, то при значительной разреженности данных количество пустых ячеек (требующих, тем не менее, места для хранения) может во много раз превысить количество заполненных, и в результате общий объем неоправданно возрастет. Решения, предлагаемые для этого компанией Microsoft, приводятся ниже.

Разновидности OLAP. Для хранения OLAP–данных могут использоваться:

Специальные многомерные СУБД (OLAP–серверы). В этом случае говорят о MOLAP (Multidimensional OLAP). При выполнении сложных запросов, анализирующих данные в различных измерениях, многомерные СУБД обеспечивают большую производительность, чем реляционные. При этом скорость выполнения запроса не зависит от того, по какому измерению производится «срез» многомерного куба.

Традиционные реляционные СУБД – ROLAP (Relational OLAP). Применение специальных структур данных – схемы «звезды» (star) и «снежинки» (snowflake), а также хранение вычисленных агрегатов делают возможным многомерный анализ реляционных данных. Реляционные СУБД исторически более привычны, и в них сделаны значительные инвестиции, поэтому пока ROLAP более распространен.

Комбинированный вариант – HOLAP (Hybrid OLAP), совмещающий и тот и другой вид СУБД. Одним из вариантов совмещения двух типов СУБД является хранение агрегатов в многомерной СУБД, а детальных данных (имеющих наибольший объем) – в реляционной.

Компания Microsoft предлагает следующие средства OLAP–анализа:

В комплект Microsoft SQL Server 7.0 входит полнофункциональный OLAP–сервер – SQL Server OLAP Services. Сервер, естественно, предназначен для обслуживания запросов клиентов, а для этого требуется некий протокол взаимодействия и язык запросов. Например, для взаимодействия клиента с серверной реляционной СУБД – SQL Server – используются протоколы ODBC или OLE DB и язык запросов SQL. Для доступа к OLAP–серверу компанией Microsoft был разработан протокол OLE DB for OLAP и язык запросов к многомерным данным – MDX (MultiDimensional eXpression). Аналогично тому, как для упрощения и удобства над OLE DB разработан слой объектов ADO (ActiveX Data Objects), над OLE DB for OLAP построен ADO MD (MultiDimensional ADO).

Средства анализа данных в Microsoft Office 2000 (и выше). Microsoft Excel 2000 содержит новый механизм сводных таблиц – OLAP PivotTable, который заменил собой одноименный механизм предыдущих версий. Наряду с прежними возможностями анализа реляционных данных, механизм PivotTable теперь включает возможности анализа OLAP–данных, то есть выступает в качестве OLAP–клиента. В качестве сервера может использоваться Microsoft SQL Server 7.0, а также любой продукт, поддерживающий интерфейс OLE DB for OLAP. Механизм сводных таблиц Excel в полном объеме поддерживает возможности, предоставляемые описанным выше сервисом PivotTable Services (PTS). Таким образом, анализируемые OLAP–данные могут находиться как в локальных кубах, так и на OLAP–сервере.

Microsoft Office 2000 содержит также набор ActiveX–компонентов, называемых Office 2000 Web Components, которые позволяют организовать анализ OLAP–данных средствами просмотра Web. К ним относятся следующие четыре компонента:

Spreadsheet – реализует ограниченную функциональность листа Excel.

PivotTable – "близнец" сводных таблиц Excel; может работать с данными OLAP Services.

Chart – позволяет строить диаграммы, основанные как на реляционных, так и на OLAP–данных.

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

При работе с OLAP–данными Web Components обращаются к PivotTable Services.

Не нашли, что искали? Воспользуйтесь поиском по сайту: