Представим себе сценарий: клиент на кассе предъявляет карточку постоянного покупателя. Система моментально сравнивает его текущую корзину и историю покупок, а также «лайки» в открытых соцсетях. После этого системе остается выдать кассиру спецпредложения для этого клиента, например, купон со скидкой на товар, который может быть ему интересен.
Конечно, это требует обработки огромного количества информации за очень короткий промежуток времени – пока клиент стоит у кассы. Техническим «бутылочным горлышком», которое затрудняет выполнение подобных задач, сегодня являются медленные жесткие диски. Они не могут справиться с нагрузкой. Единственное решение – перенести данные для анализа в быструю оперативную память (ОП) и получать «выжимки» сразу.
Идея перемещения данных для бизнес-анализа с жестких дисков в ОП не нова: подобное решение было впервые реализовано шведским инженером Хокеном Вольге в BI-продукте QlikView ещё в 1997 году (о нашем опыте работы с QlikView мы писали в Jet Info 2, 2013). Технологии In-Memory стремительно развивались, и в 2008 году компания SAP AG представила СУБД SAP HANA.
SAP HANA упрощает системный ландшафт, что ведёт к экономии затрат на поддержку аналитических систем
Решение идет дальше простого хранения данных в оперативной памяти. В нем применяются различные методы оптимизации работы процессора с ОП, в частности используется поколоночное хранение данных (речь идёт о физическом хранении, для пользователя БД состоит из привычных таблиц). Это обеспечивает уровень компрессии до семи раз.
И всё же первое, что отмечает пользователь, – это высокая производительность SAP HANA. Например, в одном из российских банков мы недавно реализовали пилотный проект по миграции СУБД на SAP HANA и добились существенного повышения скорости стандартных SQL-запросов. Нам нужно было ускорить запрос для отчета по просроченным кредитам, он строился на основании 450 млн записей в течение 20 минут. Компания ставила задачу уложиться в одну минуту, но после миграции данных на SAP HANA запрос сразу стал выполняться со скоростью 0,01 секунды. Нам не пришлось даже переписывать запрос, хоть он и был написан для другой СУБД.
Были и другие заметные результаты, например, сверка по остаткам на счетах за 2 года (9 млрд проводок) была ускорена с 240 до менее чем 4 минут. SAP HANA хорошо проявила себя там, где были необходимы запросы на чтение или обновление данных. Мы не были удовлетворены производительностью в тех случаях, когда требовалось большое количество последовательных обновлений одних и тех же данных. Такие экзотические операции у заказчика появились в ходе оптимизации работы исходной СУБД. Она не могла эффективно выполнить нужные операции за один раз, поэтому пришлось разбить их на последовательные обновления. Для SAP HANA же можно переписать запросы так, чтобы все последовательные обновления выполнялись в виде одной большой операции. Сделав это, мы добились ускорения ежедневной загрузки данных из АБС – 3 минуты 20 секунд вместо более чем полутора часов.
Как говорил Генри Форд: «Если бы я спросил у людей, что им нужно, они бы попросили более быструю лошадь». SAP HANA – это более быстрая СУБД, но в то же время и комплексная платформа, которая позволяет упростить системный ландшафт. Например, web-сервер SAP HANA Extended Application Services, расположенный в SAP HANA, позволяет разворачивать web-приложения на стороне СУБД. Такой подход повышает производительность благодаря тесной интеграции сервера приложений и СУБД, исключает издержки на реализацию сложной логики работы web-приложений с базой данных, облегчает администрирование, упрощает разработку. Лишнюю нагрузку можно снять и с сервера BI при помощи встроенных в SAP HANA инструментов для построения виртуальных кубов данных.
Функциональность SAP HANA позволяет перенести многие операции, которые выполнялись отдельными приложениями, непосредственно в СУБД.
Мы не привыкли ассоциировать некоторый функционал этого решения с системами управления базами данных. Например, оно может работать с языком для статистической обработки данных R, анализировать неструктурированные
данные (Natural Language Processing), проводить упреждающий (Predictive Analysis), глубинный анализ данных (Data Mining), финансовый анализ. В него встроен полнотекстовый поиск, позволяющий обрабатывать такие файлы, как .pdf, .doc, в стиле поиска в Google.
Место в системном ландшафте
Как показал наш опыт, есть три варианта внедрения SAP HANA. Первый – в качестве отдельной базы данных для аналитики. Это внедрение «с нуля», прежде всего для решения задач отчетности и аналитики в режиме реального времени. Наиболее оптимально параллельно ставить BI-инструмент. Такой вариант подойдёт в первую очередь компаниям с амбициозными планами по расширению аналитической отчетности. Разработка с нуля позволит воплотить в жизнь любые задумки, но такой подход наиболее трудоёмок и потребует больше времени, чем другие способы внедрения.
Второй – SAP NetWeaver BW на SAP HANA. Здесь основная цель – повышение производительности уже существующего решения, работающего поверх одной из традиционных баз данных. Приятным побочным эффектом такого внедрения будет существенное уменьшение размера БД – с SAP HANA будут уже не нужны специальные конструкции, созданные SAP NetWeaver BW для повышения скорости работы.
Применение
Решения In-Memory уже завоевали популярность в сфере розничной торговли. Ритейлеры особенно заинтересованы в возможности получения результатов аналитики до того, пока клиент не отошёл от кассы или не закрыл web-страничку. Список задач, которые можно решить здесь при помощи SAP HANA, ограничен только фантазией аналитиков. Можно, например:
- составить детальные портреты покупателей, чтобы предоставить им индивидуальные предложения;
- осуществлять мониторинг показателей эффективности, получая важные предупреждения в течение секунд после наступления события;
- использовать высокопроизводительные методы планирования на основе детальных транзакционных данных;
- предсказывать поведение конкретных покупателей на основе их транзакционных данных;
- улучшить эффективность цепочек поставок, оптимизировать логистику;
- следить за наполнением полок в режиме реального времени, предотвращать потенциальные проблемы (например, нехватку товара);
- оптимизировать работу мерчендайзинга;
- предотвращать fraud-операции.
И третий – SAP Business Suite на SAP HANA. Это метод внедрения, который позволит отказаться от традиционного разделения систем на OLTP и OLAP: SAP HANA значительно ускоряет функционирование приложений, работающих с СУБД, при этом снимает с разработчиков нагрузку, связанную с проектированием разных баз данных, соответствующих методологиям построения OLAP- и OLTP-систем. Другими словами, SAP HANA за счет высокой скорости работы позволяет объединить транзакционную и аналитическую системы в одну единую БД. Такой подход позволит исключить отдельные ETL-загрузки из OLTP в OLAP. Данные попадают в отчеты практически сразу после того, как они были созданы транзакционной системой. При этом в отчетах хранятся самые детальные данные, то есть аналитик может проследить, например, изменение эффективности работы на разных уровнях: от магазина в целом до конкретных кассиров и даже чеков.
Второй и третий варианты внедрения будут интересны компаниям, ищущим способы оптимизации работы уже существующих SAP-систем.
SAP HANA упрощает общий системный ландшафт, что ведёт к экономии затрат на поддержку аналитических (а в некоторых случаях и транзакционных) систем. Ещё недавно представители бизнеса с некоторой опаской смотрели в сторону решения, но успешные проекты доказывают его перспективность. Сегодня открываются возможности решения задач, которые раньше казались неосуществимыми, и можно с уверенностью сказать, что приход SAP HANA поистине изменил правила игры.