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

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

Обзор Части 2 Выявление площади под установку In-Memory в SAP BW RDBMS + BWA становятся единым пакетом HANA Планирование In-Memory Объекты хранения данных In-Memory (In-Memory DSO) Заключение

Выявление площади под установку 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 на механизм планирования и на слой организации хранилищ данных.

Рис. 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 (т.е. ближе к данным),