 |
|
|
|
Серая мышь голубых кровей. Об одной математической интерпретации OLAP-кубов
Серая мышь голубых кровей У скромной утилиты SSAS – серой мыши программного обеспечения SQL-сервера – обнаруживаются замечательная история и глубокая математическая подоплека Зачем все это нужно, искать отцов-основателей, идеи, лежащие в основе? Как говорится, «работает – и работает», что еще? Причин – две. Во-первых, аналитик или программист, который не понимает, как работает его средство, похож на известного пленника «китайской комнаты», придуманной американским философом Дж. Серлом. Пользуясь косвенными указаниями, этот пленник выполняет задания на китайском, не зная языка. Китайцы в восторге, принимают его за своего. Сам же он не понимает, что делает. По Серлу, этот пленник подобен вычислительной машине, имеющей сознание… Во-вторых, забыв о корнях, мы можем ненароком засушить дерево. Или вырастить декоративный бонсай на месте могучего дуба. Но от довольно витиеватых «вокруг да около» перейдем к делу. Работая несколько лет с OLAP-кубами (утилита MS SQL Server Analysis Services, SSAS), я часто задумывался, какую известную математическую идею они выражают? То, что такая идея есть, я не сомневался. Конструкции языка MDX, calculations из стандартного интерфейса SSAS, напоминали объекты теории меры и теории вероятностей: множества, меры, интегралы Лебега, условные математические ожидания и даже мартингалы, но все это в каком-то стертом илизамаскированном виде. Фигура загадочного Мойши Пасуманского, якобы создателя языка MDX, только накаляла интригу. Но пока работаешь, некогда «удовлетворять свое любопытство за счет работодателя», поэтому мои догадки копились, но не разрешались. Наконец, уйдя с работы, я получил досуг и возможность во всем разобраться. Преимущества OLAP Чем замечательны OLAP-кубы? Простотой в формулировке и скоростью в расчете аналитических показателей работы фирмы. Разумеется, любой конкретный показатель, рассчитанный методом OLAP, может быть получен другими способами: SQL-запросами к базе данных, содержащими агрегатные функции (типа sum), предложения group by, конструкции pivot table и т.д. На универсальных языках могут быть написаны прикладные программы или даже параметрические генераторы отчетов, обращающиеся к базе данных с SQL-запросами. Для ускорения аналитических расчетов в рамках учетных ERP-систем (Enterprise Resource Planning) могут создаваться промежуточные накопители данных (типа регистров в 1С). Кроме того, для задач формата desktop могут быть применены функционально близкие к OLAP-кубам «сводные таблицы» MS Excel. И все-таки, когда речь идет о больших объемах данных (миллионы записей), комплексных показателях и многоуровневых разрезах, десятках и сотнях пользователей, динамичном и вариативном стиле работы корпорации, все эти методы безнадежно проигрывают OLAP-кубам. С технической точки зрения, что означает «создать аналитику»? Как минимум написать SQL-запрос и выполнить его. Чтобы заказчик в дальнейшем мог самостоятельно запускать этот запрос, придется написать программу спользовательским интерфейсом и обращением к SQL-серверу. В программе можно предусмотреть параметризацию запроса и несколько форматов ответа. Думаю, никто не будет спорить, что компьютерные системы крупных фирм буквально забиты сотнями и тысячами таких программ. Эта программная свалка характеризуется дублированием программ, отсутствием преемственности, многократными перерасчетами одних и тех же показателей, наконец, постоянной загрузкой программистов и постановщиков повторной работой, расточительной для корпорации. Кстати, качество программ (в т.ч. SQL-запросов) будет не очень высоким. Ведь их пишут прикладные программисты, нанятые не для разработки аналитики, а для сопровождения учетных ERP-систем. (Примеры крайне неудачных алгоритмов работы с базами данных можно встретить и среди обработок 1С, и среди приложений MS Dynamics AX, когда программный код, написанный в технике обработки данных 90-х годов «файл-сервер», применяется вместо более эффективной техники «клиент-сервер» [1].) Напротив, в методологии OLAP-куба не нужно писать ни SQL-запросов, ни программ. Новые показатели и разрезы либо создаются в стандартном интерфейсе SSAS на стадии дизайна OLAP-куба, либо формулируются на языке MDX в виде выражений calculations на стадии эксплуатации. Все существующие в OLAP-кубе аналитики полностью интегрированы и произвольно сочетаются друг с другом в отчетах. Это обеспечивает операция Deploy, запускаемая после создания новых аналитик. Операция Process, запускаемая периодически, обновляет данные куба, в частности, пересчитывает все показатели во всех разрезах (и их сочетаниях). Отметим, что матобеспечение SSAS написано разработчиком (MS) навысоком профессиональном уровне, так что головоломно сложные операции Deploy и Process выполняются достаточно быстро. После операций Deploy и Process все показатели и разрезы OLAP доступны пользователям корпорации (всоответствии с их правами), причем уже без повторных перерасчетов. Какие же конструктивные особенности позволяют OLAP-кубам избежать указанных выше недостатков? Наверное, это два главных свойства. Во-первых, в рамках OLAP-куба все возможные SQL-запросы уже написаны (на стадии дизайна) и, во-вторых, они уже вычислены (после операции Process). Поэтому пользователю остается только вытянуть мышью из списка нужные показатели и нужные разрезы – и на экране появится соответствующая таблица с данными. Нам представляется, что задача корпоративной аналитики (в плане техники расчета) решена методом OLAP в наиболее общем виде, так что все прочие решения являются как бы ее частными случаями. Иначе говоря, функциональность OLAP влюбом случае с необходимостью выполняется в корпорации. Но, если не используется OLAP (SSAS) – специализированное программное средство, – значит, выполнение функциональности OLAP берут на себя прикладные программы и ихразработчики, по сути, «изобретая велосипед» и не эффективно расходуя ресурсы корпорации. Посвятим абзац пользовательским интерфейсам OLAP. Это вообще не тема статьи, поэтому просто укажем для определенности, что можно представить себе два интерфейса. Во-первых, стандартный интерфейс разработчика SSAS, наиболее полный и гибкий, позволяющий работать с кубом на языке MDX. Во-вторых, интерфейс между Excel и OLAP, простой и эффективный, работающий на чтение, внешне похожий на Excel Pivot Table, предназначенный для конечных пользователей. В англоязычной литературе с OLAP-кубами связаны две группы сущностей, называемые dimensions и measures и переводимые по-русски соответственно как «измерения» и «меры». Этот перевод, несомненно, корректен, но не очень хорош исемантически, и синтаксически. Русские слова «измерение» и «мера» в отличие от оригинальных английских терминов dimension и measure близки по смыслу и написанию, что не редко приводит к путанице в русских текстах по OLAP. Между тем в русской статистической литературе существуют наглядные и выразительные термины, релевантные понятиям measure и dimension. Это слова «показатель» и «разрез». Скажем, «показатель суммы отгрузки в разрезе поконтрагентам и по датам». В данной статье мы будем использовать и русские, и английские термины. Ниже мы покажем, что OLAP-куб с точки зрения высшей математики представляет собой «измеримое пространство» – особый объект теории меры, при этом «разрезы» dimensions задают «пространство элементарных исходов», имеющее топологию многомерного «куба». А «показатели» и в самом деле порождают меры measures (аддитивные и не только), определенные на алгебре подмножеств многомерного «куба». Мы рассмотрим также вероятностную трактовку OLAP-куба, в которой показатель может быть случайной величиной с.в.; показатель в разрезе – условным математическим ожиданием с.в.; показатель в последовательности разрезов – мартингалом (случайным процессом особого вида). Кроме того, мы покажем, что OLAP-куб – это не просто некий стихийно сложившийся инструментарий, оказавшийся полезным при расчете аналитики, но что OLAP – это математическая теория аналитики, формализация интуитивных представлений о ней. Статью целиком читайте в журнале «Системный администратор», №09 за 2016 г. на страницах 70-74. PDF-версию данного номера можно приобрести в нашем магазине.
|
КОНСТАНТИН ТОКМАЧЕВ, ЗАО «Русское море», системный аналитик, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
