В прошлую пятницу, 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).
Затем пришло время другим решениям от SAP переходить на новую платформу. Сначала появились продукты SAP Business Suite on (powered by) SAP HANA, а сейчас - SAP S4/HANA (рис. 2).
Таким образом, решения 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 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 варианта проектирования:
Первое решение дорогое, второе дешевле и более гибкое.
Выделяют 2 архитектуры разворачивания:
Виртуализация не рекомендуется для SAP HANA, а отказоустойчивый кластер, наоборот, настойчиво рекомендуется.
В SAP HANA есть свой WebAS. Весь инструмент работы с SAP HANA переводится в Web.
Текущий инструмент, SAP HANA Studio не имеет будущего.
Примеры установки и использование SAP HANA можно посмотреть на рис. 3.
Есть проблема с лицензированием BW4/HANA - полностью изменена модель: с пользователей на лицензирование по объему памяти.
Для того, чтобы предварительно посмотреть SAP HANA можно использовать:
Автор: Шиболов Вячеслав Анатольевич
Сразу скажу, что я ни разу не пожалел о своём посещении. На этот мастер-класс я пытался попасть ещё весной 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 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 ведется именно на ней.
Возможно 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.
Автор: Шиболов Вячеслав Анатольевич
>Нет нужды в индексах
ОтветитьУдалитьэто видимо, какая-то неточность/ошибка.
Владимир, на сколько я понял, автор имел в виду именно в классическом смысле реляционной СУБД. Они не нужны для увеличения производительности при чтении из базы. На сколько я понял, они используются при записи.
Удалитьиндексы в в классических реляционных SQL и в noSQL, newSQL БД используются для ускорения поиска, чтения и формирования выборки данных. При записи, индекс создает дополнительную нагрузку, к основной операции вставки/изменения данных, независимо от типа БД. In-memory engines подразумевают другие способы хранения и обработки данных, нежели классические РСУБД, в т.ч. и индексов для этих данных, но не отказ от использования индексов.
ОтветитьУдалитьСпасибо Владимир за комментарий. В одних и тех же решениях, например ERP на ORACLE и S4/HANA количество индексов соизмеримо?
УдалитьИнтересный вопрос. 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 - т.е. для некоторых видов операций, да, это справедливо - другой вид хранения данных для оптимизации операций с ними, да, можно отказаться от части индексов, сделать индексы неявными. Но для конкретного предприятия, с его конкретной спецификой операций - не факт что данный тип организации данных и работы с ними будет оптимален, что, собственно неоднократно подтверждается на практике.
УдалитьIn addition to the comments, only column store tables do not use indexes.
ОтветитьУдалитьПро 2025 год - если сравнить стоимость железа для SM7.2 на Oracle и на HANA, то возникают сомнения в целесообразности перехода на HANA в некоторых случаях, не говоря о том, что поколоночное хранение HANA ориентировано на OLAP, а не OLTP (ERP) системы. Кроме того, с учетом быстрого роста хранимых данных и стоимости ОЗУ, рано или поздно встанет вопрос о выведении части данных из HANA и периодической их загрузки обратно, что создаcт дополнительные накладные расходы.
ОтветитьУдалитьДа, всё не так однозначно. И SAP HANA накладывает определенные ограничения.
Удалить