Каждый средний и крупный бизнес со временем сталкивается с тем, что объем информации в корпоративном хранилище данных (КХД) начинает превышать запланированные изначально мощности. В случае нашего клиента в наличии было: КХД на платформе 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 остаются только актуальные данные (обычно это данные за текущий и предыдущий годы).  (!) На данном шаге освобождается дисковое пространство кластера.  По мере необходимости высвобождения дополнительных мощностей кластера SAP HANA мигрируют наиболее нагруженные ETL-процессы. В приоритете ETL данных из "неSAP" систем, а также ETL-данных, которые передаются в третьи системы, но пользователями в SAP HANA не анализируются.  Обычно после переноса ресурсоемкого ETL проблемы производительности удается полностью решить. Причина в том, что проблемы, связанные именно с ETL (активация большого количества записей, ресурсоемкие операции "insert" и "delta merge"), возникают намного раньше, чем появляются сложности у пользователей аналитической отчетности. И именно с ними связано абсолютное большинство потребностей в расширении сайзинга.  Теперь в 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 базу данных. Посмотреть запись вебинара можно по ссылке. *** Задавайте вопросы, будем рады ответить.