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