OLAP-средства и Web-технологии

Дата: Май 2003 года
Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab

Успешно развивающиеся технологии Хранилищ данных (ХД) и средств Business Intelligence (BI) – весьма полезные инструменты поддержки современного бизнеса. Однако большинству традиционных BI-приложений свойственны некоторые ограничения. Технология, на основе которой они реализуются, была разработана для анализа небольших выборок данных. Со временем круг пользователей расширялся, но ориентация на небольшие объемы данных при этом сохранялась. Наконец, появились технологии, предназначенные для обработки постоянно растущих огромных объемов данных, содержащихся в Хранилищах.

Такие технологии, как многомерный OLAP, реляционный OLAP и гибридный HOLAP, обеспечивают новые подходы к анализу больших баз данных. С другой стороны, они накладывают ограничения на количество пользователей. Для того, чтобы снять эти ограничения, следующее поколение BI-средств использует аналитические методы в сочетании с технологией Internet/Intranet. Если раньше крупномасштабный BI-проект подразумевал сотни пользователей, то теперь поддержка нескольких тысяч человек считается обычной, а в будущем предполагается обеспечивать сотни тысяч и более.

Динамические технологии, появление которых стало возможно в результате развития «всемирной паутины» (World Wide Web), представляют собой прекрасную альтернативу традиционным клиент/серверным OLAP-методам. За последнее время появился целый ряд OLAP-средств (их называют Web-OLAP или WOLAP), оснащенных Web-возможностями. Они выполняют аналитические функции, такие как агрегирование и детализация (drill-up и drill-down), а также обеспечивают высокую производительность в сочетании со всеми преимуществами, которые дает Web-приложение.

С такими приложениями значительно облегчается задача установки, конфигурирования и развертывания. Web-приложение выполняется на сервере, и поэтому на клиентской машине нужен только Web-браузер и подключение к Intranet/Internet. Подобная стратегия развертывания особенно удобна для администраторов Хранилищ данных, которым часто приходится работать с широким контингентом удаленных пользователей (например, с продавцами или служащими отделов, расположенных в удаленных офисах), что очень не просто при использовании традиционной клиент/серверной архитектуры.

Использование Web-технологий влияет и на стоимость BI-приложений:

• существенно снижаются затраты на развертывание программного обеспечения в расчете на одного пользователя;
• компании могут воспользоваться более выгодными ценовыми моделями, оплачивая использование продукта (которое определяется количеством одновременно работающих пользователей), вне зависимости от числа рабочих мест или размера сервера.

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

Internet/Intranet OLAP

Сегодня многие компании применяют intranet-технологии для развертывания Хранилищ данных и предоставления OLAP-функций в масштабе всего предприятия, а затем переходят и к технологиям extranet, чтобы обеспечить своих партнеров (поставщиков, оптовых и розничных продавцов, представителей филиалов) защищенным доступом к Хранилищу и OLAP-средствам. Такой способ расширенной поддержки принятия решений позволяет сотрудничающим организациям совместно использовать информационные ресурсы и находить новые возможности развития бизнеса.

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

Итак, Web – это очень продуктивный способ передачи информации всем участникам процесса принятия решений. Применяя технологию Web-OLAP наряду с агентами оперативной доставки данных на сервер (push-technology), можно предоставить менеджерам приоритетную информацию, связанную с определенными бизнес-правилами.

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

Архитектура Web-OLAP

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

Большинство Web-OLAP приложений используют общую архитектуру, в которой клиентский браузер взаимодействует с HTTP-сервером, пересылающим HTML-страницы. Но помимо этого предоставляется еще и промежуточное (связующее) ПО, хранящееся на сервере. Такой компонент может напрямую связываться с Web-браузером или взаимодействовать с HTTP-сервером, который затем возвращает браузеру HTML-страницы с дополнительными данным.

Web-OLAP компонент промежуточного уровня выполняет набор функций, которые не может обеспечить HTML, а именно:

• взаимодействие с базой данных, где находится Хранилище;
• хранение состояний (предыдущих транзакций базы данных);
• вычисление и буферизация данных, возвращаемых на клиент.

Последним компонентом этой архитектуры является база данных. Web-браузер не соединяется с ней напрямую: за это отвечает связующее звено. Таким образом, ограниченные возможности HTML наряду с лимитированным доступом клиентской машины на сервер обеспечивают достаточную безопасность при извлечении данных из реляционной базы.

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

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

Такой подход предотвращает разрастание объема ХД. Централизованное хранение информации, доступной для всех пользователей с помощью OLAP-инструментов, устраняет риск работы с устаревшими данными, так как все пользователи будут обращаться только к тем элементам, которые находятся в центральном Хранилище.

Подходы к реализации Web-OLAP

На сегодняшний день реализовано множество различных Web-OLAP решений, в том числе на основе технологий HTML (DHTML), Java, ActiveX, а также комбинации выше названных.

Перечислим основные типы продуктов:

1. HTML(DHTML)-решения.
2. HTML с расширениями – CGI, связующее ПО.
3. HTML с использованием Java-апплетов.
4. Java или ActiveX-компоненты.

HTML-решения

Для реализации OLAP-функциональности в Web-браузере используется только HTML.

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

В этом случае для получения данных из автономных OLAP-машин используются планировщики, формирующие статические HTML-отчеты по HTML-шаблонам. Шаблоны создаются таким образом, чтобы все отчеты имели согласованный вид. Отчеты обрабатываются и передаются в браузер с помощью Web-сервера. Статические отчеты характеризуются хорошей переносимостью, быстро доставляются в браузер, при этом взаимодействия пользователя с браузером практически не происходит. В некоторых случаях имитируется переход по измерениям путем навигации по отчету. Планировщик может создать набор отчетов, связанных между собою гиперссылками. К примеру, пользователь, щелкнув по ссылке под названием «Третий квартал», переедет к другому отчету, содержащему данные за июль, август и сентябрь.

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

Метаданные могут храниться на сервере в двух форматах: в виде обычных HTML-тэгов в шаблонах на сервере (в HTML-файле) или в двоичном формате, например как поля в базе данных.

HTML-шаблоны также представимы в одном из двух форматов. Если для создания шаблонов используется готовый редактор, то они хранятся в обычных гипертекстовых файлах на Web-сервере. Пользователь может щелкнуть в браузере по ссылке с названием отчета и HTML-шаблона. Некоторые поставщики предлагают инструментальные Web-средства для создания и хранения метаданных шаблонов вместе с метаданными отчетов в двоичном формате. В таком случае и отчет, и шаблон могут быть созданы в оперативном режиме с помощью специальных процессов Web-сервера.

При любом способе хранения метаданных шаблонов и отчетов информация собирается Web-сервером согласно коду отчета, посылаемому с браузера. Программное обеспечение Web-сервера использует метаданные отчета, чтобы извлечь соответствующие данные из базы. База может храниться как на том же компьютере, что и приложение Web-сервера, так и на другом. Полученные из базы данные объединяются на основе шаблона в отчет и передаются в браузер.

Как правило, отчет уже содержит по умолчанию определенную OLAP-функциональность. При взаимодействии с отчетом пользовательский код посылается вместе с другой информацией на Web-сервер, использующий этот код для отслеживания информации, которую пользователь видит в браузере. Код может храниться в HTML-файле как часть HTML-команды, поступающей на сервер в тот момент, когда пользователь запрашивает новые данные. Как правило, такие решения имеют ограниченные возможности. HTML не может передать точные X и Y координаты точки, где должен располагаться тот или иной элемент отчета, поэтому в зависимости от браузера или платформы отчет может выглядеть по-разному. Полный набор OLAP-функций (вращение, агрегирование и углубление в данные) не предусмотрен.

HTML с расширениями – CGI, связующее ПО

Одно из самых слабых мест HTML – невозможность хранить состояния. Предлагаемый вариант решения проблемы – использование CGI (Common Gateway Interface – общий шлюзовой интерфейс) или других Web API (Application Programming Interface - интерфейс прикладного программирования) для реализации связующего ПО (middleware). С помощью этого метода можно обеспечить хранение состояний, а также буферизацию строк, возвращаемых на клиент, и выполнение некоторых вычислений над передаваемыми данными.

В случае использования такой архитектуры переносимость для клиентских платформ обеспечивается за счет использования HTML в качестве интерфейса. Однако в зависимости от того, как реализовано приложение Web-сервера, проект может также переноситься с одной серверной платформы на другую. Это, в частности, касается CGI-приложений, обладающих высокой переносимостью. О большинстве других Web API этого сказать нельзя. Например, серверное приложение, разработанное с использованием API Microsoft Internet Information Server (ISAPI) вероятнее всего будет работать только на Internet Information Server.

Однако и в этом случае использование только HTML налагает ограничения на интерфейс. Правильное отображение графиков и отчетов будет затруднено. Эта проблема решается с помощью Java-апплетов, которые обладают большими возможностями по управлению выводом информации на монитор.

HTML с использованием Java-апплетов

Совместное использование HTML и Java-апплетов позволяет создать отличное Web-OLAP решение. В этом случае HTML применяется для отображения меню и выполнения простых интерфейсных функций, а с помощью Java-апплетов обеспечиваются более сложные компоненты интерфейса программы, а также согласованное отображение диаграмм, графиков и таблиц. В таких приложениях чаще всего реализованы функции агрегирования и детализации, а также вращения (pivoting) данных. За счет широких графических возможностей Java по сравнению с HTML, можно представлять данные в виде диаграмм и изменять их в интерактивном режиме.

Java или Active X

Следующий подход предполагает использование Java- или ActiveX-компонентов для минимизации взаимодействия между браузером и Web-сервером, а также расширения возможностей пользователя по работе с данными за счет более качественного интерфейса. Существует два способа применения этих компонентов.

В первом случае Web-сервер заполняет двоичный файл данными для отчетов, и интерфейсные компоненты посылаются в браузер вместе с ответным HTML-файлом. На клиенте одно из свойств управляющего элемента (ActiveX или Java) задает для браузера название соответствующего файла данных. Браузер скачивает этот файл, а компонент загружает данные. Таким образом, компоненты обеспечивают выполнение таких OLAP-функций, как агрегирование, детализация и вращение с помощью удобного интерфейса, без обращения к серверу. Поскольку передача данных между клиентом и сервером осуществляется в двоичном формате, такой подход можно считать более безопасным.

Во втором случае, интерфейсный компонент напрямую соединяется с сервером, который в интерактивном режиме передает данные на клиент по мере поступления запросов пользователей. В этом случае интерфейсный компонент запрашивает данные с Web-сервера, открывая HTTP-поток. Затем, получив результаты с сервера, он анализирует полученную информацию и предает данные на объект для отображения.

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

Предпочтения пользователей

В ходе опроса, который проводился Survey.com, компанией, занимающейся маркетинговыми исследованиями в области Web-технологий, пользователям Web OLAP-систем был задан вопрос, касающийся их предпочтений в отношении архитектуры (Java, ActiveX, DHTML и т.п.). С учетом места и значимости Web-а, ожидалось, что эти предпочтения будут достаточно четкими. Но на деле это предположение себя не оправдало. Треть респондентов заявила, что четкого мнения на этот счет не имеет, а тех, кто твердо придерживается той или иной архитектуры оказалось намного меньше. Среди них наибольшей популярностью пользуется Java, это объясняется тем, что в опросе участвовали пользователи фирмы Oracle, из которых 37% предпочитают именно такую архитектуру. И, наоборот, заказчики компании Brio одобряют технологию своего поставщика, предпочитая встраиваемые модули (plug-in approach). Клиенты Cognos придерживаются использования только HTML, именно эта архитектура заложена в PowerPlay. Некоторые участники опроса отметили свое желание работать с ActiveX. В целом, сложилось впечатление, что большинство респондентов поддерживают ту технологию, которая реализуется их поставщиками. Это связано либо с выбором продукта в зависимости от его Web-архитектуры (что маловероятно), либо с «подготовкой», которую провел разработчик, поставляющий приложения.

Удивительно то, что лишь немногие пользователи высказались за использование XML или XSL в качестве наиболее удачной Web архитектуры, и практически никто не отметил DHTML (Динамический язык HTML), несмотря на то, что для большинства поставщиков OLAP-инструментов рассматривают эти языки как основные средства реализации.

В целом пользователи довольны большинством лидирующих OLAP-продуктов, однако многие вчерашние «звезды» рынка уже поблекли. Мало нашлось активных пользователей известных продуктов, таких как Gentia, Holos, Pilot, SAP BW и SAS MDDB, да и те немногие, кто ими пользуется, меньше удовлетворены результатами, чем все опрошенные в среднем.

Заключение

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