Как с помощью Arenadata снизить нагрузку на SAP HANA

Авторы статьи:

Большинство компаний выбирают следующие пути миграции:

• Полная миграция на новую платформу данных
• Отказ от миграции
• Частичная (гибридная) миграция

Если первые два подхода очевидны, то про третий не так часто задумываются, а он во многом является компромиссным с управляемым бюджетом и контролируемыми рисками. Рассмотрим ключевые особенности каждого подхода, а также риски и драйверы, влияющие на стоимость и сроки реализации проекта.

Полная миграция

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

Основные риски:

• сложность быстрого переобучения внутренней технической команды и найма сотрудников с новой компетенцией;
• стоимость и технические риски единовременного переноса всей BI-отчётности на новый инструмент;
• сложность обучения бизнес пользователей и потенциально возможный негатив от новых инструментов;
• риски увольнения важных ключевых сотрудников технической команды;
• необходимость в новых серверных мощностях.

Эти риски ведут как к повышению стоимости миграции, так и к резкому снижению SLA со всеми вытекающими последствиями. Тем не менее данный подход обладает является необходимым, если есть необходимость единовременной миграции по требованию регуляторов или акционеров.

Отказ от миграции

Этот подход, несмотря на все минусы, присутствует в большинстве компаний — очень часто просто как затянувшийся переходный период, пока принимается решение что делать дальше. Подход несёт в себе большое число рисков:

• отсутствие поддержки влечёт за собой потенциальный риск невозможности выполнения SLA;
• демотивация внутренней команды из-за перспектив карьеры, связанной с SAP технологиями на российском рынке;
• необходимость инвестиций в дорогостоящее оборудование под SAP HANA и длительные сроки поставки (а в данном подходе SAP HANA будет использоваться скорее всего не только для горячих, но и для исторических данных и тяжёлых расчётов).

Тем не менее у него есть плюсы, такие как отсутствие необходимости инвестиций на внедрение новой платформы данных, переобучения персонала и бизнес-пользователей.

Гибридная миграция или распределение нагрузки

Потенциал для гибридной миграции состоит в первую очередь в разделении данных по «температуре» и выборе наиболее подходящих программно-аппаратных решений для холодных, тёплых и горячих данных. Малое время отклика и возможности обработки большого количества конкурентных запросов делают SAP HANA оптимальным решением для горячих данных. Однако в SAP HANA обрабатываются далеко не только горячие данные. В первую очередь потенциал для оптимизации связан со следующими большими категориями данных:

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

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

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

Шаг первый: охлаждение истории. На данном этапе в Arenadata DB создаются таблицы-копии объектов хранилища SAP BW для которых будет осуществляться миграция данных, для каждого слоя хранилища, т. е. воспроизводится модель данных. Таблицы-копии в ADB в целом повторяют объекты SAP BW, но построены с учётом правил дистрибуции. Для доступа к данным воссоздаётся слой виртуальных витрин, реализуются минималистичные аналитические OLAP-отчёты. Все ETL-процессы остаются на стороне SAP BW / SAP HANA. Данные в Arenadata DB выгружаются без изменений, настраивается регулярное инкрементальное обновление данных в таблицах 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-процессов. В SAP BW / SAP HANA остаются только витрины с горячими данными. Ядро КХД «переезжает» в Arenadata DB. Наш опыт подсказывает, что вопросы производительности получится гарантированно решить на втором шаге, т. е. полный перенос ETL обычно избыточен. Однако, если вопрос ставится как полный отказ от решений SAP в области КХД, то полный перенос ETL-процессов является необходимым для последующего отказа от SAP BW / SAP HANA, и, возможно, переноса витрин на Arenadata QuickMarts (на базе ClickHouse) либо другое решение для реализации требований малого времени отклика при конкурентном доступе к данным. Целевое состояние КХД схематично представлено на диаграмме:

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

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

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

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

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

Шаг	Эффект	Сценарий
Охлаждение истории	Высвобождение дискового пространства и оперативной памяти кластера SAP HANA за счёт физического переноса тёплых и холодных данных.	КХД на платформе SAP BW, с прогнозом по выходу на предел использования памяти SAP HANA на горизонте 1 год и более.
Вынос из BW/HANA ресурсоёмких ETL-процессов	Существенное высвобождение оперативной памяти, используемой для расчётов.	КХД на основе SAP BW в ситуации острой необходимости по сокращению использования оперативной памяти кластера SAP HANA.
Вынос из BW/HANA всех ETL-процессов	SAP HANA используется только как быстрая витрина данных для отчётности.	Снижение зависимости от ПО SAP. Подготовка полного перехода КХД на замещающие технологии.

Узнать подробнее о технических нюансах гибридной миграции с использованием продуктов Arenadata можно из видео с записью вебинара Sapiens solutions и Arenadata. В рамках онлайн-семинара эксперты:

• демонстрируют, как с помощью Airflow можно выгрузить данные из SAP ERP в режиме «дельты» с использованием экстракторов;
• раскрывают особенности загрузки данных в MPP базу данных;
• поясняют, как можно снизить трудозатраты на перенос модели данных и обеспечить необходимую скорость обработки данных, а также их эффективное хранение;
• отвечают на вопросы участников вебинара.

Дополнительные вопросы по гибридной миграции с SAP BW / SAP HANA на Arenadata DB и Arenadata QuickMarts можно адресовать на почту: info@arenadata.io