Best Practices in HFM Application Design

Chris Barbieri
Consolidation Practice Director Oracle ACE Ranzal & Associates

Personal Background
Chris Barbieri
Established HFM performance tuning techniques and statistics widely used today 4+ years as Sr. Product Issues Manager at Hyperion
HFM, Smart View, Shared Services, MDM

Member of HFM launch team in 2001, certified in HFM and Enterprise MBA, Babson College B.S. Finance & Accounting, Boston College Co-founded the HFM Performance Tuning Lab at Ranzal with infrastructure expert Kurt Schletter

Application Design: the Foundation of Performance

Hyperion Financial Management Metadata design as it impacts performance
Volume of members Impact of structures

Data
Content Density

Metadata

Designing HFMs 12 Dimensions

Application Profile
1. Year 2. Period 3. View

User controlled
Entity 6. Account 7. ICP 8. Scenario
5.

System
4. Value dimension, includes currencies

User defined
Custom 1 10. Custom 2 11. Custom 3 12. Custom 4
9.

Application Profile
Year
No inherent impact on performance Cannot be changed after the application is built Impacts the number of tables that can be created in the database

Period
The base periods comprise the column structure of every table, whether you use them or not. For this reason, avoid weekly or yearly profiles unless it is key to your entire applications design

View
No impact, but only YTD is stored and Periodic, QTD are on-the-fly derivations

System Dimension
Value Dimension
Can not directly modify this <Entity Currency> is a simple variable directing you to the current entitys default currency <Parent Currency> points back to the currency of the entitys parent

Currencies
Dont add currencies you arent using
Sets of calc status records for (every entity * every currency) Impact of loading metadata with entity or currency changes

Normally translate from the entitys currency only into its parents currency. Beware of non-default translations
Impacted calc status Data explosion

User Controlled Dimensions

Entity
Sum of the data of the children Avoid Consolidate All or All With Data on each hierarchy Assign Adj flags sparingly

ICP
Hidden dimension

Scenario
Number of tables

Impact of Account Depth

4- Net Income 3- Optg Income 2- Gross Margin 1- Sales

6- Net Income 5- EBIT 4- Optg Income 3- Gross Profit 2- Gross Margin

Effect is multiplied when you consider the custom dimensions Parent accounts dont lock

1- Sales

User Defined Dimensions

Custom 1..4
Think dozens or hundreds, but not thousands Avoid:
Employees Products Anything that is very dynamic One to one relationship with the entities

Metadata Efficiency Ratio

What does the average entity have in common with the top entity?
Density measurement of re-use of the accounts and customs across all entities
top entity children unique custom 1

Metadata Volumes (Americas)

Dimension
Accounts Entities Currencies Custom1 Custom2 Custom3 Custom4 Scenarios Entity hierarchies ICP Accounts with Plug Accounts with Line Item Detail Consolidation Rules Consolidation methods OrgByPeriod ICP Members Entities flagged for Parent Adjs Scenarios using Process Mgmt 86 143 5 1,407 7,698 53

Average Volume
2,132 1,165 16 388 153 61 39 11 3 41 36 5

Recorded High
14,409 22,882 233 19,410 15,188 26,816 11,389 78 24 1,223 1,667 10
use only

Comments

1 currency 30%

use Custom 1 96% use Custom 2 86% use Custom 3 86% use Custom 4 62%

the equivalent of Organizations in Hyperion Enterprise use automated intercompany matching 56%

16% use this, but only 10% have more than 1 account flagged
use consolidation rules 28% use methods 14% use organization by period 9% track intercompany activity 81% Allow [Parent Adj] or [Contribution Adj] journals30% use process management46%

Data

Whats a Subcube?
HFM data structure Database tables stored by
Each record contains all periods for the [Year] All records for a subcube are loaded into memory together

Parent subcube, stored in DCN tables Currency subcubes, stored in DCE tables

Take it to the Limit

Reports, Grids, or Forms that:
Pull lots of entities Lots of years Lots of scenarios

Not so problematic:
Lots of accounts Or Custom dimension members

Smart View
Cell volume impacts bandwidth Subcubes impact server performance

HFM Urban Legends

100,000 records per subcube Increase MaxNumDataRecordsInRAM = better performance 500 children to a parent System 9 allows an unlimited sub cube size Customs should be ordered largest to smallest Limit to the Account dimension depth 64 bit is faster (this requires some explanation)

Data Design

Metadata volume is interesting, but its how you

Density Content
Specifically: zeros Tiny numbers Invalid Records

it that matters most

Data Volume Measurement

No perfect method
Method Data Extract How-To Extract all data, count per entity Parse HFM event logs Pros Cons Simple, easy to see input Can only extract from calculated <Entity Currency> Good sense of average cube, easy to monitor monthly growth Cant identify individual cubes, harder to understand

FreeLRU

Database Analysis

Query DCE, DCN tables and count

Easy for a DBA, see all subcubes

Doesnt count dynamic members, includes invalid records

Data Density Using FreeLRU

Survey of data density using FreeLRU method
Number of applications reviewed: 32 Average Min Max Median ABC Customer 577 1,107,614 31,446 2,288 7.3%

NumCubesInRAM NumDataRecordsInRAM NumRecordsInLargestCube Average records per cube Average metadata efficiency: average cube/densest cube

2,672 1,502,788 86,415 6,309 7.3%

72

10,206

1,345

247,900 5,627,748 1,170,908 2,508 24 0.3% 593,924 91,418 39.7% 53,089 1,352 3.4%

Loaded Data
What percent of the loaded data is a zero value?
No hard rule, but <5% may be reasonable No zeros are best, watch ZeroView settings on the scenarios

Watch out for tiny values, resulting from allocations How much does the data expand from Sub Calculate?
Am I generating zeros, or tiny numbers?
Input Base Records Total Input zeros % zero loaded Values > -1 and < 1 % values > -1 and < 1 Input Plus Calculated Base Records 2,031,976 Total 18,024 Calculated zeros 0.9% % zeros calculated at base 373,226 Values > -1 and < 1 calculated 18.4% % values > -1 and < 1 calculated 4,387,520 413,837 9.4% 593,981 13.5% % Increase From Rules

116 % 2,196 % 59 %

Effect of Sparsity on Record Volume

Most dense data is at the top entity
Greatest number of populated intersections (account _ custom 1..4 combinations)

Consolidated Data
Total volume of data in any subcube How many zeros are generated by the consolidation process?
Intercompany eliminations Allocations Empty variables
Calculated 9.4%
Loaded 0.9%

Consolidated Base Records Total Consolidated zeros % zeros Values > -1 and < 1 % values > -1 and < 1 991,587 194,204 19.6% 84,251 8.5%

Consolidated 19.6%

Data Density <> Calc Time

Average Rule Execution Time in Contrast with Data Volume
900 800 700 600 1.500 500 400 1.000 300 200 100 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 0.500 Seconds Records 2.000 2.500

correlation between density and calc times Most applications are rules bound

Invalid Records
Type 1: Orphaned records from metadata that has
been deleted
Member is removed from dimension_Item table, but not from the data tables These can be removed by Database > Delete Invalid Records

Type 2: the member still exists, but is no longer in a

valid intersection
Most often from changing CustomX Top Member on an account These cannot be removed by HFM, but are filtered out in memory

Chris Barbieri
cbarbieri@ranzal.com Needham, MA USA +1.617.480.6173 www.ranzal.com