When you start reading SAP-related publications, it is very hard to find any article that does not mention the word HANA. Especially when you focus on business intelligence, you hear very little about alternative solutions, until today.
In the past months, we have assessed the pros and cons of implementing IBM DB2 with BLU Acceleration on the BW system at one of our customers. For them, it was the perfect layover on their journey from a traditional BW to a state-of-the-art in-memory analytics platform.
To fully appreciate the SAP HANA offering against its competing products, one must first appreciate the difference between an in-memory database and a database with in-memory technology. The former means that the data is always processed in RAM. Data is directed to disk only for secondary purposes, most importantly data preservation in case of outages.
Databases with in-memory technology do the reverse. They are in fact the old-fashioned RDMS-es as we know them. Data is first moved to disk, and from there it propagates to the in-memory areas. At a glance, the two may appear very similar, but in fact, the concept is fundamentally different.
The emphasis in the HANA design is to converge online analytical processing (OLAP) and online transaction processing (OLTP) into one. The design advantage of using an in-memory database is that cache and disk latency is eliminated, and OLAP and OLTP activities can take place in parallel in real time.
BLU is the in-memory acceleration technology in IBM’s DB2 databases. It utilizes several techniques like a column-based organization of data, data compression, parallel data processing optimizations (SIMD) etc. IBM’s DB2 BLU Acceleration takes advantage of a system design where CPU, memory, and I/O are blended in an optimized way.
The data compression in DB2 BLU can process the data more efficiently than SAP HANA, as it does not need to decompress the data prior to reading it. Leveraging its data-skipping technology, DB2 BLU can locate the data blocks of interest and decompress them when needed.
Enterprises that want to merge their OLTP and OLAP into one common environment for real-time decision making, would likely be well served by adopting to the HANA platform. Since all data that is being created is readily and instantly available for reporting, there is no longer a latency, nor is there a need for replication.
Regarding in-memory, BLU and HANA quite comparable to what they have to offer. The table below shows the similarities in their engines.
The examples given by many of our customers may seem obvious, but they have become more relevant than ever: now there is a way to address these concerns faster and more efficiently!
Better visualizations for improved insight?
Open platform to enable third-party tools like Spotfire or Tableau?
Availability on the iPad?
Faster month-end closure?
Live prototyping and operational reporting?
Single point of truth?
Big data reporting?
Lowered TCO of IT assets?
Scattered landscapes (no single point of truth)?
24/7 system data availability (continuous data loads)?
Move to the cloud?
Advanced analytics (predictive)
Cross-platform and cross-system analytics?
Self-service concepts in reporting?
New reporting tools, e.g. Lumira
Optimized SAP Business suite for HANA
Optimized data warehouse: code pushdown (AMDP)
Integration of OLTP and OLAP environments
Fiori/HTML5 user experience
Multi-tenancy (multiple DB instances on one server)
Multi-tiering (offloading warm and cold data)
Access anywhere anytime
The questions of the previous paragraph boil down to the following set of capabilities. The background color indicates which platform can deliver the capability.
Here it becomes clear that HANA delivers a complete platform and not just some accelerated database platform and optimized storage solution. Depending on needs and budget however, BLU may just offer the right set of capabilities to either fulfill all the requirements or to bridge the period until a full HANA migration is possible.
The hardware requirements for implementing DB2 BLU are quite modest compared to SAP HANA. It may even be possible to implement it on an existing set of hardware.
Especially because not all data needs to reside in memory, a lower amount of RAM can still offer much better performance over a traditional setup.
HANA is an enabler, DB2 BLU an accelerator
Both offer state-of-the-art technology for in-memory reporting
Either one will significantly accelerate the analytical performance of the BW ecosystem
HANA also addresses the many business questions, not just the technology parts
The user growth and data growth can be mitigated with the better performance and data compression
BLU is not a real-time solution
DB2 BLU does not solve the inherent latency between OLTP and OLAP that makes real-time reporting difficult
BLU puts most-used data in cache, HANA preloads all.
The former balances better on smaller footprint systems
The latter responds better to real-time out-of-the-blue questions
BLU now does not eliminate HANA later
BLU will certainly bring a boost to reporting performance, taking the heat off some of the bottlenecks
The business questions still need addressing, e.g. self-service, mobility, predictive
It may even be the perfect bridge between traditional OLAP and modern in-memory
The SAP roadmap clearly states the future is HANA, both for their ERP and their analytical suite
New features will rely on HANA more and more
Client tools and connectivity
SAP’s own BI Suite with native connectors (Lumira, Design Studio, Analysis for Office)
Likewise, third party applications all have HANA connectors, e.g. Spotfire, Tableau, Qlik and MicroStrategy
HANA has open standards support for ODBC, JDBC, ODBO and MDX as well as a raw SQL client, hdbsql
Interested in the features of SAP HANA and or IBM BLU and how it can help your organization to improve? Feel free to contact us.