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

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

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

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

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

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

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 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Необходимо заметить, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.

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

Хранилища данных обладают рядом свойств:

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

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

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

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

5. Интеграция. Различные ОБД разрабатываются  различными коллективами разработчиков,  зачастую в разное время и  различными средствами разработки. Это приводит к тому, что объекты,  отражающие одну сущность, имеют  различные наименования и единицы  измерения. Обязательная интеграция  данных в ХД позволяет решить  эту проблему.

6. Минимизация избыточности информации. В ХД информация загружается  из ОБД или OLTP-систем, при этом  избыточность оказывается минимальной

Типы хранилищ данных

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

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

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

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

1.Финансовые хранилища данных

В большинстве случаев финансовые ХД организации строят в первую очередь. Создание финансового ХД — необходимый компонент финансовой инфраструктуры любой организации.

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

2. Хранилища данных в области страхования

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

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

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

3. Хранилища данных для управления персоналом

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

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

4. Глобальные хранилища данных

Глобальные хранилища данных предназначены  для глобального представления  деятельности организации. Различают три типа таких ХД.

• Географически превалирующая обработка данных. Например, необходимо интегрировать бизнес в Гонконге с бизнесом в Париже, который, в свою очередь, следует интегрировать с Москвой, а тот — с Владивостоком.
• Функционально превалирующая обработка данных. Производственная деятельность должна быть интегрирована с поставками, которые необходимо интегрировать с продажами, а те — с исследованиями и так далее.
• Отраслевая превалирующая обработка данных. Например, требуется интегрировать печатное дело с консалтингом, который подлежит интеграции с бизнесом в сфере медицинского оборудования, а тот — со специализацией в области программного обеспечения.

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

5. Хранилища данных с возможностями обнаружения новых данных (Data Mining)

ХД, поддерживающие технологию обнаружения  новых данных (Data Mining), являются гибридом классических ХД. Они используются для выполнения мощной статистической обработки данных. Эти ХД являются:

• очень детальными;
• глубоко историческими;
• оптимизированными для статистического анализа.

6. Хранилища данных в области телекоммуникаций

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

Существуют несколько способов хранения подробностей на уровне телефонного  разговора:

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

 Вывод

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

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

Бесплатные  сервисы облачных хранилищ данных.

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

Стоимость.

Для ориентира, можно дать очень  примерную стоимость внедрения  хранилища данных для среднего Банка  со средней функциональностью, стоимость  составит около 4 000 000$ и потребует около 3-х лет.

Более точно можно оценить область  охвата проведя предварительное  обследование в течении 3-х месяцев и точно определить рамки бюджета, проведя конкурс среди 10-ти наиболее известных интеграторов региона. 
Мне приходилось участвовать, готовить или просто анализировать около 10-ти коммерческие проектов по внедрению хранилища данных с бюджетом от 500 000$ до 7 000 000$ и сроками реализации от 1-го до 4-х лет. На стоимость влияет очень много факторов: заинтересованность бизнеса, четкое описание области охвата, хороший менеджмент, выбранная архитектура хранилища, модель данных, состав источников и качество данных, унификация НСИ, проработанность методик расчета по функциональным задачам, выбор вендора, квалификация команды от исполнителя и команды от Банка и тп.

Распределение затрат:

Среда Microsoft Data Warehousing Framework

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

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