SAP NW BW 7.3, powered by SAP HANA - How does the InfoCube/DSO data gets stored?

[Former Member]

Hi HANAians,

Its good to see so many people discussing about SAP HANA and BW on HANA. I am late to enter this forum, since I was on experiencehana.com

Some straight questions -

1. Once BW is on HANA, how does the data in InfoProviders (InfoCube/DSO) gets stored in the HANA DB - Columnar or Row. Or is it the 'internal intelligence' of HANA that decides how to store the data. If so, HOW (on what parameters) does it decide? In one of the documents, it was mentioned that only Analytic Views created in HANA Studio in turn creates and stores data in columns.

2. We have massive parallel processing available via multi-core processors. How do I leverage the same with my existing ABAP/Coding in BW? Native SQL (pushing calculations onto Database Layer) and Asynchornous RFCs (Parallelism) are some of the ways. Any other methods? And if I need to leverage, I will need to change my ABAP. This defeats the 'non-destructive' glamour of BW on HANA.

3. With BW on HANA we do not utilize one of the USP's of HANA which is real-time analysis. Unless, you have enhanced your datasource earlier for real-time extraction. Which means only in-memory (and some areas of modeling like compression is no more required, etc.) is the advantage here. Any thoughts?

4. HOW does HANA compress the source data to achieve compression ratios of ~ 5 times. is it only the columnar storage that leads to such massive compression of data?

Appreciate your thoughts on the above.

Thank you.

Regards, Kunal Gandhi

[lbreddemann · Accepted solution]

Hi Kunal,

I'll try to briefly answer your questions, although most of the information could be found here in the SAP HANA space and on https://www.experiencesaphana.com/ ...

1. The user data of the BW system is always stored in column store tables. You want to have good reporting performance on your DSOs and Infocubes. This is true for basically all tables, except a set of BW/Netweaver-internal management tables, that aren't used for reporting, but used in a rather strict OLTP fashin (e.g. all the basis tables).
2. As an ABAP developer you don't have to think about how to parallelize data access on HANA. This is done automatically and depending on the technical possibility to actually parallelize a certain statement as well on the overall system usage.
   
   
3. There are many additional benefits that improve the overall BW-efficiency even if you're not looking into realtime-operational-reporting. There is no need for aggregate building anymore. You don't need ot drop and rebuild secondary indexes and CBO statistics collection has become obsolete.
   Even more, due to the high query performance, reporting on DSOs will become way more popular and InfoCube will likely become modelling schemes - but not materialized data stores.
   
   These are just a few benefits to mention and you get all this, without having the need to actually change your datawarehouse.
4. The HANA column store is technically based on a value dictionary - so "dictionary compression" is what you get automatically when you create a column based table and we call it compression NONE
   As soon as the delta index is merged, HANA automatically analyses the contents of every column and picks one of multiple (e.g. RLE, cluster packing, etc... ) algorithms to actually compress the data even more. Again, this happens fully automatic (except you're the kind of super-DBA that fiddles around with every internal setting to further optimize this...

Ok, I guess that's a lot of answers and more are already present here in the SCN space and on the website I mentioned. Also, don't miss out on the pretty good documentation available on https://help.sap.com/hana_appliance .

best regards,

Lars

[Former Member · Accepted solution]

Hey Lars,

Appreciate the prompt response. Thank you for the insights on my questions.

My understanding -

1. Information contained in all the InfoProviders in BW, by default gets stored in columnar tables. So there is NO hybrid (row+column) storage for BW on HANA and no parameters on which HANA decides that it should be stored in columns.

2. This is something that I have a slightly different opinion on. You mentioned that the developer need not worry and it will be (again) HANA that takes care of how to leverage the underlying multi-core processing power to execute our (existing) ABAP statements. But there has to be some ither ways (like Asynchronous RFCs as I mentioned earlier) to 'exploit' the processing capabilities. Do we wait for NGAP?

3. Agreed. BW on HANA has its own advantages.

4. (Again) HANA takes care of the compression and columnar storage and varied compression techniques help us achieve this. Please share (if pubilcly available) any technical documents on the same.

Hope my understanding on the above is correct. Kindly correct me otherwise.

Thanks, once again!

Regards, Kunal Gandhi

PS: I have already gone through 'many' of the documentation available on Experience HANA & Help and it gives sufficient details of 'WHAT' in all topics, but the 'HOW' is missing which I tried to present in questions as above. I have gone through these documents and am versed with the basics and architectural details of SAP HANA. As a next step, I need some 'technical' know-how of the different features of HANA.

[former_member184768 · Accepted solution]

Hi Kunal,

In my point of view:

1) It is necessary for you to ensure that the DSOs and Cubes in BW on HANA are "Optimized for HANA". Once you do that, the existing data will be migrated to Columnar storage.

2) For the DSOs 4 tables can be seen in the system ending with 00 (Active), 40 (Update), 70 (Modification Rules) and 80 (In memory activation), which can be related to Active table, New table, Delta and History tables as per the architecture. Again I could not get any more details on these tables and the storage architecture.

3) Change log is just a view and not a storage in the system anymore.

4) Regarding the ABAP capability, it should be explored if you can call native SQL procedures through the ABAP code using EXEC SQL calls. I do not have complete information on this yet, but it it is worth trying. I believe you need the power of native SQL for the lookup / data selection and not for data manipulation.

5) From utilizing the MPP architecture perspective, you can see that in regular BW operations like data loading, activation (delta merge) and Queries. It can definitely be influenced by the BW settings, but again SAP also takes care of it in the regular operations and queries.

Hope this helps.

Thanks and regards,

Ravi

[lbreddemann · Accepted solution]

Hi Ravi,

your point of view 1) indicates that if you not convert your InfoCubes/DSOs to the "HANA optimized" version, they won't be stored in the column store. That is plain wrong!

As I wrote, ALL your BW data is always stored in column store - using the optimized versions "just" changes the physical data design (e.g. no persisted change log table for DSOs anymore - instead a calculation view is used to derive the changes, or that no dimension tables are used for Infocubes anymore).

For your point 4): it's perfectly possible to call procedures via ABAP - actually this is done a lot in BW on HANA.

For point 5) don't confuse the DELTA MERGE operation with the activation of data. These two actions refer to completely different areas. DELTA MERGE is a operation on column store structures - totally HANA internal stuff. Activating data on the other hand is an activity in your data warehouse. It has a meaning to your business data.

For the parallelity employed for any HANA action, there are (at least not yet) any BW settings to consider. The BW-level options available are not HANA specific...

best regards,

Lars    

[Former Member · Accepted solution]

Hey Lars,

Thanks! I have (almost) understood every question that I asked. May be it will get more clear and confident once there is some documentation released publicly from SAP in these regards.

@ Ravi - Thank you for your inputs as well!

Regards, Kunal Gandhi