Онлайн-аналитическая обработка или OLAP (), является подходом для быстрого ответа на многомерные аналитические (MDA) запросы в вычислениях. OLAP является частью более широкой категории бизнес-аналитики, которая также включает реляционные базы данных, написание отчетов и интеллектуальный анализ данных. Типичные приложения OLAP включают бизнес-отчетность для продаж, маркетинг, управленческую отчетность, управление бизнес-процессами (BPM), бюджетирование и прогнозирование, финансовая отчетность и подобные области с появлением новых приложений, таких как сельское хозяйство.
Термин OLAP был создан как небольшая модификация традиционного термина базы данных онлайн обработка транзакций (OLTP).
Инструменты OLAP позволяют пользователям анализировать многомерные данные в интерактивном режиме с разных точек зрения. OLAP состоит из трех основных аналитических операций: консолидации (сворачивания), детализации, а также нарезки и нарезки кубиками. Консолидация включает в себя агрегирование данных, которые можно накапливать и вычислять в одном или нескольких измерениях. Например, все офисы продаж объединены с отделом продаж или отделом продаж, чтобы предвидеть тенденции продаж. В отличие от этого, детализация - это метод, который позволяет пользователям ориентироваться в деталях. Например, пользователи могут просматривать продажи по отдельным продуктам, составляющим продажи региона. Нарезка и нарезание кубиками - это функция, с помощью которой пользователи могут извлекать (разрезать) определенный набор данных из куба OLAP и просматривать (разрезать) срезы с разных точек зрения. Эти точки зрения иногда называют измерениями (например, просмотр одних и тех же продаж по продавцу, по дате, по покупателю, по продукту, по региону и т. Д.)
Базы данных, настроенные для OLAP, используют многомерные данные модель, позволяющая выполнять сложные аналитические и специальные запросы с быстрым временем выполнения. Они заимствуют аспекты навигационных баз данных, иерархических баз данных и реляционных баз данных.
OLAP обычно отличается от OLTP (обработка онлайн-транзакций), который обычно характеризуется гораздо менее сложными запросами в большем объеме для обработки транзакций, а не для целей бизнес-аналитики. или отчетности. В то время как системы OLAP в основном оптимизированы для чтения, OLTP должен обрабатывать все виды запросов (чтение, вставка, обновление и удаление).
В основе любой системы OLAP лежит куб OLAP (также называемый «многомерным кубом» или гиперкубом ). Он состоит из числовых фактов, называемых мерами, которые классифицируются по измерениям. Меры помещаются на пересечениях гиперкуба, который охватывает измерения как векторное пространство . Обычным интерфейсом для управления кубом OLAP является интерфейс матрицы, такой как сводные таблицы в программе электронных таблиц, который выполняет операции проецирования по измерениям, такие как агрегирование или усреднение.
Метаданные куба обычно создаются из звездообразной схемы или схемы снежинки или совокупности фактов таблиц в реляционной базе данных. Меры берутся из записей в таблице фактов, а измерения берутся из таблиц измерений.
Каждая мера может рассматриваться как имеющая набор ярлыков или связанных с ней метаданных.. Размерность - это то, что описывает эти ярлыки; он предоставляет информацию о мере.
Простым примером может служить куб, содержащий продажи магазина в качестве меры и дату / время в качестве измерения. У каждой продажи есть метка даты / времени, которая описывает больше об этой продаже.
Например:
Таблица фактов продаж + ------------- + ---------- + | sale_amount | time_id | + ------------- + ---------- + Измерение времени | 2008.10 | 1234 | ---- + + --------- + ------------------- + + ----------- - + ---------- + | | time_id | отметка времени | | + --------- + ------------------- + + ---->| 1234 | 20080902 12:35:43 | + --------- + ------------------- +
Многомерная структура определяется как «вариант реляционной модели, которая использует многомерные структуры для организации данных и выражения отношений между данными». Структура разбита на кубы, и кубы могут хранить и получать доступ к данным в пределах каждого куба. «Каждая ячейка в многомерной структуре содержит агрегированные данные, относящиеся к элементам по каждому из ее измерений». Даже когда данные обрабатываются, они остаются легкодоступными и продолжают составлять компактный формат базы данных. Данные остаются взаимосвязанными. Многомерная структура довольно популярна для аналитических баз данных, использующих приложения онлайн-аналитической обработки (OLAP). Аналитические базы данных используют эти базы данных из-за их способности быстро предоставлять ответы на сложные бизнес-запросы. Данные можно рассматривать под разными углами, что дает более широкую перспективу проблемы в отличие от других моделей.
Утверждалось, что для сложных запросов кубы OLAP могут дать ответ примерно за 0,1 % времени, необходимого для того же запроса к реляционным данным OLTP. Наиболее важным механизмом OLAP, который позволяет достичь такой производительности, является использование агрегирования. Агрегации создаются на основе таблицы фактов путем изменения степени детализации по конкретным измерениям и агрегирования данных по этим измерениям с помощью агрегатной функции (или функции агрегирования). Количество возможных агрегатов определяется всеми возможными комбинациями гранулярностей измерений.
Комбинация всех возможных агрегатов и базовых данных содержит ответы на каждый запрос, на который можно ответить, исходя из данных.
Потому что обычно существует множество агрегатов, которые можно вычислить, часто только один заранее определенное количество полностью рассчитано; остальные решаются по запросу. Проблема выбора агрегатов (представлений) для вычисления известна как проблема выбора представлений. Выбор представления может быть ограничен общим размером выбранного набора агрегатов, временем их обновления из-за изменений в базовых данных или и тем, и другим. Целью выбора представления обычно является минимизация среднего времени ответа на запросы OLAP, хотя некоторые исследования также минимизируют время обновления. Выбор вида: NP-Complete. Были изучены многие подходы к проблеме, включая жадные алгоритмы, рандомизированный поиск, генетические алгоритмы и алгоритм поиска A *.
Некоторые функции агрегирования могут быть вычислены для всего Куб OLAP путем предварительного вычисления значений для каждой ячейки, а затем вычисления агрегации для объединения ячеек путем агрегации этих агрегатов, применяя алгоритм разделяй и властвуй к многомерной задаче для вычисления их эффективно. Например, общая сумма свертки - это просто сумма промежуточных сумм в каждой ячейке. Функции, которые можно разложить таким образом, называются разлагаемыми функциями агрегирования и включают COUNT, MAX, MIN,
и SUM
, которые можно вычислить для каждой ячейки. а затем непосредственно агрегированы; они известны как саморазлагаемые функции агрегирования. В других случаях агрегатная функция может быть вычислена путем вычисления вспомогательных чисел для ячеек, агрегирования этих вспомогательных чисел и, наконец, вычисления общего числа в конце; примеры включают AVERAGE
(отслеживание суммы и счетчика, деление в конце) и RANGE
(отслеживание максимума и минимума, вычитание в конце). В других случаях агрегатная функция не может быть вычислена без одновременного анализа всего набора, хотя в некоторых случаях могут быть вычислены приближения; примеры включают DISTINCT COUNT, MEDIAN,
и MODE
; например, медиана набора не является медианой медиан подмножеств. Последние трудно реализовать эффективно в OLAP, поскольку они требуют вычисления агрегатной функции на основе базовых данных, либо их вычисления в оперативном режиме (медленно), либо их предварительного вычисления для возможного развертывания (большое пространство).
Системы OLAP традиционно классифицируются с использованием следующей таксономии:
MOLAP (многомерная онлайн-аналитическая обработка) - это классическая форма OLAP, которую иногда называют просто OLAP. MOLAP хранит эти данные в оптимизированном хранилище многомерных массивов, а не в реляционной базе данных.
Для некоторых инструментов MOLAP требуется предварительное вычисление и хранение производных данных, например консолидация - операция, известная как обработка. Такие инструменты MOLAP обычно используют предварительно рассчитанный набор данных, называемый кубом данных. Куб данных содержит все возможные ответы на заданный круг вопросов. В результате они очень быстро отвечают на запросы. С другой стороны, обновление может занять много времени в зависимости от степени предварительного расчета. Предварительные вычисления также могут привести к так называемому взрыву данных.
Другие инструменты MOLAP, особенно те, которые реализуют функциональную модель базы данных, не производят предварительное вычисление производных данных, а выполняют все вычисления по запросу, кроме тех, которые были ранее запрошены и сохранены в кэше.
Преимущества MOLAP
Недостатки MOLAP
Примеры коммерческих продуктов, использующих MOLAP: Cognos Powerplay, Oracle Database OLAP Option, MicroStrategy, Microsoft Analysis Services, Essbase, TM1, Jedox и icCube.
ROLAP работает напрямую с реляционными базами данных и не требует предварительных вычислений. Базовые данные и таблицы измерений хранятся в виде реляционных таблиц, а новые таблицы создаются для хранения агрегированной информации. Это зависит от конкретной схемы. Эта методология основывается на манипулировании данными, хранящимися в реляционной базе данных, чтобы создать видимость традиционных функций нарезки и нарезания кубиков OLAP. По сути, каждое действие нарезки и нарезки кубиками эквивалентно добавлению предложения WHERE в оператор SQL. Инструменты ROLAP не используют предварительно рассчитанные кубы данных, а вместо этого создают запрос к стандартной реляционной базе данных и ее таблицам, чтобы вернуть данные, необходимые для ответа на вопрос. Инструменты ROLAP позволяют задать любой вопрос, поскольку методология не ограничивается содержимым куба. ROLAP также может выполнять детализацию до самого низкого уровня детализации в базе данных.
Хотя ROLAP использует источник реляционной базы данных, обычно база данных должна быть тщательно разработана для использования ROLAP. База данных, которая была разработана для OLTP, не будет хорошо работать как база данных ROLAP. Следовательно, ROLAP по-прежнему предполагает создание дополнительной копии данных. Однако, поскольку это база данных, для ее заполнения можно использовать различные технологии.
В индустрии OLAP ROLAP обычно воспринимается как возможность масштабирования для больших объемов данных, но страдающая от более медленного запроса производительность в отличие от MOLAP. OLAP Survey, крупнейшее независимое исследование всех основных продуктов OLAP, проводившееся в течение 6 лет (с 2001 по 2006 гг.), Неизменно обнаруживало, что компании, использующие ROLAP, сообщают о более низкой производительности, чем те, которые используют MOLAP, даже когда были взяты объемы данных во внимание.
Однако, как и в случае любого опроса, существует ряд тонких моментов, которые необходимо учитывать при интерпретации результатов.
Некоторые компании выбирают ROLAP, потому что они намерены повторно использовать существующие таблицы реляционной базы данных - эти таблицы будут часто не могут быть оптимально разработаны для использования OLAP. Превосходная гибкость инструментов ROLAP позволяет работать с этим далеко не оптимальным дизайном, но при этом страдает производительность. Инструменты MOLAP, напротив, вынуждают повторно загружать данные в оптимальный дизайн OLAP.
Нежелательный компромисс между дополнительной стоимостью ETL и низкой производительностью запросов привел к тому, что большинство коммерческих инструментов OLAP теперь используют «гибридный OLAP» (HOLAP), который позволяет разработчику модели решать, какая часть данных будет храниться в MOLAP, а какая - в ROLAP.
В отрасли нет четкого соглашения о том, что представляет собой «гибридный OLAP», за исключением того, что база данных будет разделять данные между реляционным и специализированным хранилищами. Например, для некоторых поставщиков база данных HOLAP будет использовать реляционные таблицы для хранения больших объемов подробных данных и использовать специализированное хранилище, по крайней мере, для некоторых аспектов меньших объемов более агрегированных или менее подробных данных. HOLAP устраняет недостатки MOLAP и ROLAP путем объединения возможностей обоих подходов. Инструменты HOLAP могут использовать как предварительно рассчитанные кубы, так и реляционные источники данных.
В этом режиме HOLAP сохраняет агрегаты в MOLAP для быстрого выполнения запросов, а подробные данные - в ROLAP для оптимизации времени обработки куба.
В этом режиме HOLAP сохраняет некоторый фрагмент данных, обычно более свежий (т.е. срезанный по измерению времени) в MOLAP для быстрого выполнения запросов, и старые данные в ROLAP. Более того, мы можем хранить некоторые кубики в MOLAP, а другие в ROLAP, используя тот факт, что в большом кубоиде будут плотные и разреженные подобласти.
Первым продуктом, предоставляющим хранилище HOLAP, был Holos, но эта технология также стала доступна в других коммерческих продуктах, таких как Microsoft Analysis Services, Oracle Database OLAP Вариант, MicroStrategy и SAP AG BI Accelerator. Гибридный подход OLAP объединяет технологии ROLAP и MOLAP, извлекая выгоду из большей масштабируемости ROLAP и более быстрого вычисления MOLAP. Например, сервер HOLAP может хранить большие объемы подробных данных в реляционной базе данных, в то время как агрегаты хранятся в отдельном хранилище MOLAP. Службы OLAP Microsoft SQL Server 7.0 поддерживают гибридный сервер OLAP
Каждый тип имеет определенные преимущества, хотя между поставщиками существуют разногласия по поводу специфики преимуществ.
Иногда используются следующие сокращения, хотя они не так широко распространены, как приведенные выше:
В отличие от реляционных баз данных, в которых SQL был стандартным языком запросов, и широко распространенных API, таких как ODBC, JDBC и OLEDB, долгое время в мире OLAP не было такой унификации. Первым настоящим стандартным API была спецификация OLE DB для OLAP от Microsoft, которая появилась в 1997 году и представила язык запросов MDX. Несколько поставщиков OLAP - как серверных, так и клиентских - приняли его. В 2001 году Microsoft и Hyperion объявили о спецификации XML для анализа, которая была одобрена большинством поставщиков OLAP. Поскольку здесь также использовались многомерные выражения в качестве языка запросов, многомерные выражения стали стандартом де-факто. С сентября 2011 года LINQ можно использовать для запроса SSAS кубов OLAP из Microsoft.NET.
Первым продуктом, который выполнял запросы OLAP, был Express, выпущенный в 1970 году (и приобретенный Oracle в 1995 году у компании Information Resources). Однако этот термин не появлялся до 1993 года, когда он был введен Эдгаром Ф. Коддом, который был описан как «отец реляционной базы данных». Работа Кодда стала результатом короткого консультационного задания, которое Кодд взял на себя для бывшего Arbor Software (позже Hyperion Solutions, а в 2007 году был приобретен Oracle) как своего рода маркетинговый ход. Годом ранее компания выпустила собственный продукт OLAP, Essbase. В результате «Двенадцать законов онлайн-аналитической обработки» Кодда были явными в их ссылке на Essbase. Возникли споры, и когда Computerworld узнал, что Арбор заплатила Кодду, он отозвал статью. Рынок OLAP пережил сильный рост в конце 1990-х, когда на рынок вышли десятки коммерческих продуктов. В 1998 году Microsoft выпустила свой первый сервер OLAP - Microsoft Analysis Services, который привел к широкому распространению технологии OLAP и вывел ее на рынок массовых товаров.
Клиенты OLAP включают в себя множество программ для работы с электронными таблицами, таких как Excel, веб-приложение, SQL, инструменты панели мониторинга и т. Д. Многие клиенты поддерживают интерактивное исследование данных, которое выбирают пользователи. интересующие размеры и меры. Некоторые измерения используются как фильтры (для нарезки и нарезки данных), а другие выбираются в качестве осей сводной таблицы или сводной диаграммы. Пользователи также могут изменять уровень агрегации (для детализации или сворачивания) отображаемого представления. Клиенты также могут предлагать различные графические виджеты, такие как ползунки, географические карты, тепловые карты и многое другое, которые можно сгруппировать и скоординировать в виде информационных панелей. Обширный список клиентов отображается в столбце визуализации таблицы сравнения серверов OLAP.
Ниже приведен список ведущих поставщиков OLAP в 2006 году с цифрами в миллионах долларов США.
Поставщик | Глобальный доход | Объединенная компания |
---|---|---|
Microsoft Corporation | 1806 | Microsoft |
Hyperion Solutions Corporation | 1077 | Oracle |
Cognos | 735 | IBM |
Business Objects | 416 | SAP |
MicroStrategy | 416 | MicroStrategy |
SAP AG | 330 | SAP |
Картез (SAP ) | 210 | SAP |
Applix | 205 | IBM |
Infor | 199 | Infor |
Oracle Corporation | 159 | Oracle |
Прочие | 152 | Прочие |
Всего | 5700 |