BI experts Dr. Bjarne Berg of Comerit & Penny Silvia of IBM recently took questions in their second forum on HANA. The first one was back in July, pre-implementation of their joint HANA implementation, and they held their followup Q&A on October 26, now that the ComeritLabs HANA rollout is complete.
Molly Folan, producer of SAPinsider's HANA Seminar and the Xcelsius Dashboards Bootcamp, recently moderated this Q&A with Dr. Berg and Penny Silvia, authors of the new SAPinsider book SAP HANA: An Introduction.
Penny and Berg responded to your technical implementation, integration and performance questions.You can view the entire archived thread in our BI-BW Forum, or read our edited transcript here:
Molly Folan: Penny and Dr. Berg - thanks so much for joining! I think everyone would be very interested in hearing an update on your HANA implementation, if you wouldn't mind discussing!
Just a few notes on the experience of these two experts who have joined us today...
ComeritLabs recently collaborated with IBM on testing, development, and benchmarking SAP HANA for BW solutions and are actively using their HANA implementation now. .
Dr. Berg: The HANA system we used in our book is now completed and I am now working with 5 companies on their HANA implementations. Two are IBM based HW, one is on Fujitsu's hardware, and two are using Dell's 910R box.
Some are quite interesting and will have over 40Tb of raw data with a project of over 18 months, while another is only 500Gb (raw data) and the client is attempting to do as much as they can themselves in only 6 weeks.
So, HANA looks like it is being deployed quite rapidly this fall...
PavanVasudevan: I have now received the book SAP HANA: An Introduction, from SAP Press and read through few chapters. Thanks for the comprehensive coverage of all the topics related to HANA.
My question is: What kind of performance improvement can be seen with the Accelerator scenario? For example, with CO-PA Accelerator, since the logic is still in SAP Application Layer (or SAP AS)? Is it 2x or 3x or more? Is there a need for tuning on the ECC system for this scenario?
Dr. Berg: Hi Pravan,
The performance depends a bit on the logic you are using on the Accelerator. The calculation engine is basically inside HANA, so that is much faster (as well as the I/Os). There is still an application layer, but it is mainly for graphical presentation, connectivity and app logic.
So, we may see 5-20x faster access depending on number of value fields, number of COPA records, and the query design (filtering and conditioning). For the ECC environment, there are minimal changes needed unless you are having a very high number of records, complexity and/or poor system performance already.
1. HANA sizing is done on the primary memory required for the data. My question is how do we size for concurrent users in HANA?
2. What is the failover architecture in HANA? How should we plan for continuity in case of hardware or software failure?
Dr. Berg: Hi Dibakar,
There are 3 ways to get some sizing numbers:
Method 1: You can look at SAP's T-Shirt sizing model to get some basic ideas.
Method 2: You can use a rule-of-thumb for preliminary sizing. This include RAM = (data footprint /5) *2; 1 x RAM for log files on disk; 4 x RAM for persistence area; 0.2 CPU cores per active user.
Method 3: You can use the bottom-up detailed HANA sizing in SAP's Quick Sizer for HANA.
There are 3 versions, but for BW on HANA, you also get some programs you run on your existing HANA system to get detailed input for the footprint (table-4 in the Quick Sizer).
So, start from the top and then refine your estimates by Methods 1 and 2 and then do it properly with Method 3. This is detailed with step-by-step instructions in our HANA book on pages 121-129.
For the continuity for HANA, there is a difference between Disaster Recovery and High-availability (HA was available as of 6 months ago). This is a very complex area that we cover on page 403 and SAP has issued more details on this topic in the HANA admin guide, but it is basically creating up to 3 standby name servers.
The active one of these is assigned the master index server and a statistics server and if the active name server fails the other standby server kicks in. You can also create groups of failover systems for each host (faster restores).
So, again a very long topic that can be 2-3 sessions at TechEd...
Almost forgot: SP5 contains updates for the High-Availability for HANA
M.S. Hein: Hi Dr. Berg and Penny.
I have some questions. We're getting questions about using a Rapid Deployment Solution or full-blown HANA implementation. How do you compare the two? How should we advise on which one will meet the project's needs? Thanks.
Dr. Berg: I am going to let Penny answer this. (She wrote the RDS appendices in our book).
Penny Silvia: The RDSs are a good option for those who are looking for a very specific 'point' solution and are able to accept that solution as-is. The good thing about the RDSs is that they are fixed price - but that also means they are fixed scope. Like many other things - the devil is in the details. You have to assess how much customization will be necessary to have these meet your goals - or if you are able to live with something that is 'close enough'. They are ALWAYS worth looking at!
Zahir Malpekar: Hi Dr. Berg and Penny Silvia,
1. How do we decide on SAP HANA version & what points to be consider for selection?
2. When doing implementation SAP BW on HANA for easy integration, please let me know the best practice to follow?
Dr. Berg: Hi Zahir,
There are basically 3 editions of HANA: the platform edition, the enterprise edition, and the extended enterprise edition. You can also buy BW-specific licensing.
The differences between editions are mainly the ETL components -- for example, with the enterprise edition you get BOBJ Data Services, DXT and SLT (not included in the platform edition). While in the extended edition, you also get Sybase replication server, Load controller (LC) and ASE as well.
We outline the differences of each of these editions on page 130 and also show all subcomponents in a table on page 131 (if you are looking for more details).
For the implementation, it is hard to determine best practices. Today I worked with a company where their hardware vendor shipped an empty box with nothing in it. Then the hardware vendors sent a person to install HANA and left the client by themselves to install BW, set up servers and connectivity. Another hardware vendor takes a much more comprehensive approach and installs all software at their site and ships a complete box with all software components installed (I like this better)....
If we do the latter, I prefer a clean install and start all new development in the new HANA box and leave the old 'stuff' back in the old BW system. This allows me to keep the old system, while gradually migrate new content to HANA either as new development, or moving old config and then redesign it.
The tasks are then typically:
1. Conduct HANA health checks for connectivity, install, disk and memory allocations
2. Configure HANA system with setup for privileges and access rules
3. Configure Monitoring alerts, and administrative notifications
4. Configure SLT for extraction and/or Data services for non-SAP extraction jobs (incl. table setup and job scheduling)
5. Covert key data stores and InfoCubes to HANA optimized InfoCubes and DSOs
6. Setup users and roles in HANA system
7. Setting up admin console and client customization (i.e. templates, background saves, logs, catalog objects retrieved, error dialogs, values formatting etc.)
8. Adding systems for and interfaces for HANA in/outbound data (JDBC, ODBC, BICS, XML or DBSQL)
9. Setting up memory and disk monitoring jobs for HANA Administration
10. Install permanent licensing keys and cutover for HANA production environment
11. Set up automated updating of HANA studio and/or appliance (rules) and testing of Update manager
12. Setup authentication server and/or LDAP, Kerberos, SAP authorization, assign admin privileges and roles,
13. Conduct HANA admin workshops and knowledge transfer to HANA administrators
14. Create first BW application (extraction, DSO, IC, MP, DTP, BEx Query and process chain) to test HANA appliance
As you see, I get this question often :-)
GopalakrishnanVenkatachalam: Hi Dr.Berg and Penny Silvia,
Can MDX be used by third-party reporting tools to report on HANA data?
Dr. Berg: Hi Gopalakrishnan,
Not yet. The current version is MDX for MS 2010. So it is not a generic version, but MS specific for MS query and MS Excel integration. We show you how to do this step-by-step with screenshots on pages 115-163 in the book if you are interested.
PaulArevalo: Hi Dr. Berg, my question is: Does SAP NetWeaver BW on SAP HANA provide “Real-Time Analytics Capabilities” or does the data latency still reflect the time the data was loaded into SAP BW?
Dr. Berg: Hi Paul, There are several ways to get this:
1. Increased data feeds with SLT or LC. Since data activation and loads are much faster, you can push this to 'near-time' data warehousing with minimal latency.
2. HybridProviders (BW 7.3 feature) with querying directly for the current records in ECC and old records in HANA/BW
3. Deamon updates (still available)
4. ECC 6.0 SP8 has BEx query designer and you can pick it up directly in BOBJ
5. Virtual/remote cubes in BW with querying directly as a through-pull to the ERP box.
SO lots of options, but I strongly prefer #1 if you have invested in HANA already...
By running BW on HANA and using Real Time Data Acquisition (RDA) extractors, can we achieve the near real-time reporting on SAP data? Does HANA improve this process in any way? Or running SAP BW and SAP ECC on the same HANA box the only alternative to achieve real-time reporting in a multi-source environment?
Dr. Berg: Ooops! Forgot RDA. Yes, that is an option as well. The process that changes for HANA is basically the activation.
With HANA the SID generation is done in-memory and the lengthy and slow process of accessing the NRIV table is extremely fast. I have seen load/activation performance as high as 36% faster. So this is significant if you are having 1+ hour activation times. Even smaller data loads benefits greatly from it and perhaps WO DSOs are no longer needed and you can build reportable DSOs in the future instead (what happens with ICs are still a questions to be answered by 'best practice').
Molly Folan: Hi Experts --I've received lots of questions from customers on the requirements for building a business case for HANA. Could you speak to a few of the key factors that should be considering in this process?
Dr. Berg: The business case can be built around:
1. Server simplification (multiple app and DB servers)
2. Costs savings for DB licensing as well as faster deployment (may not need as many layers for DSOs and ICs as well as aggregates).
3. Saved labor hours by business. I have a client that had an average of 9,500 reports run every week at over 67 second average runtime. With HANA we expect this to take 10 seconds or less. That is 150 hours waiting for reports each week. If we have a labor costs of $28/hr, that alone is a saving of over $219,000.
4. New capabilities (whatever you are planning to do)
5. Performance tunings savings (less need for that)
We also outline 4 more business case examples in detail in our book in chapter 4. Just some ideas,
Zahir Malpekar: Hi,
1. HANA's implementation for column-based tables has a few limitations, like performance problems, when it comes to joining tables stored in a "column store". What steps should be taken when such a scenario occurs?
2. HANA has its own user authorization database, but doesn't have a built-in ability to read or use the security database of other SAP products. That means that besides having to transport the DATA to the HANA system, you will probably have to find a way to copy or recreate the user authorization database in HANA.
Dr. Berg: Hi Zahir,
For question 1:
Column data stores are great for search, analysis, calculation, smaller data footprint and faster data access than row data stores. But it can have lower performance than row data stores when working with joins. Some of this is due to the need to link to the individual data point that has been compressed. It is important to keep this in perspective -- the join is still dramatically faster than a traditional database like Oracle, but in some case not as fast as a row data store (depends a bit on the number of records).
We discuss much of this in the advanced HANA modeler chapter (chapter 8) in the HANA book and go into some details on what can be done to minimize the impacts (i.e. partitioning). But it is still 'bloody' fast! ;-)
For question 2: There are some workarounds to upload the roles. For most of what we are doing now, we interface with SAP security, Kerboros, LDAP, or we manually recreate the roles and priveledges in HANA admin console...
Richard Bremer (Senior RIG Specialist at SAP) has done some presentations on HANA security and I know he will deliver another session on HANA security at TechEd in Madrid next week. You might download his deck for the possible workaround, but my team typically keeps this in another server, or more commonly recreate it in HANA as part of our install project.
Philip Neijenhuys: Hi Dr. Berg,
We have tried to deploy a BWA solution, but the BWA indexes were not used in most of our queries. The reason was extensive use of display attributes from the master data.
We are planning a proof of concept with BW on HANA to find out if our queries do get the needed acceleration. Can you comment on this and what we need to do to make the PoC a success? Thanks!
Dr. Berg: Hi Philip. FYI:
- BWA will not be used if a query has a key figure set to NO1, NO2, or NOP (no aggregation).
- Some could have used the ABAP program ‘’ZZ_SET_QUERY_NOHPA_FLAG to turn off BWA access for single queries in the RSRREPDIR table (mean people :-)
- Some could have turned off the BWA index query availability for InfoCubes through the transaction “RSDDBIAMON2.”
- Nor can you use the exception aggregation for single key figures in SAP BW Accelerator if it uses:
Virtual key figures
> Conversion before aggregation
> Formula calculation before aggregation
> Non-cumulative key figures
> Key figures with elimination of internal business volume
So there may be many reasons why BWA was not used (i.e. over 3 million rows in result set/data package). However, most of this becomes meaningless when the BI analytical Engine in BW 7.3 and the database are in-memory (HANA).
So I would expect significant differences in the BWA vs. HANA PoC.
Thanks for your replies to my earlier questions. I have another question:
While implementing/migrating BW on HANA, will there be a possibility to run SAP ECC on the same HANA box in the future if we size it for both BW and ECC? Or will this require a separate instance of HANA for ECC?
Dr. Berg: Hi Gopal,
Hard to tell. You cannot run ERP and BW in the same box today, and I have not seen anything form SAP that indicates that you will be able to do that in the future (except some bullet points in some Powerpoint decks).
It is a great idea for smaller companies, and I believe it would be possible with some changes to the backend. But this is an SAP product strategy question that I would pose to Ingo Brenckmann, the Senior Development Manager for the HANA product management in Walldorf. I would not expect it in the near future.
Mike Ballentine: My corporation is looking at Visual Intelligence, would you recommend that we deploy it over HANA even if we are still a relatively small reporting shop?
Dr. Berg: Hi Mike,
Absolutely. I was speaking at BI2012 Singapore last week and saw the new demo of visual intelligence and it is really cool! With HANA you get dramatically faster performance and this is somewhat expected when people navigate maps, images and graphs on-the-fly. You have 5 options:
1. Install HANA and have everything run faster
2. Pre-cache queries in OLAP cache using BEx broadcaster (poor-man's HANA, but only 200-400MB memory),
3. Create summary cubes with less details (harder to do with VI that needs to map anything)
4. Create 'snapshot' cubes with only a day or a weeks data (i.e. current) to get volume down
5. Create x number of aggregates.
I think #3-4 are legacy workarounds, while #1 is the cleanest and simplest solution.
Molly: Thanks to all who posted questions and followed the discussion! Today’s live online forum will be wrapping up shortly, but we will post a full summary of all the discussion here in the SAP BI-BW Forum.
For Dr. Berg’s regular blog on Insider Learning Network. And of course, if you have a specific BI question, ask the entire community by selecting "New Thread" in the Forum.
And thank you again to Comerit’s Dr. Bjarne Berg and IBM’s Penny Silvia for joining us today!