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

OLAP-системы — «настольные» против серверных

Фраза «аналитическая обработка в реальном времени» стала синонимом анализа по методу «сечение-разбиение» (slice-and-dice). В настольных OLAP-приложениях SQL-запросы выполняются в базе данных, а возвращаемый набор результатов попадает в клиентское приложение, в котором дальнейшие манипуляции и создание сводных таблиц выполняются локально. Настольные OLAP-системы полезны, но не очень масштабируемы. Серверные OLAP-приложения, в которых приложение инициирует запрос к существенно более крупным удаленным базам данных на языке, отличном от SQL, более масштабируемы и обеспечивают возможности более глубокого анализа, чем настольные аналоги. На рынке серверных OLAP-приложений около дюжины игроков, но царствуют четыре продукта — Microsoft SQL Server Analysis Services, различные инкарнации Hyperion Essbase, Oracle Express и MicroStrategy.

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

Если OLAP-технология обеспечивает поддержку сложной аналитики и высокую производительность запросов, почему же она не доминирует на рынке? Основные причины — фрагментация рынка, масштабируемость, цена и гибкость. Фрагментация рынка служит плохую службу клиентам. До недавнего времени отсутствовали какие бы то ни было соглашения даже на уровне API-интерфейсов клиентского доступа. Ситуация постепенно улучшается благодаря недавнему принятию стандарта XML for Analysis большинством производителей OLAP-серверов.

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

Размерные сходства

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

Измерения в OLAP состоят из иерархий, или путей свертки. Отношение между иерархией данных и OLAP-измерением очень важно. Многие OLAP-приложения позволяют определять множественные иерархии на основе одного измерения, например, финансовый и стандартный календари. Если OLAP-приложение создавалось на основе реляционного многомерного хранилища данных, в нем должны уже присутствовать свернутые («суррогатные») клавиши, которые служат одинаковым целям как в OLAP, так и в реляционных системах.

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

Размерные различия

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

Также исключительно важно то, что OLAP-средства используют строгие иерархии для определения порядка агрегирования. OLAP-сервер обеспечивает своего рода ссылочную целостность между иерархическими уровнями в измерении. Чисто реляционная система не обеспечивает иерархической целостности, особенно при использовании схемы «звезда», а не «снежинка».

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

Произвольные временные диапазоны

Есть вещи, которые очень просто реализовать в чисто реляционной схеме и чрезвычайно сложно — в мире OLAP. Пример — создание запроса, возвращающего итоговый результат за произвольный промежуток времени. Такой запрос, как «общий объем продаж за первый квартал 2002 года», просто сформулировать, и он практически мгновенно обрабатывается OLAP-сервером.

Но горе тому пользователю, который пожелает получить сведения об общем объеме продаж за произвольный период, например, с 3 января по 12 марта 2002 года, то есть данные, иерархия которых не предопределена. Часть вины лежит на клиентских средствах создания запросов: некоторые из них не позволяют даже сформулировать такой запрос — их возможности ограничиваются запросом данных о ежедневных продажах в январе, феврале и марте. Если вашим бизнес-пользователям приходится выполнять подобные операции действительно часто, позаботьтесь о включении реализации этих функциональных возможностей в свой план.

Огромные преимущества

Я только что рассказал о вещах, которые действительно просты в реляционном мире, но трудны в реализации на некоторых OLAP-серверах. Но у OLAP-технологий масса преимуществ перед реляционными системами. Вот мой список преимуществ OLAP-средств:

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

В качестве простого примера рассмотрим баланс складских запасов: уровень запасов в январе и феврале, конечно же, не является простой суммой запасов в этих двух месяцах. Вы можете научить пользователей не суммировать уровни запасов за произвольные промежутки времени, но всегда ли они будут помнить ваши рекомендации? Все ли пользователи будут применять один и тот же метод агрегирования, например, конечный или средний уровень запасов? OLAP-системы справляются с подобными проблемами, делая работу более «прозрачной».

OLAP-система позволяет осуществлять на сервере сложные вычисления. Об ограничениях SQL как языка для поддержки аналитики я уже рассказывал: собственно, SQL не является аналитическим языком или языком для создания отчетов, вам потребуется сервер анализа для поддержки статистики, алгоритмов data mining или даже простых, основанных на правилах, бизнес-вычислений — таких, как локализация и распределение затрат. OLAP-сервер играет роль дружественного интерфейса к кубу данных, обеспечивая сотрудникам возможность пользоваться заданной на сервере аналитикой, не задумываясь о том, как и где она определяется и вычисляется.

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

Вычислительные операции можно определить лишь раз, а выполнять неоднократно. Чем больше вычислительных операций определено на центральном сервере, тем большая гибкость доступна вашим пользователям при обращении к данным. Даже простой инструмент анализа по методу slice-and-dice может использовать сложную аналитику, заранее определенную на OLAP-сервере. Эта возможность обычно недоступна в реляционных средах. И, конечно же, опытным пользователям можно разрешить определять на сервере сложные вычисления, чтобы ими могли воспользоваться остальные.

Работа с OLAP — одно удовольствие. Как правило.

Создано для анализа

Среди новейших тенденций на рынке OLAP-решений — стремление к снижению затрат, повышению производительности и масштабируемости, расширению функциональных возможностей в базовой области аналитики и распространении в соседние области, такие, как data mining. Эти тенденции будут руководить рынком на протяжении следующих нескольких лет по мере того, как ведущие поставщики баз данных станут больше внимания уделять OLAP-серверам и теснее интегрировать их с другими аналитическими приложениями и прикладными программами для управления данными.

OLAP-серверы представляют размерные данные в интуитивно понятной форме, позволяя множеству пользователей анализировать данные по методу slice-and-dice и обнаруживать интересную информацию. OLAP — «родной брат» размерных моделей в реляционной базе данных, обладающий интеллектом в области заданных на сервере отношений и вычислений, которые обеспечивают повышение скорости выполнения запросов и получение более интересной аналитической информации при помощи разнообразных инструментальных средств создания запросов. Следует думать об OLAP-сервере не как о конкуренте реляционного хранилища данных, а как о его расширении. Пусть реляционная база данных делает то, что умеет лучше всего, — обеспечивает хранение и управление данными. Не мучайтесь, заставляя реляционную СУБД и ее неуклюжий язык запросов, SQL, выполнять не свойственные им задачи — проводить анализ.

Джой Манди — приглашенный обозреватель, популяризирующий лучшие методы создания хранилищ данных и BI-решений на базе Microsoft SQL Server. С ним можно связаться по e-mail: joy@microsoft.com.