Having recently migrated BW onto the HANA in-memory platform for one of our FMCG clients, I wanted to write about some of the key changes BW on HANA brings from both a day to day system management and development perspective at a high level. There’s lots of great content out there on HANA but very little on a consolidated view of operating BW HANA on a day to day basis.
BW on HANA delivers significant improvements for both query and loading times, most of which happen transparently under the bonnet, but what does it actually change at a day to day operational level for your BW team?
The key point to remember is that BW on HANA allows you to optimise and streamline your existing BW system: migration to in-memory technology without the need for reimplementation. This means that BW on HANA is non-disruptive to the business users (zero retraining). At a high level it also means that the day to day running of your BW system, from both a functional and technical viewpoint, is the same as old but. There is however some new knowledge that’s required to manage the system effectively and make sure you get the most impact and value from your HANA investment.
The key functionality which gets removed with BW on HANA centres mainly on the tasks to manage performance.
BW Aggregates are gone. No need to build them and fill them at every InfoCube data load, no need to manage them given the fact they may become quickly obsolete depending on what questions the business is asking the system.
Deletion and creation of indexing pre and posts data for InfoCubes loads are also gone. Optimised data retrieval is handled for us by the HANA.
One other point to add here, if you have BWA, you don’t require it either after migrating to HANA including its specific functionality (i.e. BWA roll up).
In-Memory Optimised (IMO) objects
InfoCubes now become in-memory optimised (all newly created InfoCubes will be IMO by default and migrated InfoCubes will need to be converted). We now have one fact table and just one dimension table for the data package details. All of the InfoObject characteristics’ SIDs are now keys directly in the fact table meaning quicker data loading, reading and reduced modelling effort. This also means dimension modelling & issues around high cardinality is gone.
A point to clarify, InfoCubes are still required with BW on HANA. There may be the possibility in certain scenarios to remove the InfoCube from the data flow because reporting can now be performed very quickly directly on top of the granular DSO. There’s still certain scenarios however that require InfoCubes, such as non-cumulative key figures which can only be modelled in InfoCubes.
On the topic of non-cumulative key figures, inventory InfoCubes have also changed. Instead of setting the flag for ‘Marker Update’ during the compression of an InfoCube you now have to decide within the DTP whether the records are treated to be historical transactions or deltas.
Active Data Management
Whilst HANA will manage the memory for you, in terms of displacement of object’s data from memory if the allocation is being reached, you can specify an unloading priority object by object. This influences when the object will become unloaded from memory, along with its last accessed data, should it be competing for memory with another object. By default PSA tables and Write Optimised DSOs have the ‘Early Unload’ flag set giving them a lower memory priority when compared to InfoCubes for example. There is a new transaction to allow the management of this, as well as the ability to manually load and unload tables (PSA, DSO, InfoObjects, InfoCubes) from the memory of HANA.
A separate blog will follow soon on a more in depth look at active data management in BW on HANA.
Delta Merge Management
When data is loaded into HANA it is loaded into memory, but not directly into the main memory tables, rather into a delta memory table. This means data can be quickly written into memory without having to reorganise the main memory tables each time (such as the reorg of the data dictionaries, see this blog for further details on HANA tables). But as the read performance of the delta memory tables is not as optimal as the main memory tables we need to merge the two together which requires the reorganisation – known as a delta merge. For certain BW objects this delta merge happens automatically by HANA but some objects require it to be specifically triggered. We can automate this trigger by using a new option within a DTP or can use a new processing type within a Process Chain. To ensure delta merge is triggered at the most optimal time, including the automated triggers in HANA, this requires some thought, consideration and tweaking.
HANA execution mode for queries
BW on HANA offers different read access modes for query execution, changeable in RSRT along with the standard query read modes (it’s also configurable at the InfoProvider level too). The current 4 modes influence whether SQL or the HANA API is used to call the data and how it is called (a query built on a MultiProvider with multiple InfoCubes beneath it for example, is the data called in parallel for the Part Providers and the Union pushed down into HANA?) and determining where exception aggregation is performed. Changing and testing the various HANA execution modes against a query, particularly those with complex restricted key figures, can make a difference to performance.
BW and HANA model interoperability
It is possible to consume BW data models directly from the HANA database (in an external BI tool for example). These are the HANA Analytic & Calculation views that get created on top of the BW InfoCubes and DSO (automatically or by importing manually) which can be combined with native HANA content. You can also consume native HANA views within BW through Virtual, Transient and Composite Providers, read more on this in the latter part of this document. You can also create a HANA Analytic view on top of a snapshot of a BEx Query.
Even though there’s only one fact table of an IMO InfoCube, you still have the option to run InfoCube compression. Compression is no longer required to be run for query performance reasons, since the impact of size difference before and after compression of the fact table is negligible for the read performance.
In some cases compressing the InfoCube can however have a positive impact on the load time, or to be more precise, the delta merge time, but this only becomes only relevant for very large InfoCubes. The InfoCube compression is now executed as a HANA optimised Stored Procedure, but still triggered in the standard ways.
The fact table of an IMO InfoCube can no longer be physically partitioned by using a time characteristics (Fiscal or Calendar). Query performance is fast even without such time partitions on very large fact tables. However, an IMO InfoCube in HANA has 4 different partitions for its fact table, which are created automatically: Partition 1 for non-compressed requests, Partition 2 for compressed Requests, Partition 3 for reference points of the inventory data, and Partition 4 for historic movements of inventory data. Partitions 3 and 4 are created even if the InfoCube does not contain any inventory/non-cumulative key figures, in which case they are always empty.
Integrated Planning (IP)
With HANA as the database the limit on the number of characteristics that can be used as the key fields of a direct update DSO used for IP gets removed (16 key fields max on non-HANA databases).
Although not all BW functional consultants/developer will use the DBA cockpit transactions, they can be an extremely useful way of analysing the DB size (memory consumption in particular), growth, alerts and table details. The DBA cockpit changes with HANA as the database and gives a view of things similar to the HANA studio.
All of the changes that BW on HANA brings are of great benefit, overall we will be able to save time on managing and maintaining BW. This means more time to deliver and meet evolving business requirements and embarking on delivering new capabilities within BW itself, or around the BI layer on top of BW such as data visualisation and mobilisation outputs in BusinessObjects for example.
The final thing to add here is around the approach, thinking and mind set around BW. With BW on HANA we have a platform that removes previous boundaries in terms of complexity, granularity, performance and development effort. Solutions that were previously difficult to achieve can now be executed on the platform and new reporting scenarios can be implemented and achieved. This extends to how the business users interact with and use the system.
The AgilityWorks BW on HANA Fast Start Migration
Our BW on HANA Fast Start Migration offers an accelerated end to end delivery model for migrating your BW landscape onto the HANA platform. You could be up and running with your productive BW system on HANA in as little as 10 weeks. The Fast Start Migration program includes full knowledge transfer to your internal teams throughout the migration process to ensure you get the most out of your HANA investment. This includes HANA and BW on HANA knowledge workshops, as well as tailored materials and documentation. All of the topics highlight in this blog are explained and discussed in further detail including the hows and whys for your system in an Operating BW on HANA workshop.
To find out more about the BW on HANA Fast Start Migration, our other BW and HANA services and how we can help you start you HANA journey, please get in touch.