Хранилище данных - что это такое?

I.T.Manning

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

Для множества людей хранилище данных - это некая совокупность данных объединенных из различных источников, структурированная и оптимизированная для доступа к ним при помощи средств создания запросов OLAP (on-line analytical processing - оперативной аналитической обработки). Этот взгляд изначально распространялся поставщиками средств OLAP. Для других хранилище данных - это фактически некая база данных, содержащая данные более чем из одного источника, собранные для целей управления информацией. Это определение не является ни полезным, ни очевидным, поскольку такие базы данных служили для принятия решений задолго до возникновения самого термина "хранилище данных".

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

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

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

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

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

Почему это так дорого?

Хотя концепция хранения данных в ее различных проявлениях продолжает привлекать интерес, многие проекты в этой области не оправдывают возлагавшихся на них надежды, оказываясь чрезмерно дорогими при разработке и дальнейшем обслуживании. Поэтому важно иметь ясное представление об их реальных преимуществах, и того, как добиться этих преимуществ посредством приемлемых для предприятия затрат.
Стоимость проектов по хранению данных обычно довольно высока. Это объясняется, в первую очередь, необходимостью собрать, "очистить" и обобщить данные из различных источников, часто из наследственных систем. Такая работа весьма трудоемка и занимает много времени, в тоже время, она является необходимым звеном успеха для проекта - плохо интегрированные данные низкого качества - это неполная или бесполезная для управления информация. Стоимость извлечения, отбора и обобщения данных составляет 60-80% от общей стоимости обычного проекта по хранению данных, как и для любого другого проекта разработки средств для поддержки принятия решений.

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

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

Как оправдать затраты?

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

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

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

Исследование привело к нескольким важным результатам:

1. 80% данных, использовавшихся различными информационными хранилищами корпорации, поступало из 20% исходных систем.
   
2. В каждом новом проекте хранения данных, как правило, была собственная процедура извлечения, очистки и обобщения данных из различных источников, не взирая на тот факт, что большая часть вновь используемых данных уже подвергалась подобной обработке в предыдущих проектах.
   
3. Данные, которые должны были быть размещены в хранилище, обычно отбирались исходя из нужд конкретной группы, с соответствующим набором информационных требований. При этом нужды других групп в тех же данных учитывались редко.
   

Опыт других организаций продемонстрировал картину весьма сходную с описанной выше. Уже из этих результатов ясно, что в планировании проектов хранения данных есть резервы для экономии. Если 20% исходных систем, поставляют 80% данных для систем поддержки принятия решений, то проект, который просто объединит в одно хранилище "полезные" данные из этих систем, создаст предпосылки для сокращения стоимости будущих проектов, в которых эти данные потребуются. Вместо того чтобы сосредотачиваться на конкретных бизнес-процессах или функциях, следует ориентироваться на более широкую аудиторию для поддержки принятия решений. Такой проект заложит неоценимое основание для дальнейшего развития среды хранилища данных.

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

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

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

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

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

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

Об авторе:

Ian Manning - внештатный консультант в области информационных технологий с опытом работы около 20 лет, специализируется на консультациях по хранению данных и поддержке принятия решений. Занимался управлением проектом, архитектурой систем, деловым и системным анализом, проектирование систем, проектирование и настройка баз данных, анализ и обработка данных. Это выполнялось для широкого спектра клиентов из различных отраслей, включая банковское дело, промышленность, местное самоуправление, фармацевтику, энергетику и страхование.