Как с помощью импортозамещающих технологий снизить нагрузку на SAP HANA

Проблема

Рост объема данных в КХД на платформе SAP Business Warehouse заставляет задумываться о покупке и добавлении дополнительных мощностей в кластер SAP HANA. Это довольно дорогостоящая операция. И здесь есть потенциал для оптимизации и существенной экономии в первую очередь за счет разделения данных по «температуре» и выбора наиболее подходящих программно-аппаратных решений для холодных, теплых и горячих данных. Малое время отклика и возможности обработки большого количества конкурентных запросов делают SAP HANA оптимальным решением для горячих данных. Однако в HANA хранятся далеко не только горячие данные. В первую очередь потенциал для оптимизации связан со следующими большими категориями данных:

1. Детальные исторические данные, доступ к которым необходим в OLAP-режиме, но нечасто и очень ограниченному кругу потребителей (например, для прохождения аудита).

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

3. Данные, которые накапливаются и хранятся в SAP HANA для передачи в прочие системы, но напрямую в SAP HANA потребителями не анализируются.

Решение — гибридная миграция

Проблему можно решить добавлением в архитектуру корпоративного хранилища данных реляционного MPP-СУБД с хранением данных на дисках и переносом части данных из SAP HANA. Это может быть Arenadata DB (ADB), либо ванильный Greenplum. Выбор именно реляционного MPP-СУБД связан с трудозатратами на перенос модели данных из SAP BW (SAP HANA) без существенных изменений, а также с необходимостью организации доступа к данным в OLAP-режиме.

Миграцию можно осуществлять последовательно, инкрементально перенося центр тяжести КХД из SAP HANA в ADB по мере появления необходимости в высвобождении ресурсов.

Шаг первый: охлаждение истории. На данном этапе в ADB создаются таблицы-копии объектов хранилища SAP BW для которых будет осуществляться миграция данных, для каждого слоя хранилища, т. е. воспроизводится модель данных. Таблицы-копии в ADB в целом повторяют объекты SAP BW, но построены с учетом правил дистрибуции. Для доступа к данным воссоздается слой виртуальных витрин, реализуются минималистичные аналитические OLAP-отчеты. Весь ETL остается на стороне SAP BW/SAP HANA. Данные в ADB переливаются без изменений, настраивается регулярное инкрементальное обновление данных в таблицах ADB из SAP BW/SAP HANA. Исторические данные в объектах хранилища SAP BW очищаются, доступ к ним предоставляется только в ADB. В SAP BW остаются только актуальные данные (обычно это данные за текущий и предыдущий годы). На этом шаге освобождается дисковое пространство кластера. Целевое состояние КХД схематично представлено на рисунке:

Шаг второй: перенос наиболее ресурсоемких ETL-процессов. По мере необходимости высвобождения дополнительных мощностей кластера SAP HANA мигрируются наиболее нагруженные ETL-процессы. В приоритете ETL данных из «неSAP» систем, а также ETL-данных, которые передаются в третьи системы, но пользователями в SAP HANA не анализируются. Обычно после переноса ресурсоемкого ETL проблемы производительности удается полностью решить, т. к. проблемы, связанные именно с ETL (активация большого количества записей, ресурсоемкие операции ‘insert’ и ‘delta merge’) возникают намного раньше, чем появляются проблемы у пользователей аналитической отчетности и именно с ними связано абсолютное большинство потребностей в расширении сайзинга. Целевое состояние КХД схематично представлено на рисунке:

Шаг третий: полный перенос ETL-процессов. В BW/HANA остаются только витрины с горячими данными. Ядро КХД «переезжает» в ADB. Наш опыт подсказывает, что вопросы производительности получится гарантированно решить на втором шаге, т. е. полный перенос ETL обычно избыточен. Однако, если вопрос ставится как полный отказ от решений SAP в области КХД, то полный перенос является необходимым для последующей замены SAP BW/SAP HANA, например на Arenadata Quick Marts (Clickhouse) либо другое решение для реализации требований малого времени отклика при конкурентном доступе к данным. Целевое состояние КХД схематично представлено на рисунке:

Преимущества подхода

Такой подход позволяет гарантировано решить проблемы с производительностью SAP HANA, предотвратить необходимость покупки и добавления новых мощностей в кластер. За счет выбора наиболее подходящих программно-аппаратных решений для «горячих» и «теплых» данных появляется возможность сэкономить средства компании.

Одним из преимуществ подхода является его «ползучий» характер, укладывающийся в современные гибкие методологии ведения проектов. При этом для основной части пользователей аналитической отчетности реализация гибридной миграции остается незаметной (за исключением улучшения ситуации с производительностью), актуальные данные доступны для анализа на всем протяжении миграции, витрины данных продолжают обновляться, фронт-енд остается без каких-либо изменений.

Появление в ландшафте дополнительного аналитического КХД, кратковременные перебои в работе которого не влияют на доступность данных в корпоративной отчетности, позволяет предоставить доступ к детальным данным для дата-аналитиков с полномочиями выполнять SQL-запросы для формирования AD HOC отчетов. (В случае с SAP HANA, такой подход принципиально невозможен из-за риска создания неприемлемой нагрузки на кластер, что сделает всю отчетность недоступной на некоторое время).

Сравнительный анализ шагов и сценариев миграции

Заключение

В заключение предлагаем принять участие в вебинаре, организованном командами Sapiens solutions и Arenadata. где будут обсуждаться технические детали гибридной миграции КХД с использованием продуктов платформы Arenadata. Спикеры ответят на все интересующие вопросы, расскажут про платформу, о ее компонентах и особенностях работы. В ходе онлайн-семинара будет продемонстрировано, как с помощью Airflow можно выгрузить данные из SAP ERP в режиме «дельты» с использованием экстракторов, также слушатели могут познакомиться с особенностями загрузки данных в MPP базу данных. Записаться на вебинар можно по ссылке.