А в чем, собственно, проблема?

Каждый средний и крупный бизнес со временем сталкивается с тем, что объем информации в корпоративном хранилище данных (КХД) начинает превышать запланированные изначально мощности.

В случае нашего клиента в наличии было:

• КХД на платформе SAP Business Warehouse,

• необходимость покупать дополнительные мощности в кластер SAP HANA.

Ну и в чем проблема, скажете вы. 

Во-первых, это дорого. Во-вторых - долго. И в переходный период неизбежно те или иные данные будут недоступны пользователям, а значит, могут привести к потерям в бизнесе.

Нашей команде удалось существенно сэкономить бюджет клиента и сделать период внедрения новых решений практически незаметным для пользователей.

И вот как мы это сделали.

Разделяй и властвуй (над данными)

Мы решили внедрить простой и очень действенный способ, основанный на разделении данных по "температуре" - на “холодные”, “теплые” и “горячие”. Дальше нужно было выбрать наиболее подходящее программно-аппаратное решение под каждый сегмент.

SAP HANA прекрасно подходит для горячих данных. Она обеспечивает малое время отклика и умеет обрабатывать большое количество конкурентных запросов. Однако реальность такова, что в HANA хранятся далеко не только “горячие” данные, и потенциал для оптимизации связан именно с ними.

Далее рассмотрим, что мы придумали.

Решение - отделить часть данных

Итак, у нас в наличии были три больших категории данных:

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

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

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

Решение - добавить в архитектуру КХД реляционную MPP-СУБД с хранением данных на дисках и перенести туда часть данных из SAP HANA.

Почему мы решили использовать именно реляционную MPP-СУБД? 

• Во-первых, с ней трудозатраты на перенос модели данных из SAP BW(SAP HANA) без существенных изменений заметно ниже.

• Во-вторых, было необходимо организовать доступ к данным в OLAP-режиме.

В качестве MPP-СУБД мы рассматривали Arenadata DB(ADB), либо ванильный Greenplum. Остановились на первом варианте.

Гибридная миграция: пошаговая инструкция

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

Дальше мы пошагово опишем весь процесс. А вы сможете с помощью этой инструкции провести его самостоятельно при наличии такой необходимости.

Шаг первый: охлаждение истории

В ADB создаем таблицы-копии объектов хранилища SAP BW для которых будет осуществляться миграция данных, для каждого слоя хранилища. То есть воспроизводится модель данных. Они в целом повторяют объекты 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 такой подход принципиально невозможен из-за риска создания неприемлемой нагрузки на кластер, что сделает всю отчетность недоступной на некоторое время.

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

Если хотите углубиться в тему

Весной 2023 года мы проводили вебинар, где подробно рассказали о технических деталях гибридной миграции КХД с использованием продуктов платформы Arenadata. 

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

Вы можете посмотреть запись вебинара по ссылке и рассказать о своих впечатлениях в комментариях к этой статье.

***

Задавайте вопросы, будем рады ответить.