RTE-2.0 by Elena Tamazova

УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ БИЗНЕС-СИСТЕМ

REAL-TIME ENTERPRISE 2.0

Сборник статей под редакцией Р.Д. Гимранова

УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ БИЗНЕС-СИСТЕМ

REAL-TIME ENTERPRISE 2.0 Сборник статей под редакцией Р.Д. Гимранова

Санкт-Петербург • Сургут 2014

УДК 519.687.5: 65.011.56 ББК 32.973.202-018.2

Редактор Р.Д. Гимранов. Рецензенты: В. А. Сухомлин, доктор технических наук, профессор ВМК МГУ им. М. В. Ломоносова; Д‑р Штефан Зигг, SAP SE, Боннский университет.

Управление жизненным циклом информационных бизнес-систем: Real-Time Enterprise 2.0.: сб. ст. под ред. Р.Д. Гимранова. — СПб, Сургут, 2014. — 114 с. ISBN 978-5-906157-17-1 Настоящий сборник статей посвящен применению подходов «Предприятия реального времени» на основе инновационной технологии In‑Memory Data Management в информационной системе крупной компании нефтегазового комплекса России. Авторы статей — ИТ-специалисты и руководители ОАО «Сургутнефтегаз», эксперты организаций-партнеров — делятся собственным опытом и идеями. Сборник можно рекомендовать ИТ-специалистам и руководителям предприятий, магистрантам и аспирантам по направлению «Информационные технологии» для ознакомления с опытом практического применения технологий In‑Memory, а также новыми подходами к реализации концепции «Предприятия реального времени».

УДК 519.687.5: 65.011.56 ББК 32.973.202-018.2 Дизайн, верстка и подготовка к печати: студия «Аэроплан». Санкт-Петербург, ул. Заозерная, 8 «А», www.airoplan.ru. Подписано в печать 03.12.2014. Гарнитура Exo 2.0. Формат 175х230 мм. Тираж 400 экз. Отпечатано в типографии «Колорит». 197198, Россия, Санкт-Петербург, Большая Пушкарская, 10.

ISBN 978-5-906157-17-1

СОДЕРЖАНИЕ

Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 А.Ю. Опарин Отличительные особенности технологии in-memory data management (IMDM) . . . . . 7 Е.Н. Матвиенко Решение аналитических задач с использованием SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Р.Д. Гимранов Real-Time Enterprise 2.0. Изменения корпоративных информационных систем при реализации технологии in-memory data management . . . . . . . . . . . . . . . . . . . . 27 В.А. Поборцев SAP HANA в контексте тенденций развития информационных технологий . . . . . . . . . 33 Руперт Хольцбауэр Новый стиль ИТ для SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 И.Н. Холкин Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем (на примере технологии in-memory data management, IMDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 С.П. Шаргалин Опыт трансформации традиционного аналитического решения (SAP + Oracle + BusinessObjects) на IMDM (SAP HANA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 В.В. Куфтерин Построение аналитической системы с использованием IMDM на основе репозитория метаданных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 И.Н. Ветряев Технико-экономические показатели работы транспорта в SAP HANA, SAP BO 4

. . .

Е.В. Максимюк Решение задач потоковой обработки данных и поддержки принятия решений с использованием IMDM (SAP HANA) на примере задач энергоэффективности производственных объектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 П.В. Ковалишин, Д.И. Буслов Использование SAPUI5 при разработке приложения по анализу техникоэкономических показателей на базе SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

ПРЕДИСЛОВИЕ

огласно второму принципу диалектического материализма количественное переходит в качественное скачком. В настоящее время мы наблюдаем процессы стремительных качественных изменений как в геополитике и экономике, так и в информационных технологиях. В этом смысле мы живем в интересное время, когда, по известной китайской пословице, почуяв ветер перемен, кто-то строит щит от ветра, а кто-то — ветряную мельницу. Айтишники в большинстве своем активные, системно и диалектически мыслящие люди, поэтому нашим выбором становится «ветряная мельница», а в контексте современных информационных технологий — построение системы управления предприятием со скоростью мысли (вольный перевод Real-Time Enterprise). Сила привычки Представьте, что вам предстоит управлять автомобилем, у которого вместо лобового стекла установлен монитор, и на этом мониторе показано то же место, где находится автомобиль, но только вчера. «Это невозможно», — говорите вы, и просите улучшить ситуацию. Новый проект, масса инвестиций, и вот на мониторе новая картинка — десять часов назад. Супердостижение. Снова не годится. Следующий проект, в десять раз дороже — час назад, десять минут назад, пять, три… Не годится! Проблема не считается решенной до тех пор, пока монитор не будет заменен на прозрачное стекло. Управлять современным предприятием сложнее, чем автомобилем. А ведь наши бизнесмены принимают управленческие решения на основании данных из информационных систем с задержкой не то что на день — иногда на месяц! И все привыкли. Привыкли к тому, что аналитические системы требуют времени и денег на перекачку, очистку, подготовку информации. Что системы поддержки принятия решений могут использовать только «вчерашнюю» аналитику, на это настроены архитектурные и процессные решения. Сила технологии Не зря некоторые инновационные технологии называют прорывными. Они разрывают привычные ограничения и приносят доселе небывалые возможности. Для современных информационных систем одна из таких прорывных инноваций — системы управления поколоночными базами данных в оперативной памяти (кратко — in-memory). Кардинально меняя возможности СУБД как основы любой информационной системы, технология in-memory позволяет исключить задержки при обработке информации, так что скорости возрастают на порядки — в тысячи и десятки тысяч раз! За счет чего это происходит, мы рассказываем в двух первых статьях сборника.

Сила решения Инновационная СУБД сильно влияет на возможности корпоративных информационных систем, состоящих из десятков и сотен СУБД, на их архитектуру и инфраструктуру. Важно понять, какие именно решения будут наиболее эффективны, в каких направлениях предстоит действовать. Прежде чем приступить к системной деятельности, мы определяем понятия, рассматриваем подходы вендоров, анализируем тренды развития. Об этом — в следующих статьях. Правильность выбранных подходов, особенности применения, экономическая и технологическая эффективность поверяются только практикой. О ряде проектов по внедрению СУБД in-memory SAP HANA рассказано в последних четырех статьях. Мы находимся в начале многолетней работы по созданию зрелой, эффективной информационной системы класса Real-Time Enterprise 2.0. В книге с архитектурной и с программной точек зрения описаны основные подходы и первые результаты. Прорывная инновация in-memory открывает пути для множества новых решений. Над какими-то из них уже ведется научная и практическая работа, но большинство пока даже не прорабатываются, что дает каждому из нас возможность строить свою «мельницу» — открывать и создавать что-то новое, учиться и развиваться профессионально. Р. Д.  Гимранов

Андрей Юрьевич Опарин Главный специалист по программному обеспечению ПУ «СургутАСУнефть» ОАО «Сургутнефтегаз», аспирант Сургутского государственного университета, преподаватель курса «Система управления основными данными» магистерской программы базовой кафедры ОАО «Сургутнефтегаз» в Сургутском государственном университете.

ОТЛИЧИТЕЛЬНЫЕ ОСОБЕННОСТИ ТЕХНОЛОГИИ IN-MEMORY DATA MANAGEMENT (IMDM)

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

Real-Time Enterprise 2.0

огласно исследованиям EMC 2011 года мировой объем данных увеличивается более чем в два раза каждые 2 года [1]. Впервые оказался нарушен закон Мура, т. е. темпы роста объема данных превысили темпы роста числа транзисторов на кристалле. Аналогичная ситуация наблюдается на корпоративном уровне. Например, на протяжении последних 15 лет объем данных, регистрируемых в информационных системах ОАО «Сургутнефтегаз», кратно увеличивается каждый год. При этом все более сложные задачи, требующие хранения и обработки больших объемов информации, ложатся на СУБД общего назначения, что требует новых подходов к построению систем управления данными.

СОСТОЯНИЕ ТЕХНОЛОГИЙ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СУБД Переломным в развитии микропроцессорной техники стал 2000 год — его можно считать годом окончания гонки частот и уменьшения размеров транзисторов. В период с 2000 по 2005 год был достигнут предел тактовых частот на текущих технологиях, а также энергетический барьер и предел параллелизма на уровне команд. Следствием оказался «технологический кризис», который заставил искать новые решения для повышения производительности вычислительных систем, такие как многоядерные архитектуры, многопроцессорные архитектуры, кластеризация. Кратко рассмотрим эти варианты. Многоядерность Современные микропроцессоры содержат от 1 до n ядер. Каждое ядро имеет собственный кэш первого (L1) и второго (L2) уровней. Кэш третьего уровня (L3), общий для всех ядер, первоначально появился как средство взаимодействия между ядрами и равнялся по объему сумме кэшей второго уровня всех ядер. Для непосредственно выполнения команды и данные должны быть в L1 кэше; если процессор их там не находит, происходит загрузка из L2 кэша, который, в свою очередь, загружает данные из L3 кэша. В случае если данных нет в L3 кэше, следует обращение к оперативной памяти. Данный процесс происходит автоматически, и для его оптимизации в современных микропроцессорах применяется множество технологий. Отдельно стоит отметить технологию SmartCache, которая автоматически перераспределяет объем L3 кэша в зависимости от интенсивности работы ядра с данными (интенсивности обращения к ОЗУ по требованию конкретного ядра). С появлением технологии SmartCache объем L3 кэша постоянно растет (до 24 Мб на современных процессорах). Теоретически, многоядерность выглядит очень перспективной, но на деле оказывается, что размещение множества ядер на одном кристалле приводит к перегреву процессора. Единственный способ побороть этот эффект — снижать тактовую

А.Ю. Опарин. Отличительные особенности технологии in-memory data management (IMDM)

Число транзисторов, тыс. шт. Тактовая частота, МГц Энергопотребление, Вт Степень параллелизма на уровне инструкций 10 000 000

Dual-Core Itanium 2

1 000 000

100 000

Pentium 4

10 000

Pentium 1000

386 100

0 1970

1975

1980

1985

1990

1995

2000

2005

2010

Рис. 1. Число транзисторов, тактовая частота, энергопотребление, степень параллелизма на уровне инструкций

частоту, что, в свою очередь, при решении задач общего назначения приводит к падению быстродействия. Именно поэтому современные серверные процессоры имеют 8–16 ядер, и это предел, дозволенный сегодняшними частотами и сегодняшними технологиями. Т. е. дальнейшее наращивание производительности за счет увеличения количества ядер невозможно. Многопроцессорность При размещении нескольких процессоров в одной ЭВМ каждый из них работает полностью независимо; ОЗУ при этом является разделяемым ресурсом. Обращение к ОЗУ происходит через общий для всех процессоров КДП (контроллер доступа к памяти). При активной работе всех процессоров с данными возникает эффект «бутылочного горлышка», когда процессоры и их ядра периодически простаивают в ожидании доступа к ОЗУ.

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

Real-Time Enterprise 2.0 Процессор

Процессор 1 Я1

Ядро 1

...

Ядро n

32+32 Кб

Кэш первого уровня ядра 1

Кэш первого уровня ядра n

500 Кб

Кэш второго уровня ядра 1

Кэш второго уровня ядра n

24 Мб

Процессор n

Яn

Я1

К1

Кn

К1

Кn

К1

Кn

К1

Кn

Кэш третьего уровня (с поддержкой Smart Cache)

Рис. 2. Многоядерные процессоры и многопроцессорные ЭВМ

...

К3

...

Яn

К3 КДП RAM

Кластеризация Идея объединения нескольких ЭВМ в вычислительный кластер посредством сети и распределения нагрузки между ними возникла и реализуется на практике очень давно. Кластеры позволяют подключать дополнительные вычислительные ресурсы по мере необходимости. Теоретических порогов наращивания производительности кластеров не существует, но когда мы сталкиваемся с необходимостью обработки больших объемов данных, классические вычислительные кластеры теряют все свои плюсы. Сети передачи данных работают кратно медленнее внутренней памяти ЭВМ. Когда требуется обработать сравнительно простые запросы в применении к большим объемам данных, перемещение данных на соответствующий узел кластера занимает больше времени, чем обработка «на месте». Следовательно, для достижения оптимальных результатов данные уже должны находиться на узле кластера в момент обращения к ним. Именно поэтому универсальные кластеры нашли применение в вычислительно сложных задачах при сравнительно небольших объемах данных, т. е. в задачах, где время расчетов кратно превышает время, требуемое на передачу исходных данных по сети. В условиях «технологического кризиса», когда адекватное росту нагрузки увеличение вычислительных мощностей невозможно, возникает вопрос: насколько эффективно СУБД общего назначения используют возможности современных ЭВМ в условиях действующих предприятий? Объемы информации, которые необходи-

А.Ю. Опарин. Отличительные особенности технологии in-memory data management (IMDM)

мо обрабатывать, растут ежегодно. Количество параметров, собираемых, например, системами АСУТП ОАО «Сургутнефтегаз», увеличилось за 15 лет с 80 тысяч до 5 миллионов, а средний период их поступления сократился с 30 минут до нескольких секунд (более чем в 7000 раз). В системах электронного документооборота каждые 2 секунды регистрируется новый документ (включая электронные копии). По примерным оценкам в единой информационной системе ОАО «Сургутнефтегаз» регистрируется несколько мегабайт данных каждую секунду 24 часа в сутки 365 дней в году. Все эти массивы информации хранятся и обрабатываются СУБД общего назначения. Несмотря на то что СУБД работают на современных многоядерных и многопроцессорных серверах, время обработки информации не удовлетворяет запросам бизнеса. Часто возникает ситуация, когда решение определенных задач оказывается возможно лишь частично из-за больших объемов информации. В 2000–2010 годах Michael Stonebraker с соавторами [2] и еще ряд независимых исследователей опубликовали работы, показывающие несостоятельность современных СУБД и подходов 1970‑х годов, которые в них до сих пор действуют. Также была показана неэффективность современных СУБД при работе с большими массивами данных и использования современных ЭВМ на архитектуре x86. Запросы с полным перебором на больших массивах простых данных (массив целых чисел) на алгоритмических языках низкого уровня работают в сотни и тысячи раз быстрее аналогичных запросов в современных СУБД общего назначения.

ПУТИ РЕШЕНИЯ ПРОБЛЕМ ОБРАБОТКИ БОЛЬШИХ ОБЪЕМОВ ДАННЫХ Одним из способов справиться с обработкой больших объемов данных стали интернет-технологии — например, модель вычислений MapReduce. Что же делать на уровне корпораций, когда для решения прикладных задач необходимы СУБД общего назначения? Все исследователи единогласно пришли к выводу о том, что возможности современных корпоративных ИС ныне ограничивает именно универсальность СУБД. Необходимо искать новые подходы к программной реализации СУБД общего назначения, максимально учитывающие возможности и ограничения архитектуры современных ЭВМ. СУБД в ОЗУ В 2006 году Jim Gray [3] представил доклад, в котором привел анализ всех типов внешней памяти ЭВМ. В данном докладе он показал, что стоимость 1 Кб ОЗУ, будучи в 100 раз выше стоимости 1 Кб дисковой памяти в какой-либо момент времени, примерно через 10 лет сравнивается с ней. При этом ОЗУ от 1000 до 10000 раз быстрее дисковых накопителей и всего в 100 раз медленнее L3 кэша процессора.

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

Real-Time Enterprise 2.0 КБ/с

1E+7 1E+6 1E+5

100:1

1E+4 1E+3 1E+2 1E+1 1E+0

Рис. 3. Стоимость накопителей за период с 1975 по 2006 год

Disk 10 лет

RAM

1E-1 1975

1980

1985

1990

1995

2000

2005

2010

Jim Gray пришел к выводам: 1. Чтобы оптимально нагрузить процессор, данные должны находиться в кэше. 2. Обращения к ОЗУ должны быть оптимизированы за счет применения «особенных» структур данных и алгоритмов. 3. Становятся возможными СУБД в оперативной памяти. Поколоночное (column) хранение Основной эффект in-memory технологии дают благодаря применению поколоночного хранения данных. При поколоночном хранении данные одной колонки последовательно располагаются в ОЗУ. Большинство запросов в СУБД направлены на атомарные операции с отдельными колонками; при этом они (колонки) однородны, а значит, к ним применимы векторные операции современных процессоров, что позволяет оптимально использовать кэш процессора и нагружать ядра и процессоры по максимуму. Сжатие данных Все данные одной колонки относятся к одному типу. Это означает, что к ним можно эффективно применить алгоритмы сжатия. При этом выбираются «легкие» алгоритмы, не требующие предварительной распаковки до обращения к данным. Применение специальных алгоритмов позволяет сжать данные в 10 и более раз. Это позволяет не только эффективно использовать ОЗУ, снижая разницу в стоимости RAM и Disk от 100:1 до 10:1 (для систем в целом иногда до 1:1 и даже 1:n), но и загрузить данные в кэш процессора за меньшее количество шагов. Отдельная колонка или таблица может быть целиком размещена в L3 кэше!

А.Ю. Опарин. Отличительные особенности технологии in-memory data management (IMDM)

Таблица Страна

Продукт

Строка 1

Индия

Шоколад

1000

Строка 2

Индия

Мороженое

2000

Строка 3

Германия

Шоколад

4000

Строка 4

США

Макароны

1000

Построчное хранение

Продано

Поколоночное хранение Индия

Индия Строка 1

Шоколад

Страна

Германия

1000 Строка 2

Индия

США

Мороженое

Шоколад

2000 Германия Строка 3

Продукт

США Макароны 1000

Мороженое Шоколад Макароны

Шоколад

1000

4000 Строка 4

Индия

Продано

2000 4000 1000

Рис. 4. Построчное и поколоночное хранение

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

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

Real-Time Enterprise 2.0

ЗАКЛЮЧЕНИЕ Применение поколоночного хранения данных в сочетании с «легкими» алгоритмами сжатия и разбиением данных по узлам кластера дает возможность использовать полностью in-memory СУБД, в которых Flash-диски и жесткие диски используются исключительно как резервное хранилище. Быстродействие таких СУБД в тысячи раз выше классических СУБД за счет эффективного использования всех возможностей архитектуры современных ЭВМ. Эффективная организация данных в оперативной памяти позволяет с большей отдачей задействовать доступные вычислительные ресурсы в задачах обработки больших массивов данных и открывает новые возможности для корпоративных информационных систем.

ЛИТЕРАТУРА 1. Extracting Value from Chaos [Электронный ресурс]. — http://www.emc.com/ collateral/analyst-reports/idc-extracting-value-from-chaos-ar.pdf (дата обращения: 12.03.2014). 2. The End of an Architectural Era (It’s Time for a Complete Rewrite) [Электронный ресурс]. — http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf (дата обращения: 12.03.2014). 3. Tape is Dead Disk is Tape Flash is Disk Ram Locality is King [Электронный ресурс]. — http://www.docme.ru/doc/372722/tape-is-dead-disk-is-tape-flash-is-diskram-locality-is-king (дата обращения: 12.03.2014). 4. Plattner H. A Course in In-Memory Data Management: The Inner Mechanics of InMemory Databases // Springer Heidelberg, 2013. 5. Plattner H. A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database/ed. by U. Çetintemel, S. Zdonik, D. Kossmann. — SIGMOD Conference. ACM, New York, 2009.

Евгений Николаевич Матвиенко Инженер I категории отдела бизнес-решений управления информационных технологий ОАО «Сургутнефтегаз», аспирант Сургутского государственного университета по специальности 05.13.01 «Системный анализ, управление и обработка информации». Направление научной работы — системы оперативного принятия управленческих решений на базе транзакционных данных в концепте Real-Time Enterprise 2.0.

Е.Н. МАТВИЕНКО

РЕШЕНИЕ АНАЛИТИЧЕСКИХ ЗАДАЧ С ИСПОЛЬЗОВАНИЕМ SAP HANA

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

Real-Time Enterprise 2.0

ВВЕДЕНИЕ Для любого бизнеса актуальна задача эффективного использования операционных данных, накапливаемых в транзакционной системе. Анализ текущих и исторических данных о состоянии организации позволяет руководителям принимать обоснованные, более качественные решения. На предприятиях используются различные способы получения аналитических отчетов. В данной работе рассмотрены следующие подходы к решению этой задачи: реализация аналитического отчета в транзакционной системе, реализация витрины данных, реализация корпоративного хранилища данных. Для каждого подхода сначала приводится схема решения с использованием традиционной СУБД, а затем описывается архитектура решения с использованием платформы SAP HANA. Также в начале каждого раздела приведены определения и характеристики, которые не претендуют на исчерпывающее описание, но подчеркивают значимые для дальнейшего изложения моменты. Несколько слов о SAP HANA. Упрощенно, это реляционная СУБД, разработанная компанией SAP, особенность которой — размещение базы данных в оперативной памяти, благодаря чему достигается высокая скорость выполнения запросов на извлечение данных. Если говорить точнее, в настоящий момент SAP HANA представляет собой многофункциональную платформу, включающую СУБД, богатый функционал для обработки и преобразования данных, сервер приложений, несколько языков программирования и множество других инструментов [1].

АНАЛИТИЧЕСКИЙ ОТЧЕТ В ТРАНЗАКЦИОННОЙ СИСТЕМЕ Транзакционная система (OLTP-система) — система, предназначенная для ввода и структурированного хранения информации об операционной деятельности предприятия. Основные операции — добавление, изменение и удаление отдельных записей в БД. Схема БД обычно нормализована. Для сохранения производительности исторические данные с определенной периодичностью перемещаются в архив и удаляются из БД транзакционной системы. Итак, аналитический отчет может быть реализован средствами транзакционной системы, и для этого разрабатывается новая программа с пользовательским интерфейсом (рис. 1). Программа последовательно извлекает данные из БД, обрабатывает их, снова извлекает данные из БД, снова их обрабатывает. После необходимого количества итераций она размещает полученные данные в нужных частях экрана и отправляет результат пользователю. К плюсам такого подхода можно отнести то, что обычно разработка нового отчета в транзакционной системе не занимает много времени. Также аналитика в этом случае строится на актуальных данных, а не на устаревших, бывших актуальными час, день или неделю назад, что тоже является достоинством подхода. Однако при таком способе реализации речь может идти только о достаточ-

Е.Н. Матвиенко. Решение аналитических задач с использованием SAP HANA

Сервер приложений Z-отчет DB

1. Выборка 1 2. Обработка 1 3. Выборка 2 4. Обработка 2 ... n. Вывод результатов

Клиент

Рис. 1. Аналитический отчет в транзакционной системе

но простой аналитике. Выполнение аналитических запросов на транзакционных данных требует соединения множества реляционных таблиц, извлечения большого количества записей и выполнения процедур агрегации данных. Более-менее сложный отчет потребует значительного времени для того, чтобы сформироваться в транзакционной системе, и параллельно создаст существенную нагрузку на сервер СУБД и сервер приложений, вследствие чего снизится эффективность обработки основных транзакционных запросов, что, разумеется, создаст неудобства для конечных пользователей. Недостатком подхода является и отсутствие гибкости — отчет решает строго определенный, узкий круг задач, и когда возникнет необходимость в новом отчете, потребуется разработать новую программу. Еще один недостаток — источником данных для аналитического отчета может быть только БД транзакционной системы, в которой он реализуется, т. е. данные из внешних систем не могут быть использованы в отчете напрямую. Использование SAP HANA в качестве СУБД (рис. 2) способно ускорить процесс извлечения данных из БД. Но так как обработка данных по-прежнему выполняется на сервере приложений, принципиальных изменений производительности не будет. Сервер приложений Z-отчет HANA

1. Выборка 1 2. Обработка 1 3. Выборка 2 4. Обработка 2 ... n. Вывод результатов

Клиент Рис. 2. Аналитический отчет в транзакционной системе: SAP HANA как СУБД

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

Real-Time Enterprise 2.0

SAP HANA Сервер приложений

Рис. 3. Аналитический отчет в транзакционной системе: хранимая процедура в SAP HANA

Z-хранимая процедура

Z-отчет

1. Выборка 1 2. Обработка 1 3. Выборка 2 4. Обработка 2 ... n. Возврат данных

1. Вызов ХП 2. Вывод результатов

Клиент

Для того чтобы отчет формировался быстро, нужно перенести логику обработки данных на уровень SAP HANA, реализовав соответствующую хранимую процедуру (рис. 3). Программа в транзакционной системе лишь вызывает хранимую процедуру, получает от нее результирующий набор данных, расставляет данные в нужные места формы и возвращает отчет пользователю [2]. Нагрузка на сервер приложений в этом случае окажется несущественной, а за счет технологических возможностей SAP HANA выборка и обработка данных будут выполняться быстро. Очевидно, что такая схема применима только в случае, если транзакционная сиSAP HANA Сервер приложений Z-хранимая процедура

Рис. 4. Аналитический отчет в транзакционной системе: хранимая процедура в SAP HANA + репликация из традиционной СУБД

1. Выборка 1 2. Обработка 1 3. Выборка 2 4. Обработка 2 ... n. Возврат данных

SAP SLT

Z-отчет 1. Вызов ХП 2. Вывод результатов

DBDB

Клиент

Е.Н. Матвиенко. Решение аналитических задач с использованием SAP HANA

стема осуществляет чтение и запись данных в БД, находящуюся под управлением SAP HANA. Это не всегда быстро реализуемо. Тогда возможна альтернативная схема. Транзакционная система продолжает использовать традиционную СУБД, но дополнительно настраивается соединение транзакционной системы с SAP HANA; также настраивается (например, с помощью инструмента SAP SLT) репликация данных из традиционной БД в SAP HANA в режиме реального времени для использования аналитическими отчетами (рис. 4). Программа, формирующая аналитический отчет, как и в предыдущей схеме, вызывает хранимую процедуру в SAP HANA и получает от нее результирующий набор данных, который остается лишь предъявить пользователю [2]. Достоинства этой и предыдущей схемы совпадают. Недостатки, такие как узкий круг решаемых задач и единственный источник данных, также свойственны рассматриваемой схеме, но они относятся к недостаткам выбранного подхода, а не конкретной схемы. В следующем разделе рассматривается другой подход к получению аналитических отчетов, у которого указанные недостатки отсутствуют. Таким образом, SAP HANA позволяет реализовывать аналитические отчеты со сложными алгоритмами обработки данных, не создающие существенной нагрузки на транзакционную систему, предоставляющие наиболее актуальную информацию и характеризуемые коротким периодом разработки.

ВИТРИНА ДАННЫХ Витрина данных (Data Mart) — это специализированная база данных, предназначенная для построения отчетов и бизнес-анализа. Характеризуется тем, что: предметно-ориентирована, т. е. содержит данные из одной предметной области, соответствующие одному из направлений деятельности компании; интегрирует данные из нескольких источников; строится на основе многомерной модели данных; в целях увеличения скорости выполнения аналитических запросов данные обычно хранятся в денормализованном виде и с определенной степенью агрегации [3]. Приложения BI (Business Intelligence) — это класс программ, которые предоставляют инструменты для получения данных из БД, анализа извлеченных данных и построения отчетов. ETL (Extract, Transform, Load) — это процесс последовательного извлечения данных из источников, их очистки, трансформации и загрузки в целевую БД. Так же называют класс систем, предоставляющих описанную функциональность. Многомерная модель данных — это способ хранения и представления данных, хорошо подходящий для целей бизнес-анализа и построения отчетов (рис. 5). Ее реализацию в реляционной БД обычно называют схемой «звезда». Состоит из таблицы фактов и таблиц измерений. Таблица фактов содержит меры, т. е. количественные по-

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

Real-Time Enterprise 2.0

D_DATE

D_PRODUCT

PK_DATE DATE DAY_OF_WEEK DAY_OF_MONTH MONTH YEAR IS_HOLIDAY FISICAL_MONTH

D_SALES FK_DATE FK_PRODUCT FK_STORE FK_CASHIER FK_PAYMENT_METHOD QUANTITY PRICE DOLLAR_AMOUNT

D_STORE

Рис. 5. Многомерная модель данных

PK_STORE NAME STREET CITY COUNTRY

PK_PRODUCT DESCRIPTION SUBCATEGORY CATEGORY D_CASHIER PK_CASHIER NAME SURNAME BIRTH_DATE

D_PAYMENT_METHOD PK_PAYMENT_METHOD DESCRIPTION GROUP

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

WEB DBDB

CRM Рис. 6. Витрина данных

ETL

Приложения BI

Е.Н. Матвиенко. Решение аналитических задач с использованием SAP HANA

WEB SAP HANA

ERP

CRM

ETL

Приложения BI

Рис. 7. Витрина данных: БД в SAP HANA

с многомерной моделью данных в БД. Поскольку ETL-процесс на этапе выгрузки данных создает значительную нагрузку на системы-источники, модули ETL запускаются с определенной периодичностью: один раз в час, один раз в сутки, иногда — один раз в неделю. Бизнес-пользователь получает доступ к данным посредством приложений BI. Грамотно спроектированная витрина данных, интегрирующая данные из нескольких источников и представляющая их в подходящей форме, предоставляет возможность решать широкий круг задач по анализу операционных данных предприятия. Другими словами, на основе одной витрины данных можно построить большое количество различных аналитических отчетов. А с помощью современных приложений BI бизнес-пользователь может формировать отчеты самостоятельно, не прибегая к помощи программистов. С другой стороны, поскольку ETL-процесс запускается с определенной периодичностью и занимает продолжительное время, витрина данных предоставляет не самые актуальные данные, а те, которые были актуальны часом, днем или неделей ранее. Кроме того, как уже упоминалось, данные хранятся в витрине данных в агрегированном виде, что ограничивает уровень детализации анализа. Если в качестве СУБД используется высокопроизводительная SAP HANA (рис. 7), становится ненужным выполнение агрегации в модулях ETL, и бизнес-пользователь получает возможность работать с детализированными данными. Но для того, чтобы пользователь мог проводить анализ текущих (актуальных) транзакционных данных, необходимо избавиться от медленного процесса ETL и вместо него использовать информационные представления данных SAP HANA. Информационное представление данных (View) SAP HANA — это виртуальная таблица, содержимое которой вычисляется динамически на основании данных, находящихся в реальных таблицах, и алгоритмов преобразования данных, определенных при создании представления данных. Другими словами, при создании представления данных в SAP HANA определяются три аспекта:

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

Real-Time Enterprise 2.0

SAP HANA

WEB ETL

Витрина данных

Рис. 8. Real-time витрина данных

SAP система

SAP SLT

Не SAP система

SAP SRS

Приложения BI

1) набор таблиц-источников и представлений-источников, откуда будут браться данные; 2) алгоритм извлечения и преобразования данных из источников; 3) формат таблицы, в виде которой данные будут возвращаться. Алгоритмы преобразования данных и таблицы-источники инкапсулированы в представлении данных, то есть для того, кто делает запрос, представление данных выглядит как обычная таблица. Алгоритмы преобразования данных могут быть описаны на внутреннем для SAP HANA языке программирования, и могут быть сколь угодно сложными. Соответственно, с помощью представлений данных можно реализовать множественные уровни абстракции, создавая сложные модели данных, в том числе многомерные. Вкратце отметим, что в SAP HANA существует несколько видов информационного представления данных, каждый из которых имеет свои достоинства, недостатки и подходящие случаи применения. На рис. 8 изображена схема real-time витрины данных, которая предоставляет аналитическую информацию, рассчитываемую на основе детализированных транзакционных данных в режиме реального времени. Справочные и какие-либо дополнительные данные из плоских файлов и вебсервисов загружаются в SAP HANA при помощи традиционного ETL с определенной периодичностью. Это вполне допустимо, поскольку обычно такие данные не характеризуются большими объемами, частыми изменениями и сложными связями, соответственно алгоритмы ETL для таких случаев достаточно просты. Транзакционные данные реплицируются в SAP HANA из систем-источников один к одному, в режиме реального времени. Для настройки репликации данных из SAPсистем используется инструмент SAP SLT, для не-SAP систем — инструмент SAP SRS. Очевидно, что если транзакционная система в качестве основной БД использует БД под управлением SAP HANA, настраивать для нее репликацию не нужно.

Е.Н. Матвиенко. Решение аналитических задач с использованием SAP HANA

В SAP HANA реализуется виртуальная витрина данных, которая обычно состоит из нескольких слоев представлений данных, образующих иерархию. Источником данных для представлений первого слоя, создающих абстракцию, например, на уровне технических объектов учетной системы, являются физические таблицы SAP HANA. Следующий слой использует в качестве источников данных как физические таблицы, так и представления первого уровня, формируя, например, уровень бизнес-объектов. Третий слой может быть представлен моделями таблиц фактов, которые используют в качестве измерений бизнес-объекты из второго уровня. Возможны и другие варианты деления представлений на уровни, с различным количеством логических слоев, но суть заключается в том, что каждый уровень отвечает за определенную часть логики преобразования данных. Таким образом, когда бизнес-пользователь с помощью приложений BI делает запрос к многомерной модели данных, реализованной в SAP HANA, запрос проходит путь от представления данных верхнего уровня, через представления данных нижележащих уровней, пока не спустится до уровня физических таблиц. Из последних извлекаются необходимые данные, которые затем проходят весь путь преобразований и возвращаются бизнес-пользователю. Поскольку технические возможности SAP HANA позволяют выполнять такой вид запросов быстро, и так как репликация из систем-источников в физические таблицы происходит в режиме реального времени, бизнес-пользователь практически мгновенно получает в аналитическом отчете актуальные данные. Не данные по состоянию на вчерашний день, или даже какими они были час назад, а те данные, которые содержатся в учетной системе в текущий момент времени. Стоит отметить, что от проектировщиков и программистов, реализующих виртуальную real-time витрину данных, требуется хорошее знание платформы SAP HANA, так как для того, чтобы извлечение данных происходило быстро, при разработке необходимо учитывать множество технических особенностей. Витрина данных, спроектированная и реализованная при активном взаимодействии с бизнес-пользователями, оказывает значительную информационную поддержку в процессе принятия решений, предоставляя разностороннюю аналитику. Но витрина данных обслуживает только один бизнес-процесс, либо одно организационное подразделение (отдел) предприятия. Соответственно, для другого отдела создается отдельный набор витрин данных, для третьего — еще набор витрин данных и т. д. Причем друг с другом эти витрины данных обычно никак не связаны, поэтому рано или поздно на предприятии возникают следующие проблемы: суммы в отчетах отделов не согласуются друг с другом; одна и та же сущность называется в разных отделах по-разному; логика преобразования данных, выполняемая при формировании витрин данных, дублируется в витринах данных разных отделов (например, покупатель, продавец, материал, счет главной книги обычно присутствуют во многих витринах данных); наконец, поддержка множества независимых витрин данных сложна и требует больших временных затрат. На решение этих проблем направлен подход, заключающийся в создании на предприятии корпоративного хранилища данных.

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

Real-Time Enterprise 2.0

Транзакционные системы-источники

DBDB Многомерные модели

Приложения BI

Система ETL Рис. 9. Архитектура корпоративного хранилища данных Ральфа Кимболла

Корпоративная шина измерений

КОРПОРАТИВНОЕ ХРАНИЛИЩЕ ДАННЫХ Корпоративное хранилище данных (Data Warehouse) — это также база данных, используемая для анализа данных и построения отчетов, но которая, в отличие от витрины данных, содержит консолидированный, согласованный набор данных из всех информационных источников предприятия. Также корпоративное хранилище данных характеризуется следующим: служит для поддержки принятия решений; содержит как атомарные, так и агрегированные данные; содержит как исторические, так и текущие данные; данные не изменяются пользователями; данные загружаются в хранилище с определенной периодичностью; объединяет данные из множества предметных областей. На рис. 9 изображена классическая архитектура построения корпоративного хранилища данных, предложенная Ральфом Кимболлом. Ядром этой архитектуры является система ETL. Консолидация данных осуществляется за счет использования так называемой корпоративной шины измерений, т. е. определенного набора согласованных измерений, используемых многомерными моделями предприятия (подробнее см. [4]). Опять же, недостатком архитектуры является невозможность получить аналитику над наиболее «свежими» данными учетной системы вследствие временных задержек, создаваемых системой ETL. При использовании SAP HANA как платформы для построения корпоративного хранилища данных возможно реализовать корпоративную шину измерений с помощью информационных представлений данных (рис. 10). Многомерные модели данных, которые также реализуются с помощью представлений данных, при такой схеме используют измерения из корпоративной шины. Таким образом, SAP HANA

Е.Н. Матвиенко. Решение аналитических задач с использованием SAP HANA

SAP HANA

WEB ETL

SAP система

SAP SLT

Не-SAP система

SAP SRS

БД

Многомерные модели

Приложения BI

Корпоративная шина измерений

SDA

Рис. 10. Корпоративное хранилище данных с использованием SAP HANA

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

ЗАКЛЮЧЕНИЕ Высокая производительность программно-аппаратного комплекса SAP HANA позволяет получать сложную, детализированную бизнес-аналитику непосредственно на транзакционных данных в режиме реального времени, тем самым открывая новые возможности в области систем бизнес-аналитики и систем поддержки принятия решений в целом.

ЛИТЕРАТУРА 1. Berg B., Silvia P. SAP HANA: An Introduction. — SAP Press, 2012. 2. SAP HANA System Landscape Guide [Электронный ресурс]. — SAP AG, 2013. — http://www.saphana.com/docs/DOC‑4385. 3. Лисянский К. Архитектурные решения и моделирование хранилищ и витрин данных [Электронный ресурс]. — http://www.osp.ru/cio/2002/03/172076/. 4. Kimball R., Ross M. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, Third Edition. — John Wiley & Sons, Inc., 2013.

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

Real-Time Enterprise 2.0

Ринат Дамирович Гимранов Начальник управления информационных технологий ОАО «Сургутнефтегаз», заведующий базовой кафедрой ОАО «Сургутнефтегаз» в Сургутском государственном университете, преподает магистрантам курс «Общество и информатизация». Автор ряда публикаций в научных журналах и ИТ-изданиях по тематике внедрения ИТ, СУБД in-memory, предприятия реального времени, архитектуры предприятия и управления данными.

REAL-TIME ENTERPRISE 2.0. ИЗМЕНЕНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ ПРИ РЕАЛИЗАЦИИ ТЕХНОЛОГИИ IN-MEMORY DATA MANAGEMENT

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

Real-Time Enterprise 2.0

Полнота данных и детализация (уровень агрегации)

спользуемые сегодня крупными предприятиями информационные системы сложны и многокомпонентны. Они содержат системы учета, хранилища данных, аналитические и вспомогательные системы. Сложность архитектуры и необходимость для систем обмениваться значительными объемами данных приучили наших бизнес-пользователей при принятии управленческих решений использовать устаревшую информацию. Практически все аналитические системы оперируют данными прошлых суток и еще более старыми. При необходимости обеспечить более оперативную информацию в системах принятия решений, мы вынуждены идти на определенные упрощения, агрегации, но даже в этом случае «кладем на стол» менеджеров информацию из прошлого — например, часовой давности. Причем стоимость таких решений гиперболически возрастает с приближением к времени реального события. Можно говорить об определенном технологическом барьере, обусловленном текущими особенностями корпоративных информационных систем (рис. 1). Попытки качественных улучшений в приближении к реальному времени в основном связывали с усовершенствованием аппаратной части. Так, при появлении конвергентных аппаратных решений в начале XXI века Gartner предложил определение предприятия, управляемого в реальном времени (real-time enterprise), как “an enterprise that competes by using up-to-date information to progressively remove delays to the management and execution of its critical business processes”. Наличие

Обходные пути

Сущест вую щи ет ех но л

ИТ-решение

ния ниче гра ео ки ес ич ог

Рис. 1. Событие

Р.Д. Гимранов. Real-Time Enterprise 2.0. Изменения корпоративных информационных систем при реализации технологии in-memory data management

Полнота данных и детализация (уровень агрегации)

2. 0 e ris

rp te

Re a

l-T i

До

ст

иж ен ие

це л

ИТ-решение

Рис. 2. Событие

в определении характеристики последовательного исключения задержек обусловлено ограничениями, архитектурными и функциональными, со стороны СУБД. Причем Gartner отмечал, что приближение к реальному времени асимптотическое. Современные требования к информационным системам по обработке больших массивов информации и потоков событий, проведению неструктурированного поиска, поддержке принятия решений не могут быть в полной мере реализованы на реляционной СУБД, которая с 1970‑х годов и до сегодняшнего дня положена в основу практически любой информационной системы [1]. По прогнозу М. Стоунбрейкера и других ученых на смену реляционной СУБД на дисках придут разнообразные решения, специализированные для конкретных задач. Одно из таких решений — поколоночная СУБД, размещенная в оперативной памяти сервера. Концептуальный подход и прототип были представлены в 2007 году [2], в 2008 году подход был расширен дополнительными технологическими находками [3] и в 2009 году реализован в первой коммерческой СУБД in-memory SAP HANA [4]. С тех пор, с той или иной степенью успешности, этот подход реализуется в решениях всех крупных поставщиков СУБД — Oracle, IBM, Microsoft. Именно вследствие появления нового «полностью переписанного» продукта можно утверждать, что технологические решения, заложенные в in-memory data management, предоставляют возможность строить информационные системы, которые принципиально по-другому работают с потоками и объемами информации.

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

Real-Time Enterprise 2.0

Старые технологические ограничения преодолены, и теперь предприятия могут управлять своими бизнес-процессами в реальном времени (рис. 2). Осуществление инновации стало возможным, как и десятилетием ранее, благодаря достижениям производителей аппаратного обеспечения — существенному увеличению объема оперативной памяти серверов и снижению ее стоимости, а также появлению многоядерных процессоров, обеспечивающих сверхбыстрые вычисления с использованием большого объема оперативной памяти. Основные технологические решения, положенные в основу новой СУБД, — поколоночное хранение, сжатие, распараллеливание, буферизация изменений. Именно они позволили повысить на порядки скорость обработки данных, уменьшить объемы БД, получить новые возможности. На уровне структуры данных стало возможным существенное упрощение за счет исключения промежуточных агрегатов, фактов, витрин, индексов, а также благодаря изменению подходов к количеству и структуре таблиц с особенностями поколоночного хранения. На уровне аппаратного обеспечения снижаются требования к системе хранения данных, поскольку диски (а теперь уже, как правило, флеш-память) используются лишь для резервного хранения, и только в режиме записи. На порядки возросшая скорость обработки позволяет решать прежние задачи на меньших по мощности вычислительных ресурсах. ОАО «Сургутнефтегаз» уже 3 года использует SAP HANA, и мы можем обоснованно подтвердить все теоретические и макетные предположения [5, 6]. Первое же реализованное в 2011 году продуктивное решение на базе SAP HANA позволило получать результаты (отчеты) о наличии и движении материальных ресурсов в 675 раз быстрее (16 секунд вместо 3 часов), а объемы хранимой информации снизились вчетверо. Впервые менеджерам среднего звена предоставлена возможность получить единый оперативный и исторический отчет, не устанавливая никаких ограничений на глубину и объем выборки (по складам, номенклатуре, датам и т. п.). Возможности новой СУБД сильно влияют на ИТ-архитектуру информационных систем. Так как нет более необходимости разделять транзакционную и аналитическую БД, можно исключить многие системы, а именно — хранилища данных, системы загрузки и трансформации (ETL — Extraction, Transformation, Loading), системы обработки цепочки сервисов и др. Архивные и исторические данные перемещаются из оперативной памяти на диски или флеш-память автоматически при понижении «температуры данных» — интегрального показателя изменяемости и использования. Таким образом, в наиболее эффективном применении in-memory можно реализовать функциональность корпоративной информационной системы в одной СУБД (рис. 3), а задачи, которые ранее решались с использованием отдельных баз данных, становятся сервисами уровня приложений. Однако основное значение перемен заключается не в снижении затрат и упрощении инфраструктуры, а в появлении новых возможностей. Так, в аналитических приложениях мы можем оперировать свежими данными непосредственно из транзакционной БД. Можем строить аналитические запросы тысячекратно более сложные, чем раньше. Значит, потенциально in-memory открывает широкие

Транзакционные системы

Сервер приложений Хранилища данных ETL-системы

СУБД

Сервер BI

Сервер обработки

СУБД

Сервер приложений

Сервисы транзакционной бизнес-логики Сервисы BI

СУБД

Сервисы...

СУБД

Сервер BI

СУБД

Сервер приложений

СУБД

Витрины данных

СУБД

Сервер приложений

... СУБД

СУБД

Вспомогательные и интерфейсные системы

СУБД

Рис. 3. Свертывание инфраструктуры

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

Real-Time Enterprise 2.0

возможности для появления нового поколения систем поддержки принятия решений. Таким образом, становится возможным преодолеть текущий технологический барьер и построить информационную систему предприятия для управления в режиме реального времени, которая позволит принимать управленческие решения на основе актуальной информации не только на оперативном, но и на стратегическом уровне. Можно определить такую информационную систему как Real-Time Enterprise 2.0, дополнив определение Gartner 2002 года: “An enterprise that competes by using up-to-date information to progressively completely remove delays to the management and execution of its critical business processes”. Корпоративные информационные системы сложны и неповоротливы, поэтому нам предстоит длительный путь повышения их эффективности с использованием СУБД in-memory. М. Стоунбрейкер с коллегами, проводя аналогию с периодом появления реляционной СУБД, писал: «Период 1970–1985 годов был временем интенсивных дебатов, множества идей и значительного переворота. Мы предсказываем, что следующие 15 лет будут такими же» [2]. В заключение отмечу, что in-memory data management как инновационная технология, далекая от зрелости, открывает возможности для решения актуальных сегодня задач импортозамещения и, уверен, при проведении организованных совместных работ позволит создавать мощные конкурентные решения на российском программном обеспечении — от операционной системы и СУБД до прикладных и интерфейсных систем.

ЛИТЕРАТУРА 1. Stonebraker M., Çetintemel U. “One Size Fits All”: An Idea Whose Time Has Come and Gone. 2. Stonebraker M., Madden S., Abadi D. J., Harizopoulos S. et al. The End of an Architectural Era (It’s Time for a Complete Rewrite) // VLDB. 2007. No. 7. 3. Plattner H. A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database // SIGMOD’09. 4. Plattner H., Zeier A. In-Memory Data Management. — Springer, 2011. 5. Surgutneftegas Takes HANA for a Test Drive. SAP insider profiles, 2012. 6. Gimranov R. Customer Report: Surgutneftegas Deploys SAP HANA to Increase the Energy Efficiency of Thousands of Operating Facilities in Real Time // SAP Service and Support. — SAP Press, 2014. — P. 44–46. 7. Гимранов Р. Д., Агиевич В. А. Обеспечение достоверной информации в информационной системе крупного предприятия на основе архитектурного подхода // Нефтяное хозяйство. — 2013. — 4.

Владимир Андреевич Поборцев Старший директор AGS, SAP SE.

SAP HANA В КОНТЕКСТЕ ТЕНДЕНЦИЙ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

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

Real-Time Enterprise 2.0

начение информационных технологий постоянно увеличивается, ИТ оказывают огромное влияние практически на все аспекты и области нашей жизни и стали ее неотъемлемой частью. Это влияние будет расти все больше и больше с развитием уровня имеющихся и появлением новых технологий. Рассмотрим, в каких направлениях пойдет развитие ИТ в ближайшее время. При этом я буду опираться на уже сформировавшиеся тенденции и исходить из имеющихся ныне на рынке технологий. Хочу сразу оговориться: данные рассуждения носят чисто субъективный характер и представляют мое личное видение этого вопроса. Первая тенденция, которая прослеживается уже сейчас, это отход от разработки сложных платформ в области бизнес-приложений. До настоящего времени крупные производители программного обеспечения предлагали своим клиентам сложные программы-конструкторы с обширным набором инструментов. Упор делался на универсальность. Приобретая такое программное обеспечение, пользователь получал возможность настроить его под свои нужды индивидуально, для выполнения задач, входящих в зону его ответственности. Конечно же, в большинстве случаев каждый отдельный пользователь работал лишь с малой частью функциональности такой программы и вряд ли когда-либо задействовал все ее возможности. Производители — создатели таких программ, как правило, содержат в штате целые команды экспертов для изучения рыночного спроса. Если речь идет о бизнес-приложениях, то изучаются отдельные отрасли экономики, учитываются региональные требования и другие аспекты. В результате появляется программа-конструктор, уровень универсальности которой исключительно высок. Конечно же, как всякий конструктор, такая программа требует преднастройки, порой весьма затратной. Эту рыночную нишу уже несколько десятилетий весьма успешно занимают консалтинговые фирмы, оказывающие клиентам услуги по настройке таких программ. При этом всегда находятся клиенты, которым даже в самом универсальном конструкторе не хватает преднастроенных решений. К тому же на этапе жизненного цикла у пользователей постоянно возникают новые требования, диктуемые бизнесом, внешней средой и другими факторами. Производители программного обеспечения регулярно выпускают заплатки, расширяя функциональные возможности своих продуктов. Однако многое по понятным причинам остается за бортом так называемого стандартного пакета. Такие требования квалифицируются как индивидуальные, и для их реализации часто требуется дополнительная разработка. Именно это становится наиболее затратной статьей расходов большинства клиентов на всем протяжении жизненного цикла программного обеспечения. Еще одним недостатком сложных программ-конструкторов, как правило, является, как это ни странно звучит, недостаточная гибкость. Ограничения платформенного характера или связанные с техническим дизайном зачастую осложняют реализацию индивидуальных требований пользователей ПО. Речь идет в первую очередь об эргономичности, удобстве и простоте. Зачастую всё это приносят в жертву универсальности и стандартности. А ведь именно удовлетворенность пользова-

В.А. Поборцев. SAP HANA в контексте тенденций развития информационных технологий

телей, работающих с программой ежедневно, является мерилом качества и успеха производителей ПО. Сейчас, с появлением апплетов, ситуация кардинально изменилась. На пользовательских устройствах появились апплеты — простые приложения с ограниченным объемом функциональности, но чрезвычайно удобные в повседневном использовании. С каждым днем их становится больше, при этом многие апплеты практически полностью дублируют функциональность друг друга и различаются лишь в части пользовательского интерфейса. Происходит нечто наподобие естественного отбора: неудачные апплеты пользователи отсеивают. Необходимым условием для развития апплетов является универсальная платформа, управляющая и предоставляющая данные по принципу единого источника правды (single source of truth). Ведущие производители ПО, к которым относится и SAP, достаточно давно идут по этому пути, и платформы такого рода уже доступны. SAP предлагает клиентам платформу HANA, созданную на базе технологии inmemory. Переход от сложных программ-конструкторов к апплетам несет с собой также кардинальные изменения в экосистеме, существующей вокруг информационных технологий. Огромное количество данных, в том числе не агрегированных, поступающих из разных источников в режиме реального времени, открывает новые горизонты, заставляя пересмотреть представление о реляционной модели базы данных как индустриальном стандарте. Но одновременно появляются и дополнительные пожелания к программистам. Очевидно, что все более востребованными становятся навыки по управлению большими потоками данных, умение выбирать из общего потока нужные данные и правильно преподносить их пользователю посредством удобного и эргоноямичного интерфейса. Спрос же на специалистов по настройке сложных программ-конструкторов будет постепенно снижаться. Эти изменения окажутся достаточно масштабными и затронут целый спектр ИТ-компаний, специализирующихся на предоставлении такого рода услуг. Еще одна ожидаемая тенденция — получение прибыли от управления большими потоками и объемами данных. Словосочетание «большие объемы данных (big data)» все чаще встречается в прессе. Сегодняшний уровень развития технологий позволяет создавать и накапливать действительно большие объемы данных. В первую очередь речь идет о разного рода датчиках, которые могут работать круглый год 7 дней в неделю 24 часа в сутки в режиме реального времени и генерировать огромные массивы данных. Сам по себе этот факт еще не повод говорить о выгоде для бизнеса и о конкурентных преимуществах для компании, которая данными владеет. У компании не увеличится количество клиентов, не вырастут продажи лишь из-за того, что она владеет большими массивами данных. Но как только та или иная компания поймет, что именно с этими данными надо делать для получения выгоды, как они сразу превратятся в капитал. Некоторые производители автомобилей уже сейчас оснащают их электронными устройствами, непрерывно запоминающими данные телеметрии с датчиков агрегатов автомобиля, временные показатели и данные геолокации. Подспудно каждый

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

Real-Time Enterprise 2.0

понимает, что иметь эти данные полезно. Но ответить на вопрос, что же с ними надо делать, чтобы получать выгоду, пока мало кто может. На сегодняшний день эти данные если и используются в бизнесе, то не в полной мере. Очевидно, что тот, кто первым научится полноценно их использовать, кто сумеет создать на этой основе бизнес-модель, получит колоссальные конкурентные преимущества и откроет новые возможности ведения бизнеса. На эту тему уже сейчас идут достаточно активные дискуссии. Я уверен, что они продолжатся и в будущем. Следующую тенденцию можно обозначить как реальную мощь огромных массивов данных, которая будет способна заменить людские ресурсы, экспертов в тех или иных областях. Каждый, наверное, слышал о шахматных компьютерах. Долгое время они совершенствовались. И если раньше у человека был реальный шанс обыграть такой компьютер, то теперь эта задача стала практически не по силам ни одному гроссмейстеру. Значит ли это, что ученые создали машину, обладающую настолько развитым интеллектом, чтобы понимать все нюансы игры в шахматы как таковой? Отнюдь нет. Компьютер всего лишь делает анализ всех записанных за многие годы шахматных партий и выбирает оптимальный ход на основе неких хитроумных алгоритмов. Теоретически, такую же работу компьютер мог выполнять и десять, и двадцать лет назад. Но если раньше на то, чтобы просчитать оптимальный ход, уходили десятки часов, то сегодняшний уровень развития технологии позволяет делать это за секунды, практически в режиме онлайн. Вот еще один пример реальной мощи огромных объемов данных. В последние десятилетия ученые вложили много усилий в то, чтобы в полной мере реализовать машинный перевод с одного языка на другой. При этом за основу бралась научная сторона, язык рассматривался с точки зрения его лингвистических характеристик. Ученые пытались научить машину «человеческому» языку. Были созданы комплексные лингвистические модели, и даже достигнут некоторый успех. Но как-то одному программисту пришла в голову простая идея. Он предположил, что кто-то когдато уже перевел каждое известное человечеству слово на тот или иной язык, и все варианты переводов доступны в различных уголках всемирной сети Интернет. Поэтому вместо того, чтобы создавать сложные лингвистические модели, достаточно поискать в Интернете уже доступные варианты перевода, сделанные кем-то ранее. Обработав результаты поиска по определенному алгоритму, компьютер выдает вполне приемлемый переведенный текст. Именно по такому принципу работает Google Translate. При этом компьютер ничего не знает о языке, а лишь выполняет поиск и обрабатывает его результаты по определенным правилам. Конечно же, эта идея не могла быть реализована на базе нескольких десятков интернет-страниц. Но когда речь идет о миллиардах страниц, все начинает выглядеть совсем иначе. Оба примера* наглядно показывают, что огромные массивы данных представляют собой реальную мощь. Машина пока что не способна заменить человека, его интеллект. Но в данном случае это и не требуется. Само по себе управление огромПримеры взяты из выступления доктора Штефана Зигга, SAP SE.

В.А. Поборцев. SAP HANA в контексте тенденций развития информационных технологий

ными объемами данных в короткие промежутки времени, что на сегодняшний день стало возможным благодаря развитию технологий, позволит в будущем если не заменить человека полностью в тех или иных профессиях, то предоставить ему существенную поддержку в процессе принятия решений. При этом речь идет, как правило, об экспертах высокого уровня и уникальных экспертизах. Умение предсказывать будущее — еще один тренд развития ИТ. Нет ничего более страшного для бизнеса, чем упущенные возможности, когда есть спрос на твой товар, а ты не можешь его удовлетворить. Практически все руководители компаний на вопрос, какую задачу они мечтают решить больше всего, в один голос утверждают, что им хотелось бы научиться предсказывать спрос на их товар. Они хотели бы иметь такую систему, которая могла бы предсказывать спрос на товар в определенное время и в определенном месте. Таким образом, они получили бы возможность оптимизировать закупки, производство, логистические цепочки и склады. Безусловно, это очень интересная область, и ведущие производители ПО должны сконцентрировать усилия на этом направлении. Следует отметить, что качество предсказаний напрямую зависит от качества и объема исходных данных. Причем большие объемы данных должны быть уникальными, то есть без ненужного дублирования. И, как уже было сказано ранее, поверх этих данных устанавливаются апплеты. Думаю, что одним из наиболее востребованных был бы апплет по предсказанию будущего спроса на товар. Но каким он будет, пока еще неизвестно. Ведь речь сегодня идет о тенденциях развития ИТ в будущем. Вообще, тема предсказания будущего намного шире, и она не ограничивается лишь предсказанием спроса на товар. Поставщики также могут удовлетворять наш спрос не безгранично — к примеру, если речь идет о продукции сельского хозяйства, где на урожай влияет множество факторов, в том числе погода. Система, умеющая предсказывать пределы объемов поставок сырья вашими поставщиками, тоже была бы востребована. Этот список можно продолжить. Давайте поговорим о частных данных пользователей. В последнее время мы часто слышим о всякого рода разоблачениях, о слежке, к примеру, со стороны Агентства национальной безопасности США. При этом мы испытываем неприятные ощущения, представляя, что и к нашим частным данным кто-то имеет доступ без нашего на то разрешения. Но, несмотря на это, вечером мы все равно садимся за компьютер, чтобы запостить свежую информацию и початиться в соцсети. Безусловно, частные данные подлежат защите. Но с другой стороны, можно также понять и компании, которые хотят использовать наши частные данные для того, чтобы делать нам индивидуальные предложения. Ведь сейчас маркетинг делит целевую аудиторию на сегменты и пытается адресовать отдельным сегментам те или иные товары и услуги. На это тратятся огромные средства, а эффект от такого подхода практически минимальный. Так, находя в почтовом ящике очередной проспект с рекламой страховки, мы не глядя бросаем его в урну. Но если бы компании имели возможность не делить целевую аудиторию на сегменты, а работать с отдельными людьми, то эффект был бы намного выше. К примеру, если бы страховая компания знала о том, что я вчера делал запрос в поисковике о страховании дома от пожа-

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

Real-Time Enterprise 2.0

ра, она могла бы выслать мне рекламный проспект с актуальными предложениями по страхованию недвижимости. Не исключено, что в таком случае я бы насторожился, удивившись, как много знает обо мне страховая фирма. Но возможно и то, что я не выкинул бы такой проспект не читая, а обратил бы на него пристальное внимание. Таким образом, налицо два взаимозависимых тренда. С одной стороны, это стремление сохранить приватность данных. С другой стороны, это стремление бизнеса перейти от сегментов к индивидуальному подходу к каждому клиенту. Эти тренды в будущем обязательно будут оказывать влияние на развитие ПО. Рассмотрим один из примеров развития в вышеуказанных направлениях. SAP HANA отличается от своих конкурентов с точки зрения ее технических характеристик, так как это (1) полностью реализованная в оперативной памяти база данных (2) с поиском по столбцам и (3) высоким уровнем параллельности. Эти три характеристики вместе уже достаточно уникально описывают HANA. Они хорошо задокументированы и описаны в литературе. Поэтому можно себе теоретически представить, что некая сильная команда разработчиков решит создать некий альтернативный продукт с такими же характеристиками. Трехуровневая информационная система состоит из серверов баз данных, серверов приложений и клиентского ПО. Именно так реализовывались практически все продукты SAP до появления HANA: ERP, CRM, SRM и другие. Рассмотрим пример. Пусть пользователю необходимо рассчитать конфигурации вариантов материала. Приложение делает запрос в базу данных, получает оттуда результат, обрабатывает его и форматирует для представления пользователю. Но на определенном этапе мы начинаем сталкиваться здесь с ограничениями. Если пользователь захочет рассчитать конфигурации вариантов сложного объекта, к примеру, целого автомобиля, в режиме онлайн, расчет будет делаться слишком долго. Объяснение здесь простое: для расчета конфигурации вариантов сложного объекта приложение запрашивает из базы огромное количество данных. И так как по законам физики чтение и передача этих данных занимают некое продолжительное время, весь процесс оказывается сильно растянут. «Данные к функциям» — до появления HANA все решения SAP работали именно таким образом. Данные извлекались из базы и предоставлялись различным функциям, таким как расчет конфигурации вариантов материала, расчет цены, любые отчеты FI и др. И в большинстве случаев причиной медленной работы функций было то, что они запрашивали слишком большое количество данных из базы. Каким же образом мы это изменили? Мы больше не доставляем данные к функциям, а наоборот, доставляем функции к данным. HANA, полностью реализованная в оперативной памяти база данных с поиском по столбцам и высоким уровнем параллельности, позволяет нам теперь это делать. Другими словами, мы заново определили границу между приложением и базой данных. Традиционные базы данных созданы под другие реалии. Аппаратные средства 40 лет назад, когда появились первые концепты традиционных баз данных, были совсем другими. Теперь, с использованием современных технологий и аппаратных средств, мы можем де-

В.А. Поборцев. SAP HANA в контексте тенденций развития информационных технологий

Любые приложения

SAP Business Suite

Any App Server

an BW ABAP App Server

SQL

MDX

Поддерживает различные устройства

JSON

Open Connectivity

Платформа SAP HANA SQL, SQL Script, JavaScript Пространственный

Поиск

Анализ текста

Хранимые процедуры и модели данных

Приложения и UI-сервисы

Библиотека бизнесфункций

Библиотека интеллектуального анализа

Службы базы данных

Движок планирования

Движок правил

Службы интеграции Транзакция

Неструктурированность

Компьютер

Hadoop

Режим реального времени

лать на уровне базы данных намного больше, чем прежде. Сервер стандартной конфигурации сегодня может иметь 16 процессоров (юнитов) по 15 ядер в каждом и управлять 12 терабайтами оперативной памяти. И это лишь один компьютер. А ведь мы теперь умеем распределять данные на несколько компьютеров (т. н. ноды). Если вдруг 12 терабайт будет недостаточно, можно просто добавить еще один, два, или даже двадцать таких компьютеров и распределить задачу между ними. Переопределив границу между уровнем приложений и уровнем базы данных, мы добавили в последнюю множество объектов и инструментов. Теперь это не только язык SQL, но и те функции, которые раньше были реализованы в приложении. Все функции работают с одними и теми же данными, но все это происходит в оперативной памяти. Мы можем выполнять поиск при помощи поисковой машины (search engine), у нас наконец-то появился планировщик (planning engine) прямо в базе данных, с помощью которого мы можем симулировать, например, расчет бюджета и многие другие операции. Основное отличие HANA от конкурентов — наличие всех библиотек (library)

Объекты

Другие приложения

Платформа SAP HANA.

SAP HANA Platform Converges Database, Data Processing and Application Platform Capabilities & Provides Libraries for Predictive, Planning, Text, Spatial, and Business Analytics to enable business to operate in realtime

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

Real-Time Enterprise 2.0

и машин (engine), представленных на рисунке в составе SAP HANA Platform. Причем список этот далеко не полный. Новая платформа позволяет теперь разрабатывать приложения намного быстрее и эффективнее, а также создавать такие приложения, которые раньше невозможно было даже представить. Мы только сейчас по-настоящему начинаем осознавать, с каким огромным потенциалом имеем дело.

ЛИТЕРАТУРА 1. Plattner H., Zeier A. In-Memory Data Management: An Inflection Point for Enterprise Applications. — Berlin: Springer, 2011. 2. Belzer J. Very Large Data Base Systems to Zero-Memory and Markov Information Source // Albert G. Holzman (Hrsg.): Encyclopedia of Computer Science and Technology, 14. — Marcel Dekker Inc., 1980. 3. Plattner H., Meinel Ch., Weinberg U. Design-Thinking. — München: mi-Wirtschaftsbuch, 2009. 4. Dokumentation zu SAP HANA. [Электронный документ]. — http://help.sap.com/ hana_platform. 5. SAP HANA als Entwicklungsplattform — Mehr als eine Datenbank. [Электронный документ] — http://entwickler.de/artikel/Mehr-als-eine-Datenbank‑166293. 6. SAP.info — Projekte und Neuigkeiten rund um SAP HANA. [Электронный документ] — http://de.news-sap.com/topics/sap-hana/.

Руперт Хольцбауэр (Rupert Holzbauer) Директор Центра компетенции SAP, директор глобального альянса с SAP в EMEA Hewlett-Packard (Director SAP Competence Center SAP Alliance Director EMEA Hewlett-Packard).

НОВЫЙ СТИЛЬ ИТ ДЛЯ SAP

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

Real-time Enterprise 2.0

Новые требования, предъявляемые к IT Технические • Перенос данных с жестких дисков в оперативную память • Серверы с огромной оперативной памятью (до 24 ТБ) • СХД нужны только для резервного копирования • Серверы и СХД объединяются в единое устройство • Высокая скорость доступа к СХД • Единая операционная система • Требуются новые подходы к организации высокой доступности и отказоустойчивости систем Операционные/организационные • Новая модель расчета • Сеть SAN больше не нужна • Новая модель лицензирования БД • Private/Enterprise Cloud

Концепция RealTime Enterprise на базе SAP HANA

SAP Suite on HANA Scale-up или Scale-out appliance для баз данных. Сервер приложений по прежнему требуется SAP BW on HANA Scale-up или Scale-out appliance SAP BWA Первый аppliance для ускорения. OLAP R/3, SAP ERP Классическая трехуровневая архитектура

омпании HP и SAP имеют давнюю (свыше 20 лет) историю партнерства. В 1989 году компания HP поставила SAP первую систему, когда SAP разрабатывала проект под кодовым именем «Гейдельберг», позднее названный R/3. Центр компетенции SAP в штаб-квартире SAP в Вальдорфе (Германия) был основан в 1990 году. В 1994‑м компания HP установила в продуктивную среду первую систему SAP R/3 на Windows NT. В 2011 году были поставлены первые системы для SAP HANA, которые назывались AppSystems для SAP HANA. В 2012 году компания HP поставила мировой рекорд в тесте EML (Enhanced Mixed Load, стандартный тест для SAP BW), который до сих пор не побит. К 2014 году компания HP поставила уже свыше тысячи специализированных комплексов для HANA, став мировым лидером по этому показателю. Предприятие реального времени на базе SAP HANA требует нового технического, и в то же время организационного мышления. В силу природы «вычислений в памяти» для SAP HANA требуются новые системы. Это касается не только оперативной памяти — задержки между серверами, системами хранения данных и в сети должны позволять работу в реальном времени. По этой причине системы для SAP HANA поставляются в виде специализированных комплексов. В специализированном комплексе СУБД, серверы, системы хранения данных и сетевое оборудование не разделены как прежде, а встроены в заранее сконфигурированную систему. Только при такой интеграции выпол-

Руперт Хольцбауэр. Новый стиль ИТ для SAP

няются требования к работе в реальном времени. Новая концепция специализированных комплексов радикально упрощает архитектуру систем для SAP HANA, но в то же время меняет требования к ИТ-инфраструктуре и ее эксплуатации. Прежние ИТ-подразделения, группы серверов, системы хранения и сети должны быть заменены подразделением специализированных комплексов. В реальности классический подход к организации ИТ, конечно же, не устарел одномоментно, но налицо новый тренд, который нельзя игнорировать. Специализированные комплексы реального времени для SAP HANA также открывают дорогу для других моделей использования SAP HANA. Публичные и частные облака упрощают использование SAP HANA в режиме подписки. SAP предлагает HANA в своем «корпоративном облаке HANA», но у HP также есть HANA по облачной модели — «HANA как услуга». Две системы семейства специализированных комплексов HP для SAP HANA покрывают все нужды, от очень скромных до наиболее амбициозных. Самая маленькая система ConvergedSystem 500 содержит узлы с 256 Гб, 512 Гб и 1 Тб оперативной памяти, и может объединяться в кластеры, включающие до 16 Тб памяти. ConvergedSystem 900 масштабируется еще лучше: до 32 Тб в горизонтально масштабируемом кластере и до 12 Тб в одной вертикально масштабируемой системе — все в едином пуле памяти. Отметим основные особенности ИТ-систем для «предприятия реального времени»: «вычисления в памяти» становятся стандартным решением у всех разработчиков СУБД; SAP является лидером со своим продуктом SAP HANA; SAP HANA для OLAP (OnLine Analytical Processing, аналитическая обработка в реальном времени) и OLTP (OnLine Transaction Processing, обработка транзакций в реальном времени) станет новым стандартом для пользователей SAP; стандартные ИТ-подразделения (серверов, систем хранения данных, сетей) претерпевают изменения; стандартизованные специализированные комплексы и облачная модель обеспечивают сокращение расходов.

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

Real-time Enterprise 2.0

Как уже сказано, компания HP установила свыше тысячи специализированных комплексов HANA для более чем 800 заказчиков. Благодаря большому количеству инсталляций компания HP получила уникальный опыт по внедрению SAP HANA. Это огромное преимущество, которого не имеют большинство других изготовителей. Например, свыше двадцати крупнейших компаний нефтегазовой отрасли используют SAP HANA на специализированных комплексах производства HP. Из их числа самая большая горизонтально масштабируемая продуктивная система используется одной голландской нефтяной компанией. Хотелось бы отметить следующие примеры внедрения: Suite на HANA — немецкий автопроизводитель; Suite на HANA — компания Kaeser Kompressoren; инсталляция с 16 ТБ памяти — голландская нефтяная компания; внедрение HANA у себя в компании HP. Первый пример — одна из первых инсталляций ERP на платформе HANA (или Suite на HANA). Заказчик начал мигрировать свою стандартную систему ERP на HANA, но решил сохранить часть уже имеющихся систем хранения. Инсталляция HANA была выполнена в виде так называемого «индивидуального ЦОДа», который позволяет использовать для специализированных комплексов HANA существующие системы хранения данных. Другой особенностью стало использование программного обеспечения VMware в продуктивной среде, что обычно не поддерживается компанией SAP. В этом случае компания SAP «узаконила» инсталляцию после детальных испытаний производительности. В целом внедрение заняло больше времени, чем обычно, из-за «индивидуального ЦОДа», но к настоящему моменту решение работает уже несколько месяцев. Заказчик обещает предоставить детальные результаты и поделиться опытом эксплуатации. В сумме внедрение заняло 10 месяцев. Следующий пример — немецкая компания Kaeser Kompressoren, мировой лидер в производстве промышленных компрессоров. Это внедрение также явилось важным пилотным проектом для SAP. Компания Kaeser Kompressoren хотела использовать разработанный специально для HANA модуль для ERP. С помощью этого модуля Kaeser может лучше управлять своими сервисными ресурсами для заказчиков. Тысячи датчиков в компрессорах посылают информацию о состоянии системы. Kaeser может запускать процедуры сопровождения у заказчика в реальном времени, не дожидаясь отказа системы. Это реальное конкурентное преимущество для компании Kaeser Kompressoren. Технически компании Kaeser Kompressoren требуются 12‑терабайтные системы HANA для запуска ERP на HANA в виртуализованной среде. Кроме того, компания решила заменить системы хранения NetApp на 3PAR производства HP. Системы ConvergedSystem 900 на 12 Тб ожидаются в октябре 2014 года. Еще один пример — самое крупное продуктивное внедрение BW на HANA в голландской нефтяной компании. Суммарно 48 ТБ данных BW обрабатываются системами HANA.  Вот лишь некоторые детали: комплекс для HANA с горизонтальным масштабированием (BW на HANA плюс Sidecar);

Руперт Хольцбауэр. Новый стиль ИТ для SAP

www.yodobashi.com HP лидирует с более чем 800 совместными проектами внедрения SAP HANA

ERS: три системы на HANA (6 Тб; 5,5 Tб; 5,5 Tб); GSAP: системы на HANA (16 Tб; 4,5 Тб; 4,5 Тб); UI: три системы на HANA (2 Тб; 2 Тб; 1,5 Тб). Но компания HP также использует HANA в собственной ИТ-среде. В течение уже длительного времени HP работает над новым поколением систем реального времени. Исследовательское подразделение HP — HP Labs — разрабатывает радикально новые подходы к высокомасштабируемым, высокопроизводительным инфраструктурам и аналитическим системам, необходимым для поддержки мира ЦОДов. Архитектура, реализующая такие подходы, получила кодовое название «Машина». «Машина» — это новое поколение вычислительных систем и аналитических методов для работы с «большими данными». Инфраструктура, которая требуется для сбора, обработки, хранения и анализа таких данных, требует революционных изменений в основах вычислений. Подразделение HP Labs использует электроны для вычислений, фотоны для передачи данных и ионы для их хранения. Мы рассчитываем, что первые прототипы для SAP HANA появятся в 2019 году.

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

Real-time Enterprise 2.0

Игорь Николаевич Холкин Мастер ТРИЗ, консультант BDO Unicon Business Solutions. Научные интересы в области ТРИЗ — Directed Evolution, SLCA.

ПРИМЕНЕНИЕ МЕТОДА DIRECTED EVOLUTION ДЛЯ АНАЛИЗА И ПРОГНОЗИРОВАНИЯ РАЗВИТИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (НА ПРИМЕРЕ ТЕХНОЛОГИИ IN-MEMORY DATA MANAGEMENT, IMDM)

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

Real-Time Enterprise 2.0

ВВЕДЕНИЕ Растущая потребность в инновациях в сфере ИТ нуждается в прогнозировании и интенсивном осмыслении тенденций развития информационных технологий и систем. Целью прогнозирования является минимизация потерь от внедрения «тупиковых» инженерных решений и максимизация доходности при «попадании в точку» — создании востребованной рынком высокоэффективной информационной системы. Настоящая статья имеет целью донести до аудитории возможности метода Directed Evolution как инструмента для анализа и поиска перспективных путей развития информационных систем; при этом имеется в виду целенаправленное повышение полезных характеристик систем для их лучшей реализации в секторе рынка бизнес-аналитики и поддержки принятия решений (Business Intelligence & Decision Support Systems).

«ИННОВАЦИОННЫЙ КПД» Ускоряющиеся темпы развития информационных технологий, усиление рыночной конкуренции, растущая потребность в инновациях для поддержания нужных темпов экономического роста определяют необходимость существенно повысить эффективность цикла «от идеи до рынка». В настоящее время эта эффективность очень мала: и в мире, и в России до внедрения доходит менее 1% разработок; «инновационный КПД» недопустимо низок. Как видно из рис. 1, за последние 50 лет в США из 125 разработок новых продуктов до рыночной реализации доходила только одна; «КПД» = 0,8%. В СССР, в период 1960–1980 годов, из 150 тысяч разработок до внедрения доходила только 1 тысяча. Сегодня в России дела обстоят не лучше — итоги деятельности организаций, призванных повысить эффективность инноваций (например, Роснано и Сколково), пока оцениваются как неудовлетворительные*, а в мировом рейтинге инновационной активности Россия занимает 51‑е место из 133 стран**. «Инновационный КПД» в уходящем постиндустриальном обществе был ниже, чем у паровоза. Сегодня, на этапе перехода к информационному обществу и экономике знаний, стало возможным повысить его до 40–60%. Каким образом?

ПРОБЛЕМА И РЕШЕНИЕ Создание информационной системы — всегда значительная инновация, со всеми присущими ей проблемами и задачами. По разным оценкам, при создании информационных систем от 30% до 60% проектов заканчиваются неудачей. Причем http://www.ach.gov.ru/userfiles/tree/201305rosnano-tree_files-fl‑755.pdf; http://www.ach.gov.ru/ru/news/archive/15022013/. ** The Global Competitiveness Report 2009–2010 (World Economic Forum). *

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

10 000

Эффективность менее 1%

3000 «сырых» идей 1000

Источник: Greg A. Stevens and James Burley, Research Technology Management, Industrial Research Institute, USA, 2003

Количество идей

300 одобренных идей 125 проектных решений (ОКР) 100

9 опытных прототипов 4 главных разработки

1,7 запущено в производство 1 1

1 успешный на рынке продукт 4

Стадии инновационного процесса

Рис. 1.

причины этих неудач лежат не только в сфере управления проектами (превышение плановых сроков и бюджета) — они часто связаны с принятием «тупиковых», неверных инновационных решений, требующих дорогостоящего перепроектирования всей системы или ее отдельных компонентов. Как повысить «инновационный КПД» при создании информационных систем? Как избежать тупиковых путей и неверных решений? Оставим пока в стороне вопросы управления проектами и посмотрим в корень самой инновации: как получить высокоэффективный, патентоспособный инновационный продукт, несущий в себе потенциал рыночного успеха? Как получить хорошее решение, «алмаз» инженерной мысли? Воспользуемся аналогией: можно добывать алмазы, перерабатывая сотни тонн породы, а можно выращивать их искусственным путем (синтезировать). Сегодня мы видим, что успешные решения в ИТ появляются далеко не сразу — идет долгий перебор разнообразных вариантов, совершается множество удачных и неудачных попыток. То есть инновационное решение возникает внутри некоторого стохастического, малоуправляемого процесса, и хорошая конкурентоспособная система получается лишь в результате многочисленных проб и ошибок. А ведь есть и другой, давно используемый в мире подход. Успешные инновационные решения должны быть целенаправленно «синтезированы»: при этом инновации вырабатываются «по правилам», процесс получения инженерных решений-«алмазов» оказывается управляемым, и появление новых, совершенных информационных систем — целенаправленно спрогнозированнным. Мы говорим о методах синтеза инноваций и прогнозирования развития систем. В США, Франции, Финляндии, Израиле, Австралии, Японии и Южной Корее уже

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

Real-Time Enterprise 2.0

около 20 лет развиваются методы, которые можно объединить под общим названием «синтез инноваций». Эти методы основаны на ТРИЗ* и служат для интенсификации инженерного творчества и управления процессом выработки технологических инноваций. Синтез инноваций в качестве наддисциплинарного метода высокоэффективен в любой области знания (техника, информатика, общество) и в любой отрасли деятельности (нефтегазовая, авиационная, автомобильная, аграрная, банковская и т. п.). Метод предоставляет специалисту и менеджеру комплекс приемов, операторов и алгоритмов, основанных на объективных закономерностях технической эволюции, которые выявил анализ мирового фонда патентной информации на протяжении полувека. Родоначальник метода — Генрих Альтшуллер** (1926–1998), создатель ТРИЗ.

СИНТЕЗ ИННОВАЦИЙ Метод синтеза инноваций сегодня используется во многих областях знания и отраслях мировой промышленности***. Как можно видеть из рис. 2, наибольшее применение метод нашел в машиностроении, электротехнике, химической промышленности, автоматике и вычислительной технике, электронике и радиотехнике, энергетике, транспорте, медицине и здравоохранении, а также при решении общих комплексных проблем технических и прикладных наук. Проекты по синтезу инноваций ведутся в таких мировых компаниях и организациях, как British Petroleum/Amoco, NASA, Boeing, 3M, Sony, Renault, Dow Chemical, Ford, General Motors, DaimlerChrysler, Bentley, General Electric, LG Electronics, Samsung, Hitachi, HP — всего более двух с половиной тысяч компаний во всем мире. В состав метода входят следующие компоненты: технология прогнозирования развития технических и информационных систем на базе объективных закономерностей технической эволюции — Directed Evolution; технология анализа проблем и выявления технических противоречий, постановки инновационных задач; технология генерации инновационных решений, включающая инструментальное ПО инженера-инноватора и базу знаний; технология оценки эффективности полученных инновационных решений, в том числе в форме патентов; технология автоматизированного патентного поиска по мировым информационным базам с использованием критериев отбора; См.: Структура и функции ТРИЗ. — Википедия. Май 2014 года. См.: Альтшуллер, Генрих Саулович. — Википедия. Май 2014 года. *** Источник: ЦИТК «Алгоритм». — http://gen3.ru/3639/3934. *

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

Сельское и лесное хозяйство

Медицина Транспорт Жилищнокоммунальное и здравоохранение хозяйство

Строительство, архитектура Лесная и деревообрабатывающая промышленность Легкая промышленность Биотехнологии Химическая промышленность

Прочие отрасли экономики Общие и комплексные проблемы технических и прикладных наук Метрология Информатика Физика Механика Химия Биология Геология Энергетика

Полиграфия, репрография, фототехника Приборостроение Ядерная техника Машиностроение Металлургия Горное дело

Электротехника Электроника, радиотехника Связь Автоматика, вычислительная техника

Рис. 2. Области применения синтеза инноваций

технология выявления технологических и иных рисков, их предотвращения и устранения. Из этого перечня в контексте настоящей статьи нас интересует первый пункт.

DIRECTED EVOLUTION Как известно, далеко не все существующие на сегодня методы прогнозирования обеспечивают нужный результат. Например, экспертно-интуитивные методы основаны на использовании знаний, опыта и профессиональной интуиции экспертов, а формализованные методы — на математической экстраполяции существующих тенденций. И те, и другие имеют свои преимущественные области применения и присущие им недостатки. Directed Evolution**** относится к методам управляемого развития, и заменяет предсказание (прогнозирование) на планируемое, целенаправленное создание (изобретение) новых путей и способов развития систем. В основе современного метода технологического прогнозирования Directed Evolution лежат закономерности технической эволюции, выявленные в рамках классической ТРИЗ и развитые современными исследователями в России и за рубежом. Метод Directed Evolution используется на всех этапах жизненного цикла инноваций. Кратко рассмотрим основные положения метода. Термин ввел Борис Злотин, автор Directed Evolution. См.: http://www.ideationtriz.com/new/materials/ DEinInformationalCivilization.pdf.

****

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

Real-Time Enterprise 2.0

Указание направления к «идеальной системе», выбор наиболее эффективных линий развития

Direct Evolution Снятие с производства. Поиск новой идеи продукта Рост выпуска продукта, расширение рынка

Выработка инновационных технических решений

Формулировка проблем, генерация идей решений, создание концепции новой системы

Выработка новой концепции системы

Экспертиза

Оценка технического уровня решений

Бизнеспланирование

Плановое улучшение системы по реакции рынка

Серийное производство и продажа продукта Выход на рынок, рекламная кампания, опытная серия продукта

Устранение недостатков и снижение стоимости владения системой

Доработка образца продукта

Рис. 3. Directed Evolution в жизненном цикле инноваций

Выявление и предотвращение рисков Решение конструктивных проблем опытного образца

Пилотный образец инновационного продукта

Разработка инвестиционного проекта Открытие финансирования

Создание start-up компании

1. Закон повышения идеальности систем Все системы развиваются в направлении повышения своей идеальности. Идеальность — это отношение суммы полезных факторов в системе к сумме ее негативных факторов (рисков и затрат). Идеальность =

∑ полезных факторов ∑ факторов риска + ∑ факторов затрат

Полезные факторы — это такие понятия, как функциональность, производительность, эргономичность и т. п. Факторами риска могут быть сбои, недостатки, проблемы, аварии и прочие негативные явления в системе. Факторы затрат в нашем случае — это совокупная стоимость владения системой — Total Cost of Ownership (TCO).

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

Следствием первого закона является понятие идеальной системы. «Идеальная техническая система — это система, вес, объем и площадь которой стремятся к нулю, хотя ее способность выполнять работу при этом не уменьшается. Иначе говоря, идеальная система — это когда системы нет, а функция ее сохраняется и выполняется». (Г. С. Альтшуллер) Теоретически «самая идеальная» система имеет бесконечное количество полезных функций в числителе и полное отсутствие вредных факторов в знаменателе. Иными словами, это система, которая «умеет всё», делает это мгновенно, не стоит ни копейки и сделана «из ничего». Для информационных систем этот основной закон диктует развитие ИС по пути выполнения все большего количества полезных функций, со все большей производительностью, с использованием все меньших вычислительных и программных ресурсов (уменьшение размеров и количества подсистем, оптимизация программного кода, переход от программирования к сборке из программных модулей, самоорганизация систем и переход к самообслуживанию, уменьшение совокупной стоимости владения системой). 2. Закон трехэтапного развития по S‑кривой Идеальность систем изменяется по S‑образной кривой, охватывающей три этапа развития систем: 1‑й этап — «рождение и детство», эксперименты, start-up, появление на рынке; 2‑й этап — «рост и взросление», промышленная эксплуатация, широкое признание рынком; 3‑й этап — «угасание и старость», «дотягивание» характеристик, уход с рынка. Закон трехэтапного развития диктует необходимость мониторинга «уровня идеальности» и прогнозирования развития технической системы для того, чтобы вовремя заметить наступление третьего этапа и начать очередной инновационный цикл, избежав потерь на поддержание функционирования изжившей себя системы. Это особенно важно для информационных систем — с учетом очень высоких темпов развития информационных технологий по сравнению с другими технологическими областями, в том числе с учетом действия закона Мура и концепции технологической сингулярности. Следует отметить при этом, что концепцию технологической сингулярности* в чистом виде — как своего рода «страшилку» — российские ученые справедливо критикуют, поскольку развитие мировых технологий также подчинено заТехнологическая сингулярность — гипотетический момент, по прошествии которого, по мнению сторонников данной концепции, технический прогресс станет настолько быстрым и сложным, что окажется недоступным пониманию; это предположительно этап, следующий после создания искусственного интеллекта и самовоспроизводящихся машин, интеграции человека с вычислительными машинами либо значительного скачкообразного увеличения возможностей человеческого мозга за счет биотехнологий. — Википедия.

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

Real-Time Enterprise 2.0 Идеальность

1 Рис. 4. Этапы развития систем

Время

Hype Cycle (Gartner)

описывает 1-й этап с переходом на 2-й этап развития

кону трехэтапного развития и идет по S‑образной кривой, не достигая точки острого кризиса, а переходя на следующую S‑кривую развития — более высокого уровня. Технология in-memory находится на первом отрезке S‑кривой (см. рис. 4), то есть на переходе с 1‑го на 2‑й этап развития. На рис. 5 приведена оценка, сделанная компанией Gartner в 2012 году, которая детализирует положение различных применений in-memory на этом отрезке. На рисунке указаны некоторые применения технологии in-memory на разных этапах развития. На расстоянии от 5 до 10 лет до достижения «плато продуктивности» (масштабное признание рынком) находятся следующие продукты: серверы приложений in-memory; СУБД in-memory для OLTP; серверы, использующие флэш-память как дополнительную, а также инфраструктура для высокоскоростного обмена сообщениями; магниторезистивная RAM; твердотельные устройства; обработка сложных событий «на лету». Следующие продукты находятся уже на расстоянии от 2 до 5 лет до достижения «плато продуктивности»: аналитические СУБД in-memory; инфраструктурные приложения in-memory; распределенные хранилища данных in-memory;

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

Период выхода технологии на плато продуктивности: меньше 2 лет

от 2 до 5 лет

от 5 до 10 лет

expectations

Аналитические СУБД in-memory

Обработка сложных событий «на лету»

Твердотельные устройства Магниторезистивная RAM Серверы с доп. флэш-памятью

Инфраструктурные приложения in-memory Распределенные хранилища данных in-memory Твердотельные HD уровня предприятия

Мгновенные оповещения СУБД in-memory для OLTP

Технология DDR4 DRAM

Серверы приложений in-memory

Бизнес-аналитика in-memory As of July 2012

Technology Trigger

Peak Trough of of Inflated Disillusionment Expectations

Slope of Enlightenment

Источник: Gartner (July 2012)

бизнес-аналитика in-memory; технология DDR4 DRAM. Из этого следует, что основанные на технологии inmemory информационно-аналитические системы уже через 2–3 года будут широко востребованы на мировом рынке. 3. Закон полноты частей системы Необходимым условием принципиальной жизнеспособности системы является наличие и минимальная работоспособность ее четырех основных частей — Источника, Преобразователя, Исполнителя и Управления. Источник — формирует Ресурсы для выполнения Главной полезной функции системы и выработки Продукта системы. Преобразователь — превращает Ресурсы в Продукт. Исполнитель — завершает выполнение Главной полезной функции системы и передает Продукт потребителю. Управление — прогнозирует, планирует, координирует, контролирует, анализирует, оповещает и обеспечивает обратную связь. Для информационно-аналитической системы этот закон означает, что архитектура системы должна включать все четыре названные части, и может выглядеть примерно

Plateau of Productivity time

Рис. 5. Положение технологии inmemory на S‑кривой

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

Real-Time Enterprise 2.0

Источник

Преобразователь

Исполнитель Продукт

Рис. 6. Полнота частей системы

Управление

так, как показано на рис. 7. На примере ИАС КИНЕФ ОАО «Сургутнефтегаз» можно представить эти компоненты следующим образом. Источник — формирует Ресурсы для выполнения Главной полезной функции системы и выработки Продукта системы. Главной полезной функцией ИАС КИНЕФ является поддержка бизнес-аналитики, Продуктом — аналитические отчеты, Ресурсами — данные из транзакционных систем КИНЕФ. Источник — это системы SAP ECC и АС КИНЕФ, а также компонент SLT, реплицирующий данные в Преобразователь. Преобразователь — превращает Ресурсы в Продукт. В ИАС КИНЕФ преобразование транзакционных данных в аналитические модели для последующего преобразования в Продукт (аналитические отчеты) происходит в SAP HANA и BW on HANA. Исполнитель — завершает выполнение Главной полезной функции системы и передает Продукт потребителю. В ИАС КИНЕФ Исполнитель SAP BО на основе данных и правил, содержащихся в аналитических моделях Преобразователя SAP HANA, формирует Продукт — аналитические отчеты, запрашиваемые пользователем. Управление — планирует, координирует, контролирует, анализирует, оповещает и обеспечивает обратную связь. В ИАС КИНЕФ функции Управления выполняет Репозиторий Бизнес-объектов. 4. Закон развертывания-свертывания Системы развиваются от функционального центра к периферии, проходя фазы развертывания и свертывания. Развертывание — это увеличение числителя (суммы полезных факторов) с одновременным увеличением знаменателя (суммы негативных факторов — рисков и затрат). Идеальность =

∑ полезных факторов ∑ факторов риска + ∑ факторов затрат

Свертывание — это увеличение или сохранение числителя с одновременным уменьшением знаменателя.

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

Источник

Преобразователь

Исполнитель

Транзакционные системы-источники

HANA

BO on HANA

Логический уровень

Данные из таблиц

Область показателей

Бизнесобъекты

Аналитические отчеты

Средства аналитики

Физический уровень Средства визуализации

SLT (SAP Landscape Transformation Server)

Область БО

Экстракция

Базовая область

HANA

Область источников

Бизнес-область

Бизнеспользователи

Показатели

Преобразование Загрузка/Репликация

Аналитические запросы

Бизнес-объекты Показатели НСИ

Управление Репозиторий бизнес-объектов/показателей (ББО)

Введение метаданных

Ведение правил формирования БО

Отражение структуры хранения и сбора данных

Контроль версий и изменений БО

Просмотр данных

Управление доступом, запуском и архивированием

Управление качеством и мониторинг

Поддержка НСИ

Управление моделями

Идеальность =

∑ полезных факторов ∑ факторов риска + ∑ факторов затрат

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

ИТ-специалисты

Рис. 7. Полнота частей применительно к ИАС

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

Real-Time Enterprise 2.0

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

ЗАКОНЫ И ЛИНИИ РАЗВИТИЯ СИСТЕМ Всего в классической ТРИЗ сформулировано восемь законов развития технических систем. Эти законы были подробно декомпозированы на линии развития, которые используются в методе Directed Evolution. Для прогнозирования используются сотни линий развития систем — кроме описанной выше линии свертывания, это могут быть такие, как: Повышение использования системой ресурсов, в том числе: –– Увеличение числа типов используемых ресурсов –– Переход к использованию производных ресурсов –– Увеличение количества уровней структурной иерархии Повышение адаптивности системы, включая: –– Повышение динамичности –– Повышение управляемости –– Согласование/рассогласование Появление и разрешение противоречий в системе Вытеснение человека из системы — и многие другие. В целом метод включает около 600 линий развития систем, а также около 700 операторов для решения инновационных задач и проведения инверсионного анализа.

ДИАГРАММА ИДЕАЛЬНОСТИ СИСТЕМЫ Каждая из линий развития систем имеет свое начало и конец. Весь путь системы от зарождения до идеального состояния по конкретной линии можно принять за 100%. Анализируя протекающий этап развития системы по каждой линии, специалист по синтезу инноваций может дать каждой линии количественную экспертную оценку.

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

Развитие полезных функций 1

Перемены в участии человека 12

Устранение вредных функций

Стремление к многоуровневости 11

3 Развитие приложений

Эволюция полей 10

Развитие процессов 9 в системе

Интеграция и структуризация

Повышение динамичности и управляемости

6 Развитие соответствия/несоответствия

Разрешение противоречий 8 7

Применение ресурсов

Рис. 8. Диаграмма идеальности системы

ОБЩАЯ СХЕМА DIRECTED EVOLUTION Применение Directed Evolution опирается на следующие логические шаги: прогноз развития рассматриваемой системы: –– выявление возможных и вероятных позитивных вариантов развития; –– выявление негатива — опасностей и рисков, которые могут быть связаны с развитием (использование метода инверсионного анализа). выбор среди возможных вариантов развития одного, наиболее реализуемого имеющимися ресурсами системы; формулирование и синтез необходимых инноваций в системе, обеспечивающих реальную возможность желаемого развития;

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

Real-Time Enterprise 2.0

Причинноследственная диаграмма

План защиты интеллектуальной собственности

...

Вопросник

Рабочие планы

Эволюционные события

Ближний

...

Изучение системы

...

Сценарии эволюции

Средний

Дальний

...

Реализация планов

Планирование развития

Прошлое

Настоящее

Будущее

Законы и линии развития

Диверсионный анализ

...

1 12

6 11

Проблемы

Идеи

Концепции

...

8 7

Применение законов развития

Рис. 9. Общая схема процесса

Решение задач

создание сценария желательного развития системы на базе выполненного прогноза и синтезированных инноваций; управление реализацией сценария — план, координация, контроль, анализ, оповещение (отчетность) и обратная связь. Его можно проиллюстрировать следующей схемой: В состав проекта по проведению Directed Evolution входят следующие крупные этапы: 1. Подготовка проекта. 2. Экспресс-прогноз. 3. Анализ эволюции системы.

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

Рис. 10. Пошаговый процесс

4. Ресурсы и ограничения. 5. Причинно-следственный анализ. 6. Прогноз по линиям развития. 7. Выработка прогнозных гипотез. 8. Оценка результатов. 9. План внедрения. Весь процесс поддерживается соответствующим ПО, указанные выше этапы подробно декомпозируются на шаги процесса (см. пример — снимок экрана ПО Directed Evolution на рис. 10). Проект Directed Evolution идет итеративно, со многими циклами, включая большие циклы итераций и малые (вложенные) циклы. В большие циклы входят: Express Directed Evolution как подготовка к основной работе Основной цикл работ Вспомогательные циклы, проводимые по мере необходимости. В малые вложенные циклы на каждом шаге работ включены: Сбор специфической информации по данному шагу Анализ собранной информации Творческий процесс поиска новых идей Предварительная интеграция идей данного шага с идеями, найденными ранее.

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

Real-Time Enterprise 2.0

ПРИМЕР ЭКСПРЕСС-ПРОГНОЗА Метод синтеза инноваций работает уже более 20 лет во многих развитых странах, во многих отраслях промышленности и различных областях знания, в том числе в сфере ИТ. За это время только тремя наиболее известными компаниями в США, специализирующимися на синтезе инноваций*, выполнено более 1700 инновационных проектов, обучено более 250 тысяч специалистов, в более чем 2000 мировых компаниях около 50 тысяч пользователей применяют ПО поддержки инноваций**. Как использовать метод синтеза инноваций и его прогнозную часть, Directed Evolution, для целей развития информационных систем в российском нефтегазовом комплексе и в ОАО «Сургутнефтегаз»? Компания «Сургутнефтегаз» традиционно опирается на ИТ-решения в рамках продуктов компании SAP AG, а операционная деятельность компании поддерживается ERP-системой SAP R3 (SAP ECC). В настоящее время в компании «Сургутнефтегаз» идет внедрение информационно-аналитической системы, основанной на SAP HANA, использующей технологию in-memory. Путь от идеи до промышленной реализации in-memory занял 18 лет, с 1998 (Bell Labs, Dali Main-Memory Storage Manager) по 2011 год (SAP HANA). Интересно, каков будет путь от идеи Real-Time Enterprise до ее будущей промышленной реализации, если сейчас начать использовать метод Directed Evolution? Попытаемся дать экспресс-прогноз эволюционирования технологии in-memory в направлении к концепции Real-Time Enterprise (RTE). Зададим цель: повысить полезные характеристики транзакционных и аналитических систем, в том числе систем бизнес-аналитики и поддержки принятия решений (Business Intelligence & Decision Support Systems), в направлении к реализации концепции предприятия, обрабатывающего информацию в режиме реального времени. Зададим вектор, направленный к «идеалу», то есть сформулируем «образ будущего» — идеальную систему предприятия в концепции RTE, использующего технологию in-memory и другие сопутствующие идеи и технологии. Такой образ будущего был сформирован в рамках «проектной мастерской» на старте проекта ИАС КИНЕФ и лег в основу концепции ее построения. Дополним этот образ, основанный на знаниях экспертов предметной области и ИТ-специалистов, прогнозными гипотезами Directed Evolution, основанными на представлениях о закономерностях технической эволюции в форме «линий развития» систем. В ограниченных рамках статьи, в качестве примера экспресс-прогноза, рассматривается только одна из нескольких сотен существующих линий развития — свертывание.

Ideation International Inc., GEN3 Partners, Invention Machine Corp. Invention Machine Corp. — http://www.invention-machine.com.

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

ПРОГНОЗНЫЕ ГИПОТЕЗЫ ПО ЛИНИИ СВЕРТЫВАНИЯ СИСТЕМ Одна из линий повышения идеальности систем — это линия свертывания. В нашем случае идеальная ИС предприятия предполагает максимально свернутую ИС. Это означает, что информационная система свертывается до состояния, в котором часть ее функций оказывается встроенной в отдельные элементы предприятия (в цеха, аппараты, детали), а другая часть функций ИС вынесена в надсистему, за пределы предприятия — например, в облако, в Интернет, в глобальные системы позиционирования и т. п. Как сказано выше, технология IMDM — только одно из направлений свертывания в ИС; свернуть можно и другие компоненты. Например, четыре архитектурных домена TOGAF (Бизнес, Приложения, Данные, Технология) можно свернуть в два: 1) Информация (виртуальный аспект) 2) Носители информации (материальный аспект). Можно представить также такую архитектуру системы в виде «информационного потока» и «русла потока». Таким образом, свернутая ИС состоит из двух основных частей — виртуального и материального слоев. Будем опираться на эту метафору по ходу экспресс-прогноза. Виртуальный слой «Информация» Информация в свернутой ИС обрабатывается с очень высокой скоростью, позволяя предприятию достичь состояния real-time enterprise/production on demand. В связи с этим появляются существенные улучшения и ранее недоступные возможности. Приложения, или SaaS-свертывание Отдельных функциональных приложений в свернутой ИС не будет — они превратятся в интегрированный конгломерат собираемых «на лету» информационных процессов (сервисов), отражающих реальные бизнес-процессы производства/ управления и выполняемых как по стандартным регламентам, так и по специальным запросам пользователей. В развитие парадигмы SaaS «ПО как услуга по требованию», прикладные приложения свертываются в интернет-сервисы, доступные с мобильных устройств. Сервисы выносятся за физические границы ИС — например, в облако, в дата-центры. Усиливается ориентация на предоставление гибких информационных сервисов вместо использования жестко детерминированных функциональных компонентов, они свертываются в упомянутый выше интегрированный конгломерат. Назовем его рабочим термином «свернутое ПО» — Furled Software.

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

Real-Time Enterprise 2.0

Свертывание in-memory + cloud + mobility Происходит свертывание (конвергенция) нескольких технологий в интегрированное решение, например in-memory + cloud + mobility. Такое решение используется как для предприятия в целом, так и для отдельного корпоративного пользователя — например, оно обеспечивает доступ сотрудников к мобильным сервисам предприятия через информационные витрины, поддерживающие «свернутое ПО». Основные вычисления, хранение информации, бизнес-аналитика будут вестись в таком свернутом решении. Мобильные приложения ИС, привязанные к облачным услугам аналитики и репозиториям «больших данных», обеспечивают возможность анализа, оптимизации и моделирования бизнес-ситуаций в любом месте и в любое время. Свертывание в архитектуре ИС В архитектуре ИС свертывание проявляется в форме переноса некоторых функций с одних функциональных компонентов на другие либо на информационные сервисы (компоненты становятся ненужными, система упрощается). Вместо вопроса «какой новый компонент нужно создать для выполнения данной функции» разработчик задается вопросом «какой существующий компонент или сервис может взять на себя данную функцию». При этом происходит многократное использование одних и тех же функциональных элементов ИС, увеличивается удельная нагрузка на них — значит, повышается эффективность функционирования, ликвидируется дублирование функций, происходит унификация типовых операционных процессов. Аналитика Вся бизнес-аналитика сворачивается в единую платформу in-memory, где транзакционные данные обрабатываются в режиме реального времени, где существенно упрощены структуры многомерных кубов и витрин данных, агрегирование и расчеты, а аналитические функции выполняются «на лету», как сказано выше. Обработка потоков событий Обработка потоков событий ведется по данным, поступающим прямо с датчиков (функции SCADA в сегодняшнем понимании становятся ненужными, сворачиваются); управление и анализ осуществляются непосредственно на оперативных данных, с учетом оперативных условий, обеспечивая мгновенную обратную связь. Мгновенный снимок бизнеса Итоговые учетные процедуры по предприятию (закрытие периода) выполняются за несколько часов, а не за несколько дней (а записав трек закрытия, всегда можно

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

быстро перезакрыть период, изменив лишь несколько транзакций в треке). Имеется возможность «закрыть предприятие» по факту каждой транзакции, тогда перезакрытие вообще не потребуется. В этом случае предприятие может практически в любой момент иметь «мгновенный снимок» своего бизнеса. Сворачивается (существенно упрощается) весь механизм подготовки фискальной и управленческой отчетности. Системы поддержки принятия решений (СППР) В СППР анализируется не только текущая информация, но и события в бизнеспроцессах; ведется как мониторинг выполняемых бизнес-процессов, так и упреждающий прогноз возможных событий — «что будет, если», «что именно и когда может случиться». Используются прогностические возможности Directed Evolution, которые встраиваются в оперативный бизнес как средство поддержки принятия решений и управления жизненным циклом решений. Ведется мониторинг истории и траектории управленческих решений: какое решение было предложено, какое принято, как оно выполнялось, какие получены результаты и какими оказались последствия, в том числе побочные. Материальный слой «Инфраструктура» Сеть передачи данных в рамках предприятия становится полностью беспроводной, высокоскоростной, с пропускной способностью, близкой к real-time — поскольку требуется мгновенная передача данных между всеми объектами с RFIDметками. Здесь возникают реально Большие Данные, Big Data. Интернет (Интранет) Вещей Технологическое оборудование предприятия и различные потребительские устройства интегрируются в Интернет (Интранет) через встроенные сенсоры. Каждому материальному объекту реального предприятия будет соответствовать его информационный виртуальный «двойник» (аналог понятия Internet of Things — назовем его Intranet of Things, Интранет Вещей). Каждый бизнес-объект предприятия (например, деталь, прибор, инструмент, станок, материал, изделие, работник), то есть каждый элемент, входящий в предприятие как в бизнес-систему, будет иметь идентификатор, метку типа RFID, по которой ИС отслеживает состояние и положение этого объекта в технологическом цикле и в бизнес-процессах. Возникает действующая в реальном времени виртуальная модель предприятия. Сеть передачи данных и вычислительные ресурсы Происходит свертывание внутренней сети предприятия и внешних сетей —

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

Real-Time Enterprise 2.0

в процессе интеграции с Интернетом, сетями мобильной связи, GPS-ГЛОНАСС, спутниковыми и кабельными сетями телевещания и другими — вплоть до систем управления транспортными потоками для отслеживания логистики в цепочках поставок (снабжение) и отгрузок товарной продукции (сбыт). Вычислительные ресурсы сворачиваются, переходя большей частью в надсистему: они выполняются в мощных облачных кластерах, в дата-центрах на аутсорсинге, за пределами ИС предприятия. В результате свернутая ИТ-инфраструктура предприятия становится: с одной стороны, полностью интегрированной в структуры, объекты и процессы предприятия; в них сворачиваются все ключевые компоненты ИТинфраструктуры, которые реализуют специфику предприятия и, например, необходимы для виртуализации объектов Интранета Вещей; с другой стороны, значительная часть инфраструктуры ИС выносится за физические пределы предприятия, происходит свертывание в надсистему, предприятие пользуется инфраструктурой провайдеров вычислительных услуг — с тем, чтобы сосредоточиться на своих бизнес-задачах и не отвлекать силы на собственные ИТ. В итоге ИТ-инфраструктура предприятия потребует меньше серверов БД, дисковых ресурсов, сетевых компонентов, аппаратная часть ИС приобретет гораздо более высокую масштабируемость и гибкость, снизится совокупная стоимость владения ИТ. Дополнительные гипотезы Виртуальные помощники и их роли В связи с наличием подробной и точной информации о реальной деятельности предприятия (мгновенная аналитика через Интранет Вещей), отражаемой в «виртуальной модели предприятия», у сотрудников возникают виртуальные ассистенты. Например, может быть создан инфокибер «виртуальный аудитор» финансового департамента для автоматической сверки, или «виртуальный инспектор по технике безопасности», или «виртуальный контролер качества», или «виртуальный рисканалитик». Изменения в системном окружении и в надсистеме В ходе развития информационных систем в рассмотренных направлениях, когда упомянутые изменения происходят на многих других предприятиях и в организациях, ИС конкретного предприятия гораздо более тесно интегрируется с бизнеспартнерами, с государством, с рынком. Например: Информационные системы поставщиков (supply chain), работающие на тех же принципах и связанные с ИС предприятия, обеспечивают ему мгновенную прозрачную информацию о состоянии процесса поставок, возможных задержках

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

и сбоях в логистике, мониторинг движения грузов и т. п. Потребители общаются с ИС предприятия через мобильные устройства (делая заказы, оплачивая закупки, получая отчеты и консультации). ИС налоговых и регулирующих госорганов связаны с ИС предприятия через Интернет с возможностью получения статистики и регламентной отчетности, проведения быстрых налоговых и иных контрольных проверок и т. д. Информационная и технологическая безопасность Наличие меток на всех бизнес-объектах позволяет вести мониторинг подозрительной деятельности в режиме реального времени, мгновенно выявлять и анализировать угрозы, а в случае внедрения системы оценки рисков — эффективно выявлять и предотвращать потенциальные аварии, брак, другие негативные явления. Самоорганизация систем Развитие в направлении к идеальной системе подразумевает не только использование принципа свертывания, но и принципа «система сама себя улучшает» — то есть принципа самоорганизации. Самоорганизующейся является система, способная без специального воздействия извне формировать/изменять свою функциональную и компонентную структуру. Такая система имеет возможность модифицировать себя под требования пользователей — без перепроектирования, с целью обеспечить свое нормальное функционирование при изменениях как внешних факторов (решаемые бизнес-задачи), так и внутренних факторов (недостаточный объем ресурсов, рост базы данных, выявление дубликатов данных). Система также сама себя обслуживает, предотвращая и выявляя сбои и неполадки, уменьшая тем самым необходимость вмешательства ИТ-службы. Итоги экспресс-прогноза Таким образом, подытоживая экспресс-прогноз с использованием одной-единственной линии развития — свертывания, уже можно выделить следующие интересные предположения: Приложения превращаются в «свернутое ПО», набор собираемых «на лету» инфосервисов, доступных бизнес-пользователям с мобильных устройств в любом месте в любое время; пользователи могут в реальном времени получить любую аналитику по предприятию, включая «мгновенный снимок бизнеса», прогноз показателей деятельности, предупреждения о возможных событиях или о возникающих рисках. Существенно упрощается и удешевляется вычислительная инфраструктура, но одновременно развертывается инфраструктура съема данных с датчиков для Интранета Вещей — действующей в реальном времени виртуальной модели предприятия.

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

Real-Time Enterprise 2.0

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

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

ЛИТЕРАТУРА 1. Plattner H. A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database // SIGMOD’09, June 29 — July 2, 2009, Providence, Rhode Island, USA. 2. Холкина М. М., Холкин И. Н. Феномен инфосоциосреды: системные отношения и прогноз развития. В рамках гранта РФФИ 09–06–00274 «Трансформации общественного сознания и картины мира личности в условиях формирования информационного общества» // Институт системных исследований и КСП. М., 2010.

И.Н. Холкин. Применение метода Directed Evolution для анализа и прогнозирования развития информационных систем

3. Холкина М. М., Холкин И. Н. Интернет как часть феномена инфосоциосреды в информационном обществе // Институт системных исследований и КСП. М., 2010. 4. Mizrachi Yo. Comments on Intellectual History, The Logical and Applicative Visibility, and The Underlying Assumption of Directed Evolution (DE) // The BRM Institute for Technology and Society, The Graduate School of Business Administration. Tel Aviv University, 2007. 5. Fulbright R. Don’t Try to Predict the Future, Engineer it With Directed Evolution // Ideation International Inc., 2006. 6. Zlotin B., Zusman A. Patterns of Evolution: Recent Findings on Structure and Origin // Ideation International Inc., 2006. 7. Zlotin B., Zusman A. Directed Evolution as a Method of Thinking in the Era of Informational Civilization // Ideation International Inc., 2001. 8. Злотин Б., Зусман А. ТРИЗ-прогнозирование: вчера, сегодня, завтра. Выход за парадигму // Ideation International Inc., 2002. 9. Zlotin  B., Zusman  A.  Directed Evolution: Philosophy, Theory and Practice // Ideation International Inc., 2001. 10. Петров В. М., Злотина Э. С. Теория решения изобретательских задач — основа прогнозирования развития технических систем. — Прага: ЧДНТО, 1989. 11. Альтшуллер Г. С. Творчество как точная наука. Теория решения изобретательских задач. — М.: Советское радио, 1979.

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

Real-Time Enterprise 2.0

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

ОПЫТ ТРАНСФОРМАЦИИ ТРАДИЦИОННОГО АНАЛИТИЧЕСКОГО РЕШЕНИЯ (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)

BusinessObjects

Oracle

SAP Data Services

SAP R/3 SAP CRM

СПбМТСБ ММТЭБ

SAP PI

Биржа «Санкт-Петербург» ЦДУ ТЭК

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

РЖД КОРТЕС

Рис. 1.

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

АРХИТЕКТУРА РЕШЕНИЯ НА БАЗЕ BUSINESSOBJECTS + HANA Перед стартом проекта была проведена апробация (proof of concept, PoC) предстоящего проекта реинжиниринга информационно-аналитической системы. Рассматривались два варианта построения будущей модели данных: расчет по запросу (классическая in-memory) и создание предрассчитанного слоя в ХД. По результатам PoC, для оптимизации производительности и поддержки информационно-аналитической системы было принято решение: разделить модель данных в соответствии с функциональными областями бизнес-задач; при построении модели использовать гибридный подход — сочетание элементов классического хранилища данных, и технологии in-memory; апробировать систему сбора моделей данных на основе бизнес-объектов.

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

Real-Time Enterprise 2.0

BusinessObjects HANA Статическая часть

SAP Data Services

Рис. 2.

SAP R/3 SAP CRM

СПбМТСБ ММТЭБ

Динамическая часть

SLT

Биржа «Санкт-Петербург» ЦДУ ТЭК

SAP PI

РЖД КОРТЕС

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

С целью облегчения процесса перехода было решено оставить существующий уровень моделей данных без изменения, что не создаст трудностей для пользователей системы, а также потребует минимальных затрат при переделке отчетов. В итоге архитектура решения (рис. 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)

Статическая часть

Перерасчет

Динамическая часть

Модель данных View Триггеры

SAP HANA Column Tables

SLT

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

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-nextgeneration-real-time-analytics/#sthash.b5SQuHVv.dpuf (дата обращения: 25.04.2013).

Владимир Валерьевич Куфтерин Ведущий инженер отдела инновационных проектов управления информационных технологий ОАО «Сургутнефтегаз».

ПОСТРОЕНИЕ АНАЛИТИЧЕСКОЙ СИСТЕМЫ С ИСПОЛЬЗОВАНИЕМ IMDM НА ОСНОВЕ РЕПОЗИТОРИЯ МЕТАДАННЫХ

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

Real-Time Enterprise 2.0

какими основными проблемами сталкиваются организации при построении аналитической системы? 1. Ограниченный бюджет. Решения для бизнес-аналитики не только дороги, но и крайне требовательны к ресурсам. Это связано как с большим объемом обрабатываемых данных из различных источников, так и с желанием бизнес-пользователей получать ответы на поставленные вопросы в режиме приближенном к режиму реального времени. 2. Соответствие требованиям бизнеса. Требования бизнеса динамически меняются в соответствии с возникающими перед ним задачами, и бизнесу важно получить ответ на поставленный вопрос сейчас, а не спустя какое-то время, необходимое для настройки системы, когда ответ утратит актуальность. 3. Эффективное обслуживание системы после внедрения. Аналитическая система должна быть гибкой и управляемой, но, как показывает практика, быстрая и легкая адаптация к изменениям не является сильной стороной BI-систем. Нередко расходы на их сопровождение составляют от 40% до 100% в год от первоначальной стоимости разработки. Свою лепту вносят сложные модели бизнеса, постоянно изменяющиеся под влиянием внутренних и внешних факторов. 4. Перечисленные три проблемы в процессе эксплуатации системы нередко порождают четвертую — недоверие бизнес-пользователей к информации, выдаваемой аналитической системой. Какие есть пути для преодоления изложенных выше проблем? Заострим внимание на главных, а именно: несоответствие требованиям бизнеса; неэффективное обслуживание системы; недоверие бизнес-пользователей. Здесь необходимо абстрагировать бизнес-логику и интерфейс пользователя от источника данных, разработав систему динамического соответствия и трансляции бизнес-модели на модель базы данных и наоборот, что в комплексе позволит обеспечить: независимость эволюции бизнес-модели от модели базы данных; актуализацию пользователями бизнес-модели под влиянием меняющихся требований бизнеса и внешних факторов. Исходя из предложенного подхода, обозначим основные компоненты такой системы. Это три функциональных блока (рис. 1): Корпоративный репозиторий бизнес-метаданных. Аналитическая система. Подсистема управления данными. Рассмотрим каждый из функциональных блоков. С чем привыкли работать пользователи — с объектами, встречающимися в их повседневной деятельности. Пользователи представляют весь жизненный цикл этих объектов, их взаимодействие и взаимосвязи. Любую бизнес-модель можно представить в виде совокупности и взаимодействия отдельных сущностей (бизнестерминов), обладающих определенными свойствами. Связывая различные бизнес-

В.В. Куфтерин. Построение аналитической системы с использованием IMDM на основе репозитория метаданных

Бизнес Корпоративный репозиторий бизнесметаданных

ИТ Подсистема управления данными

Аналитическая система

Поддержка соответствия моделей Управление метаданными Управление качеством Рис. 1.

термины в той или иной последовательности, возможно построить модель любого бизнес-процесса, имеющего место на предприятии. Значит, для эффективного перехода к моделированию аналитической системы силами бизнес-пользователей необходимо представить модель бизнес-архитектуры в понятных для бизнеса терминах. Для консолидации и ведения объектов бизнеса организован репозиторий бизнес-метаданных. В первую очередь репозиторий выполняет функции бизнес-словаря, где все объекты бизнеса, с которыми пользователи имеют дело в своей повседневной деятельности, представлены в виде бизнес-терминов. Для каждого бизнес-термина определяется его бизнес-описание (происхождение, функции, роль в деятельности предприятия), правила формирования и проверки качества. Определяются ключевые слова и синонимы с целью быстрого поиска. Бизнес-термины, нашедшие отражение в информационной системе предприятия, приобретают статус информационного объекта. Информационные объекты можно разделить на три категории: бизнес-объекты, справочники и показатели (рис. 2). Для каждого информационного объекта в информационной системе имеется однозначное соответствие в виде совокупности технических объектов (связанных таблиц базы данных для реляционной БД, или же набора SQL-запросов/представлений в случае с in-memory базой данных SAP HANA). Основная часть информационных объектов — это документы: договор, реестр, платежное поручение и пр., а также справочники и классификаторы. Совокупность логически связанных справочников и бизнес-объектов с их коли-

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

Real-Time Enterprise 2.0

Повседневная деятельность

Информационная система

Бизнес-термин

Информационный объект Справочник SQL

Бизнес-проект SQL

Показатель

Рис. 2.

SQL

чественной характеристикой (транзакционными данными) образует показатели. Базовые показатели, отражающие конкретный факт по отдельно взятому бизнесобъекту, представляют собой низший операционный уровень аналитики. Оперативные показатели являются основой для построения аналитической пирамиды, с выводом аналитической информации на тактическом и стратегическом уровнях управления предприятием. Такой подход предполагает выстраивание и согласование иерархии показателей как «снизу вверх» так и «сверху вниз» — от базовых оперативных до ключевых показателей деятельности предприятия на самом верху (рис. 3). Следующий компонент, аналитическая система, построен на основе программно-аппаратного комплекса обработки данных в оперативной памяти и реализован по классической схеме (рис. 4). Базовый компонент аналитической системы — in-memory БД HANA — логически разделен на пять уровней (рис. 5): Уровень исходных систем содержит физические таблицы с данными, реплицированными из исходных систем. Пользователи с этим уровнем не работают — он является поставщиком данных для последующих уровней. Базовый уровень содержит аналитические представления над отдельными физическими таблицами или группой таблиц, объединение которых может быть использовано для анализа и проверки качества информации на уровне исходных систем. Например, связь заголовка и позиции финансового документа послужит сигналом о целостности документа при репликации. Данный уровень имеет ограничение на доступ пользователей и предназначен, прежде всего, для работы ИТперсонала и стюардов данных. Может быть поставщиком данных для последующих уровней. Уровень бизнес-объектов содержит логические представления бизнес-объектов и справочников. Уровень доступен для пользователей посредством перехода

В.В. Куфтерин. Построение аналитической системы с использованием IMDM на основе репозитория метаданных

Стратегический

Бизнес-области

SQL

Тактический

SQL

Оперативный

SQL

Показатели Справочники, бизнес-объекты SQL

SQL

Рис. 3.

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

Аналитические приложения

Уровень показателей

Представление HANA Хранение Экстракция, преобразование, загрузка Системы-источники

Уровень бизнес-области

Уровень бизнес-объектов Базовый уровень

SLT

ERP

Уровень исходных систем

Рис. 4.

SQL

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

Real-Time Enterprise 2.0

Уровень бизнесобластей Аналитики

Бизнеспользователи

CV_BP1

Уровень показателей CV_BO1

ИТ

Рис. 5.

CV_AN2

CV_BO3 CV_BOn

CV_DIR

Стюарды данных

Уровень исходных систем

CV_BP2

CV_AN1

Уровень бизнесобъектов

Базовый уровень

CV_BP1

CV_T1

CV_T3

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

В.В. Куфтерин. Построение аналитической системы с использованием IMDM на основе репозитория метаданных

ных объектов описать бизнес-модели практически любой сложности и оперативно реагировать на различные изменения бизнес-среды. Для того чтобы аналитическая система и репозиторий бизнес-метаданных имели представление о существовании друг друга, для организации процесса обмена информацией и осуществления контроля за ее качеством предусмотрена подсистема управления данными, функционально разделенная на три соответствующих блока (см. рис. 1). Блок управления метаданными отвечает за сбор метаданных со всех уровней аналитической системы. С его помощью можно установить однозначное соответствие между объектами репозитория метаданных и логическими объектами аналитической системы, а также проследить цепочку происхождения и использования данных. Блок управления качеством выполняет функцию контроля качества данных в соответствии с правилами проверки качества, определенными в репозитории метаданных. Контроль качества осуществляется как на уровне исходных систем, так и на вышележащих уровнях аналитической системы. При этом правила учитывают всю цепочку прохождения данных. Блок поддержки соответствия моделей транслирует бизнес-метаданные из репозитория в модель аналитической системы. В момент получения информационным объектом статуса «Утвержден» формируется пакет инструкций для исполнения на стороне аналитической системы: набор SQL-запросов, содержащих новую структуру информационного объекта; набор корректирующих SQL-запросов на цепочку объектов, зависимых от измененного объекта; набор инструкций по перемещению «остывшей» (устаревшей) версии информационного объекта из in-memory БД в менее производительную БД; набор скриптов, содержащих логику перехода от предыдущей версии объекта к текущей. При получении пакета инструкций логическая модель аналитической системы динамически преобразовывается в соответствии с бизнес-моделью. Это становится возможным благодаря использованию in-memory БД, которую отличает большая гибкость в отношении изменения логической организации данных, и все необходимые вычисления возможно проводить «на лету», на основе данных из уровня исходных систем, что позволяет избежать длительных перезагрузок данных из одной структуры в другую. Изменение структуры информационного объекта, правил его расчета, динамическая синхронизация с моделью аналитической системы позволяет повысить адекватность аналитической системы текущим условиям бизнеса. Но как же быть c историей аналитики за предыдущие периоды до момента изменения? Чтобы сохранить историю анализа за прошлые периоды, а также возможность сравнивать ее с текущими результатами, вводится понятие «температура версии информационного объекта» (рис. 6).

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

Real-Time Enterprise 2.0

In-memory «Горячая»

NLS «Теплая»

«Холодная»

2 SQL

Перенос «холодных» объектов в NLS

Температура Рис. 6.

max

min

Каждый информационный объект на конкретный момент времени имеет определенную структуру и правила формирования. На момент его описания состояние информационного объекта фиксируется за версией «0». При каждом изменении информационного объекта его состояние фиксируется в новой версии (текущая + 1). Все предыдущие версии объектов сохраняются, определяются правила трансформации предыдущей версии к текущей, что позволяет анализировать изменения версий. Чем ниже номер версии, тем ниже ее «температура». Актуальная модель бизнеса строится на информационных объектах в самой высокой версии, т. е. на самых «горячих». Поскольку подразумевается, что версии информационных объектов ниже текущей уже не подлежат изменению, а уровень востребованности «холодных» версий ниже, чем «горячих», то представляется рациональным переносить «холодные» версии объектов из in-memory БД HANA в более низкопроизводительные и недорогие, например, NLS на базе Sybase IQ. При этом выполняется материализация как самих структур информационного объекта, так и заполнение их данными на момент перевода версии из «горячего» хранилища. Описанный подход с привлечением пользователей к процессу управления аналитической системой, с использованием бизнес-метаданных, описывающих предметную область, бизнес-правила, логику взаимодействия системы и данных в виде информационных объектов, имеющих однозначное соответствие терминам бизнеса: позволит по-новому взглянуть на информационное наполнение аналитической системы;

В.В. Куфтерин. Построение аналитической системы с использованием IMDM на основе репозитория метаданных

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

ЛИТЕРАТУРА 1. Бизнес-аналитика для всех [Электронный ресурс] // Microsoft. Технический документ. 2009. Октябрь. — http://www.navicongroup.ru/moss/library/6.pdf. 2. Шовкун А. Как повысить прозрачность аналитических систем и снизить их ТСО [Электронный ресурс] // Директор информационной службы. — 2005. 5. — http://www.osp.ru/cio/2005/05/173983/. 3. Воинов Ю. Корпоративные хранилища данных: мифы и реальность [Электронный ресурс]. 2003. — http://www.softdeco.com/index.php?uin=1207201621&id=1 207201991&pg=1207386974. 4. Зинченко Р. Е. Модель и алгоритмы динамической поддержки системного изоморфизма концептуальной модели предметной области и базы данных: автореф. дис. … канд. техн. наук. — Гос. пед. ун-т им. В. Г. Белинского. — Пенза, 2011. 5. Дрожин В. В., Зинченко Р. Е. Эволюция архитектуры информационных систем // Программные продукты и системы. — 2010. 4. — С. 59–63. 6. Асадуллаев  С.  Пошаговое внедрение средств управления метаданными IBM Information Server [Электронный ресурс]. 21.09.2009. — http://www.ibm. com/developerworks/ru/library/sabir/Information_Server/index.html. 7. Асадуллаев С. Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных [Электронный ресурс]. 09.07.2009. — http://www.ibm.com/ developerworks/ru/library/r‑nci/index.html.

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

Real-Time Enterprise 2.0

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

ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ РАБОТЫ ТРАНСПОРТА В SAP HANA, SAP BO 4

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

Real-Time Enterprise 2.0

ранспортное обеспечение — один из главных видов деятельности, которому уделяется большое внимание в любой нефтяной компании. Для эффективной работы предприятия организация транспортного обеспечения должна основываться на четкой экономической целесообразности. Транспортники первыми приходят на объекты будущего производства, участвуют во всех технологических процессах и обеспечивают разведку, освоение и эксплуатацию нефтегазовых месторождений. Основные задачи в области организации транспортного обеспечения компании: поддержание техники в надлежащем состоянии; контроль за ее эффективной эксплуатацией; обеспечение безопасности дорожного движения; содержание внутрипромысловых и магистральных дорог; своевременная доставка материалов и оборудования в подразделения компании. Этими задачами в ОАО «Сургутнефтегаз» занимается более 30 тысяч сотрудников. Транспортный комплекс компании сегодня составляют 28 транспортных подразделений и порядка 30 тысяч единиц техники различного назначения. География оказания транспортных услуг — от самых западных регионов до Дальнего Востока России. Основные месторождения находятся в Западной и Восточной Сибири. Высокий уровень квалификации инженеров, водителей, ремонтников, четкая организация труда и строгая производственная дисциплина позволяют нам успешно справляться со сложными задачами транспортного обеспечения добычи нефти и газа в сложных климатических условиях при непрерывном цикле производства. С учетом весомой доли транспортных затрат в себестоимости добычи нефти и газа, особое значение приобретает комплексное решение задач повышения эффективности использования транспорта. Существенный эффект может быть достигнут только в условиях всесторонней автоматизации процессов управления и обработки всех потоков информации в единой системе управления автотранспортом.

ИС «АВТОТРАНСПОРТ» И ЕЕ ЗАДАЧИ В 2003 году создана и с тех пор совершенствуется информационная система «Автотранспорт» — единая интегрированная информационная система управления автомобильным транспортом ОАО «Сургутнефтегаз» (рис. 1). В ее состав входят: ИС «Автотранспорт» (на базе СУБД Oracle) — обеспечивает первичный оперативный учет работы автотранспорта, водителей и машинистов. SAP R/3 — обеспечивает учет нормативно-справочной информации, учет персонала, бухгалтерский, финансовый, материальный учет, учет затрат, учет ТО и ремонтов. Программное средство «Анализ ТЭП работы транспорта» (на базе СУБД MS SQL) — обеспечивает анализ агрегированных ежемесячных технико-эконо-

И.Н. Ветряев. Технико-экономические показатели работы транспорта в SAP HANA, SAP BO 4

Аналитика верхнего уровня

SAP ERP SAP R/3 4.7 Учет ТС (ведение НСИ) Учет узлов и агрегатов Планирование и учет рабочего времени Планирование и учет ТОиР Учет затрат на единицу техники Учет ГСМ

Аналитическая, регламентная отчетность, ТН

Гибкая аналитика

Монитор руководителя

SAP BW

SAP HANA

SAP BO

Ведение оргструктуры

Диспетчерская

Формирование табеля

Обработка путевой документации

Расчет зарплаты SAP PI интеграция

SAP MDM Справочник видов работ (U)

ПТО

Справочник внутрисменных операций

ИС «Авиаперевозки. Версия 2» ПС «Карьеры» ИС «ОКО ЦИТС Нефтепродуктообеспечение»

Заказчик ОТК и КПП

Справочник материалов

Анализ ТЭП ТС

ИСАТ (Oracle)

SAP ERP2005 (HR)

АСУ ТП АЗС ИС «ОКО ЦИТС СНДСР» СКРТ «Навигатор С»

ПЭО (уровень СП) ОТК и КПП

Магнитные карты водителей

ИС «КТС»

ИС «Метеоусловия»

ГСМ и АЗС

ГИС ОАО «СНГ»

мических показателей работы транспорта в рамках структурного подразделения и компании в целом. Отчетность в SAP BW — аналитические отчеты по наличию и возрастному составу транспортных средств, расчет транспортного налога, отчеты по затратам на ТО и ремонт. В условиях развития бизнеса, интенсивного освоения новых территорий, в силу объективных экономических причин затраты на транспортное обеспечение существенно возрастают. Поэтому основными задачами специалистов и управленцев различного уровня становятся: повышение эффективности транспортного обслуживания; снижение доли затрат на транспорт в себестоимости продукции ОАО «Сургутнефтегаз»;

Рис. 1.

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

Real-Time Enterprise 2.0

безусловное, качественное и своевременное транспортное обеспечение в требуемых объемах. Ценность управленческих решений в таких условиях возрастает, от их правильности и своевременности в конечном итоге зависит успешность основного бизнеса компании. В свою очередь, гарантировать эффективность решений можно только при обеспеченности руководителя управленческой отчетностью качественно нового уровня. Требуемый уровень отчетности характеризуется совокупным представлением об оперативной обстановке, складывающейся в реальном времени, и динамике данных за несколько последних отчетных периодов. Управленческие решения, требующие особой оперативности, принимают специалисты, непосредственно участвующие в бизнес-процессах. Поэтому специалисты сами, без особых затрат времени, должны генерировать уникальные ракурсы информации, необходимые им в конкретных ситуациях. В настоящий момент для анализа и контроля деятельности транспортного комплекса ОАО «Сургутнефтегаз» специалисты планово‑экономических отделов структурных подразделений и служб аппарата управления ежедневно осуществляют: Сбор и расчет технико-экономических показателей, характеризующих процессы эксплуатации и ремонта транспорта, работу персонала, финансовый и бухгалтерский учет. Формирование регламентной отчетности строгой формы из различных информационных систем для представления руководству. Формирование, в том числе и вручную (средствами Excel), по требованию руководства сводной аналитической отчетности в произвольной форме с различной степенью детализации для поддержки принятия управленческих решений. Существующие сегодня в компании системы оперативной и аналитической отчетности по транспорту не способны в полной мере обеспечить современные потребности бизнеса в управленческой аналитике, так как содержат ряд ограничений: разрозненность учетных систем — источников информации; неоднородность и разная степень детализации данных в них; отсутствие средств трансформации исходных данных в реальном времени; длительные сроки доработки отчетности — при необходимости модифицировать структуру, добавить новый показатель, измерение или фильтр; недостаточная производительность для обработки очень больших массивов данных. Таким образом, возникает потребность в качественно новой системе аналитической отчетности, удовлетворяющей следующим современным требованиям бизнеса: Объединение показателей, характеризующих все процессы транспортного обслуживания, из различных информационных систем в едином хранилище данных. Повышение качества аналитики за счет использования максимального количества возможных измерений. Обеспечение актуальности данных в режиме реального времени.

И.Н. Ветряев. Технико-экономические показатели работы транспорта в SAP HANA, SAP BO 4

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

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ Система должна обеспечивать: сбор, трансформацию, загрузку, хранение, обновление информации из различных СУБД (в том числе Oracle, MS SQL) в реальном времени; многомерность, полноту, непротиворечивость, целостность данных в моделях проекта; использование бизнес-терминов для доступа к данным; представление информации в настраиваемых аналитических ракурсах, создание выходных форм отчетов; высокую производительность обработки и извлечения больших объемов данных; разграничение прав доступа для сотрудников ОАО «Сургутнефтегаз».

ТЕХНИЧЕСКОЕ РЕШЕНИЕ Использование высокопроизводительной СУБД SAP HANA для обеспечения хранения и обработки информации, инструментария SAP HANA для реализации модели данных проекта. Использование SAP SLT для обеспечения загрузки и обновления информации из всех систем — источников данных в СУБД SAP HANA в режиме реального времени. Использование средств SAP BO 4.0 для создания семантического слоя, представляющего модель SAP HANA в бизнес-терминах, для формирования запросов к модели данных, создания бизнес-пользователем произвольных отчетных форм на основе запросов SAP BO, без программирования.

КРАТКОЕ ОПИСАНИЕ СИСТЕМЫ Данные из учетных систем-источников реплицируются и хранятся в columnтаблицах SAP HANA. В процессе репликации данные подвергаются минимальным преобразованиям — происходит конвертирование форматов данных, формируются расчетные поля (рис. 2).

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

Real-Time Enterprise 2.0

Sources

DB Layer

Presentation Layer

SAP HANA

BOE Explorer

VIEWs

Dashboards / Design Studio

SAP R/3 SLT ИСАТ (Oracle)

Universe DB Schema

БД ТЭП

(MS SQL Server)

Webi

Рис. 2.

На основе таблиц SAP HANA создается ряд низкоуровневых моделей данных (Attribute view, script), ориентированных на описание связанных между собой показателей и включающих набор их общих измерений (рис. 3). Основная трансформация данных происходит на этом уровне. Для объединения низкоуровневых моделей в единую результирующую модель проекта осуществляется выравнивание мер и измерений во всех моделях — создаются

Рис. 3. Примеры объектов в SAP HANA

И.Н. Ветряев. Технико-экономические показатели работы транспорта в SAP HANA, SAP BO 4

Модель ТЭП Модель ИСАТ Путевые листы

Измерения

NULL

Измерения

NULL значения

Модель ИСАТ Модель ИСАТ

Нормы по технике

Нулевые значения

Меры

Нулевые значения

Измерения NULL

NULL

Нулевые значения

Меры Нулевые

Измерения

Машино-дни

Нулевые

Меры значения Меры

Нулевые значения

Общие измерения для анализа всей модели

Рис. 4. Структура модели

недостающие расчетные поля: меры = 0, измерения = Null (рис. 4). Низкоуровневые модели при помощи оператора Union объединяются в результирующую модель проекта (на основе Calculation view) (рис. 5). Для представления пользователям мер и измерений CV_ОБЩАЯ МОДЕЛЬ ИСАТ ТЕП

КЛАССИФИКАТОР, КАЛЕНДАРЬ, БС, ДРУГИЕ СПРАВОЧНИКИ

Рис. 5. Иерархия моделей

CV_ОБЪЕДИНЕНИЕ В МОДЕЛЬ ИСАТ CV_МОДЕЛЬ ТЕП

CV_РАЗВОРОТ МОДЕЛИ ТЕП CV_ПЛАН_ ФАКТ_PL

AT_ПЛАН_ МД

AT_ФАКТ_ МД

CV_ПЛАН_ МД

CV_ФАКТ_ МД

CV_ПЛАН_ НОРМ_ПО_ ТЕХНИКЕ

AT_ПЛАН_ AT_ФАКТ_ AT_ПЛАН_НОРМЫ PL PL _ПО ТЕХНИКЕ

AT_ФАКТ_НОРМЫ _ПО ТЕХНИКЕ

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

Real-Time Enterprise 2.0

из модели в виде понятных им бизнес-терминов, возможности формировать запросы данных и произвольные формы отчетности создается семантический слой в SAP BusinessObjects. Построение и форматирование отчетности осуществляются средствами Web Intelligence.

РЕЗУЛЬТАТ Используя инновационные решения компании SAP в области технологии обработки данных in-memory и Business Intelligence, удалось создать качественно новый инструмент гибкого бизнес-анализа, способный удовлетворить текущим и перспективным требованиям бизнеса.

ЛИТЕРАТУРА 1. Спирли Э. Корпоративные хранилища данных. Планирование, разработка, реализация. Том. 1: пер. с англ. — М.: Изд. дом «Вильямс», 2001. 2. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Ф. Проектирование экономических информационных систем: учебник / под ред. Ю. Ф. Тельнова. — М.: Финансы и статистика, 2001. 3. Бачурин  А. А.  Анализ производственно-хозяйственной деятельности автотранспортных организаций: учеб. пособие для студ. высш. учеб. заведений / под ред. З. И. Аксеновой. — М.: Издат. центр «Академия», 2004. 4. Садоский В. Н. Системный подход и общая теория систем: статус, основные проблемы и перспективы развития // Системные исследования. Методологические проблемы. — М.: Наука, 1980.

Евгения Владимировна Максимюк Инженер-программист I категории ПУ «СургутАСУнефть», аспирант Сургутского государственного университета.

РЕШЕНИЕ ЗАДАЧ ПОТОКОВОЙ ОБРАБОТКИ ДАННЫХ И ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ С ИСПОЛЬЗОВАНИЕМ IMDM (SAP HANA) НА ПРИМЕРЕ ЗАДАЧ ЭНЕРГОЭФФЕКТИВНОСТИ ПРОИЗВОДСТВЕННЫХ ОБЪЕКТОВ

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

Real-Time Enterprise 2.0

ктуальность темы обусловлена необходимостью увеличения полезного эффекта от расходования ресурсов, используемых для получения полезной продукции, и уменьшения затрат на ее выработку. Это требует постоянной обработки большого количества данных. Одним из направлений развития топливно-энергетического комплекса является работа по повышению его энергоэффективности, что ставит перед нами следующие задачи: повышение технологической и энергетической эффективности работы производственных объектов за счет своевременного выявления отклонений контролируемых параметров от нормативных значений; приведение параметров состояния оборудования, производственных объектов к оптимальным значениям; разработка на основе обработанных данных мероприятий по повышению энергетической эффективности. Для исследования вопросов повышения энергоэффективности в работе рассматривается процесс производства тепловой энергии котельными установками. Котельные установки — комплекс технологически связанных тепловых энергоустановок, расположенных в обособленных производственных зданиях с котлами, водонагревателями и котельно-вспомогательным оборудованием, предназначенных для выработки теплоты. Цель работы — обеспечить эффективное принятие решений в области повышения энергоэффективности работы котельных установок нефтегазодобывающего комплекса путем создания интеллектуальной информационной системы поддержки принятия решений. В настоящее время для управления процессами повышения энергоэффективности источников теплоснабжения используют информацию об отклонениях технологических показателей от их удельных норм (см. рис. 1). Например, отклонение удельного расхода котельно-печного топлива на отпуск тепловой энергии от нормативного показателя, установленного для каждой котельной по соответствующим типам котлов и видам топлива из сборника норм расхода. Такой подход содержит в себе следующие недостатки: контроль удельных норм не позволяет локализовать проблему до определенного узла оборудования производственного объекта, а только показывает, что происходит снижение эффективности его работы и нужно предпринимать какие-то меры; несвоевременное выявление отклонений от норм в работе оборудования приводит к увеличению стоимости мероприятий по повышению энергетической эффективности объекта. Будем считать событием в задаче повышения энергоэффективности выход контролируемых параметров за границы норматива. Для выявления причинноследственных связей указанных событий с состоянием определенного типа узла оборудования необходимо обрабатывать показания датчиков, регистрирующих состояние данного узла производственного объекта. Регистрация сигналов про-

Е.В. Максимюк. Решение задач потоковой обработки данных и поддержки принятия решений с использованием IMDM (SAP HANA)

Газ

Потребление энергоресурсов

Вода

Котельные

Тепловая энергия

Электроэнергия

Показатели эффективности работы источников теплоснабжения

Выработка продукции

• • • • • •

Удельный расход топливного газа, м3/Гкал Удельный расход жидкого топлива, кг/Гкал Удельный расход условного топлива, кг.у.т./Гкал Удельный расход электроэнергии, кВт/Гкал Удельный расход воды, м3/Гкал Фактическая подключенная тепловая нагрузка котельной, Гкал/ч • Рекомендуемый расход теплоносителя

изводится в заданные моменты времени. Одновременно может регистрироваться до сотен показаний различных датчиков. Такой объем данных требует соответствующих инструментов и технологий для обработки. На рис. 2 представлена архитектура информационной системы поддержки принятия решения с целью повышения энергоэффективности работы источников теплоснабжения. Инструментом потоковой передачи данных и их первичной обработки была выбрана платформа SAP ESP. Реляционные СУБД рассчитаны на сбор и хранение данных, которые затем требуется анализировать: фильтровать, сочетать, выявлять шаблоны, вычислять высокоуровневые сводки и т. д. В СУБД анализ выполняется автономно, т. е. не как ответ на поступающие события. SAP ESP преобразует все поступающие данные в потоки, обрабатываемые процессором. События, в свою очередь, привязываются к потокам и к временной шкале. В обработке событий применяется архитектура потоков данных, при которой входящие сообщения пропускаются через операторы запросов непрерывного действия; таким образом, результаты непрерывно обновляются. Средствами SAP HANA осуществляется контроль за отклонением параметров работы оборудования источника теплоснабжения (показателями эффективности, т. е. зависимыми переменными) от их удельных норм и пересчет математических моделей зависимостей показателей эффективности от переменных, отражающих рабочее состо-

Рис. 1. Природа энергоэффективности источников теплоснабжения

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

Real-Time Enterprise 2.0

UI5

ECC (IS-U)

BO 4.0

Oracle

SAP Landscape Transformation (SLT) ESP

11 систем

5.1 SP2

OKO Non SAP (top level MES)

SOI2 server

Oracle

Рис. 2. Реализация системы показателей энергоэффективности

SOI2 input adapter

HANA Hana output adapter

SAP PI яние отдельных узлов тепловой установки (независимых переменных). Алгоритм обработки данных в разрабатываемой системе представляет собой следующую последовательность: 1. На основании показаний приборов учета происходит постоянный мониторинг фактического расхода ресурсов на выработку тепловой энергии: расхода топлива и электроэнергии. Мониторинг реализуется посредством механизма контрольных карт Шухарта расхода электроэнергии и котельно-печного топлива. 2. Специальными правилами алгоритма контрольных карт выявляется тенденция к выходу контролируемых параметров за пределы границ стабильного функционирования системы. Первая точка обнаруженной тенденции становится сигналом для запуска механизма линейного регрессионного анализа формирования математической модели зависимости контролируемых параметров от состояния отдельных узлов установки. Одновременно происходит оповещение ответственного лица.

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

ЛИТЕРАТУРА 1. Абдульманов Р. Р., Максимюк Е. В., Микшина В. С. Подходы к созданию систем поддержки принятия решения реального времени в области энергоэффективности источников теплоснабжения // Инновационные информационные технологии: матер. междунар. науч.-практ. конф. / под общ. ред. С. У. Увайсова. — М.: МИЭМ НИУ ВШЭ, 2013. 2. Башлыков А. А., Бремеев А. П. Экспертные системы поддержки принятия решений в энергетике / под ред. А. Ф. Дьякова. — М.: Изд-во МЭИ, 1994. 3. Гулбрандсен Т. Х., Падалко Л. П., Червинский В. Л. Энергоэффективность и энергетический менеджмент: учеб.-методич. пособие. — Минск: БГАТУ, 2010. 4. Maksimyuk E. V., Mikshina V. S. Mathematical Methods And Algorithms For Decision Support To Ensure Energy Efficiency // Innovative Information Technologies: Materials of the International scientific — practical conference. Part 3. — M.: HSE, 2014.

100

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

Real-Time Enterprise 2.0

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

Дмитрий Игоревич Буслов Ведущий консультант, ЗАО «БДО Юникон Бизнес Солюшнс».

ИСПОЛЬЗОВАНИЕ SAPUI5 ПРИ РАЗРАБОТКЕ ПРИЛОЖЕНИЯ П О АНАЛИЗУ ТЕХНИКО-ЭКОНОМИЧЕСКИХ ПОКАЗАТЕЛЕЙ НА БАЗЕ SAP HANA

102

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

Real-Time Enterprise 2.0

ОАО «Сургутнефтегаз» бизнес-аналитике отводится особое место. В разное время специалисты компании использовали различные аналитические продукты, но всегда «Сургутнефтегаз» старался быть в авангарде предприятий, использующих передовые технологии в данной области. Этому способствовало тесное сотрудничество с компанией SAP. Бизнес-аналитика требуется в различных сферах деятельности компании — не стало исключением и управление персоналом. В настоящее время в ОАО «Сургутнефтегаз» в целях планирования расстановки численности по всем структурным подразделениям разработан программный комплекс для формирования лимитов численности. Данное программное обеспечение позволяет формировать различные варианты плана лимитов численности по всем организационным единицам всех структурных подразделений (далее по тексту — СП). Процесс формирования лимитов численности можно в очень упрощенном виде представить следующим образом: 1. На первом этапе ответственные специалисты СП создают вариант плана лимитов численности (копированием из факта) и вносят в него необходимые изменения. Вариант плана содержит рассчитанные значения показателей по всем организационным единицам СП: объемные показатели, оценочные и показатели среднесписочной численности. 2. Далее вариант плана попадает на рассмотрение к ответственному специалисту аппарата управления ОАО «Сургутнефтегаз» (управление организации и оплаты труда), который проверяет вариант плана и либо утверждает его, либо возвращает в СП на доработку. В случае утверждения вариант плана блокируется от изменений. 3. Далее специалисты формируют сводные проекты лимитов численности, технико-экономических и оценочных показателей по ОАО «Сургутнефтегаз» в целом и в разрезе СП и предоставляют их на рассмотрение Научно-технического совета ОАО на заседании секции «Экономика, организация труда, управление производством и нормирование труда». 4. Далее утвержденный пакет документов по каждому СП передается на рассмотрение Центральной комиссии ОАО. 5. Центральная комиссия рассматривает пакет документов и выносит решение по утверждению годового лимита численности и переходящего лимита на следующий планируемый год. В течение всего вышеописанного процесса в систему BW поступают данные для анализа по всем организационным единицам по различным версиям плана, в том числе и фактические данные (рис. 1). В итоге все полученные данные можно разбить на три группы: объемные показатели, оценочные показатели, показатели ССЧ (среднесписочной численности). Структура хранения данных в системе BW разработана с учетом интеграции с Библиотекой показателей. Большинство крупных ИТ-проектов, реализуемых в настоящее время в информационной системе ОАО «Сургутнефтегаз» на базе систем SAP, разрабатываются с учетом интеграции с Библиотекой показателей (рис. 2).

П.В. Ковалишин, Д.И. Буслов. Использование SAPUI5 при разработке приложения по анализу технико-экономических показателей на базе SAP HANA

103

Программный комплекс Формирование лимитов и плановой расстановки численности структурных подразделений ОАО «Сургутнефтегаз»

Исходные данные SAP HR

Версии планов лимитов численности Процесс согласования планового лимита численности структурного подразделения

SAP R/3

Portal C (ручной ввод)

Счет показателей

SAP BW

Аналитическая и строгая отчетность

Рис. 1. Поток данных в программном комплексе по формированию лимитов численности

Библиотека показателей представляет собой единое хранилище всех ключевых показателей оценки деятельности компании, которые определяются в процессе проектирования различных ИТ-решений. Показатели регистрируются в Библиотеке с набором всех необходимых атрибутов, именуемых паспортом показателя. Паспорт всесторонне описывает показатель, определяет его принадлежность к направлению деятельности, бизнес-процессу (информационной системе), классифицирует по различным признакам, определяет, в чьей зоне ответственности показатель находится. Паспорт включает общие для всех ИТ-решений атрибуты (наименование, единица измерения, уровни планирования, перечень аналитик и т. д.), а также атрибуты под конкретную информационную систему, в которой этот показатель используется. Если реализация ИТ-решения предполагается на базе Библиотеки, то помимо ключевых оценочных показателей создаются также все показатели, необходимые для их расчета. Ведение Библиотеки показателей осуществляется через портальное приложение (Portal CE) с хранением данных на уровне плоских таблиц в системе SAP BW. BW / Portal CE Проект Лимиты численности

Идентификатор показателя IND

Библиотека пользователей

Хранение показателей Классификация показателей Унификация показателей

Паспорт показателя

Рис. 2. Связь проекта по формированию лимитов численности с Библиотекой показателей

104

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

Real-Time Enterprise 2.0

Библиотека показателей обеспечивает: Единый центр хранения метаданных по показателям, структурирование показателей по различным параметрам: видам деятельности, логическим классам и пр. Хранение алгоритмов расчета показателей, хранение аналитических признаков, указания на источники данных и пр.; содержит указание на использующие показатель информационные системы. Закрепление ответственности за конкретными должностями (ролями) по ведению (алгоритмы расчета и источники данных) и наполнению показателей данными. Синхронизацию и сопоставимость данных в хранилище данных. Унификацию использования показателей. Создает основу для разработки систем управления, например применение технологии BSC. В процессе формирования и согласования лимитов численности структурных подразделений ОАО «Сургутнефтегаз» специалистам аппарата управления требуется проводить анализ значений технико-экономических показателей (далее по тексту — ТЭП) по лимитам численности в различных ракурсах (периоды, бизнессферы, версии плана и т. п.), в том числе с возможностью анализа по атрибутам показателей. Можно выделить следующие основные задачи «от бизнеса»: выверка данных; сравнение фактических и плановых значений показателей; сравнение плановых версий; анализ на основе данных библиотеки показателей; поддержка принятия решения. А также требования к ПО, реализация которых позволит выполнить требуемый анализ данных: каскадная фильтрация; анализ больших массивов данных (~10 млн записей); графическое и табличное отображение данных; сравнение фактических и плановых значений показателей; иерархическое представление данных; нечеткий поиск; каскадная фильтрация (каждый фильтр влияет на все последующие); быстрая и стабильная работа приложения; удобный интуитивно-понятный интерфейс. В процессе проектирования приложения для анализа ТЭП лимитов численности были рассмотрены различные аналитические продукты от компании SAP. Стоит более подробно остановиться на некоторых из них. BusinessObjects Webi Один из самых популярных продуктов от компании SAP, предназначенный для разработки аналитических форм с возможностью различного графического представления информации, предоставляющий инструменты разработки в среде web.

105

Web Intelligence прежде всего ориентирован на бизнес-пользователей и не требует специальных навыков (программирования, знания SQL, структуры баз данных, СУБД) при построении аналитических запросов или отчетов. Однообразие терминов и возможность использования их без участия ИТ-специалистов достигается за счет определения семантического слоя (юниверса) между пользователями и базой данных. Технология составляет основу для конечных пользователей при построении запросов и анализе данных, она сконцентрирована на бизнес-среде и позволяет использовать понятные, одинаковые для всех объекты. BusinessObjects Explorer Аналитическое приложение, которое позволяет быстро и точно получить ответы на бизнес-вопросы на основе корпоративных данных. С помощью средств поиска можно найти необходимые данные, содержащиеся в согласованных и содержательных наборах данных, известных как информационные пространства. Для поиска предусмотрены фильтры, а также возможности детализации информационных пространств и просмотра только необходимых данных с помощью расширенной визуализации или диаграмм. Lumira SAP Lumira — это программное обеспечение, предназначенное для визуализации и управления данными и поддерживающее режим point-and-click. Оно позволяет пользователям анализировать данные с помощью создания и совместного использования графической визуализации данных из нескольких источников без написания кода. Design Studio SAP BusinessObjects Design Studio представляет собой инструмент, помогающий создавать мобильные дашборды и другие приложения, используя HTML5. Design Studio позволяет быстро разрабатывать аналитические приложения и мониторы для веб-браузеров и мобильных устройств. Обладает обширным набором компонентов, а также простым для понимания скриптовым языком, позволяющим гибко определять взаимодействие между компонентами. В табл. 1 приведено сравнение некоторых возможностей указанных выше продуктов на момент написания статьи. Несомненно, все эти продукты обладают большим набором полезных инструментов, однако требуемый уровень гибкости и быстродействия был достигнут лишь при реализации пользовательского интерфейса на SAPUI5, базирующегося на платформе SAP HANA. В области обработки данных в реальном времени заложен большой потенциал для развития технологии хранилищ данных и обработки информации.

106

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

Real-Time Enterprise 2.0 BO Webi

BO Explorer

Lumira

Design Studio

Поддержка иерархий

есть (для BW)

нет

есть (без возможности выбора иерархии)

есть (только на этапе разработки)

Поиск в фильтрах

есть

есть (только точный)

есть

Скорость разработки

быстро

очень быстро

быстро

Мобильные устройства

экспорт в BO for mobile

есть

Ввод данных

нет

есть (в HANA)

только 1 запись SDK (beta)

Кастомизация

нет

возможность разработки своих диаграмм

Запуск приложения

с портала BO

клиент (online/ offline)

с портала BO или Net Weaver

Каскадные фильтры

нет

есть

есть (не работают с HANA)

Табл. 1. Сравнение продуктов SAP

HANA позволяет: производить обработку сложных запросов за считанные секунды; параллельно выполнять несколько запросов без ущерба для производительности; разрабатывать сложные прогнозные модели для нужд предприятия. Предпосылками для разработки приложения по анализу ТЭП лимитов численности на SAP HANA стали: большой объем данных (~50 млн записей); сложные запросы к данным; получение результатов в режиме онлайн. Отдельное внимание стоит уделить пользовательскому интерфейсу (User Interface, или UI). Он представляет собой совокупность элементов и компонентов программы, которые способны оказывать влияние на взаимодействие пользователя с программным обеспечением. К этим элементам можно отнести: инструменты управления; инструменты навигации; визуальный дизайн экранов; устройства и технологии ввода данных; обратную связь (всплывающие окна, подсказки) и др.

107

Рис. 3. R/2: Terminal Screens

Интерфейсы постоянно развиваются и совершенствуются. На рис. 3–10 представлена «историческая лестница» пользовательских интерфейсов от SAP. SAPUI5 обеспечивает универсальность, доступность с любого устройства без дополнительной установки клиента, гибкость, скорость, возможность использовать современные стили и менять их под Brandbook (регламентированное стилевое оформление) компании — всё это уже реальность, которую привнесли веб-технологии. HTML5 и JavaScript — вот основа, на которой базируется данная библиотека. На текущий момент традиционными и наиболее распространенными средствами ввода информации являются компьютерная мышь и клавиатура, хотя все большее распространение получают более естественные для человека способы взаимодей-

Рис. 4. R/3 Version 1.0, 1.1

108

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

Real-Time Enterprise 2.0

Рис. 5. R/3 Version 2, 2.1

Рис. 6. R/3 Version 3, 3.1

109

Рис. 7. R/3 Version 4

Рис. 8. R/3 Version 4.6

110

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

Real-Time Enterprise 2.0

Рис. 9. SAP NetWeaver Business Client

Рис. 10. SAPUI5

ствия, например, управление голосом. На конференции Google IO 2013 голосовой поиск выделялся как одно из перспективных направлений развития. На базе стандартных компонентов, расширенных возможностями браузера Google Chrome или Chrome frame (в случае использования Internet Explorer), считываются и распознаются голосовые команды (Google API). Далее, с использованием нечеткого поиска (fuzzy search) в SAP HANA, обнаруживается наиболее «близкая» команда; после подтверждения от пользователя она выполняется. (Таким образом могут заполняться стандартные фильтры приложения.)

111

То есть, если распознавание голоса от Google дополнено возможностями нечеткого поиска SAP HANA, вероятность достоверного восприятия команды существенно возрастает. Точность соответствия указывается с помощью весового коэффициента, рассчитываемого по формуле: score = bestMatchingTokenWeight · max (tokenScores) + (1 — bestMatchingTokenWeight) · · √(∑(tokenScore²) / (matchedTokenCount + excessTokenCount x excessTokenWeight))

Данная схема представлена как сценарий перспективного развития пользовательского интерфейса.

АРХИТЕКТУРА ПРИЛОЖЕНИЯ Приложение для анализа показателей хозяйственной деятельности состоит из следующих компонентов: Shell — оболочка веб-приложения, основной компонент; FilterDialog — панель фильтров; FilterBArea — фильтр бизнес-сферы; FilterDFromTo — фильтр даты; FilterGroup — фильтр группы наименований; FilterOrgUnit — фильтр оргединиц; FilterTask — фильтр задач; FilterVersion — фильтр версий; FilterMeasure — фильтр показателей; DisplayFilters — панель выбранных фильтров; Presentation — панель представления данных (таблица, графика); Chart — график; Table — таблица. Shell.view FilterDialog.view

FilterMeasure.view

DisplayFilters.view

FilterBArea.view FilterOrgUnit.view FilterTask.view FilterBundle.view FilterGroup.view FilterDFromTo.view

Presentation.view Chart.view

Table.view

FilterVersion.view

Рис. 11. Визуальное отображение

112

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

Real-Time Enterprise 2.0

OData сервис

Клиент

XSJS сервисы

инициализация Все значения фильтров, показателей

выбор значения фильтра Значения выбранных фильтров Актуальные значения признаков

выбор значения показателя Значения выбранных фильтров Список доступных показателей

актуализация данных графика Значения выбранных фильтров, показателей, выбранные столбцы Данные графика, таблицы

экспорт в Excel Значения выбранных фильтров, показателей, выбранные столбцы Файл Excel

OData сервис

Рис. 12. Клиент-серверная часть

Клиент

XSJS сервисы

Визуальное отображение интерфейса представлено на рис. 11. Взаимодействие клиентской и серверной части представлено на рис. 12. В платформу SAP HANA помимо базы данных также встроен сервер приложений — HANA Extended Application Services (сокращенно HANA XS), который обеспечивает возможность создания приложений, используя фронт-энд HTML5, JavaScript, SAPUI5 (пользовательский интерфейс) и бэк-энд OData, JavaScript, XMLA, напрямую извлекая данные из HANA с использованием SQL/SQLScript.

113

Контроллер

Вид

Модель

Рис. 13. MVC

Чтобы все приложения с использованием SAPUI5 были максимально унифицированы, понятны, удобны для разработки и поддержки, SAP рекомендует проектировать новые приложения с использованием паттерна MVC (Model-View-Controller, или Модель — Вид — Контроллер) (рис. 13). Модель Связь отображения (Вида) с данными приложения. Принимает запросы от Вида и обрабатывает данные. Не зависит от третьих элементов. Вид Отражает информацию на экране. Зависит от Модели. Контроллер Получает информацию и связывает Модель/Вид для выполнения необходимых действий. Зависит от Модели. Унификация (возможность доступа с любого устройства), веб-доступ с использованием протокола HTTPS (удаленный безопасный доступ), новые возможности (HTML5, CSS3 и т. д.), постоянное появление и расширение уже существующих элементов управления — основные преимущества новой платформы. Поэтому использование таких платформ как SAPUI5 будет одним из ключевых направлений развития пользовательских интерфейсов, в особенности для новых систем, построенных на технологии in-memory.

114

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

Real-Time Enterprise 2.0

ЛИТЕРАТУРА 1. SAPUI5 Developer Guide [Электронный документ]. — https://sapui5.netweaver. ondemand.com/sdk/#docs/guide/95d113be50ae40d5b0b562b84d715227.html. 2. Официальный блог Google Россия [Электронный документ]. — http:// googlerussiablog.blogspot.ru/. 3. SAP HANA Developer Guide (SP7). 4. История интерфейсов R/3 [Электронный документ]. — http://www. sapdesignguild.org/goodies/r3_history.asp.

ISBN: 978-5-906157-17-1

9 785906 157171 Постоянные изменения, происходящие в мире бизнеса, значительное сокращение цикла «идея — продукт», ускорение и интеграция бизнес-процессов заставляют предприятия всё чаще обращаться к концепциям гибкого предприятия (Agile Enterprise) и предприятия реального времени (Real Time Enterprise — RTE). Многих современных управленцев уже не устраивают вчерашние отчеты, получаемые из систем бизнес-аналитики, — менеджеры требуют инwформации о том, в каком состоянии находится предприятие сейчас, или даже «сию секунду». Однако традиционные технологии не способны обеспечить аналитику реального времени на том огромном объеме данных, которые хранятся в информационных системах крупного предприятия. Кроме того, упомянутые требования бизнеса не могут быть удовлетворены, когда информация вводится в эти системы со значительной задержкой после выполнения бизнес-операций. И это только две самые очевидные проблемы на пути к RTE — пути, который до конца еще не прошло ни одно предприятие в мире. В последние два года значительный прорыв был сделан в области систем управления базами данных, когда сразу несколько ИТ-компаний предложили свои решения по базам данных in-memory («в оперативной памяти»). Этот прорыв сделал возможной реализацию «предприятия реального времени» за реальные деньги, и концепция RTE сейчас переживает второе рождение — специалисты говорят уже об RTE 2.0. Поэтому вопросы, освещаемые в настоящем сборнике, весьма актуальны как с научной, так и с практической точек зрения. В сборнике статей представлены результаты разработки и внедрения принципов предприятия реального времени с применением инновационных технологий in-memory database, а именно SAP HANA, в крупной компании нефтегазового комплекса России. Авторы обсуждают актуальные вопросы: законы развития информационных систем и баз данных, методы и инструменты построения бизнес-аналитики реального времени, новые концепции хранения и обработки информации, практический опыт трансформации традиционного аналитического решения и построения решений для потоковой обработки событий. Большой интерес представляют статьи, описывающие генезис и эволюцию появления технологии in-memory в контексте понятия идеальности информационных систем и тенденций развития информационных технологий в области управления большими массивами данных, а также обсуждение перспектив развития технологий in-memory в нашей стране. Важно и то, что в статьях обосновывается влияние полученных результатов на бизнес-процессы. Сборник можно рекомендовать ИТ-специалистам и руководителям предприятий, магистрантам и аспирантам по направлению «Информационные технологии» для ознакомления с опытом практического применения технологий in-memory, а также с новыми подходами к реализации концепции предприятия реального времени. В. А. Сухомлин, доктор технических наук, профессор ВМК МГУ им. М. В. Ломоносова. Д‑р Штефан Зигг, SAP SE, Боннский университет.

2014