SAP BW auf HANA. Frank Riesner Klaus-Peter Sauer

Transkript

1 SAP BW auf HANA Frank Riesner Klaus-Peter Sauer

2 INHALTSVERZEICHNIS Inhaltsverzeichnis Vorwort 7 Danksagung 11 1 Evolution und Überblick Evolution von SAP HANA Evolution von BW BW auf HANA versus BWA 31 2 Vorbereitung der Umstellung auf HANA Sizing Migrationsoptionen und unterstützende Werkzeuge Housekeeping Betrieb im Rechenzentrum Data Lifecycle Management 98 3 Änderungen bei der Datenbewirtschaftung Generisches BW-Delta DB Connect Operational Data Provisioning In-memory Data Fabric Modellierung in SAP BW auf HANA Änderungen an bestehenden InfoProvidern SAP-HANA-Modellierung Neue InfoProvider Anwendungsszenarien SAP-BW-Optimierung durch HANA 223 3

3 INHALTSVERZEICHNIS 4.6 Berechtigungen Prozessketten Obsolete Modellierungsfunktionen SAP-BW-Referenzarchitektur Layered Scalable Architecture klassisch Layered Scalable Architecture auf HANA Umwandlung einer LSA in LSA SAP HANA Live Motivation und Ziele Virtuelles Datenmodell Werkzeuge SAP BW versus SAP Hana Live Zusammenfassung und Ausblick Wie Sie von BW auf HANA profitieren BW auf HANA im Vergleich zu anderen Datenbanken mit In-Memory-Funktionen BW Roadmap der Blick in die Zukunft 295 4

4 INHALTSVERZEICHNIS Quellenverzeichnis 301 Neue BW-Transaktionen 302 A Die Autoren 306 B Index 309 C Disclaimer 314 Weitere Bücher von Espresso Tutorials 315 5

5 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 Lifecycle 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 Housekeeping 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äufigsten Fehlern beim Sizing eines BWs auf HANA geschrieben. 35

6 VORBEREITUNG DER UMSTELLUNG AUF HANA Blog: Wie man ein BW-System nicht sized blog/2013/08/28/how-not-to-size-a-sap-netweaverbw-system-for-sap-hana Sizing eines neuen BWs auf HANA Beim Sizing eines brandneuen Systems für BW auf HANA sollte der Quicksizer eingesetzt werden ( Auch wenn es darum geht, die Applikationsserver richtig zu dimensionieren, finden Sie entsprechende Hilfestellung in diesem Tool 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 Quelldatenbestand 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

7 VORBEREITUNG DER UMSTELLUNG AUF HANA 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 (DISK Persistenz ) ist das benötigte Minimum, 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 (DISK Log ) empfiehlt es sich ebenfalls, einen Plattenbereich entsprechend der Hauptspeichergröße (einmal die Hauptspeichergröße auf Platte) zu reservieren. Hier werden alle Informationen 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 typischen 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. 37

8 VORBEREITUNG DER UMSTELLUNG AUF HANA 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 dynamische 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 beschrieben. 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. 38

9 VORBEREITUNG DER UMSTELLUNG AUF HANA 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 überführen. Derzeit setzen sie keine Komprimierung ein. RAM = (600 GB 60 GB) * 2 / 4 * 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 abzulegen, dies aber in ihrem heutigen System nicht tun, dann sollten Sie das in Ihre Überlegungen miteinbeziehen, 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 virtualisieren 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«(siehe Abschnitt 2.5.2). Darüber hinaus haben Sie mit Extended Tables die Möglichkeit, große Staging-Tabellen (z. B. PSA oder schreiboptimierte DSOs) nur persistent auf Platte zu speichern (siehe Abschnitt 2.5.3). 39

10 INDEX 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,

11 INDEX 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

12 INDEX 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,

13 INDEX 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

14 INDEX 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,