There are many materials out there on SCN discussing the benefit of having BW running on HANA as database. There is even its own space dedicated to SAP NetWeaver BW Powered by SAP HANA. In this post I’d like to take a look on these benefits from pure BW point of view. My motivation is to have arguments for my clients while considering migration of their BW systems to HANA database. Assumption here is that no other change/optimization is done while migrating from current DB to HANA DB.
I hope I captured those topics discussed below right. However my knowledge of HANA / “BW on HANA” is just theoretical at this time. Therefore I appreciate your comments and/or correction to my findings.
1. New in-memory DB
Once you migrate your BW from the current DB to HANA DB you get basically new in-memory DB and all its features right away. This means that without any reimplementation of your existing data flows you can use power of in-memory HANA engine.
As HANA is in-memory DB any aggregates, indices and other materialized views on data are not needed anymore in BW system in most cases. Means administration and maintenance of whole BW system is easier.
HANA tears down very consuming DB operations like data loading, DSO activation by its in-memory nature. I/O operations are faster as it is in-memory DB. Similarly no rollups on cubes after cube is loaded are needed. Also no Attribute Change Runs (ACR) while master data were changed are not necessary.
2. Data Flows/Transformations
There is no need to migrate your BW 3.x style data flows to 7.x style to run the BW system on HANA DB. Notice that 7.x data flow is mandatory for HANA-optimized InfoProviders only. Regarding existing transformations their certain parts of standard data loading process in BW is accelerated by HANA. Especially in BW 7.4 runs a standard transformation differently than it does in older releases of BW. System pushes down the transformation processing to HANA database. However this is only valid for transformations where no custom ABAP routines are used.
By running BW on HANA you get following InfoProvider types. These are not new types of InfoProvs but they are optimized to be used on HANA.
HANA optimized DSO – notice that even this is new term “HANA optimized DSO” it already became obsolete. Earlier the DSO could have been converted into this type of DSO after migration to HANA. This is not the case anymore. As of NetWeaver BW 7.30 Support Package 10 HANA-optimized activation is supported for all Standard DataStore Objects by default. So no conversion needed to Standard DSOs.
With respect to different Support Pack there are following architectures of DSO:
- As of BW 7.30 SP05-09: Change Log of DSO is provided by HANA’s Calculation view. This means there is no persistency of data. This speeds up data activation and SID creation.
- As of BW 7.30 SP10: There is database table for Change log. By this we gain performance while loading the data from the DSO to further InfoProvs as less resource and memory consumption is achieved.
More information can be found here: DataStore Objects in SAP NetWeaver BW on SAP HANA
HANA optimized infocubes – Within classic BW infocubes there are 2 fact tables (F – normal one and E – compressed one) and several dimension tables as per cube setup. HANA optimized cubes are flat, there is no dimension tables and there is only one F table for facts. This means info cubes running on HANA gain faster data loads, their data model is simplified, remodeling is easier (e.g. while adding/removing new characteristics/key figure), no changes to cubes after migration to HANA.
Within BW on HANA cubes are become even less relevant from data storage perspective. In case there is no any business logic in place between DSO and cube layer there is no need to have cube layer. Report can run directly on top of the DSOs. Of course this needs to be approached by checking data flow one by one. If this is the case data model gets simplified. Be aware that there are still cases there cubes are needed. Just to name a few: usage of non-cumulative key figures in cube, external write access to cube, integrated planning.
More information can be found here: InfoProviders in SAP NetWeaver BW powered by SAP HANA
4. New InfoProviders as of BW 7.3
A bunch of new InfoProv types were introduced in BW version 7.3. Let’s see how they are supported while BW runs on HANA.
Semantic Partitioned Object (SPO) – SPO is used to store very large volumes of data as per partition defined based on business object. There are two cases depending weather SPO is based on DSO or on cube. In case of the cube it gets automatically HANA optimized. In case of DSO you may want to convert SPO to HANA optimized see note: 1685280 – SPO: Data conversion for SAP HANA-optimized partitions.
CompositeProvider – Enables combination of InfoProviders of type cube, DSO and Analytic Indexes (like BWA and Analysis Process Designer (ADP)) via UNION, INNER and LEFT OUTER JOIN. Such a scenario runs faster in BW on HANA as UNION/JOIN operations are executed in HANA and not on application server.
HybridProvider – Used for modeling for near real-time data access. It is combination of two InfoProv: one for historic data (e.g. cube) and other one for actual real time data (e.g. DSO loaded via Real Time Data Acquisition (RDA) type of DataSource). Here same rules apply as mentioned above for cube and DSO: in case of cube it is automatically HANA-optimized and in case of DSO it stays standard as it was before HANA migration.
VirtualProvider – either based on: Data Transfer Process (DTP), BAPIs or function module are used for e.g. reconciliation purposes of the data loaded in BW with a normal staging data flow and the source system. Such a VirtualProv runs in BW on HANA environment as well.
Other case within connection to VirtualProv can be with reference to HANA model. By this HANA model e.g. analytic or calculation view is exposed to BW’s InfoProv.
TransientProvider – As it has no any persistent BW metadata (nothing visible in BW’s Data Warehouse Workbench) there is nothing to be optimized by HANA. Actually TransientProv is used to consume a HANA model (Analytic or Calculation View) which is published into BW (transaction RSDD_HM_PUBLISH). So if you have some scenarios with TransientProv it should work in BW on HANA as well.
Analytic Index (AI) – Is data container in BWA stores the data in simply star schema format as facts and characteristics (dimensions) with attributes. The data for AI is prepared by Analysis Process Designer (APD).
Moreover while connecting of AI to TransientProvider: HANA model can be published in the BW as AI. TransientProvider is generated then on this AI. While having scenario where data is being changed very frequently; HANA model is changed also the AI is adjusted automatically.
Snapshot Index (SI) – If BEx query is marked as InfoProvider in BWA an index called Query Snapshot Index (QSI) is created. Such a SI for Query as InfoProv and SI for Virtual Prov are still supported in BW on HANA.
5. Process Chains
There are few process types that are obsolete in BW system running on HANA. These are Attribute Change Runs (ACR), aggregate roll-ups, cube roll-ups, cube’s index deletion/creation before/after the load. Existing chains having these processes will run without errors just those processes will not be executed. However clean-up is advised to be done after the migration to HANA.
BEx queries stay as they are and no change is needed. While query runtime HANA is leveraging column store and in-memory calculations as engine for query acceleration. The data is not replicated (e.g. in case of aggregate or BWA) – the query runs directly against primary data persistence.
Therefore queries should run at least as fast before HANA migration in BWA but better runtime is of course anticipated without any changes to queries itself.
When it comes to SAP BW’s planning application they traditionally run in BW’s application server. While HANA in place; planning functions are running in-memory. Therefore with no change on planning models, planning processes a performance boost is expected in BW on HANA in areas: dis/aggregation, copy, delete, set value, re-post operation, FOX formulas, conversions, revaluation etc.
Authorization and all activities related to user access are managed by BW application. Therefore nothing has changes here while migration to HANA DB. All authorization concepts used before are being valid and used. Going forward if you will be using also purely HANA objects (e.g. HANA models: attribute/analytic/calculation views) these are managed by HANA privileges. They are less detailed comparing to BW authorization therefore if you need complex authorization you need to consume HAMA models via BW’s InfoProviders like Transient or Virtual one.
Notice that authorization must be already using BW 7.x technology prior DB migration to HANA.
Other sources of information on BW on HANA: