HANA и BW 7.30 - Часть 1

Нечитайлов Юрий Вячеславович

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


Нечитайлов Юрий Вячеславович 18 октября 2011, 14:15

Автор: Томас Зурек(Thomas Zurek)

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

 

Обзор Части 1.

Обзор Части 2

  • Выявление площади под установку In-Memory в SAP BW
  • RDBMS + BWA становится единой HANA Box
  • Планирование In-Memory
  • In-Memory DSO
  • Заключение

Обзор In-Memory

Для начала давайте бегло рассмотрим основы in-memory computing (вычислений в оперативной памяти). С этой целью давайте обратимся к таблице, представленной на Рис. 1, которую я с благодарностью позаимствовал из презентации Энди Бехтольсгейма (Andy Bechtolsheim) для HPTS 2009. В таблице показано, как изменятся параметры ряда компонентов, согласно прогнозам полупроводниковой индустрии. См. ITRS.


Рис. 1: Маршрутная карта процессорных модулей (CPU module)

Достаточно посмотреть на две первые строки, "тактовая частота" (clock rate) и "ядра" (cores). Отсюда можно вывести две вещи:

  1. закон Мура (Moore's law) будет продолжать действовать.
  2. Однако он будет основан, скорее, на кратном изменении числа ядер процессора, нежели на тактовой частоте процессора, причем основной причиной этого изменения будет энергоэффективность.

Соображение, начинающееся со слова "однако", фундаментально и носит жесткий предписывающий характер для отрасли программного обеспечения, а именно: ключевым фактором в разработке архитектуры будущих процессоров будет параллелизм. Ответом SAP на этот вызов и стало то, что получило название in-memory computing (вычислений в оперативной памяти). Однако этот термин излишне выпячивает аспект оперативной памяти (main memory) и несколько заслоняет другие аспекты, которые имеют ключевое значение для преимуществ в производительности, которых удается достичь в данном контексте. Логика продвигается по следующим направлениям:

  • параллелизм: как видно из Рис. 1, ключевую роль играет поддержка многоядерных архитектур средствами параллелизма программного обеспечения;
  • in-memory: необходимым условием параллелизма является расположение релевантных данных близко к ядрам в локальной памяти;
  • колоночные структуры данных: они, в свою очередь, являются необходимым условием для возможности включать данные в оперативную память; колоночные структуры данных эффективны в отношении ввода/вывода и являются необходимым условием для следующего требования;
  • сжатие: колоночные данные можно сжимать более эффективно, чем строчные данные, благодаря более высокой степени повторяемости значений и, следовательно, более высокому потенциалу для сжатия;
  • назначение приоритетов приложений: этот фактор независим от предыдущих четырех технологических факторов и сводится к созданию инструмента, рассчитанного на приложения SAP; во второй записи в этом блоге в контексте BW будут приведены соответствующие примеры.

С моей точки зрения, последний элемент в рамках текущего обсуждения упускают из виду и недооценивают чаще всего. На самом деле в этом элементе раскрывается то, что многие компании уже давно и успешно выполняют, а именно - используют свойства, присущие основным приложениям, в целях ослабления некоторых традиционных ограничений RDBMS, чтобы строить инновационные кластеры по обработке данных, например, основанные на узлах MySQL или Hadoop. Частным случаем является теорема CAP; ознакомьтесь с несколькими примерами, внедренными Ebay, здесь. Решение BWA компании SAP - это еще один хороший пример, поскольку оно сконструировано в соответствии со схемой BW.

In-Memory @ SAP

Ответ компании SAP на потребность в новой архитектуре ПО - это ее программный компонент In-Memory Computing Engine (IMCE; aka NewDB). Я не хочу вдаваться в детали IMCE и думаю, что - для простых задач - вы можете рассматривать IMCE как

  • продукт эволюции BWA, хотя больше и не привязанный исключительно к BW,
  • внедрение компанией SAP базы данных in-memory DB, разработанной специально для приложений SAP,
  • полную автономную базу данных SQL,
  • OLAP-процессор для запросов MDX.

Далее, HANA  - это аббревиатура, обозначающая High Performance Analytical Appliance (высокопроизводительный инструмент для аналитики). Кроме того, несколько упрощая (хотя с технической точки зрения это не будет стопроцентно верно), вы можете рассматривать HANA следующим образом:

  • грубо говоря: IMCE как устройство
  • однако в HANA входит не только IMCE
  • HANA - это термин, который вы часто слышите от людей
  • до конца этой презентации мы примем, что: IMCE ≈ HANA (чтобы избежать излишней путаницы)

Как HANA затрагивает хранение данных

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

  1. Сегодня: EDW = RDBMS + X
    Это означает, что хранилище данных на предприятии (EDW) не тождественно системе базы данных, но требует дополнения (здесь оно обозначено как X). Под X вы можете представлять вручную написанный или сгенерированный специальными инструментами код, например,
    • программы экстракции
    • код DDL (такой, как операторы CREATE TABLE (создать таблицу))
    • ограничения, предписания по проверке
    • преобразования и гармонизация данных
    • определения процесса, календарные планы и мониторинг, обработка ошибок (в особенности - непротиворечивый перезапуск)
    • определения KPI
    • бизнес-семантика, например, правила конвертации валют или определения финансовых годов
    • управление общими и частными измерениями, в том числе - иерархиями
    • определение и интерпретация семантики в заголовках таблиц и столбцов, например,
      • столбец X - это родительский столбец иерархии H вида 'parent-child', привязанной к измерению D
      • столбец Y - это показатель позиции со связанной позицией, которая хранится в столбце U
      • столбец Z - это свойство членов измерения, ключ которых - составное значение в столбцах A и B
      • в таблице T содержатся составленные на естественном языке описания ключей членов измерения,  в соответствии с чем столбец L обозначает язык, а столбец C - описание
      • столбец P в таблице Q - это внешний ключ членов измерения D; непротиворечивость ссылок гарантируется (да/нет)
      • семантика времени и календаря, например, основанная на иерархиях, таких, как "день - месяц - квартал - год" или "неделя - год"
    • управление таблицами и данными, например, определение стандартов хранения измерений (таблиц и соответствующих им форматов (layouts)), стандартов индексирования и/или разделения этих таблиц
    • жизненный цикл (метаданных) моделей и таблиц, например, создание версий; изменения, в том числе - анализ влияния, и распространение, разработка / тестирование / наладка производства
    • жизненный цикл (данных): архивирование и необходимое для него управление архивами (что было заархивировано, а что - нет; избежание пересечения контейнеров данных и т.д.)
    • безопасность, в особенности - моделирование и управление на основе более высоких концептуальных уровней, например, измерений, членов, иерархий
    • записи в журнале, аудит и иные особенности, связанные с соответствием
    • и т.д. и т.п.

Одним словом, X ответственно за удовлетворение этих требований. Это может быть объединение сгенерированного кода, определений метаданных, вручную написанных программ и т.д. BW - это готовый к использованию вариант X.

  1. Теперь: RDBMS ⇒ HANA
    Это выражение означает, что технология RDBMS перерабатывается с помощью in-memory computing (вычислений в оперативной памяти), внедренных в HANA.
  2. Таким образом: (новый) EDW = HANA + Y
    Теперь п.1 и п.2. объединяются в п.3. Поскольку HANA не является точной, один-к-одному, заменой RDBMS и поскольку изменяются ограничения и физические правила in-memory computing (вычислений в оперативной памяти) - особенно модель затрат на производительность, - программное обеспечение, которое играет руководящую роль (т.е., то, что ранее было обозначено как X), должно быть перенастроено так, чтобы оно учитывало новые ограничения и правила. Этот шаг мы обозначаем заменой X в п.1 на Y в п.3. И все же Y должен решать те же вопросы, что и X, но по-другому. Помимо этого, новыми ограничениями и правилами порождаются новые, расширенные, возможности в Y по сравнению с X. Это смена парадигмы, которую можно сравнить с переходом от аналоговой к цифровой фотографии. Просто представьте себе все разнообразие новых возможностей, которые предоставляет нам цифровая фотография сегодня!
    BW будет следовать путем преобразования от X к Y, адаптируя его для HANA. Первые шаги можно будет наблюдать с появлением реализации HANA BW 7.3, запланированной на конец 2011 года.

Сценарии HANA

По своему опыту могу сказать, что слайды, представленные на Рис. 2, 3 и 4 чрезвычайно полезны, поскольку они провоцируют плодотворные обсуждения с клиентами. В основных чертах я обсудил Рис. 2, 3 и 4 в своем блоге The BW-HANA Relationship(Отношение BW и HANA). Пожалуйста, обратите внимание на то, что не существует "лучшего" сценария, но каждый из сценариев, представленных на Рис. 2, подчеркивает некоторое свойство в ущерб остальным. Таким образом, за этими сценариями уже стоят готовые решения. Это смущает многих клиентов, ожидающих от SAP простого ответа на свои затруднения. Но я думаю, что эта ситуация сродни покупке машины: вам приходится взвешивать различные аспекты для выбора модели, которая будет соответствовать вашим конкретным целям.


Рис. 2: Сценарии HANA.

 


Рис. 3: Сценарии HANA и соответствующие им компромиссные варианты (trade-offs).

HANA как BWA

Возникало немало вопросов о соотношении BWA и HANA, например, будут ли новые версии BWA, не пропадут ли инвестиции в BWA, и т.д.. Базовый план состоит в том, чтобы приспособить HANA к тому, что она в будущем будет играть роль BWA. Иными словами: в 2012 (это план!) должна появиться возможность купить пакет HANA, который можно будет настроить и сконфигурировать его для работы в качестве акселератора, подобно тому, как это было с BW и BWA.

В связи с этим возникает два варианта введения HANA в существующий ландшафт BW 7.3 - обратите внимание на то, что версия 7.3 - это необходимое требование для запуска BW с HANA:

  • "консервативный подход" (две маленьких стрелочки на Рис. 4): вы можете применить HANA в качестве акселератора для вашего существующего BW. При выборе этого подхода вы приобретете уверенность при работе с HANA, научитесь управлять HANA и уже на этом этапе получите большое количество преимуществ Например, в HANA есть вычислительная система (calculation engine), улучшенная по сравнению с этой программой в BWA.
  •  "прогрессивный подход" (длинная стрелка на Рис. 4): он заключается в перемещении сервера DBMS, лежащего в основе вашей системы BW, в HANA. BWA как акселератор устаревает, поскольку HANA уже включает в себя вычислительные возможности BWA.


Рис. 4: Варианты миграции из классического BW к BW, основанному на HANA.

Заключение

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

Томас Зурек (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/25122

← Назад