What Makes #BW-on-HANA So Unique!

Klaus Nagel

Posted by Klaus Nagel on July 29, 2013

Director - Development

More by this author

Abstract/Executive Summary

With some years delay now most mayor DB vendors have followed SAP on the path of providing columnar, in-memory engines in their database products. While this clearly shows that SAP took the right decision (early on) the question is how these offerings differ from HANA and what the right choice is for a customer. I don’t want to compare here the different technologies, stacks and fundamental approaches, or even worse, try to bash our competitors. Instead I simply want to emphasize and summarize what, in my point of view, makes BW-on-HANA so unique. Then you, the customer, can simply go and compare yourself.

My arguments for BW-on-HANA can be summarized in the following two fundamental points:

  1. SAP HANA is a columnar and in-memory Database from ground-up – and not an add-on to an existing engine. E.g. in BW-on-HANA more than 95% of the tables are in the ColumnStore – automatically.
  2. SAP HANA provides advanced and Application-specific Engines, Procedures, and Algorithms and BW-on-HANA can use those to push down time-consuming operations (like OLAP, Planning, Delta Calculations, Transformations …) – this is where the final speed comes from. This goes well beyond boosting SQL processing in an analytic context.


Let’s look at these points in some more detail.

  • ColumnStore versus RowStore

All solutions, including HANA, offer the option to store data either row-based or column-based. But in HANA only exceptions are in the RowStore. Less than 1000 tables of the in average 60,000 tables of a BW system are placed (automatically!) in the HANA RowStore – and I foresee that this number will decrease to less than 100 by the end of the year. The ColumnStore in general offers its unique value for an “analytic/OLAP” work load, but may have its deficits in other scenarios, like single record operations, and also potentially during bulk loads and/or massive parallel Inserts/Updates (“ETL”-load). The ColumnStore of HANA is not just super-fast for Analytics and excellent for ETL-load, but it is also simply good enough to handle almost any “OLTP”-like workload that occurs in a BW system. These can be lookups in transformations, status updates, statistics collection, auditing, or masterdata changes. So my statement here is, that HANA does embrace the Columnar approach full-heartily and seriously – and not as “just another tuning option”.

  • Analytics is not just fast SQL

As other authors and myself have pointed out, if you restrict yourself to SQL in analytics you can only have the lowest level of aggregation done by the database (see e.g. “BW-on-HANA and the FEMS“, “The OLAP Compiler in BW-on-HANA“). The rest of the OLAP operation needs to be done on the application server – which is, of course, much less optimized than when doing it without moving the data between the layers. HANA offers a CalculationEngine and a special interface for BW to execute complex statements that enables a push-down of calculation logic and additional aggregation types to the database server. This capability is largely the reasons for the excellent Query performance you see in BW-on-HANA – and without it you are restricted to either “simple” aggregation Queries or you speed up only the low level aggregation part of the query, which may be just a small portion of the end-to-end execution time.

An example is shown in this demo video: even with the very fast aggregation of HANA by pushing down the more complex operations (here cell-based restrictions and exception aggregation) the end-to-end runtime decreases from 16.3 to 3.4 seconds or 12.6 to 1.4 seconds.

  • HANA has a Planning Engine

Additional to the CalculationEngine SAP HANA offers a Planning Engine that enables the execution of planning operations close to the data in a similar fashion as the CalculationEngine does this for the OLAP processor. This Engine is leveraged not just by BW-IP (“PAK”), but also by the SAP BPC (NW) product, and HANA-native Apps like S&OP.

  • BW logic moving to HANA

Many data “transformations” and “operations” in a classic data warehouse can be executed now close to the data as opposed to moving the data to the application server, processing the logic there, and then moving the data back to the database. Examples are:

    • A lookup in a transformation often can be modeled as a JOIN – with the BW CompositeProvider you can decide to execute this JOIN only at Query runtime and do not materialize the result. The CompositeProvider JOIN is executed directly in SAP HANA.
    • The calculation of a “delta”, the Data Activation procedure for a DSO, happens inside HANA and no longer in the application server. This is the most time-consuming procedure within most data flows in BW. A 10-times better performance of this process (which we easily see at our customers) can be the enabler for a different way of working with your data and your data sources.
    • By the end of this year, with SP05 of BW7.4-on-HANA, we plan to release the “in-memory” transformations and the so-called HANA Analysis Processes. This functionality enables you to execute BW-modeled transformations (with formulas, currency conversions, projections …) or complex data analysis (like ABC clustering, K-Means, statistical analysis using “R”, DataQuality procedures …) directly on the HANA database using own SQLScript procedures, HANA-native algorithms, and the HANA CalculationEngine. All this is completely embedded in your BW data and process flow.

  • New scenarios based on the rich HANA content and new applications

The speed of HANA enables a new kind of usage. To mix this data with your existing wealth of data in BW and create new value and insight out of it is a gold mine that has just been taped. The BW CompositeProvider offers just these methods you need here (see e.g. here or check out the SAP HANA-optimized BI Content for some great examples).

  • and there is of course much more:
    • Agility and flexibility: BW Workspace offer a simple and secure way to integrate “local” data … and it requires intrinsic HANA functionality like mapping proposals …
    • Integrating HANA Federation in BW7.4 (new with HANA SP06)
    • HANA-native Read- and Write-operations for the NLS-solution with Sybase IQ in BW7.4

Key Take-Away

So when someone tells you that you simple have to move your BW to the new “xyz” database to compete with HANA, simple ask what the unique value proposition is and how this compares to the above points that HANA can make … and then it’s up you to decide.

VN:F [1.9.22_1171]
Average User Rating
Rating: 5.0/5 (1 vote cast)
What Makes #BW-on-HANA So Unique!, 5.0 out of 5 based on 1 rating