Эта статья будет интересна в первую очередь архитекторам и консультантам по решениям на основе популярного продукта компании SAP — корпоративного хранилища данных SAP BW.
Если вы отвечаете за развитие корпоративного хранилища данных на базе SAP BW on HANA или SAP BW/4 HANA, вы рано или поздно (лучше — рано) задумаетесь о контроле роста объемов данных «колоночных» таблиц, которые загружаются в оперативную память сервера БД SAP HANA. По рекомендации SAP, суммарный объем табличных данных («поколоночных» и «строчных») таблиц в памяти не должен превышать эмпирического значения 50% от выделенной на SAP HANA памяти сервера(ов). В противном случае, процессы в SAP HANA станут выполняться менее предсказуемо в части длительности, а порой и просто стабильности. Это относится и к процессам трансформации данных в BW (т. н. DTP), и к выполнению пользовательских отчетов.
Столкнувшись с нехваткой памяти, SAP HANA инициирует процессы вытеснения из памяти сегментов (колонок поколоночных таблиц или их партиций), которые использовались наиболее давно и имеют более высокий приоритет к вытеснению. В SAP HANA за это отвечает параметр UNLOAD PRIORITY, который устанавливается на «поколоночную» таблицу и может быть изменен впоследствии. Однако, в ситуации, когда одновременно десяткам, а порой и сотням параллельных процессов требуется больше памяти, внутренним методам выделения и освобождения памяти в HANA приходится «в авральном режиме» решать задачу определения, сколько нужно вытеснить, что именно можно вытеснить и выполнить само вытеснение. Очевидно, что это не добавляет производительности процессам, ради которых это вытеснение и выполняется. И даже при наличии таких совершенных алгоритмов возникают ошибки нехватки памяти в HANA (OOM), что приводит к проблемам уже на уровне приложения SAP HANA, а именно — SAP BW. Это выражается в аварийном прерывании процесса. И хорошо еще, если этот процесс‑ некритичный пользовательский отчет. Совсем другое дело, если это ночная загрузка. Без должного реагирования пользователи утром могут не увидеть в отчетах свежие данные.
Таким образом, задача контроля использования памяти таблицами — ключевая для стабильности работы SAP BW, основанных на SAP HANA. Задача довольно непростая, особенно если ваша система SAP BW развивается и эксплуатируется уже десяток лет сотнями пользователей. Маловероятно, что вам поможет какая‑то одна из мер, какое‑то одно из «лекарств». Скорее всего, речь пойдет о комплексной и постоянной терапии — ведь кол‑во данных прибавляется день ото дня, даже если бизнес не растет. А если, к счастью, бизнес прирастает год‑к-году, то каждый следующий год будет больше новых данных, чем в предыдущий.
В основе всех оптимизационных мер — разделение данных на, условно, «нужные» каждый день (hot), «нужные пореже» (warm) и «нужные очень редко» (cold). Эти три категории данных должны хранится в разных «контейнерах» (обобщенная формулировка, поэтому в кавычках), чтобы либо у администратора BW, либо у процессов SAP HANA была возможность выгрузить такой контейнер из оперативной памяти сервера, а то и выгрузить совсем из SAP BW. Такими «контейнерами» могут быть партиции ADSO, партиции ADSO в NSE, партиции в SAP IQ (бывш. Sybase IQ) или даже целиком ADSO. Подробнее про NSE и SAP IQ лучше почитать в официальной документации SAP. Выскажу лишь персональные наблюдения. Использование сторонней БД SAP IQ для хранения самых редко используемых данных не является эффективным. Это сильно усложнит серверный ландшафт (особенно в случае полного резервирования оборудования Disaster Recovery), потребует от вашей команды компетенций администрирования еще одной СУБД, которую в силу лицензий вы можете использовать только для одного сценария — хранение cold‑данных с доступом только из SAP BW. И влиять на производительность отчетов, использующих cold‑данные, гораздо сложнее, потому что это «внутренняя кухня» SAP BW и SAP HANA. На мой взгляд, при наличии лицензии OpenHub (входит в лицензию SAP BW/4) более оптимально использовать для cold‑данных подходящую стороннюю СУБД, по которой в вашей компании уже есть компетенции либо вы готовы их развивать. Хотя в этом вопросе много пространства для дискуссий.
Если начать разделение на hot‑warm‑cold с данных, имеющих наибольший размер, то и первые результаты будут заметнее и вдохновят вас на дальнейшие работы. Определить данные наибольшего размера в SAP HANA удобнее через системные view. Вам решать, какой критерий для этого использовать: занимаемую оперативную память или занимаемую память на диске. На мой взгляд, если мы видим в оперативной памяти огромный непартицированный ADSO, хранящий данные за 3 последних года, а, по словам пользователей (или по данным статистики), необходимы лишь данные последнего года, то, очевидно, грамотное партицирование может принести толк. Напишите в комментах, почему партицирования все же недостаточно для того, чтобы SAP HANA хранила в оперативной памяти данные только последнего года.
Переведя партиции с «warm»‑данными в NSE, вы ограничите «сверху» объем оперативной памяти HANA, которое СУБД использует для _всех_ сегментов (партиций или целых таблиц), относящихся к NSE. Цена, которую придется за это заплатить, производительность доступа к таким данным. Но ее придется платить не всегда. И причина этого — та же, что и в моем вопросе выше по тексту.
Оптимизировав структуру хранения TopN ADSO вы уже можете добиться если даже не сокращения среднего потребления памяти под все таблицы, то хотя бы прекращения его роста на горизонте нескольких месяцев. Что можно предпринять далее? Наладить процессы регулярного (раз в 1–2 месяца) мониторинга SAP HANA и изменения структуры хранения данных ADSO. У каких‑то ADSO надо создать дополнительные партиции, у других, наоборот, объединить в одну, у третьих — перевести часть партиций в NSE, что‑то вообще выгрузить из BW, что‑то переместить в «cold» ADSO и выгрузить из памяти. Поскольку хранилище не только прирастает новыми данными в текущих ADSO, но и создаются новые ADSO, то процесс оптимизации хранения должен быть в составе регулярного обслуживания SAP BW. Как регулярная уборка в квартире или доме.
По аналогии с квартирой или домом, в HANA есть свой «робот‑пылесос». Как и в случае с реальным пылесосом, он не будет эффективен, если его движению создаются помехи. Но если помех нет, то это хорошее подспорье для администратора SAP BW. Речь идет о параметрах сервера unused_retention_period и unused_retention_period_check_interval. Каждые N секунд, определяемые во втором параметре, SAP HANA проверяет, какие сегменты (колонки, партиции, таблицы) не использовались последние M секунд (определяемые 1-м параметром) и выгружает их в очередности согласно UNLOAD PRIORITY. Значение по умолчанию для 1-ого параметра — 0, что означает отключение автоматического механизма «робота‑пылесоса». Значение по умолчанию для 2-ого параметра — 7200 (2 часа). По нашему опыту, значение 1-ого параметра 86 400 (24 часа) наиболее эффективно, т.к. соответствует регулярности использования данных. Пробуя выставить параметр на 18h получили заметный рост потребления CPU (контроль выполняли по одному из SAP HANA MiniChecks) и вернулись к исходным 24h. Впрочем, оптимальная настройка параметров определяется для каждой системы в каждый момент времени индивидуально.
Настройка (при выполненном заранее партицировании) позволила снизить среднее потребление памяти сразу на 40%. И теперь мы получили новый средний уровень потребления, который не только обеспечил нам стабильность выполнения ночных процессов, но и дает больше уверенности в том, что текущее оборудование для SAP HANA будет достаточно по памяти еще несколько лет. Рост под контролем!