Доступ к аналитике: новые интерфейсы для OLAP

Исторически сложилось так, что извлечение данных (data mining) и онлайновая аналитическая обработка информации (OLAP) были исключительно прерогативой человека, т. е. именно люди определяли и создавали аналитические модели, а затем использовали полученные с их помощью результаты. Но с появлением вычислительной модели Web-служб, которые рассматриваются как универсальное средство объединения разнородных систем, картина существенно изменилась: аналитику теперь можно легко связать с другими вычислительными задачами (см. врезку «Уже не только для людей»). Другими словами, люди перестали быть единственными создателями или потребителями аналитических сервисов. Как вы понимаете, это открывает захватывающие возможности.

Уже не только для людей Что же такое аналитическое взаимодействие «без людей»? Возьмем, к примеру, «интеллектуального агента», обслуживающего B2B-обмен в процессе поиска партнеров по сделке. Кроме прочего, поиск предусматривает количественное определение риска — процесс, аналогичный оценке риска при выдаче кредита. Конечная задача агента — ответить на вопрос, годится ли партнер Х для включения в сделку. Агент определяет важные критерии (переменные и алгоритмы) в запросе на оценку риска. Этот запрос может включать вычисление временных рядов, ранжирование и похожую на data mining процедуру оценки неизвестных параметров партнеров, но автором и потребителем запроса является агент, а не человек. Более того, достаточно интеллектуальный агент должен обладать реальным аналитическим «мастерством»: на основании результатов одного запроса создать второй набор запросов, на основании второго — третий и т. д. Со стороны API это напоминает интерактивный сеанс, а с точки зрения пользователя — систему с собственным «интеллектом».

До недавнего времени возможности организации взаимодействия аналитических «движков» были ограничены. Разработчикам был доступен ряд созданных производителями API, а также технология Microsoft OLE DB for OLAP (или ODBO), которую помимо Microsoft поддерживали и другие серверы. Но протокол ODBO доступен только в Win32, что вряд ли могло сделать его универсальным средством доступа для Web-служб или корпоративных приложений среднего уровня. Java-версию созданного Советом по OLAP (OLAP Council) интерфейса MD-API не реализовал ни один поставщик серверных или клиентских продуктов, поэтому для серверов приложений на основе отличных от Win32 технологий мультивендорные API вообще отсутствовали.

Тем не менее появляются новые возможности. В этой статье я расскажу о двух разрабатывающихся API для доступа к OLAP-информации. Первый интерфейс называется XML for Analysis (XML/A) и уже существует в версии 1.0, а в ближайшем будущем ожидается выпуск версии 1.1. Другой интерфейс — Java OLAP Interface (JOLAP) в настоящее время проходит процесс одобрения по процедуре Java Community Process после того, как завершилась стадия открытой оценки (с 20 июня по 19 июля 2002 года).

Первое преимущество этих интерфейсов — поддержка приложений среднего уровня, созданных не на Win32, причем независимо от того, считаете ли вы такие приложения Web-службами или нет. Понятно, что оба интерфейса годятся и для других целей. Так, для клиентских приложений эти API как минимум обеспечивают доступ к ранее недоступному подмножеству серверов. Далее я расскажу, на что способны указанные интерфейсы и как различные поставщики рассматривают API в свете собственных интересов.

Подход на базе XML for Analysis

XML/A — это API, основанный на протоколе SOAP и охватывающий функции ODBO компании Microsoft. Он основан на базовых спецификациях SOAP и ODBO; кроме того, в него добавлены расширенные SOAP-операции и XML-схемы для ODBO-структур данных.

SOAP обеспечивает логический механизм для передачи клиентского запроса на сервер и выборки информации. Клиенту доступны только две SOAP-операции: Discover (для выборки метаданных) и Execute (для генерации текстов на языках DDL или DML). В провайдерах, основанных на SOAP, можно реализовать широчайший диапазон транспортных протоколов, но, вероятнее всего, большинство поставщиков XML/A-провайдеров предпочтут поддерживать HTTP. Кроме того, как и HTTP, XML/A не поддерживает состояний и характеризуется минималистским подходом к обработке сеансов.

В основе интерфейса XML/A лежит ODBO, поэтому многие OLAP-особенности этого интерфейса должны быть знакомы разработчикам, которые уже работают с ODBO. В частности, для запросов и DDL применяется тот же язык многомерного моделирования MDX, а для представления таблиц метаданных OLAP — те же обязательные структуры данных. Сам по себе XML/A располагается уровнем ниже, чем ODBO, поскольку XML-строки нуждаются в отдельном синтаксическом разборе до того, как стать структурой данных, похожей на структуру данных в ODBO. Представление DOM-объекта результата запроса или набора метаданных напоминает структуры данных ODBO. Большинство работающих с ODBO разработчиков сегодня используют библиотеку ADO MD компании Microsoft, потому что она обеспечивает более простой высокоуровневый доступ. Microsoft планирует представить версии ADO MD и для XML/A (об этом чуть ниже).

Ранее я говорил, что XML/A — это API для доступа к информации. Как и в OLE DB для OLAP, клиент может запрашивать многомерную информацию в виде набора записей реляционных данных, а также многомерных наборов клеток. Однако спецификации достаточно открыты и обеспечивают подключение других типов провайдеров и доступ к ним без нарушения нормативов.

ODBO и OLE DB for Data Mining компании Microsoft — это два отдельных API. С другой стороны, XML/A как спецификация аналитических запросов и транспортировки результатов «перекрывает» функциональные возможности обоих интерфейсов. OLE DB for Data Mining в настоящее время не является частью XML/A, но работающие над этим интерфейсом поставщики предполагают включить соответствующие функции в будущую версию. Microsoft рассматривает XML/A как обобщенный расширяемый каркас, который вполне может применяться для создания запросов и отчетов. Кроме того, ничто не мешает клиенту подключиться к реляционному провайдеру данных, направить SQL-запрос и получить в ответ набор строк. Основная идея проста — каркас позволяет осуществлять различные аналитические операции, такие, как создание отчетов на базе реляционных данных, составление ГИС-запросов или работа с оптимизационными моделями. В XML/A не определены структуры данных или типы взаимодействия, которые могут препятствовать обработке информации при помощи этого каркаса, но в настоящее время он не поддерживает такие данные в явном виде.

В XML/A версии 1.0 реализовано XML-моделирование метаданных и результатов запросов, хотя и в виде относительно простых массивов, а в качестве языка запросов определен MDX. Однако сейчас разрабатывается формат разметки MDX — он называется mdXML. На момент написания этих строк mdXML все еще не готов, но в будущем его планируется применять в качестве объектного описания MDX-запросов. Главная выгода формата разметки — в предоставлении разработчикам объектной модели для создания программных запросов и обеспечении механизма участия различных уровней ПО в аналитических запросах. Пока непонятно, обогатит ли mdXML семантику MDX в плане текстового интерфейса. Тем не менее разработчикам доступно программное управление DOM-представлениями mdXML для создания и изменения запросов, а также использование Xpath- и DOM-операций для внедрения уже имеющихся запросов и их результатов в компоненты новых запросов.

Один из источников беспокойства как для потребителей, так и для производителей — «текстуальность» XML в противовес двоичным форматам, особенно ее влияние на передачу данных. При передаче «чистого» XML сеть нагружается сильнее, чем при пересылке двоичных данных, и тому есть две причины: двоичные данные необходимо представлять в виде текста, отчего их объем обычно возрастает, кроме того, открывающие и закрывающие теги занимают существенно больший объем, чем эквивалентные им маркеры в двоичных коммуникационных протоколах. Поставщики, работающие над XML/A, планируют усовершенствовать разрабатываемые методики для общего улучшения связи с применением XML.

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

«Соль» JOLAP

JOLAP основан на Java, и потому все аспекты этого API объектно-ориентированы. В спецификации описана объектная модель для просмотра метаданных, результатов запросов и конструирования запросов. Примечательно, что не определено никакого текстового языка запросов — вместо этого в объектной модели присутствуют классы, которые можно комбинировать для определения выборки и размещения результатов.

JOLAP (Java Specification Request-69) использует и другие спецификации, такие, как спецификации группы OMG для метамодели Common Warehouse Metamodel (CWM), объектной модели Meta Object Facility (MOF), XML Metadata Interchange (XMI), а также находящийся в процессе утверждения Java Metadata Interface (JMI, JSR-40). Архитектура этого интерфейса обеспечивает совместимость с J2EE и J2SE; подсистемы подключения и обработки транзакций созданы по образцу J2EE Connector Architecture. Разработчики, уже вложившие средства в поддержку других стандартов этого класса, особенно CWM и JMI, получат выгоды от возможности расширить область применимости уже созданного кода, охватив OLAP-возможности.

JOLAP обеспечивает отчасти обогащенный механизм описания и получения метаданных. Измерения, кубы, иерархии, уровни, атрибуты и зависимости между измерениями и кубами — все они имеют вид объектов метаданных, производных от объекта корневой схемы. Объекты, которые описывают элементы, запрашиваются из измерений и их компонентов. Управление ресурсами посредством курсоров доступно во всех операциях выборки элементов, поэтому оно вполне годится для извлечения информации на уровнях с сотнями тысяч элементов. ADO MD компании Microsoft также включает объектную модель для доступа к метаданным, но модель JOLAP несколько богаче и лучше приспособлена для использования ресурсов.

Объектные модели запросов и языков критически важны для разработчиков, имеющих дело с аналитическими API. Каждое средство динамического клиента имеет определенную внутреннюю модель структурирования компонентов запроса и метаданных с тем, чтобы изменять компоненты запросов и собирать их в единое целое. В JOLAP все запросы моделируются как наборы объектов, структура которых отражает последовательность операций в графическом интерфейсе при построении и модификации запросов. Приложению не требуется никаких дополнительных операций для просмотра объектов и генерации текстовых запросов.

Объектная модель JOLAP концептуально во многом похожа на объектные модели большинства, если не всех клиентских OLAP-средств. Объектная модель напоминает обоюдоострый меч — для встраивания расширений, поддерживающих запросы, необходимо обновлять библиотеки. Однако при внесении любых расширений в базовый язык текстовых запросов потребуется изменить клиентское ПО, поэтому обновление библиотек можно считать главной составляющей синхронизации.

JOLAP обладает одной очень интересной особенностью интерактивной поддержки клиентов: транзакции на основе объектных конструкций, определяющих запросы, позволяют клиентским приложениям легко управлять модификацией и откатом частей запроса, таких, как последовательность перемещений на более низкий уровень детализации (drill-down) и изменения фильтров. Реверсия последовательности изменений и выбор более раннего состояния запроса в качестве отправной точки для нового анализа может управляться API, а не пользовательским приложением. Такой подход дает возможность уменьшить в клиентской части количество кода для управления состоянием запроса, а API-реализация может использовать свое «знание» подключения между двумя состояниями для оптимизации пересылки данных.

Вообще говоря, в каждом из API возможности создания OLAP-запросов аналогичны, и одни интерфейсы обеспечивают функции, которых у других нет. Должен признаться, что из-за недостатка времени мне не удалось достаточно детально изучить спецификации JOLAP, чтобы найти ключевые различия, так как эти спецификации были опубликованы за несколько недель до завершения данной статьи. Оба API оставляют простор для будущих усовершенствований. В частности, несмотря на коллективную разработку обоих интерфейсов, ни в одном API не определена поддержка ввода данных клиентом или отмена долго выполняющихся команд.

Сравнение подходов

Две спецификации представляют два различных технических и процедурных подхода. XML/A — это не поддерживающий состояния протокол на базе XML, служащий оболочкой ODBO. Теоретически клиент может быть очень легким, однако если требуется выполнять какие-то операции с XML-результатами, то понадобится создавать дополнительные уровни ПО. С другой стороны, JOLAP — довольно «богатый» функциями API, обладающий набором обязательных и необязательных классов. Исторически сложилось так, что JOLAP разрабатывался дольше и решает широкий круг задач, а XML/A развивается существенно быстрее, «закрывает» меньшую часть всей функциональности, но доступен для более быстрого внедрения. В то время как OLE DB for OLAP — это спецификация, разработанная компанией Microsoft, интерфейсом XML/A совместно владеют финансирующие его разработку организации, в том числе Microsoft, Hyperion Solutions и SAS Institute. В таблице перечислены наиболее заметные особенности каждого из API — как присущие им «по рождению», так и привнесенные.

Сравнительный анализ JOLAP и XML/A

В двух словах, JOLAP — довольно развитый объектно-ориентированный Java API, ориентированный на интерактивных клиентов, а XML/A — легкий интерфейс с богатой функциональностью запросов в ODBO (а вскоре и в OLE DB for Data Mining) с возможностью доступа из многих языков программирования. Производители серьезно отнеслись к этим API, а некоторые даже стараются обеспечить поддержку обоих интерфейсов. Особенно важно подчеркнуть это в отношении JOLAP в свете того, что спецификации, разрабатываемые Советом OLAP (OLAP Council) и экспертной группой JOLAP, значительно перекрываются.

Для Oracle язык Java все еще остается стратегическим. Компания давно занимается разработкой собственного OLAP API на базе Java (он называется OLAPI). OLAPI обеспечивает несколько более детализированный каркас, чем JOLAP, но, по заверениям Oracle, JOLAP удовлетворит потребности приблизительно 80% приложений, а оставшиеся 20% могут обращаться к OLAPI с применением механизма шаблонов в JOLAP. Oracle не считает перечисленные API единственными Java-интерфейсами, которые можно использовать для доступа к аналитическим функциям его программных продуктов. Недавняя интеграция аналитики Oracle в SQL-ядро означает, что если не нужна многомерность результатов запроса, можно применять JDBC.

Для Microsoft XML и SOAP очень важны как часть стратегии компании в отношении API. Microsoft уже поддерживает провайдер и комплект разработчика (SDK) для XML/A и планирует включить в библиотеку ADO MD поддержку подключений XML/A наравне с ODBO-драйверами. Компания предполагает выпустить две дополнительные версии ADO MD, которые называются ADOMD.NET и ADOMD.J и призваны обеспечить доступ к источникам данных на основе XML/A. Первая версия будет доступна из среды .NET. Удивительно, но ADOMD.J запланирована как EJB-версия ADO MD, в которой для транспортировки данных будет применяться XML/A. И ADOMD.NET, и ADOMD.J будут содержать объектную модель для конструирования запросов и метаданных, т. е. как раз то, что отсутствовало в ADO MD с самого начала (COM ADO MD не будет поддерживать подобную объектную модель запросов). Поскольку XML/A обеспечивает низкоуровневое структурирование ODBO, большинство разработчиков в среде .NET, вероятно, постараются использовать интерфейс ADO MD для упрощенного доступа.

Hyperion рассматривает эти API как нечто большее, чем просто еще одна альтернатива, о чем свидетельствует ее участие в финансировании разработки спецификаций XML/A и активная роль в работе над JOLAP. По утверждению менеджера продукта Рагнара Эдхолма (Ragnar Edholm), цель заключается в том, чтобы обеспечить максимально широкую аудиторию Essbase. Разработчики, предпочитающие более текстуальный интерфейс, могут использовать MDX с XML/A. Программисты на Java могут использовать относящиеся к XML API для доступа к XML/A из Java, однако специалисты Hyperion полагают, что серьезные разработчики на Java предпочтут «богатую» объектную модель программирования, а именно JOLAP. Естественно, что технические различия между API также окажут влияние на выбор разработчиков.

Ведущая роль Hyperion в каждой из перечисленных инициатив также заключается в обеспечении совместимости моделей: в идеале любую из них можно выразить в терминах другой. Поддержка MDX для XML/A замечательно дополняет функции Essbase, что потребовало многих усилий со стороны Hyperion, но тем не менее обеспечило расширение возможностей запросов. Такое же широкое применение MDX, как и API создания отчетов (Report API), увеличивает возможности каждого отдельного запроса.

Hyperion представил поддержку XML/A некоторым из своих клиентов и партнеров и планирует внедрить ее в следующий выпуск Essbase. Время встраивания поддержки JOLAP зависит от того, как будет проходить JCP-процесс, тем не менее компания планирует обеспечить поддержку JOLAP сразу же после завершения работы над спецификацией.

Рыночные тенденции

Чтобы интерфейсы оказались полезными, необходима их поддержка с обеих сторон. При наличии адекватной поддержки серверов разработчики корпоративных приложений смогут успешно применять оба API в приложениях среднего уровня. Производители клиентских приложений также внимательно следят за разработкой интерфейсов — все опрошенные мной поставщики говорили об одних и тех же соображениях и тревогах, в частности, о проблемах с производительностью новых интерфейсов. Многие благосклонно относятся к XML/A, говоря о возможности быстрой его реализации и «родстве» с ODBO. По словам Расса Уитни (Russ Whitney), вице-президента по разработкам и развитию компании ProClarity, его фирма «несомненно, планирует поддерживать провайдеры XML/A». Ему кажется, что при создании XML/A более тщательно отнеслись к перекрестной совместимости серверов и полной поддержке заявленных функциональных возможностей, чем при разработке OLE DB for OLAP. Естественно, тот факт, что XML/A финансируется тремя компаниями и создан механизм групповой координации, дает этому интерфейсу преимущество перед ODBO, хотя подобное первенство можно также отнести на счет большей зрелости реализации базовых ODBO-механизмов некоторыми поставщиками.

Компания Business Objects планирует поддерживать XML/A в течение 90 дней после внедрения серверного приложения в компании первого эшелона, а обеспечение поддержки JOLAP будет определяться спросом среди клиентов и появлением реализаций у поставщиков баз данных. Business Objects видит JOLAP как дополнение к уже объявленному компанией доступу средствами SQL к Oracle9iR2 OLAP. Cognos исследует возможность использования XML/A, видя в нем интерфейс к OLAP-приложениям среднего уровня и Web-службам. Компания также расценивает JOLAP как средство усовершенствованного доступа к серверам Oracle, хотя доступ к OLAP-функциям в Oracle с применением SQL-расширений также представляет интерес для Cognos. В общем, как ясно выразились директор по развитию Business Objects Нейл Томсон (Neil Thomson) и директор по разработкам и развитию Cognos Колин Моден (Colin Moden), тот факт, что за счет новых интерфейсов увеличивается общее число интерфейсов к серверным приложениям, немного усложняет принятие их независимыми поставщиками оборудования, потому что им приходится поддерживать дополнительные спецификации.

Проблема совместимости возникает для любого поддерживаемого многими вендорами API. При внедрении приходится задаваться двумя вопросами: соответствует ли спецификациям реализация поставщика А и совместимы ли реализации поставщиков А и Б. Производители, сотрудничающие с Консультативным советом по XML/A (XML/A Advisory Council), планируют провести один или несколько тестов на совместимость для устранения возможных нестыковок реализаций XML/A до развертывания реальных продуктов. JCP-процесс (Java Community Process) в качестве обязательного результата предусматривает пилотное внедрение, поэтому JOLAP «выйдет в свет» с готовым послужным списком и не станет продуктом одного поставщика.

С какой стороны ни посмотри

Кажется, оба API будут опубликованы и найдут свою область применения. Хотя ни один из этих интерфейсов революции в доступе к аналитическим данным не сделает, новые средства могут серьезно расширить выбор аналитических технологий.

Джордж Споффорд (George Spofford) — главный архитектор в DSS Lab, компании, специализирующейся в области сервисов поддержки принятия решений. Участвовал в разработке стандартов в Совете OLAP (OLAP Council) и Консультативном совете по XML for Analysis (XML for Analysis Advisory Council). С ним можно связаться по адресу george@dsslab.com.

Источники дополнительной информации Спецификации CWM: http://www.omg.org/technology/cwm/index.htm Спецификации JOLAP: http://www.jcp.org/jsr/detail/69.jsp Спецификации OLE DB для OLAP: http://www.microsoft.com/data/oledb/olap SOAP: http://www.w3.org/TR/SOAP Web-сайт по XML for Analysis: http://www.xmla.org