![](https://habrastorage.org/webt/nf/96/da/nf96daardoyhax1e_lj6oy2wk9o.jpeg)
Примерно 4 года назад мы перенесли нашу систему отчётности с Oracle на SAP Hana. Сегодня в ней хранится около 10 000 таблиц, ею пользуется 38 000 человек и в ней ежедневно происходят более 5000 процессов загрузки. На текущий момент наш комплекс, на котором работает система, представляет собой 8 серверов с 14 Тб памяти. Каждый день в системе отчётности обрабатывается 1,5 Пб данных. При этом Hana оказалась примерно в 20 раз производительнее Oracle, DB2 и MySQL. И сегодня я хочу рассказать, как мы в рамках интеграции «М.Видео» и «Эльдорадо» дополнительно повышали производительность системы отчётности, какие оптимизации вносили.
Нагрузка
Сегодня из нескольких тысяч отчётов, создаваемых системой, всего 10 генерируют 70% всей нагрузки. Самый тяжелый отчёт в базе данных Hana — Weekly Bussines Review. Он выполняется 30 минут и потребляет 4 Тб памяти. 90% всех отчётов генерирует контактный центр: мы создали сервис, который при звонке клиента по номеру его телефона автоматически открывает отчёт и показывает оператору всю историю покупок звонящего и его взаимодействия с компанией.
Модель данных
Ключевая модель данных, на которой строится основной объем отчётов, содержит 1500 таблиц. Большинство из них — таблицы справочников. С помощью этой модели можно проанализировать любое направление деятельности компании. На примере — визуализация модели данных, созданная с помощью Universe designer. Правда, она отражает только десятую часть нашей системы.
![](https://habrastorage.org/getpro/habr/post_images/054/47a/9d3/05447a9d3d7447a41a4732c49a7b205d.png)
Производительность
На момент объединения «М.Видео» и «Эльдорадо», объем данных в двух системах отчётности был около 10 Тб: 7 Тб в системе BW on HANA «М.Видео», 2 Тб — в BW on HANA «Эльдорадо» и 1 Тб дополнительных данных в HADOOP (исторические данные). При объединении систем у нас были аппаратные ограничения: комплекс «М.Видео» состоял из 6 нод (по 2 Тб), в том числе одна резервная. Эту систему можно было расширить максимум до 8 нод, из которых одна резервная.
При подготовке к объединению мы предполагали, что общий объем всех данных достигнет 13 Тб. Поэтому, исходя из рекомендаций SAP, нам необходима была система из 16 нод по 2 Тб, в том числе две резервные. Также один узел нужно было выделить в качестве мастер-ноды, которая при таком объёме информации брала бы на себя функции управления. То есть для корректной работы нужно было развернуть 13 нод.
Как видите, доступных ресурсов категорически не хватало. И это был первый вызов.
Второй главной трудностью до объединения было то, что скорость работы системы часто не удовлетворяла запросам бизнеса. Основной причиной было большое количество параллельных обращений к БД. С точки зрения системы это выглядело как снежный ком, который мог привести либо к зависанию и прерыванию работы части процессов, либо даже к глобальным дампам «out of memory» на узлах.
Было понятно, что без существенных доработок двукратное увеличение объёмов данных в отчётах (для двух брендов) приведёт к примерно двукратному ухудшению ситуации.
Поэтому мы решили оптимизировать систему по следующим направлениям:
- Отчётность. Ускорение наиболее критичных и наиболее ресурсоёмких отчётов и пересмотр модели данных.
- Хранилище. Архивация и оптимизация хранения.
- Загрузки. Оптимизация процедуры и изменение расписания загрузок.
Общий подход к оптимизации был таким:
![](https://habrastorage.org/getpro/habr/post_images/1aa/534/20d/1aa53420d809464c7d3f28bd9761e411.png)
Сначала мы проводили анализ по всем направлениям, выявляли причины проблем, а затем анализировали возможности системы с требуемыми ресурсами. Также мы сразу постарались максимально автоматизировать этот процесс, чтобы в дальнейшем быстрее выявлять причины проблем и оперативно восстанавливать производительность.
Что мы сделали:
- Изменили конфигурацию серверов приложений ABAP: количество инстанций, эффективное использование технологии NUMA и оптимальное количество рабочих процессов.
- Применили оптимальные параметры HANA и операционной системы Linux.
- Проанализировали снижение потребления ЦПУ.
- Проанализировали потребление ОЗУ во всём наблюдаемом интервале времени.
- Проанализировали возникновение OOM на HANA.
- Проанализировали возникновение блокировок в системе и доступности системных ресурсов по операциям ожидания (wait).
- Проанализировали балансировку данных с учётом редистрибуции и репартицирования данных для решения SCALE-OUT HANA.
- Проанализировали причины ABAP-дампов, влияющих на работу критически важных цепочек.
По результатам составили отчёты о производительности, а также инструкции, чтобы в дальнейшем можно было самостоятельно определять узкие места в системе и пиковые интервалы времени.
Каких результатов удалось добиться:
![](https://habrastorage.org/getpro/habr/post_images/82a/e7e/382/82ae7e3826abf0a8eaf2cafb2c10d27b.png)
![](https://habrastorage.org/getpro/habr/post_images/d5a/b6e/221/d5ab6e221145f19b6f385738f57d9dca.png)
![](https://habrastorage.org/getpro/habr/post_images/a5e/a35/4d2/a5ea354d258baaed8ef8176ad0a0ad45.png)
![](https://habrastorage.org/getpro/habr/post_images/1dc/654/1f7/1dc6541f7d68c70012d8203e92182775.png)
Ряд оптимизированных отчётов SAP BO стали работать во много раз быстрее и потреблять в сотни раз меньше памяти.
![](https://habrastorage.org/getpro/habr/post_images/7fc/ed2/3c7/7fced23c7b586cf2334745b265245447.png)
Вот несколько ярких примеров того, как система некорректно отрабатывает условия выбора, и как нужно правильно строить запросы в HANA.
Выявлены проблемы при фильтрации по нематериализованным объектам, особенно (!) при использовании показателей
COUNT DISTINCT
(CD может быть прописан как на уровне Universe, так и в функции в CV).![](https://habrastorage.org/getpro/habr/post_images/c2c/25c/e8c/c2c25ce8cab11363b6dd1958c9b1c25a.png)
Даже если исключить CD из запроса, первый вариант всё равно будет выполняться в 20 раз медленнее, чем второй, а при CD скорость получается выше более чем в 500 раз.
![](https://habrastorage.org/getpro/habr/post_images/1dc/f0b/6a3/1dcf0b6a38e4053829e20a531d67c45a.png)
Частный случай использования нематериализованных объектов в фильтрах: составные фильтры из двух и более объектов, например, склеивание недели и года:
![](https://habrastorage.org/getpro/habr/post_images/cda/a3a/d8e/cdaa3ad8e73905c217346b6b00004dd0.png)
Запросы со склеенными фильтрами работают не так медленно, как преобразование в дату, но всё же сильно замедляют запросы (примерно в 2-3 раза).
![](https://habrastorage.org/getpro/habr/post_images/cec/182/9d6/cec1829d65a06d6d73f53b2110cfc4e3.png)
Для сбора статистики о работе системы отчётности, процессов загрузки и цепочек мы разработали такую схему:
![](https://habrastorage.org/getpro/habr/post_images/9fc/3c5/d8a/9fc3c5d8aab834bca29c4988592f25f8.png)
При этом во все отчёты мы добавили специальный комментарий с названием отчёта. Таким образом, мы можем сравнивать нагрузку от различных частей системы и сравнивать период к периоду.
![](https://habrastorage.org/getpro/habr/post_images/14e/665/69b/14e66569bb4292fb4e66364fe51de6be.png)
Планы
У нас много планов по развитию бизнес-функциональности и существенной переработке инструмента визуализации данных. Глобальный тренд, в котором мы активно участвуем, заключается во встраивании системы отчётности в парадигму цифровой трансформации.
Что имеется в виду?
Когда наша система отчётности была молода, к нам часто приходили пользователи с подобными просьбами: «Автоматизируйте построение отчёта, который показывает, сколько чистой прибыли получил тот или иной магазин, или вся компания».
Затем к нам стали приходить с просьбами придумать алгоритм, который бы строил план или прогноз получения чистой прибыли в зависимости от конкретных факторов.
А сегодня мы пришли к тому, что пользователи хотят знать точный прогноз чистой прибыли. У нас есть все необходимые данные для разработки алгоритмов прогнозирования, и есть специалисты по анализу данных, способные создавать модели машинного обучения. Как вы понимаете, для этого нужны действительно большие объёмы данных, так что один из главных трендов в развитии нашей системы отчётности — переход к анализу и созданию моделей на основе big data.
Пара слов о нашей команде
Сегодня в крупных компаниях всё чаще внедряют системы прогнозирования, которые построены на алгоритмах машинного обучения, разрабатываемых самой системой. Два года назад у нас появился центр компетенции в сфере анализа данных Digital Retail Data Science Centre, а в этом году у нас появилась группа data-инженеров. Мы внедряем новую систему для обработки и анализа больших данных. И нам в команду нужны люди в отделы поддержки, развития и прикладного анализа данных.
Если вам интересны эти направления, если чувствуете в себе силы — добро пожаловать! Вас ждёт интересная и непростая работа, иногда стрессовая, но всегда творческая.
![](https://habrastorage.org/files/fa7/d16/199/fa7d16199fca4fee89c0b96fa9919513.png)