Anaplan model size Issues
We have a DEV model with around 15 Lists. Each Lists have lot of List items.
Also our Data Import load file(Excel file loaded into Anaplan) has too many records(more than 40,000 records) for various combinations.
Also we have requirement that a single output module must contain most of these list as Dimensions. Since most of these lists are required as dimensions in a single output module, the space is exceeding too much.
We also tried combining 2-3 lists(numbered lists) into one and applying it into Output module, yet the size of the model is too much.
Please can you help on the same.
Regards,
Rajasekhar
Answers
-
Hello @Rajasekhar
Having a lot of data in the lists in itself is not a problem, Anaplan can handle large data, however, unnecessarily using these lists as a dimension in a module would be a big problem.
How are you loading the Data Input file? To a Flat module or a module with dimensions? (It should be a flat module)
A business requirement shouldn’t be -as a user I need these specific dimension.
The user should determine the data needed in the output and you -the Anaplan team- should design it in the most effective way. So just because the data is needed to be classified by a certain list, that list should not be automatically added as a dimension.I have often seen modelers adding a list as a dimension while it in fact should be just a property (List formatted line item).
So before we start thinking about more invasive adjustment such as splitting the model for example I advise you to review the dimensions used in each module and determine if it should be used or not.
If that’s the case, then redesigning the modules will significantly reduce the model size.Other low hanging fruits you could use are:
- Review the Summary method of the line items. If you don’t need to view the data aggregate -for example- then change the summary method to NONE
- Review your lists, not every list should have a top level, Again, if you don’t need the list items to be automatically aggregated, then no need for a Top Level
These are general best practices that could help, however, the first item you should consider as I said is the architecture of the model (how lists are used in modules)
If you have a more specific issue, Let me know and we can look at it deeper together.0 -
Your question is a very popular question and I'm really glad you asked it. In addition to @einas.ibrahim excellent suggestions I would also add these two:
- Required reading is @rob_marshall data hub peak performance best practice and @DavidSmith The truth about Sparsity part 1 and 2.
- When you create an export (or output module) you can create it flat, meaning one dimension in Anaplan but contains all the dimensions in your requirement as separate line items. This can save a lot of space.
- Make sure time is a dimension (if used). Do not import it as a separate line item and do not include it in your unique identifier (this is covered in @rob_marshall best practice article.
Let's keep the conversation going. @einas.ibrahim asked some good questions that will help us give you more pointed suggestions.
0 -
Hi @Rajasekhar
You have been already presented with links or summaries to modelling and sizing best practices, and I too advise you to read them.
As a more direct answer to your question: there is no way you can combine 15 dimensions in a single module, not even 10 dimensions.
The answer is simple: 15 dimension (let's suppose that each dimension only has 10 items) is 10^15 = 1,000,000,000,000,000 cells
with an average size per cell of 8 bytes, that turns out to be well above 7 million Gb.
So, leaving aside whether or not 15 dimensions are really needed (which sounds a bit uncommon to me and I would start by thinking what is what you really want to achieve and then re-do the fron-to-back design process to find out the most efficient way to achieve your desired outcome with an Anaplan model - have a look https://community.anaplan.com/t5/Best-Practices/The-Model-Design-Process/ta-p/33544 , https://community.anaplan.com/t5/On-Demand-Courses/Front-to-Back-Model-Design/ta-p/63617 )
Otherwise, I think the only alternative is to concatenate all the combinations in a single numbered list. This means that you will effectively replace the dimensions by attributes in Line Items (Assuming that your model is highly sparse, if your 15-diemnsion module is 100% dense, the space consumption of the module and the "concatenated list" will be the same, as every module intersection will result in an item in the list).
Let us know how things go,
Cheers,
Alex
1 -
@AlejandroGomez
I totally agree with you. The size problem usually stems from the confusion between what should be a dimension and what is simply an attribute that will not change.
"Technical" Use Case:I have a Product SKU list with 100 Product SKUs. Each Product SKU comes in a single color and sold in multiple locations.
I have a total of 20 colors and 30 locations.
What dimensions should I use -in addition to the Product SKU- to calculate the $ Sales for Product SKUs?
Color, Location, or both?
Here is a litmus test to figure out if a "list" should be a dimension or a list formatted line item.
Start with a single item from your main dimension, SKU-ABC
Consider each list you are trying to determine to add as a dimension.- Location
Ask yourself If location changed from New York to London will I get different or meaningful values for SKU-ABC?
In our example, the answer is Yes because you will have sales for that SKU in New York and in London that are not the same.
Location should be a dimension - Color
For the same SKU-ABC, If I change the color from red to green will I get different or meaningful values? The answer is No because SKU-ABC only comes in red, so the sales values will be zero for all the other colors.
Color should not be a dimension but rather a list formatted line item
The pushback I usually get from people I tutor/mentor is .... What if I want to display the sales for all my red Product SKUs?
The answer is .... use a saved view with a filter where color line item = Red
This is the core of the issue and an important step in model architecture that significantly affect the size.
0 - Location
-
Thank you all for all your suggestions. I shall try to change my design as per your suggestions and let you know.
Regards,
Rajasekhar
0