Companies typically implement SAP HANA to enhance their system’s performance and to process voluminous amounts of data. When companies evaluate their performance, they generally identify specific areas that need improvement; most commonly, query performance, data loading, and software add-on/application performance. Below we provide examples of how in-memory computing both enhances the performance and accelerates applications.
SAP BW 7.3x offers a substantial number of improvements over traditional RDBMS configurations. Some of these improvements also reduce both administration costs and total cost of ownership (TCO). With each release, SAP BW introduces new innovations to better support customers’ business operations.
Over the past decade, the amount of data that businesses need to query and analyze has grown exponentially. Unfortunately, as we’ve already discussed, relational databases were not designed around multidimensional data models in the EDW. To overcome the limitations of the transactional-based databases, EDW systems incorporated functionality — aggregates, fact tables, and other features — into the LSA model. Today, however, the availability of columnar databases and in-memory technologies has made these additional elements obsolete. In 2005, SAP introduced the SAP BW Accelerator as a query accelerator. As SAP BWA matured, SAP provided additional engines and features. Specifically, SAP BW on SAP HANA has incorporated the query acceleration and engines from the BWA, along with other valuable columnar database features.
As with the SAP BW Accelerator, performance is one of the key drivers for in-memory computing. In-memory computing improves performance in a number of areas. From the end user perspective, query response time is often one of the primary elements in system performance. SAP BW Accelerator delivered approximately 100 times the query performance compared to a relational database alone. SAP BW Powered by SAP HANA provides similar results for end user query response times. Of course, customer results have varied and will vary based on configuration and content. Some customers have reported query performance, greater than SAP BWA. The general rule, however, is to expect similar query performance.
In an SAP BW with SAP BWA implementation, customers have to maintain two systems. This is one area where this architecture can reduce both TCO and administration costs. Further, when companies utilize an SAP BWA appliance, they must obtain separate licenses for the relational database and for SAP BWA. They also need to maintain two sets of hardware and data. In contrast, implementing SAP HANA as the database for SAP BW involves only a single hardware appliance and license model. From an administration point of view, then, the customer no longer needs to manage multiple data sets. By reducing redundancy, improving data lifecycle management, and eliminating hardware and license duplication, SAP HANA dramatically reduces a company’s TCO.
Figure 1: Migration from SAP BW & BWA to SAP BW on SAP HANA
Figure 2: SAP BW on SAP HANA Architecture
In contrast to SAP BWA, SAP HANA provides much more functionality to the SAP BW than simply query acceleration. In the business environment for many SAP customers, the need for real-time or near real-time data reporting has dramatically increased. With their existing systems, the time required to extract data from a source system is fairly static and predictable; it generally comprises about 20% of the data load process. The remaining 80% is spent on data activation and updates. This is where the intelligence and deep integration of the SAP HANA appliance and the hardware are able to reduce this time considerably.
Figure 3: In-Memory Execution in SAP BW
The process of data activation requires business logic from the application to perform activation actions on the data updates. When this business logic exists entirely in the application, potentially millions or billions of round trips occur between the database server and the application server. With SAP HANA, the business logic for the activation is passed to the SAP HANA appliance along with the data. This arrangement reduces the number of round trips between SAP BW and the SAP HANA appliance to only a few. When SAP was tested, the data-loading improvement was 10 times that of an RDBMS alone. Customers have reported improvement rates ranging from 6 times to more than 20 times. Of course, the actual customer performance is dependent on a number of factors. Overall, then, we can safely use an average of 6 to 10 times as a guideline.
Figure 4: SAP BW on SAP HANA DSO Acceleration
By utilizing the enhanced data-loading and analytic capabilities of SAP HANA, customers have been able to provide their businesses with more rapid results to data and analytics use cases. In addition, the reduced load times enable them to run updates and analysis operations more often without severely affecting SAP BW operations. Many IT departments currently have severely limited windows for regular updates due to the global nature of business operations. By reducing data-loading times, SAP BW and SAP HANA enable IT operations to provide greater support to the business.
As mentioned earlier, EDW systems added specific functionality to enable the RDBMS to process analytic operations on vast amounts of data. SAP HANA makes it possible for users to eliminate many of these artifacts, thereby making the data model more efficient. This process is known as “flattening” the LSA model. SAP BW 7.3x delivered programs to convert existing data store objects (DSOs) and info cubes into SAP HANA-optimized DSOs and info cubes. While the old structures continue to operate with SAP HANA as the database, the performance is improved by converting to the SAP HANA- optimized structures.
Figure 5: Conversion of SAP BW Data Structures
In this new structure, the most common question is whether info cubes are still needed. The answer is that SAP HANA still utilizes info cubes, but their role and use are more defined. Customers have been able to reduce the need for info cubes dramatically and report directly against a DSO. In general, info cubes are utilized only in certain specific scenarios:
(1) when multiple DSOs are consolidated,
(2) when additional transformations are needed, or
(3) when an add-in application requires an info cube for specific operations.
The lighter LSA model structure that allows for more flexibility makes data modeling easier and more efficient. This efficiency generally leads to a further reduction in TCO, although quantifying these savings is problematic.
There are a number of add-in applications for SAP BW, including Strategic Enterprise Management (SEM), Integrated Planning (BI-IP), and Corporate Performance Management (CPM). As with data-activation processes, these applications utilize a complete business logic as an integral part of the solution. When the application server has to host the business logic, the number of round trips to the database server can be extremely large. These add-in applications are now being “HANA-fied” to fully utilize SAP HANA to process the business logic inside the database rather than up in the application layer. The result is a much improved performance from multiple areas within the application.
Figure 6: Planning in SAP BW on SAP HANA
SAP BW 7.30 SP8 and SAP HANA SP5 have delivered new efficiency and flexibility capabilities. As database sizes in SAP BW landscapes have increased, SAP has been re-evaluating which data need to be in memory — that is, “active” data — and which data can be loaded as needed — that is, “non-active” data. Significantly, SAP has configured SAP BW 7.30 SP8 and SAP HANA SP5 to flag all PSA tables and write-optimized DSOs as non-active. Consequently, the non-active data will remain on disk persistence until they are needed. In addition, they will be the first data to be flushed from memory when they are no longer needed. Customers who have implemented these new systems have reported that SAP HANA memory utilization has been reduced by roughly 20%.
In addition to the features discussed above, SAP has incorporated greater flexibility in utilizing SAP HANA data models with native SAP BW models. Some of these innovations provide a database connect (DB connection), virtual provider, transient provider, and open hub services to consume SAP BW and SAP HANA data. This flexibility allows for maximum options in data consolidation and reporting.
Figure 8: Open Hub Services