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

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

Подход к решению - гибридная миграция

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

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

Шаг первый - охлаждение истории. На данном этапе в ADB создаются таблицы-копии объектов хранилища SAP BW/HANA для которых будет осуществляться миграция данных, для каждого слоя хранилища, т. е. воспроизводится модель данных. Таблицы-копии в ADB в целом повторяют объекты и таблицы BW/HANA, но построены с учетом правил дистрибуции. Для доступа к данным воссоздается слой виртуальных витрин, реализуются минималистичные аналитические OLAP-отчеты. Весь ETL остается на стороне SAP BW/HANA. Данные в ADB переливаются без изменений, настраивается регулярное инкрементальное обновление данных в таблицах ADB из SAP BW/HANA. Исторические данные в объектах хранилища SAP BW/HANA очищаются, доступ к ним предоставляется только в ADB. В SAP BW/HANA остаются только актуальные данные (обычно это данные за текущий и предыдущий годы). На данном шаге освобождается дисковое пространство кластера. Целевое состояние КХД схематично представлено на рисунке:

Шаг второй - перенос наиболее ресурсоемких ETL процессов. По мере необходимости высвобождения дополнительных мощностей кластера SAP BW/HANA мигрируются наиболее нагруженные ETL-процессы. В приоритете ETL данных из «неSAP» систем, а также ETL-данных, которые передаются в третьи системы, но пользователями в SAP BW/HANA не анализируются. Обычно после переноса ресурсоемкого ETL проблемы производительности удается полностью решить, т. к. проблемы связанные именно с ETL (активация большого количества записей, ресурсоемкие операции ‘insert’ и ‘delta merge’) возникают намного раньше, чем появляются проблемы у пользователей аналитической отчетности и именно с ними связано абсолютное большинство потребностей в расширении сайзинга. Целевое состояние КХД схематично представлено на рисунке: