СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1 OLAP: что это и для чего………………………………………………..7
2 Универсальные критерии определения OLAP………………………...9
ОСНОВНАЯ ЧАСТЬ
1 Классификация OLAP-продуктов……………………………………..11
2 OLAP-клиент - OLAP-сервер: "за" и "против"……………………….13
2.1 Объем обрабатываемых данных………………………………….13
2.2 Производительность системы…………………………………….14
2.3 Организация архитектур с прямым доступом к первичным данным………………………………………………………………….16
2.4 Мощность ПК пользователей……………………………………..17
2.5 Сетевой трафик…………………………………………………….18
2.6 Затраты на внедрение и сопровождение………………………....18
2.7 Принципы работы OLAP-клиентов………………………………19
2.8 Заключение…………………………………………………………21
3 Ядро OLAP системы……………………………………………………22
3.1 Принципы построения……………………………………………..22
3.1.1 Кросс-таблица. ………………………………………………24
3.1.2 Подготовка данных…………………………………………..26
3.1.3Библиотека компонентов CubeBase…………………………27
3.2 Внутри гиперкуба………………………………………………….28
3.2.1 Загрузка данных в гиперкуб………………………………...28
3.2.2 Реализация гиперкуба………………………………………31
3.3 Построение срезов куба…………………………………………..34
3.4 Реализации OLAP…………………………………………………40
3.4.1 Хорошо известные OLAP-продукты ………………………40
3.4.2 Deductor ……………………………………………………...41
ЗАКЛЮЧЕНИЕ……………………………………………………………….44
СПИСОК ИСТОЧНИКОВ……………………………………………………46
ВВЕДЕНИЕ
1 OLAP: что это и для чего
Трудно найти в компьютерном мире человека, который хотя бы на интуитивном уровне не понимал, что такое базы данных и зачем они нужны. В отличие от традиционных реляционных СУБД, концепция OLAP не так широко известна, хотя загадочный термин "кубы OLAP" слышали, наверное, почти все. Что же такое OnLine Analytical Processing?
OLAP - это не отдельно взятый программный продукт, не язык программирования и даже не конкретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным. Несмотря на то, что с таким определением вряд ли кто-нибудь не согласится, сомнительно, чтобы оно хоть на йоту приблизило неспециалистов к пониманию предмета. Поэтому в своем стремлении к познанию OLAP лучше идти другим путем. Для начала надо выяснить, зачем аналитикам надо как-то специально облегчать доступ к данным.
Дело в том, что аналитики - это особые потребители корпоративной информации. Задача аналитика - находить закономерности в больших массивах данных. Поэтому аналитик не будет обращать внимания на отдельно взятый факт, ему нужна информация о сотнях и тысячах событий. Кстати, один из существенных моментов, который привелл к появлению OLAP - производительность и эффективность. Представим себе, что происходит, когда аналитику необходимо получить информацию, а средства OLAP на предприятии отсутствуют. Аналитик самостоятельно (что маловероятно) или с помощью программиста делает соответствующий SQL-запрос и получает интересующие данные в виде отчета или экспортирует их в электронную таблицу. Проблем при этом возникает великое множество. Во-первых, аналитик вынужден заниматься не своей работой (SQL-программированием) либо ждать, когда за него задачу выполнят программисты - все это отрицательно сказывается на производительности труда, повышается инфарктно-инсультный уровень и так далее. Во-вторых, один-единственный отчет или таблица, как правило, не спасает гигантов мысли и отцов русского анализа - и всю процедуру придется повторять снова и снова. В-третьих, как мы уже выяснили, аналитики по мелочам не спрашивают - им нужно все и сразу. Это означает (хотя техника и идет вперед семимильными шагами), что сервер корпоративной реляционной СУБД, к которому обращается аналитик, может задуматься глубоко и надолго, заблокировав остальные транзакции.
Концепция OLAP появилась именно для разрешения подобных проблем. Кубы OLAP представляют собой, по сути, мета-отчеты. Разрезая мета-отчеты (кубы, то есть) по измерениям, аналитик получает, фактически, интересующие его "обычные" двумерные отчеты (это не обязательно отчеты в обычном понимании этого термина - речь идет о структурах данных с такими же функциями). Преимущества кубов очевидны - данные необходимо запросить из реляционной СУБД всего один раз - при построении куба. Поскольку аналитики, как правило, не работают с информацией, которая дополняется и меняется "на лету", сформированный куб является актуальным в течение достаточно продолжительного времени. Благодаря этому, не только исключаются перебои в работе сервера реляционной СУБД (нет запросов с тысячами и миллионами строк ответов), но и резко повышается скорость доступа к данным для самого аналитика. Кроме того, как уже отмечалось, производительность повышается и за счет подсчета промежуточных сумм иерархий и других агрегированных значений в момент построения куба.
Конечно, за повышение таким способом производительности надо платить. Иногда говорят, что структура данных просто "взрывается" - куб OLAP может занимать в десятки и даже сотни раз больше места, чем исходные данные.
2 Универсальные критерии определения OLAP
Теперь, когда мы немного разобрались в том, как работает и для чего служит OLAP, стоит, все же, несколько формализовать наши знания и дать критерии OLAP уже без синхронного перевода на обычный человеческий язык. Эти критерии (всего числом 12) были сформулированы в 1993 году Е.Ф. Коддом - создателем концепции реляционных СУБД и, по совместительству, OLAP. Непосредственно их мы рассматривать не будем, поскольку позднее они были переработаны в так называемый тест FASMI, который определяет требования к продуктам OLAP. FASMI - это аббревиатура от названия каждого пункта теста:
- Fast (быстрый). Это свойство означает, что система должна обеспечивать ответ на запрос пользователя в среднем за пять секунд; при этом большинство запросов обрабатываются в пределах одной секунды, а самые сложные запросы должны обрабатываться в пределах двадцати секунд. Недавние исследования показали, что пользователь начинает сомневаться в успешности запроса, если он занимает более тридцати секунд.
- Analysis (аналитический). Система должна справляться с любым логическим и статистическим анализом, характерным для бизнес–приложений, и обеспечивает сохранение результатов в виде, доступном для конечного пользователя. Средства анализа могут включать процедуры анализа временных рядов, распределения затрат, конверсии валют, моделирования изменений организационных структур и некоторые другие.
- Shared (разделяемый). Система должна предоставлять широкие возможности разграничения доступа к данным и одновременной работы многих пользователей.
- Multidimensional (многомерный). Система должна обеспечивать концептуально многомерное представление данных, включая полную поддержку множественных иерархий.
- Information (информация). Мощность различных программных продуктов характеризуется количеством обрабатываемых входных данных. Разные OLAP–системы имеют разную мощность: передовые OLAP–решения могут оперировать, по крайней мере, в тысячу раз большим количеством данных по сравнению с самыми маломощными. При выборе OLAP–инструмента следует учитывать целый ряд факторов, включая дублирование данных, требуемую оперативную память, использование дискового пространства, эксплуатационные показатели, интеграцию с информационными хранилищами и т.п.
ОСНОВНАЯ ЧАСТЬ
1 Классификация OLAP-продуктов
Итак, суть OLAP заключается в том, что исходная для анализа информация представляется в виде многомерного куба, и обеспечивается возможность произвольно манипулировать ею и получать нужные информационные разрезы - отчеты. При этом конечный пользователь видит куб как многомерную динамическую таблицу, которая автоматически суммирует данные (факты) в различных разрезах (измерениях), и позволяет интерактивно управлять вычислениями и формой отчета. Выполнение этих операций обеспечивается OLAP-машиной (или машиной OLAP-вычислений).
На сегодняшний день в мире разработано множество продуктов, реализующих OLAP-технологии. Чтобы легче было ориентироваться среди них, используют классификации OLAP-продуктов: по способу хранения данных для анализа и по месту нахождения OLAP-машины. Рассмотрим подробнее каждую категорию OLAP-продуктов.
Начну я с классификации по способу хранения данных. Напомню, что многомерные кубы строятся на основе исходных и агрегатных данных. И исходные и агрегатные данные для кубов могут храниться как в реляционных, так и многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP). Соответственно, OLAP-продукты по способу хранения данных делятся на три аналогичные категории:
В случае MOLAP, исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе.
В ROLAP-продуктах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-средства.
В случае использования HOLAP архитектуры исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP-куба выполняется по запросу OLAP-средства на основе реляционных и многомерных данных.
Следующая классификация - по месту размещения OLAP-машины. По этому признаку OLAP-продукты делятся на OLAP-серверы и OLAP-клиенты:
- В серверных OLAP-средствах вычисления и хранение агрегатных данных выполняются отдельным процессом - сервером. Клиентское приложение получает только результаты запросов к многомерным кубам, которые хранятся на сервере. Некоторые OLAP-серверы поддерживают хранение данных только в реляционных базах, некоторые - только в многомерных. Многие современные OLAP-серверы поддерживают все три способа хранения данных: MOLAP, ROLAP и HOLAP.
- OLAP-клиент устроен по-другому. Построение многомерного куба и OLAP-вычисления выполняются в памяти клиентского компьютера. OLAP-клиенты также делятся на ROLAP и MOLAP. А некоторые могут поддерживать оба варианта доступа к данным.
У каждого из этих подходов, есть свои "плюсы" и "минусы". Вопреки распространенному мнению о преимуществах серверных средств перед клиентскими, в целом ряде случаев применение OLAP-клиента для пользователей может оказаться эффективнее и выгоднее использования OLAP-сервера.
2 OLAP-клиент - OLAP-сервер: "за" и "против"
При построении информационной системы OLAP-функциональность может быть реализована как серверными, так и клиентскими OLAP-средствами. На практике выбор является результатом компромисса эксплуатационных показателей и стоимости программного обеспечения.
2.1 Объем обрабатываемых данных
Объем данных определяется совокупностью следующих характеристик: количество записей, количество измерений, количество элементов измерений, длина измерений и количество фактов. Известно, что OLAP-сервер может обрабатывать большие объемы данных, чем OLAP-клиент при равной мощности компьютера. Это объясняется тем, что OLAP-сервер хранит на жестких дисках многомерную базу данных, содержащую заранее вычисленные кубы.
Клиентские программы в момент выполнения OLAP-операций выполняют к ней запросы на SQL-подобном языке, получая не весь куб, а его отображаемые фрагменты. OLAP-клиент в момент работы должен иметь в оперативной памяти весь куб. В случае ROLAP-архитектуры, необходимо предварительно загрузить в память весь используемый для вычисления куба массив данных. Кроме того, при увеличении числа измерений, фактов или элементов измерений количество агрегатов растет в геометрической прогрессии. Таким образом, объем данных, обрабатываемых OLAP-клиентом, находится в прямой зависимости от объема оперативной памяти ПК пользователя.
Однако заметим, что большинство OLAP-клиентов обеспечивают выполнение распределенных вычислений. Поэтому под количеством обрабатываемых записей, которое ограничивает работу клиентского OLAP-средства, понимается не объем первичных данных корпоративной БД, а размер агрегированной выборки из нее. OLAP-клиент генерирует запрос к СУБД, в котором описываются условия фильтрации и алгоритм предварительной группировки первичных данных. Сервер находит, группирует записи и возвращает компактную выборку для дальнейших OLAP-вычислений. Размер этой выборки может быть в десятки и сотни раз меньше объема первичных, не агрегированных записей. Следовательно, потребность такого OLAP-клиента в ресурсах ПК существенно снижается.
Кроме того, на количество измерений накладывают ограничения возможности человеческого восприятия. Известно, что средний человек может одновременно оперировать 3-4, максимум 8 измерениями. При большем количестве измерений в динамической таблице восприятие информации существенно затрудняется. Этот фактор следует учитывать при предварительном расчете оперативной памяти, которая может потребоваться OLAP-клиенту.
Длина измерений также влияет на размер адресного пространства OLAP-средства, занятого при вычислении OLAP-куба. Чем длиннее измерения, тем больше ресурсов требуется для выполнения предварительной сортировки многомерного массива, и наоборот. Только короткие измерения в исходных данных - еще один аргумент в пользу OLAP-клиента.
2.2 Производительность системы
Эта характеристика определяется двумя рассмотренными выше факторами: объемом обрабатываемых данных и мощностью компьютеров. При возрастании количества, например, измерений, производительность всех OLAP-средств снижается за счет значительного увеличения количества агрегатов, но при этом темпы снижения разные. Продемонстрируем эту зависимость на графике. Дддддддддддддддддд
Схема 1. Зависимость производительности клиентских и серверных OLAP-средств от увеличения объема данных
Скоростные характеристики OLAP-сервера менее чувствительны к росту объема данных. Это объясняется различными технологиями обработки запросов пользователей OLAP-сервером и OLAP-клиентом. Например, при операции детализации OLAP-сервер обращается к хранимым данным и "вытягивает" данные этой "ветки". OLAP-клиент же вычисляет весь набор агрегатов в момент загрузки.
Однако до определенного объема данных производительность серверных и клиентских средств является сопоставимой. Для OLAP-клиентов, поддерживающих распределенные вычисления, область сопоставимости производительности может распространяться на объемы данных, покрывающие потребности в OLAP-анализе огромного количества пользователей. Это подтверждают результаты внутреннего тестирования MS OLAP Server и OLAP-клиента "Контур Стандарт" . Тест выполнен на ПК IBM PC Pentium Celeron 400 МГц, 256 Mb для выборки в 1 миллион уникальных (т.е. агрегированных) записей с 7 измерениями, содержащими от 10 до 70 членов. Время загрузки куба в обоих случаях не превышает 1 секунды, а выполнение различных OLAP-операций (drill up, drill down, move, filter и др.) выполняется за сотые доли секунды.
Когда размер выборки превысит объем оперативной памяти, начинается обмен (swapping) с диском и производительность OLAP-клиента резко падает. Только с этого момента можно говорить о преимуществе OLAP-сервера.
Следует помнить, что точка "перелома" определяет границу резкого удорожания OLAP-решения. Для задач каждого конкретного пользователя эта точка легко определяется по тестам производительности OLAP-клиента. Такие тесты можно получить у компании-разработчика.
Кроме того, стоимость серверного OLAP-решения растет при увеличении количества пользователей. Дело в том, что OLAP-сервер выполняет вычисления для всех пользователей на одном компьютере. Соответственно, чем больше количество пользователей, тем больше оперативной памяти и процессорной мощности требуется компьютеру.
Таким образом, если объемы обрабатываемых данных лежат в области сопоставимой производительности серверных и клиентских систем, то при прочих равных условиях, использование OLAP-клиента будет выгоднее.
|
