Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
16 Январь 2007 г
Аналитическая обработка данных в онлайне. Именно так можно расшифровать и представить по-русски акроним 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 нашел реализацию в мастерских IBM1.
Сущность 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), и новая машинка типа ROLAP2.
Следующее десятилетие, 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, однако аспект оперирования с многомерными массивами данных там уже и вовсе не просматривался.
Знаменитая своей бурной историей компания Lotus3 стала следующим игроком, попытавшемся играть на поле систем с многомерными электронными таблицами, выпустив свой пакет 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 году и, к законной гордости его создателей, не претерпело изменений по сей день. Именно это определение сейчас используется в самой широкой практике. Итак, начнем…
Этот дескриптор означает, что система должна отработать запрос в среднем за 5 секунд. Для простых запросов этот параметр может значить до секунды, а для редкостных по сложности запросов показатель может достигать 20 секунд. Исследования показывают, что если отклика не следует в течение 30 секунд, то пользователь перестает считать систему полезной. Дальнейшей реакцией является набор сакраментальной комбинации клавиш Alt-Ctrl-Del.
Даже будучи осведомленными о возможно продолжительном времени обработки аналитического запроса, пользователи просто уходят от первой мысли и обрывают обработку, от чего утрачивает качество весь аналитический процесс.
Конечно, добиться быстрых аналитических операций на огромных массивах данных, тем паче в режиме on fly (на лету) или же когда того требуют нестандартные аналитические схемы (ad hoc), не так-то просто. Разработчики систем OLAP пытаются ускорить их действие разного рода методами, например непрерывной динамической предобработкой данных в базе или же созданием специальных программно-аппаратных конструкций, но поскольку предметные области приложений OLAP очень разнородны, все это кажется делом лишь начальных исследований.
Вообще, именно критерий скорости является наиболее критическим в определении принадлежности программного изделия к классу OLAP.
Это свойство программного решения означает способность справиться с любой логикой науки или бизнеса, способность, отвечающую как прикладной области, так и запросам пользователя. Принципиально необходимо, чтобы система предоставляла пользователю возможности задания всех вычислений ad hoc, входящих в состав конкретной аналитической процедуры. Не менее важным качеством является гибкость системы в выдаче графических результатов анализа.
Не стоит обсуждать здесь такие аспекты: делается ли анализ оригинальными встроенными движками самого продукта, либо подключенными движками других производителей, — достаточно того, чтобы пользователь был удовлетворен. Среди свойств аналитической машины могут (и должны) присутствовать такие полезности, как анализ последовательностей временных срезов, распределения ресурсов, транзакций, поиск целей, структурных изменений, неформальное моделирование на образах данных, сигнализация об отклонениях от нормативного пространства и т. п.
Требование совместного использования баз многомерных данных означает наличие механизмов конфиденциального использования информации. В случае необходимости множественного доступа к записи и модификации данных должна присутствовать система авторизации этих действий на должном уровне менеджмента.
Кстати, отсутствие такого рода механизмов является существенным упущением большинства существующих систем OLAP: предполагается, что эти системы работают в простейшем режиме «только чтение». Даже многопользовательские системы с возможностями «чтение-запись» (как, например, Microsoft OLAP Services), далеко не всегда проявляют нужную гибкость.
Лаконичный термин «многомерные массивы данных» является богатым синонимом всему, что касается OLAP. Это квинтэссенция всего подхода — представлять данные как многомерные структуры. Исходя из этого основополагающего начала, все системы OLAP должны обладать способностями работы в многомерных пространствах, включая оперирование на развитых иерархиях. Определение этого дескриптора вовсе не говорит о конкретных размерностях пространств данных и размерах каждого из измерений. Это аспекты частных реализаций.
Это все об источниках данных и самих данных, которые подлежат обработке методами OLAP. Важно понимать, что методы OLAP пытаются решить задачу обнаружения направленного, имеющего ценность контента — а не просто объемов информации, измеряемых терабайтами.
Способности разного рода систем OLAP к обработке информации разнятся в три десятичных порядка, то есть в тысячи раз. И в этом аспекте возникают размышления о совершенно разных потребностях систем в объемах оперативной и постоянной памяти, производительности вычислительных средств, их интегрированности в комплексы, с хранилищами данных, с другими аналитическими компонентами.
Академические изыскания в области систем поддержки принятия решений (DSS — Decision Support Systems) прослеживаются архивами и специальными хрониками с конца 60-х годов. Развитие теории происходило с начала 70-х, а в начале 80-х появились системы поддержки финансового планирования и системы корпоративного взаимодействия (Group DSS). Все это движение впоследствии разветвилось на три направления: информационные системы для ответственных руководителей (Executive Information System), системы деловой осведомленности (Business Intelligence System) и собственно OLAP. Заключительным аккордом в середине 90-х стало выведение всей этой группы решений сначала в Интернет, потом — в корпоративные сети (intranets).
Но будем вещать по порядку… Системы поддержки принятия решений возникли в ранние годы распределенных вычислений (distributed computing). История систем такого рода началась в 1967 году, но идеи, технологии и люди к тому времени уже были в наличии.
До 1965 года конструирование больших информационных систем было делом не только технически сложным, но и чрезвычайно дорогостоящим. Появление IBM System 360 как доступного для корпоративного использования инструмента (вскоре и мэйнфреймов других производителей) привело к тому, что крупные компании смогли позволить себе обзаводиться информационными системами менеджмента (MIS — management information systems). Первые MIS обладали весьма нешироким набором сервисов: как правило, они снабжали руководителей структурированными данными о корпоративных событиях — на регулярной основе.
В конце 60-х годов два новатора, Питер Кин и Чарльз Стобель, проведшие исследования при Технологическом институте Карнеги (1950 — 1960) и Массачусетском технологическом институте (конец 60-х) дали основу модельно-ориентированным системам поддержки принятия решений.
Вообще, согласно исследованиям агентства Sprague and Watson, с начала 70-х годов пошел буквально вал публикаций по системам поддержки принятия решений. Например, известна работа Фергюсона и Джоунса, опубликованная в 1969 году, в которой обсуждаются аспекты компьютерных решений проблемы. В 1971 году была опубликована монография Майкла Скотта Мортона «Системы принятия решений: компьютерная поддержка».
Кляйн и Метли в своей работе отмечают, что история развития систем поддержки принятия решений еще ждет своих авторов. Очень вероятно то, что первые теории и практики систем DSS были заложены в составе давнейших академических исследований. В Слоуновском институте был известен проект MAC; при технической школе Така (Tuck) разрабатывалась система Dourtmouth Time Sharing System.
Во Франции в 1967 году была реализована управленческая система, работавшая в реальном времени. Это сделало учебное учреждение HEC в своем проекте SIAD ('Systemes Interactif d'Aide а la Dйcision', что по-французски означает то же самое — DSS). Интересно то, что в период с 1969 по 1974 год концепция DSS разрабатывалась в HEC независимо от того, что делалось в этом направлении в остальном мире (несколько статей профессоров из HEC описывают достижения проекта SCARABEE, который охватил именно указанные годы).
В 1975 году была опубликована докторская диссертация исследователя из МИТ Стивена Ольтера, озаглавленная «Системы поддержки принятия решений: современная практика и грядущие проблемы»4, которая позволила раздвинуть границы понимания предмета DSS. Кроме того, в этой работе были выведены существенные дескриптивные, то есть эмпирические признаки систем DSS.
В середине 70-х годов последовали академические обсуждения концепции компьютерной поддержки принятия решений, что проявилось в ряде конференций, организованных American Institute for Decision Sciences, и в конференции Decision Support Systems, проведенной группой интересов ACM SIGBDP.
Именно академическая обстановка позволила провести неформальный обмен идеями в области DSS, а мнение таких специалистов из МИТ, как Питер Кин и Майкл Скотт Мортон, было почти непререкаемым. Изданная ими в 1978 году монография5 послужила ориентиром в последующих изысканиях в области анализа, проектирования, оценок и разработок систем класса DSS.
В 1979 году Джон Рокарт, работавший в Школе бизнеса при Гарвардском университете, опубликовал статью, ставшую основополагающей для выделения из DSS такого класса систем, как EIS (executive information system), иначе — ESS (executive support system).
В 1981 году Бончек, Холсэппл и Уинстон6 заявили о теоретической модели, предназначенной для конструирования знание-ориентированных систем DSS. Речь там шла о том, как методы искусственного интеллекта и технологий экспертных систем можно эффективно прилагать к созданию DSS.
Немаловажным событием стала публикация в 1982 году книги Ральфа Спрейга и Эрика Карлсона «Построение эффективных систем поддержки принятия решений»7. Она просто конкретно ответила на вопросы: что такое эти системы, зачем и когда они нужны, как их строить.
Нужно сказать, что именно конец 70-х был ознаменован созданием интерактивных компьютерных систем, способных решать слабоструктурированные информационные вопросы. И все это называлось DSS, хотя, по серьезному разбору, эти системы представляли обширное видовое многообразие.
Хранилища данных (data warehouses) и методы онлайнового аналитического процессинга возникли практически одновременно в начале 90-х годов прошлого века8.
В начале 90-х произошел серьезный сдвиг в технологиях DSS — корпорации от мэйнфреймов перешли к массовому использованию персональных компьютеров. Радикально изменилась и системная архитектура: вместо терминалов, завязанных на общий мэйнфрейм, появились системы типа «клиент-сервер». В 1992—1993 годах некоторые из поставщиков программных продуктов начали продвигать на рынок объектно-ориентированные решения, основанные на «повторно-используемых» модулях.
С 1994 года многие компании начали переоснащение своих корпоративных сетей и информационных хранилищ. Именно в те годы многие из разработчиков систем управления базами данных поняли, что инструментарий OLAP вовсе не тождественен общим решениям DSS, и начали давать свои варианты OLAP как компонентов в составе базовых продуктов.
Итак, что же мы имеем с OLAP на сей день?