After building BWA indexes the Fact table is not evenly partitioned and distributed among BWA blades. Some of the Fact table parts are very large compare to others and which causes more issues related high memory on those blades that store more data than others. For example, part7 is huger than other parts.
The F table will be splited according to the demision table, normally the largest one demistion. You could find the split configuration in TREX Admin Tool->Index->Landscape, right click the splitted index to choose Split/Merger Index, you could find the following:
You could check the size of demetaion B is the largest demision on BW side:
The possible reason for this uneven partition is that most of the rollup data (new data) was possible relevant to one single demision table part and this part is relevant to part 7 for the Ftable. So most of the new data come to part 7, then uneven partition happened.
When indexing, BWA will split F table by the D table Keys (partition Spec: HASH D-Table). In the following case, if there are 3 blades, BWA will calculate and try to split F-index evenly. When rolling up (not full reindexing), new data will be added into the index, if most new data's d-key is relevant to one key group in D-index, say it key1 and 2, new data will be added into part 1 cumulatively. When re-indexing, BWA will re-calculate the key group to guarantee the partitions in F-index more even.
RSDDV recreate and refill the indices for the infocube.
Notes relevant to partition and reorg
Note 1313260 - BWA 7.00: Advanced configuration of reorg and initial reorg
Note 1163149 - BIA 7.00: New Reorg Parameters
Note 1051100 - BWA 7.00 & 7.20: Reduce Number Parts per Blade - Performance
Note 1313259 - BWA 7.00: Reorg algorithm "ReorgByCube"
Note 1524320 - BWA: Master data reorganization recreates one physical index