30 октября 2017 г.

Мастер-класс по архитектуре SAP HANA

В прошлую пятницу, 27 октября, я посетил мастер-класс "Архитектура решений на SAP HANA. Рекомендации". Мастер-класс проводился в рамках осенней сессии мастер-классов SAPLAND. Попал я на него бесплатно, как автор статей на портале. За что порталу отдельная благодарность.

Сразу скажу, что я ни разу не пожалел о своём посещении. На этот мастер-класс я пытался попасть ещё весной 2017 года, но, к сожалению, его тогда отменили - в последний момент оказалось только 2 участника. В этот раз было 11 человек. Отдельно хочу отметить ребят из "М-Видео", которые активно делились опытом использования BW on SAP HANA.

Организация семинара была осуществлена на базе учебного центра "Специалист при МГУ им. Н. Э. Баумана". В целом за организацию можно поставить твёрдую четвертку. Учебные классы хорошие, хотя участие в мастер-классе было пассивное, никаких практических заданий не было. Чай-кофе, вода, раздаточные материалы. Девушки из SAPLand, я считаю, отработали на 5. Понятное дело, что сравнение с учебным центром SAP в Москве некорректно, туда вложено больше денег и уровень там другой. Ну и для однодневного семинара это всё не так принципиально.

Автору мастер-класса Михаилу Вронскому отдельное спасибо. Материал был объёмный и при этом всё крайне полезно. Работали практически без перерывов, чтобы всё успеть. Было много практических рекомендаций и обсуждения опыта автора и участников. Я бы даже сравнил количество материала с 2-3 днями хорошего семинара. Только практики не было.

Небольшие заметки по мастер-классу (это лишь 10 % того, что там было :) ).

SAP HANA - база данных с поколоночным хранением данных и обработкой в оперативной памяти. Была впервые представлена в 2011 году. После этого на работу с данной базой данных была переведена система SAP BW. Решение носило название SAP BW on (powered by) SAP HANA или BWoH. Затем решение было полностью интегрировано в платформу SAP HANA и решение стало носить название SAP BW4/HANA (рис. 1).

Рис. 1. Эволюция решений SAP BW, использующих платформу SAP HANA.

Затем пришло время другим решениям от SAP переходить на новую платформу. Сначала появились продукты SAP Business Suite on (powered by) SAP HANA, а сейчас - SAP S4/HANA (рис. 2).

Рис. 2. Эволюция решений SAP Business Suite, использующих SAP HANA.

Таким образом, решения SAP BW4/HANA и SAP S4/HANA являются продуктами, в которых интеграция с платформой SAP HANA достигла такого уровня, что эти продукты могут работать только на ней. Эти решения используют новую модель данных, оптимизированную под SAP HANA.

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

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

При поколоночном решении обеспечивается хорошее сжатие данных и быстрый поиск. Нет нужды в индексах (для таблиц с поколоночным хранением), убраны некоторые таблицы (например, pool и кластерные).

Соответственно, систему SAP BW проще перевести на BW4/HANA, ERP сложнее. Хороший вариант: перевнедрение - установить систему рядом и переносить данные перед стартом в промышленную эксплуатацию.

Для OLAP систем - автор рекомендует переходить на SAP HANA, для OLTP систем можно не спешить, надо взвешивать все за и против. Особенно для высоко-нагруженных систем.

Есть решение ORACLE in-memory, когда в памяти выделяется область для копирования таблиц в поколоночное хранение. Это увеличивает скорость работы. Но в SAP HANA идет изменение модели хранения и изменение кода.

На данный момент поддерживаются следующие версии SAP HANA:
  • SAP HANA 1.0 SPS12 (поддержка до 2021 года),
  • SAP HANA 2.0 SPS01,
  • SAP HANA 2.0 SPS02.

Версию SAP HANA 2.0 пока поддерживают не все системы.
Новый график выхода версий (SPS) - раз в год (апрель).

Оборудование (для продуктивных систем): только х86_64 (для HANA 2.0 от Intel Haswell и выше) и ограниченная поддержка IBM Power (для HANA 2.0 IBM Power 8). Всё оборудование должно быть сертифицировано SAP (до конкретной модели сервера). Системы хранения данных тоже только сертифицированные.

Операционные системы: только Linux - SLES или RHEL и только определенных версий.
В качестве ОС, автор рекомендует SLES, так как разработка SAP NetWeaver и SAP HANA в SAPLabs ведется именно на ней.

Подробности в PAM.

Возможно 2 варианта проектирования:
  • покупка готового решения (Appliance): готовый сервер+СХД+все оборудование, предустановленная SAP HANA, запуск, обучение.
  • конфигурация всего по отдельности (Tailored Data Center или TDI): покупка оборудования, системы, монтаж, установка, запуск. 

Первое решение дорогое, второе дешевле и более гибкое.


Выделяют 2 архитектуры разворачивания:
  • Scale-up - одна HANA нода. Рекомендуется для SAP ERP on HANA. Более производительное решение, но для апгрейда требует замену полностью всего оборудования на новый Applience. 
  • Scale-out - несколько HANA нод, объединенных в одну базу. Рекомендуется для BW on HANA и BW4/HANA. Позволяет наращивать объем памяти через добавление новых нод. Так же добавляет некоторую отказоустойчивость.

Виртуализация не рекомендуется для SAP HANA, а отказоустойчивый кластер, наоборот, настойчиво рекомендуется.

В SAP HANA есть свой WebAS. Весь инструмент работы с SAP HANA переводится в Web.
Текущий инструмент, SAP HANA Studio не имеет будущего.

Примеры установки и использование SAP HANA можно посмотреть на рис. 3.

Рис. 3. Примеры разворачивания и использования платформы SAP HANA.

Есть проблема с лицензированием BW4/HANA - полностью изменена модель: с пользователей на лицензирование по объему памяти.

Для того, чтобы предварительно посмотреть SAP HANA можно использовать:
  • SAP HANA Express edition (в виде самостоятельной установки или готового образа ВМ),
  • SAP Solution Manager 7.2 on SAP HANA 1.0.

Автор: Шиболов Вячеслав Анатольевич


8 комментариев:

  1. >Нет нужды в индексах
    это видимо, какая-то неточность/ошибка.

    ОтветитьУдалить
    Ответы
    1. Владимир, на сколько я понял, автор имел в виду именно в классическом смысле реляционной СУБД. Они не нужны для увеличения производительности при чтении из базы. На сколько я понял, они используются при записи.

      Удалить
  2. индексы в в классических реляционных SQL и в noSQL, newSQL БД используются для ускорения поиска, чтения и формирования выборки данных. При записи, индекс создает дополнительную нагрузку, к основной операции вставки/изменения данных, независимо от типа БД. In-memory engines подразумевают другие способы хранения и обработки данных, нежели классические РСУБД, в т.ч. и индексов для этих данных, но не отказ от использования индексов.

    ОтветитьУдалить
    Ответы
    1. Спасибо Владимир за комментарий. В одних и тех же решениях, например ERP на ORACLE и S4/HANA количество индексов соизмеримо?

      Удалить
    2. Интересный вопрос. DD12L? Я работал с ERP on HANA + SAP Simple Finance. Работа с индексами была в нормальной работе базиса. С другой стороны есть такое https://blogs.sap.com/2013/12/29/6-golden-rules-for-new-sap-hana-developers/ - что в принципе верно для одного типа операций, недаром Hasso chuckles, “because I am a renegade and I wanted to do something different, I made a proposal to completely get rid of pre-aggregated totals, 40 years of aggregates, which was too radical a proposal then. – The Beginning of SAP HANA - т.е. для некоторых видов операций, да, это справедливо - другой вид хранения данных для оптимизации операций с ними, да, можно отказаться от части индексов, сделать индексы неявными. Но для конкретного предприятия, с его конкретной спецификой операций - не факт что данный тип организации данных и работы с ними будет оптимален, что, собственно неоднократно подтверждается на практике.

      Удалить
  3. In addition to the comments, only column store tables do not use indexes.

    ОтветитьУдалить
  4. Про 2025 год - если сравнить стоимость железа для SM7.2 на Oracle и на HANA, то возникают сомнения в целесообразности перехода на HANA в некоторых случаях, не говоря о том, что поколоночное хранение HANA ориентировано на OLAP, а не OLTP (ERP) системы. Кроме того, с учетом быстрого роста хранимых данных и стоимости ОЗУ, рано или поздно встанет вопрос о выведении части данных из HANA и периодической их загрузки обратно, что создаcт дополнительные накладные расходы.

    ОтветитьУдалить
    Ответы
    1. Да, всё не так однозначно. И SAP HANA накладывает определенные ограничения.

      Удалить