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