Стремление объединить в одной архитектуре СППР возможности OLTP-систем исистем анализа,привело к появлению концепции х ра н и л ищ д а н ны х (ХД).
Концепция ХД так или иначе обсуждалась специалистами в области инфор-
мационных систем достаточно давно. Первые статьи,посвященные именно ХД,появились
в 1988 г., их авторами были Б. Девлин и П. Мэрфи. В 1992 г. У. Инмон подробно описалданную концепцию в своей монографии "Построение хранилищ данных" ("Building the Data Warehouse", second edition - QED Publishing Group, 1996).
В основе концепции ХД лежит идея разделения данных, используемых для
оперативной обработки и для решения задач анализа. Это позволяет применять структурыданных, которые удовлетворяют требованиям их хранения с учетом использования в OLTP-системах и системах анализа. Такое разделение позволяет оптимизировать какструктуры данных оперативного хранения (оперативные БД, файлы, электронные таблицы и т. п.) для выполнения операций ввода, модификации, удаления и поиска, так иструктуры данных, используемые для анализа (для выполнения аналитических запросов). В СППР эти два типа данных называются соответственно о п е р а т и в н ы м и и с т о ч н и к а м и д а нны х (ОИ Д ) и х р а ни л и щ е м д а нн ы х .
В своей работе Инмон дал следующее определение ХД.
Х ра ни л и щ е д а н н ы х -предметно-ориентированный,интегрированный,
неизменчивый, поддерживающий хронологию набор данных, организованный для целейподдержки принятия решений.
Рассмотрим свойства ХД более подробно.
П р ед м е т н ая о ри е н т а ци я. Это фундаментальное отличие ХД от ОИД.
Разные ОИД могут содержать данные, описывающие одну и ту же предметную область с разных точек зрения (например, с точки зрения бухгалтерского учета, складского учета,планового отдела и т. п.). Решение, принятое на основе только одной точки зрения, можетбыть неэффективным или даже неверным. ХД позволяют интегрировать информацию,отражающую разные точки зрения на одну предметную область.
Предметная ориентация позволяет также хранить в ХД только те данные, которые
нужны для их анализа (например, для анализа нет смысла хранить информацию о номерахдокументовкупли-продажи, в то время как их содержимое - количество,ценапроданного товара -необходимо). Это существенно сокращает затраты на носителиинформации и повышает безопасность доступа к данным.
И н т е гр а ци я . ОИД, как правило, разрабатываются в разное время несколькими коллективами с собственным инструментарием. Это приводит к тому, что данные, отражающие один и тот же объект реального мира в разных системах, описывают его по- разному. Обязательная интеграция данных в ХД позволяет решить эту проблему, приведя данные к единому формату. По дде р ж к а х р о н оло гии . Данные в ОИД необходимы для выполнения над ними операций в текущий момент времени. Поэтому они могут не иметь привязки ко времени. Для анализа данных часто бывает важно иметь возможность отслеживать хронологию изменений показателей предметной области. Поэтому все данные, хранящиеся в ХД, должны соответствовать последовательным интервалам времени. Н е и зм е н я е мо с т ь . Требования к ОИД накладывают ограничения на времяхранения в них данных. Те данные, которые не нужны для оперативной обработки, какправило, удаляются из ОИД для уменьшения занимаемых ресурсов. Для анализа,наоборот, требуются данные за максимально большой период времени. Поэтому, вотличие от ОИД,данные в ХД после загрузки только читаются. Это позволяетсущественно повысить скорость доступа к данным, как за счет возможной избыточностихранящейся информации,так и за счет исключения операций модификации.
При реализации в СППР концепции ХД данные из разных ОИД копируются вединое хранилище. Собранные данные приводятся к единому формату, согласовываются и обобщаются.Аналитические запросы адресуются к ХД (рис. 1).
Такая модель неизбежно приводит к дублированию информации в ОИД и в ХД.
Однако Инмон в своей работе утверждает, что избыточность данных, хранящихся в
СППР, не превышает 1 %! Это можно объяснить следующими причинами.
При загрузке информации из ОИД в ХД данные фильтруются. Многие из них непопадают в ХД, поскольку лишены смысла с точки зрения использования в процедураханализа.
Информация в ОИД носит, как правило, оперативный характер, и данные, потеряв
актуальность, удаляются. В ХД, напротив, хранится историческая информация. С этойточки зрения дублирование содержимого ХД данными ОИД оказывается весьманезначительным. В ХД хранится обобщенная информация,которая в ОИД отсутствует.
Во время загрузки в ХД данные очищаются (удаляется ненужная информация), и
после такой обработки они занимают гораздо меньший объем.
Подсистем а ввода(OLTP)
П о д с и с т е м
Аналитические запросы
П о д с и с т е м
О п е р а т о
Подсистем а ввода(OLTP)
а анализа
Р и с у н о к 7. Структура СППР с физическим ХД
Избыточность информации можно свести к нулю, используя виртуальное ХД. Вданном случае в отличие от классического (физического) ХД данные из ОИД некопируются в единое хранилище. Они извлекаются, преобразуются и интегрируютсянепосредственнопри выполнении аналитических запросов в оперативной памятикомпьютера. Фактически такие запросы напрямую адресуются к ОИД (рис. 2). Основнымидостоинствами виртуального ХД являются:
минимизация объема памяти, занимаемой на носителе информацией; р а б о т а с т ек у щ и м и, д е т а л изи р о в а нн ы м и д а нн ы м и.Подсистем а ввода(OLTP)
Подсистем а ввода(OLTP)
Подсистем а ввода
Подсистема храненияинформации
Аналитические запросы
Подсистем а анализа(OLAP,
О п е р а т о
В и р т у а л ьн о е
Р и с у н о к 8. С т р у к т у ра С ПП Р с в и р т у а л ь н ы м Х Д
Однако такой подход обладает многими недостатками.
Время обработки запросов к виртуальному ХД значительно превышает соот-
ветствующиепоказателидляфизическогохранилища.Крометого,структурыоперативных БД, рассчитанные на интенсивное обновление одиночных записей, ввысокой степени нормализованы. Для выполнения же аналитического запроса требуетсяобъединение большого числа таблиц,что также приводит к снижению быстродействия.
Интегрированный взгляд на виртуальное хранилище возможен толькопривыполнении условия постоянной доступности всех ОИД. Таким образом, временнаянедоступность хотя бы одного из источников может привести либо к невыполнениюаналитического запроса, либо к неверным результатам.
Выполнение сложных аналитических запросов над ОИД требует значительных ресурсов компьютеров. Это приводит к снижению быстродействия OLTP-систем, чтонедопустимо,т.к.время выполнения операций в таких системах часто весьма критично.
Различные ОИД могут поддерживать разные форматы и кодировки данных. Часто
на один и тот же вопрос может быть получено несколько вариантов ответа. Это можетбыть связано с:
несинхронностью моментов обновления данных в разных ОИД; отличиями в описании одинаковых объектов и событий предметной области; ошибками при вводе; утерей фрагментов архивов и т. д.В таком случае цель - формирование единого непротиворечивого взгляда наобъект управления - может быть не достигнута.
Главным же недостатком виртуального хранилища следует признать практическую
невозможностьполученияданныхзадолгийпериодвремени. Приотсутствиифизического хранилища доступны только те данные, которые на момент запроса есть в ОИД. Основное назначение OLTP-систем -оперативная обработка текущихданных,поэтому они не ориентированы на хранение данных за длительный период времени. Помере устаревания данные выгружаются в архив и удаляются из оперативной БД.
Несмотря на преимущества физического ХД перед виртуальным, необходимо
признать, что его реализация представляет собой достаточно трудоемкий процесс.
Остановимся на основных проблемах создания ХД:
необходимость интеграции данных из неоднородных источников в рас-пределенной среде;
потребность в эффективном хранении и обработке очень больших объемов информации; необходимость наличия многоуровневых справочников метаданных; Оповышенные требования к безопасности данных. Рассмотрим эти проблемы более
подробно.
Н е об х о д и мо с т ь ин т е гр а ци и д а нн ых и з н е о д н о р о д н ых и с т о ч ник ов в р а с - пр еде л е нн ой с р еде . ХД создаются для интегрирования данных, которые могут поступатьиз разнородных ОИД,физически размещающихсяна разныхкомпьютерах:БД,электронных архивов, публичных и коммерческих электронных каталогов, справочников,статистических сборников. При создании ХД приходится решать задачу построениясистемы, согласованно функционирующей с неоднородными программными средствами и решениями. При выборе средств реализации ХД приходится учитывать множествофакторов, включающих уровень совместимости различных программных компонентов, легкость их освоения и использования,эффективность функционирования и т. д.
По т р е б н о с т ь в э ф ф е к т и в н ом х р а н е ни и и о б р або т к е о че н ь бол ь ш и х об ъ е мов ин ф о р ма ц и и . Свойство неизменности ХД предполагает накопление в нем информации задолгий период времени, что должно поддерживаться постоянным ростом объемовдисковой памяти. Ориентация на выполнение аналитических запросов и связанная с этимденормализация данных приводят к нелинейному росту объемов памяти, занимаемой ХДпри возрастании объема данных. Исследования, проведенные на основе тестового набораTPC-D, показали, что для баз данных объемом в 100 Гбайт требуется память, в 4,87 разабольшая объемом,чем нужно для хранения полезных данных.
Н е об х о д и мо с т ь м н о г оу р ов н е вых с пр аво ч ник ов м е т а д а нн ы х . Длясистеманализа наличие развитых метаданных (данных о данных) и средств их предоставленияконечным пользователям является одним из основных условий успешной реализации ХД.Метаданные необходимы пользователям СППР для понимания структуры информации, наосновании которой принимается решение. Например, прежде чем менеджер корпорациизадаст системе свой вопрос, он должен понять, какая информация имеется, насколько онаактуальна, можно ли ей доверять, сколько времени может занять формирование ответа и т.д. При создании ХД необходимо решать задачи хранения и удобного представленияметаданных пользователям.
Повы ш е ни е т р е бова ни й к б е зо п а с н о с т и д а нн ы х . Собранная вместе и со-
гласованная информация об истории развития корпорации, ее успехах и неудачах, овзаимоотношениях с поставщиками и заказчиками, об истории и состоянии рынка даетвозможность анализа прошлой и текущей деятельности корпорации и построенияпрогнозовдлябудущего. Очевидно,чтоподобнаяинформация являетсяконфиденциальной и доступ к ней ограничен в пределах самой компании, не говоря уже одругих компаниях. Для обеспечения безопасности данных приходится решать вопросыаутентификации пользователей, защиты данных при их перемещении в хранилище
данных из оперативных баз данных и внешних источников, защиты данных при ихпередаче по сети и т.п.
Снижения затрат на создание ХД можно добиться, создавая его упрощенный
вариант - витрину данных (Data Mart).
В и т р ин а д а н ны х (В Д ) - это упрощенный вариант ХД, содержащий только тема-
тически объединенные данные.
ВД максимально приближена к конечному пользователю и содержит данные,
тематически ориентированные на него (например, ВД для работников отдела маркетингаможет содержать данные, необходимые для маркетингового анализа). ВД существенноменьше по объему, чем ХД, и для ее реализации не требуется больших затрат. Они могутбыть реализованы как самостоятельно,так и вместе с ХД.
Самостоятельные ВД (рис. 3) часто появляются в организации исторически ивстречаются вкрупныхорганизациях сбольшимколичествомнезависимыхподразделений, решающих собственные аналитические задачи.
проектирование ВД для ответов на определенный круг вопросов; быстрое внедрение автономных ВД и получение отдачи; упрощение процедур заполнения ВД и повышение их производительности за счет учета потребностей определенного круга пользователей.Подсистем а ввода(OLTP)
Подсистем а ввода(OLTP)
Подсистема храненияинформации
Аналитические запросы
Аналитические
запросы
Подсистем а анализа(OLAP,
П о д с и с т е м
О п е р а т о
Подсистем а ввода(OLTP)
а анализа
Р и с у н о к 9. Структура СППР с самостоятельными ВД
Недостатками автономных ВД являются:
многократное хранение данных в разных ВД, что приводит к увеличению расходов на их хранение и потенциальным проблемам, связанным с необходимостью поддержания непротиворечивости данных; отсутствие консолидированности данных на уровне предметной области, а,следовательно - отсутствие единой картины.
В последнее время все более популярной становится идея совместить ХД и ВД в
одной системе. В этом случае ХД используется в качестве единственного источникаинтегрированных данных для всех ВД (рис. 4).
ХД представляет собой единый централизованный источник информации для всейпредметнойобласти, аВД являютсяподмножествамиданныхизхранилища,
организованными для представления информации по тематическим разделам даннойобласти. Конечные пользователи имеют возможность доступа к детальным даннымхранилища, если данных в витрине недостаточно, а также для получения более полнойинформационной картины.
Достоинствами такого подхода являются:
простота создания и наполнения ВД, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных данных - из ХД; простота расширения СППР за счет добавления новых ВД; с ни ж е ни е н а г р у з к и н а о с н о в н о е Х Д.Подсистем а ввода(OLTP)
Подсистема храненияинформации
Аналитические запросы
П о д с и с т е м
О п е р а т о
Подсистем а ввода(OLTP)
Подсистем а ввода(OLTP)
А н а л и т и че с к и е
ХД запросы
ВД
а анализа
Подсистем а анализа(OLAP,
Р и с у н о к 10. Структура СППР с ХД и ВД
К недостаткам относятся:
избыточность (данные хранятся как в ХД, так и в ВД); дополнительные затраты на разработку СППР с ХД и ВД.Подводя итог анализу путей реализации СППР с использованием концепции ХД,можно выделить следующие архитектуры таких систем:
СППР с физическим (классическим) ХД (см. рис. 1); СППР с виртуальным ХД (см. рис. 2); СППР с ВД (см. рис. 3); СППР с физическим ХД и с ВД (рис. 4).В случае архитектур с физическим ХД и/или ВД необходимо уделить внимание
вопросам организации (архитектуры) ХД и переносу данных из ОИД вХД.
По наблюдению исследовательской компании Forrester Research, большинство крупных компаний сталкивается со следующей проблемой: они накапливают огромное количество информации, которая никогда не используется. Практически в любой организации реально функционирует множество транзакционных систем, ориентированных на оперативную обработку данных (каждая для конкретного класса задач) и непрерывно пополняющих многочисленные базы данных . Кроме этого, зачастую предприятия владеют огромными объемами информации, хранящейся в т. н. унаследованных системах. Все эти данные распределены по сетям персональных компьютеров, хранятся на мэйнфреймах, рабочих станциях и серверах. Таким образом, информация есть, но она рассредоточена, несогласована, неструктурирована, зачастую избыточна и не всегда достоверна. Поэтому в большинстве организаций эти данные до сих пор не могут быть использованы для принятия критических бизнес-решений. На разрешение этого противоречия и направлена концепция хранилищ данных (Data Warehouse).
Билл Инмон, автор концепции, в своей классической статье «Что такое хранилища данных» (D2K Incorporated, 1996) определяет хранилища данных как «предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления». Он рассматривает хранилища как «единый и единственный источник истины», «центр вселенной» систем поддержки принятия решений (СППР). «Из хранилищ данных,– пишет он,– информация перетекает в различные отделы, отфильтровываясь в соответствии с заданными настройками СППР. Эти отдельные базы данных для принятия решений называются витринами данных».
В основе концепции хранилищ данных лежит идея объединения корпоративных данных, рассеянных по системам оперативной обработки данных, историческим архивам и другим внешним источникам. Эти источники могут содержать данные, не используемые непосредственно в СОД, но являющиеся жизненно необходимыми для СППР: законодательная база (включая налоговые прогнозы), планы развития отраслей, статистические данные, электронные справочники. Как показывает практика, решение, принятое на основе лишь внутренних данных, чаще всего оказывается некорректным.
Цель концепции хранилищ данных – прояснить отличия в характеристиках данных в операционных и аналитических системах, определить требования к данным, помещаемым в хранилище, определить общие принципы и этапы её построения, основные источники данных, дать рекомендации по решению потенциальных проблем, возникающих при их выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД хранилища.
Сравнение характеристик данных в информационных системах , ориентированных на операционную и аналитическую обработку данных
Характеристика | Операционные | Аналитические |
Частота обновления | Высокая частота, маленькими порциями | Малая частота, большими порциями |
Источники данных | В основном внутренние | В основном внешние |
Объемы хранимых данных | Сотни мегабайт, гигабайты | Гигабайты и терабайты |
Возраст данных | Текущие (за период от нескольких месяцев до одного года) | Текущие и исторические (за период в несколько лет, десятки лет) |
Назначение | Фиксация, оперативный поиск и преобразование данных | Хранение детализированных и агрегированных исторических данных, аналитическая обработка, прогнозирование и моделирование |
Основные требования к данным в хранилище данных
Предметная ориентированность | Все данные о некотором предмете (бизнес-объекте) собираются (обычно из множества различных источников), очищаются, согласовываются, дополняются, агрегируются и представляются в единой, удобной для их использования в бизнес-анализе форме. |
Интегрированность | Все данные о разных бизнес-объектах взаимно согласованы и хранятся в едином общекорпоративном хранилище |
Неизменчивость | Исходные (исторические) данные, после того как они были согласованы, верифицированы и внесены в общекорпоративное хранилище, остаются неизменными и используются исключительно в режиме чтения |
Поддержка хронологии | Данные хронологически структурированы и отражают историю за достаточный, для выполнения задач бизнес-анализа и прогнозирования, период времени. |
Предметом концепции хранилищ данных является не анализ данных, а собственно данные, т. е. концепция их подготовки для дальнейшего анализа. В то же время концепция хранилища данных определяет не просто единый логический взгляд на корпоративные данные, а реализацию единого интегрированного источника данных.
Модели анализа данных
Несмотря на то, что в сформулированной Б. Инмоном концепции хранилищ данных акцент делается на самих данных и выявлении их наиболее общих свойств, характерик и связей, понятно, что эти данные должны использоваться в процессе принятия бизнес-решений на всех уровнях, вплоть до корпоративных и межкорпоративных. К настоящему времени исторически сформировались две основные модели анализа данных, на которых основаны существующие аналитические СППР:
1. Статический анализ (DSS). Само понятие DSS (Decision Support Systems) собственно и переводится как СППР. До недавнего времени это была единственная аналитическая концепция. Результатом работы таких систем являлись строго регламентированные многостраничные отчеты, для формирования которых выполнялись длительные запросы, обрабатывающие колоссальные объемы данных. Такие запросы могли выполняться по нескольку часов, иногда десятки часов и даже сутками.
2. Оперативный анализ данных (OLAP). Автором концепции OLAP (On-Line Analytical Processing) является д-р Э. Кодд, сформулировавший в 1993 г. 12 основных требований к средствам реализации OLAP. Принципиальным отличием этой модели от традиционной статической DSS является концептуальное представление данных в виде многомерного куба. В то же время Э. Кодд показал потенциальные недостатки реляционного подхода в системах, ориентированным на анализ данных. Целью создания этой концепции являлась принципиальная возможность предоставления конечному пользователю средств формирования, обработки и выполнения нерегламентированных аналитических запросов с минимальным временем отклика системы. Необходимость возникновения этой новой концепции была предопределена тем фактором, что зачастую после получения стандартного отчета средствами DSS у аналитика появлялся новый вопрос или осознание того, что сам вопрос был сформулирован некорректно. В результате ему приходилось вновь долгое время ожидать получения очередного результата с тем, чтобы затем, возможно, вернуться к очередной итерации этого процесса.
Сравнение характеристик статического и динамического анализа
Характеристика | Статический анализ | Динамический анализ |
Типы вопросов | Сколько? Как? Когда? | Почему? Что будет, если?.. |
Время отклика | Не регламентируется | |
Типичные операции | Регламентированный отчет, диаграмма | Последовательность интерактивных отчетов, диаграмм, экранных форм. Динамическое изменение уровней агрегации и срезов данных. |
Уровень аналитических требований | ||
Тип экранных форм | В основном определенный заранее, регламентированный | Определяемый пользователем |
Уровень агрегации данных | Детализированные и суммарные | В основном суммарные |
Возраст данных | Исторические и текущие | Исторические, текущие и прогнозируемые |
Типы запросов | В основном предсказуемые | Непредсказуемые, от случая к случаю |
Назначение | Регламентированная аналитическая обработка | Многофункциональный анализ, моделирование и построение прогнозов |
Сегодня направление OLAP является, пожалуй, наиболее перспективным для решения аналитических задач управления. Средствами специально созданной службы OLAP Report первоначально сформулированные д-ром Коддом 12 требований были частично пересмотрены и существенно дополнены как базовыми, так и специальными возможностями, такими как выделение и обработка отсутствующих данных и др. Но по-прежнему ядром концепции OLAP является многомерное представление данных на концептуальном уровне.
Витрины данных
По классическому определению, витрина данных (Data Mart) представляет собой подмножество хранилища данных, отражающее специфику подразделения (бизнес-объект) и обеспечивающее повышенную производительность. Таким образом, витрина является звеном, на котором базируется конкретная аналитическая система для решения своего круга задач. Тем не менее возможна ситуация, когда некоторая область деятельности предприятия практически не коррелирует с другими, и возможно построить соответствующую витрину данных автономно, без привязки к корпоративному хранилищу. Тогда витрина будет пополняться данными непосредственно из оперативных систем обработки транзакций. Такие витрины данных получили название независимых, в отличие от классических зависимых от хранилища данных и пополняемых из него витрин.
В ряде случаев представляется целесообразным развернуть витрину данных вместо полностью сформированного хранилища. Витрины данных накладывают меньшие обязательства, они дешевле и проще в построении и базируются на более дешевых серверах, а не на мультипроцессорных комплексах. При таком подходе нет необходимости задействовать целую информационную систему корпорации и поддерживать сложные процедуры синхронного обновления витрины данных при обновлении хранилища. В то же время необходимо понимать, что при таком подходе витрины данных могут размножиться в целые комплексы независимых информационных баз данных, и естественно будет поставлена задача управления индивидуальными стратегиями поиска, обслуживания и восстановления. С другой стороны, строить единое корпоративное хранилище на основе множества независимых витрин данных значительно выгоднее, чем опираясь на рассеянные по системам обработки транзакций данные.
Так что же целесообразно применять: единое хранилище, самостоятельные витрины данных, хранилище с зависимыми витринами или другие варианты? Универсального ответа на вопрос о необходимости применения того или иного варианта не существует. В каждом случае оптимальный вариант определяется требованиями бизнеса, интенсивностью запросов, сетевой архитектурой, необходимой быстротой реакции и другими условиями.
Технология реализации хранилищ данных
При создании хранилища данных естественно придерживаться поэтапной разработки. Несмотря на то, что никакое описание процесса построения хранилища данных в виде последовательности фаз не может охватить все аспекты обратной связи с его потенциальными пользователями, менеджерами и аналитиками, тем не менее существуют некоторые базовые этапы, применимые к процессу построения корпоративной архитектуры:
1. Определение потребности конечных пользователей и построение модели бизнес-вопросов, на которые необходимо ответить.
2. Идентификация данных из корпоративных и внешних источников, которые будут питать хранилище или витрину данных.
3. Анализ источников данных и моделирование функций и процессов, которые эти источники охватывают. Усвоение правил, по которым действует бизнес – одно из важнейших условий построения хранилищ или витрин данных, так как именно на его основе устанавливается уровень детализации элементов в хранилище данных.
4. Определение процедур трансформации, очистки и логической интеграции данных источника перед их помещением в хранилище или витрину данных, а также регламентирование выполнения этих процедур, обновляющих хранилище данных.
5. Создание метаданных, описывающих источники и способы преобразования данных и логику хранилища данных. Репозиторий метаданных должен включать определения данных, бизнес-правила и детальную логику для моделирования разработки аналитических систем.
6. Формирование физических таблиц хранилища данных и его заполнение. Этот процесс может потребовать нескольких итераций с учетом возможного перепроектирования структур данных при анализе схемы данных хранилища.
7. Построение репозитория витрин данных, в которые войдут подмножества данных из хранилища и предварительно агрегированные данные. Часть метаданных будет описывать, каким образом первичные данные хранилища преобразуются, агрегируются и кэшируются в витринах данных.
8. Установка средств OLAP, прикладных систем, Web-серверов и всех необходимых инструментов и серверных программ, необходимых для доступа к данным, анализа и получения отчетов.
9. Установка на рабочие станции конечных пользователей клиентского программного обеспечения («толстый» клиент) или браузеров, поддерживающих стандартные форматы данных и Java-аплеты, а также необходимые расширения plug-in («тонкий» клиент) для доступа пользователей к данным.
После завершения процесса создания хранилища данных может показаться, что все уже сделано. На самом деле формирование хранилища представляет собой процесс, включающий также необходимые фазы постоянного надзора и сопровождения хранилища данных. Корректный надзор подразумевает не только поддержание корректности данных, но и обеспечение их секретности, особенно если доступ к данным хранилища осуществляется через Web. «Так как хранилище данных содержит одну из самых больших ценностей предприятия,– говорит Р. Тенлер, председатель компании Information Advantage,– данные должны быть в безопасности. Но чтобы осознать потенциальную ценность хранилища данных, организации придется предложить ее потенциальным покупателям».
Поддержание хранилища данных в хорошем состоянии в течение длительного времени является еще одной важнейшей задачей. Этот фактор становится особенно важным, когда число пользователей, обращающихся к системе, начинает расти. При этом, если в процессе проектирования хранилища данных информационными службами обычно проводится тщательная выверка данных, то с течением времени внимание людей обычно ослабевает, и хранилище данных может превратиться в свалку. Чтобы этого не происходило, необходимо назначить ответственных за поддержание качества данных, которые будут постоянно осуществлять верификацию информации, поступаемой из систем обработки транзакций, с данными в хранилище или витрине.
В заключение можно отметить, что процесс проектирования хранилища данных, используемого для предоставления необходимой информации в процессе принятия решений корпоративного и межкорпоративного уровня, является критически важным для жизнедеятельности предприятия. На этапе его реализации приходится обращать внимание не только на решение технических вопросов, но и на проблемы, связанные с человеческим фактором. Нельзя также забывать о необходимости постоянной оценки целесообразности предпринимаемых усилий. Кроме правильной цепочки управления проектом, необходимо на каждом этапе учитывать как потребности пользователей, так и наличие политических аспектов, которые могут затормозить проект. При грамотном подходе к решению этой задачи хранилище данных вскоре может стать частью коммерческой системы предприятия путем предоставления части сторонних пользователей за определенную плату возможности использования данных из некоторого подмножества хранилища. Такой подход позволит не только окупить работы по формированию хранилища данных, но и обеспечит новый канал поступления доходов.
Понятие хранилища данных
«Хранилище данных»- это предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений.
Данные в хранилище попадают из оперативных систем (OLTP-систем), которые предназначены для автоматизации бизнес-процессов. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов, различных справочников и т.д. Хранилище данных кроме детализированной информации содержит в себе агрегаты, т.е. обобщающую информацию, например суммы продаж, количество, общие расходы и т.д.
Хранилище налоговых данных следует рассматривать как центр информации, в котором автоматизируется расчет отложенных налогов, принимается и хранится информация из внешних источников, а данные преобразуются в удобный для пользователей формат. Такое хранилище представляет собой площадку для хранения точных и оперативных налоговых данных, которые могут быть извлечены и переданы во внешние приложения для целей анализа, аудита, планирования и прогнозирования.
Хранилище данных представляет собой репозитарий информационных ресурсов и обеспечивает консолидацию данных предприятия для целей отчетности и анализа. Данные и информация, как операционная, так и неоперационная, вводятся в хранилище обычно при помощи инструментов ETL из источников, данных по мере их появления или на регулярной основе. Трансформация данных позволяет своевременно обрабатывать запросы и анализировать их, что упрощает и ускоряет процесс выполнения запросов на информацию, изначально поступившую из других источников.
Преимущества, которые дает хранилище, включают возможность преобразования данных в качественную информацию, необходимую для подготовки налоговой отчетности и соблюдения налогового законодательства, для пользователей всех уровней. Любые заинтересованные лица – клиенты, партнеры, сотрудники, менеджеры и руководители – могут получать интерактивный контент когда угодно и где угодно.
Само наличие единого источника информации для подготовки налоговой отчетности и соблюдения налогового законодательства является большим шагом вперед для многих налоговых служб.
Зачем нужно строить хранилища данных - ведь они содержат заведомо избыточную информацию, которая и так находится в базах или файлах оперативных систем? Анализировать данные оперативных систем напрямую невозможно или очень затруднительно. Это объясняется различными причинами, в том числе разрозненностью данных и хранением их в форматах различных СУБД. Но даже если на предприятии все данные хранятся на центральном сервере БД, аналитик почти наверняка не разберется в их сложных, подчас запутанных структурах.
Таким образом, задача хранилища - предоставить «сырье» для анализа в одном месте и в простой, понятной структуре.
Есть и еще одна причина, оправдывающая появление отдельного хранилища - сложные аналитические запросы к оперативной информации тормозят текущую работу компании, надолго блокируя таблицы и захватывая ресурсы сервера.
Под хранилищем можно понимать не обязательно гигантское скопление данных - главное, чтобы оно было удобно для анализа.
Концепция хранилища данных
Автором концепции хранилищ данных (Data Warehouse) является Б. Инмон, который определил хранилища данных как: «предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления», призванные выступать в роли «единого и единственного источника истины», обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений. Схему хранилища данных можно представить следующим образом:
Физическая реализация данной схемы может быть самой разнообразной. Рассмотрим первый вариант - виртуальное хранилище данных, это система, предоставляющая доступ к обычной регистрирующей системе, которая эмулирует работу с хранилищем данных. Виртуальное хранилище можно организовать двумя способами. Можно создать ряд «представлений» (view) в базе данных или использовать специальные средства доступа к базе данных (например, продукты класса desktop OLAP).
Поскольку конструирование хранилища данных - сложный процесс, который может занять несколько лет, некоторые организации вместо этого строят витрины данных (data mart), содержащие информацию для конкретных подразделений. Например, маркетинговая витрина данных может содержать только информацию о клиентах, продуктах и продажах и не включать в себя планы поставок. Несколько витрин данных для подразделений могут сосуществовать с основным хранилищем данных, давая частичное представление о содержании хранилища. Витрины данных строятся значительно быстрее, чем хранилище, но впоследствии могут возникнуть серьезные проблемы с интеграцией, если первоначальное планирование проводилось без учета полной бизнес-модели. Это второй способ.
Построение полноценного корпоративного хранилища данных обычно выполняется в трехуровневой архитектуре. На первом уровне расположены разнообразные источники данных - внутренние регистрирующие системы, справочные системы, внешние источники (данные информационных агентств, макроэкономические показатели). Второй уровень содержит центральное хранилище, куда стекается информация от всех источников с первого уровня, и, возможно, оперативный склад данных, который не содержит исторических данных и выполняет две основные функции.
В основе концепции хранилищ данных лежат две основополагающие идеи:
1) интеграция ранее разъединенных детализированных данных в едином хранилище данных, их согласование и, возможно, агрегация:
· исторических архивов;
· данных из традиционных СОД;
· данных из внешних источников.
2) разделение наборов данных, используемых для операционной обработки, и наборов данных, применяемых для решения задач анализа.
Цель концепции хранилищ данных - выяснить требования к данным, помещаемым в целевую БД хранилища данных (Таблица 1), определить общие принципы и этапы ее построения, основные источники данных, дать рекомендации по решению потенциальных проблем, возникающих при их выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД.
Таблица 1. Основные требования к данным в Хранилище Данных.
| Предметная ориентированность | Все данные о некотором предмете (бизнес-объекте) собираются (обычно из множества различных источников), очищаются, согласовываются, дополняются, агрегируются и представляются в единой, удобной для их использования в бизнес-анализе форме. |
| Интегрированность | Все данные о разных бизнес-объектах взаимно согласованы и хранятся в едином общекорпоративном Хранилище. |
| Неизменчивость | Исходные (исторические) данные, после того как они были согласованы, верифицированы и внесены в общекорпоративное Хранилище, остаются неизменными и используются исключительно в режиме чтения. |
| Поддержка хронологии | Данные хронологически структурированы и отражают историю, за достаточный для выполнения задач бизнес-анализа и прогнозирования период времени. |
Предметом концепции хранилищ данных служат сами данные. После того как традиционная система обработки данных (СОД) реализована и начинает функционировать, она становится ровно таким же самостоятельным объектом реального мира, как и любой производственный процесс. А данные, которые являются одним из конечных продуктов такого производства, обладают ровно теми же свойствами и характеристиками, что и любой промышленный продукт: сроком годности, местом складирования (хранения), совместимостью с данными из других производств (СОД), рыночной стоимостью, транспортабельностью, комплектностью, ремонтопригодностью и т. д.
Именно с этой точки зрения и рассматриваются данные в хранилищах данных. То есть целью здесь являются не способы описания и отображения объектов предметной области, а собственно данные, как самостоятельный объект предметной области, порожденной в результате функционирования ранее созданных информационных систем.
Для правильного понимания данной концепции необходимо уяснение следующих принципиальных моментов:
· Концепция хранилищ данных - это не концепция анализа данных, скорее, это концепция подготовки данных для анализа.
· Концепция хранилищ данных не предопределяет архитектуру целевой аналитической системы. Она говорит о том, какие процессы должны выполняться в системе, но не о том, где конкретно и как эти процессы должны выполняться.
·Концепция хранилищ данных предполагает не просто единый логический взгляд на данные организации, а реализацию единого интегрированного источника данных.
Кроме единого справочника метаданных, средств выгрузки, агрегации и согласования данных, концепция хранилищ данных подразумевает: интегрированность, неизменчивость, поддержку хронологии и согласованность данных. И если два первых свойства (интегрированность и неизменчивость) влияют на режимы анализа данных, то последние два (поддержка хронологии и согласованность) существенно сужают список решаемых аналитических задач.
Без поддержки хронологии (наличия исторических данных) нельзя говорить о решении задач прогнозирования и анализа тенденций. Но наиболее критичными и болезненными оказываются вопросы, связанные с согласованием данных.
Основным требованием аналитика является даже не столько оперативность, сколько достоверность ответа. Но достоверность, в конечном счете, и определяется согласованностью. Пока не проведена работа по взаимному согласованию значений данных из различных источников, сложно говорить об их достоверности.
Нередко, менеджер сталкивается с ситуацией, когда на один и тот же вопрос, различные системы могут дать и обычно дают различный ответ. Это может быть связано как с несинхронностью моментов модификации данных, отличиями в трактовке одних и тех же событий, понятий и данных, изменением семантики данных в процессе развития предметной области, элементарными ошибками при вводе и обработке, частичной утратой отдельных фрагментов архивов и т. д. Очевидно, что учесть и заранее определить алгоритмы разрешения всех возможных коллизий мало реально. Тем более, это нереально сделать в оперативном режиме, динамически, непосредственно в процессе формирования ответа на запрос.
Похожая информация.
Читайте также:
|
Хранилище данных (ХД) – предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений.
В основе концепции ХД лежит идея разделения данных, используемых для оперативной обработки и для решения задач анализа. Такое разделение позволяет оптимизировать как структуры данных оперативного хранения (оперативные БД, файлы, электронные таблицы и т. п.) для выполнения операций ввода, модификации, удаления и поиска, так и структуры данных, используемые для анализа (для выполнения аналитических запросов).
В СППР (система поддержки принятия решений) эти два типа данных называются соответственно оперативными источниками данных(ОИД) и хранилищем данных.
Витрина данных(ВД) – это упрощенный вариант ХД, содержащий только тематически объединенные данные.
Свойства хранилищ данных:
Предметная ориентация (Это фундаментальное отличие ХД от ОИД. Разные ОИДмогут содержать данные, описывающие одну и ту же предметную область с разных точек зрения (например, с точки зрения бухгалтерского учета, складского учета, планового отдела и т. п.). Решение, принятое на основе только одной точки зрения, может быть неэффективным или даже неверным. ХД позволяют интегрировать информацию, отражающую разные точки зрения на одну предметную область.)
Интеграция (ОИД, как правило, разрабатываются в разное время несколькими коллективами с собственным инструментарием. Это приводит к тому, что данные, отражающие один и тот же объект реального мира в разных системах, описывают его по-разному. Обязательная интеграция данных в ХД позволяет решить эту проблему, приведя данные к единому формату.)
Поддержка хронологии (Данные в ОИД необходимы для выполнения над ними операций в текущий момент времени. Поэтому они могут не иметь привязки ко времени. Для анализа данных часто бывает важно иметь возможность отслеживать хронологию изменений показателей предметной области. Поэтому все данные, хранящиеся в ХД, должны соответствовать последовательным интервалам времени.)
Неизменяемость (Требования к ОИД накладывают ограничения на время хранения в них данных. Те данные, которые не нужны для оперативной обработки, как правило, удаляются из ОИД для уменьшения занимаемых ресурсов. Для анализа, наоборот, требуются данные за максимально большой период времени. Поэтому, в отличие от ОИД, данные в ХД после загрузки только читаются. Это позволяет существенно повысить скорость доступа к данным, как за счет возможной избыточности хранящейся информации, так и за счет исключения операций модификации.)
Можно выделить следующие архитектуры СППР с использованием ХД:
1) СППР с физическим (классическим) ХД. Такая модель неизбежно приводит к дублированию информации в ОИД и в ХД. Однако избыточность данных, хранящихся в СППР, не превышает 1 %.
Это можно объяснить следующими причинами:
При загрузке информации из ОИД в ХД данные фильтруются. Многие из них не попадают в ХД, поскольку лишены смысла с точки зрения использования в процедурах анализа.
Информация в ОИД носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В ХД, напротив, хранится историческая информация. С этой точки зрения дублирование содержимого ХД данными ОИД оказывается весьма незначительным. В ХД хранится обобщенная информация, которая в ОИД отсутствует.
Во время загрузки в ХД данные очищаются (удаляется ненужная информация), и после такой обработки они занимают гораздо меньший объем.
2) СППР с виртуальным ХД. Избыточность в данном варианте СППР сведена к нулю. В данном случае в отличие от классического (физического) ХД данные из ОИД не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются непосредственно при выполнении аналитических запросов в оперативной памяти компьютера. Фактически такие запросы напрямую адресуются к ОИД. Основными достоинствами виртуального ХД являются: минимизация объема памяти, занимаемой на носителе информацией; работа с текущими, детализированными данными.
Недостатки данного подхода:
Время обработки запросов к виртуальному ХД значительно превышает соответствующие показатели для физического хранилища.
Интегрированный взгляд на виртуальное хранилище возможен только при выполнении условия постоянной доступности всех ОИД. Таким образом, временная недоступность хотя бы одного из источников может привести либо к невыполнению аналитического запроса, либо к неверным результатам.
Выполнение сложных аналитических запросов над ОИД требует значительных ресурсов компьютеров.
Различные ОИД могут поддерживать разные форматы и кодировки данных. Часто на один и тот же вопрос может быть получено несколько вариантов ответа. Это может быть связано с:
– несинхронностью моментов обновления данных в разных ОИД;
– отличиями в описании одинаковых объектов и событий предметной области;
– ошибками при вводе;
– утерей фрагментов архивов и т. д.
В таком случае цель – формирование единого непротиворечивого взгляда на объект управления – может быть не достигнута.
Главный недостаток виртуального ХД - практическая невозможность получения данных за долгий период времени. При отсутствии физического хранилища доступны только те данные, которые на момент запроса есть в ОИД.
3) СППР с ВД. Достоинствами такого подхода являются:
Проектирование ВД для ответов на определенный круг вопросов;
Быстрое внедрение автономных ВД и получение отдачи;
Упрощение процедур заполнения ВД и повышение их производительности за счет учета потребностей определенного круга пользователей.
Недостатками автономных ВД являются:
Многократное хранение данных в разных ВД, что приводит к увеличению расходов на их хранение и потенциальным проблемам, связанным с необходимостью поддержания непротиворечивости данных;
Отсутствие консолидированности данных на уровне предметной области, а, следовательно – отсутствие единой картины.
4) СППР с ХД и ВД. В последнее время все более популярной становится идея совместить ХД и ВД в одной системе. В этом случае ХД используется в качестве единственного источника интегрированных данных для всех ВД.
ХД представляет собой единый централизованный источник информации для всей предметной области, а ВД являются подмножествами данных из хранилища, организованными для представления информации по тематическим разделам данной области.
Конечные пользователи имеют возможность доступа к детальным данным хранилища, если данных в витрине недостаточно, а также для получения более полной информационной картины.
Достоинствами такого подхода являются:
Простота создания и наполнения ВД, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных данных – из ХД;
Простота расширения СППР за счет добавления новых ВД;
Снижение нагрузки на основное ХД.
К недостаткам относятся:
Избыточность (данные хранятся как в ХД, так и в ВД);
Дополнительные затраты на разработку СППР с ХД и ВД.
