SSAS 2012: от многомерной к табличной модели данных

Введение

Табличная Модель Данных как основа для решений в бизнес-аналитике была предложена корпорацией Майкрософт в компоненте по имени PowerPivot, скромном дополнении к Microsoft Office Excel. С тех пор дискуссии о значении этой модели не стихают и по сей день. Апологеты новой технологии убеждены в ее революционности, скептики считают, что это не более чем эволюционная подвижка. В SQL Server 2012 Analysis Services (SSAS 2012) Майкрософт представил теперь уже серверный вариант аналитической базы данных, основанной на принципах Табличной Модели. Естественно, это не может не добавить в диспуты свежую струю.

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

Предпосылки

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

Главной (хотя и не единственной) предпосылкой явился резко возросший интерес к методам IT бизнес-аналитики со стороны малого и среднего бизнеса. Как следствие, поиск удобных инструментов и методов интерактивного бизнес-анализа. В ходе этого поиска выяснилось, что практически монопольное положение в этой области занимает так называемый Многомерный Анализ Данных (Multidimensional Data Analysis). В то же время стало очевидно, что данная технология, обеспечивая замечательную гибкость и производительность при решении аналитических задач в крупных организациях, является чересчур громоздкой и неоправданно сложной для бизнес-анализа в небольших предприятиях.

Соответственно, возникла потребность в упрощенных технологиях, адаптированных для бизнес-задач небольших предприятий. Именно таким замечательным решением и стал Табличный Анализ Данных на основе Табличной Модели.

(Естественным следствием стало «свержение» монополии Многомерного Анализа в области интерактивной бизнес-аналитики – какое же революционное преобразование обходится без свержения? Впрочем, Многомерный Анализ никто не отменял, его лишь пока слегка потеснили, так что теперь ему придется делить область бизнес-анализа с другой, весьма перспективной технологией.)

Еще одно введение в бизнес-аналитику

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

Во-первых, дадим определение. Бизнес-анализ – это процесс, в ходе которого делаются выводы, предлагаются бизнес-решения и строятся прогнозы. Разумеется, все это должен выполнять человек, являющийся специалистом в соответствующей области бизнеса: финансов, логистики, маркетинга и т.д. Такой специалист и является, собственно, аналитиком. Исходная информация для процесса анализа, традиционно размещается в IT-структурах, так что для ее извлечения аналитику не обойтись без услуг IT-специалиста. Таким образом, в процессе бизнес-аналитики участвуют две стороны: аналитик и IT-cпециалист, как поставщик информации. От успешности их «симбиоза» зависит общая эффективность процесса.

Во-вторых, какие материалы нужны аналитику? Точнее сказать, какие материалы ему нужны от IT-специалиста? Здесь ответ оказывается неожиданно простым – требуются сводные таблицы и диаграммы. Много и разных.

В-третьих, отношения между IT-специалистом и аналитиком строятся в соответствие с известной дилеммой: «Что дать нуждающемуся – рыбу или удочку?». То есть, либо IT-специалист изготовит нужные аналитику таблицы и диаграммы (вариант «рыба»), либо сам аналитик будет создавать свои таблицы и диаграммы, а IT-специалист лишь снабдит его нужными данными и инструментами (вариант «удочка). Не вдаваясь в плюсы и минусы каждого из этих подходов, отметим, что нынешние тенденции однозначно показывают в пользу второго варианта.

Четвертое, коль скоро аналитик будет сам конструировать для себя таблицы и диаграммы, нужно снабдить его удобным и относительно простым инструментарием. Выбор таких программных инструментов достаточно велик, так что при желании можно найти на любой вкус. Майкрософт, в частности, предлагает для этих задач замечательный и популярнейший инструмент Microsoft Office Excel с фунционалом PivotTable (не путать с PowerPivot – это далеко не одно и то же).

Наконец, пятое. Для IT-специалиста главной проблемой становится предоставление исходных данных, нужных аналитику, в максимально удобном, комфортном виде. Эта задача, в свою очередь, основывается на нескольких простых подходах: а) отобрать только те данные, которые действительно нужны для работы; б)задать логические связи между ними; в) присвоить этим данным понятные названия; г) разбить их по категориям. Такое удобное и понятное размещение данных для последующего бизнес-анализа называется семантической моделью. Традиционно такие модели представляют собой наборы таблиц, связанных в форме «звезды» или «снежинки».

Таким образом, главная задача IT-профессионала, специализирующегося в области бизнес-аналитики, кратко формулируется так: создание семантической модели данных.

Многие годы в качестве такой семантической модели выступал Многомерный Куб. И именно его призвана заместить, по крайней мере в определенных областях бизнеса, новая семантическая модель – Табличная Модель Данных.

Типовая технологическая цепочка

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

• Традиционно первоисточником данных являются базы данных OLTP (Online Transactional Processing – Интерактивная обработка транзакций), в которых отображаются текущие бизнес-процессы (например, размещение и продвижение заказов). Не вдаваясь в детали, отмечу, что специфика этих баз такова, что они, как правило, мало пригодны для непосредственного бизнес-анализа.
• Соответственно, данные из этих баз экспортируются в специальные Хранилища Данных (DW – Data Warehouses). Такие хранилища способны накапливать и объединять данные из самых разных источников. Отметим важный момент – структура данных в хранилищах обычно не повторяет структуру исходных OLTP-баз. Напротив, информацию в них стараются размещать в относительно удобной и понятной форме – обычно в виде «звезды» или «снежинки», так что уже на этом уровне можно разглядеть прообраз семантической модели.
• Хранилища в свою очередь выступают в качестве источников для так называемых Многомерных Баз Данных OLAP (Online Analytical Processing – Интерактивная Аналитическая Обработка). В таких базах можно выделить два логических уровня: Представление Источника Данных (DSV – Data Source View) и собственно Многомерный Куб (Multidimensional Cube). Назначение DSV – предоставить промежуточную модель для последующего создания кубов: во-первых, DSV отбирает (отфильтровывает) для отображения только нужные таблицы; во-вторых, эти отобранные из разных источников таблицы объединяет связями в единую модель. DSV являются исходной структурой для создания Многомерных Кубов, которые и являются окончательными семантическими моделями. Как видно на картинке, одна база ОLAP может содержать несколько DSV, и, в свою очередь, один DSV может служить основой для создания нескольких кубов.
• Аналитики с помощью клиентских приложений, таких как Excel PivotTable, подключаются к базе OLAP, выбирают нужный куб и используют его структуру и данные для создания своих сводных таблиц и диаграмм.
• В этой цепочке мы видим четыре уровня моделей данных: стурктура баз ОLTP, структура хранилищ, DSV и куб. Важно отметить, что три последние модели — DW, DSV и Куб -обычно имеют вполне понятный для аналитика вид и, с теми или иными оговорками, могут считаться семантическими.

От многомерной модели к табличной

Естественно задаться вопросом – не слишком ли много семантических моделей в этой последовательности? Ответ зависит от масштаба предприятия. Для крупного предприятия, насчитывающего сотни, а возможно, и тысячи баз данных OLTP, десятки кубов и хранилищ, такая цепочка отнюдь не является избыточной. Напротив, она обеспечивает максимальную гибкость решений и, соответственно, совершенно обоснована.

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

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

Здесь, пожалуй, пора заглянуть «внутрь» самого Многомерного куба, который пока в нашем рассмотрении был «черным ящиком».

Основой куба является так называемая Многомерная Модель. Эта модель исходит из того, что конечной целью является изготовление сводных таблиц, представляющих собой наборы агрегированных данных. Соответственно, в модели все данные изначально разбиты на две разновидности: те, которые предназначены для последующего агрегирования – так называемые меры (measures), и те, которые задают контекст агрегирования – их называют измерения (dimensions). Например, мы собираемся создать таблицу, где по вертикали указаны названия магазинов, по горизонтали – годы, а внутри суммарные объемы продаж по годам и магазинам. В этом случае объем продаж в модели фигурирует как мера, годы и магазины — как атрибуты измерений, а суммирование – частный случай агрегирования. Для дополнительного удобства логические связи между мерами и измерениями заданы непосредственно в модели, а функции агрегирования привязаны непосредственно к мерам также внутри модели. Так что для создания сводной таблицы достаточно только выбрать нужные меры и атрибуты измерений, все остальное – логические связи между выбранными компонентами и способ агрегирования берется непосредственно из самой модели, так сказать, «прозрачно» для пользователя.

Таким образом, Многомерная модель – это, по сути, совокупность многих мер и измерений, логически связанных между собой. Отсюда, кстати, и само название «многомерная», сами же по себе меры и измерения имеют вполне табличный, «двумерный» вид.

Важно отметить, что куб помимо самой модели имеет дополнительную функциональность, интересную для конечного потребителя, например, возможность создания иерархий из атрибутов измерений и очень популярные ныне компоненты – Ключевые Показатели Эффективности (KPI – Key Performance Indicators).

Соответственно, можно представить куб следующим образом:

Теперь вернемся к нашей технологической цепочке для небольшого предприятия. Для компактности на картинке отображены только те компоненты, которые содержат интересующие нас семантические модели (DW, DSV и Куб).

Здесь мы столкнемся с ситуацией, часто встречающейся на практике – все три модели очень похожи, в особенности DSV и Многомерная модель. Так что решение напрашивается само собой – что нибудь выбросить. Вопрос — что именно?

И вот тут разработчики Майкрософт приняли, на первый взгляд, парадоксальное решение – удалить из цепочки Многомерную модель, а вместе с ней и само понятие Многомерный куб! Оставшийся же от куба функционал (иерархии, KPI и проч.) присоединить непосредственно к DSV! Парадокс заключается в том, что технически проще было бы изъять DSV, а куб вместе со всей своей сложившейся и проверенной функциональностью оставить нетронутым. Тем не менее сделали так как сделали!

Перед тем как объяснить смысл этого парадоксального решения, посмотрим как теперь выглядит наша аналитическая база. Теперь она уже называется База Данных Табличной Модели. Сам DSV, получивший в «наследство» функциональность Куба, также называется по другому – Табличная Модель данных.

<img src="" alt=«image»/>

Общая картина технологической цепочки будет выглядеть примерно следующим образом:

Сразу отметим, что для клиентов здесь мало что изменилось. К Базе Данных Табличной Модели, можно подключаться привычными способами, например, с помощью уже упомянутого инструмента Excel PivotTable (небольшое техническое отличие — в базе может быть только одна модель).

Так в чем же революционность?

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

Для ответа, еще раз вернемся к парадоксу, на который мы уже обращали внимание: вместо того, чтобы пойти по пути наименьшего сопротивления и в качестве лишнего звена выбросить DSV, разработчики Майкрософт поступили неожиданно – изъяли Многомерную модель. А вслед за удалением Многомерной модели из базы исчез Многомерный Куб, а вслед за этим и само понятие Многомерного Анализа.

Как ни покажется парадоксальным, именно это изъятие «многомерности» и является главным революционным достижением!

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

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

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

Термины «многомерный куб», «многомерная» модель, «многомерный анализ» давят на психику обычного человека, создают психологический барьер и, соответственно, являются тормозом к освоению данной области – вот простая истина, открытая разработчиками Майкрософт. Избавиться от «многомерной» терминологии, заменить ее на такие простые и привычные «плоские» термины, как таблицы и столбцы – и психологический барьер исчезнет.

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

Заключение

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

Многие годы Майкрософт пытался привить в качестве средства автоматизации административных задач VBScript (усеченную версию Visual Basic). И все эти годы сисадмины (не все разумеется, но многие – такие вещи вообще проявляются только статистически) стойко противились этому вполне достойному средству, предпочитая создавать сценарии автоматизации на куда более примитивном языке командной строки. Противостояние продолжалось годами, пока в чью-то светлую голову не пришла идея предложить сисадминам новый продвинутый механизм автоматизации, но внешне напоминающий привычную для них командную строку – PowerShell. И дело пошло на лад — новый инструментарий был принят с восторгом, хотя, признаемся, положа руку на сердце, PowerShell ненамного проще VBScript. Просто и здесь был грамотно учтен психологический момент.