Несколько лет назад аналитическая компания Gartner опубликовала небольшой документ с довольно скандальным названием — The Death of the Database. Не смотря на пафос, в нем не предрекалась скорая смерть СУБД, а всего лишь констатировался тот факт, что в будущем роль баз данных окажется не столь всеобъемлющей, как это было на протяжении нескольких десятилетий. В этом отчете аналитик Дэвид Фейнберг пишет: «Современные системы, поддерживающие принятие решений, и средства бизнес-аналитики не могут быть построены исключительно на исторических данных, накопленных в хранилищах, в своей работе они должны включать и долговременные данные (long-term), и данные, хранящиеся среднее время (mid-term), но главное место в них будет отводиться ‘живым’, или текущим данным (immediate). Сегодня работу с последней категорией данных называют обработкой событий в реальном времени, но вскоре подобный подход станет нормой».
В применении к бизнес-аналитике (Business Intelligence, BI) для обозначения такого рода отношения к данным стали использовать индекс 2.0.
Живым примером внедрения BI 2.0 могут быть продукты английской компании с показательным названием SeeWhy Software (то есть «посмотри почему»), среди них — SeeWhy Enterprise Edition, платформа бизнес-аналитики, обеспечивающая обработку текущих событий. В отличие от классических систем BI, требующих загрузить данные в хранилища, прежде чем их обрабатывать, SeeWhy Enterprise Edition может использовать потоковые данные, поставляемые программным обеспечением промежуточного слоя от Web-сервисов. Инструментарий SeeWhy может быть использован для анализа структурированных и неструктурированных данных. Чарльз Николс, идеолог SeeWhy, проводит следующую аналогию: «Наша компания первой предложила полнофункциональную платформу для управления предприятием, используя для этого сведения о текущих событиях, этим она отличается от других систем для BI. Традиционные системы можно сравнить с самописцами, устанавливаемыми на каких-то объектах, например на самолетах, их данные используются тогда, когда в этом возникает потребность, а система SeeWhy Enterprise Edition подобна системе автоматизации управления самолетом».
Первым успешным внедрением SeeWhy Enterprise Edition стала система управления транспортировкой пива «Гиннес» из Ирландии в Соединенные Штаты.
Компания SeeWhy помимо корпоративной версии своего продукта предлагает версию SeeWhy Community Edition, свободно распространяемую и работающую только на одном процессоре. Кроме того, с сайта компании стоит загрузить интересную и не лишенную философской направленности книгу Чарльза Николса «В поиске понимания» (In Search of Insight).
«Карфаген должен быть разрушен»
Когда во времена Пунических войн престарелый сенатор Катон Старший к месту и не к месту говорил «Картагинэм эссэ дэлендам!», а римляне ему не верили, большинству граждан могущество Карфагена казалось незыблемым. Над старцем посмеивались, но мы-то знаем, что в итоге его предвидение оправдалось. Карфаген пал, а место, где он стоял, распахали. Пример упрямца Катона вдохновляет автора в его назойливых утверждениях, что системы управления в бизнесе рано или поздно, но все-таки уподобятся техническим системам. Естественно, они будут построены на других принципах и с учетом иного уровня сложности. В качестве еще одного аргумента в пользу этой точки зрения можно рассматривать наблюдаемую конвергенцию, казалось бы, таких далеких явлений, как BI, SOA и CEP (Complex Event Processing — «обработка сложных событий»).
BI и новые технологии
В еще одном отчете Gartner, озаглавленном Emerging Technologies Will Help Drive Mainstream BI Adoption и опубликованном в феврале текущего года, его автор, аналитик Курт Шлегель называет пять новых, активно развивающихся технологий, которые должны изменить отношение к BI и к месту, занимаемому бизнес-аналитикой в общей системе управления предприятием. В списке Шлегеля на первом месте стоит так называемая «интерактивная визуализация». Под этим словосочетанием скрывается не что иное, как наиболее современный подход к визуальному представлению данных, он отличается от принятых методов двумя основными качествами: 1. до сих пор все традиционные способы визуализации, начиная от аналоговых стрелочных приборов до виртуальных панелей управления, принятых в BI, оставались всего лишь статической проекцией имеющихся данных в иную форму, лучше воспринимаемую человеком. Теперь же средства визуализации можно делать трансформируемыми и адаптируемыми, то есть под контроль пользователя передается возможность управления процедурами ввода/вывода. 2. это является принципиально новым для систем управления бизнесом, взаимодействие пользователя с BI может осуществляться в режиме реального времени, разумеется, с поправкой на то, что это режим «мягкого реального времени» (soft-real-time). От обычного режима реального времени, принятого в технологических системах управления, он отличается тем, что допускает определенные задержки, но незначительные, не препятствующие восприятию, не нарушающие процесс интерактивного взаимодействия.
Далее Шлегель выделяет аналитические средства, способные работать с данными, размещаемыми в оперативной памяти (in-memory analytics). Их появление стало возможным вместе с массовым распространением 64-разрядных серверов и снижением цены на оперативную память. В отличие от обычных подходов OLAP здесь исключается загрузка данных в хранилища. Если традиционные подходы (ETL в сочетании с OLAP) больше годятся для анализа накопленных исторических данных, то в памяти предпочтительнее анализировать оперативную информацию.
На третьем месте — интеграция методов BI с технологиями поиска; заметим, что имеется в виду не Web-поиск, а специализированные средства для корпоративного поиска.
Четвертое и пятое место разделили программное обеспечение как сервис (Software as a Service, SaaS) и сервис-ориентированные архитектуры (Service-Oriented Architecture, SOA). Предполагается, что более доступные по цене технологии, построенные на принципах SaaS, откроют возможность для использования BI небольшим компаниям, а говоря о SOA, автор отчета, скорее всего, подразумевал, что методам, используемым для аналитики, предстоит приспособиться к архитектуре этого типа. В жизнь входят новые архитектуры, и технологии, поддерживающие BI, должны быть к ним адаптированы.
Как происходит обычно в таких случаях, прогнозы Gartner немедленно растиражировались, а текст отчета оказался разобран на цитаты. В прессе появились восторженные отклики; скажем, в статье «Бизнес-аналитика — бриллиант в короне SOA» (Computerworld Россия, № 7-8, http://www.osp.ru/cw/2008/07-08/4840613 ) утверждается, что «BI может стать, образно говоря, самым ярким компонентом в... портфеле решений в сервис-ориентированной архитектуре». Тезис, вынесенный в название, вообще говоря, ставит все с ног на голову. Вспомним, что когда создавались подходы к многострадальной архитектуре SOA, никакого специального расчета на BI не было, на протяжении ряда лет решалась совершенно иная архитектурная задача. И вот теперь, когда такая архитектура создана, нет никакой нужды украшать ее чем-то. Напротив, происходит обратное явление, когда SOA утвердилась, она подчиняет себе некоторые старые технологические приемы и требует их перестройки, точнее говоря, SOA создает новые условия для их существования. Если иметь в виду BI, то главное изменение состоит в том, что в условиях SOA данные распределены между сервисами и приходится решать обратную задачу: как в рамках SOA создать возможность для наиболее эффективного внедрения BI. Об этом и пойдет речь ниже, но для начала сделаем попытку разобраться в природе BI и отношениях BI с поддерживающими технологиями.
И все-таки, что же такое BI?
Если посмотреть со стороны, то не может не показаться странным, с какой всеядностью BI поглощает новые технологии, начиная от электронных таблиц и кончая «добычей данных» (Data Mining). Наверное, не случайно через многие труды рефреном проходит вопрос «что такое BI», на который дается множество разных ответов. (Показательно, что никто не задается вопросами «что такое СУБД» или «что такое язык программирования» и им подобными.) Как ни странно, им задаются даже признанные авторитеты. К примеру, даже Шаку Атре, широко известная как популяризатор BI, в недавнем интервью (оно так и было названо — Shaku Atre: What is Business Intelligence?) не смогла дать прямого ответа и точного определения, что же такое BI. Правда, в известной книге Business Intelligence Roadmap, написанной ею в соавторстве с Лариссой Мосс, еще одной евангелисткой BI, мы находим следующее очень важное определение-наблюдение: «BI — это не продукт и не система. Скорее всего, это некоторое архитектурное сооружение или набор взаимосвязанных средств, а также приложений, поддерживающих принятие решений и баз данных, которые обеспечивают бизнес-сообществу простой доступ к бизнес-данным». Там же мы можем найти и такое: «Область действия BI-приложений, поддерживающих принятие решений, распространяется на различные действия, связанные с прогнозированием, анализом бизнес-процессов, подготовкой балансовых отчетов».
Так или иначе, технологии, используемые для анализа данных, могут быть разными, но суть их одна — они предназначены для перевода данных из формы, понятной машине, в такое представление, которое позволяет человеку извлечь из них максимум полезной информации*.
Немного истории
Мало кто помнит, но впервые термин Business Intelligence предложил выдающийся американский ученый Ханс Петер Лун (1896-1964). Он был специалистом в области information science, то есть занимался информатикой в ее первородном смысле, а не в том, который навязали этому слову отечественные ученые в 80-е годы. И это чрезвычайно важно, поскольку доказывает, что как направление BI возникло вне всякой связи с какими-то конкретными, тем более, современными технологиями. К появлению BI подтолкнуло глубинное понимание сути информационных процессов и информации, роли информации в различных видах человеческой деятельности, а не только в бизнесе в том смысле, который вкладывают в слово business, произнося его на русском языке**.
Ханс Петер Лун — первооткрыватель BI
До создания им основ BI Лун занимался статистическими исследованиями и индексацией текстов, это было еще в докомпьютерную эпоху, ему были доступны только электромеханические табуляторы. Перед тем как обозначить предмет своей работы, он определил его компоненты, описав business как набор различных активностей, предпринимаемых в науке, технологиях, коммерции, индустрии, законодательной деятельности, обороне и т.д. Коммуникационные системы, поддерживающие эти виды активности, он назвал intelligence system, то есть системами, поддерживающими разумную деятельность. А под intelligence Лун понимал способность устанавливать взаимосвязь между представлениями отдельных фактов с тем, чтобы действовать в интересах решения поставленных задач и намеченных целей. Свое видение проблемы он выразил в статье A Business Intelligence System, опубликованной в IBM Journal в октябре 1958 года. С точки зрения понимания роли и места BI эта статья вполне актуальна и сегодня. В интерпретации Луна все выглядит строго и понятно. Однако тридцать лет спустя после публикации Луна аналитик Gartner Говард Дреснер дал BI расширительную трактовку, предложив использовать BI в качестве зонтичного термина для различных технологий, предназначенных для поддержки принятия решений, не более того, после этого начались расхождения во мнениях и поиск смысла BI.
Двадцать лет спустя после публикации Дреснера его точка зрения стала общепринятой. Поддержка BI по-прежнему рассматривается как совокупность слабо связанных между собой технологий. Среди них по-прежнему остается и классический инструмент — электронные таблицы, плюс к тому генераторы отчетов, технологии OLAP, средства для управления бизнес-процессами с цифровыми приборными щитами, технологии разработки данных и текстов, а также многое другое. Но какими бы изощренными ни были эти инструменты, в конечном итоге они служат той цели, которую определил Лун, они, каждый по-своему, способствуют человеку в процессе превращения данных в полезную для него информацию.
Эволюция BI
Если не годятся прямые пути для определения какой-то сущности, то следует искать обходные. Встречаются такие явления, природа которых не позволяет представить их посредством формальных определений, но в то же время есть шанс передать их суть, показав эволюционные шаги, которые привели к их появлению. BI относится к этой категории. Поэтому мы не будем говорить «BI — это…», а посмотрим, как эволюционировали аналитические средства, и тогда увидим, что такое BI на самом деле. Цитировавшаяся выше Шаку Атре в соавторстве с Дипендрой Малхотрой в статье Real-Time Analysis and Data Integration for BI (http://www.dmreview.com/issues/20040201/8034-1.html ) предлагают свою образную эволюционную схему, состоящую из пяти этапов (рис. 1). На первых этапах доминировали отчеты, составляемые с использованием технологий OLAP, они предназначались ограниченному кругу менеджеров и аналитиков для стратегического планирования. По мере увеличения доступности отчетных данных отчеты начинают использовать управляющие среднего звена для принятия тактических решений. И, наконец, при наличии развитых средств поддержки BI появляется возможность пользоваться аналитической информацией в процессе оперативного управления. Аналитика в реальном времени является одним из шагов по направлению к предприятию, работающему в реальном времени. Из этой эволюционной схемы несложно сделать такой вывод: первичным является совершенствование и демократизация процесса предоставления аналитических данных, расширение круга работников, способных и полномочных принимать решения, а что касается технологий, то используются те, которые доступны на данный момент.
Группа авторов в статье Business Intelligence Solution Evolution: Adoption and Use (http://bi-bestpractices.com/view-articles/4759 ) выстраивает близкую по смыслу картину, представляя эволюционный процесс BI в виде четырехуровневой модели. На нижнем уровне находится инфраструктура BI, уровнем выше — управление основными показателями бизнеса (Business Performance Management), еще выше — поддержка принятия решений (Decision Enablement) и на вершине пирамиды — мониторинг бизнес-процессов (Business Activity Monitoring). Концепцию BAM иногда называют «BI в реальном времени».
На протяжении всей истории направление BI эволюционировало вместе с поддерживающими технологиями со времен мэйнфремов, но общим для этих технологий, было то, что они предполагали централизованный подход к хранению данных. Руководствуясь идеями централизации, была выстроена вся философия накопления данных в хранилищах, и приближенные к BI технологии извлечения, преобразования и загрузки данных (Extract, Transform and Load — ETL) являлись централизованными вне зависимости от взглядов «отцов-основателей» — Билла Инмона или Ральфа Кимбалла, которых придерживались ее создатели.
Сложившуюся и ставшую уже почти канонической картину технологий, используемых для BI, разрушают появившиеся относительно недавно сервис-ориентированные архитектуры SOA.
SOA и распределение данных
Преимущества систем, собранных из слабосвязанных модулей по архитектуре SOA, доказано и уже не вызывает сомнения. И все же, как любое инженерное решение, и этот подход является компромиссом, в данном случае отрицательной является оборотная сторона децентрализации, вместе с SOA теряется стройная система хранения данных, они оказываются распределенными между отдельными сервисами. Для большинства транзакционных систем это обстоятельство не имеет существенного значения, но для систем типа BI, где требуется анализировать данные, в том числе и исторические, децентрализация в хранении критична. Причем настолько, что появился специальный термин — «разрыв между SOA и BI» (gap between BI & SOA), так что ни о каком «бриллианте в короне» и говорить не приходится — скорее, задача состоит в том, как совместить SOA и BI.
Зазор возник из-за того, что часть данных заключена в сервисы, еще часть содержится в сообщениях, которыми обмениваются сервисы, ну и, естественно, некоторая часть, возможно наибольшая, остается в традиционных базах. Всеобъемлющий анализ проблемы данных в сервисных системах был сделан экспертом корпорации Microsoft Патом Хелландом (Data on the Outside versus Data on the Inside, www.cidrdb.org/cidr2005/papers/P12.pdf)***.
В своей работе Хелланд показал отличие функций, компонентов и сервисов с точки зрения работы с данными (рис. 3).
Объект или компонент как понятие, взятое из объектно-ориентированного подхода к программированию, — это некоторая сущность, обладающая состоянием и поведением. Точнее, компонент — это объект, написанный в соответствии со спецификацией (чаще всего такой спецификацией является COM и Enterprise JavaBeans). И функции, и компоненты состоят из кодов, они получают перерабатываемые ими данные централизованных источников в программе. В отличие от них сервисы состоят не только из кодов, но и из данных, причем и коды, и данные каждого сервиса отделены от всех остальных границами самого сервиса. Обмен между сервисами осуществляется посредством передачи данных в сообщениях. Чтобы выразить это своеобразие сервисов, Хелланд вводит представления о внутренних и внешних данных (рис. 4). В упомянутой работе исследуются особенности этих двух категорий данных. Однако в контексте этой статьи в своем большинстве они не имеют существенного значения, но самым важным в работе Хелланда является то, что он показал причину сложности реализации BI в архитектуре SOA, где приходится иметь дело с внутренними и внешними данными сервисов.
Пути преодоления проблем, созданных SOA
Итак, все технологии, на которые опирается BI, были созданы применительно к системной архитектуре, где есть централизованные источники данных; собственно, до последнего времени ничего иного и не было. Но наступают иные времена, и доминирующими становятся новые архитектурные подходы, основанные на сервисных принципах, где данные так или иначе распределены между сервисами. Как быть, как собрать разрозненные данные в единое хранилище для последующего анализа? Систематизацию возможных выходов из сложившегося положения предлагает Арнон Ротем-Гал-Оз, известный израильский эксперт в области распределенных систем, автор книги SOA Patterns и ведущий портала в журнале Dr. Dobb’s. Год назад он опубликовал статью «Преодоление сопротивления между BI и SOA» (Bridging the Impedance Mismatch Between Business Intelligence and Service-Oriented Architecture).
Арнон видит три возможных пути для преодоления барьера между BI и SOA. Вариант первый: можно попытаться распространить классические методы извлечения, трансформации и загрузки данных ETL на архитектуру SOA. Однако к чему это приведет? Вообще говоря, сбор данных для BI из разных источников не является чем-то принципиально новым, подобный опыт имеется в связи с использованием данных из ERP, CRM и других систем, распределенных по подразделениям предприятий. Но даже при наличии ограниченного числа подсистем процедуры ETL оказываются довольно запутанными, их перемежающиеся связи образуют так называемое блюдо спагетти. Потоки данных ETL накладываются на существующие связи между базами данных, между файлами и между приложениями. Нетрудно представить, какова будет степень запутанности, если придется наложить процедуры ETL на сервисы, их больше по количеству, и они имеют меньшую гранулярность. Кроме того, есть опасность нарушить основной принцип SOA, сервисы должны быть слабо связаны, если же на сервисы наложить процедуры ETL, то они потеряют автономность и вместе с ней потеряются основные преимущества SOA.
Возможен второй способ (его можно назвать методом «вытягивания данных из SOA»), суть его в том, чтобы специальным образом отслеживать состояние сервисов и выбирать из них изменения в данных. Путь этот чреват тем, что объем собираемых данных будет слишком большим, как следствие есть опасность перегрузки каналов передачи и систем хранения данных. Если же ввести какую-то ограничительную фильтрацию, скажем, сканировать данные с заданной скважностью, то можно пропустить какие-то важные события.
Единственным выходом из положения может стать третье решение, основанное на модели принудительной (push) рассылки. Этот метод приобретает популярность вместе с архитектурным подходом, называемым Event-Driven Architecture (EDA). Его суть в том, что сервис сам оповещает о происходящих в нем событиях, это происходит либо на периодической основе, либо в связи с возникновением события. На базе этого архитектурного подхода можно реализовать потоковую обработку событий (Event Stream Processing, ESP) и обработку сложных событий (Complex Event Processing, CEP). Если быть точным, то нужно отметить, что архитектура EDA может быть реализована и иными средствами, чем SOA, но их совмещение дает заметные преимущества. «EDA, построенная на SOA» решает все проблемы BI; если налажена потоковая обработка событий, то компоненты BI набирают нужные им данные, фильтруют их так, как им нужно, и размещают в хранилищах данных или в витринах данных.
Возвращаясь к Карфагену
Родственных черт, которые объединяют системы управления технологическими процессами и средства для автоматизации бизнеса, намного больше, чем можно предположить. Управление технологиями с использованием компьютеров началось в 60-е годы, в период расцвета кибернетики. Это дает основание к отождествлению кибернетических методов с практикой, не случайно появились такие дисциплины, как техническая, сельскохозяйственная, юридическая и прочие кибернетики. В конечном счете, все эти направления оказались тупиковыми, их наследием оказалась дискредитация кибернетики как науки. В реальности кибернетика оставалась необходимой философской основой, но не более того, работающие системы строились и строятся исходя из здравого смысла и предметного знания автоматизируемой области. В итоге в большинстве своем работающие системы управления состоят из нескольких традиционных подсистем: информационной, собирающей данные с объекта; вычислительной, вырабатывающей управляющие воздействия и ассистирующей человеку-оператору, находящемуся за пультом управления; и исполнительной, передающей управляющие воздействия на объект. Развитие систем управления начиналось с информационных систем, сначала нужно было предоставить оператору достоверную информацию, а потом уже пытаться как-то его заменить.
Распространение кибернетических методов на экономические и социальные системы (organizational cybernetics, management cybernetics, sociocybernetics) оказалось ничуть не более продуктивным, чем кибернетические направления, перечисленные выше. История повторяется, точно то же самое наблюдается в системах автоматизации бизнеса, пока в основном развивается информирующая часть, с помощью различных коммуникационных технологий (в том числе технологии радиочастотной идентификации), ключевых показателей эффективности (Key Performance Indicator, KPI), информирующих модулей, встроенных в сервисы SOA. Далее создаются корпоративные приборные панели и средства BI, ассистирующие менеджерам-операторам, сидящим перед этими пультами управления. В совокупности этими технологиями удается управлять в реальном времени и таким образом получить предприятие, работающее в режиме реального времени (Real Time Enterprise, RTE).
BI 2.0: прообраз новой архитектуры бизнес-аналитики http://www.osp.ru/os/2007/05/4260805
Открытые системы и проблемы сложности http://www.osp.ru/os/2004/08/185094
Корпоративный поиск 2.0 http://www.osp.ru/os/2007/07/4391731
SaaS — конец начала http://www.osp.ru/os/2007/10/4706040
Что Business Intelligence предлагает бизнесу? http://www.osp.ru/os/2003/04/182906/_p3.html
Взгляд Ральфа Кимбалла на хранилища данных http://www.osp.ru/os/2007/05/4265198
Хранилища и карты данных http://www.osp.ru/cw/2005/47/373696
EDA как очередная инкарнация SOA http://www.osp.ru/os/2006/09/3776459
EDA — архитектура, управляемая событиями http://www.osp.ru/os/2005/02/185297
* Именно из-за отмеченной неопределенности термин Business Intelligence практически невозможно перевести на русский язык. Если бы это было более конкретное понятие, соответствующий термин, конечно же, нашелся. Сложности подбора термина возникают тогда, когда понятие, стоящее за ним, размыто. — Прим. автора.
** Тем, кто интересуется такой информатикой, можно рекомендовать книгу «Основы информатики» Ружеро Гиляревского.
*** Надо заметить, что Хелланд отличается разнообразием талантов, на конференции TechEd Europe 2004 он представил свою песню The Day That IT Died («День, когда умрут ИТ»), написанную в ответ на статью Николаса Карра IT Doesn’t Matter («Не в ИТ дело»). Клип, где поет Хелланд, размещен по адресу http://channel9.msdn.com/ShowPost.aspx?PostID=11950 , а слова — на http://channel9.msdn.com/wiki/default.aspx/Channel9.MrcioGuy . Кстати, на фортепьяно ему аккомпанирует известный аналитик Дэвид Чеппелл.
