Архитектуры для хранения данных: битва титанов

Крупный план 3.1

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

Модель Инмона. Эта модель, названная так в честь Билла Инмона. плодовитого автора и уважаемой фигуры в кругах «хранителей данных», построена на базе «звездной» архитектуры, в которой центральное хранилище данных служит подготовительной (staging) зоной для сбора данных от множества систем-источников с последующим распределением подмножеств этих данных по витринам данных более низкого уровня. В такой многослойной архитектуре пользователи обращаются с запросами не к хранилищам данных, а к витринам данных: хранилища данных при этом функционируют больше как зоны подготовки и центры распределения данных. Хранилища данных содержат подробные данные, тогда как витрины данных содержат главным образом обобщенные данные.

Модель Кимбола. Еще одно крупное направление поддерживает взгляды Ральфа Кимбола. тоже плодовитого автора и тоже уважаемой в отрасли фигуры. Модель Кимбола исключает потребность в хранилище данных. Обычно пользователям нужны детальные данные, и. по мнению Кимбола. их лучше хранить в индивидуальных витринах данных и логически объединять с использованием «соответствующих» параметров. В сущности, хранилище данных у Кимбола — это совокупность всех витрин данных. Чтобы обеспечить большую эффективность запросов и облегчить пользование витринами данных. Кимбол ввел другой тип модели данных, называемый схемой «звезда», которая сегодня широко используется, даже среди «инмонитов». при создании витрин данных.

Централизованная модель хранилища данных. Компания Teradata (отделение NCR) — сторонник использования хранилищ данных без каких бы то ни было витрин данных. Такой централизованный подход обеспечивает пользователям свободный доступ ко всем данным в хранилище данных, не ограничивая их отдельными витринами данных. Это также облегчает управление и обслуживание, потому что все данные хранятся централизованно, в пределах единой платформы управления данными. Однако централизованное хранилище данных может стать чрезвычайно большим и по объему хранимых данных, и по числу поддерживаемых пользователей. Чтобы обеспечить адекватное обслуживание запросов в больших централизованных хранилищах, организация должна иметь быстродействующую базу данных с параллельной обработкой (наподобие тех. которые поставляет Teradata).

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

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

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

Операционные склады данных

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

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

Инструменты

для складирования и хранения данных

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

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

Инструменты для интеграции данных

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

Для поддержки режима обновления по мере необходимости («в нужное время») или даже в режиме реального времени группа управления эффективностью может также развернуть быстродействующее промежуточное программное обеспечение в сочетании с инструментами для выборки, трансформации и загрузки данных (ETL). Например, организации, использующие системы интеграции корпоративных приложений (EAI) для интегрирования пакетных и унаследованных приложений, теперь вводят данные в механизмы выборки, трансформации и загрузки данных в режиме реального времени. Такая «капельная» подача данных заменяет традиционные процессы пакетной загрузки, которые фактически позволяют хранить в хранилищах данных лишь прошлые статистические данные. Сочетание систем интеграции корпоративных приложений (ЕА1) и выборки, трансформации и загрузки данных (ETL) открывает перспективы преобразования хранилищ данных из громоздких исторических архивов в активные репозитории, представляющие информацию по запросам.

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

Облегченная инфраструктура

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

Крупный план 3.2

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