Data Warehouse: с чего начать?

Владимир Туманов

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

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

- описание функциональных возможностей конкретных программных продуктов;

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

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

Кроме того, от построения DW отпугивали большой объем внутренних капиталовложений и варьирования временных рамок (от 3 месяцев до 3 лет в зависимости от масштабов проекта - данные приводятся по оценкам западных специалистов). Для российского рынка информационных услуг существенным тормозом в построении DW был незначительный (5 - 8 лет) период существования основной массы предприятий на рынке, ибо потребности этого периода хорошо охватываются так называемыми транзакционными системами.

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

Немного истории

Концепция DW была предложена в 1990 г. Б. Инмоном и стала одной из доминирующих в разработке информационных технологий обработки данных 90-х годов. На мой взгляд, появление этой концепции было следствием неявного осознания того факта, что существует два основных функционально различных класса систем обработки информации.

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

В российской печати термин Data Warehouse переводится двояко: как хранилище данных и как информационное хранилище. Однако термин Information warehouse был введен корпорацией IBM в начале 80-х годов и, по утверждению ее специалистов, означает нечто большее, чем DW по Инмону. Поэтому было бы целесообразно пользоваться уже примелькавшимся термином “хранилище данных”, хотя он несколько хуже передает суть концепции. Терминология, используемая сейчас в рамках концепции DW, приведена в глоссарии.    

Что же такое DW?

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

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

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

Функциональное определение понятия Data Warehouse

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

Заметим также, что интеграция в определении DW понимается не как интеграция информации по всем источникам функциональной деятельности предприятия, а в смысле согласованного представления данных из разных источников по их типу, размерности и содержательному описанию. Это есть интеграция данных от бизнес-процессов, а не самих бизнес-процессов. Бизнес-процессы интегрируются в рамках корпоративной информационной системы (КИС) вашего предприятия.

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

Что может испортить хорошую затею

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

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

- Единообразие технологической концепции. При создании КИС обычно используются технологии Internet/intranet, так называемая Groupwise или их разумная комбинация. Независимо от выбора СУБД в рамках этих технологий формируется различная корпоративная технология обработки данных, по-разному распределяются нагрузки на сервер и клиентскую части и т. д. Единообразие подхода в какой-то степени обеспечивает ритмичность проведения работ.

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

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

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

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

- Не объединять плохо совместимое. Например, не следует объединять в программах типа “Торговый дом” транзакционную и аналитическую части в рамках одной технологии разработки. Это будет долгий и трудный процесс, поскольку подходы к моделированию и проектированию этих частей существенно различаются. Реализовать их по отдельности и проще, и быстрее. Однако есть и другие примеры, когда для разработки используются концепции более высокого уровня абстракции. Удачны, например, решения в Baan или ROSS system, при разработке которых была отработана методология слияния транзакционной и аналитической частей в рамках единой КИС. Зато они и стоят дорого.    

Где искать выгоду

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

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

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

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

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

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

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

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

- Распространение DW из области стратегического планирования на текущие операции (здесь уместно отметить российскую фирму Ally, которая, на мой взгляд, пошла обратным путем - от операций к стратегическому планированию).

Решить перечисленные выше задачи вам помогут монографии директора фирмы Data Warehouse Network (Ирландия) Ш. Келли (Sean Kelly), а также консультанты фирм Oracle и Informix, которые в течение последних лет поддерживают концепцию DW в своих продуктах.

Глоссарий

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

Мистер Фикс, у вас есть план?

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

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

- Создать рабочую группу проекта и включить в ее состав специалистов во всех областях использования DW.

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

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

- Провести моделирование, разработать схему и построить DW.

Рассмотрим эти действия более подробно.

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

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

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

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

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

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

На этом этапе следует:

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

- Провести стандартизацию данных для DW, то есть привести все используемые данные к единому представлению в DW. Это станет первой итерацией в создании метаданных DW.

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

- Документировать в метаданных тип, размер, описание, наименование всех атрибутов объектов DW, т. е. определить смысл сохраняемых данных.

- Реализовать программные механизмы и процедуры преобразования данных для их загрузки в DW.

На этом этапе будет получен прототип DW.

4. На стадии стандартизации и очистки данных нужно:

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

- Стандартизовать представления данных в масштабах предприятия.

- Стандартизовать данные по всем основным объектам DW.

- Стандартизовать события, криптографические коды и состояния объектов в DW.

- Реализовать принятые стандарты в программном обеспечении DW.

5. База данных DW может быть не реляционной. В принципе для реализации типичной схемы DW “звезда” (см. глоссарий) может быть использован любой тип базы данных. Здесь все зависит от сложившегося информационного стереотипа организации и финансовых возможностей проекта. В любом случае нужно иметь в виду следующие задачи.

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

- Разработка или адаптация стандартных программных средств для предобработки данных (процедуры очистки данных).

- Загрузка данных на SQL-сервер или какой-либо другой сервер.

- Оценка достигнутых результатов и внедрение технологии.

Именно на этой стадии создается DW и организуется ее поддержка. Дальше только от вас зависит, насколько вложенные в создание DW средства оправдают себя.    

Вместо заключения

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

К Владимиру Туманову можно обратиться по адресу: tve@icp.ac.ru.

Основные поставщики ПО хранилищ данных

Arbor

Business Objests

Carleton

Cognos

Hewlett-Packard

IBM

Information Builders

Informix

Intellidex

Microsoft

MSP

NCR

Oracle

Platinum Technology

Praxis

Prism

Pyramid

Red Brick

SAS Institute

Sequent

Software AG

Sybase

Tandem

Все эти фирмы имеют страницы в Internet, где приводятся подробные сведения об их продуктах и услугах. Стоит отдельно отметить альянс Arbor и Seagate при встраивании OLAP в Crystal Info для СУБД Essbase.