10 Years of “No Aggregates” in #SAPBW
Cleaning up the hard drive of my laptop this week I’ve come across a number of documents that reminded me that in spring 2004 we – i.e. the BW and TREX development teams – had the first version of the BWA up and running internally. Then, it still was project Euclid. Later that year, Euclid was presented publicly at Techeds in San Diego and Munich – see also Fig. 1. Euclid paved the way to SAP’s first commercial in-memory product, the BW Accelerator (BWA). The BWA was first shipped with NetWeaver 2004s (i.e. BW 7.0). It removed the need to define and maintain aggregates, i.e. materialized aggregations (group-by’s and filters). At that time, BW’s change run – the process that adjusted aggregates to master data changes, like changes in attributes and hierarchies – was one of the top-3 critical processes in almost every customer installation.
Fig. 1: “High Performance BI” (aka BWA) as explained by Shai Agassi in his keynote at Teched San Diego in 2004.
One of the first customers adopting BWA simply upgraded from BW 3.5 to BW 7.0 leaving everything in place but added BWA to his BW system. Thus, there was no change to the end user but the power of BWA. They reported the following effects:
- more than 90% of queries on indexed cubes ran faster than before
- one third of queries saw response time cuts by more than half
- the average query runtime was cut by two thirds
Those impressive improvements in query performance translated into a better usage of their BW system. As adding BWA was the only change that improved usage could be attributed to the improved query run times:
- the number of query runs per week increased by over 60%
- over two thirds of the queries saw an increased usage
One other episode came from a European customer ordering a BWA instance for a proof-of-concept to then not allow the hardware vendor to remove the BWA as they wanted to keep and use it immediately. Since then, 1000+ BWAs have been installed and nowadays, BW-on-HANA basically runs a “BWA within” providing even better query performance w/o aggregates and removing the need to synchronize a standard RDBMS and a BWA as “all (i.e. RDBMS and BWA) is one”, namely HANA.
Aggregates usage has significantly declined over the years despite significant growth rates of around 15-20% for BW installations per year. Fig. 2 shows how the number of aggregates-related support tickets raised by BW customers has decreased by 60% over the course of 8 years while the number of BW installations roughly tripled. Oddly, some people still talk about aggregates in the context of BW, even 10 years after their way out started. Those comments are trailing 10 years behind the fact.
Fig. 2: Number of support tickets related to BW aggregates. Number of tickets in 2006 = 100%.
This blog has been cross-published here. You can follow me on Twitter under @tfxz.
I've one query over here which is freaking since from long time related to BWA & BW aggregates.
actually my concern 😕 is if we use BWA with parallel to the BW system the one which you've shown in Fig 1 then BW aggregate will not come into picture...?
how exactly this BWA, Aggregates & changes runs to master data are interlinked if you know any relevant OSS note or Blog please share so that i can resolve all my 😕
the BW change run is basically the process that sets changed master data active with all its consequences. In the presence of BW aggregates that might mean that aggregates involving navigational attributes or hierarchy-based filter etc needed to be adjusted. In case of the BWA, the change run transmitted the changed master data from the RDBMS underlying the BW to the BWA which is a fairly simple, non-critical task. I think you look at the link to the official documentation. It's the link in the blog.
I hope this helps.