Человек месяца

Уважаемые читатели!
В этом году выпуск за выпуском журнала я хочу познакомить Вас с российскими Центрами компетенции технологий Oracle. Мы уже были в гостях в ЦКТ Oracle по направлениям “Информационная безопасность” (ФОРС – Центр Разработки) и “Системы высокой готовности” (РДТЕХ). А сейчас я хочу предоставить слово Алексею Галагану, руководителю ЦКТ Oracle по созданию аналитических систем и хранилищ данных, директору Дирекции интеграционных проектов Консалтинговой группы "Борлас". Напомню, что компания “Борлас” совсем недавно получила от корпорации Oracle высший партнерский статус – “Oracle Certified Advantage Partner”, о чем мы писали и поздравляли “Борлас” в предыдущем выпуске нашего журнала.

Анатолий Бачин. Уважаемый Алексей, как руководитель ЦКТ Oracle по созданию аналитических систем и хранилищ данных, скажите, какие проекты аналитических систем и хранилищ данных сегодня нужны в России? Отличаются ли они друг от друга по назначению, особенностям построения, по используемому инструментарию? Какие примеры таких систем Вы могли бы назвать?

Алексей Галаган. Ответить на ваш вопрос мне хотелось бы максимально полно, насколько это позволит формат нашей беседы. Дело в том, что, являясь в Консалтинговой группе "Борлас" руководителем Центра компетенции Oracle по созданию аналитических систем и хранилищ данных (Oracle Data Warehousing), я ощущаю при работе с нашими клиентами потребность в классификации технологий и принципов построения корпоративных систем хранения и бизнес-анализа. Компания Oracle практически полностью обновила линейку своих аналитических продуктов, и мы сами едва поспеваем за новыми версиями, поэтому методическая помощь по классификации решений на страницах вашего специализированного журнала, я думаю, будет весьма своевременной.

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

К первому классу решений можно отнести приложения, использующие аналитические инструменты для построения оперативной управленческой отчетности. В стеке продуктов Oracle это Discoverer и, в случае формализованных требований к представлению информации, Reports. Эти мощные и универсальные инструменты при данном подходе можно быстро развернуть непосредственно над оперативными системами, настроив пользовательский интерфейс представления бизнес-показателей. Гибкая и удобная функциональность и подготовленный в рамках границ проекта стартовый набор шаблонов отчетов дает в руки аналитикам и менеджерам мощный инструмент описания сложных неформализованных запросов и форм их представления. Преимущества очевидны: сроки внедрения минимальны, стоимость проекта низкая, результаты осязаемы. Такое решение позиционируется для предприятий с ограниченным объемом исторических данных, хорошим уровнем согласованности нормативно-справочной информации и устоявшейся структурой информационных источников. Решение можно рассматривать и как первый шаг к формализации требований перед развертыванием полнофункциональной корпоративной аналитической системы. Но останавливаться на такой архитектуре опасно. Как только у менеджеров появляется удобный аналитический инструмент, количество пользователей и сложность анализа нарастают как снежный ком. Оперативные же системы спроектированы и реализуют, прежде всего, учетные функции, поэтому дополнительная аналитическая нагрузка может привести к существенному падению производительности, снижая эффективность работы не только аналитических подразделений, но и служб обеспечивающих операционную деятельность. Есть и функциональное ограничение Oracle Discoverer - это недостаточная гибкость при работе с иерархическими измерениями. Оно проявляется при анализе бизнес показателей в разрезе классификаторов, имеющих несбалансированные иерархии, когда статьи бюджета, например, описываются с различной степенью детализации. Существуют технические методы, позволяющие обойти данное ограничение, но универсальное решение лежит в плоскости многомерного представления данных, описанного ниже.

Правда, в нашей практике Oracle Discoverer и Oracle Reports чаще используется как аналитическое расширение при комплексном внедрении Oracle E-Business Suite. Это принципиально меняет ситуацию, так как источником выступает единая корпоративная система, да и при проектировании инфраструктуры решения к аппаратным ресурсам предъявляются дополнительные требования с учетом аналитики. Перечислять примеры внедрения таких проектов можно довольно долго, так как их наберется не один десяток. К наиболее крупным можно отнести решения для компаний "КапиталЪ Страхование", РАО "ЕЭС России". При этом я бы не стал относить решения к категории аналитических приложений, скорее это гибкие параметризованные средства построения управленческой отчетности.

Второй класс решений, опираясь на описанный выше аналитический инструментарий, использует в качестве единого корпоративного источника для подготовки управленческой отчетности специально спроектированное реляционное хранилище, интегрирующее данные из оперативных систем и оптимизированное под аналитические запросы. Такая архитектура снимает нагрузку с учетных систем, но требует синхронизации данных, поступающих в хранилище из различных источников. Несмотря на серьезное технологическое усложнение, решение приобретает внутреннюю стройность и завершенность, повышается согласованность и качество данных, снижается время представления информации, система становится масштабируемой и переносимой. Для успешного внедрения таких проектов требуется высокая компетенция архитекторов и разработчиков, реализующих в системе классические ETL (Extraction, Transformation, Loading) функции выгрузки данных из внешних источников, их согласования и регламентной загрузки в корпоративное хранилище. Ключевыми элементами становятся технологические аспекты и методология внедрения, включающие в себя вопросы проектирования хранилища, формализации алгоритмов очистки и контроля качества данных, разработка и согласование сценариев тестирования, оптимизация хранения и представления результатов. Вместе с полнофункциональным инструментом построения хранилищ Warehouse Builder, компания Oracle предлагает и наработанную методику внедрения Data Warehouse Method, что позволяет значительно снизить проектные риски, сократить время и стоимость ввода системы в промышленную эксплуатацию. Правда, с функциональной точки зрения, нового качества при реализации второго класса решений аналитик не получает, так как неизменными остаются технологии анализа, базирующиеся на штатных средствах представления информации.

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

Для того чтобы сделать следующий шаг в нашей классификации, хотелось бы вернуться на несколько лет назад. Компания Oracle одна из первых в мире взяла на вооружение передовую многомерную технологию хранения и анализа данных. Ключевым словом здесь является "хранение", потому что в большинстве альтернативных аналитических решений данные загружались в специализированные реляционные таблицы, хотя и описывались в терминах измерений и фактов, и только на этапе анализа эмулировалось многомерное представление бизнес-показателей. Это снижало, прежде всего, скорость доступа к информации и, как следствие, эффективность анализа. Продукт Oracle Express, реализованный на технологии MOLAP, позволил значительно расширить аналитические горизонты. Опираясь на многомерную модель данных, аналитики смогли реализовать сложные и эффективные алгоритмы анализа, моделирования, прогноза, а, используя решение для финансового анализа OFA (Oracle Financial Analyzer), создавать мощную корпоративную систему планирования и стратегического управления.

Как технологический ответ на требования пользователей к расширению и персонификации аналитической функциональности, в приложениях появляются многомерные витрины данных, развернутые над корпоративным хранилищем и обеспечивающие специализированную функциональность для аналитических служб предприятия, которые становятся неотъемлемой компонентой архитектуры. Появляется спектр задач, для решения которых необходимы новые компетенции, иные инструменты проектирования, принципиально отличный язык многомерного программирования, реализующий алгоритмы консолидации и статистического анализа. Усложняется и задача проектирования двухкомпонентного хранилища: с одной стороны, специалисты, принимающие управленческие решения, предъявляют требования к увеличению числа аналитик, по которым необходимо проводить многомерный бизнес-анализ, с другой, IT-специалисты стремятся минимизировать степень детализации данных, помещаемых в многомерную область, борясь за эффективность работы системы. Найти баланс между этими крайними позициями, одна из методических задач центров компетенции.

Нами реализован целый спектр успешных проектов, применяющих данную технологию, в различных сегментах рынка. По системам бюджетирования в производственной сфере: "Вымпелком", Пермская ГРЭС, "Галоген", "Фрито-Лей Мануфактуринг", аналитические системы в торговле: "Снежная Королева", "Торговый Дом Весна". Причем путем обобщения решений нами была создана мощная, преднастроенная аналитическая система КАИСА, вобравшая наиболее интересные алгоритмы многомерного анализа и представления данных. В предлагаемой классификации это третий класс решений, который бы я назвал OLAP-системы, спроектированные как специализированные многомерные витрины данных.

Но многомерный инструментарий, несмотря на очевидные преимущества, имел серьезный технологический минус: практически это был самостоятельный продукт, слабо связанный с базовыми технологиями Oracle. Поэтому при внедрении Oracle Express или OFA необходимо было уделять особое внимание подготовке технических специалистов Заказчика, имеющих казалось и без того большой опыт работы с продуктами Oracle. А аналитики и менеджеры были вынуждены одновременно работать в нескольких приложениях, используя то из них, которое обеспечивало требуемую детализацию данных. Вообще, многомерные технологии весьма капризны и требуют к себе повышенного внимания: в умелых руках они демонстрируют поразительную эффективность, но даже незначительные ошибки проектирования могут на порядки снизить параметры системы. Поэтому в проектах с использованием многомерных витрин всегда присутствовали дополнительные технологические риски. Безусловно, специалисты Oracle осознавали необходимость в более тесной интеграции продуктов аналитической линейки. И сегодня на смену продуктам Oracle Express пришла технология Oracle OLAP, объединившая реляционные и многомерные подходы проектирования корпоративных хранилищ данных.

Итак, к четвертому классу будем относить решения, использующие штатную Oracle Database OLAP опцию и позволяющую хранить и обрабатывать гигантские объемы первичных данных наряду с быстрым и эффективным многомерным анализом агрегированных бизнес-показателей. Для использования такой технологии компания Oracle предлагает и новые продукты. Это штатный аналитический инструмент Discoverer for OLAP и продукт проектирования многомерной базы данных Analytical Workspace Manager. При использовании их в интеграции с описанными выше продуктами, может быть реализована самая современная архитектура корпоративного хранилища. Принципиальным ее отличием от решения с использованием многомерных витрин данных является тот факт, что и реляционные и многомерные информационные объекты зарегистрированы в едином OLAP каталоге. Это позволяет скрыть от функционального аналитика физическую принадлежность информации к различным типам ее хранения. Для него это единое информационное пространство, и единственным отличием может быть только скорость доступа к тем или иным объектам анализа. С технологической же точки зрения, эффективный и хорошо зарекомендовавший себя движок Oracle Express теперь обрабатывает многомерные данные, которые физически хранятся в BLOB полях реляционной базы данных. Такое решение позволяет сопровождать и администрировать систему в рамках единой технологии Oracle Database, ставшей на сегодняшний день практически стандартом в России. На принципах Oracle Database OLAP разработана и современная система бюджетирования Oracle EPB (Enterprise Planning & Budgeting), приходящая на смену продукту OFA.

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

Пятый класс приложений реализован на технологии Oracle Database OLAP, но, во-первых, позволяет динамически рассчитывать и помещать в многомерную область хранилища бизнес-показатели, и, во-вторых, использует для анализа специализированные приложения, разработанные под заказ. Определимся сначала с необходимостью разработки специализированных приложений. Компания Oracle, наряду со штатным инструментом многомерного анализа Discoverer for OLAP, поставляет многофункциональную среду разработки аналитических приложений JDeveloper и набор Java классов BI Beans. Используя их, квалифицированная команда разработчиков может в сжатые сроки создать аналитическое приложение не только покрывающее возможности штатного инструмента анализа, но и предоставляющее конечному пользователю целый спектр дополнительных функциональных возможностей: прогноз, моделирование, статистический анализ, исследование данных. Причем подчеркиваю, создание специализированных аналитических приложений не отменяет, а дополняет штатные средства анализа. И те, и другие могут одновременно использовать различные группы пользователей системы. Как уже отмечалось выше, такое преднастроенное аналитическое решение уже было создано нами на базе Oracle Express в рамках системы КАИСА, а теперь эта расширенная функциональность перенесена и на новую технологию. Перейдем к технологическим расширениям. Стандартная последовательность функционирования хранилища выглядит следующим образом: в соответствии с регламентами, первичные оперативные данные после предварительной обработки попадают в реляционную часть хранилища. После этого наиболее востребованная информация агрегируется и помещается в многомерную область, что позволяет проводить анализ значительно эффективней, а при необходимости оперативно проваливаться для детализации в реляционную часть хранилища. Состав данных, помещаемых в многомерную область, и алгоритмы агрегации определяются при развертывании системы и модифицируются крайне редко, поэтому всегда присутствует желание спроектировать кубы с максимальным количеством измерений, создав некую избыточность на перспективу. Однако эффект от такого подхода чаще всего бывает обратный. Эффективность обслуживания системой кубов с большим числом измерений с нарастанием объемов исторических данных падает, что может стать причиной полной разбалансировки работы хранилища. Для данного класса решений мы предлагаем более гибкий механизм обслуживания хранилища: наряду со статическими кубами, формирующимися по штатной технологии, есть возможность в рамках сеанса работы конечному пользователю описать динамические кубы, рассчитать их, используя реляционную область хранения, зарегистрировать в OLAP каталоге и анализировать наравне со статическими кубами. Такой подход позволяет точечно обслуживать наиболее продвинутых аналитиков, придав алгоритмам агрегации предельную гибкость, сэкономив на объемах многомерной части хранилища, на времени агрегации и на скорости представления информации.

Вот, если коротко, ответ на Ваш вопрос. На более детальные технические вопросы наши специалисты готовы ответить в рамках работы Центра компетенции.

А.Бачин. Как производится подготовка специалистов по направлению "Аналитические системы и хранилища данных"? Считаете ли Вы нужным, полезным создание Групп пользователей, проведение конференций специалистов по Вашим направлениям?

Алексей Галаган

Подготовка специалистов – это важнейший элемент нашей повседневной работы. В конечном итоге, активы компании сосредоточены, прежде всего, в головах ее сотрудников. Это специфика высокотехнологичных компаний, и мы это прекрасно понимаем и рассматриваем подготовку специалистов как приоритетный внутренний проект. Для эффективного расширения компетенций было принято решение о выделении в самостоятельную дирекцию менеджеров и специалистов базовых технологий, то есть были сконцентрированы в одном месте и под единым руководством все технические кадры "Борлас". Это принципиально важное решение, ведь организационная структура компании может быть построена и по проектному принципу, когда подразделения самодостаточны, в них представлены специалисты всех направлений, способные реализовать комплексный проект своими силами от начала до конца. При таком подходе проще управлять проектами, но труднее добиться качественного результата, так как отсутствует серьезный анализ решений, успешно зарекомендовавших себя в проектах. А технологические находки должны быть формализованы, доработаны и растиражированы для обязательного применения. Это крайне трудно сделать в фоновом режиме между проектами, этим должны заниматься выделенные, высококвалифицированные группы специалистов, являющиеся центрами кристаллизации новых идей. Вот на базе одной из таких групп создан и успешно работает Центр компетенции Oracle по направлению "Аналитические системы и хранилища данных". Методики и технологии сначала вызревают в центрах компетенции компании и, только потом, в виде преднастроенных решений, используются в проектной работе. При этом специалисты центров работают на проектах в качестве внутренних аудиторов, что существенно повышает качество внедряемых систем. Наличие центров компетенции позволяет гораздо безболезненней вводить в проектные команды новых специалистов, потому что и они и менеджеры проектов знают, что не останутся один на один с Заказчиком, а будут курироваться и плавно подтягиваться до необходимого уровня экспертами центров. С другой стороны, наличие у Заказчика подготовленных специалистов, способных грамотно сформулировать требования к системе и принимать активное участие в реализации проекта, это практически половина успеха. Повысить квалификацию потенциального клиента, заинтересовать его в реализации у себя в компании наших решений – вторая важнейшая внешняя задача центров компетенции.

А.Бачин. Только что сосоявшийся Oracle AppsForum 2005 прошел под девизом “Предвидеть будущее”. Каково будущее аналитических систем и хранилищ данных в России, и как возглавляемый Вами Центр компетенции работает на это будущее?

Алексей Галаган.

Информационные технологии не могут развиваться вне общего контекста развития экономики страны. Посмотрите, куда движется современный российский бизнес: консолидация активов, привлечение иностранных инвесторов, выход на мировые финансовые рынки. Все это требует эффективного управления, в том числе и информационными ресурсами, повышения прозрачности бизнеса, переход на международные стандарты отчетности, адаптивности информационных систем к быстро меняющимся внешним условиям. А чем предприятия располагают на сегодняшний день: большим количеством слабо связанных учетных систем, построенных на разнородных программных платформах, не объединенных корпоративной нормативно-справочной информацией, не использующих Web-технологии. Для современных конкурентоспособных предприятий такая ситуация становится просто недопустимой. Время накопления операционных данных заканчивается, наступает этап трансформации данных в управленческую информацию, и альтернативы этому просто нет. А реализовать задачу практически можно двумя, часто взаимодополняющими способами. Либо заменить весь существующий "зоопарк", разрозненные информационные системы, на современную единую систему управления предприятием, но это весьма дорого, долго и не всегда эффективно, особенно если предприятие географически распределено и активно приобретает активы вместе с локальными системами автоматизации. Либо последовательно интегрировать существующие информационные потоки, внедряя корпоративные стандарты, формализуя регламенты взаимодействия, создавая единое информационное пространство, единую систему мониторинга ключевых бизнес-показателей. Но интеграция должна проводиться с использованием современных технологий, с четким определением приоритетов и последовательности работ, обязательным получением промежуточных практических результатов. Наша задача, как центра компетенции, как и задача специалистов других IT-компаний, квалифицированно помочь клиентам вместе пройти это нелегкий путь. И насколько грамотно и эффективно будут реализовываться интеграционные проекты, настолько предлагаемые технологии и решения будут все чаще и чаще находить своего Заказчика. Так что будущее мы делаем сегодня.

А.Бачин. Большое спасибо за беседу.