Решение аналитических задач с использованием SAP Hana Текст научной статьи по специальности «Компьютерные и информационные науки»

Евгений Николаевич Матвиенко

Инженер 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 'V

Сервер

приложений

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

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

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

Использование SAP HANA в качестве СУБД (рис. 2) способно ускорить процесс извлечения данных из БД. Но так как обработка данных по-прежнему выполняется на сервере приложений, принципиальных изменений производительности не будет.

с :> Z-отчет

1. Выборка 1

^ DB ^ е 2, Обработка 1 е э Клиент

3. Выборка 2

4. Обработка 2

n, Вывод результатов

Сервер ^

приложений

|С Z-отчет

1, Выборка 1

^ HANA ^ < 2, Обработка 1 е э Клиент

3, Выборка 2

— 4, Обработка 2

n, Вывод результатов 1—

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

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

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

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

Очевидно, что такая схема применима только в случае, если транзакционная си-

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

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

стема осуществляет чтение и запись данных в БД, находящуюся под управлением 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). Ее реализацию в реляционной БД обычно называют схемой «звезда». Состоит из таблицы фактов и таблиц измерений. Таблица фактов содержит меры, т. е. количественные по-

20 >

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

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

D_DATE

PK_DATE

DATE

DAY_OF_WEEK

DAY_OF_MONTH

MONTH

YEAR

IS_HOLIDAY FISICAI_MONTH

D_STORE

PK_STORE

NAME

STREET

CITY

COUNTRY

D_SALES

FK_DATE

FK_PRODUCT

FK_STORE

FK_CASHIER

FK_PAYMENT_METHOD

QUANTITY

PRICE

DOLLAR_AMOUNT

D_PRODUCT

PK_PRODUCT

DESCRIPTION

SUBCATEGORY

CATEGORY

D_CASHIER

PK_CASHIER

NAME

SURNAME

BIRTH_DATE

D_PAYMENT_METHOD

PK_PAYMENT_METHOD

DESCRIPTION

GROUP

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

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

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

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

Рис. 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

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

1) набор таблиц-источников и представлений-источников, откуда будут браться данные;

2) алгоритм извлечения и преобразования данных из источников;

3) формат таблицы, в виде которой данные будут возвращаться.

Алгоритмы преобразования данных и таблицы-источники инкапсулированы

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

На рис. 8 изображена схема real-time витрины данных, которая предоставляет аналитическую информацию, рассчитываемую на основе детализированных транзакционных данных в режиме реального времени.

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

Транзакционные данные реплицируются в SAP HANA из систем-источников один к одному, в режиме реального времени. Для настройки репликации данных из SAP-систем используется инструмент SAP SLT, для не-SAP систем — инструмент SAP SRS. Очевидно, что если транзакционная система в качестве основной БД использует БД под управлением SAP HANA, настраивать для нее репликацию не нужно.

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

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

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

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

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

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

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

КОРПОРАТИВНОЕ ХРАНИЛИЩЕ ДАННЫХ

Корпоративное хранилище данных (Data Warehouse) — это также база данных, используемая для анализа данных и построения отчетов, но которая, в отличие от витрины данных, содержит консолидированный, согласованный набор данных из всех информационных источников предприятия. Также корпоративное хранилище данных характеризуется следующим:

■ служит для поддержки принятия решений;

■ содержит как атомарные, так и агрегированные данные;

■ содержит как исторические, так и текущие данные;

■ данные не изменяются пользователями;

■ данные загружаются в хранилище с определенной периодичностью;

■ объединяет данные из множества предметных областей.

На рис. 9 изображена классическая архитектура построения корпоративного хранилища данных, предложенная Ральфом Кимболлом. Ядром этой архитектуры является система ETL. Консолидация данных осуществляется за счет использования так называемой корпоративной шины измерений, т. е. определенного набора согласованных измерений, используемых многомерными моделями предприятия (подробнее см. [4]).

Опять же, недостатком архитектуры является невозможность получить аналитику над наиболее «свежими» данными учетной системы вследствие временных задержек, создаваемых системой ETL.

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

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

Рис. 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.