Introduction
Semantically Partitioned Object (SPO), introduced as off SAP BW 7.3 are used to logically spread data amongst several part-providers (all with identical structures) to provide the following benefits or to overcome the following challenges:
- Logical Data De-Coupling (business driver) - Business driven need to keep the data separate based on a pre-agreed criteria. Possibly due to domain specific transformations etc.
- Data Load Performance (technical driver) - by logically splitting the infoproviders to part-providers, data loads can be accelerated due to smaller data-volumes to each table and increase parallel loading.
- Reporting Performance (technical driver) - Data logically split across part-providers using SPO can be faster because the OLAP processor can prune part-providers. In addition to pruning partitions, the OLAP processor can also parallelise the data-read operations from multiple part-providers thereby further accelerating query performance.
- Avoiding the 2 billion limit (technical driver).
Question:
1. Given the performance advantage (of load and reporting) that a HANA DB provides as part of a BW-on-HANA system over a BW-on-anyDB platform, what is the SAP strategic direction for SPO (BW 7.4 and beyond) for BW HANA systems?
2. If SPO is a strategic object (such as the likes of the Composite Provider, aDSO etc), what is the direction of its use, given that the HANA platform itself can/should overcome a number of the challenges that SPO was originally created to overcome? When should it be used for BW HANA 7,4 and beyond? Guidelines?