Before hybrid mode capabilities were available, multiple cube solutions that blended the power of block storage (BSO) and aggregate storage (ASO) cubes were often used to provide the most efficient Essbase solution. These solutions allowed developers to utilize the robust calculation capabilities of BSO along with the rapid aggregation capabilities of ASO. With the availability of hybrid storage mode, these multiple cube solutions can now be simplified into a single hybrid cube. In this webinar, Dennis Hogan will present: A case study to: Determine the impact of using hybrid storage and how it addressed key concerns of a 2 cube solution Determine how the hybrid approach will optimize performance The process of converting one multi-cube solution into a single hybrid cube The good, the bad, and the ugly of the hybrid cube conversion process The feasibility of a hybrid cube solution - Is it for you? Presenter: Dennis Hogan Date: 05/19/2017

1. Hybrid to the Rescue
Case study: Converting a Multi-cube
Solution to a Single Hybrid Cube
May 19, 2017
Dennis Hogan

2. • Founded in 2002
• 80+ employees in 20+ states
• Mostly CPAs, MBAs
• 50+ Planning / Essbase Clients
• 80+ HFM Clients
• Managed largest roll-out of HFM in North America
• Market Leader in ARM/FCM
• World Leader in FDM implementations and custom
solutions
• #1 Implementer of OneStream
Finit Overview

3. The Finit Family
Fully aligned with
our clients, not just
bottom line $
No debt or external
ownership
Work with Finit
employees, no
subcontractors
Compensation
based on CLIENT
SATISFACTION
PRIVATELY
OWNED
CLIENT
SATISFACTION
NO
SUBCONTRACTORS
DEBT FREE

4. Finit Customer Success
Our values, culture, and approach to
becoming a trusted advisor to our
customers has led to
100% customer success
for every Finit client (275+) and for
every Oracle Hyperion project (800+)

5. Some Finit Customers

6. Questions

7. About the Presenter
Dennis Hogan
(dhogan@finit.com)
Experience
• Lead Architect within Planning and Essbase Practice
• Over 20 years working in the EPM space with the majority of
that time focused on Essbase and Planning solutions
• 50/50 mix of experience in Consulting and “Corporate/Industry”
• Former Board member for the Ohio Valley Oracle Applications
User Group (OVOAUG)

8. Agenda
• Storage Options Review
• BSO
• ASO
• Hybrid
• Case Study
• Background on existing solution
• Conversion efforts
• Results/Lessons learned
• Questions and Answers

9. Data Storage Review
BSO
• Data is stored in blocks
• Dense/Sparse settings control the contents and number
of blocks created
• PAG / IND files
• Robust library of calculation functions and scripting
language
• Number of dimensions supported is limited (8-10)

10. Data Storage Review
ASO
• No blocks
• Aggregations are performed in memory unless
optional materialized aggregations are added
• MDX for formulas and queries
• Supports large dimension sizes and large numbers of
dimensions
• DAT files

11. Data Storage Review
Hybrid
• BSO at level 0
• PAG and IND files
• ASO for upper level sparse when tagged dynamic
• No materialized aggregations can be stored in these
sparse/dynamic dimensions
• Still able to have a traditional sparse dimension that
aggregates using BSO where applicable
• ASO DAT file and directories exist only while application
is running

12. CASE STUDY

13. Case Study
Existing Solution in 11.1.2.3
• Multiple-cube solution - BSO calculator cube & ASO aggregator
• Project was nearly completed before Hybrid was available
• Now patched up to 11.1.2.3.700 so Hybrid can be considered
Case Study Objective
• Determine the impact of using a Hybrid Storage to address key
concerns with the 2 cube solution and optimize performance

14. Multi-cube Design
GL1
GL2
HFM
FDM
BSO
Cube
Templates
ASO
Cube

15. Existing Solution - Primary Concerns
• Downtime for Constant Rate and Nightly Processes
• Users are unable to modify data during this processing
• Application is worldwide – difficult to find a convenient time
• Lag in updating constant rate data (once daily)
• Sporadic issues with communication interruptions when
transferring between cubes
• Lengthy recalculation process after metadata
deployments

16. Existing Solution
• 11 Dimensions
• 2 Cubes

17. Existing Solution
• Data Loads from GL and Templates into HFM and
Essbase using FDM (dual load)
• BSO cube performs calculations
• Results in BSO are transferred to ASO for aggregation
and user consumption
• User driven processes kick off the load, calculation,
and transfer for just the entities relevant to each
FDM Location

18. Scheduled / Batch Processes
• Scheduled/Maintenance Tasks
• Constant Rate Calculations
• Full Calc after deployments
• Many of the key concern items are tied to these processes

19. Constant Rate
• Constant Rate Dimension
• ScenRate
• Data as Entered/Loaded
• CR Calc copies ScenRate Data into other members to populate
them with the latest data
• Additional member values are calculated using the corresponding
rate environment to present data in a rate neutral fashion –
remove variances caused by rate fluctuations

20. Constant Rate
• This process takes approximately 30 minutes to run in the
multi-cube solution
• Live solution takes even longer
• Other changes as part of the case study reduced this from 90+
minutes to 30 minutes

21. Post-deploy Recalc
• Metadata changes are made and deployed
• Calculations must be executed to update the
contents of the cube to reflect changes
• Includes FX, Acquisition and Constant Rate processes – UDAs may
have changed
• Metadata changes are often needed during critical
month-end / forecasting periods.
• Downtime to run this process will exceed 30 minutes
• Deploy / restructure / Recalc

22. User Launched Processes
• FDM loads data and passes runtime prompt settings to
calculation processes dictating the dimensional members
to process
• Calculations executed
• Tax Calculations
• YTD to Periodic
• Calculate Foreign Exchange
• Calculate Acquisition
• Export to file & Load to ASO

23. Multi-pass Tax Calculation
Calc Taxes
Type 1
Calc DimsCalc Dims
Calc Taxes
Type2
Calc Taxes
Type 3
Calc DimsCalc Dims
Calc Taxes
Type 4
Send to ASO
• Tax Calculation
• Multi-level calculation
• Upper level values from sparse dimensions
are needed for each pass
• Logic includes cross dimensional operators

24. Converting YTD to Periodic
• Values coming in are YTD as needed for HFM
• Load into ActualLoad scenario
• Calculation compares YTD balances by month to derived
periodic value for each month
• UDAs used to indicate TBLast accounts
• Results are stored in Actual scenario

25. FX Calculations
• Calculates results in various currencies to update
ScenRate contents
• Current design only calculates the ScenRate (data as
loaded) with user launched processes
• Other rate environments are calculated in batch (Constant Rate)
• NY Budget Rate, PY Actual Rate etc.

26. Acquisition Calculations
• Determines which Entities are considered Acquisitions for
each period and sets flag value in accounts appropriately
• Populates the AcqScenRate and OperScen rate members
of the constant rate dimension with the appropriate
values based upon flag values
• ScenRate - all data as loaded
• AcqScenRate – portion of ScenRate data that is tied to acquired
companies for each period
• OperScenRate – remainder of ScenRate (Organic performance
analysis)

27. Data Transfer to ASO Cube
• Export for Transfer to ASO
• Maxl script that extracts level 0 data to text files (parallel export)
• FIX isolates on appropriate dimension
• Runtime variables set by FDM based upon location used to load
• Only the active scenario member (ScenRate) data is included in
exports with user launched load / calc processes
• Load to ASO
• Clears the appropriate region in the ASO cube
• Based upon Runtime variables passed by FDM
• Loads the text file(s) from BSO cube
• No stored aggregations are needed

28. Hybrid Time!

29. Hybrid Design
GL1
GL2
HFM
FDM
Hybrid
Cube
Templates

30. Creating the Hybrid Model
• Made a copy of the BSO application
• Changed Essbase.cfg to include the hybrid mode for the
new cube ( ASODYNAMICAGGINBSO HSRPTG FULL )
• Restarted the Essbase Service
• Using Next Generation Outline Extractor, extracted
dimension build files for sparse dimensions
• Changed storage properties in each file to set upper level
members in sparse dimensions to dynamic

31. Creating the Hybrid Model
• Updated the dimension using the text files and dim build
load rules
• Saved the new cube structure
• Removed the member formulas in the account dimension
• Cross Dims are not supported
• Limited function support
• Replaced the removed formulas with logic in calculation
scripts
• Reduced risk of unsupported function kicking a cube out of hybrid
mode upon retrieval

32. How do I know it worked?
• Execute calculation scripts or retrievals
• Review the application log
GOOD News
BAD News

33. Tuning and Optimization
Finding the Right Mix of BSO and ASO

34. Designs Tested
Design #1 Hybrid – No Aggregations
• All upper level sparse members are set to dynamic
• Calculations using upper levels will rely upon the system pulling in
these values to generate calculated values
Design #2 Hybrid – 1 Aggregated Sparse Dimension
• Modified PLBSMvmnt dimension storage property to stored for
the Income Statement rollup used in Tax Calculations
• Add Agg of this dimension to the calculation processes including
Tax calculations

35. Designs Tested
Design #3 – 2 Aggregated Sparse Dimensions
• Changed Account dimension storage properties for the Income
Statement section to stored
• Added aggregation of this structure to the calculation processes
• Calculation does an Agg of both Accounts and PLBSMvmnt

36. Processing Time Comparison
Constant Rate Calc

37. Interim Findings
• Hybrid with No aggregations looks like the best approach
for this batch processing
• Hybrid with 1 aggregation also produces significant time
savings
• Hybrid with 2 aggregations takes longer than the existing
two cube solution, so it is not looking promising

38. Processing Time Comparison
* No Agg Method = 0 (not needed) *
Aggregate All

39. Interim Findings
• Hybrid with No aggregations still looks like the best
approach after factoring in these results
• Hybrid with 1 aggregation looks like the second best
• Hybrid with 2 aggregations and the existing 2 cube
solution result in similar overall processing time (still not
looking promising)

40. Processing Time Comparisons
User-driven calculations

41. Interim Findings
• Hybrid with No aggregations hit a snafu as a key end user
driven process – taxes run time explodes
• Hybrid with 1 aggregation produces quicker overall
results than the existing solution & the no agg solution
• Hybrid with 2 aggregations nearly doubles processing
time compared to 1 aggregation
• Based purely on calculation processing times,
1 Aggregated Dimension looks to be our best choice

42. Retrieval Time Comparisions
• Created several ad-hoc spreadsheets of varying sizes
• Performed retrievals against each design and compared
times

43. Interim Findings
• Hybrid with no aggregations results in some poor
retrieval times
• Hybrid with 2 aggregations does not produce benefits on
the retrieve side that would justify the additional
processing time
• Hybrid with 1 aggregation produces quickest results in
nearly all cases
• 1 Aggregation still seems like the winning design

44. Data Storage Comparison
• Block size reduced in Hybrid– YTD members are dynamic
• ASO/Hybrid piece still needed
• DAT goes away when app is not loaded, Space must still be there to
accommodate it when loaded
• Hybrid No Aggs saves small amount of disk
• Hybrid 1 Agg (our recommended option) basically no change
• Hybrid with 2 aggregations produces a much larger footprint

45. Summary of Time Savings
• Full recalc times Multi vs New Hybrid with 1 Agg

46. Summary of Storage Impact
• Conversion to Hybrid still requires all of the BSO and ASO content
that we had in the 2 cube solution. Thus, no real storage gains
with our end result
• For a pure BSO cube with traditional aggregations of dimensions,
I would expect that you would significantly reduce the footprint

47. Conclusions
• Hybrid mode looks like a viable solution for replacing this
multi-cube solution
• The Best choice for overall performance for this model is
a hybrid cube with some aggregations performed on
sparse dimensions
• Hybrid with no aggregations was not selected due to
• Poor retrieval times & lengthy processing times for user launched
calculations (Taxes)

48. Conclusions
• Aggregation of 1 sparse dimension is a better solution
• Produced fast user/load related calculations
• Full constant rate recalc is faster than the multi-cube solution
(90+%)
• User calc times are faster than existing solution (50%+)
• Improvements may allow constant rate to run upon load (real
time)

49. Primary Concerns Revisited
• Downtime for Constant Rate and Nightly Processes
• Downtime for CR can be reduced substantially or eliminated completely
using the Hybrid solution (1 dimension aggregated)
• Lag in updating constant rate data (once daily)
• Constant Rate can be run more often with the Hybrid solution
• Possible inclusion with the user driven processes that run upon load
• Sporadic issues with communication interruptions when
transferring between cubes
• Data transfers are not needed with the Hybrid Solution
• Lengthy recalculation process after metadata deployments
• Agg all is reduced to as little as 6 minutes with Hybrid solution

50. Other Items of Note
• Properties that can be controlled are BSO settings
• Caches, Dense/Sparse etc.
• ASO properties like Compression dimension, Tablespace, and Solve
order are controlled by the system as it creates the ASO contents
• ASO components (Dat file etc.) get created when the cube starts and
remain in place until the cube is stopped.
• Block size still matters!
• Level 0 Blocks still have to be pulled into memory before the ASO
engine can derive the upper level dynamic values

51. Other Items of Note
• Query Governance can be established to prevent runaway queries
when reverting to BSO mode
• Time based control (max # of seconds a query can run)
• QRYGOVEXECTIME [appname [dbname]] n
• Size based control (max # of blocks that can be pulled)
• QRYGOVEXECBLK [appname [dbname]]
• Logs tell you if Hybrid mode is working
• When running processes, entries in the application log file will
indicate when Hybrid mode is enabled
• Hybrid Aggregation Mode is enabled will appear in the log
• Retrievals / Calculations that use unsupported functions or cross-
dims will result in the processing of upper levels executing with
traditional BSO methods
• Hybrid Aggregation Mode is disabled will appear in the log

52. What about Planning?
• The process for using Hybrid is similar
• Transfers between plan types will NOT be able to use XREF or
XWRITE to transfer data.
• Those functions are not supported in hybrid mode
• Replace with Maxl launched in business rule to export / import OR
Map to reporting / SmartPush
• Some sparse rollups may need to be stored to allow summarized
data to transfer via export/import
• May need to maintain different storage settings by plan type
• Cube using Hybrid will need upper level dynamics
(example: reporting)
• Cubes not using Hybrid would have stored setting for the same
parents (example: allocations/calculations)