Hyperion Financial Management Application Design for Performance

Hyperion Financial Management
Application Design for Performance
March 20, 2012

Chris Barbieri
Practice Director

Personal Background
► 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
► 2001 HFM launch team 2001
► Certified HFM, Hyperion Enterprise
► B.S. Finance & Accounting, Boston College
► MBA, Babson College
► Established HFM Performance Tuning Lab at Ranzal
►

Copyright © 2012 Edgewater Ranzal

Foundation of Performance
► Hyperion Financial
Management
► Metadata design as it
impacts performance
– Volume of members
– Impact of structures
► Data
– Content
– Density
► Rules
► Environment


Metadata


Designing HFM’s 12* Dimensions
Application Profile User controlled
1. Year 5. Entity
6. Account
2. Period
7. ICP
3. View 8. Scenario
System User defined
4. Value dimension, 9. Custom 1
includes 10. Custom 2
currencies
11. Custom 3
12. Custom 4
* Through release 11.1.2.1

Application Profile
Year
– No inherent impact on performance
– Can be increased after the application is built
– Impacts database table volume
Period
– Base periods comprise column structure of every table,
whether you use them or not
– Avoid weekly profiles unless it is key to your entire
application’s design
– Yearly is inadvisable
View
– No impact, but only YTD is stored
– Other views are on-the-fly derivations
• Consider the UI click volume

System Dimension
Value Dimension
– Can not directly modify this
– “<Entity Currency>” points to entity’s default currency
– “<Parent Currency>” points to default currency of the entity’s
parent
• Anything above “<Entity Curr Total>” must be Parent.Child format
Currencies
– Don’t add currencies you aren’t using
• Sets of calc status records for (every entity * every currency)
• Impact of loading metadata with entity or currency changes
– Normally translate from the entity’s currency only into it’s
parent’s currency
– Beware of non-default translations
• Impacted calc status
• Data explosion
• Adds to cycle time


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
• Don’t disable if you ever had journals on entity
ICP
– “Hidden” dimension
Scenario
– Number of tables


Impact of Account Depth

4- Net Income 6- Net Income

3- Optg Income 5- EBIT

2- Gross Margin 4- Optg Income

1- Sales 3- Gross Profit

2- Gross Margin

1- Sales
Effect is multiplied when you consider the
custom dimensions
Parent accounts don’t lock


User Defined Dimensions
Custom 1..4
– Think dozens or hundreds, but not thousands
• If Thousands are necessary, 64 bit makes this possible
• Rules remain a major factor in performance
– Avoid:
• Employees
• Products
• Anything that is very dynamic, changing greatly from year
to year
• One to one relationship with the entities
Configurable dimensions in 11.1.2.2???


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

base


Metadata Volumes (Americas)
80 Applications Median +1 Std Deviation High
Accounts 1,383 2,814 7,491
ICP Accounts With Plug 17 291 2,273
Accounts With Data Audit 26 1,356 7,490
Consolidation Rules 45%
OrgBy Period 16%
Phased Submission 19%
Consolidation Methods - 3 16
Currencies 25 57 150
Custom1 177 3,248 23,897
Custom2 67 2,397 20,484
Custom3 46 919 5,681
Custom4 19 184 1,199
Entity Hierarchies 4 12 44
Entities (unique) 672 4,242 21,199
ICP Members 200 1,161 7,770
Scenarios 10 27 81
Scenarios Using Process Management - 6 37
Scenarios Using Data Audit - 11 78

Data


What’s 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


Data Design

“Metadata volume is interesting, but it’s
how you it that matters most”

► Density
► Content
– Specifically: zeros
– Tiny numbers
– Invalid Records


Data Volume Measurement
► No perfect method
Method How-To Pros Cons
Data Extract Extract all data, Simple, easy to see input Can only extract
count per entity from calculated <Entity Currency>

FreeLRU Parse HFM event Good sense of average Can’t identify
logs cube, easy to monitor individual cubes,
monthly growth harder to understand

Database Query DCE, DCN Easy for a DBA, see all Doesn’t count dynamic
Analysis tables and count subcubes members, includes
invalid records


Data Density Using FreeLRU
► Survey of data density using FreeLRU method
Number of applications reviewed: Median Min Max +1 Std Dev
44

NumCubesInRAM 1,369 72 15,152 5,068

NumDataRecordsInRAM 1,170,908 247,900 23,019,754 4,574,074

NumRecordsInLargestCube 53,089 2,508 593,924 169,272

Records per cube 1,352 24 91,418 15,832

Metadata efficiency 3.4% 0.3% 39.7% 12.3%


Loaded vs. Consolidated Data
► What percent of the loaded data is a zero
value?
– <5% is reasonable
– No zeros are best
– Watch ZeroView settings on scenarios
► Watch out for tiny values, from allocations
► How much does the data expand from Sub
Calculate?
► How many zeros are generated by the
consolidation process? Consolidated 19.6%
– Intercompany eliminations
Calculated 9.4%
– Allocations
– Empty variables Loaded 0.9%


Growth Up the Entity Chain
Level Number Records
Top Entity 1 261,593
Average Subcube 814 5,193

Base entities including calculated data 516 680
Base entities input data only 443 421

Top 261,593

Average 5,193

Base 421


Loaded, Calculated, and Consolidated
Data
► Rough stats: median from 10 applications
Monthly Rules
Monthly Zeros % Growth Growth
Loaded Records 153,826 4.1% 3.3%
Loaded + Calculated
Records 353,122 19.7% 2.7% 2.0

Consolidated Records 63,432 6.9% 3.2%
Total data for all base (or top) entities
Can be easily managed by better rule writing!


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


So… How Much Memory Do I Really Need?
Plan A Plan B
Number of entities 814 814
* 2 cubes: entity currency + contribution 1,628 1,628
Non-USD entities 483 483
add another cube for parent currency** 483 483
Entity_value cubes 2,111 2,111

Actual 2011, 2012 2 2
4 Currency scenarios, 3 Estimate, 3 Forecast scenarios 3 10
Total Year_scenarios 5 12
Total cubes 10,555 25,332

Average records per cube 5,193 5,193
Optimal MaxRecordsInRAM setting 54,812,115 131,549,076

bytes per record 120 120
Records * bytes converted to MB =
MaxDataCacheSizeInMB 6,273 15,055

** Many entities are translated into other currencies as well, making this value low.


Rules Timing


Data Density <> Calc Time
Average Rule Execution Time in Contrast with Data Volume
900 2.500

800

700 2.000

600
1.500

Seconds
500
Records

400
1.000
300

200 0.500

100

- -
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

correlation between density and calc times
► Most applications are rules bound


S econds

0
50
100
150
200
250
300
350
400
450
83820.83820_D
FR .FR _N B M
L_R E GION S .U S
U S C A .U S
E ME A .D E
A P .C N
C Z .C Z_N B M
D E _N B M.83704
FR _N B M.83519
TH .83899
U S .U S GO
U S .80808
B R .83545
elapsed

820.83820_1801
totalrecords

OTH A P .82828
820.83820_1851
Time vs. Volume

E ME A .B E
LA .B R
U S .80820
A R .83856
0
But Some Applications are I/O Bound

10,000
20,000
30,000
40,000
50,000
60,000

How Long Should Rules Take?

► Total consolidation time for all entities, 12
periods
► Divide by 12 periods and total number of entities

Seconds Per Entity
0 0.25 2.0 4.0 10.0


Rules Impact Ratio
► Total consolidation time with
rules
► Divided by time with Blank
Rules

► Typically 2- 5 times
► More than that is an
opportunity for improvement


Reference
Application


Small but Constant Application
0:04:19

Full Rules Blank Rules
0:03:36

0:02:53

0:02:10

0:01:26

0:00:43

0:00:00
physical physical virtual virtual virtual virtual virtual virtual
HFM lab Cust E Ranzal dev T-61 laptop Cust A Cust B Cust C Cust D

► Applied across multiple environments

Hyperion Financial Management Application Design for Performance

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


Hyperion Financial Management Application Design for Performance

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Hyperion Financial Management Application Design for Performance (20)

More from Alithya (20)

Recently uploaded (20)

Hyperion Financial Management Application Design for Performance