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

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

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

На данный момент существует достаточно большое количество разновидностей информационных систем.

В последние годы в мире оформился  ряд новых концепций хранения и

анализа корпоративных данных:

1. Информационные системы класса OLTP

2. Хранилища данных (Data Warehouse);

3. Оперативная аналитическая обработка  (On-Line Analytical Processing, OLAP);

4. Интеллектуальный анализ данных - ИАД (Data Mining).

Технологии OLAP тесно связаны с  технологиями построения хранилища  данных (Data Warehouse) и методами интеллектуальной обработки - Data Mining.

 

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

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

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

Предпосылки создания концепции складирования данных

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

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

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

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

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

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

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

-поддержка высокой скорости  данных из хранилища;

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

-возможность получения и сравнения  данных;

-наличие удобных утилит просмотра  данных хранилища;

-полнота и достоверность хранимых  данных;

-поддержка качественного процесса  пополнения данных.

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

1)Обычная база данных предназначена  для того, чтобы помочь пользователям  выполнять повседневную работу, тогда как хранилища данных  предназначены для принятия решений;

2)Обычная база данных подвержена  постоянным изменениям в процессе  работы пользователей, а хранилища  данных относительно стабильно;

-данные в нем обновляются  согласно расписанию (например, ежечасно, ежедневно, ежемесячно),

-в идеале, процесс пополнения  данными за определенный период  времени без изменения прежней  информации находящейся уже в  хранилище.

3)Обычная база данных чаще  всего является источником данных  попадающих в хранилище, кроме  того хранилище может пополняться  за счет внешних источников (например, сжатия данных

Согласно исследованию META Group, 90 - 95% компаний списка Fortune 2000 активно применяют хранилища данных, чтобы добиться преимущества в конкурентной борьбе и получить значительно большую отдачу от своих инвестиций. Трехлетнее изучение опыта 62 организаций, проведенное International Data Corporation (IDC) показало, что эти организации в среднем получили 400-процентный возврат своих инвестиций в СППР-системы [4, с.24]. Перечислим главные преимущества хранилищ данных:

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

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

- Быстрота разработки: специфическая  логическая организация хранилища  и существующее специализированное  ПО позволяют создавать аналитические  системы с минимальными затратами  на программирование.

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

- Историчность и стабильность: OLTP-системы оперируют с актуальными  данными, срок применения и  хранения которых обычно не  превышает величины текущего  бизнес-периода (полугода-год), в то время как информационное хранилище данных нацелено на долговременное хранение информации в течение 10-15 лет. Стабильность означает, что фактическая информация в хранилище данных не обновляется и не удаляется, а только специальным образом адаптируется к изменениям бизнесс-атрибутов. Таким образом, появляется возможность осуществлять исторический анализ информации.

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

 

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

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

виртуальное хранилище данных;

витрины данных;

глобальное хранилище данных;

многоуровневая архитектура хранилища  данных.

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

Витрина данных (Data Mart) - это облегченный вариант хранилища данных, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Витрина данных существенно меньше по объему, чем хранилище данных, поэтому его реализации не требуется мощная вычислительная техника.

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

На первом уровне реализуется корпоративное  хранилище данных на основе одной  из развитых современных реляционных  СУБД. Это хранилище состоит, в  основном, из детализированных данных. Реляционные СУБД обеспечивают эффективное  хранение и управление данными очень  большого объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием  многомерного представления данных.

На втором уровне поддерживаются витрины  данных на основе многомерной системы  управления базами данных (примером такой  системы является Oracle Express Server). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Необходимо заметить, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.