Oracle olap что это

Обновлено: 06.07.2024

Клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства.

Если исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится самим OLAP-средством. Если же источник исходных данных - серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы, содержащие оператор GROUP BY, и в результате получают агрегатные данные, вычисленные на сервере.

Как правило, OLAP-функциональность реализована в средствах статистической обработки данных (из продуктов этого класса на российском рынке широко распространены продукты компаний StatSoft и SPSS) и в некоторых электронных таблицах. В частности, средствами многомерного анализа обладает Microsoft Excel. С помощью этого продукта можно создать и сохранить в виде файла небольшой локальный многомерный OLAP-куб и отобразить его двух- или трехмерные сечения.

Надстройки к пакету приложений Microsoft Office для извлечения и обработки данных представляют собой ряд функций, обеспечивающих доступ к возможностям извлечения и обработки данных из приложений Microsoft Office, и тем самым позволяющих осуществлять прогностический анализ на локальном компьютере. Благодаря тому, что встроенные в службы платформы Microsoft SQL Server алгоритмы извлечения и обработки данных доступны из среды приложений Microsoft Office, бизнес-пользователи могут легко извлекать ценную информацию из сложных наборов данных всего несколькими щелчками мыши. Надстройки к пакету приложений Office для извлечения и обработки данных дают конечным пользователям возможность выполнять анализ непосредственно в приложениях Microsoft Excel и Microsoft Visio.

В состав Microsoft Office 2007 входят три отдельных OLAP-компонента:

клиент извлечения и обработки данных для Excel позволяет создавать проекты извлечения и обработки данных на базе служб SSAS и управлять ими из Excel 2007;
средства анализа таблиц для приложения Excel позволяют использовать встроенные в службы SSAS функции извлечения и обработки информации для анализа данных, хранящихся в таблицах Excel;
шаблоны извлечения и обработки данных для приложения Visio позволяют визуализировать деревья решений, деревья регрессии, кластерные диаграммы и сети зависимостей на диаграммах Visio.

На рисунок 1.15 изображена сводная таблица Excel, используемая для доступа клиентов к данным служб аналитики.

С помощью приложения Microsoft Office Visio можно аннотировать, дополнять и отображать графические представления результатов извлечения и обработки данных. Платформа SQL Server 2008 в сочетании с приложением Visio 2007 позволяет:

визуализировать деревья решений, деревья регрессии, кластерные диаграммы и сети зависимостей;
сохранять модели извлечения и обработки данных в виде документов Visio, внедренных в другие документы приложений Office или сохраненных в виде веб-страниц.

Клиентские OLAP-средства применяются, как правило, при малом числе измерений (обычно рекомендуется не более шести) и небольшом разнообразии значений этих параметров, - ведь полученные агрегатные данные должны умещаться в адресном пространстве подобного средства, а их количество растет экспоненциально при увеличении числа измерений. Поэтому даже самые примитивные клиентские OLAP-средства, как правило, позволяют произвести предварительный подсчет объема требуемой оперативной памяти для создания в ней многомерного куба.

Серверные OLAP-средства

Преимущества применения серверных OLAP-средств по сравнению с клиентскими OLAP-средствами сходны с преимуществами применения серверных СУБД по сравнению с настольными: в случае применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, а клиентское приложение получает лишь результаты запросов к ним, что позволяет в общем случае снизить сетевой трафик, время выполнения запросов и требования к ресурсам, потребляемым клиентским приложением. Отметим, что средства анализа и обработки данных масштаба предприятия, как правило, базируются именно на серверных OLAP-средствах, например, таких как Oracle Database Server и Microsoft SQL Server.

Некоторые клиентские OLAP-средства (в частности, Microsoft Excel) позволяют обращаться к серверным OLAP-хранилищам, выступая в этом случае в роли клиентских приложений, выполняющих подобные запросы. Помимо этого имеется немало продуктов, представляющих собой клиентские приложения к OLAP-средствам различных производителей.

Oracle Business Intellegence

У компании Oracle существует несколько линеек продуктов класса Business Intelligence. Основная и самая большая называется Oracle Business Intelligence Enterprise Edition PLUS.

Oracle Business Intelligence (BI) - это самый обширный комплекс технологий и приложений для обеспечения представления внутренней организации бизнеса, включающий ведущие BI-приложения, технологические BI-платформы и хранилища данных.

В основе BI-платформы Oracle лежит аналитический сервер Oracle BI Server EE.

Этот сервер хранит:

описание различных источников данных. В качестве источников данных могут быть практически любые СУБД, как реляционные (Oracle, Microsoft SQL Server, Microsoft Analysis Services, IBM DB2), так и многомерные (MS AS, Hyperion Essbase или SAP BW), а также ODBC источники, текстовые файлы и т.д.
в репозитории хранится бизнес-модель данных, построенная над физическими источниками данных. Бизнес-модель описывает данные в терминах, используемых при проектировании и построении хранилищ данных. Там же описывается, каким образом данные из физических источников соответствуют бизнес-модели.
презентационный слой, представляющий собой витрины данных. В презентационном слое описывается, по сути, как, в каких терминах и в каком наборе будут видны данные разным типам пользователей.

BI Server фактически представляет собой сервер приложений, который по запросу от пользователя вычисляет, какие данные нужны, в каком физическом источнике они находятся и делает запрос к соответствующему источнику или источникам (один запрос может возвращать данные из нескольких разных источников одновременно), после чего, сервер собирает, при необходимости агрегирует или производит дополнительные вычисления и возвращает результат.

С другой стороны, BI Server сам виден в сети как ODBC источник и позволяет делать к себе запросы с помощью любого инструмента или программы, работающей с ODBC. При этом этот сервер остается виртуальным, так как данные на нем не хранятся, а собираются в момент запроса. Аналитический сервер позволяет использовать хранилище как источник данных, одновременно с OLTP системами.

Инструментальные средства корпорации Oracle обеспечивают полное интегрированное решение для создания ХД и эффективного использования накопленной в нем информации.

Общий перечень продуктов Oracle, необходимых для реализации технологии хранилищ данных и аналитических приложений, приводится в Таблица 1 соответствии с выделенными ранее уровнями (рисунок 1.14).

Oracle BI Suite Enterprise Edition

В качестве среды хранения информации в реляционных ХД и ВД используется сервер Oracle Database. Центральным инструментальным средством создания хранилищ и витрин является Oracle Warehouse Builder, построенный на базе современной архитектуры Common Warehouse Metadata. Он предназначен для описания структуры ХД и ВД, проектирования и создания процедур извлечения, согласования и загрузки данных, а также генерации метаданных для средств доступа, например таких, как Discoverer.

Проектировать хранилище можно и с помощью стандартного инструмента Oracle Designer, а затем автоматически перенести описание проекта в репозиторий метаданных Oracle Warehouse Builder.

Microsoft SQL Server Analysis Services

Другой значимой OLAP-технологией является BI-решение от компании Microsoft, построенное на платформе SQL Server и включающее компоненты Analysis Services и Integration Services. Это решение будет подробно рассмотрено во второй главе.

Что такое OLAP? Часть 2. Oracle Express и Oracle OLAP

Теперь перейдем собственно к Oracle OLAP.

На самом деле, с 1970 продукт несколько раз переписывался, в том числе и на другие языки программирования. И в 1995, когда его купил Oracle, Express был лидером в своем классе.

Семейство Oracle Express состоит из нескольких продуктов:

У Express Server есть помимо стандартных возможностей просмотра содержимого кубов, есть ряд интересных и иногда даже уникальных возможностей. Например:

При этом, все это работало очень быстро и вообще Express нетребователен к ресурсам. На основе Express написан, например, продукт Oracle Financial Analyzer, предназначенный для планирования и бюджетирования. Этот продукт успешно использует все вышеперечисленные возможности Express.

Учитывая это, в Oracle пришли к идее, что если взять движок Express Server и поместить его вместе с OLAP-данными внутрь СУБД Oracle, то это даст ряд преимуществ, тем более что диски и память стали дешевле:

В итоге решение о включении Express в состав СУБД было принято. И появилась OLAP опция СУБД Oracle. Которая сейчас называется просто Oracle OLAP. Express существует и продается, в том числе в составе Oracle Financial Analyzer, но усилия разработчиков в основном направлены на OLAP опцию базы.

Но так как процесс интеграции нереляционной СУБД внутрь реляционной оказался не так прост, то он занял некоторое время.
Сначала, в первом релизе Oracle 9i не было MOLAP, был организован только ROLAP.
Во втором релизе появился MOLAP (то есть движок Express был интегрирован в базу), но понадобилось время и несколько промежуточных релизов чтобы оптимизировать код.

Фактически, в 9-ой версии к функциональности OLAP ничего нового не добавлялось, и только в версии 10g, а особенно в 10.2 появился новый функционал, который позволяет делать то, что нельзя было делать в Express. Например:

Поэтому, если вы только знакомитесь с Oracle OLAP лучше всего начинать с версии 10.2.

К сожалению, OLAP опция не поддерживает тот API, который был в Express, поэтому приложения, написанные на Express Objects не могут работать с OLAP опцией. Вместо этого в OLAP есть Java OLAP API, через который работает например Discoverer for OLAP.

Но если вы Java не используете, вы можете работать с кубами MOLAP при помощи обычного (почти) SQL. Дело в том, что в Oracle существует табличная функция OLAP_TABLE, которая при обращении к ней из SQL ведет себя как VIEW, но в нее можно передавать параметры, говорящие движку MOLAP, что нужно достать из куба.
Выглядеть этот запрос будет, например так (взято отсюда):

SELECT *
FROM TABLE(
OLAP_TABLE(
\'AWG DURATION SESSION\',
\'\',
\'\',
\'MEASURE quant AS NUMBER FROM cubname_quantity
DIMENSION firms FROM FIRMS_DIM
WITH ATTRIBUTE firm_name FROM FIRMS_DIM_LONG_DESCRIPTION
DIMENSION countues FROM COUNTRIES_DIM
DIMENSION time FROM TIME_DIM\'
)
)

Такой запрос можно положить во VIEW и делать запросы к этой VIEW с помощью любого SQL-инструмента. Таким образом нет необходимости поддержки специального API со стороны клиентских инструментов. Любой инструмент может работать с MOLAP, даже тот, разработчики которого и не думали о такой возможности.

В случае каких-то других СУБД, не Oracle, действительно, особых альтернатив MOLAP серверам для аналитики нет. Но в случае Oracle не все так однозначно.

Но сейчас, имея гигабайты оперативной памяти, часто не такая большая проблема развернуть в памяти даже огромный кусок данных и в памяти с ним работать.

Кроме того, в самой СУБД Oracle появилось множество возможностей, присущих раньше только MOLAP серверам:

SELECT SUBSTR(country, 1, 20) country,
SUBSTR(product, 1, 15) product, year, sales
FROM sales_view
WHERE country IN (\'Italy\', \'Japan\')
MODEL
PARTITION BY (country) DIMENSION BY (product, year)
MEASURES (sales sales)
RULES
(sales[\'Bounce\', 2002] = sales[\'Bounce\', 2001] + sales[\'Bounce\', 2000],
sales[\'Y Box\', 2002] = sales[\'Y Box\', 2001],
sales[\'All_Products\', 2002] = sales[\'Bounce\', 2002] + sales[\'Y Box\', 2002])
ORDER BY country, product, year;

Как видите, как минимум на примере Oracle (в других СУБД это часто не так) в реляционной СУБД появляются возможности, существовавшие раньше только у MOLAP серверов. И теперь уже не всегда легко сделать выбор будущей архитектуры OLAP. Конечно, у MOLAP есть свои преимущества и для каких-то задач они проявляются ярко.

Наверное, из прагматических соображений, в начале проекта создания аналитической системы на платформе Oracle, сначала стоит изучить как можно лучше все современные возможности Oracle для хранилищ данных и только уже четко представляя каких возможностей там нет, имеет смысл погружаться в MOLAP. Тем более что такие инструменты как OBI EE делают возможным использование OLAP незаметным для пользователя. (Агрегаты могут быть в OLAP, а детальные данные в реляционке, и при этом пользователь не замечает перехода между OLAP и детальными данными) И OLAP при необходимости можно подключить и потом.

Вообще, развитие реляционных СУБД и в частности Oracle показывает, что происходит его сближение с MOLAP, и в будущем, наверное, эта интеграция будет еще более тесной. И тогда, возможно, вообще не будет возникать вопроса какую архитектуру выбирать. По крайней мере, хотелось бы, чтобы так было.

Когда Дмитрий Волков предложил мне выступить на семинаре Database Options Details с рассказом про OLAP опцию в 11g, я сначала подумал - да о чем тут рассказывать? Между девятой и десятой версией было много различий. А между 10 и 11 вроде ничего особо не было. Ну, кроме Cube-Organized Materialized Views. Потом решил, что на семинаре будет масса людей, которые вообще с OLAP не работали, ни с какой версией, поэтому им, возможно, будет интересно узнать об OLAP вообще. Заодно при подготовке и посмотрю внимательнее, что там изменилось. Но оказалось, что изменений неожиданно много.

В этой статье я ориентируюсь на людей, которые уже знакомы с Oracle Express или Oracle OLAP, ну или хотя бы в общих чертах представляет, что это. Для начального ознакомления предлагаю почитать мои статьи "Что такое OLAP" (Часть 1 Часть 2)

Интеграция метаданных с Oracle Database

Первое, что бросилось в глаза, это то, что действительно через любой SQL инструмент теперь стало очень удобно смотреть на данные, лежащие в OLAP кубах. Причем, как только вы создаете какой-то объект с помощью Analytic Workspace Manager (AWM) (показатель, измерение и т.д.) он тут же становится виден из SQL. Для этого автоматически создается обвязка из VIEW, каждый из которых содержит вызов CUBE_TABLE. Выглядит это примерно так:

GLOBAL.UNITS_CUBE - это указание на то, что данные лежат в кубе UNITS_CUBE, который создавался в AWM. А CUBE_TABLE - табличная функция, такой универсальный вызов данных из объектов, лежащих в аналитическом прострастве.

В 10й версии тоже была возможность увидеть данные через SQL. Для этого была табличная функция OLAP_TABLE. (Собственно, она и сейчас есть, но смысла ее использовать, наверное, не очень много) Но чтобы заставить ее работать, нужно было предварительно создать кучу разных абстрактных типов данных, описания LIMITMAP и проч. Причем можно было ошибиться на любом шаге. В общем, для начинающих совершенно не подходило. Даже был такой плагин к AWM, который эти типы мог создать сам, что, в общем, частично проблему решало. Сейчас ничего делать не надо. Для каждого измерения и куба есть соответствующая вьюшка. Вы можете легко делать запросы к этим VIEW для того, чтобы например, фильтровать измерения по атрибутам. То есть, в вашем SQL запросе будут объединяться вьюшки измерений и куба, а оптимизатор сам знает как весь этот запрос протолкнуть через CUBE_TABLE внутрь OLAP движка, где он и будет отработан. Более того, никто не запрещает объединять данные из OLAP с данными из реляционки в любом запросе. Например, для того чтобы соединить агрегированные данные с детальными.

Кроме того, в 10g вызовы OLAP_TABLE работали довольно медленно. В 11g разница в скорости заметна невооруженным глазом. Причем, встроенная смотрелка AWM работает достаточно медленно, но если такой же запрос выполнить из SQL, он работает гораздо быстрее. Что говорит скорее всего о том, что смотрелка AWM генерирует запросы не так, или медленно обрабатывает результаты. Вообще, при желании это можно оттрассировать, но мне пока не хватило времени.

Увеличение скорости работы SQL связано с тем, что теперь обработка запросов оптимизатором сделана более умно и фильтрация значений по измерениям происходит внутри аналитического пространства, то есть в движке OLAP, а не в самом Oracle, как это было в 10g. Если сравнить запрос SQL и аналогичный ему DML запрос выполнять из OLAP Worksheet, то разница в скорости не заметна. То есть, SQL отрабатыват примерно также как и запрос непосредственно к движку.

Можно сделать вывод, что связка SQL - CUBE_TABLE - стала вполне пригодной для того, чтобы пользоваться ей для доступа к OLAP.

Как следствие, к данным OLAP можно обращаться любым ROLAP инструментом, например Oracle Business Intelligence Enterprise Edition, который работает с базой Oracle через SQL. Другие API не обязательны.

При этом, любые манипуляции с движком OLAP, если это необходимо, можно делать используя пакет DBMS_AW.

Упрощение стандартной формы

Когда я запустил новый AWM, оказалось, что в нем исчезла возможность смотреть структуру AW в режиме Object View.

Тут надо сделать небольшое отступление.

В Oracle Express были пользовательские объекты. Были и внутренние объекты, хранящие метаданные, которые физически были реализованы объектами Express, такими как измерения, отношения, переменные и и.д. Но внутренние были в основном скрыты от конечного пользователя. Да и большой небходимости в них залезать не было. В 9й версии, когда OLAP стал частью СУБД Oracle, сначала все оставалось, как было в Express, но потом, в районе 9.2.0.4 (точно не помню) была придумана так называемая стандартная форма (Standard Form, SF)

Это специальная обвязка метаданных, нужная для интеграции с СУБД Oracle. Но проблема в том, что те объекты, которые создавались в AWM и которые пользователь считал измерениями, показателями и т.д., на самом деле физически лежат совершенно в других объектах, а добраться до них можно было лишь расшифорвав сложный слой метаданных SF. А SF сама по себе менялась с каждым патчсетом. Express всегда славился своим очень гибким языком, который сейчас называется OLAP DML. На нем можно было написать очень сложные расчетные формулы и программы, для работы с многомерными объектами. Но сложность SF по сути убивала эту возможность, так как было довольно сложно расшифровывать метаданные, к тому же, велика вероятность, что в следующем релизе что-то поменяется и ваша программа перестанет работать. А SF считается объектом внутренним и поддержка прошлых версий SF не гарантируется.

Поэтому, в AWM прошлых версий было два вида представления объектов OLAP - Model View и Object View. Model View показывал как объекты выглядят через призму SF, Object View - как они хранятся на самом деле. Что и говорить, найти соответствия между двумя предствлениями было очень сложно.

В 11 версии все стало гораздо проще. Создаем мы из AWM куб UNITS_CUBE, а в нем показатель SALES. Теперь в OLAP DML мы можем увидеть объект UNITS_CUBE_SALES, название которого составлено из названия куба и названия показателя. Это же распространяется и на вычисляемые показатели. У нас теперь опять есть простой путь использования наших показателей в формулах и программах. И не важно, что на самом деле, это не куб, а формула, которая смотрит на другой объект. Для нас уже не важно знать, как именно он хранится.
Хотя, если кому интересно, можно и посмотреть:

Напомню, что через SQL тот же куб можно увидеть через вьюшку UNITS_CUBE_VIEW, а показатель SALES соответственно будет UNITS_CUBE_VIEW.SALES

И вот тут видно основное отличие данных, которые достаются из OLAP от данных, которые берутся из обычных таблиц Oracle. Обратите внимание на первую строчку, где четыре слова "TOTAL". В этой строке - агрегат (сумма) по продажам по всем измерениям. Если бы мы хотели достать сумму по всем измерениям из обычной таблицы, нам нужно было написать что-то вроде

А OLAP уже выдает все возможные агрегаты, поэтому вместо суммирования, нам нужно в условиях SQL запроса WHERE описать фильтр этой строки. Само суммирование делать не надо. Сумму уже посчитал OLAP сервер.

Это естественно накладывает некоторые условия на программирование SQL над OLAP. Например, в том же BI EE нужно специальным образом описать правила обсчета уровней иерархий, что бы не пошло суммирование по уже агрегированным данным.

Вторая тонкость в том, что если я напишу запрос по данным о продаже определенного продукта, и не укажу условия по другим измерениям, то из таблицы фактов мне выпадут все продажи этого продкута. Но если тоже самое сделать над OLAP, то кроме фактов детального уровня выйдут и все возможные комбинации агрегатов по разным измерениям, что в зависимости от структуры куба может быть объемом в десятки раз превышающим количество детальных фактов.
Иными словами, когда вы пишете запрос к OLAP нужно всегда ограничивать все измерения

Оперативная аналитическая обработка (OLAP) — это технология, которая упорядочивает большие коммерческие базы данных и поддерживает сложный анализ. Ее можно использовать для выполнения сложных аналитических запросов без негативного воздействия на системы транзакций.

Семантическое моделирование

Семантическая модель данных — это концептуальная модель, в которой описаны значения содержащихся в ней элементов данных. Организации часто используют собственные термины, иногда синонимы или даже разные значения одного и того же термина. Например, база данных инвентаризации может отслеживать компонент оборудования с ИД ресурса и серийным номером. Но база данных по продажам может ссылаться на серийный номер как на идентификатор ресурса. Эти значения сложно связать без модели, в которой бы описывалась связь.

Семантическое моделирование обеспечивает абстракцию на уровне схемы базы данных. В этом случае пользователям не требуются знания о базовых структурах данных. Семантическое моделирование также упрощает подачу запросов данных для пользователей: им не нужно выполнять вычисления и соединения в базовой схеме. Кроме того, обычно имена столбцов преобразуются в понятные пользователям названия, чтобы контекст и значение данных были очевидными.

Семантическое моделирование преимущественно используется для сценариев с большим числом операций чтения, например для аналитики и бизнес-аналитики (OLAP), которые отличаются от обработки данных о транзакциях с большим числом операций записи (OLTP). В основном это связано с особенностями типичного семантического слоя:

поведение агрегатов задано так, чтобы в средствах создания отчетов правильно отображались соответствующие данные;
определены бизнес-логика и вычисления;
включены ориентированные на время вычисления;
данные часто интегрируются из нескольких источников.

По этим причинам семантический слой обычно размещается над хранилищем данных.

Есть два основных типа семантических моделей:

Табличный. Используются реляционные конструкции моделирования (модели, таблицы, столбцы). На внутреннем уровне метаданные наследуются из конструкций моделирования OLAP (кубы, измерения, меры). В коде и скрипте используются метаданные OLAP.
Многомерный. Используются традиционные конструкции моделирования OLAP (кубы, измерения, меры).

Пример варианта использования

Данные организации хранятся в большой базе данных. Доступ к ним нужно предоставить бизнес-пользователям и клиентам, чтобы они могли создавать собственные отчеты и проводить анализ. Одно из решений — просто предоставить пользователям прямой доступ к базе данных. Но это решение имеет недостатки, например проблемы с безопасностью и управлением доступом. Кроме того, структура базы данных, в том числе имена таблиц и столбцов, может быть сложной для пользователя. Пользователям потребуется понять, к каким таблицам выполнять запросы, как эти таблицы должны объединяться, а также другие факторы бизнес-логики, которые следует учитывать для получения правильных результатов. Чтобы приступить к работе, пользователи также должны знать язык запросов, например SQL. Обычно это приводит к тому, что несколько пользователей предоставляют в отчете одни и те же метрики, но с разными результатами.

Второй вариант решения — инкапсулировать всю информацию, необходимую пользователям, в семантическую модель. Пользователям будет проще отправлять запросы к семантической модели с помощью любого удобного средства создания отчетов. Данные, предоставленные семантической моделью, извлекаются из хранилища данных. Благодаря этому все пользователи получают единую версию данных. Семантическая модель также предоставляет понятные имена таблиц и столбцов, связи между таблицами, описания, удобные функции вычисления и безопасность на уровне строк.

Типичные признаки семантического моделирования

Семантическое моделирование и аналитическая обработка обычно имеют следующие признаки:

Требование	Описание
схема	Схема при записи (строгое соблюдение)
Использование транзакций	Нет
Стратегия блокировки	None
Возможность обновления	Нет (обычно требуется повторное вычисление куба)
Возможность добавления	Нет (обычно требуется повторное вычисление куба)
Рабочая нагрузка	Большое число операций чтения, только для чтения
Индексация	Многомерное индексирование
Размер данных	Небольшой и средний размер
Моделирование	Многомерная
Форма представления данных	Схема типа "снежинка", куб или звезда
Гибкость запросов	Высокая гибкость
Масштаб	Большой (от десятков до сотен ГБ)

Когда следует использовать это решение

Рекомендуем использовать OLAP в следующих сценариях:

если нужно выполнять сложные аналитические и нерегламентированные запросы быстро и без негативного воздействия на системы OLTP;
если нужно предоставить бизнес-пользователям компании простой способ создания отчетов на основе ваших данных;
если нужно предоставить много агрегатов, с помощью которых пользователи смогут оперативно получать согласованные результаты.

Технология OLAP особенно полезна при выполнении статистических вычислений для больших объемов данных. Системы OLAP оптимизированы для сценариев с большим числом операций чтения, например для анализа и бизнес-аналитики. OLAP позволяет пользователям сегментировать многомерные данные на срезы, которые можно просматривать в двух измерениях (например, в сводной таблице), или фильтровать данные по определенным значениям. Этот процесс иногда называется "сегментирование и фрагментирование" данных. Его можно выполнять, даже если данные секционированы по нескольким источникам. Такой процесс помогает пользователям определять тенденции, выделять шаблоны и просматривать данные без специальных знаний о традиционном анализе.

Семантические модели помогают бизнес-пользователям абстрагировать сложности связей и быстро анализировать данные.

Сложности

При всех преимуществах систем OLAP они создают и некоторые проблемы:

Данные в системах OLTP постоянно обновляются за счет транзакций, передаваемых в из разных источников, а хранилища данных OLAP обычно обновляются гораздо реже, в зависимости от потребностей компании. Это означает, что системы OLAP скорее подходят для стратегических бизнес-решений, чем для немедленной реакции на изменения. Кроме того, для поддержки хранилищ данных OLAP в актуальном состоянии необходимо запланировать определенный уровень очистки данных и оркестрации.
В отличие от традиционных нормализованных реляционных таблиц в системах OLTP, модели данных OLAP обычно являются многомерными. Из-за этого бывает сложно или невозможно непосредственно сопоставить отношения сущностей или объектно-ориентированные модели, где каждый атрибут сопоставляется с одним столбцом. Поэтому вместо традиционной нормализации в системах OLAP обычно используются схемы типа "снежинка" или "звезда".

OLAP в Azure

В Azure данные, хранящиеся в системах OLTP, например в службе "База данных SQL", копируются в систему OLAP, например в Azure Analysis Services. Средства просмотра и визуализации данных, в том числе Power BI, Excel и решения сторонних производителей, подключаются к серверам Analysis Services и предоставляют пользователям интерактивные визуальные представления моделей данных для анализа. Поток данных из системы OLTP в OLAP обычно оркестрируется с помощью SQL Server Integration Services и службы Фабрика данных Azure.

Все следующие хранилища данных в Azure будут соответствовать основным требованиям для OLAP:

В службах SQL Server Analysis Services (SSAS) предлагаются возможности OLAP и интеллектуального анализа данных для приложений бизнес-аналитики. Вы можете установить службы SSAS на локальных серверах или разместить их на виртуальной машине в Azure. Azure Analysis Services — это полностью управляемая служба, которая предоставляет те же основные функции, что и SSAS. Службы Azure Analysis Services поддерживают подключение к различным облачным и локальным корпоративным источникам данных.

Кластеризованные индексы columnstore доступны в SQL Server 2014 и более поздних версий, а также в Базе данных SQL Azure и отлично подходят для рабочих нагрузок OLAP. Но начиная с версии SQL Server 2016 (включая Базу данных SQL Azure) вы можете воспользоваться гибридной транзакционно-аналитической обработкой (HTAP) благодаря обновляемым некластеризованным индексам columnstore. HTAP позволяет выполнять задачи обработки OLTP и OLAP на одной платформе, что избавляет от необходимости хранить несколько копий данных и использовать отдельные системы OLTP и OLAP. Дополнительные сведения см. в статье Начало работы с columnstore для операционной аналитики в реальном времени.

Основные критерии выбора

Чтобы ограничить количество вариантов, сначала ответьте на следующие вопросы:

Вы хотите использовать управляемую службу, а не управлять собственными серверами?

Требуется ли безопасная аутентификация с использованием Azure Active Directory (Azure AD)?

Вам нужно проводить анализ в реальном времени? Если да, оставьте только те варианты, которые поддерживают аналитику в реальном времени.

Аналитика в реальном времени в этом контексте применяется к одному источнику данных, например к приложению для управления ресурсами предприятия (ERP), в котором будут выполняться операционная и аналитическая рабочие нагрузки. Если требуется интегрировать данные из нескольких источников или обеспечить максимальную производительность для анализа с помощью предварительно вычисленных данных, таких как кубы, вам может потребоваться отдельное хранилище данных.

Вам нужно использовать предварительно вычисленные данные, например, чтобы предоставлять семантические модели, которые делают анализ более удобным для организаций? Если да, выберите вариант, который поддерживает многомерные кубы или табличные семантические модели.

Благодаря статистическим выражениям пользователи могут последовательно выполнять статистическое вычисление данных. Предварительно вычисленные данные также позволяют значительно повысить производительность при работе с несколькими столбцами с множеством строк. Предварительно вычисленные данные могут быть представлены в виде многомерного куба или табличной семантической модели.

Нужно ли интегрировать данные из нескольких источников за пределами хранилища данных OLTP? Если да, рассмотрите варианты, которые позволяют легко интегрировать несколько источников данных.

Матрица возможностей

В следующих таблицах перечислены основные различия в возможностях.

Общие возможности

Функция	Azure Analysis Services	SQL Server Analysis Services	SQL Server с индексами columnstore	База данных SQL Azure с индексами columnstore
Является управляемой службой	Да	Нет	Нет	Да
Поддержка многомерных кубов	Нет	Да	Нет	Нет
Поддержка табличных семантических моделей	Да	Да	Нет	Нет
Простая интеграция нескольких источников данных	Да	Да	Нет 1	Нет 1
Поддержка аналитики в режиме реального времени	Нет	Нет	Да	Да
Необходимость обработки данных для их копирования из источников	Да	Да	Нет	Нет
Интеграция с Azure AD	Да	Нет	Нет 2	Да

[1] Хотя SQL Server и Базу данных SQL Azure нельзя использовать для отправки запросов и интеграции нескольких внешних источников данных, можно создать конвейер для этих задач с помощью SSIS или фабрики данных Azure. Сервер SQL Server, размещенный на виртуальной машине Azure, предоставляет дополнительные варианты, например связанные серверы и PolyBase. Дополнительные сведения см. в статье Choosing a data pipeline orchestration technology in Azure (Выбор технологии оркестрации конвейера данных в Azure).

[2] Подключение к SQL Server на виртуальной машине Azure с помощью учетной записи Azure AD не поддерживается. Вместо этого используйте учетную запись домена Active Directory.

Читайте также: