SAP HANA 1.0: Overview - Use HANA with BI 4.0

What is SAP HANA? Introduction and Overview of SAP HANA

The BW - HANA Relationship

Posted by Thomas Zurek 

With the announcement of HANA*, some customers, analysts and others have raised the question on how HANA relates to BW with a few of them even adding their own, home made answer in the sense that they speculate that HANA would succeed BW. In this blog, I like to throw in some food for thought on this.

Currently, HANA's predominant value propositions are

• (i) extremely good performance forany type of workload

• (ii) a real-time replication mechanism between an operational system (like SAP ERP) and HANA

Let's match those for a moment with the original motivation for building up a decision-support system (DSS) or data warehouse (DW). In the 1990s, a typical list of arguments in favour of such a system looked like this:

1. Take load off operational systems.
2. Provide data models that are more suitable and efficient for analysis and reporting.
3. Integrate and harmonize various data sources.
4. Historize - store a longer history of data (e.g. for compliance reasons), thereby relieving OLTPs from that task and the related data volumes.
5. Perform data quality mechanisms.
6. Secure OLTPs from unauthorized access.

Installing a DW is typically motivated by a subset or all of those reasons. There is a particular sweet spot in that area, namely a DW (e.g. an SAP BW) set up for reasons 1. and 2., but with all the other arguments not being relevant as it is connected to basically one** operational system (like SAP ERP). Here, no data has to be integrated and harmonized, meaning that the "T-portion" in ETL or ELT is void and thus that we are down to extraction-load (EL) which, in turn, is ideally done real-time. So value proposition (ii) comes along very handy. Critics will argue that such systems are no real data warehouses ... and I agree. But this is merely academic as such systems do exist and are a fact.  So, in summary, there is a good case for a certain subset of "data warehouses" (or reporting systems) that can be now built based on HANA with (i) and (ii) as excelling properties - see the top left scenario in figure 1 below.

Now, will this replace some BWs? Yes, certainly. In the light of HANA, a BW with a 1:1 connection to an ERP might not be the best way anymore. However, will this make BW obsolete in general? No, of course not. As indicated above: there is a huge case out there for data warehouses that integrate data from many heterogenous sources. Even if those sources are all SAP - e.g. a system landscape of multiple unharmonized ERPs, e.g. originating from regional structures, mergers and acquisitions - then this still requires conceptual layers that integrate, harmonize and consolidate huge volumes of data in a controlled fashion. See SAP NetWeaver BW: BW Layered Scalable Architecture (LSA) Building Blocks for a more comprehensive discussion of such an approach. I sometimes compare the data delivered to a data warehouse with timber delivered to a furniture factory: it is raw, basic material that needs to get refined in various stages depending on the type of furniture you want to produce - shelves might require less steps (i.e. "layers") than a cupboard.

Finally, I believe that there is an excellent case for building a BW on top of HANA, i.e. to combine both - see the bottom right scenario in the figure below. HANA can be seen as an evolution of BWA and, as such, this combination has already proven to be extremely successful: Understanding Query Performance in NW BI and BIA have been in the market for about 5 years,SAP BW 7.3 beta is available albeit mainly focusing on the analytic layer of BW (in contrast to the DW layer). When you continue this line of thought and when you assume that HANA is not only BWA but also able to comply with primary storage requirements (ACIDetc.) then the huge potential opens up to support, for example,

• integrated planning (BW-IP): atomic planning operators (used in planning functions) can be implemented natively inside HANA, thereby benefitting from the scalability and performance as seen with BWA and OLAP and also from avoiding to transport huge volumes of data from a DB server to an application server,
• data store objects (DSOs): one can think of implementing such an object natively (maybe as a special type of table) in HANA, thereby accelerating performance critical operations such as the data activation.

This is just a flavour of what is possible. So, overall, there is 4 potential and interesting HANA-based scenarios that I see and that are summarized in figure 1. I believe that HANA is great technology that will only come to shine if the apps exploit it properly. SAP, as the business application company, has a huge opportunity to create those apps. BW (as a DW app) is one example which has started quite some time ago on this path. So the question on the BW-HANA relationship has an obvious answer.

---

* High Performance ANalytic Appliance
** The case remains valid even if there are a few supporting data feeds, e.g. from small complementary sources.

---

Figure 1: How HANA can potentially evolve in existing SAP system landscapes ... in a non-disruptive way.

How to convert Classic Infocube/DSO to HANA optimized cubes/ DSO

Posted by Isha Gupta 

We can convert Standard info cube into In-Memory info cube by using  the Report “RSDRI_CONVERT_CUBE_TO_IN-MEMORY ”. Or Call transaction RSMIGRHANADB directly. To add the option of conversion of DSO also in the same program/T-code we can add the parameter ENBL_HDB_MIGR_DSO = X in RSADMIN Table.

During a conversion a lock is set, preventing all maintenance activity and load processes.The conversion is executed as a Stored Procedure within HANA and therefore shows an excellent performance.

During conversion DataStore objects are not available for reporting / staging. Querying on the InfoCubes is however possible during this time.

After migration to the SAP HANA database, normal standard InfoCubes are in the SAP HANA database's column-based store and have a logical index (Calculation Scenario). In the analysis, they behave like BWA-indexed InfoCubes.If the InfoCubes have data persistency in BWA, the content is deleted during the system migration to HANA and the InfoCubes are set to inactive. If you want to continue using one of these InfoCubes as a standard InfoCube, you need to activate it again and reload the data from the former primary persistence (DataStore object for example).

We can make DSO as an In-Memory based DSO only if it is of Standard type.  Also Standard DataStore objects can be converted into SAP HANA-optimized DataStores only if:

1) The DSO is not included in a BW 3.x data flow (for example, by using update rules).
Exception: If you use the BW 3.x data flow only on an inbound basis (but not on an outbound basis), you can still convert the DataStore. However, in general, we recommend that you migrate the old data flow before converting the DataStore. See: http://help.sap.com/saphelp_nw73/helpdata/en/8d/6b1b58cc1744e1b</p><p>ce7898a50e19368/frameset.htm

2) DSO is not supplied by real-time data acquisition. Since small data volumes are usually produced for each activation step when data is supplied by RDA, RDA-supplied DataStores do not benefit in the same way as staging-supplied objects. Continue to use classic DataStore objects for this use case instead.

3) DSO is not part of a HybridProvider or a semantically partitioned object (SPO).You can recreate SPOs based on SAP HANA-optimized DataStore objects

Different options available for DSO migration:

1) Simple Migration:  Only Active data gets converted and change log history gets deleted. Conversion is faster and requests cannot be rolled back after migration.

2) Full Migration: Active data gets converted along with change log history. Conversion is slower but there is no restriction on rollback of requests.

Why BW and HANA are such a good combination

There has been much talk and debate on whether HANA replaces BW. See Steven Lucas’s blog, the associated comments, discussions on Linkedin or Twitter (e.g. start somewhere around here) or some blogs (e.g. this one) and probably many other places. The sheer number and heat of those threads indicates, in my opinion, that the question is so relevant that it underlines how relevant BW is.

Figure 1: An EDW comprises a DB that is complemented with a application code (X).

Now, a lot has already been said about the matter. The origin of the controversy has a little bit to do with the perception that an enterprise data warehouse (EDW) basically is an DBMS. Actually, in a discussion with some well known analysts some time ago I popped the question whether they would see a difference and met a few seconds of silence. In my opinion, a DBMS is a fundamental component of a EDW, like an engine to a car. But the DBMS alone makes no EDW like an engine alone makes no car. The car’s chassis, body, interior, … provides the comfort for the consumer and makes sure that the engine is used in the most suitable way. Similarly, there is software surrounding a DBMS that makes it the heart of a EDW. BW is simply one such instance of software that can do that. Figure 1 shows a slide that I frequently use to create that awareness.
Why is BW such a good choice – in my opinion – to make HANA the heart of a EDW? Rather than answering this in a generic, philosophical and potentially non-tangible way I will give three instances that clearly underline that statement:

1. BW has the most capable code generator (for queries) to leverage HANA’s calculation engine in the most efficient way. Even experts will struggle to emulate this by handcrafted code. The trick is to issue a graph of related calculation instructions whose dependencies are in the calculation semantics (of an OLAP query) and exposed to the calculation engine which, in turn, can leverage that knowledge to optimize the processing. “Hello World” style or simple, SQL-style queries won’t see a notable difference but queries with calculations beyond a single row (YTD, hierchies, currentmember, normalizations to group totals, group-specific aggregations, …) will and these are neither esoteric nor rare but mainstream.
2. Changes in BW are creating the right context that allow HANA to process load operations in a way that translate into overall accelerations of factor 3 (on average) for process chains. Instances are translating single row to mass data operations or the HANA optimized versions of infocubes and DSOs. In fact, I’ve seen customer measurements that indicate that many process chains only yield equal performance (compared to classic DBMSs) but improve significantly by using the HANA optimized infocubes and DSOs.
3. In autumn, both, BW and HANA, are planned to ship a mechanism to distinguish between hot (= permanently used / queried), warm (= sporadically, e.g. in nightly batch processes) and cool (= rarely used, e.g. old requests in PSA) data. This is will translate into a significantly better usage of HANA’s memory, similarly as if the data compression algorithms were to yield higher compression rates. As the roles and semantics of tables in BW are well known they can be easily classified by a default configuration which means that a BW-on-HANA system will use HANA by default more effciently than an operational data mart where such settings can also be done but need to be set and derived manually.

This list can certainly be extended. It is meant to provide a non-marketing, down-to-earth flavour of what you gain with BW beyond the usual services. It is not surprising that some customers have lauded it the most genuine application on and for HANA that SAP provides.

All about SAP HANA – composite post

I'm very well aware that there are already initiatives to get all information about HANA into single place. Therefore consider this blog as yet another HANA blog.

As I started similarly with SAP BW 7.3 I try to collect all relevant information sources about in this case SAP HANA here. BTW: What’s HANA? In short it is in-memory solution from SAP. It stands for High-Performance Analytic Appliance and basically it is appliance (plus its software components) that can absorb large volumes of data (e.g. tera bytes) into its “operational” memory. The reason why it is so high performant is that all the data is in memory not stored in hard drives. It can be set up on top of SAP ERP or BW system (plus non SAP databases) without necessity to materialize data via transformations as in contrary to current DWH solutions. HANA bundles several components: in-memory computing engine, real-time replication service, data modeling and data services. As it is delivered as appliance it is depended currently on few vendors are supported: Fujitsu, HP, and IBM.

Basically we can say that HANA successor of SAP NetWeaver BW Accelerator as moving forward into in-memory computing. Here HANA acts as persistence mechanism for SAP NetWeaver BW.

HANA components:

1. The core of HANA is called SAP In-Memory Computing Engine (IMCE or ICE, also called as NewDB or BAE). It is an engine kind of in memory database which uses row/column/object based database technology to store data. It is for parallel data processing using state-of-the art CPU possibilities.

2. HANA Studio (client app, or Studio Repository, Eclipse based editor connected to a HANA
Server backend) consists of:
2.1 Administration console - administer and monitor database
2.2 Information modeler - data modeling
2.3 Lifecycle mngt - provides an HANA stack update using SAP Software Update Manager (SUM)

3. HANA Load Controller -resides in SAP HANA, coordinates the entire replication process: It starts the initial load of source system data to the IMDB in SAP HANA, and communicates with the Sybase Replication Server to coordinate the start of the delta replication

4. Host Agent -handles login authentication between source system and target system

5. Sybase Replication Server -accepts data from Replication Agent, distributes and applies this data to the target database using ECDA/ODBC for connectivity.

Current versions:
SAP HANA 1.0 SP02 - as of 12th June 2011 in general availability


Operating system: //only following one:
64-bit SuSE Linux Enterprise Server (SLES) 11 SP1 operating system

Upcoming version:
Nov 2011 - SAP starts rump up program for their customers to run BW-on-HANA as its database

Read more at : http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/28011