Научная статья на тему 'Опыт трансформации традиционного аналитического решения (sap + Oracle + BusinessObjects) на IMDM (sap Hana)'

Опыт трансформации традиционного аналитического решения (sap + Oracle + BusinessObjects) на IMDM (sap Hana) Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
183
71
i Надоели баннеры? Вы всегда можете отключить рекламу.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Сергей Петрович Шаргалин

Проект по созданию информационно-аналитической системы «Сбыт нефтепродуктов», заказчиком которого выступило управление коммерческо-сбытовой деятельности, стартовал и развивается как классическое ETL решение с 2008 года. Помимо возможности получать статичные отчеты на базе разрабатываемой системы, была поставлена задача предоставления пользователям возможности самостоятельно формировать аналитические запросы. Система должна была полностью покрывать потребности в аналитике и отчетности в области бизнес-процессов планирования и учета реализации нефтепродуктов на экспорт и на внутреннем рынке, учитывать весь поток документов. Необходимо отметить, что в «Сургутнефтегазе» это был первый опыт создания подобной масштабной системы.

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Опыт трансформации традиционного аналитического решения (sap + Oracle + BusinessObjects) на IMDM (sap Hana)»

Сергей Петрович Шаргалин

Руководитель группы аналитической отчетности отдела бизнес-решений управления информационных технологий ОАО «Сургутнефтегаз».

ОПЫТ ТРАНСФОРМАЦИИ ТРАДИЦИОННОГО АНАЛИТИЧЕСКОГО РЕШЕНИЯ (SAP + ORACLE + BUSINESSOBJECTS) НА IMDM (SAP HANA)

Управление жизненным циклом информационных бизнес-систем. Real-Time Enterprise 2.0

Проект по созданию информационно-аналитической системы «Сбыт нефтепродуктов», заказчиком которого выступило управление коммерческо-сбытовой деятельности, стартовал и развивается как классическое ETL решение с 2008 года. Помимо возможности получать статичные отчеты на базе разрабатываемой системы, была поставлена задача предоставления пользователям возможности самостоятельно формировать аналитические запросы. Система должна была полностью покрывать потребности в аналитике и отчетности в области бизнес-процессов планирования и учета реализации нефтепродуктов на экспорт и на внутреннем рынке, учитывать весь поток документов.

Необходимо отметить, что в «Сургутнефтегазе» это был первый опыт создания подобной масштабной системы.

АРХИТЕКТУРА РЕШЕНИЯ НА БАЗЕ BUSINESSOBJECTS + ORACLE

Одной из особенностей информационно-аналитической системы является множество источников данных, информация из которых увязывается в системе. Помимо основных учетных систем SAP R/3, SAP CRM, в аналитической системе аккумулируется информация, поступающая с нефтеперерабатывающего завода; с трех товарных бирж — Московской международной товарно-энергетической биржи, биржи «Санкт-Петербург», Санкт-Петербургской международной товарно-сырьевой биржи; от нефтетрейдера; от различных информагентств — «Кортес», Thomson Reuters, «Интерфакс»; из ЦДУ ТЭК.

Для загрузки информации в хранилище данных из внутренних информационных систем используется SAP Data Services, загрузка данных из внешних систем осуществляется через SAP PI. В качестве базы данных используется Oracle. Архитектурная схема приведена на рис. 1.

Большая часть данных обновляется один раз в сутки, так как сбор, перерасчет и очистка данных требуют много времени. В силу значительного количества исходных данных и источников, а также сложных алгоритмов расчета аналитической модели полное обновление всей модели данных занимает более 4 часов.

На сегодняшний день информационно-аналитическая система «Сбыт нефтепродуктов» — это более 10 источников данных, более 2000 измерений, более 300 показателей. На базе информационно-аналитической системы разработано свыще 100 регламентных отчетов.

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

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

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

К определенному моменту времени бизнес-пользователей перестала удовлетворять значительная задержка в получении актуальных данных.

С.П. Шаргалин. Опыт трансформации традиционного аналитического решения У (SAP + Oracle + BusinessObjects) на IMDM (SAP HANA) >

/N

Рис. 1.

Источники данных

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

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

Перед стартом проекта была проведена апробация (proof of concept, PoC) предстоящего проекта реинжиниринга информационно-аналитической системы. Рассматривались два варианта построения будущей модели данных: расчет по запросу (классическая in-memory) и создание предрассчитанного слоя в ХД.

По результатам PoC, для оптимизации производительности и поддержки информационно-аналитической системы было принято решение:

■ разделить модель данных в соответствии с функциональными областями бизнес-задач;

■ при построении модели использовать гибридный подход — сочетание элементов классического хранилища данных, и технологии in-memory;

■ апробировать систему сбора моделей данных на основе бизнес-объектов.

АРХИТЕКТУРА РЕШЕНИЯ НА БАЗЕ BUSINESSOBJECTS + HANA

Управление жизненным циклом информационных бизнес-систем. Real-Time Enterprise 2.0

BusinessObjects

Рис. 2.

SAP Data Services I SLT I SAP PI

44

SAP R/3 СПбМТСБ Биржа «Санкт-Петербург» РЖД

SAP CRM ММТЗБ ЦДУТЭК КОРТЕС

Источники данных

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

В итоге архитектура решения (рис. 2) приняла следующий вид: база данных Oracle заменена на SAP HANA. В основе модели лежат две части: историческая (статическая), которая обновляется раз в сутки, и динамическая, которая охватывает все изменения в течение дня.

Появился новый компонент SLT, обеспечивающий репликацию данных из баз систем-источников в SAP HANA. SAP PI обеспечивает работу с внешними источниками данных на основе веб-сервисов. SAP Data Services используется для загрузки и выгрузки данных, хранящихся в XLS, XML и других файловых форматах. Модель данных реализована средствами SAP HANA.

Ввиду использования сложных алгоритмов расчета показателей пересчет всей модели данных «на лету» был бы слишком затратным даже для HANA. Для реализации этой задачи было принято решение выполнять пересчет аналитических показателей на основе дельты изменений, для чего использована функциональность триггеров в HANA.Основной идеей данного подхода является захват изменений в части реплицированных таблиц и запуск расчета динамической части. Объем одновременно изменяемых данных незначителен, и процесс происходит практически мгновенно. Помимо того, используется и классический in-memory вариант расчета «на лету» — в случаях, когда нет необходимости проводить затратные расчеты. Динамическая часть модели изменяется в реальном времени и периодически перемещается в статическую. С помощью данного подхода решаются задачи быстродействия, оптимизации времени работы модели и отчетов.

С.П. Шаргалин. Опыт трансформации традиционного аналитического решения У (SAP + Oracle + BusinessObjects) на IMDM (SAP HANA) >

Рис. 3.

ЗАКЛЮЧЕНИЕ

Подводя итоги проекта и сравнивая время обновления моделей в первоначальной системе и в SAP HANA (табл. 1), мы видим, что оно существенно снизилось. Если раньше результата приходилось ждать часами, то теперь данные в аналитической системе доступны для анализа практически в режиме реального времени.

Упростился уровень модели данных посредством их деления в соответствии с функциональными областями бизнес-задач.

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

Время выполнения отчетов также сократилось в десятки раз (табл. 2). Если большие отчеты на Oracle выполнялись до 10 минут, то на SAP HANA максимальное время работы отчета не превышает 30 секунд.

Oracle SAP HANA

Полное обновление Частичное обновление модели модели в течение дня

От 4 до 5 часов до 30 минут

близкое к real-time

Табл. 1.

Среднее время Максимальное время

Oracle 30 секунд до 10 минут

SAP HANA 4 секунды до 30 секунд

Табл. 2.

Управление жизненным циклом информационных бизнес-систем. Real-Time Enterprise 2.0

ЛИТЕРАТУРА

1. Berg B., Silvia P. SAP HANA. An Introduction. — Boston: Galileo Press, 2012.

2. Haun J., Hickman Ch., Loden D., Wells R. Implementing SAP HANA. — Boston: Galileo Press, 2013.

3. Taft D. K. SAP HANA: Powering Next-Generation Real-Time Analytics [Электронный ресурс]. — http://www.eweek.com/database/sap-hana-powering-next-generation-real-time-analytics/#sthash.b5SQuHVv.dpuf (дата обращения: 25.04.2013).

i Надоели баннеры? Вы всегда можете отключить рекламу.