Ключевое понятие
SAP HANA это быстро развивающаяся база данных с набором поставляемых инструментов разработки, которая может в некоторых случаях заменить SAP BW.

SAP BW ­— это инструмент построения хранилищ данных, который может работать на различных базах данных, в том числе и используя в качестве базы данных SAP HANA. Большинство компаний знают, что SAP HANA — это намного больше чем просто быстрая база данных in-memory. SAP HANA обладает функциональностью включающей текстовый поиск, веб-сервер, предиктивные и географические средства вычислений и, ключевые для данного обсуждения, графические средства моделирования.

Когда SAP HANA только появилась было много слухов, что SAP HANA заменит средства моделирования SAP BW и даже полностью SAP BW (смотрите юмористический рис. 1). Данная статья разбирается насколько эти слухи оправданы и приводит примеры того, как можно использовать SAP BW и SAP HANA вместе.

Рис. 1. SAP HANA и SAP BW выясняющие отношения

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

Хранилища данных — нужны ли они по-прежнему?

Как и все другие хранилища данных, включая прикладную разработку, SAP BW представляет собой необходимый инструмент в силу следующих причин:

1. Для преобразования и пересохранения данных в таблицах и представлениях, оптимизированных для производительности отчетности (в отличие от транзакционных систем — SAP ERP, где целью является такой дизайн таблиц, который обеспечивает быстрое сохранение транзакционных данных, а не быструю отчетность).
2. Для отделения генерации отчетности от, критической по времени выполнения ERP системы, онлайн-обработки транзакций (OLTP).
3. Для консолидации, гомогенизации и очистки данных из различных систем компании и приведения их в единый формат с глобальными справочниками.

С появлением SAP HANA необходимость в построении хранилищ данных стала менее очевидной. Скорость обработки данных in-memory в SAP HANA позволяет получать производительность выполнения OLAP (обработка аналитики) сравнимую с OLTP (обработка транзакций) на традиционных нормализованных схемах баз данных. Более того, если сайзинг системы SAP HANA проведен надлежащим образом, нагрузка от приложений аналитической отчетности не должна мешать выполнению критических по времени задач транзакционной обработки.

Доступны и дополнительные функции для повышения производительности, такие как Dynamic Tiering и SAP HANA-tenant database containers, которые позволяют значительно увеличить производительность ERP. В результате пункт номер три из описанных выше остается как причина для использования отдельного приложения построения хранилищ данных. Или, более точно, эта причина плюс тот функционал аналитики, который отсутствует в SAP HANA, являются главными причинами для того, чтобы продолжать использовать SAP BW. Давайте проанализируем это более детально.

Консолидация, гомогенизация и очистка данных

Рассматривая причину номер три более детально, сторонники использования одной лишь SAP HANA могут сказать, что новые инструменты SAP HANA, содержащиеся в Support Package 9 и выше, делают ненужным использование SAP BW для консолидации данных. Они могут утверждать, что инструменты управления данными и интеграции SAP HANA Enterprise Information Management, объединенные с возможностью использования корпоративных данных прямо в месте их хранения через SAP HANA Smart Data Access или через виртуальные таблицы, превосходят инструменты extraction, transformation, and loading (ETL) встроенные в SAP BW.

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

Для больших компаний (да и для меньших тоже), когда часть данных хранится не в SAP HANA, для построения единой отчетности необходимо будет объединить данные и физически их обработать. В противном случае нужно будет виртуализировать их (что работает медленнее), и переслать по сети для объединения с данными SAP HANA. Для компаний хранящих 95% всех данных в SAP HANA, как в случае со сценарием ECC-on-SAP-HANA (рис. 2), виртуализация оставшихся 5 % данных это не такая уж и плохая идея.

Рис. 2. Сценарии развертывания SAP BW и SAP HANA

Однако, если появляются данных хранимые не в SAP HANA (к примеру, в случае если компанию купили), то так как пользователи привыкли к скорости работы с данными в SAP HANA, необходимость физического слияния и хранения данных в SAP HANA становится очевидной.

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

Варианты инсталляции

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

Совместный вариант инсталляции

Многие компании использующие в настоящий момент ECC, особенно те, которые считают, что SAP BW исчезнет, могут попробовать использовать данный подход (центральная часть рис. 2). Подход состоит в том, чтобы перегрузить данные в SAP HANA и использовать их для быстрого операционного получениях отчетности (низкоуровневая детализированная информация в реальном времени). Если уже используется SAP BW (а в большинстве компаний это так), то SAP BW сохраняется для консолидации данных из не-SAP систем и для построения стратегической высокоуровневой отчетности.

Вариант с инсталляцией только SAP BW на SAP HANA

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

Вариант интегрированной инсталляции

Последняя группа компаний использовала подход, предлагаемый SAP, который состоит в том, что все имеющие отношение к SAP продукты и дополнительно разработанные веб-приложения выполняются на единой системе SAP HANA (показано с правой стороны рис. 2). В такой схеме все продукты линейки ERP выполняются каждый на собственном сервере приложений, но с одной общей базой данных SAP HANA. В таком случае одним из продуктов может быть и SAP BW, но опять же со своими серверами приложений.

Данный интегрированный сценарий на самом деле можно разбить на три подсценария, а именно:

Вариант интегрированной инсталляции. Подсценарий 1

Первый подсценарий стал возможным только недавно с появлением в Support Package 9 tenant database containers (контейнеров множественной аренды). Они изолируют приложения с точки зрения использования ресурсов. В этом подсценарии SAP, BW и ECC являются разными арендаторами. Чтобы сделать это понятнее, я называю это арендой для ECC и SAP BW на SAP HANA.