OLAP. Часть II.
Разведка на местности
Там их было всех сортов,
Всех размеров, всех цветов…
А. С. Пушкин, «Царь Никита и сорок
его дочерей»
Среди прочих информационно-технологических изысков
OLAP представляет собой нечто, имеющее глубокие корни, а потому
— накопленную историю, которая, естественно, не вкладывается в скупые
строки журнала.
Тем не менее, поскольку история поучительна, и, как
она была бегло изложена в прежнем выпуске нашего журнала, нынешний
охват местности OLAP просто неизбежен. По возможности постараюсь
избегать разного рода строчек кодов, изображений с экрана и прочей
ерунды, которая не столько объясняет, сколько вносит ряби в страницы…
Гиперкубы, мультикубы
Есть множество логических путей для структурирования
многомерных данных и, конечно же, ни один из них не является совершенным.
Тем не менее, инструменты OLAP становятся все более изощренными,
в своем бесконечном стремлении к этому совершенству.
Простейшим взглядом на многомерные данные является
их представление в декартовой системе координат, число которых и
определяется размерностью приложения данных. Можно говорить о пространстве
данных, подчеркивая таким образом их скорее логическую, нежели
физическую сущность. Реализация OLAP в таком чистом пространственном
представлении — это и есть самая основа всех прочих технологических
измышлений.
На самом деле многомерные массивы данных всегда неплотны:
зачастую ячейки данных не определены на некоторых интервалах измерений.
И наоборот: в некоторых зонах многомерного пространства, например,
соответствующих во времени повышенной деловой активности, образуются
кластеры и уплотнения.
Разработчики систем OLAP, естественно, стараются учитывать
такие объективные особенности естественных процессов — технологически
учесть неплотно заполненные и кластеризованные пространства данных.
Известны два принципиальных подхода к представлению многомерных
данных: гиперкубы и мультикубы. Каждый из подходов — это не только
способ видения данных, но и способ и качество их обработки, в частности,
эффективность процесса обработки. Рассмотрим каждый из подходов
более подробно.
Гиперкубы
Некоторые, даже из больших систем OLAP, в основе представлены
простыми единичными многомерными кубами, несмотря на то, что в нижележащих
слоях могут действовать другие модели, предназначенные для эффективного
сжатия и хранения неплотных кластеризованных данных. Для таких систем
характерна способность прямого ввода значений для любых комбинаций
ячеек по любому из измерений — все элементы пространства данных
имеют одну и ту же размерность.
Согласно подходу, который проповедует Найджел Пендс,
ведущий автор сайта The OLAP Report, описанная только что структура
и называется гиперкубом (многомерным кубом) — вне каких-либо
предположений относительно количества или свойств измерений. Термин
не связан с применением каких-либо частных форматов представления
значений. Он может быть применен по отношению как к многомерным,
так и к реляционным OLAP. Поставщики и сторонники решений OLAP на
основе гиперкубов подчеркивают такое их преимущество, как простота
приложений и видения данных для конечного пользователя.
Примером современной системы на основе гиперкубов
является Essbase. Не удивительно, что Comshare решилась работать
совместно с Arbor в решении Essbase: сама она еще с 1981 года применяла
именно этот подход в нескольких поколениях менее замысловатых OLAP-систем,
восходящих к System W.
С другой стороны, компания Thorn-EMI Computer Software,
из которой вышли основатели Arbor, сама применяла подход на основе
гиперкубов в своем изделии FCS-Multi. Таким образом, можно считать,
что Essbase является логически (не технически) потомком System W
в третьем поколении.
Гиперкубы являются основой многих несложных решений
OLAP, в частности, приложений реляционных OLAP, которые используют
главную схему с единичной таблицей: эта таблица проявляется внешне
для конечного пользователя как гиперкуб. На самом деле, к единичным
гиперкубам в то или иное время обращались многие разработчики OLAP.
Среди их решений такие, как уже упомянутая система Hyperion Essbase
(а следовательно, и FlintFox Analyzer, и Comshare Decision), Temtec
Executive Viewer, SAS CFO Vision, Hummingbird Software BI/Analyze,
Cognos PowerPlay и др.
Известна разновидность подхода — обрамленный гиперкуб
(fringed hypercube). Основу здесь представляет плотный маломерный
гиперкуб, к частичным структурам которого могут быть пристыкованы
дополнительные измерения. Среди примеров реализаций на основе этого
видения — изделия Hyperion Enterprise, Cartesis CLIME, Comshare
FDC.
Мультикубы
Другим, более распространенным, является подход, известный
как мультикуб. В решениях OLAP, построенных на такой основе,
разработчик приложений сегментирует исходную базу данных в набор
многомерных структур, каждая из которых представлена в некотором
множестве измерений из их общего для базы данных числа.
Такие небольшие многомерные структуры для общности
можно называть подкубами (subcubes), поскольку их названия
различны почти в каждой из разработок OLAP: например, в Oracle Express,
Pilot и Lucent Technology Acumate это переменные, у Holos
Crystal Analysis — структуры, у Applix iTM1 и Microsoft OLAP
Services — кубы, у Speedware Media — индикаторы.
Примерами такого рода структур могут быть наборы переменных,
например, учетные записи, представленные в том наборе измерений,
которым ограничена полная характеристика.
Поставщики и сторонники систем, построенных на основе
мультикубов, подчеркивают их главные достоинства: высокая степень
гибкости в прикладных аспектах и потенциально высокая эффективность
обработки данных. Интересно, что апологеты этого подхода категорически
не желают признавать подход на основе гиперкубов как некий частный
(возможно, вырожденный) случай их концепции. Вообще говоря, такой
ригоризм не имеет оснований, поскольку решения на основе гиперкубов
тоже проводят структурирование массивов данных на подкубы, однако
делают это подспудно, вне внимания и видения конечного пользователя,
тем самым облегчая ему работу.
Обычно принято считать систему Express первым решением
на основе мультикубов, что относит происхождение подхода более чем
на десять лет назад. При желании можно усматривать происхождение
понятия мультикубов гораздо раньше — именно такой подход был выражен
в языке APL, знаменитом произведении Кена Айверсона, опубликованном
еще в 1962 году.
Решения типа ROLAP тоже могут базироваться на мультикубическом
подходе — коль они способны оперировать с множеством таблиц, каждая
из которых представляет свое множество измерений. Такими способностями
обладают достаточно развитые системы ROLAP, среди которых известны
решения от Computer Associates, IBM, MicroStrategy.
Можно различать два типа мультикубов: блочные (block)
и серийные (serial). Структуры первого типа применяются в системах
Business Objects, Gentia, Holos, Microsoft Analysis Services, Applix
iTM1, второго типа — в Lucent Technologies Acumate, Oracle Express,
Media, Pilot.
В блочных мультикубах пространство измерений ортогонально,
а потому на уровне данных нет дополнительных измерений. Куб может
быть задан в любом числе измерений, и разницы между тем, что представляют
такие измерения, например время, вовсе нет. В серийных мультикубах
каждая переменная трактуется как отдельный куб, со своим отдельным
набором измерений — зачастую как элемент во временной последовательности.
Отмеченные особенности достаточно тонки, а потому
иногда трудно отнести систему к типу используемых мультикубов —
блочных или серийных.
Блочные мультикубы считаются более гибким видом структур,
потому как они не дают ассоциаций о природе измерений и позволяют
оперировать с данными в униформальной манере. Однако иногда они
не столь удобны для формирования отчетов, поскольку многомерные
визуализаторы за один раз способны представить единственный блок.
Этой проблемы не наблюдается в системах с серийными кубами.
Есть решение этой проблемы, основанное на объединении
блочных кубов в единые структуры, которые таковыми видны лишь конечному
пользователю (на деле оставаясь физически и логически в разных блочных
кубах). Такой подход применен в системах Microsoft Analysis Services,
Gentia, и, в частности, в Crystal Analysis Holos, в которой возможен
«обзоры обзоров» (views of views), что является весьма уникальным
решением.
Что же лучше? Гиперкубы или мультикубы? На детский
вопрос «кто победит — кит или слон?» ответа не найти. Известны эффективные
решения на каждой из основ. Но в общем случае нужно заметить то,
что уже звучало: гиперкубы обеспечивают простоту оперирования и
восприятия, а мультикубы — гибкость и эффективность.
О видовом многообразии
Немало недоразумений, некоторые из которых провоцированы
целенаправленно, связано с архитектурными и функциональными особенностями
конкретных решений OLAP. В источниках и технической документации
можно обнаружить всевозможные порождения вроде ROLAP, HOLAP, MOLAP,
DOLAP… Но и этим дело не кончается: каждому из этих милых словечек
в разных источниках придаются разные дефиниции.
На самом деле существуют разные возможности и механизмы
(опции) хранения и обработки данных в системах OLAP. Любой из поставщиков
решений применяет некоторое подмножество из возможных опций, после
чего начинается маркетинговая кампания: «только наша архитектура
несет смысл и пользу». Последнее, конечно же, лишено всякого смысла.
Лишь несколько продуктов OLAP обладают возможностью работать в разных
модальностях. И не случайно, что поставщики именно этих решений
ведут себя гораздо более сдержанно на полях выкриков для публики.
Несмотря на наличие множества тонких особенностей
и оттенков в разного рода реализациях OLAP, в принципе, есть лишь
три способа хранить данные и три подхода к обработке многомерных
данных. То есть возможны девять базовых архитектур OLAP, из которых
имеют практический смысл только шесть.
Инсценировка данных
Источниками большей части данных, поступающих в OLAP,
являются другие информационные системы. Однако в некоторых приложениях,
например в планировании, инвестировании, бюджетировании и т. п.,
бывает целесообразно хранить данные непосредственно при системе
OLAP.
Когда данные исходят от других приложений, часто бывает
нужно дополнительное пространство памяти, в котором эти данные будут
дублироваться и становиться доступными для непосредственного оперирования
OLAP. Обычно такую дополнительную память называют хранилищем данных
(data warehouses). Зачем вообще нужно подобное дублирование данных?
Тому есть причины…
Производительность. Приложения OLAP
обычно весьма громоздки, и, одновременно, интерактивные процедуры
анализа чрезвычайно вариабельны и непредсказуемы. А поэтому требуется,
чтобы доступ к данным был оперативен, что и требует их хранения
в обособленной оптимизированной структуре, гарантирующей развязку
с данными в источниках — для их безопасности.
Множественность источников. Большинство
приложений OLAP питаются данными из нескольких разнородных источников,
включая, возможно, внешние данные из Интернета, данные от прикладных
задач, от корпоративных систем и т. д. Процесс слияния этих данных
в единый конгломерат может быть очень сложным: данные представлены
в разных кодах и форматах, имеют различную временную периодичность
поставки, различный уровень доступности и т. п. Примером тому может
быть международная корпорация, в национальных подразделениях которой
используются совершенно разные формы для работы с поставщиками и
заказчиками, разные формы бухгалтерской отчетности, разные системы
ERP. Это особенно характерно, если подразделение возникло как приобретенная
национальная компания, которая сохранила все особенности унаследованных
информационных ресурсов.
Очистка данных. Плачевным, но общим
для корпоративных информационных систем свойством является наличие
большого числа ошибочных данных, которые необходимо «вычистить»,
прежде чем они станут подходящими для анализа. Речь идет не столько
об ошибках в кодировке данных, сколько о таких явлениях, как незаполненные
поля или же противоречия данных в разных источниках. Например, многие
компании привыкли анализировать свою деятельность в терминах вертикальных
рынков своих клиентов. Это означает, что каждому покупателю (даже
каждой сделке) должен быть присвоен некоторый промышленный код,
что требует некоторых усилий, отдача от которых вовсе не ощутима.
Понятно, что указывать такой код вовсе никому не хочется… Более
того, вполне возможны умышленные искажения данных, в случаях, когда
кому-то одни деловые акции кажутся более выгодными, чем другие.
Согласование данных. Есть немало причин
для того, чтобы согласовывать данные до их обработки OLAP. Важно,
чтобы это происходило без влияния на внешние транзакционные системы,
а потому хранилище данных должно быть выделено. Вот некоторые причины
необходимости согласования данных:
- национальные подразделения компании могут работать
в разных системах отчетности, отличаться датами и периодичностью
отчетности;
- управленческие, операционные и правовые аспекты
деятельности компании могут покоиться на различных информационных
структурах;
- межкорпоративные деловые транзакции могут выполняться
в совершенно различных формах, что требует приведения их к единому
знаменателю;
- некоторые данные (особенно обобщенные) могут требовать
сокрытия или изменения по причине их конфиденциальности;
- исходные данные могут содержать поля, не подлежащие
операционной обработке и требующие (в конкретном случае) удаления
(например, сведения о регионе проведения рекламной акции, демографические
характеристики потребителей и пр.).
Фактор времени. Очень вероятно, что
данные, поступающие из разных источников, обновляются по несовпадающим
временным циклам. Скажем, цикл обновления может быть еженедельным,
в другом случае — ежемесячным, в одном месте итог подводится в последний
день месяца, в другом — в первый день месяца и т. д. А потому нужно
приводить данные к профилю на текущем моменте.
История. Большинство приложений OLAP
рассматривают время как одно из главных измерений, которое позволяет
получать ценные результаты из анализа последовательностей событий.
Для того чтобы это работало, следовало бы хранить данные многолетних
наблюдений, чего, очень вероятно, не заложено в способностях операционных
систем.
Аннотирование. Операционные, по сути,
фактографические, данные поневоле очень детализированы, а принятие
решений осуществляется на основе гораздо более абстрактной информации.
В интересах эффективности процесса принятия решений разумно объединять
и согласовывать данные, переводя их на более высокий уровень обобщения.
Естественно, проводить такие операции непосредственно в рабочих
системах просто невозможно.
Модификации данных. Если OLAP-приложение
допускает ввод или изменение данных, то эти операции никоим образом
не должны затрагивать оригинальные исходные данные в рабочих системах.
Хранение активных данных
Обоснованная необходимость хранения активных OLAP-данных,
в эффективной конгломерированной форме отражающих исходные данные,
заставляет задуматься о способе и структуре их представления. В
общем случае можно рассматривать три опции, хотя иногда границы
между ними размыты, а иногда решение предусматривает не единственную
организацию хранилища. Следует обратить внимание, что сам термин
«хранение» в настоящем контексте обозначает некоторую продолжительность
существования данных в относительно стабильной форме, скажем, в
течение сеанса работы пользователя или же рабочего дня группы пользователей,
а не просто для ничтожного периода времени, потребного для отработки
единичного аналитического запроса. Итак…
Реляционная база данных. Этот выбор
очевиден, в частности, тогда, когда источниками или хранилищами
данных являются реляционные базы, или же файловые системы операционных
и транзакционных компонентов имеют реляционное устройство. В большинстве
случаев данные хранятся в ненормализованном представлении — в виде
лучевых структур (звезды, снежинки) по причине производительности
и эффективности обработки данных. Обобщенные (аннотированные) данные
могут храниться в агрегированных таблицах.
Многомерная база данных. В этом случае
активные данные хранятся в многомерной базе на сервере OLAP. В их
составе могут быть данные из унаследованных систем, из реляционных
баз данных, данных, введенных пользователями. Чаще всего такого
рода база данных располагается на дисках, но случаются реализации
в оперативной памяти (RAM), обеспечивающие повышенную производительность.
Обычно возможна (иногда — обязательна) предобработка (precomputing)
агрегированных данных и сохранение результатов в форме некоторого
многомерного массива. В некоторых случаях возможны параллельные
операции чтения-записи, одновременно доступные многим пользователям.
Но это исключения: обычно поддерживается режим «single-write/multi-read»
или вообще «только чтение».
Файлы клиентов. Относительно небольшие
фрагменты активных данных могут храниться непосредственно в клиентских
компьютерах. Они рассылаются по требованию системы OLAP, могут быть
созданы и организованы по запросам (возможно, через Web). Точно
так же как в случае с многомерными базами, данные на компьютерах
клиентов могут храниться на дисках либо в оперативной памяти.
Обработка данных
В общем-то, как это сейчас станет понятно, обработка
многомерных данных вовсе не обязательно выполняется там же, где
эти данные хранятся.
SQL. Это далеко не очевидный подход
к исполнению сложных многомерных процедур, даже если данные хранятся
в реляционной базе. В SQL нет прямых возможностей для задания многомерных
вычислений в единственном операторе, а потому требуются циклические
исполнения сложных запросов — для выполнения весьма тривиальных
процедур. Тем не менее, это не останавливает разработчиков: они
пытаются пристроить SQL хотя бы для исполнения подготовительных
этапов поиска и извлечения данных, которые затем передаются машине
многомерных вычислений.
Многомерная серверная машина. Такое
решение самое очевидное и популярное для OLAP-приложений, работающих
по схеме «клиент-сервер». В этом случае производительность на вполне
удовлетворительном уровне, поскольку объемы памяти велики, а потому
база данных и машина обработки данных могут быть согласованны и
оптимизированы.
Многомерная клиентская машина. Исходя
из того, что клиентские компьютеры становятся все более мощными,
большинство поставщиков решений OLAP старается переместить на эти
компьютеры какую-то, если не большую, часть многомерной обработки
данных. Ну, а коль доступ к OLAP осуществляется через Web, то такое
решение выглядит просто естественным.
Вскрытие показало…
По итогам 2001 года объем рынка OLAP достиг примерно
3,3 млрд. долларов. Что характерно для этого рынка, на нем присутствуют
более 30 поставщиков решений, и не отмечено какого-либо явного доминирования
даже таких тяжеловесов, как Microsoft или Oracle.
Несмотря на то, что история OLAP насчитывает более
30 лет, еще сравнительно недавно не было опубликовано сколько-нибудь
полных обзоров состояния рынка этих систем. И только осенью прошлого
года появился отчет, выполненный исследовательской организацией
Survey.com, в котором с достаточной полнотой было раскрыто положение
дел на рынке и в практике использования OLAP*.
Как показало исследование, внедрение систем OLAP в
подавляющем большинстве случаев (85%) оценивается как успех (хотя
40% опрошенных назвали фактор цены «отпугивающим»), и почти все
из них планируют развивать OLAP и приобретать более современные
решения.
Высок и уровень удовлетворенности тех, кто использует
OLAP — более 70% респондентов сообщили, что их проекты были успешно
завершены и достигли целей, поставленных деловой практикой. Лишь
3% ответов свидетельствовали о том, что цели внедрения OLAP достигнуты
не были.
Интересным открытием стал тот факт, что удовлетворенность
пользователя существенно зависит от того, решение какого поставщика
используется. Например, лишь 43% клиентов изделия Seagate Info выразили
удовлетворенность в достижении ранее поставленных целей. Как противоположность,
более 80% опрошенных выражали удовлетворение, когда они являлись
счастливыми пользователями решений Oracle Express, MicroStrategy
или Applix iTM1.
Здесь будет уместно циничное, но не лишенное оснований
замечание. Все эти приведенные цифры, возможно, ничего не значат.
Дело в том, что, несмотря на высокий уровень удовлетворенности нынешними
решениями, 40% опрошенных сообщили, что ранее они отказывались от
предыдущих решений. В случаях с несколькими хорошо известными
изделиями уровень отторжения достигал 56%.
Вспомним хорошо известное правило внедрения информационных
систем: главные проблемы кроются не в технологии, а в организации.
На самом деле покрытые шрамами бизнес-сражений ветераны могут удивляться,
но 33% всех опрошенных объявили, что одной из трех главных проблем
внедрения OLAP была внутренняя корпоративная политика. Как и следовало
ожидать, 32% ответов гласили о недостаточном качестве данных. Следующей
по количеству откликов (24%) была проблема «цели изменились до окончания
проекта [внедрения OLAP]».
Высоко отмечались технические качества самих систем
OLAP: чуть больше половины опрошенных относили проблемы такого рода
к трем главным (если возникала хоть одна). И, напротив: на каждого
опрошенного было отмечено 1,4 проблемы нетехнического характера,
например, плохое администрирование, невозможность согласования условий
проекта, отсутствие профессиональной подготовки персонала и т. д.
Наконец, 20% счастливчиков проблем вообще не наблюдали.
Среди технических неурядиц с внедрением OLAP наиболее
заметной является низкая производительность отработки запросов —
почти каждый шестой из опрошенных считал это явление главной проблемой.
В зависимости от конкретного решения негативные отклики на этот
фактор варьировались в пять раз (!) — от лучших решений до худших.
Больше всего проблем этого рода возникало у пользователей настольных
решений и ROLAP, а серверные решения здесь показали себя в лучшем
свете.
Возможно, покажется странным, но аспект надежности
программных средств OLAP почти не вызвал нареканий: только 5,6%
опрошенных назвали его среди главных проблем. Даже среди тех, кто
назвал этот аспект проблемным, лишь 7% заявили о том, что их не
удовлетворяет решение в целом.
Не является ли само отсутствие технических проблем
подсознательным стимулом для иррациональной расточительности при
покупках и внедрениях систем OLAP? А ведь неумеренный пыл покупателей
и внедренцев к наращиванию мощности и многообразия систем является
серьезной проблемой. Как оказалось, остаются лежать неиспользованными
на полках (shelfware) в компаниях в среднем 39% пакетов десяти самых
популярных решений OLAP! Другими словами, из каждых пяти лицензированных
пакетов три работают, а два — отдыхают!
Наибольшими энтузиастами покупать «впрок» считаются
любители систем Cognos PowerPlay — в их среде доля «пакетов на полках»
достигает до 62% от всех лицензированных изделий! В противоположность
этому примеру, у покупателей Hyperion Essbase на полках лежат лишь
15% благоприобретенных пакетов.
Несмотря на то, что горы коробок с неиспользуемыми
программами OLAP растут, те, кто хоть раз клевал на эти приманки,
оказались на крючке: 54% опрошенных сказали, что собираются делать
закупки систем и дальше, лишь 12% сообщили, что им вполне довольно
того, что имеется.
Выявлены существенные различия в эффективности маркетинга
и продаж разных изделий OLAP. Например, Hyperion Essbase является
изделием, которое лидирует по относительному количеству оценочных
установок — только 46% из тех, кто испытал изделие, решили купить
его. А вот среди реальных покупок и постоянных установок первенство
держит Microsoft OLAP — 80% из тех, кто присматривался к этому решению,
сделали свой следующий шаг. Курьезным фактом является то, что один
из клонов Embasse, изделие IBM DB2 OLAP Server, вызывает решимость
к приобретению лишь у 24% тех, кто оценивал это решение в среде
самой DB2.
В отличие от клиентов IBM, у потребителей изделий
Oracle весьма высокий уровень лояльности не только к решениям OLAP,
но и к субкультуре компании вообще. Они не только склонны к приобретениям
продукции Oracle, например Express или Discoverer, у них совершенно
отличная манера поведения в других аспектах:
- только 47 процентов установок Express базируется
на платформах Windows NT/2000 — по сравнению с 76% в случаях использования
OLAP-решений, происхождения иного, чем от Oracle;
- 40% установок изделий Oracle до сих пор используют
для работы в Web-браузеры Netscape — по сравнению с 14% в среде
решений других поставщиков;
- только 20% установок Express используют Excel в
качестве фронтально-терминального (front-end) интерфейса — по
сравнению с 70% установок от иных поставщиков.
Вообще, субкультура Oracle серьезно смещена в сторону
Java для работы с Web и склонна к использованию компьютеров, не
ориентированных на операционные системы Windows.
Что касается положения Microsoft, то нужно признать,
что ей удалось отхватить изрядный кусок пирога OLAP. У системы Microsoft
OLAP, выпущенной в начале 1999 года, сейчас больше пользователей,
чем у какой-либо другой системы OLAP на рынке вообще. Характерным
признаком является высокий процент предпочтения этого решения после
его первичной оценки (большинство испытателей после первичной оценки
даже не пытаются проверять решения других поставщиков).
А вообще, главным фактором выбора Microsoft OLAP для
клиента являются вовсе не ожидания высоких технических свойств,
а невысокая цена изделия. Тем не менее, пользователи Microsoft OLAP,
так же как и пользователи решений Oracle, не имеют особых претензий
к эффективности и производительности обработки данных. Типичная
база данных, с которой работает Microsoft OLAP, весьма скромна по
размерам. Но показательно то, что число пользователей, работающих
с очень большими базами посредством Microsoft OLAP, превосходит
число тех, кто работает с объектами примерных размеров посредством
Essbase или Express!
Учитывая более чем невысокую репутацию Microsoft как
производителя надежных программных продуктов, примечательно то,
что у пользователей OLAP особых нареканий в этом аспекте не возникает
— по сравнению с откликами пользователей других решений. Какие бы
ни были причины тому, но факт остается фактом: те, кто использует
Microsoft OLAP, отмечают меньше технических проблем, чем пользователи
какого-либо другого изделия. Это обстоятельство, в сочетании с невысокой
ценой, делает пользователей Microsoft OLAP наиболее лояльными к
своему выбору — среди всех пользователей систем OLAP.
В течение нескольких лет многие аналитики были уверены
в том, что приложения OLAP мигрируют в сторону использования через
web-браузеры. Однако на самом деле это далеко не так. Оказывается,
только 18% всех приложений используют исключительно технологии Web
для доступа к OLAP. 28% опрошенных сообщили о том, что они вообще
не рассматривают Web как среду для работы с OLAP. Медиана использования
Web при доступе к OLAP располагается на уровне 40%.
Наиболее привязаны к технологиям Web решения, предлагаемые
MicroStrategy, в наименьшей мере — решение Applix, поставляемое
iTM1. В этом нет ничего удивительного, поскольку ситуация полностью
отвечает многолетним стратегиям каждой из компаний. Незначительное
применение технологий Web отмечено также в решениях Seagate Info
и Hyperion Essbase. Нужно отметить сильную зависимость применимости
технологий Web при доступе к OLAP от географии региона. Поскольку
в составе респондентов преобладали представители компаний США, нужно
полагать, что общие результаты использования Web следует считать
завышенными для глобальной картины.
Показательны данные, полученные при выяснении предпочтений
пользователями OLAP конкретных механизмов реализации доступа через
Web, то есть технологических решений более глубинного уровня — Java,
ActiveX, DHTML, XML и т. д.
Оказалось, что у трети опрошенных особых-то предпочтений
нет вообще. Эта группа по численности намного опережает ту, в которой
были высказаны твердые предпочтения. Наиболее популярной оказалась
технология Java, но этот показатель во многом объясняется уверенными
предпочтениями пользователей решений Oracle. К сторонникам использования
Java можно отнести и клиентов решений Business Objects.
В остальном — полный разнобой. Например, пользователи
систем Brio обеспечены уникальными решениями поставщика, которые
можно характеризовать как подключаемые (plug-in) модули. Клиенты
Cognos PowerPlay работают на основе чистого HTML. Кое-кто предпочитает
ActiveX. А вообще, как и следовало ожидать, пользователи предпочитают
не вникать во внутреннюю механику решений и берут то, что предлагают
поставщики.
Странным открытием стало то, что только несколько
опрошенных сообщили о том, что предпочитают XML или XSL, и никто
даже не упомянул о DHTML как о востребованной технологии. И это
несмотря на то, что последние перечисленные технологии в настоящее
время рассматриваются как наиболее перспективные большинством разработчиков
OLAP.
При сохранении общей тенденции движения к технологиям
Web, этот процесс оказался куда менее стремительным, чем еще недавно
предсказывали аналитики рынков OLAP.
Общая же картина такова, что большинство пользователей
OLAP вполне удовлетворено своим выбором конкретных решений (см. табл. 2). Одновременно заметно, что
многие звезды, ярко сиявшие в былые годы, потускнели. К таковым
можно отнести известные изделия таких разработчиков, как Gentia,
Holos, SAP, SAS Institute.
Волюнтаристски завершая затянувшуюся повесть, которой
и конца нет, могу сказать одно: OLAP — это о том, как с удовольствием
для себя рассматривать и понимать весьма сложные массивы
и процессы на разнородных данных, для того чтобы делать из
этих зрелищ самостоятельные выводы. Список главных продуктов на
рынке и их поставщиков приведен в таблице 3.
Уместно сообщить, что на наших просторах популяризацией
идей и самой науки OLAP занимается компания «Интерфейс» (www.olap.ru).
* Pendse, Nigel. The OLAP Survey. — Survey.com, San
Jose, CA, 2001. В исследовании были опрошены более 650 респондентов
из 45 стран. На США пришлись 72% всех опрошенных, на Европу — 21%,
остальной мир — 7%.
Советы потребителю решений OLAP
- не следует жадничать и тотально скупать пакеты OLAP — в среднем
каждая компания в США (вообще использующая инструменты такого
рода) уже накупила решений OLAP столько, что 64% из них остаются
неиспользованными
- самые совершенные и сложные решения OLAP порождают проблем гораздо
больше, чем их недорогие и не столь изысканные аналоги
- услуги консультантов от поставщиков и специалистов из компаний
по решению проблем информационных технологий обойдутся недорого,
но будут куда полезнее, чем словоблудие алчных парней из универсальных
фирм высокого полета вроде тех, которые еще недавно были известны
как «Big Five» (и куда это подевалась Arthur Andersen?)
- всегда нужно проверить и испытать решение и изделие — до того
как его приобрести; иначе уровень лояльности к решению останется
тем же, который был до покупки
- при воплощении проектов OLAP лучше держаться подальше от администраторов
— их вредоносность для дела куда выше, нежели любые технические
огрехи
|
