Hyperion Essbase & Planning Drill-Through

Hyperion Essbase & Planning Drill-Through

Drill-Through from an Essbase cube or a Planning application is a fairly common requirement. There are a couple of ways to do it: EIS, Essbase Studio, FDM, etc. The main drawback of most (probably all) of these tools is that the cube/application needs to be built from the ground up using one of these tools. There are a couple more drawbacks in some of the tools like upper level drill-through, retrieval speed and format of the returned data so there is some kind of compromise that has to be made. Business users do not necessarily see eye to eye with the consultants or hyp-admins when it comes to compromises.
Drill-through can also be done in reporting products like Web Analysis and OBIEE however the link between users and Excel cannot be broken easily.

Continue reading “Hyperion Essbase & Planning Drill-Through”

MDX NONEMPTYBLOCK and transparent partition in Hyperion Planning forms

Несколько предложений о особенностях MDX NONEMPTYBLOCK в Hyperion Planning

С некоторых пор Hyperion Planning использует для получения данных в формах MDX запросы.
Для больших (sparce) форм единственным способом оптимизации является использование опции “Suppress missing blocks”, которая выводит только значащие строки.
Для получения этих данных используется не задокументированная опция “NONEMPTYBLOCK”, которая говорит BSO кубу , о том что нужно получать только сохраненные данные.
При использовании transparent партиции BSO куб запрещает использовать опцию NONEMPTYBLOCK и все “широкие” формы становятся инвалидными.

[Thu Jan 31 19:33:11 2013]Local/Appplication/Database/EssAdmin@Native Directory/1126824256/Info(1013091)
Received Command [MdxReport] from user [EssAdmin@Native Directory]

[Thu Jan 31 19:33:11 2013]Local/Appplication/Database/EssAdmin@Native Directory/1126824256/Error(1200647)
NONEMPTYBLOCK keyword not supported for databases with transparent partitions.

[Thu Jan 31 19:33:11 2013]Local/Appplication/Database/EssAdmin@Native Directory/1126824256/Warning(1080014)
Transaction [ 0x20001( 0x510a9cc7.0x304cb ) ] aborted due to status [1200647].

p.s. Более подробно о NONEMPTYBLOCK, читайте здесь.

Replicated Partitions

Replicated partition – это копия части данных (среза) источника (source), которые хранятся и в получателе (target). Получается, что пользователи могут получить независимый доступ к данным как и из источника, так и из получателя.

Например:

В приложениях Sampart и Sampeast, поставляемых вместе с Essbase, администратором базы данных TBC создан реплицированный раздел между базой данных East и главной базой данных компании (Company), содержащей такие элементы, как Actual, Budget, Variance и Variance%. Благодаря этому пользователи восточного региона хранят свои плановые данные у себя на месте. Так как им не нужно запрашивать эту информацию непосредственно из главного подразделения, время ожидания ответа для них сокращается, и они получают больше возможностей планировать свое время и управлять локальными данными.

Изменения данных, сделанные в реплицированном разделе, переносятся из источника в получатель. Изменения, сделанные в получателе данных, не переносятся обратно в источник. Если такие изменения делаются, они перезаписываются при обновлении реплицированного раздела администратором. Администратор может заблокировать обновление данных в реплицированном участке получателя. Подобный параметр является предпочтительным по сравнению доступом через фильтры защиты. Он также рекомендуется при пакетных операциях, например загрузке или расчете данных. По умолчанию реплицированные разделы не подлежат обновлению. (Опция «The target database can be updated»)

Правила разработки:

Маппинг различных направлений: Реплицированные области, разделяемые схемами источника и получателя данных, не обязательно должны быть абсолютно одинаковыми. Главное требование – возможность обозначить их соответствие друг другу. Это значит, что необходимо указать, каким аналитическим направлениям и элементам источника соответствуют аналитические направлениях и элементы получателя.В случае отсутствия направления указывается (void)

Запрещены перекрестные ссылки: Не допускается создание реплицированное раздела поверх прозрачного. Иными словами, ни одна из областей, используемых в качестве источника реплицированного раздела, не может быть взята из прозрачного раздела (transparent partition) получателя.

Запрещено наложение: Ячейки получателя реплицированного раздела не могут быть взяты из двух разных источников; ячейки одного раздела должны браться только из одной базы данных. Если вам нужно реплицировать ячейки из нескольких баз данных, создайте отдельный раздел для каждого источника.

Множественный source:Ячейки получателя могут быть источником для разных реплицированных разделов. Так, если база данных Sampart содержит реплицированный раздел, взятый из базы данных Sampeast, ячейки базы данных Sampeast можно продублировать в любую другую базу данных, например Sampwest.

 

Преимущества :

Реплицированные разделы позволяют уменьшить нагрузку на сеть, так как данные будут храниться ближе к конечным пользователям – в получателе данных. Уменьшение нагрузки на сеть приводит к сокращению времени извлечения данных для пользователей.

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

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

Администраторы локальных баз данных могут распределять рабочее время на местах. Например, если пользователи восточного региона обращаются к собственным реплицированным данным, а не к общей базе данных, администратор может перевести базу данных на менее интенсивный режим эксплуатации без ущерба для пользователей восточного региона.

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

 

Недостатки :

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

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

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

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

Отказ от репликации выводимых данных источника может значительно сократить общее время репликации.

Иногда выводимые данные нельзя рассчитывать в получателе. В этом случае их нужно будет реплицировать из источника. Нельзя, например, рассчитывать данные, взятые непосредственно из
источника, если это:
требует расчета других данных за пределами реплицируемой области;
требует шаблонов вычислений, из которых нельзя взять только ту часть, что нужна для выполнения расчета в получателе;
предполагает репликацию в компьютер с невысокой рабочей мощностью, например лэптоп.

Выполнение разделения плотного аналитического направления занимает больше времени, чем для разреженного.

Когда реплицируются данные плотного направления, система обращается к каждому блоку источника, а затем в процессе репликации воспроизводит каждый блок в получателе. Например, если бы аналитическое направление Market было плотным, а данные реплицировались в элемент East, то системе пришлось бы обращаться к каждому блоку базы данных, а затем в ходе репликации
воспроизводить каждый блок в получателе.

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

 

 

Transparent partition

Transparent partition

 

Позволяют пользователям манипулировать данными, хранящимися в отдаленных местах, как если бы они были частью локальной базы данных. В этом смысле они очень похожи на механизм VIEW в реалиционных БД. Удаленные данные берутся из источника всякий раз, когда пользователь, находящиеся в получателе, делает соответствующий запрос. Пользователям не требуется знать, где хранится информация, так как они видят ее как часть своей локальной базы данных.

 

 

Так как данные берутся прямо из источника, пользователь получает их последнюю версию. При обновлении данных пользователем, сделанные изменения переносятся обратно в источник. Это означает, что как у пользователей, находящихся у источника, так и у тех, кто находится у получателя данных, имеется непосредственный доступ к этим изменениям.

 

Прозрачные области, разделяемые схемами источника и получателя, не обязательно должны быть абсолютно одинаковыми. Главное требование – установить их соответствие друг другу. Это значит,что необходимо указать, каким образом каждое аналитическое направление и элемент источника будут отображены в соответствующих аналитических направлениях и элементах получателя.

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

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

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

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

 

Преимущества :

Требуется меньше пространства на диске, так как информация хранится в одной базе данных.

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

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

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

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

Данные можно загружать и из источника, и из получателя.

 

Недостатки :

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

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

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

Некоторые административные операции можно выполнять только на локальных данных. Например, если архивируется получатель, то при этом не архивируется источник данных. Следующие административные операции выполняются только на локальных данных:

•    CLEARDATA;

•    DATACOPY;

•    EXPORT;

•    VALIDATE;

•    BEGINARCHIVE и ENDARCHIVE;

•    прочие операции по преобразованию в Диспетчере приложения;

 

Настройки производительности для Transparent Partitions

 

  • Разделение плотных аналитических направлений в прозрачном разделе может значительно замедлить скорость работы. Причина в том, что плотные аналитические направления используются для определения структуры и содержания блоков данных. Если база данных разделена только по плотному аналитическому направлению у получателя, системе потребуется составление блоков данных путем выполнения сетевых запросов удаленных данных в прозрачном разделе, помимо ввода-вывода данных для локальной части блока.
  • Загрузка данных в источник из получателя значительно снижает скорость работы. Данные по возможности следует загружать в источник локально.
  • Время извлечения информации замедляется, так как пользователи запрашивают данные через сеть
  • Для контроля работы можно использовать параметр ENABLE_DIAG_TRANSPARENT_PARTITION в файле essbase.cfg

 

Использование в расчетах Transparent Partitions

Когда выполняется расчет на transparent partition, Essbase выполняет расчет с использованием существующих значений локальных данных и зависимых от партиции. Когда расчет доходит до данных из партиции, то он работает в режиме bottom-up, если выполняется условие по оптимальному использованию кеша калькулятора. Увеличение его размера значительно повышает производительность расчетов, за счет уменьшения итераций по выборке данных из источника – это можно наблюдать, просматривая лог расчета, в сообщениях об использовании кеша калькулятора в целевой БД. Так же расчет сильно зависит от top-down формул на элементах.

Если вы абсолютно уверены в том, что ваш расчет не зависит от данных, лежащих на удаленной БД , можете смело использовать команду SET REMOTECALC OFF