Sap hana что это такое
SAP HANA. О преимуществах колоночного хранения
В данной статье мы кратко рассмотрим основные преимущества колоночного хранения, реализованного в базе данных HANA.
Реляционные базы данных обычно используют строковый тип хранения. SAP HANA использует как строковый так и колоночный тип хранения информации. При этом, в процессе создания таблицы без явного указания типа, в БД будет создана таблица с типом COLUMN. В SAP HANA эти два типа таблиц имеют большие отличия с точки зрения администратора базы данных, в то время как для разработчика эти различия не всегда очевидны.
Колоночно-ориентированные базы данных больше, чем традиционные, ориентированные на строковое хранение данных, подходят для аналитических задач, в таких областях как большие хранилища данных, поддержка принятия решений, предиктивная аналитика и т. д.
Память компьютера организована в виде линейной последовательности. Классические row-store таблицы хранятся в виде последовательности записей, содержащих поля одной строки. При колоночном хранении записи, колонки хранятся в непрерывных ячейках памяти. На рисунке ниже показана разница хранения в памяти между строковой и колоночной таблицами.
Представление хранения данных в памяти (Column vs Row)
Основная разница в типах хранения заключается в операциях чтения, которые при колоночном типе хранения более эффективны чем при строковом типе.
Помимо различий при операциях чтения, колоночные таблицы имеют ряд преимуществ:
Высокий коэффициент сжатия данных
Высокая производительность при операциях чтения
Исключение дополнительных индексов
Ниже мы детальнее рассмотрим некоторые особенности колоночного хранения, позволяющие увеличить производительность в операциях чтения.
Компрессия
Данные, хранящиеся в колонках более сжаты по отношению к строковому хранению. Объясняется это тем, что алгоритм сжатия лучше работает с данными с низкой энтропией. Высокая степень сжатия оказывает позитивное влияние на работу базы данных, так как сокращается объем данных, которые необходимо передать от оперативной памяти RAM к CPU.
В данном случае речь пойдет о самом распространённом типе сжатия в SAP HANA (он же тип сжатия по умолчанию) – Dictionary (сжатие на основе словаря). Это единственный тип сжатия, работающий как в Main, так и в Delta store. Техника сжатия, основана на кодировке словаря, где содержимое поля хранится в виде закодированных целых чисел в векторе атрибутов. В данном контексте это означает «перевод» содержимого поля в целочисленное значение.
Тип сжатия для интересующей вас таблицы (поля таблицы) можно посмотреть в представлении M_CS_COLUMNS поле COMPRESSION_TYPE.
Внимание! Тип сжатия определяется на уровне поля. Таким образом одна таблица по разным полям может иметь разные типы сжатия.
Для хранения содержимого поля SAP HANA создает по крайней мере две структуры данных: вектор словаря и вектор атрибута. Вектор словаря хранит каждое значение поля только один раз. Предположим у нас есть следующая таблица:
В таком случае словари (Dictionary) полей «Last Name» и «Location» будут выглядеть следующим образом:
Аттрибуты словаря (поля Last Name, Location)
При этом, только данные, закрашенные тёмным цветом, будут непосредственно храниться в памяти. Как мы видим повторяющиеся значения хранятся только один раз.
Вектор атрибута хранит только значения типа integer, которые указывают на позицию в словаре. Соответствующие векторы атрибутов будут выглядеть так:
Вектор атрибута Last Name Вектор атрибута Location
Поддержка параллельных операций
В строковом хранении, при обработке нескольких строк, сперва идет чтение каждой строки, а затем выгрузка необходимых атрибутов и представление в интерфейсе. При колоночном хранении операции выполняются параллельно, используя несколько процессорных ядер. Данные, хранящиеся в колонках уже вертикально секционированы, таким образом операции над колонками могут быть выполнены параллельно.
В колоночном хранении операции по колонкам, такие как поиск или агрегация, могут быть выполнены в циклах по массиву, хранящемуся в смежных ячейках. Подобные операции могут эффективно выполняться в кэше CPU. Операция с данными в виде массива не только минимизирует накладные расходы, но также раскрывает потенциал для паралеллизации на уровне CPU. Дополнительно, операции на одной колонкой, могут быть выполнены параллельно в случае, если эта колонка разделена (секционирована). В этом случае операции над колонкой могут быть выполнены параллельно сразу несколькими ядрами CPU. На рисунке ниже представлены возможности для распараллеливания операций над колонками в таблице с колоночным хранением в SAP HANA.
Возможности для выполнения параллельных операций при колоночном хранении
Поздняя материализация
Материализация – это процесс формирования результата, ответа на запрос. При ранней материализации мы сперва получаем поля и формируем из них таблицу(ы). Если таблиц несколько, выполняется операция Join. Таким образом таблицы соединяются по определенному условию. Если речь идет про аналитические задачи, то после этого мы получаем промежуточный результат с большим количеством данных, которые потом по которым потом применяется фильтрация.
При поздней материализации мы сначала фильтруем ненужные данные из одной или нескольких таблиц, а потом соединяем данные в промежуточной таблице, размер которой будет существенно меньше. Поздняя материализация более предпочтительна для задач по аналитике.
Итоги
Как развернуть SAP HANA: разбираем разные методы
SAP HANA — популярная in-memory СУБД, включающая сервисы хранилищ (Data Warehouse) и аналитики, встроенное промежуточное ПО, сервер приложений, платформу для настройки или разработки новых утилит. За счет устранения задержек традиционных СУБД с SAP HANA можно сильно увеличить производительность систем, обработку транзакции (OLTP) и бизнес-аналитику (OLAP).
Развернуть SAP HANA можно в режимах Appliance и TDI (если говорить о продуктивных средах). Для каждого варианта у производителя есть свои требования. В этом посте мы расскажем о преимуществах и недостатках разных вариантов, а также для наглядности — о наших реальных проектах с SAP HANA.
SAP HANA состоит из 3 основных компонентов – хоста, инстанса и системы.
Хост — это сервер или операционная среда для работы СУБД SAP HANA. Его обязательные компоненты — CPU, ОЗУ, СХД, сеть и ОС. Хост предоставляет ссылки на директории инсталляции, данных, логов или непосредственно на СХД. При этом СХД для инсталляции SAP HANA не обязательно должна располагаться на хосте. Если у системы несколько хостов – потребуется либо общее хранилище, либо такое, что доступно по требованию со всех хостов.
Инстанс — набор системных компонентов SAP HANA, установленных на одном хосте. Основные компоненты — это Index Server и Name Server. Первый, который называется также «рабочим сервером», обрабатывает запросы, управляет актуальными хранилищами данных и ядрами БД. Name Server хранит информацию о топологии инсталляции SAP HANA — о том, где работают компоненты и какие данные находятся на сервере.
Система – это один или несколько инстансов с одинаковым номером. По сути это отдельный элемент, который можно включить, отключить или скопировать (сделать резервную копию). Данные распространяются в памяти различных серверов, которые составляют систему SAP HANA.
Система может быть сконфигурирована как однохостовая (один инстанс на одном хосте) или мультихостовая, распределенная (несколько инстансов SAP HANA распределены по нескольким хостам, на каждый хост приходится по одному инстансу). В мультихостовых системах каждый инстанс должен иметь один и тот же номер. Система SAP HANA идентифицируется с помощью System ID (SID) – уникального номера, состоящего из трех буквенно-цифровых символов.
Виртуализация SAP HANA
Одним из главных ограничений SAP HANA является поддержка только одной системы — одного инстанса с уникальным SID сервера. Для более эффективного использования аппаратного обеспечения или уменьшения количества серверов в ЦОД можно использовать виртуализацию. Таким образом другие ландшафты могут сосуществовать на одном сервере с системами, имеющими меньшие требования (непродуктивные системы). Для резервного HA/DR-сервера виртуализация может повысить скорость переключения между продуктивными и непродуктивными виртуальными машинами.
SAP HANA включает поддержку гипервизора VMWare ESX. Это означает, что разные системы SAP HANA – инсталляции SAP HANA с различными номерами SID – могут сосуществовать на едином хосте (общем физическом сервере) в разных виртуальных машинах. Каждая виртуальная машина должна работать в поддерживаемой ОС.
Для продуктивных сред виртуализация SAP HANA имеет серьезные ограничения:
Топологии SAP HANA
Перейдем к развертыванию SAP HANA. Здесь определены две топологии.
Требования SAP к железу
К аппаратному обеспечению для HANA у SAP есть обязательные требования. Они касаются продуктивных сред — для non-prod достаточно минимальных характеристик. Итак, вот требования для продуктивных сред:
Развертываем SAP HANA в режимах Appliance и TDI
Теперь перейдем к практике и расскажем о том, как реализовать SAP HANA в режимах Appliance и TDI. Используем для этого наши платформы SAP HANA на основе серверов BullSequana S и Bullion S, которые сертифицированы SAP для работы в этих режимах.
Небольшая справка о продуктах. BullSequana S на базе Intel Xeon Scalable включает в себя различные модели, до 32 CPU в одном сервере. Сервер построен по модульной конструкции, обеспечивающей масштабируемость до 32 CPU и такого же количества графических процессоров. Оперативная память – от 64 ГБ до 48 ТБ. Среди особенностей BullSequana S – поддержка корпоративного ИИ для улучшенной производительности, ускорение аналитики данных, усовершенствование вычислений в памяти, модернизация с помощью виртуализации и облачных технологий.
Bullion S поставляются с CPU семейства Intel Xeon E7 v4 Family. Максимальное количество процессоров — 16. ОЗУ масштабируется со 128 ГБ до 24 ТБ. Большое количество функций RAS обеспечивает высокий уровень доступности для критически важных инфраструктур наподобие SAP HANA. Bullion S подходят для массовой консолидации ЦОД, работы с приложениями In-Memory, миграции мейнфреймов или устаревших систем.
SAP HANA Appliance
Appliance – преднастроенное решение, включающее сервер, СХД и пакет ПО для внедрения «под ключ», с централизованной службой поддержки и оговоренным уровнем производительности. Здесь HANA поставляется в виде предварительно настроенного аппаратного и программного обеспечения, полностью интегрированного и сертифицированного. Устройство в режиме Appliance готово к установке в ЦОД, а операционная система, SAP HANA и (если необходим) дополнительный инстанс VMWare уже сконфигурированы и установлены.
Сертификация SAP определяет гарантированный уровень производительности, а также модель CPU, объем RAM и СХД. После сертификации изменить конфигурацию без потери гарантии нельзя. Для масштабирования платформы HANA SAP предлагает три варианта.
Решения BullSequana S для SAP HANA в режиме Appliance
*Optional E7-8890/94v4
Решения Bullion S для SAP HANA в режиме Appliance
Все решения Bull в режиме Appliance с версии SAP HANA SPS 12 сертифицированы. Оборудование устанавливается в стандартную 19-дюймовую стойку 42U, с двумя источниками питания — внутренними PDU. Сертификацию SAP имеют серверы:
Вот пример конфигурации СХД EMC Unity 450F в нашем сетапе:
SAP HANA TDI
Альтернативой Appliance является режим TDI (Tailored Data center Integration), в котором можно выбирать конкретных производителей и компоненты инфраструктуры в зависимости от пожеланий заказчика – с учетом выполняемых задач и рабочей нагрузки. Например, SAN может быть повторно использован в ЦОД, при этом некоторые диски отводятся под установку HANA.
По сравнению с Appliance, в режиме TDI пользователю дается гораздо большая свобода в выполнении требований. Это значительно упрощает интеграцию HANA в ЦОД — можно выстроить собственную кастомизированную инфраструктуру. Например, варьировать тип и количество процессоров в зависимости от нагрузки.
Для расчета мощностей рекомендуется использовать SAP Quick Sizer — простой инструмент, выдающий требования к ЦП и памяти для разных рабочих нагрузок в SAP HANA. Затем для планирования IT-ландшафта можно обратиться в SAP Active Global Support. После этого аппаратный партнер SAP HANA преобразует результаты расчетов в разные возможные конфигурации системы — как на топовом, так и на более простом железе. В режиме TDI для серверов допустимо использовать CPU Intel E7, включая Intel Broadwell E7 и Skylake-SP (Platinum, Gold, Silver с 8 и более ядрами на процессор), а также IBM Power8/9.
Серверы поставляются без СХД, коммутаторов и стоек, но требования к аппаратной части остаются такими же, как в режиме Appliance — те же сингл-ноды, решения с вертикальным или горизонтальным масштабированием. SAP требует, чтобы использовались только сертифицированные серверы, СХД и коммутаторы, но это не страшно — у большинства производителей практически все оборудование сертифицировано.
Проверка производительности должна проводиться при помощи тестов HWCCT (Hardware Configuration Check Tool), которые позволяют проверить соблюдение определенных KPI SAP. И есть требование, не связанное с железом: HANA, ОС и гипервизор (опционально) должны быть инсталлированы специалистами с сертификацией SAP. Только системы, где соблюдаются все перечисленные правила, могут получать поддержку SAP, связанную с производительностью.
Линейка серверов BullSequana S в режиме TDI аналогична линейке в режиме Appliance, но без СХД, коммутаторов и стойки. К ним можно устанавливать любые СХД из списка сертифицированных SAP — VNX, XtremIO, NetApp и другие. Например, если VNX5400 соответствует требованиям к производительности SAP HANA, можно подключить СХД Dell EMC Unity 450F как часть конфигурации TDI. При необходимости инсталлируются адаптеры FC (1 или 10 Гбит/с), а также Ethernet-свитчи.
Теперь, чтобы вы наглядней представили описанные режимы, мы расскажем о нескольких наших реальных кейсах.
Appliance + TDI: HANA для интернет-магазина
Интернет-магазин Mall.cz, входящий в состав Mall Group, был основан 2000 году. Имеет филиалы в Чехии, Словакии, Польше, Венгрии, Словении, Хорватии и Румынии. Это крупнейший интернет-магазин в стране, продающий до 75 тысяч товаров в день, его выручка по итогам 2017 года составила порядка 280 миллионов евро.
Обновление инфраструктуры ЦОД требовалось в связи с миграцией на SAP HANA. Оцениваемый сайзинг составлял 2×6 ТБ для среды prod и 6 ТБ для сред test/dev. При этом требовалось решение с аварийным восстановлением для продуктивной среды SAP HANA в active-active кластере.
На момент объявления тендера у заказчика имелась система под SAP на базе стандартных стоечных и блейд-серверов. Два ЦОДа, располагавшиеся на расстоянии примерно в 10 км друг от друга, были укомплектованы различными СХД – IBM SVC, HP и Dell. Ключевые системы работали в режиме аварийного восстановления.
Сначала заказчик запросил сертифицированное решение в режиме Appliance для SAP HANA для всех систем (среды Production и test/dev) с ростом до 12 ТБ. Но из-за ограничений бюджета стали рассматривать другие варианты – например, большее количество CPU с модулями ОЗУ меньшего объема (модули по 64 ГБ вместо модулей по 128 ГБ). Кроме того, для оптимизации цены рассматривалось совместное СХД для сред Production и test/dev.
Сошлись на 4 CPU и 6 ТБ RAM для среды Production, с возможностью роста. Для сред test/dev в режиме TDI решили обойтись менее дорогостоящими CPU — получилось 8 CPU и 6 ТБ RAM. Из-за большего количества функций, запрашиваемого заказчиком, — репликация, бэкап, совместные среды Production и test/dev на второй площадке — вместо внутренних дисков задействовали СХД DellEMC Unity в конфигурации full-flash. Кроме того, заказчик запросил решение с аварийным восстановлением на базе репликации системы HANA (HSR) с кворумной нодой на третьей площадке.
Итоговая конфигурация для среды Prod состояла из сервера BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.10 ГГц, 165 Вт) и с 6 ТБ ОЗУ. СХД — Unity 450F 10x 3.84 ТБ. В целях disaster recovery для среды Prod использовали BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.10 ГГц, 165 Вт) с 6 ТБ ОЗУ. Для среды test/dev взяли сервер BullSequana S800 с Intel Xeon P8153 (16 ядер, 2.00 ГГц, 125 Вт) и 6 ТБ ОЗУ плюс СХД Unity 450F 15x 3.84 ТБ. В качестве кворума, серверов приложений (VxRail Solution) и решения для бэкапа (DataDomain) наши специалисты установили и настроили серверы DellEMC.
Оборудование готово к будущему апгрейду. Заказчик ожидает рост сайзинга HANA в 2019 году, и ему останется только установить в стойки новые модули.
Appliance: HANA для крупного интегратора в сфере туризма
На этот раз нашим клиентом стал крупный поставщик ИТ-услуг, занимающийся разработкой технологических решений для туристических компаний. Заказчик запустил амбициозный проект SAP HANA для внедрения новой биллинговой системы. Требовалось решение в режиме Appliance с 8 ТБ ОЗУ для сред Production и PreProd. В соответствии с рекомендациями SAP, заказчик выбрал вариант с вертикальным масштабированием.
Ключевой задачей стало внедрение аппаратной инфраструктуры, основанной на сертифицированных в режиме Appliance устройствах для SAP HANA. Приоритетными критериями являлись эффективность затрат, высокая производительность, возможность масштабирования и высокая доступность данных.
Мы предложили и реализовали решение, сертифицированное SAP, включающее в себя два сервера Bullion S16 – для сред Prod и PreProd. Оборудование работает на процессорах Intel Xeon E7-v4 8890 (24 ядра, 2.20 ГГц, 165 Вт) и оснащается 16 ТБ ОЗУ. Для BW и сред Dev/Test установили девять серверов Bullion S4 (22 ядра, 2.20 ГГц, 150 Вт) по 4 ТБ ОЗУ. В качестве СХД использовалась гибридная EMC Unity.
Такое решение обеспечивает поддержку масштабирования для всех элементов устройства – например, до 16 сокетов с CPU Intel Xeon E7-v4. Администрирование в этой конфигурации упрощено – в частности, для переконфигурирования или разбиения сервера на партиции.
Appliance + TDI: HANA для металлургов
ГМК «Норильский никель» — один из крупнейших производителей никеля и палладия — решил обновить свою аппаратную платформу SAP HANA для обеспечения работы критически важных бизнес-приложений и проектов. Требовалось расширение существующего ландшафта в части вычислительных мощностей. Одним из главных условий, выдвинутых заказчиком, стала высокая доступность платформы – несмотря на аппаратные ограничения.
Для продуктивных сред мы использовали сервер Bullion S8 и СХД в режиме SAP HANA Appliance. Для HA и test/dev платформу развернули в режиме TDI. Использовали один сервер Bull Bullion S8, два Bull Bullion S6 и гибридную СХД. Такая комбинация позволила существенно увеличить скорость работы приложений ландшафта SAP, увеличить объем вычислительных мощностей и ресурсов хранения данных и минимизировать операционные расходы. Немаловажно, что у клиента осталась возможность масштабирования до 16 CPU.
Приглашаем на SAP Форум
В этом посте мы разобрали развертывание SAP HANA разными способами, постарались осветить преимущества и недостатки доступных вариантов. Если у вас появились какие-то вопросы по внедрению SAP HANA, мы будем рады ответить на них в комментариях.
Всех, кто заинтересовался решениями Bull и возможностями их внедрения под SAP HANA, приглашаем на крупнейшее SAP-событие года: 17 апреля в Москве пройдет SAP Форум 2019. Ждем вас у нашего стенда в зоне IoT: расскажем много интересного, а также разыграем множество призов.
SAP HANA. Часть 1: Что такое SAP HANA и в чем его ценность?
Исследование зарубежного опыта
Нечитайлов Юрий Вячеславович
Серия публикаций по SAP HANA открывается вступительной публикацией одного из самых популярных и уважаемых авторов нашего журнала Инго Хильгефорта.
На прошлой неделе Вишал Сакка (Vishal Sikka) представил SAP HANA, и в этом блоге я попытаюсь объяснить, что на самом деле SAP HANA может значить для наших клиентов, а также раскрою суть некоторых его компонентов.
Итак, давайте начнем с очень простого вопроса: Что такое SAP HANA?
Что такое SAP HANA?
Прежде всего, аббревиатура HANA расшифровывается как High-performance ANalytic Appliance, т.е. высокопроизводительный инструмент для аналитики.
В следующих параграфах я хотел бы сосредоточиться на SAP HANA 1.0, а затем, в другом посте из этого цикла,хотел бы вернуться к теме маршрутной карты и к вопросу о том, как SAP HANA 1.0 будет развиваться в будущем.
SAP HANA 1.0 состоит из нескольких компонентов:
Каковы же основные возможности SAP HANA 1.0?
Наверное, вы уже сталкивались с тем, как часто люди говорят о том, что SAP HANA предоставляет средства для анализа больших объемов информации при высокой производительности, что дает короткое время реакции системы. Кроме того, SAP HANA позволяет вам использовать SAP IMCE Studio и создавать новые и гибкие модели данных на основе вашей оперативной информации и ваших данных за прошлые периоды и таким образом сочетать данные из прошлого с данными из настоящего, что позволяет вам принимать наилучшие решения для вашего бизнеса.
Еще недавно люди пытались охарактеризовать SAP HANA лишь как “более совершенную (поисковую) машину для витрины данных для SAP BusinessSuite”. Сегодня это, безусловно, одна из возможностей SAP HANA – создавать витрину данных на основе оперативных данных из SAP BusinessSuite, – однако это определенно не единственная функция SAP HANA. Благодаря интеграции с SAP BusinessObjects Data Services, SAP HANA также позволяет вам использовать любые виды источников данных (из числа поддерживаемых SAP BusinessObjects Data Services), загружать информацию в In-Memory Computing Engine и таким образом обогащать оперативную информацию дополнительными данными.
Конечно же, приведенное выше описание возможностей SAP HANA 1.0 пока что чрезвычайно кратко и не слишком хорошо формулирует то, чем SAP HANA 1.0 может быть полезно нашим клиентам. Поэтому обратимся к двум бизнес-сценариям и посмотрим, как SAP HANA 1.0 сможет помочь нашим клиентам улучшить их ситуацию.
Бизнес-сценарий №1
В нашем первом примере мы перевоплотимся в Джона, руководителя отдела сбыта. В качестве условия примем, что текущая экономическая ситуация требует от него не только выполнять целевой объем продаж, но и искать новые возможности и перспективные рынки. Сейчас Джон идет на встречу с его IT-командой и представляет им следующие бизнес-проблемы:
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
Все, что вы когда-либо хотели узнать о SAP HANA
Продукт HANA, разработанный и выпущенный в 2011 г. компанией SAP по инициативе ее основателя Хассо Платнера (поговаривают, что HANA — это акроним Hasso’s New Architecture), был представлен тогда как высокопроизводительная СУБД, способная размещать всю БД в оперативной памяти и обрабатывать ее там, не обращаясь к медленной дисковой подсистеме (in-memory). Сегодня она превратилась в полноценную платформу для разработки и исполнения приложений, запускаемых и в облаке, и на площадке заказчика. Более того, она стала базовой платформой для бизнес-приложений SAP, включая ее флагманский пакет SAP Business Suite.
Хотя в самых общих чертах о HANA сейчас знают практически все, кто следит за ИТ-рынком, есть важные детали, о которых люди, несомненно задумываются, но не удосуживаются либо стесняются спросить. Вот один из таких вопросов: «А что случится с БД в оперативной памяти, если сервер неожиданно будет обесточен?». По-видимому, специалисту из британской консалтинговой фирмы Bluefin Solutions Джону Эпплби, имеющему статус SAP Mentor и являющемуся одним из наиболее влиятельных членов комьюнити SAP HANA, с подобными вопросами приходится сталкиваться особенно часто. Это побудило его завести в своем блоге постоянно обновляемый раздел FAQ с ответами на самые животрепещущие из них. Мы оставили за скобками те, что представляют интерес для узких специалистов, и приводим в сокращенном изложении наиболее общие. Кроме того, мы дополнили этот FAQ ответами специалистов представительства SAP в странах СНГ.
Зачем SAP создала собственную СУБД?
Один из основателей SAP и председатель ее совета директоров Хассо Платнер задумался о том, что если бы была доступна СУБД с практически нулевым временем отклика, то бизнес-приложения можно было бы писать совсем по-другому и ИТ-ландшафт при этом был бы существенно упрощен. Как производителю таких приложений SAP было понятно, что ни один из традиционных софтверных вендоров создавать подобную платформу не собирается, а потому ее нужно разрабатывать самим. Кроме того, в компании были убеждены, что такая платформа послужит мощным трамплином для инновационного обновления и упрощения продуктов SAP на протяжении следующих 20 лет.
Каково происхождение HANA?
Продукт был разработан с нуля группой Института Хассо Платнера в Потсдаме, но при этом использовалась интеллектуальная собственность, реализованная в СУБД p*Time и MaxDB, поисковой машине TREX и in-memory-сервере BWA, а также полученная в результате покупки компаний Business Objects и Sybase (продукты Sybase IQ и Business Objects Data Federator).
HANA — это только СУБД?
Нет, она изначально включает в себя ряд важных дополнительных компонентов, необходимых для развертывания корпоративных приложений и поставляемых другими вендорами за отдельную плату (транзакционная и аналитическая БД, средства интеграции, поиска, прогнозирования и связи с Web).
Каковы основные отличия HANA от других подобных продуктов?
В этой БД все данные хранятся в оперативной памяти поколоночно и в сжатом виде. Поскольку все операции не требуют обращения к диску и выполняются очень быстро, отпадает нужда в индексах, материализованных представлениях, предварительно вычисляемых суммах и иных агрегатах, что позволяет уменьшить объем БД на 95% по сравнению с традиционными системами. Транзакционные и аналитические приложения могут функционировать одновременно на одном и том же экземпляре БД. SAP удалось решить основные проблемы БД с поколоночным хранением, такие как поддержка параллелизма (с помощью механизмов Multiversion Concurrency Control) и производительность операций вставки и обновления. HANA предоставляет ряд дополнительных сервисов БД, таких как обработка геоинформационных и текстовых данных, OLAP, анализ графов и др.
Кроме возможности хранения всех данных в оперативной памяти, какие еще преимущества есть у платформы?
Во-первых, благодаря совмещению свойств аналитической и транзакционной базы в одном продукте SAP HANA может без дополнительных усилий использоваться как аналитическая СУБД, что позволит сэкономить средства, требующиеся на создание специального аналитического хранилища. Во-вторых, она обладает линейной масштабируемостью: насколько позволяет память «железа», настолько эффективно будет работать SAP HANA. В-третьих, в ней изначально реализована сквозная интеграция с большинством бизнес-приложений SAP.
Каковы возможные сценарии использования HANA?
Сначала HANA применялась в основном для оперативного анализа данных, поскольку в этом случае высокая производительность сразу же достигалась штатными средствами. В типичных транзакционных приложениях (Finance, Supply Chain) рутинный переход с дисковой СУБД на HANA тоже обеспечивает повышение производительности, но не столь значительное (в финансовом модуле SAP на 50%). По-настоящему заметные преимущества возникают, когда приложение оптимизируется для HANA и часть прикладной логики передается на исполнение ядру СУБД. При этом приложение существенно упрощается (SAP сейчас работает над созданием такого упрощенного варианта пакета SAP Business Suite), в нем легко реализуются аналитические и иные сопутствующие операции реального времени. Важно то, что все корпоративные приложения работают с одним экземпляром БД, не требуя создания витрин, хранилищ и иных копий данных, синхронизируемых с основной БД.
Чем HANA может быть полезна в бизнесе?
Все зависит от того решения, в котором в качестве платформы используется SAP HANA. К примеру, в банковском секторе HANA помогает снизить нормы резервирования и риски. В связке с системой защиты от мошенничества HANA позволяет снизить уровень потерь от неправомерных действий, например, в страховом или банковском бизнесе. В финансовых блоках HANA дает возможность сократить время закрытия периода и быстрее получать консолидированную отчетность компании. Чем быстрее такая отчетность появляется у генерального директора, тем оперативнее он сможет принимать оптимальное управленческое решение. На этапе подготовки к проекту внедрения SAP HANA, консультанты SAP проводят экспертизу и делают конкретные расчеты ожидаемого эффекта для каждой компании или предприятия.
В каких отраслях и при решении каких бизнес-задач SAP HANA способна обеспечить новое качество?
Поскольку SAP HANA позиционируется, в частности, в качестве производительной СУБД для приложений любого класса, следует выделить следующие целевые отрасли:
Вот бизнес-процессы предприятия, производительность которых может быть существенно повышена с помощью SAP HANA:
HANA это все-таки что — СУБД, платформа, программно-аппаратный комплекс или облако?
Все вышеперечисленное. Современная СУБД обязана быть и сервером БД, и платформой, допуская как онпремисное, так и облачное развертывание. Бизнес стремительно движется в облака, и HANA сегодня доступна через HANA Cloud Platform в виде платформы как cервис (PaaS) и инфраструктуры как сервис (IaaS) в дата-центрах SAP, а через HANA Enterprise Cloud по модели управляемого облака как сервис Managed Cloud as a Service (McaaS) еще и в дата-центрах других облачных провайдеров. Допускается также гибридная модель, сочетающая онпремисное и облачное развертывание.
На каких системах доступна HANA?
На серверах стандартной архитектуры (стоечных и блейд), а также на их кластерных конфигурациях. Все они сертифицируются SAP и выпускаются многими вендорами [Cisco, Dell, Fujitsu, Hitachi, HP, Huawei, IBM (Lenovo), NEC и SGI]. Сегодня доступны единичные серверы с объемом ОЗУ до 6 Тб и кластеры с суммарным объемом 112 Тб. До конца года планируется завершить тестирование единичного сервера с ОЗУ 24 Тб. В качестве ОС используется Linux (SUSE или Red Hat). В будущем планируется поддержка серверов IBM POWER, но под управлением SUSE Linux, а не AIX.
Есть ли какие-то технические требования для потенциальных заказчиков?
Нет, большинство вендоров поставляют под SAP HANA сертифицированную технику. Есть несколько десятков моделей, из которых заказчик может выбрать то, что ему больше нравится.
Что случится с БД в оперативной памяти, если сервер неожиданно будет обесточен?
SAP HANA — полностью ACID-совместимая СУБД, которая с определенной периодичностью записывает на диск точки сохранения, содержащие мгновенные снимки содержимого оперативной памяти. В промежутках между ними на скоростном флэш-диске сохраняются логи всех изменений, вносимых в БД. Если произойдет сбой электропитания, то для восстановления БД в память сначала будет загружена последняя точка сохранения, а затем последовательно воспроизведены изменения, записанные в логах.
Что произойдет, если размер БД станет больше доступной оперативной памяти?
HANA всегда хранит БД на диске и по требованию загружает ее в ОЗУ сервера. Если объем ОЗУ будет исчерпан, HANA удалит оттуда те части таблиц, которые используются реже всего (на диске они останутся). В следующем релизе (сейчас известно, что в вышедшем в ноябре Service Pack 9) будет обеспечено прозрачное использование дисковой подсистемы, куда в динамическом режиме будут отправляться «холодные» данные (dynamic tiering).
Является ли HANA платформой Big Data?
В целом, да, хотя лучше она подходит для работы с данными имеющими высокую ценность. В тех случаях, когда Big Data имеют низкую ценность (скажем, записи Web-логов), HANA целесообразно использовать в роли хранилища более ценных агрегированных показателей, полученных из сырых массивов Big Data. Возможен также совместный анализ данных, одна часть которых хранится в HANA, а другая (неструктурированная) в Hadoop.
Присутствуют ли в России интеграторы, которые имеют достаточную экспертизу для осуществления проектов на базе SAP HANA? Есть ли уже опыт выполнения подобных проектов в российских компаниях?
Местная партнерская сеть активно развивается в этом направлении, и в России уже работают десятки сертифицированных партнеров по HANA, готовых к ведению крупных проектов в различных отраслях. В большинстве проектов по внедрению SAP HANA и смежных технологий также участвует подразделение SAP Consulting. У SAP есть опыт по работе с SAP HANA в «Сургутнефтегазе», «Северстали», «Эльдорадо», «МВидео», РЖД и ряде других компаний.