3. Разработка хранилища данных
реклама
Оглавление Глоссарий .............................................................................................................. 2 Введение ............................................................................................................... 3 Постановка задачи ............................................................................................... 6 1. OLAP – средство оперативного анализа данных............................................. 7 1.1 Введение в OLAP .......................................................................................... 7 1.2 Хранилища данных .................................................................................... 13 1.3 Многомерная модель данных .................................................................. 17 1.3.1 Реализация многомерной модели данных ...................................... 26 1.4 Классификация OLAP-продуктов............................................................... 29 1.4.1 Классификация по способу хранения данных .................................. 30 1.4.2 Классификация по месту размещения OLAP-машины ..................... 31 2. Исследование возможностей современных OLAP-серверов ....................... 34 2.1 Выбор критериев для сравнения .............................................................. 36 2.2 Microsoft Analysis Services ......................................................................... 39 2.3 Oracle Essbase ............................................................................................ 41 2.4 IBM Cognos TM1 ......................................................................................... 42 2.5 Pentaho Mondrian ...................................................................................... 44 2.6 Jedox Palo ................................................................................................... 45 2.7 Результаты ................................................................................................. 47 Глоссарий OLTP (Online Transaction — Processing) обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа. OLTP-системы оптимизированы для небольших дискретных транзакций. Хранилище (ХД) (англ. Warehouse) данных — очень большая предметно-ориентированная Data информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации. Строится на базе клиент-серверной архитектуры, реляционной поддержки принятия СУБД решений. и утилит Данные, поступающие в хранилище данных, становятся доступны только для чтения. Введение Современные условия ведения бизнеса, характеризующиеся возрастающей жесткой конкуренцией и нестабильностью экономических условий, предъявляют повышенные требования к оперативности и качеству принимаемых решений на всех уровнях управления предприятием или организацией. Поддержка принятия решений предполагает владение актуальной всеобъемлющей информацией о состоянии и тенденциях развития бизнеса методами и средствами Business Intelligence (BI). При этом объем информации, которую необходимо учитывать для формирования оптимальных обоснованных решений, неуклонно растет. Это приводит к ситуации, когда становится невозможно эффективно управлять компанией без использования современных средств информационного обеспечения, а именно, методов и средств бизнесаналитики. Бизнес-аналитика - это такие технологии, дающие возможность организациям превращать накапливаемые данные в информацию о бизнесе, а затем информацию - в знания для управления бизнесом, объединяются под термином Business Intelligence или BI решения. За последние 20 лет информационно-аналитические системы меняли свои названия и содержание, пройдя путь от информационных систем руководителя (executive information systems, EIS) до систем поддержки принятия решений (decision support systems, DSS). Во времена больших ЭВМ и миникомпьютеров, когда у большинства пользователей не было прямого доступа к компьютерам, организации зависели от своих подразделений ИТ, которые обеспечивали их стандартными и параметрическими отчетами. Но чтобы получить отчеты, отличные от стандартных, пользователям нужно было заказывать их разработку и ждать в течение нескольких дней или недель. Приложения EIS были настроены на нужды руководителей и менеджеров и давали возможность получать основную агрегированную информацию о состоянии их бизнеса в виде таблиц или диаграмм. Обычно они включали регламентные запросы с набором параметров. Такие пакеты обычно разрабатывались силами своих подразделений ИТ. Для получения дополнительной информации и проведения дальнейшего анализа применялись другие приложения или создавались по заказу запросы или отчеты на языке SQL. Приложения DSS первого поколения были пакетами прикладных программ с динамической генерацией SQL-скриптов по типу запрашиваемой пользователем информации. Они позволяли аналитикам получать информацию из реляционных БД, не требуя знания языка SQL. В отличие от EIS приложения DSS могут отвечать на широкий спектр вопросов бизнеса, имеют несколько вариантов представления отчетов и определенные возможности форматирования. Однако гибкость таких пакетов все же была ограничена из-за ориентации на конкретный набор задач. С приходом ПК и локальных сетей следующее поколение приложений DSS строится уже на основе BI и позволяет пользователю-непрограммисту легко и оперативно извлекать информацию из различных источников, формировать собственные настраиваемые отчеты или графические представления, проводить многомерный анализ данных. Развитие систем бизнес-аналитики прошло путь от «толстых» клиентов до Web-приложений, в которых пользователь ведет исследование с помощью браузера и может работать удаленно. Сам термин «Business Intelligence» и его идея были предложены в 1989 году Говардом Дреснером – сотрудником исследовательской группы GartnerGroup. Он использовал термин BI для того, чтобы описать «процесс, который включает доступ и исследование информации, ее анализ, выработку интуиции и понимания, которые ведут к улучшенному и неформальному принятию решений». В основе технологий BI лежит организация доступа конечных пользователей и анализ структурированных количественных по своей природе данных и информации о бизнесе. BI порождает итерационный процесс бизнес-пользователя, включающий доступ к данным и их анализ, и тем самым проявление интуиции, формирование заключений, нахождение взаимосвязей, чтобы эффективно изменять предприятие в положительную сторону. BI имеет широкий спектр пользователей на предприятии, включая руководителей и аналитиков. Цель технологий BI - своевременно принимать решения, основываясь на корректных данных. Сегодня создание и внедрение BI технологий сформировалось в самостоятельное динамично развивающееся направление индустрии информационных технологий (ИТ). Из всех категорий BI-продуктов можно выделить следующие: Средства генерации отчётов и диаграмм (Reporting) Средства оперативной аналитической обработки данных (OLAP) Средства интеллектуального анализа данных (Data Mining) Средства переноса и интеграции данных (ETL) Как правило, вышеперечисленные средства объединяются в корпоративные BI-наборы (enterprise BI suites, EBIS). В данной ВКР рассматриваются технологии оперативной аналитической обработки данных (OLAP), а именно, исследуются подходы и инструменты к построению хранилищ данных, многомерных кубов и визуализации аналитической обработки данных. На основе многомерного результатов анализа управленческих исследований данных решений с в разрабатывается системе учётом поддержки модуль принятия финансово-экономических и производственно-технологических рисков предприятий. Данная система позволяет оценивать риски выполнения предприятиями радиоэлектронной промышленности государственных заказов и выдавать советы для принятия управленческих решений. ВКР разрабатывается в рамках НИР «Разработка методологии оценки финансово-экономических и технологических рисков выполнения предприятиями радиоэлектронной промышленности федеральных целевых программ и государственных оборонных заказов». Постановка задачи Перед автором данной работы была поставлена цель: разработать модуль многомерного оперативного анализа данных в системе поддержки принятия решений. В качестве системы поддержки принятия решений было предложено использовать систему поддержки принятия управленческих решений с учётом технологических финансово-экономических рисков для предприятий и производственнорадиоэлектронной промышленности. Для достижения этой цели перед автором были поставлены следующие задачи: 1. Провести исследование возможностей современных OLAPсерверов и на основании его выбрать наиболее подходящий для разрабатываемой системы. 2. Разработать хранилище данных и на его основе сформировать необходимые для анализа многомерные кубы. 3. Разработать модуль многомерного анализа данных в системе поддержки принятия решений. 1. OLAP – средство оперативного анализа данных 1.1 Введение в OLAP Трудно найти в компьютерном мире человека, который хотя бы на интуитивном уровне не понимал, что такое базы данных и зачем они нужны. В отличие от традиционных реляционных СУБД, концепция OLAP не так широко известна, хотя загадочный термин "кубы OLAP" слышали, наверное, почти все. Что же такое Online Analytical Processing? OLAP — это не отдельно взятый программный продукт, не язык программирования и даже не конкретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным. Аналитики — это особые потребители корпоративной информации, задача которых находить закономерности в больших массивах данных и делать выводы о текущем состоянии бизнеса. Аналитик не будет обращать внимания на отдельно взятый факт — ему нужна информация о сотнях и тысячах событий. Данные, которые требуются аналитику для работы, обязательно содержат числовые значения — это обусловлено самой сущностью его деятельности. Централизация и удобное структурирование хранимых данных предприятия — это далеко не все, что нужно аналитику. Ему также потребуется инструмент для просмотра и визуализации хранимой информации. Традиционные отчеты, даже построенные на основе единого хранилища, лишены одного — гибкости. Их нельзя «покрутить», «развернуть» или «свернуть», к ним нельзя применить фильтрацию, чтобы получить желаемое представление данных. Конечно, можно вызвать программиста, и он сделает новый отчет достаточно быстро - скажем, в течение часа. Но в современных условиях ведения бизнеса этого недостаточно. Оперативность в данном случае — один из факторов успеха. Аналитику нужен такой инструмент, который позволил бы визуализировать данные быстро, просто и удобно. В качестве такого инструмента и выступает OLAP. TODO вставить картинку с отчётом Термин OLAP (On-Line Analytical Processing) был предложен доктором Е.Ф. Коддом, его супругой С.Б. Кодд и их коллегой С.Т. Солли в исследовательской статье "OLAP для пользователей-аналитиков: информационно-технологический мандат". Эта статья была опубликована в начале 1993 года и спонсировалась корпорацией Arbor Software, создателем и распространителем первого OLAP-продукта Essbase. Статья определяет OLAP как «имя, данное динамическому анализу предприятия, необходимому для создания, манипулирования, оживления и синтезирования информации на базе "моделей информации о предприятии" ("Enterprise Data Models")». Основная цель OLAP-анализа — проверка возникающих гипотез. В 1993 году Кодд сформулировал «12 принципов аналитической обработки в реальном времени» (см. табл. 1.1): Таблица 1.1 № Принцип Описание п/п 1 Многомерное данных представление Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные. 2 Прозрачность Пользователь не должен знать о том, какие конкретные средства используются обработки для хранения данных, как и данные организованы и откуда они берутся. 3 Доступность Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником Средства должны автоматическое данных. обеспечивать отображение их собственной логической схемы в различные гетерогенные источники данных. 4 Согласованная Производительность практически не производительность должна зависеть от количества Измерений в запросе. 5 Поддержка архитектуры Средства клиент-сервер 6 должны работать в архитектуре клиент-сервер. Равноправность всех Ни одно из измерений не должно измерений быть базовым, все они должны быть равноправными (симметричными). 7 Динамическая обработка Неопределенные значения должны разреженных матриц храниться и обрабатываться наиболее эффективным способом. 8 Поддержка Средства должны обеспечивать многопользовательского возможность работать более чем режима работы с данными 9 одному пользователю. Поддержка операций на основе Все различных измерений многомерные (например, операции агрегация) единообразно и должны согласованно применяться к любому числу любых измерений. 10 Простота манипулирования Средства данными должны иметь максимально естественный удобный, и комфортный пользовательский интерфейс. 11 Развитые средства Средства представления данных должны поддерживать различные способы визуализации (представления) данных. 12 Неограниченное измерений число Не должно быть ограничений на и уровней число поддерживаемых измерений. агрегации данных В 1995 году на основе принципов, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям оперативного анализа данных: предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа; возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде; многопользовательский соответствующих доступ к механизмов данным с блокировок поддержкой и средств авторизованного доступа; многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это — ключевое требование OLAP); возможность обращаться к любой нужной информации независимо от ее объема и места хранения. Большинство из существующих OLAP-средств удовлетворяют всем этим требованиям. Однако в реализации подобных приложений возникает ряд проблем, прежде всего связанных с увеличением объёма данных, которые необходимо хранить. В настоящее время встречаются следующие применения OLAP: Анализ данных. Задача, для которой изначально использовались и до сих пор остаются самыми популярными OLAP-средства. Многомерная модель данных, возможность анализировать значительные объёмы данных и быстрый отклик на запросы делают подобные системы незаменимыми для анализа продаж, маркетинговых мероприятий, дистрибуции и других задач с большим объёмом исходных данных. Примеры продуктов: Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW, Oracle Essbase, Oracle OLAP, Cognos PowerPlay, MicroStrategy, Business Objects. Финансовое планирование\бюджетирование. Многомерная модель позволяет одновременно вводить данные и легко анализировать их (например, план-факт анализ). Поэтому ряд современных продуктов класса CPM (Corporate Performance Management) используют OLAP-модели. Важная задача – многомерный обратный расчёт (back-solve, breakback, writeback), позволяющий рассчитать требуемые изменения детальных ячеек при изменении агрегированного значения. Это инструмент для анализа «что-если» (what-if), т.е. для проигрывания различных вариантов событий при планировании. Примеры продуктов: Microsoft PerformancePint, Oracle EPB, Oracle OFA, Oracle Hyperion Planning, SAP SEM, Cognos Enterprise Planning, Geac. Финансовая консолидация. Консолидация данных согласно международным стандартам учёта, принимая во внимание доли владения, различные валюты и внутренние обороты – актуальная задача в связи с ужесточающимися требованиями проверяющих органов (SOX, Basel II) и выходом компаний на IPO (Initial Public Offering — первая публичная продажа акций частной компании). OLAP-технологии позволяют ускорить расчёт консолидированных отчётов и повысить прозрачность всего процесса. Примеры продуктов: Oracle FCH, Oracle Hyperion FM, Cognos Controller. Таким образом, OLAP – актуальная и востребованная тема исследований, её практические результаты имеют широкое применение. Несмотря на достаточно долгую историю исследований, до сих не существует единых терминологических стандартов, стандартов передачи данных, языка запросов и формирования кубов. Растущие объёмы корпоративных данных повышают значимость средств анализа, большая часть которых построена на OLAP-принципах, в связи с чем, актуальны проблемы выбора оптимальных схем хранения требующие и обработки совмещения OLAP-кубов. скорости ввода Задачи бюджетирования, транзакционных систем и аналитических возможностей OLAP, представляют собой особый класс систем, алгоритмическая база которых только создается. 1.2 Хранилища данных Причина использования OLAP — это скорость. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно. Более хорошей моделью для запросов, а не для изменения, является пространственная (часто называемая многомерной) БД. Представим себе ситуацию, что в какой-то момент времени с OLTPсистемой работают 1000 пользователей и один из них захотел построить сводный отчёт за относительно большой временной период. Запрос на построение такого рода отчётов, содержащий множество соединений таблиц, выполняется долго и во время выполнения блокирует остальных пользователей. Поэтому проектные решения современных информационноаналитических систем основываются не на одной базе данных, а на нескольких: в одной из них хранятся неизменяемые данные - такая БД называется хранилищем данных (ХД), а в остальных – данные, которые со временем могут измениться (оперативные данные) (рис. 1.1). Неизменяемые данные обычно используются для долговременного хранения статистической информации. Поэтому когда пользователь захочет построить сводный отчёт за большой временной период, то данные для этого отчёта будут приходить именно из хранилища данных и, соответственно, выполняющийся запрос не будет блокировать остальных пользователей. Рис.1.1 Источники информации для хранилищ данных Данные в хранилище данных могут поступать не только из операционных баз данных, но и из других источников, таких как XMLдокументы, Excel-таблицы и прочих текстовых документов. Данные загружаются в хранилище с определённой периодичностью (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей), поэтому актуальность данных несколько отстает от OLTP-систем. Таким образом, OLAP используется данные, находящиеся не в операционных БД, а в хранилищах данных. Задача хранилища - предоставить "сырье" для анализа в одном месте и в простой, понятной структуре. Автором концепции хранилищ данных является Б. Инмон, который определил хранилища данных как: "предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления", призванные выступать в роли "единого и единственного источника истины", обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений. В основе концепции хранилищ данных лежат две основополагающие идеи: Интеграция ранее разъединенных детализированных данных в едином хранилище данных, их согласование и, возможно, агрегация: o исторических архивов; o данных из традиционных систем обработки данных; o данных из внешних источников. Разделение наборов данных, используемых для операционной обработки, и наборов данных, применяемых для решения задач анализа. Цель концепции хранилищ данных - выяснить требования к данным, помещаемым в целевую БД хранилища данных (см. табл. 1.2), определить общие принципы и этапы ее построения, основные источники данных, дать рекомендации по решению потенциальных проблем, возникающих при их выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД. Таблица 1.2. Основные требования к данным в хранилище данных. Требование Комментарий Предметная Все данные о некотором предмете (бизнес- ориентированность объекте) собираются (обычно из множества различных источников), очищаются, согласовываются, дополняются, агрегируются и представляются в единой, удобной для их использования в бизнес-анализе форме. Интегрированность Все данные о разных бизнес-объектах взаимно согласованы и хранятся в едином общекорпоративном хранилище. Неизменчивость Исходные (исторические) данные, после того как они были согласованы, верифицированы и внесены в остаются общекорпоративное неизменными и хранилище, используются исключительно в режиме чтения. Поддержка хронологии Данные хронологически отражают выполнения историю, задач за структурированы и достаточный для бизнес-анализа и прогнозирования период времени. Без поддержки хронологии (наличия исторических данных) нельзя говорить о решении задач прогнозирования и анализа тенденций. Но наиболее критичными и болезненными оказываются вопросы, связанные с согласованием данных. Основным требованием аналитика является даже не столько оперативность, сколько достоверность ответа. Но достоверность, в конечном счете, определяется согласованностью данных. Пока не проведена работа по взаимному согласованию значений данных из различных источников, сложно говорить об их достоверности. Хранилища данных бывают двух типов: корпоративные хранилища данных (enterprise data warehouses) и витрины данных (data marts). Первые содержат информацию, относящуюся ко всей корпорации и собранную из множества оперативных источников для консолидированного анализа. Обычно такие хранилища охватывают целый ряд аспектов деятельности корпорации и используются для принятия тактических и стратегических решений. Корпоративное хранилище содержит как детальную, так и суммарную информацию и в объеме может достигать от (условно) 50 Гб до одного или нескольких терабайт. Стоимость создания и поддержки корпоративных хранилищ может быть очень высокой. Обычно их созданием занимаются централизованные отделы информационных технологий, причем создаются они сверху вниз, т.е. сначала проектируется общая схема и лишь затем заполняется данными. Построение такого хранилища может длиться несколько лет. Витрины данных содержат подмножества корпоративных данных и строятся для отделов или подразделений внутри организации. Витрины часто строятся силами самого отдела и охватывают конкретный аспект, интересующий сотрудников данного отдела. Витрина может получать данные из корпоративного хранилища (зависимая витрина данных, dependent data mart) или, что вероятнее, данные могут поступать прямо из оперативных источников (независимая витрина данных, independent data mart). Витрины и хранилища данных строятся по сходным принципам и используют практически одинаковые технологии. Структуры данных хранилища заметно отличаются от применяемых в OLTP-системах. Это в первую очередь определяется предметной ориентированностью хранилища: данные организованы вокруг того или иного аспекта деятельности предприятия. В следующей главе речь пойдёт о многомерной модели данных, на которой основаны хранилища данных. 1.3 Многомерная модель данных Многомерная модель данных — это расширение реляционной модели. В отличие от реляционной модели, где основным понятием является «отношение», в многомерной модели основным понятием является многомерный «куб» (нередко называемый также OLAP-кубом), который является обобщением реляционных таблиц на любое число измерений. Набор соответствующих кубов составляет многомерную базу данных. Многомерная модель данных не рассчитана на частое выполнение транзакций, но очень удобна именно для анализа больших массивов данных. Она наиболее адекватна представлениям о предметной области, которыми оперирует аналитик или управленец. Некоторые преимущества многомерной модели по сравнению с реляционной: Возможность анализа больших объемов данных с приемлемой скоростью; Возможность осуществления любых «срезов» и «углублений» в определённой структуре БД; Быстрая локализация трендов и проблемных областей. Многомерные модели данных имеют три важных области применения, связанных с проблематикой анализа данных: 1. Хранилища данных интегрируют для анализа информации из нескольких источников. 2. Системы оперативной аналитической обработки OLAP позволяют оперативно получить ответы на запросы, охватывающие большие объемы данных в поисках общих тенденций. 3. Приложения добычи данных служат для выявления знаний за счет полуавтоматического поиска ранее неизвестных шаблонов и связей в базах данных. Многомерный куб представлен набором мер и измерений, а именно, куб — это декартовое произведение измерений, где для каждого элемента произведения проставлен набор мер. Измерения куба – набор доменов, по которым создаётся многомерное пространство. Другими словами, измерение – это упорядоченный набор значений, соответствующий грани куба. Многомерное моделирование предусматривает использование измерений для предоставления максимальной информативности. В отличие от реляционных баз данных, контролируемая избыточность в многомерных базах данных, в общем, считается оправданной, если она увеличивает информационную ценность. Измерения используются для выбора и агрегирования данных на требуемом уровне детализации. Измерения организуются в иерархию, состоящую из нескольких уровней, каждый из которых представляет уровень детализации, требуемый для соответствующего анализа. Иногда бывает полезно определять несколько иерархий для измерения. Например, модель может определять время, как в финансовых годах, так и в календарных. Несколько иерархий совместно используют один или несколько общих, самых низких уровней, например, день и месяц, и модель группирует их в несколько более высоких уровней — финансовый квартал и календарный квартал. Чтобы избежать дублирования определений, метаданные многомерной базы данных определяют иерархию измерений. Отметим, что иерархии могут быть сбалансированными (balanced, т.е. иерархии имеют одинаковую высоту по всем ветвям, а каждое значение не корневого уровня — только одного родителя), как, например, иерархия, представленная на рис. 1.2 и несбалансированными (unbalanced). Типичный пример несбалансированной иерархии — иерархия типа "начальник— подчиненный", представлен на рис. 1.3 Рис. 1.2 Сбалансированная иерархия измерений Рис. 1.3 Несбалансированная иерархия измерений Иногда для таких иерархий используется термин Parent-child hierarchy. Существуют также иерархии, занимающие промежуточное положение между сбалансированными и несбалансированными (они обозначаются термином ragged — "неровный"). Обычно они содержат такие члены, логические "родители" которых находятся не на вышестоящем уровне (см. рис. 1.4). Рис. 1.4 "Неровная" иерархия измерений непосредственно Отметим, что несбалансированные и "неровные" иерархии поддерживаются далеко не всеми OLAP-средствами. Различным в разных OLAP-средствах может быть и число уровней иерархии, и максимально допустимое число членов одного уровня, и максимально возможное число самих измерений. В отличие от линейных пространств, с которыми имеет дело алгебра матриц, многомерные модели, как правило, не предусматривают функций упорядочивания или расстояния для значений измерения. Единственное «упорядочивание» состоит в том, что значения более высокого уровня содержат значения более низких уровней. Однако для некоторых измерений, таких как время, упорядоченность значений размерности может использоваться для вычисления совокупной информации, такой как общий объем продаж за определенный период. В кубе, изображенном на рис.1.5, содержится 3 измерения – «Доставка» (характеризует вид доставки), «Отправка» (географическое местонахождение получателя посылки) и «Время» (время совершения факта отправки посылки). Каждое измерение содержит иерархию измерений, например, измерение «Отправка» состоит из отправки в восточное полушарие и в западное. В свою очередь, восточное полушарие состоит из Африки, Азии, Австралии и Европы, а западное – из Северной и Южной Америк. Рис.1.5 Пример многомерного куба Как было сказано выше, многомерная модель данных предназначена для анализа информации. Единицей анализируемой информации считается когда-либо произошедший факт, т.е. факты представляют субъект — некий шаблон или большинстве событие, которые многомерных необходимо моделей проанализировать. данных факты В однозначно определяются комбинацией значений измерений. Факт существует только тогда, когда ячейка для конкретной комбинации значений не пуста. Каждый факт обладает некоторой гранулярностью, определенной уровнями, из которых создается их комбинация значений измерений. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся: факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата); факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки); факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей). Мера (или показатель) – это значение, которое определяется фиксированным набором измерений и однозначно количественно характеризует анализируемые факты. В вышеприведенном примере мерами являются количество отправленных посылок и время отправки последней посылки. Так можно сказать, что в Европу в четвертом квартале 1999 года было отправлено 696 посылок, и последняя была отправлена 15.12.99. Меры бывают трёх типов: Аддитивные (additive) меры – допускающие агрегирование относительно любого измерения куба данных; Неаддитивные (nonadditive) меры – которые не могут агрегироваться ни по какому измерению куба данных; Полуаддитивные (semiadditive) меры – которые допускают агрегирование относительно одних измерений и не допускают относительно других. Многомерная база данных естественным образом предназначена для определенных типов запросов: Запросы вида slice и dice (срезы куба) — формирование подмножества многомерного массива данных, соответствующего единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. Если рассматривать термин slice с позиции конечного пользователя, то наиболее часто его роль играет двумерная проекция куба (рис. 1.6). Срез dice отличается от slice тем, что это трёхи более-мерная проекция куба. Фиксированное значение Срез Рис. 1.6 Операция среза (slice) Запросы вида drill-down (детализация) и roll-up (обобщение) — взаимообратные операции, которые используют иерархию измерений и меры для агрегирования. Направление детализации/обобщения может быть задано как по иерархии отдельных измерений, так и согласно прочим отношениям, установленным в рамках измерений или между измерениями. Например, если при анализе данных об объемах продаж в Северной Америке выполнить операцию drill-down для измерения "Регион", то на экране будут отображены такие его элементы как "Канада", "Восточные Штаты Америки" и "Западные Штаты Америки". В результате дальнейшей детализации элемента "Канада" будут "Монреаль" и т. д отображены элементы "Торонто", "Ванкувер", Запросы вида drill-across комбинируют кубы, которые имеют одно или несколько общих измерений. С точки зрения реляционной алгебры такая операция выполняет слияние (join). Запросы вида ranking возвращают только те ячейки, которые появляются в верхней или нижней части упорядоченного определенным образом списка. Поворот (rotating) куба дает пользователям возможность увидеть данные, сгруппированные по другим измерениям (рис. 1.7). Например, операция вращения может заключаться в перестановке местами строк и столбцов таблицы или перемещении интересующих измерений в столбцы или строки создаваемого отчета, что позволяет придавать ему желаемый вид. Измерение1 Измерение2 Измерение2 Измерение1 Вращение Измерение3 Измерение3 Рис. 1.7 Операция вращения Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию. Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации. За 30 лет с момента своего возникновения технология многомерных баз данных прошла серьезную эволюцию. С недавних пор она стала реализовываться в решениях, предназначенных для массового рынка, а ведущие производители теперь выпускают многомерные ядра вместе со своими реляционными базами данных. Данные, которые необходимо анализировать, становятся все более распределенными. К примеру, это часто необходимо для выполнения анализа, при котором используются данные в формате XML, получаемые с определенных веб-сайтов. Растущая распределенность данных, в свою очередь, требует применения методов, которые позволяют легко добавлять новые данные в многомерные базы данных, тем самым, упрощая задачу создания интегрированного хранилища данных. Технология многомерных баз данных также применяется к новым типам данных, которые современные технологии зачастую не в состоянии адекватно анализировать. Наконец, технология многомерных баз данных все больше будет применяться там, где результаты анализа напрямую передаются в другие системы, тем самым, исключая участие человека в этом процессе. 1.3.1 Реализация многомерной модели данных Многомерная структура хранения данных может быть реализована с помощью многомерных БД или в системе управления реляционными БД с использованием схемы звезды (star schema) или схемы снежинки (snowflake schema). Схема звезды (рис. 1.8) является практически реляционным воплощением многомерной представления данных. Она является проекцией куба на «реляционную плоскость» и состоит из одной таблицы фактов (fact table) и нескольких таблиц измерений (dimension table). Таблица фактов содержит по одной строке для каждого факта — минимально рассматриваемого атома анализируемого процесса. Рис.1.8 Схема звезды Например, для оптового склада фактом может служить факт продажи изделий. Полями таблицы фактов, помимо ключей, являются меры (measures), описывающие количественную характеристику факта, например, выручка от продажи изделий или количество проданных изделий. Таблицы измерений содержат собственно значения измерений, то есть информацию, характеризующую факты. Обычно это неизменяемые, либо редко изменяемые данные. Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов. Типичными измерениями процесса продажи будут «Покупатель», «Издание», «Время». Время является несколько особенным и практически необходимым измерением любого хранилища данных. Схема звезды не соответствует требованиям нормальной формы. С точки зрения нормализации таблицы измерений хранят избыточные данные. Но избыточность оправдывается двумя соображениями. Во-первых, такая схема понятнее конечному пользователю. Во-вторых, запросы по БД будут выполняться быстрее за счет уменьшения количества таблиц, объединяемых в одном запросе. Рис.1.9 Схема снежинки Схема снежинки является модификацией схемы звезды, как бы уступкой нормализации — здесь часть таблиц измерений разбита на несколько связанных таблиц (рис. 1.9). В случае если в нескольких измерениях повторяются одни и те же данные (например, адрес может встречаться и в измерении «Покупатель» и «Распространитель») необходимо выделить общее географическое измерение, содержащее атрибуты «географических точек». Благодаря частичной нормализации, «снежинка» позволяет сэкономить дисковое пространство, но она уменьшает скорость просмотра измерений. Решение в сторону использования схемы звезды или схемы снежинки, обуславливается относительной мощностью платформы БД, и инструментария для реализации запросов. Схема снежинки подходит окружению, в котором инструментарий реализации запросов предоставляет пользователям широкий доступ к структуре таблиц, а также в окружениях, где большинство запросов просты по своей природе. Схема звезды более подходит для случаев применения более сложного инструментария для реализации запросов, который в большей степени изолирует пользователей от детальной структуры таблиц, а также для среды с множеством запросов сложной структуры. 1.4 Классификация OLAP-продуктов Итак, суть OLAP заключается в том, что исходная для анализа информация представляется в виде многомерного куба, и обеспечивается возможность произвольно манипулировать ею и получать нужные информационные разрезы - отчеты. При этом конечный пользователь видит куб как многомерную динамическую таблицу, которая автоматически суммирует данные (факты) в различных разрезах (измерениях), и позволяет интерактивно управлять вычислениями и формой отчета. Выполнение этих операций обеспечивается OLAP-машиной (или машиной OLAP-вычислений). На сегодняшний день в мире разработано множество продуктов, реализующих OLAP-технологии. Чтобы легче было ориентироваться среди них, используют классификации OLAP-продуктов: по способу хранения данных для анализа и по месту нахождения OLAP-машины. Рассмотрим подробнее каждую категорию OLAP-продуктов. 1.4.1 Классификация по способу хранения данных Начнем рассмотрение с классификации по способу хранения данных. Часто в многомерных хранилищах данных содержатся и агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных — сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому, обычно, при загрузке данных в многомерную БД вычисляются и сохраняются некоторые агрегатные данные. И исходные и агрегатные данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP). Соответственно, OLAPпродукты по способу хранения данных делятся на три аналогичные категории: в случае MOLAP, исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе; в ROLAP-продуктах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-средства; в случае использования HOLAP архитектуры исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAP-средства на основе реляционных и многомерных данных. Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о «взрывном росте» объема данных). Если говорить более точно, степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов. Некоторые OLAP-продукты поддерживают хранение данных только в реляционных структурах, некоторые — только в многомерных. Однако большинство современных серверных OLAP-продуктов поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов. 1.4.2 Классификация по месту размещения OLAP-машины Следующая классификация - по месту размещения OLAP-машины. По этому признаку OLAP-продукты делятся на OLAP-серверы и OLAP-клиенты: в серверных OLAP-средствах вычисления и хранение агрегатных данных выполняются отдельным процессом – OLAP-сервером. Клиентское приложение получает только результаты запросов к многомерным кубам, которые хранятся на сервере; OLAP-клиент устроен по-другому. Построение многомерного куба и OLAP-вычисления выполняются в памяти клиентского компьютера. Сравним серверные и клиентские OLAP-средства по эксплуатационным и стоимостным показателям: 1. Объем обрабатываемых данных. Объем данных определяется совокупностью следующих характеристик: количество записей, количество измерений, количество элементов измерений, длина измерений и количество фактов. OLAP-сервер может обрабатывать большие объемы данных, чем OLAP-клиент при равной мощности компьютера. Это объясняется тем, что OLAP-сервер хранит на жестких дисках многомерную базу данных, содержащую заранее вычисленные кубы. Клиентские программы в момент выполнения OLAP-операций выполняют к ней запросы на SQL-подобном языке, получая не весь куб, а его отображаемые фрагменты. OLAP-клиент в момент работы должен иметь в оперативной памяти весь куб. Таким образом, объем данных, обрабатываемых OLAP-клиентом, находится в прямой зависимости от объема оперативной памяти ПК пользователя. 2. Производительность системы. Эта характеристика определяется следующими факторами: объемом обрабатываемых данных и мощностью компьютеров. При возрастании количества измерений производительность всех OLAP-средств снижается за счет значительного увеличения количества агрегатов, но при этом темпы снижения разные. Продемонстрируем эту зависимость на графике (рис. 1.10): Рис. 1.10 Зависимость времени отклика OLAP-средства от объема обрабатываемых данных Скоростные характеристики OLAP-сервера менее чувствительны к росту объема данных. Это объясняется различными технологиями обработки запросов пользователей OLAP-сервером и OLAP-клиентом. Например, при операции детализации OLAP-сервер обращается к хранимым данным и "вытягивает" данные этой "ветки", в то время как OLAPклиент вычисляет весь набор агрегатов в момент загрузки. 3. Сетевой трафик. При использовании OLAP-сервера по сети на ПК клиента передаются только данные для отображения, в то время как OLAP-клиент получает весь объем данных первичной выборки. Поэтому там, где применяется OLAP-клиент, сетевой трафик будет выше. Но, при применении OLAP-сервера операции пользователя, например детализация, порождают новые запросы к многомерной базе, а, значит, новую передачу данных. Выполнение же OLAPопераций OLAP-клиентом производится в оперативной памяти и, соответственно, не вызывает новых потоков данных в сети. Также необходимо отметить, что современное сетевое оборудование обеспечивает высокий уровень пропускной способности. 4. Затраты на внедрение и сопровождение. Стоимость OLAP-сервера достаточно высока. Дополнительно следует учитывать стоимость выделенного сервера и постоянные затраты на администрирование многомерной базы. Кроме того, внедрение и сопровождение OLAPсервера требует от персонала достаточно высокой квалификации. Стоимость OLAP-клиента на порядок ниже стоимости OLAP-сервера. Администрирования и дополнительного технического оборудования под OLAP-клиент не требуется. К квалификации персонала при внедрении OLAP-клиента высоких требований не предъявляется. OLAPклиент может быть внедрен значительно быстрее OLAP-сервера. Разрабатываемая система поддержки принятия управленческих решений по требованию заказчика должна быть исполнена в виде тонкого клиента (веб-приложения), поэтому в такой системе может быть использован только OLAP-сервер, а не OLAP-клиент. Перед автором ВКР стояла задача провести исследование возможностей современных OLAP-серверов разрабатываемой системы. и выбрать наиболее подходящий Следующая глава посвящена для решению поставленной задачи. 2. Исследование возможностей современных OLAP- серверов На сегодняшний день существует множество поставщиков OLAPсерверов. Все крупные поставщики СУБД, такие как Oracle, Microsoft, IBM, Sybase, выпускают также и OLAP-сервера к своим СУБД. Помимо крупнейших производителей СУБД на рынке OLAP-продуктов фигурируют и другие компании, работающие в области Business Intelligence, такие как MicroStrategy, Pentaho, SAS Institute, Jedox. Все современные OLAP-серверы удовлетворяют принципам аналитической обработки в реальном времени, изложенным Коддом в 1993 году (см. гл. 1.1), а позднее дополненными в 1995 году. Основными проблемами использования OLAP-серверов являются проблемы производительности, разреженности данных и «взрыва» данных. Проблема производительности связана к требованию к OLAP-продукту – времени отклика сервера (которое должно быть не более 5 с). Такое время сложно достичь, учитывая, что часто объём анализируемых данных превышает миллионы записей. Производители по-разному решают данную проблему, но в основном, решения основываются на кешировании сосчитанных агрегатов, либо на предварительном их вычислении и хранении в базе данных. Второй способ решения проблемы производительности порождает новую проблему – проблему эффекта «взрыва данных», т.е. к резкому увеличению объёма хранимых данных, т.к. количество хранимых агрегатов растёт в экспоненциальной зависимости от числа измерений в кубе. Синдром взрыва может приводить к еще большим проблемам при разреженном распределении исходных данных по многомерному кубу. Отсутствующие или недопустимые значения данных создают разрежение в модели данных OLAP. Наиболее удачные OLAP-серверы борются с этой проблемой, не сохраняя пустые значения, таким образом, даже плохо заполненные кубы «не раздуваются» в объеме. OLAP-серверы отличаются друг от друга гораздо больше, чем, например, реляционные базы данных, языки программирования или текстовые редакторы, что весьма увеличивает возможность ошибки при выборе OLAP-сервера. Все современные OLAP-серверы могут работать одновременно с несколькими кубами, поддерживать работу с большим числом измерений, мер и иерархий. Некоторые продукты поддерживают несколько иерархий для измерения, несбалансированные иерархии, полуаддитивные меры и некоторые другие функции, такие как «write-back», позволяющую аналитику изменить какое-либо значение в таблице-отчёте (это нужно, например, для прогнозирования - узнать, как изменится отчёт, если поменять значение в указанной ячейке) и сохранить его в хранилище данных. У каждого продукта свои протоколы обмена информацией и языки запросов к многомерным кубам, т.к. в области OLAP до сих пор нет каких-либо стандартизованных протоколов обмена информацией, но почти каждый OLAP-сервер также поддерживает стандарты «де факто» обмена информацией – XMLA (XML for Analysis) и языка запросов к многомерным данным фирмы Microsoft – MDX (Multidimensional Expressions). В виду достаточно большого количества производителей OLAPсерверов было принято решение рассмотреть только наиболее известные и долго работающие на рынке фирмы, а также ряд бесплатных продуктов. Таким образом, были выбраны следующие продукты (табл. 2.1): Таблица 2.1. Исследуемые OLAP-сервера № Фирма-производитель Название OLAP-сервера 1 Microsoft Analysis Services 2 Oracle Essbase 3 IBM Cognos TM1 4 Pentaho Mondrian 5 Jedox Palo 2.1 Выбор критериев для сравнения Для исследования возможностей и сравнения OLAP-серверов нужно определить критерии, по которым данные продукты можно сравнивать. При выборе критериев автор ВКР исходил, прежде всего, из требований к разрабатываемой системе, а также некоторых решений, принятых в ходе проектирования системы: система принятия решений реализуется как клиент-серверное приложение, причём клиент – это веб-браузер пользователя, т.е. тонкий клиент; в системе используется БД PostgreSQL; не исключено, что в системе будут использоваться и другие источники данных, например, таблицы Excel; объём входной информации для анализа – средний, не превышает 100 тыс. записей; изменчивость данных – исходные данные изменяются нечасто; число пользователей разрабатываемой системы – не более 50; система будет развёрнута в ведомственной локальной сети с большой скоростью передачи данных (100 Мбит/с); система (серверная часть) разрабатывается на языке программирования Java; разрабатываемая система развёртывается в Unix-подобной среде; система визуализации OLAP-анализа будет реализована с использованием продукта JPalo; система принятия решений достаточно сложная система с точки зрения математических вычислений – в ней используются элементы теории вероятностей и статистики, т.е. многие параметры, подлежащие дальнейшему OLAP-анализу, вычисляются по сложным формулам; требование к бюджету – получение работоспособной системы за минимальные трудозатраты и стоимость используемого программного обеспечения; относительно небольшой срок разработки системы (5 месяцев). Исходя из вышеперечисленных факторов, были следующие критерии: 1. Список поддерживаемых СУБД 2. Список поддерживаемых (MOLAP/ROLAP/HOLAP) форм хранения данных 3. Возможность создания вычисляемых меток. Используя вычисляемые метки, можно включить в многомерную базу измерения и меры, которых нет в исходных данных, но которые можно вычислить по формуле 4. Возможность создания пользовательских агрегирующих функций. Помимо стандартных агрегирующих функций, таких как сумма и среднее значение, должна быть предусмотрена возможность создания пользовательских функций, вычисляющих агрегат по определённой формуле 5. Оптимизация схемы агрегирования, т.е. возможность изменения количества вычисленных заранее агрегатов. Чем больше агрегатов хранится в готовом виде, тем выше производительность системы и тем меньше среднее время ответа на запрос. В то же время, увеличение количества хранимых агрегатов приводит к увеличению объема хранимых данных. Возможность сохранять только те агрегаты, которые наиболее часто используются в запросах пользователей, позволяет получить наименьший объем хранилища данных при максимальной производительности для наиболее популярных запросов к БД. Поэтому данный критерий достаточно важен при выборе оптимального OLAP-сервера. 6. Масштабируемость, т.е. возможность работы с различными объемами данных: от очень маленьких (менее 10 тыс. записей) до очень больших (более 1 млн. записей) без изменения состава программного продукта. 7. Удобные средства создания кубов и администрирования 8. Решение проблемы «взрыва данных» 9. Решение проблемы разреженности данных 10. Список поддерживаемых API и языков запросов. Средство визуализации OLAP-анализа, используемое в разрабатываемой системе (JPalo) должно поддерживать взаимодействие с OLAPсервером. 11. Поддержка Unix-подобных операционных систем 12. Безопасность. Часто бывает, что анализируемые данные представляют коммерческую тайну и поэтому при передаче должны быть зашифрованы. Но так как разрабатываемая система будет функционировать в пределах ведомственной локальной сети, то этот пункт является некритичным при выборе оптимального OLAPсервера. 13. Документирование. Учитывая, что проект выполняется в сжатые сроки, необходимо потратить как можно времени на изучение продукта, поэтому OLAP-сервер должен иметь хорошую документацию. 14. Цена продукта на минимальную конфигурацию Выбрав критерии для сравнения OLAP-серверов, можно перейти к рассмотрению каждого конкретного сервера. 2.2 Microsoft Analysis Services Microsoft Analysis Services (MSAS) - часть Microsoft SQL Server, включающий в себя набор средств для работы с OLAP и интеллектуальным анализом данных. Последняя версия - Microsoft Analysis Services 2008. 1. MSAS поддерживает только одну БД - Microsoft SQL Server 2. MSAS поддерживает все три вида хранения данных: MOLAP, ROLAP и HOLAP 3. MSAS поддерживает создание вычисляемых меток. Следует отметить, что для этого предусмотрен удобный мастер, облегчающий создание вычисляемой метки и редактирования её формулы 4. MSAS поддерживает создание пользовательских агрегирующих функций 5. MSAS предусматривает оптимизацию схемы агрегирования. Используя Storage Design Wizard можно найти компромисс между быстродействием системы и размером хранимых на диске агрегатов. 6. MSAS поддерживает гибкую модель масштабирования, включающую оптимизацию хранения, компрессию данных и распределённые вычисления (т.е. часть вычислений можно перенести на клиент). 7. MSAS содержит множество различных «мастеров» и «дизайнеров» по созданию кубов, измерений, иерархий и администрированию. 8. Проблема «взрыва данных» в MSAS решена. 9. Проблема разреженности данных в MSAS также решена (посредством компрессии данных) 10. MSAS поддерживает спецификации OLE DB, ADO DB, XMLA. Язык запросов к многомерным данным - MDX 11. MSAS может быть установлен только на ОС Windows совместно с Microsoft SQL Server 12. MSAS поддерживает широкий спектр протоколов безопасности, таких как NTLM, Kerberos, SSL. Безопасность обеспечивается на уровне ячейки куба, т.е. доступ проверяется не к конкретному кубу или измерению, а к конкретной ячейке в кубе 13. MSAS очень подробно документирован. Документация на русском языке. 14. Стоимость SQL Server 2008 Workgroup Edition - 4000$ Следует отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 2.3 Oracle Essbase Oracle Essbase (в дальнейшем Essbase) – первый в мире OLAP-сервер. Расшифровывается как Extended Spread Sheet dataBASE. Данный сервер изначально создавался фирмой Hyperion как расширение электронных таблиц Lotus 1-2-3 и Microsoft Excel, но впоследствии в 2007 году Oracle купил Hyperion и переименовал продукт в Oracle Essbase. Последняя версия Oracle Essbase V.11.1.2 1. Essbase поддерживает только свою БД – Oracle 2. Essbase поддерживает 2 вида хранения данных: MOLAP и HOLAP 3. Essbase поддерживает создание вычисляемых меток. Стоить отметить, что помимо обычных математических формул можно использовать процедурный язык программирования - PL/SQL 4. Essbase поддерживает создание пользовательских агрегирующих функций. Здесь также может использоваться язык PL/SQL 5. Essbase, так же как и MSAS, предусматривает гибкую оптимизацию схемы агрегирования. 6. Essbase поддерживает включающую гибкую кластеризацию, модель функции масштабирования, отказоустойчивости, оптимизацию хранения и компрессию данных. 7. Essbase содержит удобный графический интерфейс, напоминающий интерфейс Microsoft Office, поэтому освоить такой интерфейс не будет проблемой даже для новичка. 8. Проблема «взрыва данных» в Essbase решена. 9. Проблема разреженности данных в Essbase также решена. 10. Essbase поддерживает API для языков Java, C, Visual Basic и спецификацию XMLA. Язык запросов к многомерным данным - MDX 11. Essbase может быть установлен как на ОС Windows, так и на Unixподобную ОС 12. У Essbase собственный протокол безопасности, но он также поддерживает аунтефикацию по LDAP и протокол шифрования SSL. Безопасность обеспечивается на уровне ячейки куба 13. Essbase, так же как и MSAS, очень подробно документирован. Документация на русском языке. 14. Стоимость Oracle Essbase V.11.1.2– 40 000 $ Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 2.4 IBM Cognos TM1 Изначально продукт разрабатывался фирмой Cognos, но в 2009 году Cognos была поглощена компанией IBM и продукт был переименован в IBM Cognos TM1. Основное отличие TM1 от предыдущих двух серверов заключается в том, что это запатентованный 64-разрядный OLAP-сервер, использующий подход In-memory OLAP. Данный подход подразумевает кеширование исходных данных и агрегатов в оперативной памяти, тем самым увеличивая производительность сервера. Последняя версия 1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется дополнительный инструмент Turbo Integrator, поддерживающий большинство существующих БД, в том числе и PostgreSQL. Подключение в данном случае происходит через ODBC-драйвер 2. TM1 поддерживает один вид хранения данных - MOLAP 3. TM1 поддерживает создание вычисляемых меток 4. TM1 поддерживает создание пользовательских агрегирующих функций. 5. Помимо кеширования TM1 позволяет сохранять подсчитанные агрегаты в БД, тем самым предусматривается гибкая оптимизация схемы агрегирования. 6. TM1 поддерживает гибкую модель масштабирования, включающую кластеризацию, функции отказоустойчивости, оптимизацию хранения и компрессию данных. 7. TM1 содержит удобный графический интерфейс, встраиваемый в Microsoft Excel, а также собственный Web-интерфейс. 8. Проблема «взрыва данных» в TM1 решена. 9. Проблема разреженности данных в TM1 также решена. 10. TM1 поддерживает спецификации OLE DB, XMLA. Язык запросов к многомерным данным - MDX 11. TM1 может быть установлен как на ОС Windows, так и на Unixподобную ОС 12. У TM1 свой протокол безопасности, но он также поддерживает аунтефикацию по LDAP и протокол шифрования SSL. Безопасность обеспечивается на уровне ячейки куба 13. TM1, так же как Essbase и MSAS, очень подробно документирован. Документация на русском языке. 14. Стоимость IBM TM1 – 50 000 $ Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 2.5 Pentaho Mondrian В отличие от вышеперечисленных OLAP-серверов данный продукт является открытым и распространяется под лицензией EPL. Mondrian написан на Java, что с одной стороны уменьшает быстродействие (ввиду javaмашины), но с другой – добавляет кроссплатформенность. Так же, как и IBM TM1, данный сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Pentaho Analysis. Последняя версия сервера - Mondrian 3.0.4 1. Для подключения к хранилищам данных Mondrian используется JDBC-драйвер. Таким образом, сервер поддерживает БД, к которым можно подключаться через JDBC, в том числе PostgreSQL 2. Mondrian поддерживает только один вид хранения данных - ROLAP 3. Mondrian поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX. 4. Mondrian не поддерживает создание пользовательских агрегирующих функций. 5. Mondrian изначально хранит все агрегаты в оперативной памяти, но существует возможность создавать для агрегатов свои таблицы в хранилище данных. 6. Mondrian масштабируем только с точки зрения увеличения исходных данных. Функций кластеризации и отказоустойчивости у сервера нет 7. Mondrian содержит достаточно простой, но с другой стороны, удобный графический интерфейс для создания кубов. Графического интерфейса для администрирования сервера нет – всё администрирование сводится к изменениям параметров в XMLфайлах 8. Проблема «взрыва данных» в Mondrian решена. 9. Проблема разреженности данных в Mondrian также решена. 10. Mondrian поддерживает API для языков Java (OPAL4J) и спецификации XMLA и OLE DB. Язык запросов к многомерным данным - MDX 11. Mondrian может быть установлен любую машину, для которой имеется Java-машина. В частности, на Windows и Unix-подобную ОС 12. Безопасность обеспечивается на уровне ячейки куба. Следует отметить, что передаваемые данные не шифруются 13. Сервер документирован достаточно хорошо, но только на английском языке. 14. Стоимость Mondrian – бесплатно. Кроме того доступны исходные коды проекта. Следует отметить, что данный продукт поддерживает все типы иерархий, но не поддерживает полуаддитивные меры и функцию «writeback». 2.6 Jedox Palo Данный продукт, так же как Mondrian является открытым и распространяется под лицензией GPL. Так же, как IBM TM1 и Mondrian, данный сервер использует принцип In-Memory (кеширование агрегатов). Данный сервер используется в коммерческом продукте Palo Suite. Последняя версия сервера - Palo 3.1 1. Сервер хранит данные в своих собственных многомерных структурах данных. Для импорта данных в свою БД используется продукт Palo ETL Server, поддерживающий большинство существующих БД, в том числе и PostgreSQL. 2. Palo поддерживает только один вид хранения данных - MOLAP 3. Palo поддерживает создание вычисляемых меток. Выражения для меток строятся на основе математических формул и языков SQL/MDX. 4. Palo не поддерживает создание пользовательских агрегирующих функций. 5. Palo хранит все агрегаты в оперативной памяти. Не существует возможности сохранять агрегаты на жёстком диске. Стоить отметить, что сервер использует процессор видеоадаптера (GPU), что способствует уменьшению времени вычисления агрегатов. 6. Palo масштабируем с точки зрения увеличения исходных данных. Palo очень эффективно использует ресурсы процессоров (CPU и GPU), поэтому сервер хорошо масштабируем в сторону увеличения количества процессов (ядер процессоров). Функций кластеризации и отказоустойчивости у сервера нет 7. Palo содержит достаточно удобный графический интерфейс для создания кубов и администрирования сервера. Palo может быть встроен в Microsoft Excel и в Open Office, поэтому освоить такой интерфейс не будет проблемой даже для новичка. 8. Проблема «взрыва данных» в Palo решена. 9. Проблема разреженности данных в Palo также решена. 10. Palo поддерживает API для языков Java, C/C++, PHP, .NET и спецификации OLE DB и XMLA. Язык запросов к многомерным данным - MDX 11. Palo может быть установлен как на ОС Windows, так и на Unixподобную ОС 12. Безопасность обеспечивается на Передаваемые данные не шифруются уровне ячейки куба. 13. Сервер документирован достаточно хорошо, но только на английском языке. 14. Стоимость Palo – бесплатно. Кроме того доступны исходные коды проекта. Стоит отметить, что данный продукт поддерживает все типы иерархий и мер, а также функцию «write-back». 2.7 Результаты Объединим результаты сравнения OLAP-серверов в одну сводную таблицу: Таблица 2.2 Сравнение OLAP-серверов Критерий/OLAP-сервер MSAS Essbase TM1 Mondrian Palo Поддержка PostgreSQL - - + + + Поддерживаемые формы хранения данных (MOLAP/ROLAP/HOLAP) (+/+/+) (+/-/-) (+/-/-) (-/+/-) (+/-/-) Создание вычисляемых меток + + + + + Создание пользовательских агрегирующих функций + + + - - Оптимизация схемы агрегирования + + + + - Масштабируемость + + + + + Удобные средства создания кубов и администрирования + + + + + Решение проблемы «взрыва данных» + + + + + Решение проблемы разреженности данных + + + + + Поддержка XMLA и MDX + + + + + Поддержка Unixподобных операционных систем - + + + + Обеспечение безопасности + + + - - Подробное документирование на русском языке + + + - - 4000$ 40000$ 50000$ беспл. беспл. Цена продукта на минимальную конфигурацию В исследовании было использовано хранилище данных объемом порядка 100 тыс. записей. Каждый продукт устанавливался на специально выделенный сервер со следующими характеристиками: CPU – Xeon (4 ядра, 2800 МГц), ОЗУ – 4 Гб, ОС – Microsoft Windows 2008 Server. Хранилище данных располагалось на другом сервере. Скорость соединения между серверами – 100 Мбит/с. Для каждого OLAP-сервера создавался небольшой OLAP-куб, содержащий 4 измерения, 3 меры (причём, одну вычисляемую меру) и одну пользовательскую агрегирующую функцию (кроме Mondrian, т.к. он их не поддерживает). OLAP-куб визуализировался с использованием продукта JPalo, запущенным в браузере Internet Explorer 7.0 В ходе проведённого исследования можно сделать следующие выводы: все рассматриваемые продукты полностью соответствуют принципам аналитической обработки в реальном времени, изложенным Коддом, и тесту FASMI (см. гл. 1.1); у платных продуктов очень гибкая схема масштабирования, включающая кластеризацию, функции отказоустойчивости; платные продукты поддерживают все типы иерархий и мер, а также функцию «write-back»; платные продукты очень подробно документированы (на русском языке); все рассматриваемые продукты поддерживают создание вычисляемых меток; бесплатные продукты не поддерживают создание пользовательских агрегирующих функций; во всех продуктах решена проблема «взрыва данных» и разреженности данных; все рассматриваемые продукты поддерживают спецификацию XMLA и язык запросов к многомерным данным - MDX; TM1, Mondrian, Palo используют принцип In-Memory OLAP, что увеличивает быстродействие OLAP-сервера; во всех продуктах безопасность обеспечивается на уровне ячейки куба, т.е. доступ проверяется не к конкретному кубу или измерению, а к конкретной ячейке в кубе; Mondrian и Palo имеют открытый исходный код. Для разрабатываемой системы было принято решение использовать OLAP-сервер Pentaho Mondrian, главным образом исходя из следующих соображений: Стоимость - сервер Mondrian абсолютно бесплатен Открытость исходного кода. Так как сервер не поддерживает создание пользовательских агрегирующих функций (в отличие от платных серверов), то существует возможность доработать сервер и добавить недостающую функциональность (решение этой проблемы описано в гл.3). Mondrian, в отличие от Palo (который также имеет открытый исходный код и не поддерживает пользовательские агрегирующие функции), написан на языке Java, с которым автор ВКР давно знаком Графический интерфейс создания и администрирования кубов у Mondrian оказался удобнее, чем у Palo Еще ченить 3. Разработка хранилища данных 3.1 Обзор предметной области Написать зачем создаётся система, её функции Разрабатываемая государственные система программы, позволяет состоящие создавать из списка федеральные определённых мероприятий, и оценивать их риски невыполнения. Пользователь системы формирует новую программу из списка предложений, поступающих от государственных заказчиков. Если пользователь включает предложение в будущую программу, то предложение становится мероприятием, приобретая такие новые характеристики, как стоимость и сроки выполнения. По специальной методике пользователь может оценить невыполнения и возможный ущерб от срыва мероприятия. бюджет, риск Пользователь может создавать несколько вариантов для одной и той же программы для того, чтобы впоследствии сравнивать полученные варианты и выбирать наиболее оптимальный. Когда процесс выбора наиболее удачного варианта программы завершён, пользователь может утвердить этот вариант. После утверждения варианта программы нельзя изменять никакие стоимостные характеристики программы. Далее необходимо назначить исполнителя для каждого мероприятия. По специальной методике (МАИ) формируется список организацийпретендентов на выполнение мероприятия, из которых выбирается только один, при этом система подсказывает пользователю, какой из исполнителей наиболее подходит для выполнения данного мероприятия. Таким образом, можно выделить следующие сущности: Программа. Характеризуется…. Модуль многомерного анализа данных позволит пользователю более детально просматривать и анализировать стоимостные показатели и параметры рисков. Для разработки данного модуля необходимо, прежде всего, разработать хранилище данных, которое будет являться источником данных для OLAP-модуля. Данная глава посвящена решению данной проблемы.
