Oracle Hyperion Performance Lab

1*) Требования к инфраструктуре

1. Жесткие диски

• Общие требования к БД:

1. разделять массивы для файлов индекса и данных
2. Использовать диски собранные в массивы RAID 10 или 50 уровней
3. Чем больше дисков в массиве, тем лучше показатель IO

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

1. Нельзя использовать DirectIO
2. Нельзя использовать CACHE MEMORY LOCKING (отключение использования виртуальной памяти)
3. Рекомендуют использовать отдельный линк, что бы не стать жертвой сетевых задержек SAN (NAS)

Ввиду того что DirectIO, плохо работает с конкурентными расчетами (конкурентные отчеты можно отключить параметром EXCLUSIVECALC TRUE в файле Essbase.cfg (он также отключает вызов CDF)) , и поддерживается  не на всех платформах,   то существенных ограничений на использование внешних массивов дисков нет.

1. Память

• Для 64 битых систем – основным способом оптимизации является  выделение всей доступной памяти для кэширования, поэтому, чем больше памяти, тем лучше.
• Для 32 битных систем – 3 Gb на каждое приложение + 2Gb на систему.

1. Процессор

• Intel Xeon ,  лучше более быстрый,  нежели более «ядерный»
• Power5 (AIX), SPARC(SOLARIS)  – проигрывают по производительности в разы Intel’u.
• Для расчета потребности кол-ва процессоров от пользователей можно воспользоваться формулой – 50 пользователей на 1 процессор, так же нужно учитывать фактор  конкурентных и параллельных расчетов, т.е. на каждое конкурентное приложение 4 – камня.

2*) Количество БД в одном приложении

Разрешено до 4-x приложений, рекомендуемое значение 1, так как только в этом случае избегаются риски, связанные с тем, что Essbase  запускает отдельный обслуживающий процесс для каждого приложения (не для БД ):

• Утилизация памяти (актуально для 32 битной версии) – нельзя выйти за порог 2GB для одного приложения.
• Конкурентные обслуживающие процессы по перестройке (restructure) БД, обновлению метаданных, выгрузке данных
• Единая точка восстановления, при возникновении XCP события в одном из кубов – страдают все соседи по приложению.
• Конкуренции  связанные с работой обслуживающего сервиса – Essbase Agent – он поддерживает параллельную работу только для приложений (не для БД )
• Блокировка изменений системных настроек одного куба при конкурентной активности (расчет, выгрузка) в соседнем кубе.
• Один поток на приложение по выгрузке данных
• Один лог файл на приложение.
• Но, если приложение не использует EPMA, для хранения и разделения направлений, то является допустимым  совмещения в одном приложении несколько БД, для решения задач разделения метаданных и данных.

3*) Количество направлений (измерений)  в одном приложении

Разрешается до 21 измерения в BSO кубе.  Оптимальными является кубы с 12 направлениями,  так же допустимым  является 14 направлений. Данное ограничение напрямую связанно с потенциальным размером БД, так как количество хранимых элементов каждого нового  направления является еще одним множителем в общем произведении расчета размера БД.

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

a)      – разделение приложений

b)      – совмещение нескольких измерений в одном

c)       – внесение в «блок» большего числа измерений

d)      – Использовать ASO для подсчета агрегатов по направлениям

4*) Требования к целостности справочников

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

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

- если есть необходимость  поддерживать в системе медленно изменяющие измерения, то можно выбрать след. подходы

1)  Разнести родителей и детей по двум разным направлениям, тогда срез НаправлениеРодителей ->НаправлениеДетей->Период-> Показатели   однозначно говорит о том, что в данный период времени данный филиал принадлежал этой дирекции. Хорошо подходит для ситуаций, когда происходит автоматическая загрузка данных в систему, т.е. когда можно исключить ошибки ручного ввода.  Что бы использовать данный подход в формах ввода Planning’a требуется вмешательство в программный код и написание своих Custom разработок.

Но несмотря на все сложности – данный подход универсален и позволяет держать несколько версий.

2) Если поддержка версий не требуется, и нет перехода через год  и в бизнес требованиях нет сложной логики по исключению оборотов внутри  подгруппы, то можно использовать аттрибутивные направления( Varying Attributes )

3) В одном направлении ввести две ветки – для ввода данных ( только нижний уровень с признаком ~) и агрегации ( только родители ) и либо с помощью формул элементов или  либо скриптов расчетов, основываясь на атрибутивных  признаках на элементах, включать для выбранного периода в агрегацию тот или иной элемент. В сложных случаях потребуется  использование CDF и вспомогательных таблиц .

5) *     Как выбирать направления для внесения в блок.

Для определения кандидатов для внесения в блок нужно руководствоваться след. критериями

a)  Размер блока не должен превышать величины 150Kbyte, его рассчитать можно как произведение количества хранимых элементов каждого направления на 8 байт (величина для хранения значения)

b)  Количество элементов в направлении должно изменяться минимально и как можно реже. Например, лучшими кандидатами на внесение в блок являются направления, хранящие в себе месяца, мультивалютность , показатели (accounts). Но если направление Account (статьи фин. , бух.,  упр.  учета ) изменяются очень часто, их кол-во зашкаливает и критично сказывается на размере блока то  допускается : вынесение  этого направления из блока или наоборот – оставить его в блоке в одиночестве.

c)  Так же при выборе  кандидатов, на внесение в блок измеряют псевдо параметр «плотности потока данных», т.е. определяют направления в  разрезе которых  данные поступают максимально «плотно», т.е.  когда  можно создать табличку, в осях которой находится направления – кандидаты на внесения в блок,  заполненную на 90%. Но стоит заметить, что Account && Period лучший выбор для внесения в блок и это удовлетворят в 90% случаев.

d)  Если данные загружаются помесячно, то можно рассмотреть вариант исключения периодов из блока.

К несчастью, универсального решения в данном вопросе нет, и только промышленная эксплуатация позволит выбрать решение  удовлетворяющие по критериям производительности и консистентное данной автоматизации.    (см Влияние роста размер БД на скорость расчетов )

6)* Как выбирать тип сжатия БД

Практическое значение имеют только два типа сжатия

1. BITMAP – тип сжатия по умолчанию. Хорош в случаях когда в блоке более двух направлений и в базе данных множество конкурентных расчетов. Наиболее безопасный и надежный способ хранения данных.

1. RLE – позволяет сократить размер БД на треть , по сравнению с Bitmap. Хорошо сжимает модели построенные для бюджетного планирования, так как в этом случае данные обычно имеют тенденцию повторятся в разрезе одного из направлений (периода времени). Хорошо подходит для случаев, когда  расчеты агрегатов в БД происходят в монопольном режиме.  Имеет ограничения в использовании:

• Хорошо жмет блоки состоящих из двух направлений
• Первое направление в блоке – наименее длинное.
• Плохо работает с конкурентными расчетами (может стать причиной XCP)

За счет того что БД имеет меньший размер, повышает скорость расчетов на 15%.

7)*Основные настройки конфигурационного файла Essbase.cfg

• AGTSVRCONNECTIONS   – определяет  кол-во потенциальных потоков между агентом и приложением.  (5)
• AGENTTHREADS – определяет общее кол-во потоков  агента  (20)
• SERVERTHREADS – определяет общее кол-во потоков  сервера (50)
• LOCKTIMEOUT – время блокировки при операции Lock (обычно возникает в SS клиенте) (600)
• MULTIPLEBITMAPMEMCHECK   принудительно переключает  распределение памяти в  кеше калькулятора  в однопоточный режим, если хоть раз было переполнение в многопоточном  (TRUE)
• PARCALCMULTIPLEBITMAPMEMOPT  оптимизирует работу памяти в кеше калькулятора (TRUE)
• CALCCACHE – управляет кешем калькулятора. Для операций CalcDim  и  AGG в скрипте имеет смысл пробовать  SET  CALCCACHE OFF;

CALCCACHE TRUE

CALCCACHEHIGH    200000000

CALCCACHEDEFAULT 75000000

CALCCACHELOW     2000000

• CALCLOCKBLOCK% – сколько фиксировать блоков в памяти при расчете

CALCLOCKBLOCKHIGH 4000

CALCLOCKBLOCKDEFAULT 2000

CALCLOCKBLOCKLOW 1000

• CALCOPTFRMLBOTTOM – переключает сервер в блочный режим расчета (UP)

Как располагать направления в БД

Для плотных направлений следующие рекомендации

1. Если тип сжатия БД Bitmap, то направления в блоке располагаются от наиболее большого к наиболее меньшему (по кол-ву хранимых элементов)
2. Если тип сжатия БД RLE, то направления в блоке  может быть только два  и первым располагаются периоды.

Для разряженных направлений

1. Для параллельных расчетов требуется располагать последним то направление, которое имеет максимальное кол-во элементов и активно используется в формах ввода (является основной целью учета  – предприятие, продукты и т.д. ) Это  сказывается на использовании кеша калькулятора

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

9)* Как выбирать тип хранения элементов в направлениях.

1. Для плотных направлениях есть след. правило –  на всех  “родителях” ставится тип хранения – «динамический расчет». Но  если в модели активно используются формулы на плотных элементах и они содержат в себе адресацию между направлениями (оператор “->”) то при возникновении «глюков» переходят к хранимым элементам в Account и динамическими род. в периодах.

• Если, для повышения быстродействия, планируется отключить функциональность расчета формул на плотных элементах (параметр AGGRESSIVEBLKOPTIMIZATION TRUE в файле Essbase.cfg) , то  тогда доп. показатели можно рассчитать с помощью «shared» иерархий и расчета на otl

1. Для разряженных направлений есть след. рекомендации

• Головы направлений Года, Версии, Сценарии – «label only»
• Направления, в которых мало элементов – первые кандидаты на то что бы быть разбавлены динамически рассчитываемыми элементами.
• Динамический элемент на разряженном направлении – это способ уменьшения размера БД на жестком диске, но злоупотребления данным подходом  понижает скорость расчета.
• Так же является большой ошибкой «хранить голову» при «динамических детках»

10) * Особенности в проектировании иерархий

1. Для ввода данных на «верхний» уровень нужно использовать вспомогательные элементы, так как возможна ситуация «потери» данных при агрегировании
2. Не допускается использование больших плоских иерархий ( когда один родитель содержит сотни детей), нужно искусственно вводить промежуточные уровни агрегаций
3. Ввод константы в формулу элемента на разряженном направлении породит все возможное кол-во блоков.
4. Правильное расположение разряженных направлений напрямую влияет на использование кэша калькулятора, на параллельные расчеты, на дефрагментацию БД.

11) * Управление транзакциями

Практическое применение имеет только один режим работы – Uncommited Access, так как Commited Access создает слишком много блокировок и переводит систему в режим не пригодный для параллельного запуска БП. Но это означает, что одновременно два потока могут обращаться к одному блоку данных для чтения и его изменения.

Для расчета верхнего предела кол-ва блоков, при достижении которого будет происходит синхронизации с  жестким диском можно воспользоваться след. формулой   из расчета того , что 10 (?) Mb является оптимальной величиной для репликации.

• Commit Blocks = 10,000,000 / (Block Size * Compress Ratio)

При такой величине достигается баланс между дефрагментацией файла данных и скоростью расчета.

12)* Управление  фрагментацией файла данных.

Из – за конкурентных расчетов, и неравномерного создании блоков при вводе данных и агрегации файлы данных имеют тенденцию «разряжаться», что напрямую влияет на скорость расчета. Для контроля можно использовать метрику “Average clustering ratio”, она должна стремится к 1, что достигается реструктуризацией  БД.

13) * Настройка распределения памяти.

1. Index Cache, хранит в себе записи о данных, должен стремится к сумме размеров всех индексных файлов + 20% на рост.  Показатель утилизации индекса должен стремится к 1, если он меньше 0,9  – то нужно увеличивать выделяемый размер.
2. DataFile  Cache, хранит в себе распакованные блоки, и лучше отводить под его  размер всю доступную память.   Для это можно использовать мультипликатор – memscalingfactor в файле essbase.cfg
3. На утилизацию памяти влияет параметр commited block, но его завышение приводит к росту скорости дефрагментации файла данных.

14)* Влияние роста размер БД на скорость расчетов

Измеряя данный показатель, можно сказать об удачном или неудачном проектировании модели, т.е. если производительность расчетов упала менее чем на 20% при росте БД в два раза, то данная многомерная модель сбалансирована и в ней удачно выбраны плотные направления и порядок разряженных. Если расчет упал в разы – то это первый признак того что модель нуждается в пересмотре.

Для анализа обоснованности выбора того или иного направления в блок, рекомендуется след. подход

a)      – выгрузить все данные нулевого уровня в реляционную табличку

b)      – запросами вида

select “Account” ,”Scenario”,”Version”, count (*) from XX_RP_CHECK0  group by “Account”, “Scenario”, “Version”

получаем статистику по частоте использования данных элементов, по плотности заполнения и пр.

c)       – На основании данной статистики делаются выводы

1. о верности принятия решения по включению в блок того или иного направления
2. о порядке разряженных направлений
3. о возможности и способе разделения данного приложения

Максимальный допустимый размер БД,  20Gb – если база получается больше – начинайте думать об оптимизации.

15) Использование «Интеллектуального расчета»

Предназначен  для перерасчета только изменений в модели.  Вносит «неожиданности» в расчеты, так как считает,  что требуется пересчитать только те блоки и иерархии, в которых был пользовательский ввод.   Но можно «грязнить»  требуемые расчетные блоки с помощью CDF.

16) * Использование партиций

Требует аккуратного отношения и сопровождения. Это не то решение, про которое можно забыть, однажды сделав.  Конкурирует с расчетами за доступ к данным,  за доступ к агенту Essbase,  зависимо от изменений в метаданных, скорость  развертывания прямо пропорционально размеру  файлов данных.  Практическое применение  имеет  transparent партиции, так как создает аналог view, т.е обращаясь к срезу в первом кубе видим и изменяем данные во втором.

Transparent партиция в target может использовать элементы с признаком динамического расчета – так как переписывает обращения к данному срезу, тем что определено в партиции. Т.е. если в аккаунтах есть статьи, которые используется только для представления данных из другого куба, то можно сократить размер блока данных, сделав данные элементы динамическими ( например  с формулой = #Missing; )

Если данные из партиции нужны только в расчетах,  то имеет смысл строить их на отдельных (динамических) сценариях (версиях). Это может повысить скорость разворачивания.

Для контроля работы  партиций можно использовать параметр   файла essbase.cfg  ENABLE_DIAG_TRANSPARENT_PARTITION

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

Если какие-то направления передаются 1 в 1 то лучше их опустить в описании мапинга партиции.

17) Использование XREF

Хорошо подходит для точечных выборок небольших массивов данных, иначе лучше использовать transparent партиции.

Для повышения производительности можно использовать reference кубы

18)* Мультивалютность

Стандартный функционал выкидываем на помойку.

1)      Если предприятия бюджетируются только в своей валюте, и отчетность так же  репортится в одной валюте, то цепляем на это Entity код валюты через UDA или атрибут. Курсы храним, совместно с другими направлениями. Переписываем стандартную агрегацию с учетом курсов.

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

19) Загрузка данных

LoadRules  – просто удобно функционально. Хорош для загрузки данных, метаданные обновлять не удобно – для этого лучше использовать другие инструменты (EPMA,STUDIO,EIS)

EIS – поддерживается, но не развивается. Ограничения: нельзя строить Drill Trough отчеты на parent-child иерархиях .

Studio (2010г) – слишком молодой, что бы использовать в продакшн.

20) Как бороться с агрегацией #Missing блоков, и нулевых значений.

Для этого нужно использовать Custom агрегацию с помощью MemberFormula  (использование )

@SUM (@CHILDREN (@CURRMBR(“Market”)))*@SUM (@CHILDREN (@CURRMBR(“Market”)))/@SUM (@CHILDREN (@CURRMBR(“Market”)));

21) Известные ошибки и способы устранения

Exclude – не работает, нужно использовать Remove

Если в расчете используются арифметические операции над разряженными направлениями , нужно контролировать множество пустых блоков.

22)

23) Правила написания скриптов расчета

a)

b)      Могу добавить след.

c)

1. Используйте FIX,  везде, где это возможно,  –  IF медленнее.
2. CDF только там где стандартными способами ничего  не решить
3. Для того что бы избежать тиражирования  определенного расчета по всем бизнес правилам (например чтобы при изменении алгоритма агрегации данный кусок кода править только в одном месте), нужно использовать «графические БП» с включением в них скриптов.
4. Если случай сложный, то можно писать бизнес-правила на JAVA с использованием Essbase Java API