/НАЗАД
Описание проблемы
Рост объема данных в КХД на платформе SAP Business Warehouse заставляет периодически задумываться о покупке и добавлении дополнительных мощностей в кластер SAP HANA. Это довольно дорогостоящая операция. И здесь есть потенциал для оптимизации и существенной экономии в первую очередь за счет разделения данных по «температуре» и выбора наиболее подходящих программно-аппаратных решений для холодных, теплых и горячих данных. Малое время отклика и возможности обработки большого количества конкурентных запросов делают SAP HANA прекрасным решением для горячих данных. Однако реальность обычно такова, что в HANA хранятся далеко не только горячие данные. В первую очередь потенциал для оптимизации связан со следующими большими категориями данных:
- Это всевозможные детальные исторические данные, доступ к которым необходим в OLAP-режиме, но нечасто и очень ограниченному кругу потребителей данных (например, для прохождения аудита).
- Данные, которые используются в различных расчетах, однако потребителям данных не нужен доступ к ним в OLAP-режиме, т. е. хранить такие данные в детальном виде в SAP HANA нет необходимости, достаточно обновлять агрегаты, требуемые для расчетов, либо делать запросы в сторонние системы, если выполняются требования по времени отклика.
- Данные, которые накапливаются и хранятся в 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, такой подход принципиально невозможен из-за риска создания неприемлемой нагрузки на кластер, что сделает всю отчетность недоступной на некоторое время).
Сравнительный анализ шагов и сценариев миграции
| Шаг | Эффект | Сценарий |
|---|---|---|
| Охлаждение истории | Высвобождение дискового пространства и оперативной памяти кластера SAP HANA за счет физического переноса теплых и холодных данных. | КХД на платформе SAP BW, с прогнозом по выходу на предел использования памяти SAP HANA на горизонте 1 год и более. |
| Вынос из BW/HANA ресурсоемких ETL процессов | Существенное высвобождение оперативной памяти, используемой для расчетов | КХД на основе SAP BW в ситуации острой необходимости по сокращению использования оперативной памяти кластера SAP HANA. |
| Вынос из BW/HANA всех ETL процессов | SAP HANA используется только как быстрая витрина данных для отчетности. | Снижение зависимости от ПО SAP. Подготовка полного перехода КХД на замещающие технологии. |
Заключение
Весной 2023 года мы проводили вебинар, где подробно рассказали о технических деталях гибридной миграции КХД с использованием продуктов платформы Arenadata. Там мы, в частности, показали, как с помощью Airflow можно выгрузить данные из SAP ERP в режиме "дельты" с использованием экстракторов, и рассказали об особенностях загрузки данных в MPP базу данных. Посмотреть запись вебинара можно по ссылке.
/НАЗАД
Описание проблемы
Рост объема данных в КХД на платформе SAP Business Warehouse заставляет периодически задумываться о покупке и добавлении дополнительных мощностей в кластер SAP HANA. Это довольно дорогостоящая операция. И здесь есть потенциал для оптимизации и существенной экономии в первую очередь за счет разделения данных по «температуре» и выбора наиболее подходящих программно-аппаратных решений для холодных, теплых и горячих данных. Малое время отклика и возможности обработки большого количества конкурентных запросов делают SAP HANA прекрасным решением для горячих данных. Однако реальность обычно такова, что в HANA хранятся далеко не только горячие данные. В первую очередь потенциал для оптимизации связан со следующими большими категориями данных:
- Это всевозможные детальные исторические данные, доступ к которым необходим в OLAP-режиме, но нечасто и очень ограниченному кругу потребителей данных (например, для прохождения аудита).
- Данные, которые используются в различных расчетах, однако потребителям данных не нужен доступ к ним в OLAP-режиме, т. е. хранить такие данные в детальном виде в SAP HANA нет необходимости, достаточно обновлять агрегаты, требуемые для расчетов, либо делать запросы в сторонние системы, если выполняются требования по времени отклика.
- Данные, которые накапливаются и хранятся в 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, такой подход принципиально невозможен из-за риска создания неприемлемой нагрузки на кластер, что сделает всю отчетность недоступной на некоторое время).
Сравнительный анализ шагов и сценариев миграции
| Шаг | Эффект | Сценарий |
|---|---|---|
| Охлаждение истории | Высвобождение дискового пространства и оперативной памяти кластера SAP HANA за счет физического переноса теплых и холодных данных. | КХД на платформе SAP BW, с прогнозом по выходу на предел использования памяти SAP HANA на горизонте 1 год и более. |
| Вынос из BW/HANA ресурсоемких ETL процессов | Существенное высвобождение оперативной памяти, используемой для расчетов | КХД на основе SAP BW в ситуации острой необходимости по сокращению использования оперативной памяти кластера SAP HANA. |
| Вынос из BW/HANA всех ETL процессов | SAP HANA используется только как быстрая витрина данных для отчетности. | Снижение зависимости от ПО SAP. Подготовка полного перехода КХД на замещающие технологии. |
Заключение
Весной 2023 года мы проводили вебинар, где подробно рассказали о технических деталях гибридной миграции КХД с использованием продуктов платформы Arenadata. Там мы, в частности, показали, как с помощью Airflow можно выгрузить данные из SAP ERP в режиме "дельты" с использованием экстракторов, и рассказали об особенностях загрузки данных в MPP базу данных. Посмотреть запись вебинара можно по ссылке.