SAP HANA als In-Memory-Datenbank-Technologie für ein Enterprise Data Warehouse

Transkript

1 SAP HANA als In-Memory-Datenbank-Technologie für ein Enterprise Data Warehouse Oliver Neumann 08. September 2014 AKWI-Tagung 2014 Light is OSRAM

2 Agenda 1. Warum In-Memory? 2. SAP HANA technisches Konzept 3. Implementierung & Migration 4. Datenmodellierung in BW on HANA 5. Testergebnisse bei Osram OS 2

3 Agenda 1. Warum In-Memory? 2. SAP HANA technisches Konzept 3. Implementierung & Migration 4. Datenmodellierung in BW on HANA 5. Testergebnisse bei Osram OS 3

4 Warum In-Memory? Problem: Anstieg von Datenmengen in Unternehmen Schnelle Abfragen mit Trial-and-Error-Verfahren wünschenswert Hardware-Kosten sind teils enorm gesunken Nutzung neuer Trends bei Hardware Senkung von Kosten (TCO) 4

5 Agenda 1. Warum In-Memory? 2. SAP HANA technisches Konzept 3. Implementierung & Migration 4. Datenmodellierung in BW on HANA 5. Testergebnisse bei Osram OS 5

6 SAP HANA Das technische Konzept In-Memory Datenbanken sind nicht neu Die erste IMDB wurde in den 1980er entwickelt Viele Konzepte wurden kombiniert: In-Memory Verarbeitung Parallele Verarbeitung Spaltenorientierte Speicherung Komprimierung 6

7 Speichertechnologie Je näher der CPU-Kern, desto schneller die Verarbeitung. Cache miss und Full miss reduzieren Blockgröße berücksichtigen 7

8 Parallele Verarbeitung Verteilung der Daten auf mehreren Blades Horizontale Partitionierung Nutzung von Multicore-CPUs 8

9 Spaltenorientierte Speicherung Verändertes Speicherformat Sehr gute Lesegeschwindigkeit Schlechte Schreibgeschwindigkeit Eignet sich gut für hohe Komprimierung 9

10 Komprimierung Light-weight Komprimierungsverfahren Verarbeitung ohne vorherige Dekomprimierung Komprimierung um Faktor 3-5 Weitere Verfahren: Run-length encoding Null value supression 10

11 OLAP & OLTP Der Differential Buffer Gute Schreibgeschwindigkeit trotz spaltenorientierter Speicherung Lifecycle-Management für DML-Anweisungen Delta-Merge vereint beide Speicher Für Anwender nicht transparent 11

12 Agenda 1. Warum In-Memory? 2. SAP HANA technisches Konzept 3. Implementierung & Migration 4. Datenmodellierung in BW on HANA 5. Testergebnisse bei Osram OS 12

13 Implementierungsoptionen Standalone-Implementierung Freie und unbeschränkte Nutzung von HANA als DB Komplette Neuinstallation ist erforderlich BW on HANA SAP NetWeaver Business Warehouse on HANA Viele Optimierungen für die DWH-Applikation von SAP Business Suite on HANA SAPs ERP-Lösung optimiert für HANA Für viele Module wurden Anpassungen implementiert 13

14 Migrationsstrategien für BW on HANA Neuinstallation Redesign kompletter Datenflüsse möglich Schrittweise Migration Hoher Aufwand Side-by-Side Dauerhafter Parallebetrieb Nur kritische Datenflüsse und Provider werden migriert Mittlerer Aufwand Komplettmigration Migration der gesamten Datenbank Beschleunigung sämtlicher Provider und Objekte Geringer Aufwand durch DMO 14

15 Agenda 1. Warum In-Memory? 2. SAP HANA technisches Konzept 3. Implementierung & Migration 4. Datenmodellierung in BW on HANA 5. Testergebnisse bei Osram OS 15

16 Datenmodellierung in SAP HANA on BW Neue Datenflüsse für flexiblere Modellierung Je nach Anwendungsfall verwendbare Kanäle Neue Modellierung mit HANA Studio 16

17 Neues Konzept für InfoCubes Konzeptänderung für bessere Performance Dimensionstabellen und E-Tabelle werden obsolet Logisches Konzept wird beibehalten ABAP-Programm zur Konvertierung 17

18 Agenda 1. Warum In-Memory? 2. SAP HANA technisches Konzept 3. Implementierung & Migration 4. Datenmodellierung in BW on HANA 5. Testergebnisse bei Osram OS 18

19 Testobjekt in der HANA Sandbox Verwendetes Objekt für Tests mit Echtdaten ABAP-Programm zur Laufzeitmessung Vergleich des produktiven Systems mit Proof of Concept conversion LPR3MVD Lot movements daily InfoCube 32.9 Mio Datensätze LPR3MVD Lot movements daily HANA-optimized InfoCube 32.9 Mio Datensätze 19

20 Time in hours Schreibperformance Datenladung mit 32.9 Millionen Datensätze 192 ~ 33-fach schneller :34: :32:28 5:04:39 BIP, Standard InfoCube POC, Standard InfoCube POC, HANA-optimized InfoCube 20

21 Time in seconds Abfrageperformance Vergleich der neuen InfoProvider 20 19,34 ~ 19-fach schneller 18 17, BIP, Standard InfoCube POC, Standard InfoCube POC, HANA-optimized InfoCube POC, TransientProvider POC, VirtualProvider ,65 1,54 0,58 0,83 1,02 1,28 0,36 0,23 0,42 0,51 0,48 0,52 2 Wochen 1 Jahr 4 Jahre 1,34 21

22 Fazit Schnell, aber Konvertierung wird immer empfohlen -> Nacharbeit notwendig Hohe Hardwareanforderungen Langfristige Bindung an SAP In-Memory Lösungen mit anderen Konzepten IBM - DB2 BLU Oracle - 12c In-Memory Option EXASOL - EXASolution 22

23 Vielen Dank.