Среда хранения и интеграции данных

Археология данных

Левый овал на рис. 3.5 изображает среду хранения и интеграции данных. Именно на нее техническая команда тратит 60-80% своего времени. Ее функ-* — это захват, очистка, моделирование, преобразование, пересылка и загрузка операционных данных от одной или более оперативных систем в хранилище данных. Все это сложные задачи, потому что операционные данные редко бывают чистыми, согласованными-и легко поддающимися интегрированию. Подобно археологам, технические специалисты должны расшифровать смысл и подтвердить годность многих тысяч элементов данных и значений от многих оперативных систем. Затем все это нужно опять склеить вместе в единую последовательную «модель» бизнеса, что очень напоминает воссоздание палеонтологом прижизненного облика динозавра по набору его костей.

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

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

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

Витрины данных

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

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

Напротив, витрины данных обычно разрабатываются на основе модели типа «звезда», в которой реляционные данные располагаются так, чтобы их можно было легко и быстро запрашивать и загружать в модули онлайновой аналитической обработки (OLAP). В отличие от нормализованных моделей в схеме типа «звезда» вся фактическая информация (например, числа) помещается в центральной таблице, окруженной множеством параметрических таблиц (поэтому такая схема и называется «звездой»), например по клиентам, по географическим признакам, по каналам, по продуктам. Параметрические таблицы фильтруют фактические данные центральной таблицы в ответ на запрос пользователя, например: «я хочу просмотреть доходы (то есть факты) за последние 12 месяцев (параметр «время») на Среднем Западе (параметр «география») по 10 нашим лучшим клиентам (параметр «оценка клиентов»).

Многослойная архитектура

Сегодня для удовлетворения информационных потребностей пользователей в большинстве компаний используется архитектура типа «звезда» (часто называемая в англоязычной литературе hub-and-spoke). Она предусматривает наличие центрального хранилища данных, которое питает информацией множество витрин данных на более низких уровнях. В такой среде пользователи обращаются с запросами к витринам данных, рассчитанных на информационные запросы конкретных отделов или рабочих групп. С запросами к хранилищу данных, которое содержит весь супернабор информации1 для витрин данных, при этом обращаются лишь самые опытные бизнес-аналитики.

Использование витрин данных позволяет направить усилия технических специалистов на проектирование хранилищ данных, способных справляться с двумя главными задачами: 1) собирать и интегрировать данные от множества разных систем с максимально возможным дроблением и 2) готовить и распределять данные для витрин данных. Информация в хранилище данных никогда не уничтожается, так что оно служит центром их «бесконечного» обновления и областью подготовки. Такая многослойная архитектура позволяет техническим командам быстро создавать новые витрины данных за счет повторного их использования прямо в хранилище и, возможно, извлечения новых данных из оперативных систем или периодически (в серийном производстве), или в реальном времени с помощью инструментов интеграции корпоративных данных (ЕН). Однако не все специалисты по хранению данных считают такую многослойную архитектуру наилучшей (см. «Крупный план» 3.1).

Дата добавления: 2015-04-29