Вселенная отчётности на SAP



    Примерно 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. Правда, она отражает только десятую часть нашей системы.



    Производительность


    На момент объединения «М.Видео» и «Эльдорадо», объем данных в двух системах отчётности был около 10 Тб: 7 Тб в системе BW on HANA «М.Видео», 2 Тб — в BW on HANA «Эльдорадо» и 1 Тб дополнительных данных в HADOOP (исторические данные). При объединении систем у нас были аппаратные ограничения: комплекс «М.Видео» состоял из 6 нод (по 2 Тб), в том числе одна резервная. Эту систему можно было расширить максимум до 8 нод, из которых одна резервная.

    При подготовке к объединению мы предполагали, что общий объем всех данных достигнет 13 Тб. Поэтому, исходя из рекомендаций SAP, нам необходима была система из 16 нод по 2 Тб, в том числе две резервные. Также один узел нужно было выделить в качестве мастер-ноды, которая при таком объёме информации брала бы на себя функции управления. То есть для корректной работы нужно было развернуть 13 нод.

    Как видите, доступных ресурсов категорически не хватало. И это был первый вызов.

    Второй главной трудностью до объединения было то, что скорость работы системы часто не удовлетворяла запросам бизнеса. Основной причиной было большое количество параллельных обращений к БД. С точки зрения системы это выглядело как снежный ком, который мог привести либо к зависанию и прерыванию работы части процессов, либо даже к глобальным дампам «out of memory» на узлах.

    Было понятно, что без существенных доработок двукратное увеличение объёмов данных в отчётах (для двух брендов) приведёт к примерно двукратному ухудшению ситуации.

    Поэтому мы решили оптимизировать систему по следующим направлениям:

    • Отчётность. Ускорение наиболее критичных и наиболее ресурсоёмких отчётов и пересмотр модели данных.
    • Хранилище. Архивация и оптимизация хранения.
    • Загрузки. Оптимизация процедуры и изменение расписания загрузок.

    Общий подход к оптимизации был таким:



    Сначала мы проводили анализ по всем направлениям, выявляли причины проблем, а затем анализировали возможности системы с требуемыми ресурсами. Также мы сразу постарались максимально автоматизировать этот процесс, чтобы в дальнейшем быстрее выявлять причины проблем и оперативно восстанавливать производительность.

    Что мы сделали:

    • Изменили конфигурацию серверов приложений ABAP: количество инстанций, эффективное использование технологии NUMA и оптимальное количество рабочих процессов.
    • Применили оптимальные параметры HANA и операционной системы Linux.
    • Проанализировали снижение потребления ЦПУ.
    • Проанализировали потребление ОЗУ во всём наблюдаемом интервале времени.
    • Проанализировали возникновение OOM на HANA.
    • Проанализировали возникновение блокировок в системе и доступности системных ресурсов по операциям ожидания (wait).
    • Проанализировали балансировку данных с учётом редистрибуции и репартицирования данных для решения SCALE-OUT HANA.
    • Проанализировали причины ABAP-дампов, влияющих на работу критически важных цепочек.

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

    Каких результатов удалось добиться:









    Ряд оптимизированных отчётов SAP BO стали работать во много раз быстрее и потреблять в сотни раз меньше памяти.



    Вот несколько ярких примеров того, как система некорректно отрабатывает условия выбора, и как нужно правильно строить запросы в HANA.

    Выявлены проблемы при фильтрации по нематериализованным объектам, особенно (!) при использовании показателей COUNT DISTINCT (CD может быть прописан как на уровне Universe, так и в функции в CV).



    Даже если исключить CD из запроса, первый вариант всё равно будет выполняться в 20 раз медленнее, чем второй, а при CD скорость получается выше более чем в 500 раз.



    Частный случай использования нематериализованных объектов в фильтрах: составные фильтры из двух и более объектов, например, склеивание недели и года:



    Запросы со склеенными фильтрами работают не так медленно, как преобразование в дату, но всё же сильно замедляют запросы (примерно в 2-3 раза).



    Для сбора статистики о работе системы отчётности, процессов загрузки и цепочек мы разработали такую схему:



    При этом во все отчёты мы добавили специальный комментарий с названием отчёта. Таким образом, мы можем сравнивать нагрузку от различных частей системы и сравнивать период к периоду.



    Планы


    У нас много планов по развитию бизнес-функциональности и существенной переработке инструмента визуализации данных. Глобальный тренд, в котором мы активно участвуем, заключается во встраивании системы отчётности в парадигму цифровой трансформации.

    Что имеется в виду?

    Когда наша система отчётности была молода, к нам часто приходили пользователи с подобными просьбами: «Автоматизируйте построение отчёта, который показывает, сколько чистой прибыли получил тот или иной магазин, или вся компания».

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

    А сегодня мы пришли к тому, что пользователи хотят знать точный прогноз чистой прибыли. У нас есть все необходимые данные для разработки алгоритмов прогнозирования, и есть специалисты по анализу данных, способные создавать модели машинного обучения. Как вы понимаете, для этого нужны действительно большие объёмы данных, так что один из главных трендов в развитии нашей системы отчётности — переход к анализу и созданию моделей на основе big data.

    Пара слов о нашей команде


    Сегодня в крупных компаниях всё чаще внедряют системы прогнозирования, которые построены на алгоритмах машинного обучения, разрабатываемых самой системой. Два года назад у нас появился центр компетенции в сфере анализа данных Digital Retail Data Science Centre, а в этом году у нас появилась группа data-инженеров. Мы внедряем новую систему для обработки и анализа больших данных. И нам в команду нужны люди в отделы поддержки, развития и прикладного анализа данных.

    Если вам интересны эти направления, если чувствуете в себе силы — добро пожаловать! Вас ждёт интересная и непростая работа, иногда стрессовая, но всегда творческая.

    Комментарии 13

      0
      Сегодня из нескольких тысяч отчётов, создаваемых системой, всего 10 генерируют 70% всей нагрузки.

      Основным способом оптимизации отчетов является преподсчет информации, а затем инкрементное ее обновление по мере появления новых данных. Скажите, а почему нельзя было сделать это для этих 10 отчетов? То есть, грубо говоря, если они генерирует столько нагрузки, значит они постоянно «пробегают» по большому количеству информации и считают какие-то агрегирующие функции. Почему их не рассчитать заранее, а в отчетах уже обращаться к ним (по сути, схожая схема реализована в OLAP)?
        0
        Добрый день!
        Это интересный вопрос.
        Текущее состояние в системе отчетности и в материализации/предрасчете результатов отчетов это некий баланс между следующими аспектами:
        1. гибкость модели данных, мы стараемся придерживаться концепции LSA++, у нас очень часто бизнес меняет какие-либо алгоритмы расчета показателей, или же атрибутику и иерархии, которые должны ретроспективно отразится на всем периоде данных анализируем регулярно (а это три года, а данных много);
        2. доступность системы отчетности для разработки со стороны бизнес подразделений. Так сейчас в компании есть центры компетенций и отдельные аналитики создающие свои собственные отчеты в на базе Univers'а в SAP BO. Сейчас никто не ограничивает бизнес делать любую отчетность над всей глубиной данных в любой детализации. В случае предрасчитанных материализованных VIEW, они были бы ограничены рамками этих VIEW. И добавление аналитики в это VIEW потребовало подключение ИТ;
        3. Производительностью системы. И вот здесь мы обнаружили ряд кейсов, про которые я рассказал выше, ряд которые не описывал применяя которые мы существенно сократили время работы и нагрузку на систему HANA со стороны BO. А если еще регулярно проводить мониторинг разработки со стороны бизнеса, то HANA позволяет достаточно оперативно обрабатывать даже такие где-то не оптимальные с точки зрения объема данных запросы

        При этом есть ряд базовых показателей и атрибутик, которые ранее у нас так же всегда считались на лету, но мы обсудив с бизнесов поняли, что алгоритмы расчета этих аналитик жестко фиксированные и такие объекты мы «приземлили» в хранилище и считаем на уровне ETL, чтобы снять регулярную нагрузку
        В общем как-то так, каждый ищет для себя золотую середину, она у нас пока в виртуальное моделе финальных данных для КХД
          0
          которые должны ретроспективно отразится на всем периоде данных анализируем регулярно

          Зато можно получить вопросы в стиле — «Вчера были совершенно другие данные». А окажется, что просто формулы поменялись. Но опять же, не очень понимаю, что мешает их пересчитать при изменении формулы. Причем это можно сделать параллельно, а потом просто переключить формулы на новые данные.

          доступность системы отчетности для разработки со стороны бизнес подразделений. Так сейчас в компании есть центры компетенций и отдельные аналитики создающие свои собственные отчеты в на базе Univers'а в SAP BO. Сейчас никто не ограничивает бизнес делать любую отчетность над всей глубиной данных в любой детализации. В случае предрасчитанных материализованных VIEW, они были бы ограничены рамками этих VIEW. И добавление аналитики в это VIEW потребовало подключение ИТ;


          Извините, но не понял почему. Вот есть «материализованный VIEW». Кто хочет использует его, кто не хочет — пусть бегает хоть по всем данным. Каким образом наличие преподсчитанных данных ограничивает что-то?

          Производительностью системы. И вот здесь мы обнаружили ряд кейсов, про которые я рассказал выше, ряд которые не описывал применяя которые мы существенно сократили время работы и нагрузку на систему HANA со стороны BO. А если еще регулярно проводить мониторинг разработки со стороны бизнеса, то HANA позволяет достаточно оперативно обрабатывать даже такие где-то не оптимальные с точки зрения объема данных запросы

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

          Так в этом и вопрос: почему балансировка не привела к тому, чтобы снять 70% загрузки из 10 отчетов за счет преподсчета для них данных.

          0
          Действительно как то странно
          Сегодня в ней хранится около 10 000 таблиц, ею пользуется 38 000 человек и в ней ежедневно происходят более 5000 процессов загрузки
          звучит для непосвящённого человека мало. Кроме упомянутого LeshaLS
          можно каждый элемент не перепросчитывать а использовать разные мат. оптимизации.
          Например вы считаете среднее значение по некоему массиву и к нему дополнилось новое число. Глупый посчитает опять всю сумму и разделит на n+1. Умный сделает
          new_avg = (n * old_avg + new_value) / (n+1)
          0
          … создали сервис, который при звонке клиента по номеру его телефона автоматически открывает отчёт и показывает оператору всю историю покупок звонящего

          Недельный отчёт открывается 30мин. А сколько времени открывается операционный при звонке клиента?
          В своё время в похожем проекте приняли 10 секунд как максимально терпимое.
          Недельные отрабатывали тоже по полчаса. Это всё было 11 лет назад. Вот интересно, что изменилось с тех пор.
            0

            Эти сервисы были переведены на уровень буфера апликейшн сервера.
            Сейчас скорость работы около 0,3 — 0,7 секунд.
            Есть сервисы которые не переведены на уровень буфера, там идёт он-лайн запрос к БД и скорость от 1 секунды и до 10-ков

            0
            При этом Hana оказалась примерно в 20 раз производительнее Oracle, DB2 и MySQL.

            У Oracle/DB2 тоже было 8 нод и 14 TB RAM? ;)

            Поэтому, исходя из рекомендаций SAP, нам необходима была система из 16 нод по 2 Тб,

            Почему не 11 x 3 TB? Меньше нод — меньше проблем.
            Вариант перехода на scale-up + BW NLS на IQ не рассматривали?

            Применили оптимальные параметры HANA и операционной системы Linux.

            Что именно и насколько крутили не поделитесь?

              0

              Доброго времени суток.
              Понятно, что ORACLE не обладал такой RAM но сам комплекс компании обходился не многим дешевле чем комплекс HANA. В ORACLE нужно примерно в 10 раз больше СХД, нужны агрегаты, индексы, данные не сжаты поколоночно.
              Естественно я говорю про старые версии ORACLE и те ограничения что есть в SAP BW on Oracle


              Вы правы, наш опыт показывает, чем нод меньше, тем с системой проще "разбираться" и использование памяти более оптимально. Обратная сторона это CPU, хоть SAP и сертифицирует только оборудование, которое выдаёт определённый коэффициент Gb RAM/CPU, обычно на более "толстых" узлах количество CPU ниже. Если у Вас профиль нагрузки в основном упирается в CPU, то лучше больше маленьких нод с большим количеством CPU.
              Если говорит, про нашу ситуацию, то мы жили в рамках нашей инфраструктуры, комплекс покупался в 2014-ом, на тот момент 2Тб — было максимум


              Про параметры в БД возможно напишу отдельный пост. Если интересно

              0
              " WHERE
              to_date(Table__78.«CALDAY» ) = current_date "

              Это что за ад вообще? :-) Наследие индусов из стандарта BW или стажеры баловались?
                0
                Сразу вспоминается Матрица:
                Информации, получаемой из Матрицы, гораздо больше, чем ты можешь расшифровать. Ты привыкнешь к этому. Я уже даже не вижу код. Я вижу блондинку, брюнетку, рыжую.
                  0

                  Рад, что понравилось.
                  Да это некий стандарт от SAP BUSINESS OBJECT UNIVERS. Чтоб победить, нужно из вернуться
                  )

                  0
                  А разве SAP Hana работает не поверх обычной БД?
                    0

                    Нет HANA — это и есть БД

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое