Комментарии по теме

«Будущее SAP»
Артем Седловский:
Добрый день всем! Интересная философская статья. Позволю себе ответить на вопросы, заданные в конце. К сожалению, в развитии продуктов и особенно в приобретениях лично я наблюдаю отсутствие...
«По­дклю­че­ние новых типов объектов, доступных для тра­нза­кции MASS – массового изменения данных в SAP ERP»
Олег Точенюк:
Стандартные полномочия на объекты при вызове BAPI проверяются и как и положено согласно заданным у пользователя ролям, так что пользователь изменить к примеру данные карточек ОС, если у него есть...
«Цикл первый. «Це­ле­со­о­бра­зно­е» внедрение ERP системы. Статья первая. «Новый подход»»
Александр Дублин:
1. Увы, Вы поняли нас неправильно. ТОС - это не "развитие тем", а теория (методология), которая даёт инструменты для анализа ситуаций (проблем бизнеса), в том числе таких: -  Почему...

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь
Нечитайлов Юрий

Исследование зарубежного опыта

Все публикации автора

HANA и BW 7.30 - Часть 2

25 октября 2011, 13:05

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

Обзор Части 1

  • Обзор In-Memory
  • In-Memory @ SAP
  • Как HANA влияет на хранение данных (Data Warehousing)
  • Сценарии HANA
  • HANA как BWA
  • Заключение

Обзор Части 2

Выявление площади под установку In-Memory в SAP BW

Давайте сперва обратимся к 2003 году, когда усилия по разработке in-memory были начаты с BW и привели к созданию BWA (aka HPBI, HPA, BIA), который впервые был представлен на SAP Teched 2004. Понимание этой эволюции позволит вам понять подоплеку и будущих шагов развития.

На Рис. 1 представлена схема, в строках которой перечислены различные слои BW, а в столбцах - недавние версии. Вы можете заметить, что первоначальные инвестиции концентрировались вокруг тех областей, которые были естественными первыми целями, а именно - вокруг обработки запросов SQL, поддерживающей запросы, основанные на инфокубах. С появлением BWA 7.2 это стало возможно расширить на мультипровайдеров, и де-факто появилась поддержка объектов хранения данных (DSOs) с помощью гибридного провайдера. Обратитесь к этому документу для получения подробной информации по сочетанию BW 7.3 / BWA 7.2. Не ограничиваясь последним, ниже я приведу несколько примеров влияния in-memory на механизм планирования и на слой организации хранилищ данных.

Evolving In-Memory Footprint in SAP BW
Рис. 1: Выявление площади под установку In-Memory в SAP BW

RDBMS + BWA становятся единым пакетом HANA

У перехода от настройки BW, основанной на классическом сервере RDBMS, дополненном BWA, к системе BW, надстроенной над единым сервером HANA с объединенными возможностями, имеются определенные преимущества. С технической точки зрения, единство сервера HANA устраняет необходимость в поддержании непротиворечивости между двумя серверами (как это было с RDBMS и BWA). Это особенно интересно для планирования сценариев (восстановления) и значительно упрощает задачу. С точки зрения администратора ситуация более двусмысленна: некоторым клиентам BW нравится разделение, которое заключается в том, что RDBMS отвечает за хранение, а BWA - соответственно за загрузку запросов. С другой стороны, необходимо поддерживать два сервера, двойную установку аппаратного оборудования и лицензий.

Планирование In-Memory

Давайте обратимся к группе свойств, которые идут дальше традиционных выдающихся преимуществ соответственно HANA или BWA в отношении производительности, а именно - к эволюционированию BW-IP в in-memory.

На Рис. 2 представлен самый простой пример операции планирования: перед конечным пользователем отображается набор ячеек, а он решает увеличить одно из значений с 250 до 300. Что происходит после того, как это изменение сообщается серверу? Помните о том, что планирование, как правило, выполняется на агрегированных гранулах (в данном случае - на странах и годах), а данные в примере с Рис. 2 значительно более подробны: страны подразделяются на филиалы, а годы - а недели. Это значит, что изменение одного значения в UI часто приводит к большому числу изменений на уровне данных. Это называется дезагрегацией (disaggregation) и представляет собой частые действия в контексте планирования.

При традиционном подходе, который предполагает, что обработка выполняется, в основном, на сервере приложений, рассчитывается дельта изменения (в данном случае - увеличение на 50), а затем дельта разбивается по фактическим гранулам данных (в данном случае - по 52 неделям в 2011 и 500 филиалам в Германии), что приводит к потенциально большому числу значений (в данном случае - 52 * 500 = 26000), а затем эти значения отправляются через сеть в RDBMS для сохранения.

При подходе, основанном на in-memory, обработка передается вниз, в HANA (т.е. ближе к данным), благодаря изменению шагов 2 и 3, т.е. лишь одно значение (в данном случае - 50) отправляется в механизм БД вместе с инструкцией по дезагрегации и связанными с ней параметрами. Причинами выигрыша в производительности этого подхода является следующее:

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

Этот пример основан на очень общей схеме, которую можно применить и во многих других областях. Некоторые коллеги используют такие термины, как отправка данных (data shipping) (традиционный подход) vs отправка функций (function shipping) (подход in-memory).

A 'Hello World' planning example
Рис. 2: Сравнение традиционного подхода и подхода in-memory на простейшем примере планирования

Объекты хранения данных In-Memory (In-Memory DSO)

Схема, показанная на примере планирования in-memory, а именно - (а), предназначенная для того, чтобы избежать пересылки огромных объемов данных между приложением и серверами БД, и (b), предназначенная для внедрения операций, требовательных к производительности, напрямую в структуры данных, основанные на этом механизме, - может также применяться и к объекту хранилища данных (data store object, DSO) BW. Для этой цели имеет смысл вспомнить, как (концептуально) работает объект хранилища данных и где производительность становится решающим фактором. На Рис. 3 показано, как работает объект хранилища данных:

  • Есть 3 контейнера данных:
    • один - для текущих данных - текущее изображение (current image),
    • один - для недавно загруженных данных - будущее изображение (future image) и 
    • один - для результата, когда будет рассчитываться разница между текущим и будущим изображениями, - дельта-изображение (delta image), результат активации данных.
  • В традиционном RDBMS эти 3 контейнера соответственно представлены в таблице.
  • Над объектами хранилища данных производится четыре фундаментальных операции:
    • загрузка новых данных;
    • запрос текущих данных;
    • считывание текущих данных;
    • активация - см. выше.

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

Traditional DSO
Рис. 3: Традиционный объект хранилища данных (DSO)

Объект хранилища данных внедрен в HANA в исходном формате. На Рис. , по существу, показано, что (этот новый) объект хранилища данных внедрен в качестве "черного ящика", который ведет себя как традиционный объект хранения данных, показанный на Рис. 3 и описанный выше. Операции выполнения запросов (querying) и дельта-считывания (delta read) становятся логическими ракурсами (views) в дополнение к "черному ящику". Операция загрузки (upload) выполняется напрямую. Активация данных (data activation) внедрена в исходном формате и демонстрирует значительный выигрыш в производительности. Как было показано, источники этого выигрыша - уменьшение трафика данных и внедрение в исходном формате.

In-Memory DSO
Рис. 4: Объект хранения данных In-Memory

Заключение

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

Томас Зурек (Thomas Zurek)  Active Contributor Silver: 500-1,499 points - вице-президент отдела исследований и разработок SAP BW и аналитических частей HANA.


Перевод выполнен издательством ООО "Эксперт РП" для портала www.SAPLand.ru Английская версия была размещена на сайте SAP AG по адресу

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/25123