What is the neccesity of HANA enabled BW7.3 for BPC10.0NW? Why can't we directly fit BPC10.0NW  over HANA? Is there a future plan towards this direction?

Penny and Berg, thanks for joining us. Before you start responding to member questions, could you give a quick update of where your HANA implementation project stands now and how your SAP PRESS book is coming along? 

Jul 25, 2012 -- 12:27PM, mukundagattu wrote:

What is the neccesity of HANA enabled BW7.3 for BPC10.0NW? Why can't we directly fit BPC10.0NW  over HANA? Is there a future plan towards this direction?

 

Hi Mukandagattu,

That is a BPC question. I know that SAP is working on that, however, there are some work that needs to be done on writebacks. I have seen a demo and it worked fine, but I do not work with BPC so I cannot answer how SAP suppport this.

Thanks,

Berg

Hi Scott,

Many have asked, if InfoCubes are needed with a HANA system. Currently, there is significant debate on blogs and forums on the Internet on this topic. However, for the interim period there are several reasons why InfoCubes are needed:

First, transactional InfoCubes are needed for Integrated Planning and write-back options. InfoCubes are also needed to store and manage non-cumulative key figures and the RSDRI write interface only works for InfoCubes. In addition, the transition from SAP BW to HANA is simplified by allowing customers to move to the new platform without having to rewrite application logic, queries, MultiProviders and data transformations from DSOs to InfoCubes.

However, the continued use of InfoCubes has to be questioned. The propose of introducing the star-schema, snowflakes and other Dimensional Data Modeling (DDM) techniques in the 1990s was to reduce costly table joins in relational databases, while avoiding the data redundancy of data stored in 1^st normal form (1NF) in  Operational Data Stores (ODSs).

The removal of the relational database from HANA's in-memory processing makes most of the benefits of DDM mute, and continued use of these structures is questionable. In the future, we may see multi-layered DSOs with different data retention and granularity instead. But, for now InfoCubes will serve a transitional data storage role for most companies.

After the optimization of HANA InfoCubes, you can no longer partition the fact tables semantically. This is simply not needed. However, there are still four partitions behind the scenes. The first partition is used for non-compressed requests, while the second contains the compressed requests. There are also a partition with reference points of the inventory data and a partition for historical inventory data movements. The last two partitions are empty if there non-cumulative key figures are not used.

However, the first two partitions still require periodic compression to reduce the physical space used and increase the load times during merge processing (very much like traditional BW maintenance).  This has minor impact to small InfoCubes (less than 100 million records) and for InfoCubes that have not seen significantly data reloads nor have many requests. Since the compression is also executed as a stored procedure inside HANA the compression is very fast and should take no more than a few minutes even for very large InfoCubes.

Thanks,

Berg

And yes, you can continue using existing standard InfoCubes that do not have the SAP HANA-optimized property or you can convert them. The core of the new SAP HANA-optimized InfoCube is that when you assign characteristics and/or key figures to dimensions, the system does not create any dimension tables except for the package dimension. Instead, the master data identifiers (SIDs) are simply written in the fact table and the dimensional keys (DIM IDs) are no longer used, resulting in faster data read execution and data loads. In short, dimensions become logical units instead of physical data tables. (PS! the logical concept of 'dimensions' is still used  to simplify the query development in BEx Query Designer).

To convert existing InfoCubes, simply go to the program RSDRI_CONVERT_CUBE_TO_INMEMORY and select the InfoCubes you want to convert. The job is execute in the background as a store procedure and is extremely fast. Typically, you can expect 10-20 minutes even for very large InfoCubes with hundreds of millions of rows. During the conversion, users can even query the InfoCubes. However, data loads must be suspended.  Currently, traditional InfoCubes with a maximum of 233 key figures and 248 characteristics can be converted to HANA optimized InfoCubes. After the conversion to HANA optimized InfoCubes are maintained in the SAP HANA database's column-based store and are assigned a logical index (CalculationScenario).  However, if the InfoCube was stored only in BWA before the conversion, the InfoCubes are set to inactive during the conversion and you will need to re-activate it and reload the data if you want to use it.

While, HANA-optimized InfoCubes cannot be remodeled, you can still delete and add InfoObjects using the InfoCube maintenance option. This can be done, even if you have already loaded data into the InfoCube. 

Thanks,

Berg