Как мы научились эффективно управлять ростом данных с переходом на BW/4HANA

Всем привет! Меня зовут Сергей Вяльцев. Я архитектор систем аналитики по направлению «Финансы» в домене «Данные и Аналитика». Хочу поделиться тем, как благодаря миграции на BW/4HANA нам удалось разгрузить сервер базы данных хранилища SAP BW, не прибегая к покупке дорогостоящего оборудования. Более подробно остановлюсь на описании новой технологии NSE и результатах ее применения в нашей системе.

Предпосылки пересмотра подхода к хранению данных

Говоря про серверную архитектуру БД HANA корпоративного хранилища данных SAP BW в «Ленте», стоит сразу отметить, что мы используем Scale-Up подход. Это значит, что у нас есть один физический сервер, который в нашем случае может вмещать до 16 TB RAM.

В рамках статьи не буду подробно останавливаться на причинах выбора именно такой архитектуры, но с учетом большого числа реализованных проектов, а также — органического роста компании уже в 2020 году в моменты пиковых нагрузок сервер БД HANA деградировал по производительности, что приводило к задержкам в загрузках данных из исходных систем, долгому отклику диалоговых процессов, зависанию отчетов, и как результат — получению негатива со стороны бизнес-пользователей.

Схематически процесс наращивания инфраструктурных мощностей, начиная с 2016 года, выглядел следующим образом:

Таким образом, уже в 2020 году остро назревал вопрос об изменении подхода к управлению жизненным циклом данных.

Возможные на тот момент варианты:

1. Сократить, предварительно согласовав с бизнесом, горизонт хранения данных, архивируя данные, скажем, старше горизонта «Текущий + 1 год», и при необходимости, по запросу от пользователей поднимать их из архивов. Эта концепция к 2020 году уже морально устарела, поскольку сокращаемые горизонты хранения данных стремились к своему предельному значению, а бизнес не воспринимал с энтузиазмом предложения еще больше ужиматься в своих запросах.

2. Воспользоваться технологией NSE, с помощью которой можно выгружать часть данных в «теплое» хранение на диски, стоимость которых в разы дешевле памяти HANA. Для возможности использования данной технологии на уровне приложения требовалась миграция системы на BW/4HANA.

3. Покупка нового HANA-сервера (с 32 TB памяти), миграция данных с сохранением Scale-Up архитектуры.

4. Покупка HANA-сервера меньшего объема (16 TB), переход от Scale-Up к Scale-Out архитектуре.

Проанализировав указанные выше опции, мы с командой остановились на втором варианте. Размер дискового пространства, который можно использовать под технологию NSE составлял 32 TB и позволял выгрузить часть данных под «теплое» хранение. Кроме того, затраты на реализацию проекта по миграции на BW/4HANA были заметно ниже приобретения новых инфраструктурных мощностей.

В итоге на миграцию системы с BWonHANA 7.5 на BW/4HANA 3.0 у нас ушло около 8 месяцев. В результате этого у нас появился доступ к управлению данными с помощью новой технологии, которая на тот момент была доступна только для Scale-Up архитектуры.

Управление объемами данных с помощью NSE

Технология NSE позволяет управлять размерами загружаемых в «горячую» память данных, практически не теряя в производительности при работе с данными из «теплых» партиций.

Графически это выглядит следующим образом:

В HANA определяется максимальный процент ОЗУ (main memory) для использования данных NSE — так называемый buffer cache (BC). По умолчанию это 10%.

Данный параметр можно изменить в конфигурации БД с помощью параметров max_size и max_size_rel, но мы не стали его менять, оставив дефолтное значение.

Концептуально NSE предназначено для данных, которые меняются редко или не меняются вообще и, к тому же, запрашиваются реже, чем данные hot memory. Если же данные в NSE меняются, то для изменений используется delta-область (не входит в BC) аналогично данным в hot memory. Поэтому желательно также контролировать размер памяти в delta-области и для NSE-партиций.

В системной HANA View M_CS_TABLES значение поля MEMORY_SIZE_IN_TOTAL учитывает данные NSE. Поэтому в ситуации, когда переведенные в NSE разделы таблицы полностью помещаются в NSE, M_CS_TABLES.MEMORY_SIZE_IN_TOTAL для «теплых» партиций может лишь несущественно отличаться от значений в «горячих» партициях.

BC не может быть более указанного процента и когда «теплым» партициям не хватает в нем места, происходит вытеснение на диск. Эмпирическое соотношение 8 к 1 для оценки размера достаточности BC. 8 TB данных «теплых» партиций на диске соответствуют 1 TB в BC.

Так вот, получив доступ к новой технологии, первым делом потребовалось сформировать список ADSO с наибольшим потреблением памяти.

Сделать это можно в SQL-консоли HANA с помощью скрипта:

SELECT SUBSTRING( LEFT( table_name, LENGTH( table_name )-1 ), 7 ) AS adso, -- тех. имя ADSO        mem_tot_gb, -- размер в Гб        rec_cnt     -- число записей FROM ( SELECT table_name,               ROUND( SUM( (memory_size_in_total)/1024/1024/1024 ),2 ) AS mem_tot_gb,               SUM( record_count ) AS rec_cnt        FROM m_cs_tables        WHERE table_name LIKE '/BIC/A%2'        GROUP BY table_name      ) WHERE mem_tot_gb > <лимит_потребления_памяти_на_одну_таблицу>            ORDER BY mem_tot_gb DESC

Поскольку объем памяти, занимаемой непосредственно данными, после миграции на BW/4HANA составлял порядка 11,5 TB, то на первоначальном этапе было необходимо максимально сократить этот объем.

Поэтому параметр <лимит_потребления_памяти_на_одну_таблицу> был установлен на 50 GB, в результате был сформирован список из порядка 60 ADSO общим объемом более 5,5 TB. Необходимым условием для того, чтобы данные в ADSO выгружались в «теплое» хранение и по возможности подгружались в buffer cache, является его партицирование.

Поле, по которому партицируется ADSO должно соответствовать следующим критериям:

1. входить в состав ключа, который всегда заполнен;

2. быть календарным признаком;

3. календарный признак должен использоваться при обращении к ADSO (при загрузке из него выше по потоку, а также при фильтрации в отчетах);

4. поле должно позволять создавать равномерные партиции с количеством записей на одну партицию 200-250 млн.

Из сформированных ранее ADSO под указанные выше критерии партицирования попало около 85%, которые были успешно партицированы во всех системах ландшафта SAP BW. Затем часть партиций была переведена в «теплое» хранение.

Горизонт «теплого» хранения выбирался исходя из размеров объекта, частоты использования данных и гранулярности поля, по которому партицировался объект. Как правило, это партиции старше текущего года + половина предыдущего.

Стоит отметить, что существует две опции партицирования ADSO: Static и Dynamic partitioning. Мы остановились на более надежном и проверенном – Static. Это позволило нам избежать рисков динамического партицирования вплоть до потери критически важных данных, будучи отключенными от поддержки вендора.

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

Этот вопрос мы решили с помощью утвержденного регламента, согласно которому раз в год проводятся работы по выявлению новых потенциальных объектов для перевода в NSE, добавлению партиций (на год вперед) к уже существующим объектам и перевод устаревших за прошедший год периодов в «теплое» хранение.

Сложности перевода в NSE

Мы столкнулись с рядом трудностей, несмотря на техническую простоту перевода объекта в NSE, состоящую из следующих пунктов:

• нарезка необходимых партиций;

• включение «галки» Warm и выбор режима Temperature Maintenance на вкладке Data Tiering Properties:

• перевод партиций в нужный температурный режим.

Во-первых, нарезка партиций и включение галки Warm требует ремоделинга объекта в транзакции RSMONITOR, который при больших объемах данных может превышать 12 часов (в нашем случае это объект размером ~180 GB, ~6 млрд записей). Это означает, что есть риск не успеть к началу регулярной загрузки данных в объект, а в случае возможных ошибок при ремоделинге потерять доступ к важным отчетам (при этом стоит отметить, что в процессе выполнения ремоделинга отчетность, построенная на объекте, доступна). Таким образом, перевод в NSE тяжелых по памяти и критичных для отчетности ADSO практически не имеет права на ошибку.

Альтернативой ремоделингу на «живых» данных является:

• создание копии ADSO (тип Staging DataStore Object), переводимого в NSE. Для копии объекта необходимо учесть, что партиция не может содержать больше 2 млрд записей, поэтому если исходный объект был партицирован на уровне БД с помощью SQL-выражения, к примеру, по hash, то аналогичное партицирование нужно применить и к его копии;

• перенос данных в копию;

• полное удаление данных в основном ADSO;

• перенос транспортных запросов с нарезанными партициями и включенным свойством Warm;

• обратный перенос данных в основное ADSO;

• распределение партиций по областям температурного хранения.

При таком подходе тоже есть свои минусы:

• полное удаление большого количества записей — это достаточно длительный процесс, который может занять не один час, особенно, если удаление выполнять с уровня приложения. Более быстрым способом будет команда truncate table с уровня БД;

• если исходный объект ранее был партицирован вручную с уровня БД по hash, к примеру, на 8 партиций, то при переносе транспортных запросов с нарезанными статичными партициями произойдет активация ADSO, в результате чего количество hash партиций станет равным 1. Насколько это актуально, решать ответственному за перевод объекта в NSE;

• обратный перенос данных в исходное ADSO (на основе личного опыта) рекомендуется выполнять запросами, не превышающими в себе 150 млн записей, чтобы их дальнейшая активация/сжатие выполнялись за адекватное время.

Во-вторых, при ремоделинге данных могут случаться ошибки следующего вида:

Подобные ошибки случались в основном в продуктивной системе. Исправить ошибку помогал прогон отчета RSDDB_LOGINDEX_CREATE, после чего повторный прогон ремоделинга завершался успешно.

Важным моментом при переводе объекта в NSE является соблюдение последовательности действий с ADSO:

1. нарезка партиций (отдельный транспортный запрос) → Ремоделинг;

2. включение галки Warm и выбор опции On Partition Level (отдельный транспортный запрос) → Ремоделинг.

Перенос в целевые системы также необходимо осуществлять в указанной последовательности, т.к. при шаге 1 выполняется ALTER TABLE *1, *2, *3, *5 (для некумулятивных) таблиц ADSO, при котором в качестве партиций первого уровня остаются HASH-партиции, а вторым уровнем нарезаются RANGE-партиции.

На втором шаге происходит обратное репартицирование, при котором RANGE-партиции становятся основными, а партициями второго уровня становятся HASH-партиции.

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

Порядок работы с объектами, не подлежащими переводу в NSE

Как я упоминал ранее, из всего перечня потенциальных объектов для перевода в NSE, необходимым критериям соответствовали порядка 85% ADSO.

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

Далее выгружаем архивные данные на диск с помощью команды UNLOAD, вызываемой в Z-программе.

Плюсы такого подхода:

1. доступ к архивному ADSO имеют только консультанты BW, поскольку на них не строится отчетность;

2. быстрое восстановление данных;

3. данные физически не хранятся в «горячей» памяти. Даже если консультант поднимет часть из них в память, то настроенные у нас процедуры контроля использования данных, вернут их обратно на диск.

К сожалению, существуют крупные ADSO, которые не содержат календарных признаков. Соответственно, разбить выгрузку исторических данных на равные интервалы не представляется возможным.

Такие объекты ставим на hold, периодически посматривая на их объемы. В этом нам помогают EWA-отчеты, а также ряд собственных наработок для мониторинга состояния системы.

В качестве альтернативных вариантов при приближении в таких ADSO размеров партиций к 2 млрд рассматриваем возможность hash-партицирования на уровне БД.

Краткие итоги

Благодаря новой технологии NSE, ставшей доступной после миграции на BW/4HANA, а также механизму принудительной выгрузки исторических данных на диск, нам удалось сократить объемы хранения данных в «горячей» памяти до 6 TB, т.е. практически в два раза:

А самый главный эффект, которого удалось достичь, это возможность управления «горячими» данными, что при возрастающей нагрузке в пиковые сезоны продаж помогает системе справляться с резким увеличением данных, выполнять расчеты и обеспечивать готовность данных для отчетности за приемлемое, удовлетворяющее установленным SLA, время.

Планы

Конечно, с учетом органического роста компании, M&A, увеличения объемов продаж, не приходится рассчитывать на то, что мы сможем бесконечно разгружать «горячую» память. Это подтверждают предварительные замеры прироста памяти, занимаемой данными.

Именно поэтому у нас есть планы по переходу на Open Source решения, являющиеся составными компонентами архитектуры LakeHouse, которые будут обеспечивать уровень быстродействия, не уступающий считыванию данных из «теплого» хранения в память HANA. Туда в первую очередь будут переезжать исторические данные, а в перспективе, в зависимости от показанной производительности, возможен и окончательный переход с SAP BW.

Время покажет!