Зачем нужны хранилища данных?

 

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

 

Во многих случаях БД продукционных систем (бухгалтерские, финансовые, специализированные и т.п.) не могут справиться с нагрузкой, поступающей от аналитиков и персонала, формирующего отчеты. Накопленные исторические данные достаточно велики, и вычислительная техника просто не в состоянии обрабатывать в разумные сроки запросы, отнимающие много ресурсов. С другой стороны, в каждой такой системе имеются узкие места, и ответ на простой с виду вопрос занимает слишком много времени. Например, в ходе проекта по построению аналитической отчетной системы в телекоммуникационной компании Misrfone (GSM, Египет) было выявлено, что ответ на вопрос «Когда определенный абонент совершил свой первый звонок?» занял 42 часа… К тому времени сеть компании работала всего полгода…

 

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

 

Хранилище данных – элемент аналитической информационной системы

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

 

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

 

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

 

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

 

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

 

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

 

Классическая схема хранилища данных

Как было отмечено выше, хранилище само по себе не предназначено для того, чтобы быть источником данных для пользователей. Для этого есть витрины. Между тем и в хранилище информация поступает не напрямую из источников данных, а из оперативного хранилища (ODS – Operational Data Source). Теперь рассмотрим подробнее для чего все это нужно.

 

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

 

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

 

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

Что используется для построения хранилищ и витрин данных

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

 

Что касается сервера БД, то изначально для организации хранилищ и витрин использовались многомерные серверы БД. Однако в последнее время возможности реляционных серверов значительно возросли и специалисты утверждают, что настоящее большое хранилище можно построить только с их помощью. Это справедливо не только для больших, но и для любых других источников данных для аналитических приложений. Практически все производители доработали свои реляционные серверы до нужд аналитических систем. Кроме того, привлекает возможность использования уже имеющихся в компании серверов, и самое главное, навыков работы с ними. Ведь не секрет, что, например, Oracle Express – не просто дорогой сервер. Для его обслуживания нужны специалисты, которые достаточно редки.

 

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

Виртуальные витрины

Витрины данных могут быть перенесены на рабочие столы пользователей. Одним из способов сделать это – использование ПО доступа, OLAP и разработки отчетов. В качестве примера возьмем BusinessObjects – известный продукт одного из лидеров данного рынка.

 

Основная идея, заложенная в ядре BusinessObjects, заключается в виртуальном отображении физической модели данных в объектную. Программист разрабатывает словари терминов, которые затем использует конечный пользователь. Таким образом, манипулируя объектами своего бизнеса, он на самом деле строит SQL-запрос к хранилищу данных. Фактически каждый словарь – отдельная витрина данных. Использование BusinessObjects позволяет существенно снизить затраты на администрирование системы и стоимость ПО.

Выборки, полученные в результате выполнения запроса, становятся частью итогового документа (Рис. 1). Это позволяет формировать нужные пользователю отображения полученных данных и производить вычисления по ним, обращаясь к источникам данных только при необходимости обновления информации, изменении или формировании нового запроса. Документ вместе с выборкой может быть сохранен в виде файла или помещён в репозиторий документов системы BusinessObjects, что при наличии соответствующих прав позволяет продолжать работу над документом даже при отсутствии соединения с источниками данных (off-line).

 

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

 

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

К кому обратиться за предварительной консультацией

За реализацию проектов, основанных на описанных выше технологиях, в нашей компании отвечают менеджеры – Петров Владимир и Попов Илья. С ними можно связаться по многоканальному телефону +7 (495) 651-8285, или по электронной почте:
vpetrov@infocell.ru
ipopov@infocell.ru

 

 

---

* - использована информация c www.tern.ru.