POV: HANA’s impact on ABAP Programming
What is HANA?
HANA (High performance Analytical Appliance) is a new In-Memory data management appliance released by SAP which is more of separate plug-in (Software & Hardware) for faster analytical activities. This application allows processing of massive quantities of real time data in the main memory of the server to provide immediate results for analysis.
HANA is a pre-configured analytic appliance. SAP’s hardware partners provide the hardware and pre-install the SAP in-memory solution on that hardware.
How does it work?
Data is replicated from SAP or Non-SAP sources into HANA. For SAP Business Suite, there is a Replication Server & Agent that come along with HANA to transmit the data. For Non-SAP, Business Objects DATA Services tool can be used to replicate the data into HANA.
HANA has a Row store and Column Store for storing the data in relation and columnar format respectively. Columnar database is proven concept for high performance analytics. Introduction of calculation and aggregation engine at the database level is a huge advance in processing.
SQL and MDX processors are responsible for parsing SQL and MDX query requests and processing them.
HANA currently supports few clients like BO Explorer, Microsoft excel etc.
SAP HANA Studio is front-end which facilitates Data Modelling and administration.
Does HANA support ABAP Programming?
HANA 1.0 doesn’t support ABAP. It supports few clients like SAP BWA (BW Accelerator), Microsoft Excel, SAP Business Object Analysis, MS Edition for Office. HANA 1.5 will support ABAP Programming/reporting which would mean that ABAP developers can write code to read/modify data in HANA Appliance.
Will HANA impact ABAP Programming style?
Traditional ABAP Programming style is more inclined towards reducing the load on Database and shifting the processing to Application server. This is more to do with Data Storage models and SAP 3-tier system architecture provided another layer for data processing. This restricted ABAP developers to confine to the concept of “pulling required data to Application server and processing data in App Server” and along came the complexities of buffering.
With the introduction of HANA, data is available in volatile memory so data can be retrieved and processed in same “memory”. At first thought, this gives a feeling that ABAP OpenSQL Programming style should be changed and some of the “banned” OpenSQL statements like ‘Order By’ etc should come back in to use. Well, Hold on!! Let’s not jump into conclusions, let’s analyze some specific scenarios from HANA perspective and decide on this –
- Scenario-1: There is a database table with 50 records in it and you wish to read the table 1000 times for values based on field F1.
- Non-HANA: Since the database table is relatively small in size, make a copy of the table in your program and then read the desired record as and when required.
- With HANA: Read data from database table as and when required and process it. Remember, with HANA query and data processing is happening at the same place!!!
- Scenario-2: Let’s consider opposite scenario to Scenario-1. There is a database table with 10000 records in it and you wish to read the table 100 times for the values based on field F1.
- Non-HANA: Since the database table is very large, it’s better to use SELECT SINGLE than porting the entire table into an internal table.
- With HANA: Same as in Non-HANA read data from database table as and when required and process it. The only advantage here is there is no network traffic with every query as query and data processing is happening at the same place!!!
- Scenario-3: Joins Vs Nested Select statements
- Non-HANA: Join is the most preferred way to fetch data from two tables instead of nested select statement. No second thoughts about it from OpenSQL perspective.
- With HANA: Join has its own advantages and Nested select has its own advantages from Relational database perspective. With HANA, the decision to use Join Vs Nested select statement depends on further requirements. If any intermediate processing has to be done, nested select is better than join.
- Scenario-4: Optimize the cost of database searches
- HANA or No-HANA, the cost of database search should always be optimized and concept of index is extremely important
- Scenario-5: Table buffering
- SAP provides buffering facility to increase performance. Since buffers reside in Application server it takes considerably less time to read data locally than reading it from database.
- With HANA, no additional table buffering is required as all the database resides in volatile memory.
- Scenario-6: ABAP Sort Vs Order by clause
- Non-HANA: Optimized solution is to use ABAP Sort and reduce load on Database server
- With HANA: It really doesn’t matter. Both the statements should be equally good or bad.
After analyzing some of the basic programming scenarios, programming with HANA seems to be a complete different world that ABAP developers should watch out for. While the database programming best practices still hold, developers will have the flexibility to utilize data processing statements which were considered expensive without HANA. Another completely new dimension to ABAP Programming will be columnar database concept which is also a part of HANA appliance.