SAP® BW auf HANA
Frank Riesner Klaus-Peter Sauer
INHALTSVERZEICHNIS
3
Inhaltsverzeichnis
Vorwort 7
Danksagung 11
1 Evolution und Überblick 15
1.1 Evolution von SAP HANA 15
1.2 Evolution von BW 21
1.3 BW auf HANA versus BWA 31
2 Vorbereitung der Umstellung auf HANA 35
2.1 Sizing 35
2.2 Migrationsoptionen und unterstützende Werkzeuge 44
2.3 Housekeeping 58
2.4 Betrieb im Rechenzentrum 63
2.5 Data Lifecycle Management 98
3 Änderungen bei der Datenbewirtschaftung 113
3.1 Generisches BW-Delta 113
3.2 DB Connect 115
3.3 Operational Data Provisioning 116
3.4 In-memory Data Fabric 129
4 Modellierung in SAP BW auf HANA 135
4.1 Änderungen an bestehenden InfoProvidern 136
4.2 SAP-HANA-Modellierung 163
4.3 Neue InfoProvider 174
4.4 Anwendungsszenarien 199
4.5 SAP-BW-Optimierung durch HANA 223
INHALTSVERZEICHNIS
4
4.6 Berechtigungen 238
4.7 Prozessketten 243
4.8 Obsolete Modellierungsfunktionen 246
5 SAP-BW-Referenzarchitektur 249
5.1 Layered Scalable Architecture klassisch 250
5.2 Layered Scalable Architecture auf HANA 254
5.3 Umwandlung einer LSA in LSA++ 259
6 SAP HANA Live 265
6.1 Motivation und Ziele 265
6.2 Virtuelles Datenmodell 268
6.3 Werkzeuge 273
6.4 SAP BW versus SAP Hana Live 279
7 Zusammenfassung und Ausblick 283
7.1 Wie Sie von BW auf HANA profitieren 283
7.2 BW auf HANA im Vergleich zu anderen Datenbanken mit In-Memory-Funktionen 291
7.3 BW Roadmap – der Blick in die Zukunft 295
INHALTSVERZEICHNIS
5
Quellenverzeichnis 301
Neue BW-Transaktionen 302
A Die Autoren 306
B Index 309
C Disclaimer 314
Weitere Bücher von Espresso Tutorials 315
35
2 Vorbereitung der Umstellung auf HANA
Spätestens mit der Entscheidung, HANA als Datenbank für Ihr
Business Warehouse einzusetzen, sollten Sie Themen wie Sizing,
Migration, Housekeeping, Rechenzentrumsbetrieb und Data Life-
cycle Management von HANA als Datenbank für Ihr BW-System in
Angriff nehmen.
Idealerweise haben Sie im Vorfeld der Entscheidung für HANA schon
über diese Themen gesprochen. So ist etwa das Sizing nicht nur für
die Größe und Anzahl der benötigten Server maßgebend. Je nach
Lizenzierungsmodell hat die Datenbankgröße auch Einfluss auf die
Lizenzkosten.
Unabhängig vom Lizenzmodell sollten Sie die Themen wie House-
keeping und Data Lifecycle Management als permanente Prozesse
im Unternehmen etablieren. Dadurch können Systemtabellen schlank
gehalten werden. Aktuelle und häufig verwendete Daten sollten im
Hauptspeicher von HANA liegen, um schnellstmöglich analysiert zu
werden. Historische Daten, auf die nur noch selten zugegriffen wird,
können Sie hingegen im Near-Line-Storage-Archiv kostengünstig
ablegen.
2.1 Sizing
Das richtige Sizing des Datenbankservers für HANA ist sehr wichtig,
denn bereits hier können viele Fehler gemacht werden. Um das zu
vermeiden, hat Marc Bernard einen sehr guten Blog mit den häufigs-
ten Fehlern beim Sizing eines BWs auf HANA geschrieben.
VORBEREITUNG DER UMSTELLUNG AUF HANA
36
Blog: Wie man ein BW-System nicht sized
http://scn.sap.com/community/netweaver-bw-hana/
blog/2013/08/28/how-not-to-size-a-sap-netweaver-
bw-system-for-sap-hana
2.1.1 Sizing eines neuen BWs auf HANA
Beim Sizing eines brandneuen Systems für BW auf HANA sollte der
Quicksizer eingesetzt werden (http://service.sap.com/quicksizer).
Auch wenn es darum geht, die Applikationsserver richtig zu dimensi-
onieren, finden Sie entsprechende Hilfestellung in diesem Tool.
2.1.2 Sizing eines nicht-BW Data Warehouses für BW auf HANA
Angenommen, Sie haben ein bestehendes Data Warehouse, das
nicht auf BW-Technologie basiert. Dieses System möchten Sie in ein
BW auf HANA überführen. Für das Sizing gibt es zwei Möglichkeiten:
1. Quicksizer (siehe voriger Abschnitt),
2. manuelles Sizing.
Für die Berechnung des manuellen Sizings benötigen Sie den Quell-
datenbestand sowie gegebenenfalls den Kompressionsfaktor (»c«)
der Quelldatenbank. Falls die Datenbank keine Komprimierung nutzt,
setzen Sie diesen Faktor c = 1. Die Berechnung erfolgt nach den
Formeln in Abbildung 2.1.
VORBEREITUNG DER UMSTELLUNG AUF HANA
37
Abbildung 2.1: Formeln des manuellen Sizings
HANA hält die Daten primär im Hauptspeicher. Die Speicherung auf
Festplatten wird lediglich zur Ausfallsicherheit benötigt. Bei Neustart
des Systems können Sie so die Daten von der Persistenz gesichert
wiederherstellen.
Der Plattenplatz der Persistenz (DISKPersistenz) ist das benötigte Mini-
mum, muss mindestens der Größe des Hauptspeichers (in etwa
zweimal der Größe des Datenbestands) entsprechen und dient zur
Sicherung der Savepoints. Bitte reservieren Sie nach Bedarf noch
Platz für Backups, Exports und andere Zwecke. Eine Daumenregel
empfiehlt hier den vierfachen Platz des Random Access Memorys
(RAM). Letztlich hängt es von Ihren Bedürfnissen ab.
Für den Log-Bereich (DISKLog) empfiehlt es sich ebenfalls, einen Plat-
tenbereich entsprechend der Hauptspeichergröße (einmal die Haupt-
speichergröße auf Platte) zu reservieren. Hier werden alle Informati-
onen bzgl. Datenveränderungen mitprotokolliert und synchron auf
Disk geschrieben, um bei einem Systemausfall Datenverluste zu
vermeiden.
Die vorangestellte Formel geht davon aus, dass sich in einem typi-
schen BW-System etwa 60 GB der Daten im sogenannten Row Store
befinden, also in dem Teil der Datenbank, der zeilenbasiert abgelegt
wird. Diese werden vom Gesamtdatenbestand abgezogen, und der
Rest wird spaltenbasiert in der Datenbank abgelegt.
VORBEREITUNG DER UMSTELLUNG AUF HANA
38
Der Komprimierungsgrad von Daten hängt sehr speziell davon ab,
wie häufig sich Werte wiederholen und welchen Datentyp einzelne
Spalten haben. Die Erfahrung hat gezeigt, dass im Durchschnitt etwa
ein Komprimierungsfaktor von 4:1 zu erwarten ist. Dieser Wert wird
mit dem Faktor zwei multipliziert, da Sie neben der reinen Ablage der
Daten noch Platz im Hauptspeicher (RAM) benötigen, der für dyna-
mische Objekte im laufenden Betrieb gebraucht wird. Beispiele sind
hier temporäre Objekte, die zur Laufzeit von Berichten oder auch von
Datenladungen erzeugt werden. Berücksichtigen Sie dies nicht, wird
es im Betrieb zu erheblichen Problemen kommen.
Sofern die Daten in der bestehenden Datenbank komprimiert sind,
können Sie einen Komprimierungsfaktor »c« einbeziehen.
Im letzten Teil der Formel werden noch 90 GB berücksichtigt, die
typischerweise nicht spaltenweise in der Datenbank abgelegt werden.
Dazu zählen
40 GB an Systemdaten (Data Dictionary, Housekeeping
Tabellen etc.),
40 GB an Caches,
und ca. 10 GB an zusätzlichen HANA-Komponenten, wie
z. B. der Name-Server oder der Statistik-Server.
In Summe ergibt das 90 GB.
Soweit zur Erklärung der Formel; doch wie kommen Sie jetzt zum Quelldatenbestand?
Das wird detailliert im zuvor genannten Blog von Marc Bernard be-
schrieben. Sie gehen von Ihrer bestehenden Datenbankgröße aus
und ziehen den freien Platz, das Log und die Datenbankindizes ab.
Auf Aggregate können Sie ebenfalls verzichten.
Haben Sie die Daten komprimiert abgelegt, so können Sie den
durchschnittlichen Komprimierungsfaktor über den Parameter »c« in
der Formel berücksichtigen.
VORBEREITUNG DER UMSTELLUNG AUF HANA
39
Manuelles Sizing
Sie planen, ein MS-SQL-basiertes Data Warehouse
mit einer Datenbankgröße von 600 GB (ohne Indizes,
Log und Aggregate) in ein BW auf HANA zu über-
führen. Derzeit setzen sie keine Komprimierung ein.
RAM = (600 GB – 60 GB) * 2 / 4 * 1 + 90 GB = 360 GB
Was Sie wissen sollten
Eine wichtige Voraussetzung für diese Formel sind
vergleichbare Datenmodelle. Wenn Sie zum Beispiel
im BW planen, die Daten mehrfach persistent abzu-
legen, dies aber in ihrem heutigen System nicht tun,
dann sollten Sie das in Ihre Überlegungen miteinbe-
ziehen, denn sonst besteht die Gefahr, dass Sie das System zu
klein dimensionieren.
Das Gleiche gilt auch im umgekehrten Fall, d. h., wenn Sie das
Datenmodell und die vorhandenen Redundanzen auflösen, dann
benötigen Sie weniger Platz im künftigen BW-System. Im Verlauf
des Buches zeigen wir Ihnen, wie Sie Datenschichten virtualisie-
ren können, denn hierzu gibt es speziell mit BW auf HANA neue
Möglichkeiten.
Einige Datentabellen müssen Sie nicht permanent im Hauptspeicher
vorhalten. Hierzu gehören beispielsweise die Persistent Staging Area
(PSA) oder schreiboptimierte DataStore-Objekte (write-optimized
DSO). Diese können Sie mit einem niedrigeren Wert gewichten, denn
hier greift bei BW auf HANA die Logik der »nicht aktiven Daten« (sie-
he Abschnitt 2.5.2). Darüber hinaus haben Sie mit Extended Tables
die Möglichkeit, große Staging-Tabellen (z. B. PSA oder schreibopti-
mierte DSOs) nur persistent auf Platte zu speichern (siehe Abschnitt
2.5.3).
INDEX
309
B Index
A ABAP Routine Analyzer 57
Accelerator 19, 291
ADK 25
Advanced DSO 30, 106, 199,
262, 287, 293, 296
Aggregat 38, 284
Agile Data Marts 259
Aktivierung 28, 142, 286, 293
Analyseprozessdesigner 25
Analytic Manager 226, 296,
300
Analytic View 125, 167
Appliance 26, 63, 69, 74, 81,
93, 295
Architected Data-Mart Layer
253
Archivierung 111
Attribute View 125, 165
Attributsänderungslauf 286
B Backup 88
Berechtigungen 238
Bericht-Bericht-Schnittstelle
24
BEx Broadcasting 25
BEx Query 30, 128, 300
BEx Query Designer 298
BEx Web Application Designer
25
BEx-Werkzeuge 26
BI Content 24, 30, 207, 265
Business ByDesign 127
Business Explorer 23
Business Transformation
Layer 253
Business Warehouse
Accelerator 15, 17, 18, 26,
28, 31, 284, 292
BusinessObjects Analysis für
MS Excel 205
BW Migration Cockpit 55, 60
BW Reporting Layer 253
BW Roadmap 295
BW Workspaces 27, 29, 200,
259, 285, 287, 290, 293
BW-Analyseberechtigung 46,
54
C Calculation Engine 223, 226
Calculation View 125, 169,
268
Central Provider 202
Change Log 28, 59
Change Request 288
Checklist Tool 56
Code-Push-Down 27, 110,
130, 224, 266, 283, 292,
296, 298
CompositeProvider 27, 30,
133, 182, 293, 296
INDEX
310
Corporate Information Factory
23
Corporate Memory 254
D Data Acquisition Layer 252
Data Archiving Process 108
Data Lifecycle Management
98
Data Mining Workbench 25
Database Migration Option 48
Data-Mart-Schnittstelle 23,
128
DataSource 24
Datenbankmigration 47
Datenmanagement 229
Datenmodellierung 135
DB Connect 25, 113, 115,
125, 129, 133
DB2 130, 291
Delta Merge 244
Delta Queue 51, 117, 122
Desaster Recovery 91
DSO 27, 39, 106, 120, 141,
293
DTP 26
Dual Stack 46, 50
E Eclipse 164
EDW Propagation Layer 252
Enterprise Data Warehouse
23, 172, 249, 250, 280
Enterprise Storage 70, 73,
295
Exception 24
extended Star-Schema 23
Extended Table 39, 103, 297
Externe-HANA-Sicht 138,
147, 154, 190, 213
Extraktor 113, 120
F Failover 93
feldbasierte Modellierung
196, 293
feldbasiertes DSO 30, 197
Feldbezeichnung 267
Fortschreibungsregel 24
G Gemischtes Szenario 29, 211,
293, 298
generischer Extraktor 25
generisches BW-Delta 113
Greenfield 44, 52
H Hadoop 130, 133, 287, 298,
299
HANA Analyseprozess 30,
236, 287, 290, 298
HANA Cloud 84
HANA Cloud Infrastructure 84
HANA Cloud Platform 86
HANA Developer Edition 85
HANA Dynamic Tiering 103
HANA Enterprise Cloud 87
HANA Live 19, 265, 294
HANA Live Authorization
Assistant 277
HANA Live Browser 273
INDEX
311
HANA Live Extension
Assistant 278
HANA One 85
HANA Studio 20, 30, 89, 133,
164, 185, 194, 270, 273,
278, 298
HANA View 265
Harmonization Layer 252
heterogene Systemkopie 47
High Availability 92
Hochverfügbarkeit 91
hohe Kardinalität 137
Housekeeping 58
HTML5 266
HybridProvider 27
Hybrid-Szenarien 281
I InfoCube 23, 120, 147
InfoObjekt 23, 120, 136
InfoProvider 25, 296
InfoSet 26, 120, 161
InfoSet Query 24
In-Memory Data Fabric 129
In-Memory-Datenbank 15, 63
Integrierte Planung 26, 29,
285
K Komprimierung 36, 38, 128
Komprimierung InfoCube 153
KXEN 237
L Line Item Dimension 24
Local Provider 202
Log 37, 38, 88
LSA 249
LSA++ 254, 293
M manuelles Sizing 36
Master-Knoten 68, 94
MaxDB 16, 291
MCOD 43, 76
MCOS 78
Merkmale 23
Migration InfoCube 154
MS SQL Server 130, 291
MultiCube 24
MultiProvider 120, 161
Multi-Temperature Data
Management 99, 289, 292,
297
N Near Line Storage 26, 107,
133, 292, 297
NetWeaver Business Client
202
Neuinstallation 44
nicht aktive Daten 39
Nicht aktive Daten 100
O ODP 30, 116, 221
ODQ 117, 127
ODS 23, 24
OLAP 15, 18, 23, 27, 28, 265,
284, 293
OLAP-Prozessor 23
OLTP 15, 18, 23, 265
INDEX
312
Open ODS Layer 256
Open ODS View 115, 121,
133, 190, 287, 290, 293
OpenHub 25
Operational Data Store 254
operatives Reporting 279
Oracle 130, 291, 292
P P*Time 17, 18
PAL 236, 293
PAL-Skript 287, 290
Planning Application Kit 27,
285
Planung 232
Point-in-Time-Recovery 89
Post Copy Automation 50
Predictive 234
Private View 268
Prozessketten 25, 243
PSA 23, 24, 39, 59, 106, 116
Q Query View 269, 278
Quicksizer 36, 43
R R3Load 47
Recovery 88
Recovery Point Objective 92
Recovery Time Objective 92
Remodellierung 140
RemoteCube 24
Reuse View 268, 278
Row Store 37
R-Skript 287, 290
S SAP BusinessObjects BI Suite
215
SAP IQ 107, 290
SAP Predictive Analysis 238
SAP Service API 25
Savepoint 37, 88
Scale-out 40, 42, 65, 68, 72
Scale-up 65
selektive Migration 52
selektives Löschen 286
Semantisch Partitioniertes
Objekt 158
Sidecar 19, 265, 276
SID-Generierung 146
Simple Finance 21
Simplifizierung 21, 283, 289,
296
Sizing 35
Sizing Report 40, 58
Skalierbarkeit 65
SLT 30, 125, 266
Smart Data Access 30, 115,
129, 287, 290, 293, 298,
299
Software Update Manager 48
SPO 27, 120
Startroutine 24
Sternschema 148
Storage Replication 94
Systemreplikation 96
T Tailored Data Center
Integration 69, 295
transaktionaler InfoCube 25
INDEX
313
Transformation Finder 57
Transformationen 286, 293
Transformationsregel 26
TransientProvider 27, 174
Transportkonzept 24
TREX 16
U UD Connect 25, 113, 129
V Value Help View 269
Virtualisierung 81
Virtualization Layer 253
VirtualProvider 178
virtuelle Stammdaten 138
virtueller InfoCube mit
Services 25
virtuelles Datenmodell 19,
265, 268
W Whitelist 76
Worker-Knoten 68, 94