SAP BW on HANA – Basics
SAP BW Powered By HANA:
SAP HANA is an in-memory data platform that is deployable as an appliance that makes full use of the capabilities of current hardware to increase application performance, to reduce cost of ownership, and to enable new scenarios and applications. SAP HANA was designed to run on multi-core CPUs with fast communication between processors and containing terabytes of main memory. With SAP HANA, all data is available in main memory, which completely avoids the performance penalty of disk I/O. Though solid-state drives are still required for permanent data persistency in any case but that does not slows down the performance.
Primary Feature of SAP HANA:
1. In-Memory Technology:
In-memory technology moves data and information sources from remote databases into local memory so the results of analyses and transactions are available immediately.
The elements of in-memory computing has dramatically improved hardware economics and software technology innovations which made it possible to realize the real-time enterprise data with in memory business applications.
2. Row vs. Column Data Storage:
Relational databases typically use row-based data storage. However, column-based storage may be more suitable for some business applications. As shown in the figure below, a database table is conceptually a two-dimensional structure composed of cells arranged in rows and columns. Because computer memory is structured linearly, there are two options for the sequences of cell values stored in contiguous memory locations:
- Row Storage – The data sequence consists of the data fields in one table row.
- Column Storage – The data sequence consists of the entries in one table column.
Traditional databases store data simply in rows. The HANA in-memory database stores data in both rows and columns. It is this combination of both storage approaches that produces the speed, flexibility and performance of the HANA database.
OLAP queries on huge amounts of data take a lot of time because every single row is touched to collect the data for the query response. In columnar tables, this information is stored physically next to each other, significantly increasing the speed of certain data queries. Data is also compressed, enabling shorter loading times.
The following example shows the different usage of column and row storage, and positions them relative to row and column queries. Column storage is most useful for OLAP queries because these queries get just a few attributes from every data entry. But for traditional OLTP queries, it is more advantageous to store all attributes side-by-side in row tables. HANA combines the benefits of both row- and column-storage tables.
3. Multi Temperature Data:
4. Tool Support for converting existing SPOs to HANA-optimized DSOs and InfoCubes (Integrated into standard conversion tool RSMIGRHANADB to ensure consistency during conversion)
5. Partitioning of Write-Optimized DSOs (Write-optimized DSO are now partitioned by request-ID)
Benefits when Using SAP HANA as primary database for SAP NetWeaver BW:
Query Performance is equal to or better than BWA
The query performance is equal to or better than a scenario where SAP NetWeaver BWA is used:
Complex analysis and planning scenarios with unpredictable query types, high data volume, high query frequency and complex calculations can be processed with a high degree of efficiency, as read accesses are in-memory optimized. Query performance on DSO objects is comparable to the performance on InfoCubes as well.
Improved Data Load process on SAP HANA
Load processes in SAP HANA-optimized Data Warehouse objects can be processed with a high degree of efficiency.
Single instance maintenance
The SAP HANA database combines both the traditional database and SAP NetWeaver Business Warehouse Accelerator (SAP NetWeaver BWA), thus helping to cut infrastructure costs. Instead of database administration and additional SAP NetWeaver BWA administration, the SAP HANA database requires just one set of administration tools, for monitoring or backup and restore for example.
Simplified Data Modeling
Data modeling is simplified. Using SAP HANA-optimized objects for example means that it is not necessary to load to a BWA index. Also, aggregates are not necessary when using the SAP HANA database. The column-based database architecture enables easier re-modeling; allowing you for example to delete characteristics from an InfoCube that still contains data. With the improved query performance on DataStore objects, loading data from a DataStore object into a downstream InfoCube can also become unnecessary, if the InfoCube is only created to improve query performance.
Significant compression factor
With its significant compression rate, the column-based storage ensures that less data needs to be materialized. Column-based storage is used for all InfoProviders that save data as well as for the Persistent Staging Area (PSA). With using “SAP HANA-optimized” objects, performance can be improved even further.
Sizing Report for BW on HANA:
Starting with version 7.30 SP5 we can run SAP Business Information Warehouse (SAP BW) on SAP HANA as database platform. This enables us to leverage the In-Memory capabilities of HANA and the SAP-HANA-optimized BW objects.
To estimate the resource requirements of the SAP HANA In-Memory Database, a set of database-dependent scripts has been provided which analyze the database dictionary and compute the size of the relevant source database tables. Please refer to note 1637145 for more details. To simplify sizing of an SAP BW system that is supposed to be migrated, SAP now provided the database independent ABAP report /SDF/HANA_BW_SIZING which computes all information relevant to sizing a HANA database server.
Features of SAP HANA-Optimized DataStore Objects (Accelerated Data Loads)
Delta calculation completely integrated in HANA
Using in-memory optimized data structures for faster access
No roundtrips to application server needed
Process of SID generation highly optimized for HANA Optimized DSOs; low impact on staging performance
Speeding up data staging to DSOs by factor 5-10
Avoids storage of redundant data
After the upgrade to BW on HANA all DSOs remain unchanged
Tool support for converting standard DSOs into SAP HANA-optimized DSOs
Features of SAP HANA-Optimized InfoCubes (Faster Data Loads and Easier Modeling)
Traditional InfoCubes tailored to a relational DB consist of 2 Fact Tables and the according Dimension tables
SAP HANA-optimized InfoCubes represent “flat” structures without Dimension tables and E tables*:
Up to 5 time’s faster data loads (Creation of DIM Ids no longer required)
Simplified Data modeling
Faster remodeling of structural changes
After the upgrade to BW7.3, SP5 all InfoCubes remain unchanged
Tool support for converting standard InfoCubes (Lab result: 250 Million records in 4 minutes)
No changes of processes, MultiProvider, Queries required
Query Performance (Query Performance at Least as Good as with BWA)
Query acceleration on BW InfoCubes:
Leverage column store and In-Memory Calculation Engine for query acceleration
No replication – fast query access directly on primary data persistence
Indexes on InfoCubes and InfoObjects no longer required
No Rollups, Change runs
Query acceleration on BW DataStore Objects:
Leverage column store and In-Memory Calculation Engine for query acceleration
SID generation during DSO activation to be enabled
Result: Same kind of excellent query performance on DSOs
Process of SID generation highly optimized for HANA Optimized DSOs -> low impact on staging performance
Cases where InfoCubes are still required?
Non-disruptive approach when migrating to BW on HANA
Non-cumulative Key Figures
Complex business logic (report specific)
BW Integrated Planning
External write-interface (RSDRI)
Prerequisite checks for SAP BW on HANA migration
a) SAP HANA requires Unicode
b) Perform SAP HANA hardware check (SAP note 1658845 – Recently certified SAP HANA hardware)
c) Perform hardware sizing (Using report /SDF/HANA_BW_SIZING)
d) Identify which ABAP statements will be optimized for SAP HANA (SAP Note 1847431 – SAP NetWeaver BW ABAP Routine Analyzer)
e) Perform the Pre-Activity Steps for BW Environment which includes:
i. Clean the PSA which are not required
ii. Delete the Aggregates as those will not be needed again
iii. Compress the Fact tables of InfoCubes to reduce data volume
iv. Delete data from the Statistical Cubes (starts with 0CTC_*) using T-Code RSDDSTAT or the program RSDDSTAT_DATA_DELETE
v. Remove data in unused DSOs, InfoCubes and files used for staging in the BW system
vi. You may also want to clean up background information stored in the table RSBATCHDATA. This table can get very big if not managed
vii. You should also consider archiving any IDocs and clean the tRFC queues.
viii. Use the program RSDDCVER_DIM_UNUSED to delete any unused dimension entries in your InfoCubes to reduce the overall system size
SAP HANA Migration Approach:
Three options exist for implementing BW on SAP HANA.
1. The easiest option: Create a totally new BW instance, and connect it to the SAP HANA database.
2. A more complex option: Upgrade an existing BW system to version 7.3 SPS5, then change the underlying database from a traditional disk-based relational database to the new in-memory HANA system.
3. The most popular option: Keep the existing production BW system running on a traditional database while you copy the production BW system to a new BW system. Then, migrate the copied BW system to a HANA database to reduce downtime in your production landscape.
HANA Migration Testing Approach:
Phase 1: Technical Tests of SAP HANA
Phase 2: End-to-End Functional Tests
Phase 3: End-to-End Performance Tests
Obsolete BW Process Types for SAP HANA Database:
The following process types are not needed when using SAP HANA database:
o Initial Filling of New Aggregates
o Rolling Up Filled Aggregates/BWA Indexes
o Adjust Time-Dependent Aggregates
o Construct Database Statistics
o Build Index
o Delete Index
BWA vs. SAP HANA
I> SAP released the BW Accelerator (BWA) as a side-by-side in-memory appliance to accelerate query performance for BW reporting. From a reporting perspective, it appears that BWA provides the same functionality as BW Powered by HANA
II> Only a subset of data can be accelerated, and additional effort is required to replicate that data from the BW relational database to BWA. With BW on HANA, all data is automatically held in memory, which makes reports run much faster without any additional work.
III> BWA is no longer a requirement, which simplifies the IT landscape. Furthermore, with BW on HANA, data loads within a BW system are accelerated. This means the entire data provisioning process is much faster, not just the reporting on top of individual InfoProviders.
IV> BWA does not help to speed up planning processes nor does it support easier data modeling and remodeling; however, BW on HANA provides significant improvements in those areas.