This blog is originally posted on SCN:
There are many materials
out there on SCN discussing the benefit of having BW running on HANA as
database. There is even its own space dedicated to SAP NetWeaver BW Powered
by SAP HANA. In this post I'd like to take a look on these benefits from pure
BW point of view. My motivation is to have arguments for my clients while
considering migration of their BW systems to HANA database. Assumption here is
that no other change/optimization is done while migrating from current DB to
HANA DB.
I hope I captured those
topics discussed below right. However my knowledge of HANA / “BW on HANA” is just
theoretical at this time. Therefore I appreciate your comments and/or correction
to my findings.
1.
New in-memory DB
Once you migrate your BW
from the current DB to HANA DB you get basically new in-memory DB and all its
features right away. This means that without any reimplementation of your existing
data flows you can use power of in-memory HANA engine.
As HANA is in-memory DB
any aggregates, indices and other materialized views on data are not needed
anymore in BW system in most cases.
Means administration and maintenance of whole BW system is easier.
HANA tears down very
consuming DB operations like data loading, DSO activation by its in-memory
nature. I/O operations are faster as it is in-memory DB. Similarly no rollups
on cubes after cube is loaded are needed. Also no Attribute Change Runs (ACR) while
master data were changed are not necessary.
2.
Data Flows/Transformations
There is no need to
migrate your BW 3.x style data flows to 7.x style to run the BW system on HANA
DB. Notice that 7.x data flow is mandatory for HANA-optimized InfoProviders
only. Regarding existing transformations their certain parts of standard data
loading process in BW is accelerated by HANA. Especially in BW
7.4 runs a standard transformation differently than it does in older
releases of BW. System pushes down the transformation processing to HANA
database. However this is only valid for transformations where no custom ABAP
routines are used.
3.
InfoProviders
By running BW on HANA you
get following InfoProvider types. These are not new types of InfoProvs but they
are optimized to be used on HANA.
HANA
optimized DSO - notice that even this is new term “HANA
optimized DSO” it already became obsolete.
Earlier the DSO could have been converted into this type of DSO after migration
to HANA. This is not the case anymore. As of NetWeaver BW 7.30 Support Package
10 HANA-optimized activation is supported for all Standard DataStore Objects by
default. So no conversion needed to Standard DSOs.
With respect to different
Support Pack there are following architectures of DSO:
- As
of BW 7.30 SP05-09: Change Log of DSO is provided
by HANA’s Calculation view. This means there is no persistency of data.
This speeds up data activation and SID creation.
- As
of BW 7.30 SP10: There is database table for Change log. By this we gain
performance while loading the data from the DSO to further InfoProvs as less
resource and memory consumption is achieved.
HANA
optimized infocubes - Within classic BW infocubes there are 2
fact tables (F - normal one and E - compressed one) and several dimension
tables as per cube setup. HANA optimized cubes are flat, there is no dimension
tables and there is only one F table for facts. This means info cubes running
on HANA gain faster data loads, their data model is simplified, remodeling is
easier (e.g. while adding/removing new characteristics/key figure), no changes
to cubes after migration to HANA.
Within BW on HANA cubes
are become even less relevant from data storage perspective. In case there is
no any business logic in place between DSO and cube layer there is no need to
have cube layer. Report can run directly on top of the DSOs. Of course this
needs to be approached by checking data flow one by one. If this is the case
data model gets simplified. Be aware that there are still cases there cubes are
needed. Just to name a few: usage of non-cumulative
key figures in cube, external write access to cube, integrated planning.
4.
New InfoProviders as of BW 7.3
A bunch of new InfoProv
types were introduced in BW version 7.3. Let’s see how they are supported while
BW runs on HANA.
Semantic
Partitioned Object (SPO) – SPO is used to store very large
volumes of data as per partition defined based on business object. There are
two cases depending weather SPO is based on DSO or on cube. In case of the cube
it gets automatically HANA optimized. In case of DSO you may want to convert
SPO to HANA optimized see note: 1685280 - SPO: Data
conversion for SAP HANA-optimized partitions.
CompositeProvider –
Enables combination of InfoProviders of type cube, DSO and Analytic Indexes (like
BWA and Analysis Process Designer (ADP)) via UNION, INNER and LEFT OUTER JOIN.
Such a scenario runs faster in BW on HANA as UNION/JOIN operations are executed
in HANA and not on application server.
HybridProvider –
Used for modeling for near real-time data access. It is combination of two
InfoProv: one for historic data (e.g. cube) and other one for actual real time
data (e.g. DSO loaded via Real Time Data Acquisition (RDA) type of DataSource).
Here same rules apply as mentioned above for cube and DSO: in case of cube it
is automatically HANA-optimized and in case of DSO it stays standard as it was
before HANA migration.
VirtualProvider
–
either based on: Data Transfer Process (DTP), BAPIs or function module are used
for e.g. reconciliation purposes of the data loaded in BW with a normal staging
data flow and the source system. Such a VirtualProv runs in BW on
HANA environment as well.
Other case within
connection to VirtualProv can be with reference to HANA model. By this HANA
model e.g. analytic or calculation view is exposed to BW’s InfoProv.
TransientProvider –
As it has no any persistent BW metadata (nothing visible in BW’s Data Warehouse
Workbench) there is nothing to be optimized by HANA. Actually TransientProv is
used to consume a HANA model (Analytic or Calculation View) which is published
into BW (transaction RSDD_HM_PUBLISH). So if you have some scenarios with TransientProv
it should work in BW on HANA as well.
Analytic
Index (AI) – Is data container in BWA stores the data in
simply star schema format as facts and characteristics (dimensions) with
attributes. The data for AI is prepared by Analysis Process Designer (APD).
Moreover while connecting
of AI to TransientProvider: HANA model can be published in the BW as AI.
TransientProvider is generated then on this AI. While having scenario where
data is being changed very frequently; HANA model is changed also the AI is
adjusted automatically.
Snapshot
Index (SI) – If BEx query is marked as InfoProvider in BWA
an index called Query Snapshot Index (QSI) is created. Such a SI for Query as
InfoProv and SI for Virtual Prov are still supported in BW on HANA.
5.
Process Chains
There are few process
types that are obsolete in BW system running on HANA. These are Attribute
Change Runs (ACR), aggregate roll-ups, cube roll-ups, cube’s index
deletion/creation before/after the load. Existing chains having these processes
will run without errors just those processes will not be executed. However
clean-up is advised to be done after the migration to HANA.
6.
Queries
BEx queries stay as they
are and no change is needed. While query runtime HANA is leveraging column
store and in-memory calculations as engine for query acceleration. The data is
not replicated (e.g. in case of aggregate or BWA) – the query runs directly
against primary data persistence.
Therefore queries should
run at least as fast before HANA migration in BWA but better runtime is of
course anticipated without any changes to queries itself.
7.
Planning
When it comes to SAP BW’s
planning application they traditionally run in BW’s application server. While
HANA in place; planning functions are running in-memory. Therefore with no
change on planning models, planning processes a performance boost is expected
in BW on HANA in areas: dis/aggregation, copy, delete, set value, re-post
operation, FOX formulas, conversions, revaluation etc.
8.
Authorization
Authorization and all
activities related to user access are managed by BW application. Therefore
nothing has changes here while migration to HANA DB. All authorization concepts
used before are being valid and used. Going forward if you will be using also
purely HANA objects (e.g. HANA models: attribute/analytic/calculation views)
these are managed by HANA privileges. They are less detailed comparing to BW
authorization therefore if you need complex authorization you need to consume
HAMA models via BW’s InfoProviders like Transient or Virtual one.
Notice that authorization
must be already using BW 7.x technology prior DB migration to HANA.
Other sources of information on BW on HANA:
