Practitioner Perspective, HANA vs BW7 Modelling

SAP COMMUNITY NETWORK 2010 SAP AG 1

Practitioner Perspective, Modelling HANA vs BW7

Applies to: Document is applicable to all systems on SAP HANA Platform.

Summary This document provides an introductory and practical overview of HANA. It will provide a conceptual comparison as well as practical illustration.

Author(s): Benedict Yong Teng Xiang Created on: 1 December 2014

Author Bio Benedict Yong is a Certified SAP BI Consultant, and practitioner of Business Intelligence (BI) and Enterprise Asset Management (EAM).

He holds a Masters in ERP (Finance focus), Bachelor of Management (Australia) and a Diploma in Business InfoTech (Singapore). He is familiar with the Consulting and Support environments, with his various Project Lead & Consultant roles.

He is situated in Singapore and is bilingual in English and Mandarin. He can be contacted at [email protected].

Note: credits given on the last page.



Table of Contents Introduction ................................................................................................................................................... 3 Definitions ..................................................................................................................................................... 4

What is HANA? ......................................................................................................................................... 4 What are the benefits of HANA? ................................................................................................................ 6 What is BW-on-HANA? .............................................................................................................................. 7 What are the benefits of BW-on-HANA? .................................................................................................... 8

HANA Modelling step-thru ............................................................................................................................. 9 HANA Modelling Concept .......................................................................................................................... 9 Attribute View .......................................................................................................................................... 10 Analysis View .......................................................................................................................................... 11 Calculation View ...................................................................................................................................... 14 HANA Modelling vs BW7 Modelling ......................................................................................................... 20

Bridging HANA into BW7 ............................................................................................................................. 21 TransientProvider using HANA Model ...................................................................................................... 22 VirtualProvider using HANA Model .......................................................................................................... 23

Bringing together HANA and BW7 Data ...................................................................................................... 26 Getting Data at its Source: HANA Live ........................................................................................................ 30 Conclusion .................................................................................................................................................. 31 Credits and Content Sources ...................................................................................................................... 32



Introduction What is HANA? Despite all the buzz and media attentions given to HANA, it only brings more confusion as the definition continues to expand day-by-day. I liken HANA as a proverbial elephant that has many version of truths for those have not seen it firsthand. This paper seeks to provide introductory and practical overview of HANA.

Apart from answering what is HANA, it also seeks to provide answers to the following questions: How is it different from traditional database? Can or should BW and HANA co-exist? How does it impact BI architecturing with the inclusion of HANA technology?



Definitions

What is HANA? The term HANA is an acronym for "High-Performance Analytic Appliance.

SAP defines HANA as a modern in-memory platform that is deployable as an on-premise appliance or in the cloud. As an appliance, SAP HANA combines software components from SAP optimized on proven hardware provided by SAPs hardware partners.

In short, HANA is SAP in-memory solution. Its a database. You can run BW on it or you can run ERP (or other Business Suites) on it.

The following illustrates the multiple facets of HANA technology:

(image credits from SAP, additional anotation by author)

But in what sense is an in-memory database difference from a traditional database?



SAP HANA holds majority of its data in the memory for high performance. However, it still uses persistent storage to provide a fallback in case of failure. SAP promises a compliance to the ACID (Atomicity, Consistency, Isolation, Durability) expectation of traditional databases.

During normal database operation, data is automatically saved from memory to disk at regular intervals called savepoints. If a failure occurs, for example a power failure, the database will restarted in the same manner as any disk-based database, and it is returned to its last consistent state by replaying the redo log since the last savepoint.

SAP recommends that the Log file volume to be 3x 5x of the Memory for HANA.

Within the HANA box, we can choose to load all tables into it or selective (because the HANA box will still have a size limit). At startup, all row-based table are fully loaded, but column-based table are loaded on-demand (default setting).

SAP HANA is not only just an innovative technology, it is packaged with additional tools (such as HANA Studio for modelling, HANA appliances for specific business requirements)



What are the benefits of HANA? The speed benefit of HANA ranges in the thousands from 100x to 100,000x. At such performance improvement, organization can experience enablement that would never have been possible.

The performance of HANA is achieve through a couple of factors: (details on the individual factors can be found in www.saphana.com)



What is BW-on-HANA? As mentioned earlier, HANA is a database that BW or ERP can choose to run on. It is a logical step to move BW into HANA, due to its speed performance and scalable and agile modeling. From personal experience, BEx reports can have an improvement of 500x 3000x.

Typical BW

BW-on-HANA, means the whole BW server is running in-memory (including BEx)



What are the benefits of BW-on-HANA? We have two options to leverage on HANAs high performance:

1) Using BW base on the optimized cubes no modelling need, cubes are migrated 2) Using BW with HANA Modelling options.

HANA optimized infocubes have a different structure with traditional BW7 infocubes. InfoCubes in BW are modeled using the BW-extended star schema with 2 fact tables (an E table with read-optimized partitioning, and an F table with write/delete-optimized partitioning), Dimension tables grouping sets of characteristics, and shared Master Data tables. This schema is optimized for classic RDBMS technology. With HANA technology, the schema can be simplified to one fact table (HANA can perform read, write and delete operations equally fast on this layout) joined directly to the Master Data tables.

HANA optimized infocubes eliminate unnecessary joins and tables bringing in better performance. No modelling is needed.

However, to harness the power of on-the-fly in-memory advantage, we need to apply HANA modelling. HANA modelling comprises of views, these views generate real-time SQL statements behind the scene. The advantage is in its non-persistency nature: data is read and not staged, this data-modelling agility is coupled with native HANA DB in-memory speed.



HANA Modelling step-thru

HANA Modelling Concept HANA Modelling uses 3 information views, namely:

(1) Attribute View (2) Analysis View (3) Calculation View

The information views from HANA Modelling draw parallel to BW7 concept of MasterData and InfoCube. At the Attribute View level, we can combine several MasterData tables and appoint a primary key. At this stage, we can do Master Data reporting. At the Analysis View level, we can combine several Transaction Data tables as the foundation, and enrich it with Attribute View. At this stage, we can already achieve analytical reporting. If more complex scenario exist, such as merging two infocubes, we can create a Calculation View.

In pages to come, we will explain the HANA modelling process in greater details. It will helps to explain what is HANA modelling, but it will not be suffice to explain how to do HANA modelling.



Attribute View It is used for Master Data Modeling

Can be used to join two or more master data tables (eg MARA, MARC, MAKT, MBEW) No measures, only attributes

Attribute View modelling is broken down into 2 steps: At the Data Foundation stage, we can join master tables At the Semantics stage, we can set the details of the final columns

HANA Studio allows a sample data preview for the first 200 rows:



Analysis View It represents an OLAP View with a Star Schema including measures and attributes. Represents an OLAP View with a Star Schema including measures and attributes.

Can be used to join two or more transaction data tables (eg VBRK, VBRK) as well as master data tables and Attribute Views

Includes a Data Foundation based on a Fact Table with measures. Can be used for OLAP Analysis, typically within one functional area

Analysis View modelling is broken down into 3 steps: At the Data Foundation stage, we can join transaction tables At the Logical Join stage, we can link the Data Foundation with Attribute Views At the Semantics stage, we can set the details of the final columns

At the Data Foundation pane, we can insert the transaction tables and perform joining.



At the Logical Join pane, we can see the transaction tables are represented as Data Foundation. We can perform joining with Attribute View.

At the Semantics pane, we can set the details of the final columns.




HANA Studio allows the sample data preview to be in charts:



Calculation View It is used for Advanced Modeling, for instance cross-cube analysis or flexible joining

Calculation Views are used to address complex business scenarios. They are created using attribute views, analytic views and tables.

It can be created directly using the SQL (Script) editor, or using the standard Information View Modelling

Calculated View modelling is broken down into 4 steps (minimally): Projection where Analytic Views or Attribute Views are selected Combination the individual Projections can be combined (Union or Join) Aggregation grouping of lines with similar keys. At aggregation, Attribute View can be added Semantics settings on the final columns

In our case, we can have a fabricated taxation scenario. In our taxation analysis, we need to compute the total taxation amount where New York has a 15% Goods/Services Tax and Texas has a 7% Goods/Services Tax. In Calculation View Modelling, we can do Select (aka Projection) for New York and compute the amount. Likewise for Texas. Finally, perform a Union



We start by pulling in the Projection Task into the Scenario Pane. After defining the Projection Task, we will drag in the Union Task.

During the definition of Projection (Selection), we can choose what column to pick and filter off rows. In our case, we need to filter State = New York.



In the Projection Task, we can define new columns. In our case, we need to create the computed State_Tax as (Amount Sold X 15%).

In the Union Task, we can map the output fields from the incoming fields (from the Projection).



Next we are going to include the next leg for State = Texas and include it into the Union mapping.




Alternatively, a Calculated View can be created base on scripting (instead of modelling panels).



HANA Modelling vs BW7 Modelling BW7 Modelling is based on persistent data storage hence will have loading tasks such as Infopackage, DTP. HANA Modelling based on in-memory data storage hence will focus more querying tasks such Join/Union, Aggregation, Projection (equivalent to SQL Select / Where). Remodeling is a topic organization shun due to its risk and effort for data migration. However, in an ever-changing business environment, changing business strategies entails changing reporting and remodeling of datasources. In BW7, the Remodelling Toolkit helps cushion of quite a large portion of the pain but migratory effort still exist at a smaller scale. With HANA Modelling having transient InfoProviders, it rids us the hassle of post-remodelling migration, cutting short deployment time, allowing agile response. Do note that the developer will still need to re-publish, activate the infocube when the model gets updated.

Revisiting the earlier Calculation View Tax Scenario, HANA Modelling makes development flow with greater ease. Using BW7 Modelling for the same scenario, we need to have two more cubes to split the data into two different Taxation States for individual processing and union them back again with a MultiProvider. Not to mention, the Process Chain needed to cater for the additional modelling steps. For discussion purposes, we can have a quick-fix by using a restricted key figure in BEx. But what if the criteria gets more complicated, how would BW7 Data flow handle and how would HANA Modeler handle? In HANA Modeler, we are allowed to create multiple Projections (SQL Select / Where) and in each isolated Projections we can tweak the flow of that particular set of data. Eventually when we are ready, we can merge those Projections with a Join/Union task. For those who are SQL purist, they can query their way into a Calculation View. Such flexibility and scalability will be very difficult for any persistent InfoProvider to rival.

BW7 Data flow HANA Modeler



Bridging HANA into BW7 The HANA information model can be utilized by BEx, in one of the two ways: 1) TransientProvider using HANA Model 2) VirtualProvider using HANA Model

From our earlier HANA Modelling, we have created 3 type of Information Views. We can use these for illustrating how HANA data can be access by BW (specifically BEx).



TransientProvider using HANA Model For the above option, we need to use the BW7 transaction RSDD_HM_PUBLISH. This will export HANA Model to BW7 and make it available for BEx. It is optional to create specific infoobject for the published fields.



VirtualProvider using HANA Model For the above option, we need to use the BW7 Workbench to create a VirtualProvider with the 4th option VirtualProvider Based on HANA Model.



Package and Information Views has to be selected.



Individual fields from the information view has to be assigned with a BW infoobject.



Bringing together HANA and BW7 Data

HANA Modelling bring in a very important benefits to the BI space, providing additional flexibility for discovery and agile response. However, the need for traditional standardization and structuring is also necessary. The use of HANA and BW7 Modelling depend on specific business scenarios.

Integrating HANA data with BW7 can be achieved with one of the 4 methods: Using BW7 MultiProvider in conjunction with VirtualProvider (HANA Model based) Using BW7 CompositeProvider in conjunction with TransientProvider Using multisource Universe Using merge queries in Webi



Getting Data at its Source: HANA Live As mentioned earlier, HANA is a database. We can run BW on HANA, we can also run ERP on HANA (aka Business Suite on HANA). The clear advantage of this is, we are nearer to the data lesser overheads, more options. In the past, having an OLAP in an OLTP is not recommended due to resource constraints. HANA, however, has removed this hurdle.

Once again the question, should we eliminate BW? The answer: it depends. I can think of one scenario that BW is relevant. Imagine a company archives its ERP tables annually will not be able to perform multi-year sales analysis directly at its source; BW on the other hand, being a staging data warehouse, will contain summarized multiyear information.



Conclusion In the past, ERP is used as a competitive advantage for enterprise-wide effective consolidation. As ERP is becomes a norm for large enterprise, as well as, medium; this advantage has been diluted. The new advantage resides in the data that ERP has collected. With the inclusion of HANA and Businessobjects, the BI landscape is not limited to only Traditional BW7 Modelling and BEx reporting. We are now presented with unprecedented versatility. For instance, we have options between Webi broadcasting capabilities versus traditional EP, BW MultiProvider versus Webi merge queries, BW workspace versus Webi ExcelProvider, and so on. Our challenge now, is how to harness relevant and applicable information that has long been left out in our ERP treasure trove. The emergence of ERP on HANA and HANA Live beautifully brings Analytics back to SAP ERP --- not as a peripheral extension but an intrinsic business process. We should come to the understanding that Analytics is the business process of business processes --- all business processes have KPI and needs to be measured.



Credits and Content Sources 1. SAP HANA Portal

www.saphana.com 2. SAP HANA Technical Operations Manual

help.sap.com/hana/sap_hana_technical_operations_manual_en.pdf

Practitioner Perspective, HANA vs BW7 Modelling

Documents

Transcript of Practitioner Perspective, HANA vs BW7 Modelling