Начало 2006 года для корпорации Oracle ознаменовалось очередным приобретением на этот раз компании Siebel , известной в качестве лидера на рынке CRM-систем и, в частности своим продуктом Siebel Analytics . Многие из партнеров, уже привыкшие к такого рода событиям, отнеслись к этой новости как к желанию Oracle укрепить свои позиции на этом рынке. К числу людей, воспринявших это известие без особого энтузиазма, относился и я, но только до тех пор, пока в июле 2006 года мы не стали активно работать с новым продуктом Oracle Business Intelligence Suite Enterprise Edition или сокращенно - Oracle BI.
На поверку оказалось, что Oracle BI EE - это не просто новый продукт с какими-то новыми возможностями для пользователей аналитических систем или компаний-интеграторов, их внедряющих. Сегодня, получив первый опыт практической работы с ним, я могу с уверенностью сказать, что Oracle BI EE - это де-факто новая аналитическая платформа следующего поколения, во многом меняющая саму идеологию проектирования и реализацию аналитических систем и систем поддержки принятия решений. Ниже я постараюсь поделиться своими соображениями на этот счет, в первую очередь, с точки зрения представителя компании, проектирующей и внедряющей такие системы у предприятий-клиентов.
В рамках этой статьи я хотел бы выделить четыре основных технологических аспекта нового продукта, выгодно отличающих его от прежней аналитической платформы Oracle, известной как семейство продуктов Oracle Discoverer (ныне - Oracle Business Intelligence Standard Edition - Oracle BI SE ).
Архитектура сервера Oracle BI EE и преимущества, которые она обеспечивает
Во-первых, хотелось бы отметить технологическую архитектуру новой платформы и особенно ее ядра - аналитического сервера, благодаря которой он легко интегрируется с различными гетерогенными источниками данных. Оно и понятно. Поскольку ранее этот сервер развивался в рамках независимой компании, он и не "затачивался" именно (и преимущественно) на работу с базой данных Oracle. И если не брать во внимание технологические преимущества самой базы данных Oracle по сравнению с другими СУБД, что не является предметом обсуждения этой статьи, то Oracle для этого сервера - не более чем один из возможных источников данных. Один из источников, с которым сервер взаимодействует столь же эффективно, как и с другими. Принимая во внимание тот факт, что аналитический сервер не хранит в себе никаких данных (т.к. это не сервер баз данных ), а хранит скорее "карту доступа" к данным, мы получаем достаточно любопытный результат.
Предположим, что у заказчика в промышленной эксплуатации находятся несколько транзакционных систем, работающих с разными базами данных. И нам необходимо получить консолидированную аналитическую отчетность, которая должна содержать согласованные между собой данные каждой из этих баз. Так вот, с помощью аналитического сервера мы можем решить эту задачу без проектирования и построения классического хранилища данных . Все необходимые интеграционные процессы могут быть реализованы внутри сервера. Фактически на его уровне может быть создано " виртуальное хранилище данных" , которое для клиентских приложений будет выглядеть как независимый источник денормализованных данных (в привычных понятиях: анализируемые величины, аналитические разрезы, иерархии и т.д.). При обработке поступающих запросов это "виртуальное хранилище" будет их транслировать к первичным источникам данных, в том числе транзакционным! При этом практически никаких ограничений на тип СУБД -источников - большинство известных "в природе" СУБД интегрируются одинаково технологично.
Мне бы не хотелось сейчас более подробно останавливаться на технических подробностях такого рода решений. Понятно, что при сложной выверке первичных данных это будет сделать несколько сложнее, чем с помощью привычных ETL-инструментов. Скажу лишь, что для перекодировки уникальных идентификаторов мы можем использовать соответствующие Excel-таблицы, зарегистрировав их в качестве одного из источника данных. Более важно здесь другое, а именно: при необходимости получить быстрый положительный результат в сжатые сроки на узкой, локальной задаче, мы можем использовать описанный выше технологический подход, т.е. реализовать ограниченный объем аналитической отчетности без проектировки и внедрения хранилища данных . При этом, конечно, следует помнить, что мы столкнемся с рядом ограничений, на которых я остановлюсь ниже. Но согласитесь, иногда мы оказываемся в ситуации, в которой действительно необходимо продемонстрировать быстрый положительный результат с решением ограниченной функциональности. Особенно тогда, когда от этого может зависеть финансирование проектов на ближайшие несколько лет. Сейчас с инструментами новой платформы, мы можем (без реализации хранилища по заданным алгоритмам) посчитать ограниченное количество ключевых показателей и дать доступ к ним нескольким топ-менеджерам (разумеется, если в транзакционных системах имеется вся необходимая информация), тогда как ранее, на основе прежней аналитической платформы Oracle, сделать это было невозможно .
Теперь об ограничениях "виртуального хранилища данных". У этой, казалось бы, привлекательной "медали", как и ожидалось, есть и обратная сторона. Я бы даже сказал "мина". Дело в том, что за последние несколько месяцев мне неоднократно приходилось слышать такое мнение уважаемых людей о новой аналитической платформе Oracle: "хранилища вообще больше могут не понадобиться" . Не могу с этим согласиться. Дело в том, что именно благодаря аппаратным ресурсам серверов, на которых реализованы хранилища данных, пользователи аналитических систем не нагружают учетные системы, выполняющие, как известно, свои, не менее важные функции. Так что, если реализовать аналитическое решение с "виртуальным хранилищем данных", которым будут активно пользоваться несколько десятков пользователей - можно "поставить на колени" любую учетную систему, не говоря уже о том, что скорость отклика запросов аналитического решения оставит желать лучшего. Конечно, у аналитического сервера Oracle BI EE можно активно задействовать кэш, что в известной мере снизит нагрузку, но я не думаю, что это панацея.
Таким образом, если нам необходимо быстро реализовать аналитическое решение, состоящее из ограниченного набора вычисляемых ключевых показателей, получить которые возможно из существующих систем по известным алгоритмам, для ограниченного количества бизнес-пользователей (например, нескольких топ-менеджеров), то создание аналитической системы без хранилища данных выглядит привлекательным. К тому же позже, при необходимости, нам никто не помешает построить хранилище, например, в рамках дальнейшего масштабирования системы. В остальных же случаях к выбору технической архитектуры решения (в пользу хранилища или без него) я бы рекомендовал подходить крайне взвешенно.
С хранилищем, без хранилища и …
Второй аспект, на котором мне хотелось бы остановиться, вытекает из тех же самых особенностей нового аналитического сервера Oracle. По сути, выше были рассмотрены два крайних варианта построения архитектуры аналитического решения: классический подход, с созданием корпоративного хранилища данных, маппингом и всей вытекающей из этого "кухней", и подход с "легкой надстройкой" над транзакционными системами, представляющей собой фактически всего лишь "карту доступа к данным". Интуитивно понятно, что "истина где-то рядом". Так вот самое замечательное заключается в том, что эти два варианта не исключают друг друга и возможно их сочетание в рамках одного проекта. И возможность такого сочетания надо обязательно рассматривать при реализации проектов! Ниже я поясню, о чем идет речь.
Фактически, любое корпоративное хранилище данных - это исторические данные в силу того, что загрузка в него осуществляется по расписанию, в соответствии с регламентом, например, ночью. А это означает, что практически в любой момент времени информация в хранилище в той или иной степени уже является устаревшей. С другой стороны, хранилище, как нам хорошо известно, обеспечивает снижение нагрузки на системы - источники данных. Кроме того, информация в хранилищах размещена в денормализованном виде, что обеспечивает минимальное время отклика системы на запросы. А это само по себе немаловажно.
Так вот репозиторий нового аналитического сервера Oracle можно настроить таким образом, что при обращении пользователей к историческим данным или данным по закрытым периодам он будет транслировать свои запросы к хранилищу, а при обращении к данным, например, текущего дня - к транзакционной системе. И для пользователя это все абсолютно прозрачно! То есть, при настройке клиентских рабочих мест мы используем настроенный однажды репозиторий сервера, даже не задумываясь о том, откуда и в каких случаях будет поступать информация. Альтернативным вариантом решения может являться агрегированная информация, содержащаяся в хранилище, с возможностью ее детализации до первичных проводок, хранящихся в транзакционной системе.
На мой взгляд, именно такой "гибридный" вариант архитектуры с использованием корпоративного хранилища данных является наиболее привлекательным и перспективным. Правда, здесь злую шутку может сыграть тот самый пресловутый кэш, обеспечивающий снижение нагрузки на транзакционные системы, т.к. если данные хорошо "закэшировать", то не совсем понятно, чем это будет отличаться от хранилища. Но и здесь есть выход из положения, т.к. сервер поддерживает механизм очистки кэша по событию, привязанного, например, к триггеру таблицы источника. Так или иначе, вопросы эти решаются, и мы реально можем получить одновременный доступ как к историческим данным по классической схеме, так и к данным реального времени транзакционных систем. Это еще одна выгодная особенность новой архитектуры, которая в старой платформе не имела места быть.
В довершении ко всему следует упомянуть еще одну немаловажную особенность нового аналитического сервера Oracle, о которой я до сих пор не говорил. Дело в том, что этот сервер может сам по себе являться независимым ODBC-источником данных. Казалось бы, это несущественный факт, но, если подумать, то именно на этом основании можно говорить о фактической, а не декларированной открытости архитектуры. Судите сами, предположим, по какой-либо причине (мне тяжело ее сейчас предположить, но все же) наш заказчик захотел пользоваться клиентскими приложениями третьих фирм. Или просто продолжать использовать "старые" приложения, к которым привыкли его сотрудники и которые его устраивают. Никаких противоречий. Все, о чем шла речь в этой статье до сих пор, может использоваться в рамках аналитического сервера Oracle, который будет являться независимым источником данных , как если бы это была какая-либо база данных. Нравится Вам использовать продукты третьих фирм - используйте! Не это ли защита вложенных инвестиций?
О клиентских приложениях Oracle BI EE
До сих пор мы обсуждали возможности ядра новой платформы - аналитического сервера. Хотелось бы коротко остановиться и на том, что же из себя представляют ее клиентские приложения. Я не ставлю себе сейчас задачу перечислить всю возможную функциональность этих приложений - сейчас в свободном доступе достаточно материалов по новой платформе и ее приложениям, в том числе и на русском языке (см., например, страницу сайта Oracle СНГ c ссылками на брошюры http://www.oracle.com/global/ru/pdfs/tech/ ). Мне лишь хотелось бы поделиться своими соображениями о том, что нового это может дать разработчикам и почему последним будет проще выходить на рынок с конкурентоспособными решениями.
Если честно, то до знакомства с новой платформой я пребывал в пределах относительно четких стереотипов: отчетность бывает регламентированная и аналитическая, регламентированная отчетность - это скорее к учетным системам, а для аналитики - все больше "опция" . А вот аналитические гибкие отчеты (Oracle Discovever) - это конек. Рабочий инструмент аналитиков, "золотых мальчиков" , которые обязательно найдут с помощью инструмента, который мы им, разумеется, дадим, ответы практически на любые вопросы.
Все это, конечно, так, но жизнь, как обычно, вносит свои коррективы. Дело в том, что "мальчиков золотых" мало, да и когда они есть, коммуникации между ними и топ-менеджерами, являющимися наиболее заинтересованными конечными пользователями аналитической системы, оставляют желать лучшего.
Другими словами, прежняя технологическая платформа, позволяла предоставить Заказчику очень гибкое решение, обеспечивающее работу не столько с отчетами, сколько с "тематическими витринами данных" . В этом случае пользователь мог работать с витриной, пользуясь преднастроенной отчетностью скорее как "точкой входа" , нежели как конечным востребованным результатом. И в этом смысле Oracle Discoverer (версии Desktop и Plus ), по моему убеждению, и сейчас является флагманским продуктом. Более того, в этом контексте новая аналитическая платформа и этот продукт друг друга дополняют.
Но жизнь показала, что количество пользователей, которым такая гибкость помогает, а не мешает в работе, как это не парадоксально, ограничено. И подавляющее большинство пользователей нуждается в более простых и эргономичных средствах, а именно:
получить интересующую информацию на ограниченном пространстве монитора и разобраться с ней за ограниченное время желательно без необходимости манипулировать клавиатурой и мышью .
Разумеется, если это необходимо, должна быть обеспечена возможность перехода, например, к детализированным данным, но одно другого не исключает. И от того, насколько эргономично может быть представлена информация на экране в соответствии с той или иной ролью пользователя , во многом зависит успех проекта.
Мне хотелось бы отметить, что приложения новой аналитической платформы, в сравнении с Oracle Discover, позволяют при одних и тех же трудозатратах построить эргономичные рабочие места не только для аналитиков, но и для пользователей, роль которых никак не связана с анализом и оптимизацией бизнес-процессов компании. А трудозатраты, как известно, и определяют стоимость (во всяком случае, себестоимость) проекта.
Примером могут служить менеджеры по продажам, для которых важно реализовать соответствующую страничку с информацией, прямо связанной с их финансовой мотивацией. Но главное, что стало очень удобно формировать сводную информацию для топ-менеджмента, когда необходимо на ограниченном пространстве монитора представить сводную информацию в удобном для восприятия виде. Это третий аспект, на котором я хотел остановиться. Но, как говорится, лучше один раз увидеть, чем семь раз услышать, поэтому если Вы еще не знакомы с этой платформой, - попробуйте и тогда сами сможете оценить ее преимущества.
О проактивной аналитике
В заключение хотелось бы остановиться на том, что специалисты Oracle называют "проактивной аналитикой" . Идея достаточно проста и банальна, а именно: "хотелось бы, чтобы аналитическая система не только позволяла мне контролировать ключевые показатели эффективности, но и сама, при необходимости, тем или иным образом оповещала о выходе того или иного показателя за установленные пределы".
Среди клиентских приложений новой платформы есть такое, которое решает именно эту задачу. При этом в качестве формируемого события (при выходе показателя за установленные пределы) может выступать электронное письмо с вложенным отчетом, sms на мобильный телефон, привлекающее внимание к отчету по обороту продаж и т.д. Но самое замечательное заключается даже не в этом. Начиная с версии Oracle BI EE 10.1.3.2 , реализована интеграция приложения, формирующего такие бизнес-события, с "движком" Oracle BPEL PM , обеспечивающим workflow для обработки сформированных событий по соответственно установленным цепочкам.
Я сейчас даже не берусь фантазировать, перебирая все возможные в этой связи варианты технологической архитектуры комплексных интеграционных проектов . Но одно я знаю точно: 2006 год стал для нас ключевым с точки зрения технологического прорыва и теперь в наших руках находится одна из самых передовых технологий. Тем легче нам будет удовлетворить потребности предприятий-клиентов, а значит - еще больше укрепить свои позиции на рынке.