Краткий обзор архитектур ХД

Лекция 4. Краткий обзор архитектур ХД Разработка и построение корпоративного ХД — это дорогостоящая и трудоемкая задача. Успешность внедрения ХД во многом зависит от уровня информатизации бизнес-процессов в компании, установившихся информационных потоков, объема и структуры используемых данных, требований к скорости выполнения запро­сов и частоте обновления хранилища, характера решаемых аналитических задач и т. д. Чтобы приблизить ХД к условиям и специфике конкретной организации, в настоящее время разработано несколько архитектур хранилищ — реляционные, многомерные, гибридные и виртуальные. Реляционные ХД используют классическую реляционную модель, характерную для оперативных регистрирующих OLTP-систем. Данные хранятся в реляционных табли­цах, но образуют специальные структуры, эмулирующие многомерное представление данных. Такая технология обозначается аббревиатурой ROLAP — Relational OLAP. Многомерные Х Д реализуют многомерное представление данных на физическом уровне в виде многомерных кубов. Данная технология получила название MOLAP — Multidimensional OLAP. Гибридные Х Д сочетают в себе свойства как реляционной, так и многомерной модели данных. В гибридных ХД детализированные данные хранятся в реляцион­ных таблицах, а агрегаты — в многомерных кубах. Такая технология построения ХД называется HOLAP — Hybrid OLAP. Виртуальные Х Д не являются хранилищами данных в привычном понимании. В таких системах работа ведется с отдельными источниками данных, но при этом эмулируется работа обычного ХД. Иначе говоря, данные не консолидируются фи­зически, а собираются непосредственно в процессе выполнения запроса. Кроме того, все ХД можно разделить на одноплатформенные и кросс-платфор- менные. Одноплатформенные ХД строятся на базе только одной СУБД, а кросс- платформенные могут строиться на базе нескольких СУБД. Многомерные хранилища данных Основное назначение многомерных хранилищ данных (МХД) — поддержка систем, ориентированных на аналитическую обработку данных, поскольку такие хранилища лучше справляются с выполнением сложных нерегламентированных запросов. Многомерная модель данных, лежащая в основе построения многомерных хра­нилищ данных, опирается на концепцию многомерных кубов, или гиперкубов. Они представляют собой упорядоченные многомерные массивы, которые также часто называют OLAP-кубами (аббревиатура OLAP расшифровывается как On-Line Analytical Processing — оперативная аналитическая обработка). Технология OLAP представляет собой методику оперативного извлечения нужной информации из больших массивов данных и формирования соответствующих отчетов. Основы многомерного представления данных Сущность многомерного представления данных состоит в следующем. Большинство реальных бизнес-процессов описывается множеством показателей, свойств, атрибу­тов и т. д. Например, для описания процесса продаж могут понадобиться сведения о наименованиях товаров или их групп, о поставщике и покупателе, о городе, где производились продажи, а также о ценах, количествах проданных товаров и общих суммах. Кроме того, для отслеживания процесса во времени должен быть введен в рассмотрение такой атрибут, как дата. Если собрать всю эту информацию в таблицу, то она окажется сложной для визуального анализа и осмысления. Более того, она может оказаться избыточной: если, например, один и тот же товар продавался в один и тот же день в различных городах, то придется несколько раз повторить одно и то же соответствие «город — товар» с указанием различных суммы и количества. Все это способно окончательно запутать и сбить с толку любого, кто попытается извлечь из такой таблицы полезную информацию с целью анализа текущего состояния продаж и поиска путей оптимизации процесса торговли. Указанные проблемы возникают по одной простой причине: в плоской таблице хранятся многомерные данные. Примерно то же самое можно сказать об информации, представленной несколь­кими рядами данных. Каждый такой ряд (поле таблицы) можно рассматривать как своего рода информационное измерение, и тогда «плоская» таблица может быть интерпретирована как результат преобразования многомерной информационной структуры в совершенно несвойственную ей плоскую форму. Чтобы компенси­ровать потерю информации от исключения одного или нескольких измерений, приходится усложнять структуру таблицы, а это в большинстве случаев приводит к тому, что разобраться в ней становится очень сложно. Можно пойти другим путем — выполнить декомпозицию информации в не­ сколько более простых таблиц, связать их некоторым набором отношений и перейти к реляционной модели, которую используют классические базы данных. Однако доказано, что реляционная модель не является оптимальной с точки зрения задач анализа, поскольку предполагает высокую степень нормализации, в результате чего снижается скорость выполнения запросов. Поэтому разработка многомерной мо­дели представления данных, которая реализуется с помощью многомерных кубов, стала естественным шагом. Измерения и факты — базовые понятия многомерной модели данных В основе многомерного представления данных лежит их разделение на две груп­ пы — измерения и факты. Измерения — это категориальные атрибуты, наименования и свойства объ­ектов, участвующих в некотором бизнес-процессе. Значениями измерений являются наименования товаров, названия фирм-поставщиков и покупателей, ФИО людей, названия городов и т. д. Измерения могут быть и числовыми, если какой-либо категории (например, наименованию товара) соответствует числовой код, но в любом случае это данные дискретные, то есть принимающие значения из ограниченного набора. Измерения качественно описывают исследуемый бизнес-процесс. Факты — это данные, количественно описывающие бизнес-процесс, непрерыв­ные по своему характеру, то есть они могут принимать бесконечное множество значений. Примеры фактов — цена товара или изделия, их количество, сумма продаж или закупок, зарплата сотрудников, сумма кредита, страховое вознаграж­дение и т. д. Структура многомерного куба Многомерный куб можно рассматривать как систему координат, осями которой являются измерения, например Дата, Товар, Покупатель. По осям будут откла­дываться значения измерений — даты, наименования товаров, названия фирм-покупателей, ФИО физических лиц и т. д. В такой системе каждому набору значений измерений (например, «дата — то­ вар — покупатель») будет соответствовать ячейка, в которой можно разместить числовые показатели (то есть факты), связанные с данным набором. Таким обра­зом, между объектами бизнес-процесса и их числовыми характеристиками будет установлена однозначная связь. Рис.1 Принцип реализации многомерного куба Многомерный взгляд на измерения Дата, Товар и Покупатель представлен на рис.1. Фактами в данном случае могут быть Цена, Количество, Сумма. Тогда выделенный сегмент будет содержать информацию о том, сколько плит, на какую сумму и по какой цене приобрела фирма ЗАО «Строитель» 3 ноября. Рис.2 Измерения и факты в многомерном кубе Таким образом, информация в многомерном хранилище данных является ло­гически целостной. Это уже не просто наборы строковых и числовых значений, которые в случае реляционной модели нужно получать из различных таблиц, а це­лостные структуры типа «кому, что и в каком количестве было продано на данный момент времени». Преимущества многомерного подхода очевидны. • Представление данных в виде многомерных кубов более наглядно, чем сово­купность нормализованных таблиц реляционной модели, структуру которой представляет только администратор БД. • Возможности построения аналитических запросов к системе, использующей МХД, более широки. • В некоторых случаях использование многомерной модели позволяет значи­тельно уменьшить продолжительность поиска в МХД, обеспечивая выпол­нение аналитических запросов практически в режиме реального времени. В принципе, OLAP-куб может быть реализован и с помощью обычной ре­ляционной модели. В этом случае имеет место эмуляция многомерного пред­ставления совокупностью плоских таблиц. Такие системы получили название ROLAP — Relational OLAP. Использование многомерной модели данных сопряжено с определенными трудностями. Так, для ее реализации требуется больший объем памяти. Это связано с тем, что при реализации физической многомерности используется большое количество технической информации, поэтому объем данных, который может поддерживаться МХД, обычно не превышает нескольких десятков гига­байт. Кроме того, многомерная структура труднее поддается модификации; при необходимости встроить еще одно измерение требуется выполнить физическую перестройку всего многомерного куба. На основании этого можно сделать вывод, что применение систем хранения, в основе которых лежит многомерное представ­ление данных, целесообразно только в тех случаях, когда объем используемых данных сравнительно невелик, а сама многомерная модель имеет стабильный набор измерений. Работа с измерениями В процессе поиска и извлечения из гиперкуба нужной информации над его изме­рениями производится ряд действий, наиболее типичными из которых являются: • сечение (срез); • транспонирование; • свертка; • детализация. Сечение заключается в выделении подмножества ячеек гиперкуба при фиксировании значения одного или нескольких измерений. В результате сечения получается срез или несколько срезов, каждый из которых содержит информацию, связанную со значением измерения, по которому он был построен. Например, если выполнить сечение по значению ЗАО «Строитель» измерения Покупатель, Ю полученный в результате срез будет содержать информацию об истории про­даж всех товаров данного предприятия, которую можно будет свести в плоскую таблицу. При необходимости ограничить информацию только одним товаром (например, керамзитом) потребуется выполнить еще одно сечение, но теперь уже по значению Керамзит измерения Товар. Результатом построения двух срезов бу­дет информация о продажах одной фирме по одному товару. Манипулируя таким образом сечениями гиперкуба, пользователь всегда может получить информацию в нужном разрезе. Затем на основе построенных срезов может быть сформирована кросс-таблица и с ее помощью очень быстро получен необходимый отчет. Данная методика лежит в основе технологии OLAP-анализа. На рис. 3 схематично представлены сечения гиперкуба. Слева сечение вы­ полнено при некотором фиксированном значении измерения Дата. Полученный срез (светло-серая область) содержит информацию обо всех товарах и всех поку­пателях на определенную дату. На правом фрагменте рисунка получено два среза, пересечение которых будет содержать информацию обо всех покупателях, но на определенный товар и на определенную дату. Рис 3.Сечения куба Транспонирование (вращение) обычно применяется к плоским таблицам, полу­ченным, например, в результате среза, и позволяет изменить порядок представле­ния измерений таким образом, что измерения, отображавшиеся в столбцах, будут отображаться в строках, и наоборот. В ряде случаев транспонирование позволяет сделать таблицу более наглядной. Операции свертки (группировки) и детализации (декомпозиции) возможны только тогда, когда имеет место иерархическая подчиненность значений измере­ний. При свертке одно или несколько подчиненных значений измерений заменя­ются теми значениями, которым они подчинены. При этом уровень обобщения данных уменьшается. Так, если отдельные товары образуют группы, например Стройматериалы, то в результате свертки вместо отдельных наименований то­ варов будет указано наименование группы, а соответствующие им факты будут агрегированы. Проиллюстрируем результаты свертки: в табл. 1 представлена исходная таблица, а в табл. 2 — результат ее свертки по измерению Товар. Табл. 1. Исходная таблица Табл.2. Результат свертки исходной таблицы по измерению «Товар» Детализация — это процедура, обратная свертке; уровень обобщения данных уменьшается. При этом значения измерений более высокого иерархического уровня заменяются одним или несколькими значениями более низкого уровня, то есть вме­сто наименований групп товаров отображаются наименования отдельных товаров. Реляционные хранилища данных В начале 1970-х гг. англо-американский ученый Э. Кодд разработал реляционную модель организации хранимых данных, которая положила начало новому этапу эволюции СУБД. Благодаря простоте и гибкости реляционная модель стала доми­нирующей, а реляционные СУБД стали промышленным стандартом де-факто. ОПРЕДЕЛЕНИЕ Реляционная база данных (relational database) — совокупность отношений, содержащих всю информацию, которая должна храниться в базе. Физически это выражается в том, что информация хранится в виде двумерных таблиц, связанных с помощью ключевых полей. Применение реляционной модели при создании ХД в ряде случаев позволяет получить преимущества над многомерной технологией, особенно в части эффектив­ности работы с большими массивами данных и использования памяти компьютера. Па основе реляционных хранилищ данных (РХД) строятся ROLАР-системы, и эта идея тоже принадлежит Кодцу. В основе технологии РХД лежит принцип, в соответствии с которым измерения хранятся в плоских таблицах так же, как и в обычных реляционных СУБД, а факты (агрегируемые данные) — в отдельных специальных таблицах этой же базы данных. При этом таблица фактов является основой для связанных с ней таблиц измерений. Она содержит количественные характеристики объектов и событий, совокупность которых предполагается в дальнейшем анализировать. Схемы построения РХД На логическом уровне различают две схемы построения РХД — «звезда» и «сне­ жинка». При использовании схемы «звезда» центральной является таблица фактов, с которой связаны все таблицы измерений. Таким образом, информация о каждом измерении располагается в отдельной таблице, что упрощает их просмотр, а саму схему делает логически прозрачной и понятной пользователю Рис. 4. Схема построения РХД «звезда» Однако размещение всей информации об измерении в одной таблице оказы­вается не всегда оправданным. Например, если продаваемые товары объединены в группы (имеет место иерархия), то придется тем или иным способом показать, к какой группе относится каждый товар, что приведет к многократному повто­рению названий групп. Это не только вызовет рост избыточности, но и повысит вероятность возникновения противоречий (если, например, один и тот же т ошибочно отнесут к разным группам). Для более эффективной работы с иерархическими измерениями была разра­ботана модификация схемы «звезда», которая получила название «снежинка». Главной особенностью схемы «снежинка» является то, что информация об одном измерении может храниться в нескольких связанных таблицах. То есть если хотя бы одна из таблиц измерений имеет одну или несколько связанных с ней других таблиц измерений, в этом случае будет применяться схема «снежинки » Рис. 5. Схема построения РХД «снежинка» Основное функциональное отличие схемы «снежинка» от схемы «звезда» — это возможность работы с иерархическими уровнями, определяющими степень дета­лизации данных. В приведенном примере схема «снежинка» позволяет работать с данными на уровне максимальной детализации, например с каждым товаром отдельно, или использовать обобщенное представление по группам товаров с со­ ответствующей агрегацией фактов. Выбор схемы для построения РХД зависит от используемых механизмов сбора и обработки данных. Каждая из схем имеет свои преимущества и недостатки, ко­торые, однако, могут проявляться в большей или меньшей степени в зависимости от особенностей функционирования ХД в целом. К преимуществам схемы «звезда» можно отнести: • простоту и логическую прозрачность модели; • более простую процедуру пополнения измерений, поскольку приходится рабо­тать только с одной таблицей. Недостатками схемы «звезда» являются: • медленная обработка измерений, поскольку одни и те же значения измерений могут встречаться несколько раз в одной и той же таблице; • высокая вероятность возникновения несоответствий в данных (в частности, противоречий), например, из-за ошибок ввода. Преимуществами схемы «снежинка» являются следующие: • она ближе к представлению данных в многомерной модели; • процедура загрузки из РХД в многомерные структуры более эффективна и про­ ста, поскольку загрузка производится из отдельных таблиц; • намного ниже вероятность появления ошибок, несоответствия данных; • большая, по сравнению со схемой «звезда», компактность представления дан­ных, поскольку все значения измерений упоминаются только один раз. Недостатки схемы «снежинка»: • достаточно сложная для реализации и понимания структура данных; • усложненная процедура добавления значений измерений Кроме того, существует ряд технических особенностей, которые могут опреде­лить предпочтения разработчиков РХД при выборе схемы его построения. Преимущества и недостатки РХД Основные преимущества РХД следующие: • практически неограниченный объем хранимых данных; • поскольку реляционные СУБД лежат в основе построения многих систем опе­ративной обработки (OLTP), которые обычно являются главными источника­ ми данных для ХД, использование реляционной модели позволяет упростить процедуру загрузки и интеграции данных в хранилище; • при добавлении новых измерений данных нет необходимости выполнять слож­ную физическую реорганизацию хранилища, в отличие, например, от много­ мерных ХД; • обеспечиваются высокий уровень защиты данных и широкие возможности разграничения прав доступа. Главный недостаток реляционных хранилищ данных заключается в том, что при использовании высокого уровня обобщения данных и иерархичности измерений в таких хранилищах начинают «размножаться» таблицы агрегатов. В результате скорость выполнения запросов реляционным хранилищем замед­ляется. В то же время в многомерных хранилищах, где данные хранятся в виде много­ мерных кубов, эта проблема практически не возникает и в большинстве случаев удается достичь более высокой скорости выполнения запросов. Таким образом, выбор реляционной модели при построении ХД целесообразен в следующих случаях. • Значителен объем хранимых данных (многомерные ХД становятся неэффек­тивными). • Иерархия измерений несложная (другими словами, немного агрегированных данных). • Требуется частое изменение размерности данных. При использовании реляци­онной модели можно ограничиться добавлением новых таблиц, а для многомер­ной модели придется выполнять сложную перестройку физической структуры хранилища Гибридные хранилища данных Многомерная и реляционная модели хранилищ данных имеют свои преимущества и недостатки. Например, многомерная модель позволяет быстрее получить ответ на запрос, но не дает возможности эффективно управлять такими же большими объемами данных, как реляционная модель Логично было бы использовать такую модель ХД, которая представляла бы собой комбинацию реляционной и многомерной моделей и позволяла бы сочетать высокую производительность, характерную для многомерной модели, и возможность хранить сколь угодно большие массивы данных, присущую ре­ляционной модели. Такая модель, сочетающая в себе принципы реляционной и многомерной моделей, получила название гибридной, или HOLAP (Hybrid OLAP). Хранилища данных, построенные на основе HOLAP, называются гибридными хранилищами данных (ГХД) Главным принципом построения ГХД является то, что детализированные данные хранятся в реляционной структуре (ROLAP), которая позволяет хранить большие объемы данных, а агрегированные — в многомерной (MOLAP), которая позволяет увеличить скорость выполнения запросов (поскольку при выполнении аналитических запросов уже не требуется вычислять агрегаты). Рис.6. Гибридное ХД Недостатком гибридной модели является усложнение администрирования ХД из-за более сложного регламента его пополнения, поскольку при этом не­ обходимо согласовывать изменения в реляционной и многомерной структурах. Однако существует и ряд преимуществ, делающих гибридную модель ХД при­влекательной. • Хранение данных в реляционной структуре делает их в большей степени сис­ темно независимыми, что особенно важно при использовании в управлении предприятием экономической информации (показателей). • Реляционная структура формирует устойчивые и непротиворечивые опорные точки для многомерного хранилища • Поскольку реляционное хранилище поддерживает актуальность и корректность данных, оно обеспечивает очень надежный транспортный уровень для доставки информации в многомерное хранилище. Витрины данных С гибридной архитектурой ХД обычно связывают еще одно важное понятие — витрины данных (data marts). Ситуация, когда для анализа необходима вся инфор­мация, содержащаяся в ХД, возникает крайне редко. ОПРЕДЕЛЕНИЕ Витрина данных — специализированное локальное тематическое хранилище, подключен­ ное к централизованному ХД и обслуживающее отдельное подразделение организации или определенное направление ее деятельности. Рис.7. Консолидация с использованием витрин данных Использование витрин данных имеет следующие преимущества, делающие их ближе и доступнее конечному пользователю: • содержание данных, тематически ориентированных на конкретного пользова­теля; • относительно небольшой объем хранимых данных, на организацию и поддерж­ку которых не требуется значительных затрат; • улучшенные возможности в разграничении прав доступа пользователей, так как каждый из них работает только со своей витриной и имеет доступ только к ин­ формации, относящейся к определенному направлению деятельности. Виртуальные хранилища данных ОПРЕДЕЛЕНИЕ Виртуальным хранилищем данных называется система, которая работает с разрозненными источниками данных и эмулирует работу обычного хранилища данных, извлекая, преобразуя и интегрируя данные непосредственно в процессе выполнения запроса. Преимущества такого подхода очевидны • Появляется возможность анализа данных в OLTP-системе сразу после их по­ступления без ожидания загрузки в хранилище • Минимизируется объем требуемой дисковой и оперативной памяти, по­скольку отсутствует необходимость хранения исторических данных и много­ численных агрегированных данных для различных уровней обобщения информации. • Наличие в ВХД развитого семантического слоя позволяет аналитику полно­стью абстрагироваться от проблем, связанных с процессом извлечения данных из разнообразных источников, и сосредоточиться на решении задач анализа данных. Рис.8. Витрины данных Концепция ВХД имеет ряд недостатков по сравнению с ХД, где информация консолидируется физически. • Увеличивается нагрузка на OLTP-систему, потому что, помимо обычных поль­зователей, к ней обращаются аналитики с нерегламентированными запросами. В результате производительность OLTP-системы падает. • Источники данных, информация из которых запрашивается в ВХД, могут оказаться недоступными, если доступ к ним осуществляется по сети или если изменилось место их локализации. Временная недоступность хотя бы одного из источников может привести к невозможности выполнения запроса или к ис­кажению представленной по нему информации. • Отсутствует автоматическая поддержка целостности и непротиворечивости данных, могут быть утеряны отдельные фрагменты документов и т. Д • Данные в источниках хранятся в различных форматах и кодировках, что может привести к ошибкам при их обработке и к искажению информации, полученной в ответ на запрос. • Из-за возможной несогласованности моментов пополнения источников данных и из-за отсутствия поддержки в них хронологии по одному и тому же запросу в различные моменты времени могут быть получены отличающиеся данные. • Практически невозможна работа с данными, накопленными за долгий период времени, поскольку в ВХД доступны только те данные, которые находятся в источниках в конкретный момент времени.