Comments 13
Сегодня из нескольких тысяч отчётов, создаваемых системой, всего 10 генерируют 70% всей нагрузки.
Основным способом оптимизации отчетов является преподсчет информации, а затем инкрементное ее обновление по мере появления новых данных. Скажите, а почему нельзя было сделать это для этих 10 отчетов? То есть, грубо говоря, если они генерирует столько нагрузки, значит они постоянно «пробегают» по большому количеству информации и считают какие-то агрегирующие функции. Почему их не рассчитать заранее, а в отчетах уже обращаться к ним (по сути, схожая схема реализована в OLAP)?
Добрый день!
Это интересный вопрос.
Текущее состояние в системе отчетности и в материализации/предрасчете результатов отчетов это некий баланс между следующими аспектами:
1. гибкость модели данных, мы стараемся придерживаться концепции LSA++, у нас очень часто бизнес меняет какие-либо алгоритмы расчета показателей, или же атрибутику и иерархии, которые должны ретроспективно отразится на всем периоде данных анализируем регулярно (а это три года, а данных много);
2. доступность системы отчетности для разработки со стороны бизнес подразделений. Так сейчас в компании есть центры компетенций и отдельные аналитики создающие свои собственные отчеты в на базе Univers'а в SAP BO. Сейчас никто не ограничивает бизнес делать любую отчетность над всей глубиной данных в любой детализации. В случае предрасчитанных материализованных VIEW, они были бы ограничены рамками этих VIEW. И добавление аналитики в это VIEW потребовало подключение ИТ;
3. Производительностью системы. И вот здесь мы обнаружили ряд кейсов, про которые я рассказал выше, ряд которые не описывал применяя которые мы существенно сократили время работы и нагрузку на систему HANA со стороны BO. А если еще регулярно проводить мониторинг разработки со стороны бизнеса, то HANA позволяет достаточно оперативно обрабатывать даже такие где-то не оптимальные с точки зрения объема данных запросы
При этом есть ряд базовых показателей и атрибутик, которые ранее у нас так же всегда считались на лету, но мы обсудив с бизнесов поняли, что алгоритмы расчета этих аналитик жестко фиксированные и такие объекты мы «приземлили» в хранилище и считаем на уровне ETL, чтобы снять регулярную нагрузку
В общем как-то так, каждый ищет для себя золотую середину, она у нас пока в виртуальное моделе финальных данных для КХД
Это интересный вопрос.
Текущее состояние в системе отчетности и в материализации/предрасчете результатов отчетов это некий баланс между следующими аспектами:
1. гибкость модели данных, мы стараемся придерживаться концепции LSA++, у нас очень часто бизнес меняет какие-либо алгоритмы расчета показателей, или же атрибутику и иерархии, которые должны ретроспективно отразится на всем периоде данных анализируем регулярно (а это три года, а данных много);
2. доступность системы отчетности для разработки со стороны бизнес подразделений. Так сейчас в компании есть центры компетенций и отдельные аналитики создающие свои собственные отчеты в на базе Univers'а в SAP BO. Сейчас никто не ограничивает бизнес делать любую отчетность над всей глубиной данных в любой детализации. В случае предрасчитанных материализованных VIEW, они были бы ограничены рамками этих VIEW. И добавление аналитики в это VIEW потребовало подключение ИТ;
3. Производительностью системы. И вот здесь мы обнаружили ряд кейсов, про которые я рассказал выше, ряд которые не описывал применяя которые мы существенно сократили время работы и нагрузку на систему HANA со стороны BO. А если еще регулярно проводить мониторинг разработки со стороны бизнеса, то HANA позволяет достаточно оперативно обрабатывать даже такие где-то не оптимальные с точки зрения объема данных запросы
При этом есть ряд базовых показателей и атрибутик, которые ранее у нас так же всегда считались на лету, но мы обсудив с бизнесов поняли, что алгоритмы расчета этих аналитик жестко фиксированные и такие объекты мы «приземлили» в хранилище и считаем на уровне ETL, чтобы снять регулярную нагрузку
В общем как-то так, каждый ищет для себя золотую середину, она у нас пока в виртуальное моделе финальных данных для КХД
которые должны ретроспективно отразится на всем периоде данных анализируем регулярно
Зато можно получить вопросы в стиле — «Вчера были совершенно другие данные». А окажется, что просто формулы поменялись. Но опять же, не очень понимаю, что мешает их пересчитать при изменении формулы. Причем это можно сделать параллельно, а потом просто переключить формулы на новые данные.
доступность системы отчетности для разработки со стороны бизнес подразделений. Так сейчас в компании есть центры компетенций и отдельные аналитики создающие свои собственные отчеты в на базе Univers'а в SAP BO. Сейчас никто не ограничивает бизнес делать любую отчетность над всей глубиной данных в любой детализации. В случае предрасчитанных материализованных VIEW, они были бы ограничены рамками этих VIEW. И добавление аналитики в это VIEW потребовало подключение ИТ;
Извините, но не понял почему. Вот есть «материализованный VIEW». Кто хочет использует его, кто не хочет — пусть бегает хоть по всем данным. Каким образом наличие преподсчитанных данных ограничивает что-то?
Производительностью системы. И вот здесь мы обнаружили ряд кейсов, про которые я рассказал выше, ряд которые не описывал применяя которые мы существенно сократили время работы и нагрузку на систему HANA со стороны BO. А если еще регулярно проводить мониторинг разработки со стороны бизнеса, то HANA позволяет достаточно оперативно обрабатывать даже такие где-то не оптимальные с точки зрения объема данных запросы
Инкрементальное обновление данных, в зависимости от выбранных структур хранения, чаще всего можно сделать за логарифм. То есть на производительность это не должно сильно влиять.
При этом есть ряд базовых показателей и атрибутик, которые ранее у нас так же всегда считались на лету, но мы обсудив с бизнесов поняли, что алгоритмы расчета этих аналитик жестко фиксированные и такие объекты мы «приземлили» в хранилище и считаем на уровне ETL, чтобы снять регулярную нагрузку
Так в этом и вопрос: почему балансировка не привела к тому, чтобы снять 70% загрузки из 10 отчетов за счет преподсчета для них данных.
Действительно как то странно
можно каждый элемент не перепросчитывать а использовать разные мат. оптимизации.
Например вы считаете среднее значение по некоему массиву и к нему дополнилось новое число. Глупый посчитает опять всю сумму и разделит на n+1. Умный сделает
new_avg = (n * old_avg + new_value) / (n+1)
Сегодня в ней хранится около 10 000 таблиц, ею пользуется 38 000 человек и в ней ежедневно происходят более 5000 процессов загрузкизвучит для непосвящённого человека мало. Кроме упомянутого LeshaLS
можно каждый элемент не перепросчитывать а использовать разные мат. оптимизации.
Например вы считаете среднее значение по некоему массиву и к нему дополнилось новое число. Глупый посчитает опять всю сумму и разделит на n+1. Умный сделает
new_avg = (n * old_avg + new_value) / (n+1)
… создали сервис, который при звонке клиента по номеру его телефона автоматически открывает отчёт и показывает оператору всю историю покупок звонящего
Недельный отчёт открывается 30мин. А сколько времени открывается операционный при звонке клиента?
В своё время в похожем проекте приняли 10 секунд как максимально терпимое.
Недельные отрабатывали тоже по полчаса. Это всё было 11 лет назад. Вот интересно, что изменилось с тех пор.
При этом 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.
Что именно и насколько крутили не поделитесь?
Доброго времени суток.
Понятно, что ORACLE не обладал такой RAM но сам комплекс компании обходился не многим дешевле чем комплекс HANA. В ORACLE нужно примерно в 10 раз больше СХД, нужны агрегаты, индексы, данные не сжаты поколоночно.
Естественно я говорю про старые версии ORACLE и те ограничения что есть в SAP BW on Oracle
Вы правы, наш опыт показывает, чем нод меньше, тем с системой проще "разбираться" и использование памяти более оптимально. Обратная сторона это CPU, хоть SAP и сертифицирует только оборудование, которое выдаёт определённый коэффициент Gb RAM/CPU, обычно на более "толстых" узлах количество CPU ниже. Если у Вас профиль нагрузки в основном упирается в CPU, то лучше больше маленьких нод с большим количеством CPU.
Если говорит, про нашу ситуацию, то мы жили в рамках нашей инфраструктуры, комплекс покупался в 2014-ом, на тот момент 2Тб — было максимум
Про параметры в БД возможно напишу отдельный пост. Если интересно
" WHERE
to_date(Table__78.«CALDAY» ) = current_date "
Это что за ад вообще? :-) Наследие индусов из стандарта BW или стажеры баловались?
to_date(Table__78.«CALDAY» ) = current_date "
Это что за ад вообще? :-) Наследие индусов из стандарта BW или стажеры баловались?
А разве SAP Hana работает не поверх обычной БД?
Sign up to leave a comment.
Вселенная отчётности на SAP