OLAP. Часть 1.
Старо как мир компьютерный
Аналитическая обработка данных в онлайне.
Именно так можно расшифровать и представить по-русски акроним OLAP
— on-line analytical processing. Некоторую иронию содержит в названии
предмета слово «online», которое в наши новейшие дни отражает модальность
присутствия в Интернете.
Здесь необходимо отметить следующее: в дни, когда
появились системы поддержки принятия решений, так называемые DSS
(decision support system), из которых как отдельный компонент выделились
OLAP, онлайн был синонимом интерактивности (sic!). То есть, был
режим пакетной (batch) обработки данных (инициируемый, как помнится,
вводом колоды перфокарт в хобот чудовищного монстра — считывателя)
и был онлайновый режим, который понимался как работа через
некоторый (жуткий, должен сказать, с ядовито-зеленого цвета экраном)
интерактивный терминал.
Предания
Как повествует Найджел Пендз, автор специализированного
интернет-издания The OLAP Report, многомерный анализ, ставший основой
решений OLAP, восходит к опубликованной в 1962 году работе Кена
Айверсона «A Programming Language», en masse отмеченного как язык
APL. Это была пионерская работа, которая на бумаге, с высокой связностью
и логичностью описывала некоторый полезный язык программирования,
скорее — как идею. Только в конце 60-х годов APL нашел реализацию
в мастерских IBM*.
Сущность APL заключалась в том, что это был весьма
элегантный, хотя и довольно причудливый формальный язык, эффективно
оперирующий с многомерными переменными. Нужно заметить, что по оригинальной
задумке Айверсона, APL вообще не предназначался к использованию
в качестве очередного языка программирования, подобно бесчисленным
Фортранам, Алголам, Коболам и иже с ними… Это была формальная схема
преобразования многомерных данных. А потому таким низким предметам,
как вывод результатов на экраны или на печать, уделялось крайне
мало внимания.
И, не имея возможности опираться на убогие в те годы
возможности компьютерной символики (графики-то еще и не было!),
Айверсон ввел в пользование буквы греческого алфавита плюс ряд специально
подобранных значков. А потому тексты программ APL оказались столь
мудреными, что их мало кто (кроме прямых авторов) мог вообще понимать.
Язык получил новое прозвище: WOL — Write Only Language («язык только
для письма»).
К сожалению, приходится повторять, все это происходило
еще в те годы, когда не было ни цветных экранов с графикой достаточного
разрешения, ни лазерных, ни струйных принтеров. А потому разного
рода нестандартная символика требовала применения специальных
экранов, клавиатур, принтеров и другого периферийного оборудования.
(Позднее для представления некоторых концепций и метафор вместо
греческих букв в APL стали применять английские слова, но пуристы
начальной идеи всячески этому препятствовали.)
Еще одним обстоятельством проблем продвижения APL
явилось то, что реализация языка была чистым интерпретатором (не
компилятором), а это означало потребление больших, в те годы чрезвычайно
дефицитных и дорогих ресурсов — памяти, скорости процессоров и т.
п.
И все-таки, несмотря на столь невзрачный старт, системы
APL вовсе не исчезли: они во множестве применялись в деловых приложениях
70-х и 80-х годов, функционально очень напоминая то, что потом получило
название OLAP. Компания IBM даже создала специализированную операционную
систему — движок для приложений APL, которая называлась VSPC. Пользователи
воспринимали эту среду как средство увеличения персональной производительности.
Стоит заметить, что электронных таблиц (speadsheets) тогда еще не
существовало. Даже в наши дни существуют несколько приложений OLAP,
внутри которых работают программы APL.
И, все-таки, оригинальный APL был слишком интеллектуально-элитарным
для широкой аудитории потребителей аналитических инструментов —
даже при тех обстоятельствах, что аппаратные проблемы постепенно
находили решения. Надо сказать, что APL нашел свои инкарнации на
платформах PC, в начале 80-х, где они пребывают (правда, без особого
процветания) и по сей день.
В этом эпосе важнее другое: APL стал прародителем
других поколений инструментов многомерной аналитики. Так, в 1970
году в ходе академических изысканий был создан ориентированный на
предметные области инструмент многомерного анализа — Express. И
сейчас, через более, чем 30 прошедших лет, главные решения OLAP
покоятся на оригинальных кодах Express — стоит снять неплотный поверхностный
слой и обнаруживается: там все те же алгоритмы и логические находки.
Характерным примером является история с разработкой
OLAP от Oracle, внедренной в систему Oracle9i OLAP Services:
в технологическом решении одновременно присутствуют и движок Express
(обозванный в данном случае как analytic workspace), и новая
машинка типа ROLAP**.
Следующее десятилетие, 80-е годы, обозначилось дальнейшим
развитием направления. В начале декады появилась система Strategem,
которая в виде некоторой следующей личины Acumate (являющейся с
определенных пор собственностью Lucent Technologies) весьма активно
фигурировала на рынках до середины 90-х годов. Являясь отдаленным
духовным родственником Express, Strategem никогда не достигала рыночного
успеха своего предшественника. Между тем, Computer Associates (CA)
приобрела Strategem, затем парочку решений ROLAP — Prodea Beacon
и Information Advantage DecisionSuite, которые и сгинули подобно
многим прочим во всеядном чреве CA.
В 1981 году компания Comshare выставила свою новую
систему System W, которая первой была основана на концепции гиперкубов;
одновременно эта система была ориентирована на пользовательскую
разработку приложений, способных работать с финансовыми данными.
Эта система и по сей день широко адаптирована во многих компаниях.
Ее привлекательными свойствами являются возможности задания непроцедуральных,
слабоформализованных правил, профилирование многомерных массивов
на полном экране, приятное редактирование многомерных массивов,
автоматические рекалькуляции по массивам, интеграция с массивами
данных в базах реляционных структур.
Однако слишком высокие потребности в компьютерных
ресурсах, а также меньшая степень программируемости по сравнению
с более современными системами все далее выводит System W из зоны
популярности у информационных менеджеров.
Доступные сейчас на платформах Unix, System W не являются
продуктами «клиент-сервер». Они вообще не продвигались разработчиком
в явном виде как системы OLAP. Позднее Comshare развила идеи System
W в своем изделии Commander Prism, в дальнейшем — Comshare Planning.
Компания Hyperion Solutions в те же годы выпустила
свой продукт Essbase, идеологически явившийся весьма близким родственником
System W — ориентация на приложения обработки финансовой информации,
гиперкубическая основа. По иронии судьбы (очень похоже, не судьбы,
а человеческой иронии), впоследствии Comshare лицензировала Essbase
для использования продукта в качестве движка более поздних OLAP-решений
(вместо того, чтобы использовать более продвинутые решения своей
собственной System W).
В начале тех же 80-х годов появилось такое программное
произведение, как Metaphor. Оно было ориентировано на облегчение
труда профессионалов-маркетеров в компаниях розничной торговли товарами
общего потребления. Этот инструмент внес немало новых идей в OLAP,
что оставляло его чрезвычайно популярным на протяжении даже всего
прошлого десятилетия. В состав новшеств, предложенных Metaphor,
входили архитектура «клиент-сервер», многомерный процессинг реляционных
баз данных, возможности обработки данных для рабочих групп, объектно-ориентированная
разработка приложений.
К сожалению, возможности Metaphor не могли быть реализованы
на основе типичных аппаратных основ персональных компьютеров тех
времен. Требовалось изготовление заказных компьютеров и создание
специальных сетевых инфраструктур. И вообще, поскольку в Metaphor
никогда не учитывались стандарты графических интерфейсов, все это
дело плавно закруглилось бы.
Но случилось так, что IBM пожелала купить Metaphor.
В 1994 году в IBM пришли к решению — интегрировать уникальную технологию
Metaphor (быстренько переименованную в DIS) с некими будущими технологиями
самой IBM и полностью ассимилировать все остатки отдельного определения
Metaphor. Эти замыслы вызвали настолько сильные протесты со стороны
состоявшихся пользователей Metaphor, что IBM была вынуждена продолжить
сопровождение этого продукта. И по сей день изделие поддерживается
IBM для лояльных владельцев прежних версий, фигурирует под именем
IDS, но вряд ли сколько-нибудь активно продвигается.
Более важно то, что креативная концепция Metaphor
стала начальной позицией при проектировании новейших систем Information
Advantage, Brio, Sagent, MicroStrategy, Gentia… Далеко не все референции.
Одним из замечательных свойств всех производителей
новых клонов и генераций ROLAP на основе архитектуры Metaphor является
их неприбыльность в этом плане деятельности. Вообще, поставщики
законченных решений ROLAP, что продемонстрировали такие компании,
как Metaphor, MicroStrategy, MineShare, WhiteLight, STG, IA, Prodea
и др. не набирают балансовых прибылей по следующим причинам: естественный
рынок для систем класса ROLAP слишком мал, но требует слишком больших
трудозатрат на производство единичных изделий. То есть существенной
бизнес-модели, как таковой, вообще не создано.
В середине 80-х возник термин EIS (Executive Information
System). Первые решения данного вида, известные как Command Center,
были предложены компанией Pilot (хотя, если быть объективным, почти
за десять лет до того разработки концептуально сходных систем были
выпущены компаниями IRI и Comshare). Это были системы, ориентированные
на обработку корпоративных данных, с архитектурой, которую сейчас
признали бы как типичную для систем типа «клиент-сервер».
Вследствие того, что ресурсы персональных компьютеров
середины 80-х были очень ограниченны, вся архитектура OLAP-систем
была сервер-ориентированной, в особенности, это стало почти модой
по пришествии систем, подобных EUREKA, объединявших концепции стратегического
анализа.
Сейчас почти не существует примеров использования
системы Command Center, она давно вне рыночных предложений. Тем
не менее, полезные свойства этого инструмента прослеживаются практически
во всех OLAP сегодняшнего дня. Сюда можно причислить автоматическую
обработку временных профилей на массивах данных, многомерную аналитику
в режиме «клиент-сервер», упрощенную и удобную формулу человеко-машинного
интерфейса. Большинство из этих свойств получило дальнейшее развитие
в продуктах Pilot, таких, к примеру, как Analysis Server. Что там
теперь, сказать сложновато, поскольку компания Pilot в августе 2000
года была куплена Accure Software.
Возвращаясь к более ранней истории, нужно заметить,
что в конце 80-х годов аналитики-практики начали широко использовать
электронные таблицы, которые впервые проявились в системе Complete
(одноименной компании). Первоначально это изделие позиционировалось
как весьма дорогой инструмент для профессионалов. Однако поставщики
решения не смогли найти столь обширного рынка для Complete, чтобы
обеспечить на нем прибыльный бизнес. Изделие было куплено Computer
Associates, заодно с несколькими другими системами, основанными
на электронных таблицах, например, SuperCalc, 20/20, пр.
Основным результатом того, что Complete была ассимилирована
Computer Associates, стало снижение цен на продукт. Кроме того,
CA сняла защиту программного продукта от копирования (что всегда
полезно делать при расширении рынка), а также начала жесткий промоушн.
Но, несмотря на такие пылкие меры, особого рыночного успеха с этим
делом у CA так и не воспоследовало, как, впрочем, и с другими начинаниями
компании в области OLAP.
Лет через пять следы Complete в работах CA можно было
обнаружить разве что в изделии SuperCalc версии 5, однако аспект
оперирования с многомерными массивами данных там уже и вовсе не
просматривался.
Знаменитая своей бурной историей компания Lotus********
стала следующим игроком, попытавшемся играть на поле систем с многомерными
электронными таблицами, выпустив свой пакет Improve. С изрядной
бравадой этот пакет был реализован на системной основе известного
детища основателя Apple Стива Джобса — компьютере NeXT. И там все
было вроде бы в порядке, и файлы из известного 1-2-3 импортировались
нормально, но когда Improve был перенесен на платформу Windows,
то оказалось, что милый нашим душам Excel справляется с теми же
задачами по крайней мере не хуже. То есть, для Improve рынка не
оказалось так же, как для Complete в потугах CA.
И Lotus убрала Improve с рынка, а развитие систем
этого направления было прекращено. Собственно говоря, это было обусловлено
еще и тем, что дальнейшая разработка новых инструментов многомерного
процессинга требовала значительных финансовых вливаний, а эти системы
не могли быть реализованы эволюционно — хотя бы из тех соображений,
что электронные таблицы первого поколения, оперирование которыми
было основано на макросах, были несовместимы с новыми подходами
OLAP.
Еще одним обстоятельством закругления этой линии стало
то, что концепция небольших анализаторов многомерных данных, поставляемых
как решения для персональных применений, очевидно, не была адекватной
потребностям делового мира. И здесь нашлась Microsoft, добавив возможность
PivotTables к Excel. Несмотря на то, что лишь малая часть пользователей
Excel хоть раз обращается к PivotTables, вероятно, что это наиболее
популярный инструмент многомерного анализа, учитывая массу пользователей
самого Excel. Кстати, уже в Excel 2000 появилась более совершенная
версия PivotTables, способная проявляться как OLAP на экране, а
кроме того, способная становиться клиентом системы Microsoft Analytic
Services.
Нужно заметить, что функциональные возможности PivotTables
в Excel 2000 не превышают таковых от прочих поставщиков решений:
смело можно делать вставки и включки (plug-ins).
Помимо того, что получали свое развитие методы многомерного
анализа данных, появились потребности обработки данных в очень больших
базах, построенных на реляционной основе. Таким образом, появились
решения OLAP для реляционных баз. Эти решения отличаются гораздо
большей стоимостью использования и сопровождения, в расчете на пользователя.
Причиной тому более многочисленные, специализированные и вариантные
инструменты работы с данными, структурированными по реляционному
принципу. Ну а, впрочем, именно эти инструменты дают путь-дорожку
для аналитики на данных вообще аморфных, то есть, не структурированных!
После того ряд разработчиков провел расширение концепции,
приведя к тому, что стало называться десктоп-OLAP (хотя, нужно заметить,
именно многомерные кубы, то есть ортогональные разрезы данных, даже
в присутствии в Web, остаются главной концептуальной особенностью
этих систем — так легче и понятнее). А вообще, все это процессирование
выглядит ни чем иным, как выборкой из многомерных массивов сложных
данных трехмерных изображений, обработкой их и представлением к
некоторой визуализации.
Надо сказать, что такой простой метод, как генерирование
визуально воспринимаемых трехмерных изображений, оказался просто
удобным. Уже в те года компания Cognos (со своими изделиями Impromhtu
и PowerPlay) декларировала о неизбежности перевода многомерных изображений
в профили меньшей (максимум 3-мерной) размерности.
В наши дни даже крупнейшие поставщики систем управления
реляционными базами данных, такие как Oracle, IBM, Computer Associates,
Microsoft и Sybase — все они разрабатывают продукты OLAP. По иронии
судьбы снова случилось так, что никто из них не приложил даже малейших
усилий к становлению систем многомерной аналитики данных на ранних
этапах развития этого направления.
На деле
Большая часть моей работы, как вы уже обнаружили,
была посвящена истории OLAP. Это не случайно, поскольку OLAP — уже
история, а эта наука всегда поучительна. На самом деле суть OLAP,
как и всякого достаточно сложного технологического предмета, одновременно
и проста, и расплывчата.
Вышеупомянутый источник The OLAP Report, начавший
свои публикации в 1994 году, отмечает, что с ходом времени определенности
в толковании OLAP только убывает. Нет ни малейших оснований верить
декларациям самих производителей программных систем, гласящих, что
их творения относятся к классу OLAP. Нет никаких поводов полагать,
что принадлежность к некоему практически пассивному органу OLAP
Council может дать преимущества в толковании смысла предмета. В
общем, как всегда, дело неясное…
Тем не менее, существует тест FASMI, позволяющий по
существу идентифицировать инструменты, относящиеся к классу OLAP.
Важно то, что этот тест не обращается к особенностям реализации
конкретного изделия — признаками являются функциональность и прикладные
свойства.
Собственно, критерий принадлежности к изделиям OLAP
содержится в самом названии теста FASMI — Fast Analysis of Shared
Multidimentional Information (быстрый анализ совместно используемой
многомерной информации). Это определение впервые было дано The OLAP
Reports в 1994 году и, к законной гордости его создателей, не претерпело
изменений по сей день. Именно это определение сейчас используется
в самой широкой практике. Итак, начнем…
Fast
Этот дескриптор означает, что система должна отработать
запрос в среднем за 5 секунд. Для простых запросов этот параметр
может значить до секунды, а для редкостных по сложности запросов
показатель может достигать 20 секунд. Исследования показывают, что
если отклика не следует в течение 30 секунд, то пользователь перестает
считать систему полезной. Дальнейшей реакцией является набор сакраментальной
комбинации клавиш Alt-Ctrl-Del.
Даже будучи осведомленными о возможно продолжительном
времени обработки аналитического запроса, пользователи просто уходят
от первой мысли и обрывают обработку, от чего утрачивает качество
весь аналитический процесс.
Конечно, добиться быстрых аналитических операций на
огромных массивах данных, тем паче в режиме on fly (на лету) или
же когда того требуют нестандартные аналитические схемы (ad hoc),
не так-то просто. Разработчики систем OLAP пытаются ускорить их
действие разного рода методами, например непрерывной динамической
предобработкой данных в базе или же созданием специальных программно-аппаратных
конструкций, но поскольку предметные области приложений OLAP очень
разнородны, все это кажется делом лишь начальных исследований.
Вообще, именно критерий скорости является наиболее
критическим в определении принадлежности программного изделия к
классу OLAP.
Analysis
Это свойство программного решения означает способность
справиться с любой логикой науки или бизнеса, способность, отвечающую
как прикладной области, так и запросам пользователя. Принципиально
необходимо, чтобы система предоставляла пользователю возможности
задания всех вычислений ad hoc, входящих в состав конкретной аналитической
процедуры. Не менее важным качеством является гибкость системы в
выдаче графических результатов анализа.
Не стоит обсуждать здесь такие аспекты: делается ли
анализ оригинальными встроенными движками самого продукта, либо
подключенными движками других производителей, — достаточно того,
чтобы пользователь был удовлетворен. Среди свойств аналитической
машины могут (и должны) присутствовать такие полезности, как анализ
последовательностей временных срезов, распределения ресурсов, транзакций,
поиск целей, структурных изменений, неформальное моделирование на
образах данных, сигнализация об отклонениях от нормативного пространства
и т. п.
Shared
Требование совместного использования баз многомерных
данных означает наличие механизмов конфиденциального использования
информации. В случае необходимости множественного доступа к записи
и модификации данных должна присутствовать система авторизации этих
действий на должном уровне менеджмента.
Кстати, отсутствие такого рода механизмов является
существенным упущением большинства существующих систем OLAP: предполагается,
что эти системы работают в простейшем режиме «только чтение». Даже
многопользовательские системы с возможностями «чтение-запись» (как,
например, Microsoft OLAP Services), далеко не всегда проявляют нужную
гибкость.
Multidimentional
Лаконичный термин «многомерные массивы данных» является
богатым синонимом всему, что касается OLAP. Это квинтэссенция всего
подхода — представлять данные как многомерные структуры. Исходя
из этого основополагающего начала, все системы OLAP должны обладать
способностями работы в многомерных пространствах, включая оперирование
на развитых иерархиях. Определение этого дескриптора вовсе не говорит
о конкретных размерностях пространств данных и размерах каждого
из измерений. Это аспекты частных реализаций.
Information
Это все об источниках данных и самих данных, которые
подлежат обработке методами OLAP. Важно понимать, что методы OLAP
пытаются решить задачу обнаружения направленного, имеющего ценность
контента — а не просто объемов информации, измеряемых терабайтами.
Способности разного рода систем
OLAP к обработке информации разнятся в три десятичных порядка, то
есть в тысячи раз. И в этом аспекте возникают размышления о совершенно
разных потребностях систем в объемах оперативной и постоянной памяти,
производительности вычислительных средств, их интегрированности
в комплексы, с хранилищами данных, с другими аналитическими компонентами.
(Продолжение следует)
* Я сам был участником попыток адаптации замечательного
языка APL на ЭВМ ЕС, которые по причинам уже тогдашней, конца 70-х
годов, нашей технической нищеты не могли дать даже надежд на успех.
** ROLAP — Relational Online Analytical Processing.
Форма OLAP для динамического многомерного анализа данных, представленных
в реляционных базах (в отличие от представлений в многомерных базах).
ROLAP требует существенно больших вычислительных ресурсов по сравнению
с традиционными OLAP. Одновременно ROLAP, по самому свойству реляционных
баз данных, способен дать значительно большую функциональную гибкость,
что позволяет обслуживать большие группы пользователей и расширить
численность подключенных подразделений.
*** Alter, S. «A Study of Computer Aided Decision
Making in Organizations», Ph. D. dissertation, M.I.T., 1975.
**** Keen, P. G. W. and M. S. Scott Morton, Decision
Support Systems: An Organizational Perspective. Reading, MA. — Addison-Wesley,
Inc., 1978.
***** Bonczek, R. H., C. W. Holsapple, and A. Whinston.
Foundations of Decision Support Systems. Academic Press, 1981.
****** Sprague, R. H. and E. D. Carlson. Building
Effective Decision Support Systems. Englewood Cliffs, N.J. — Prentice-Hall,
Inc., 1982.
******* Dhar, V. & Stein, R., Intelligent Decision
Support Methods: The Science of Knowledge. Upper Saddle River, NJ.
— Prentice-Hall, 1997.
******** В конце концов оказавшаяся в разжиженном
состоянии с именем Lotus Company of IBM.
|