Business Intelligence Infotag

Transkript

1 Business Intelligence Infotag SAP Consulting und Leuphana Universität im Dialog Data Warehousing in column & memory - Trends im Business Warehouse Thorsten Winsemann

2 Inhalt TW Zur Person R/3-Informationssysteme Ein Rückblick Business Information Warehouse BW Accelerator In Column & Memory: OLTP + OLAP Ausblick SAP 2009 / Page 2

4 TW Zur Person Studien Hochschule Bremerhaven Transportwesen ( Logistik ) Diplom-Wirtschaftsingenieur (FH) Systemanalyse ( Wirtschaftsinformatik ) Diplom-Ingenieur (FH) Beruf SAP AG, SAP Hosting, SAP SI, SAP Deutschland Entwicklung (Walldorf) Logistikinformationssysteme + Business Information Warehouse 1999 heute Beratung (Walldorf + Hamburg) Business Information Warehouse + Logistikinformationssysteme seit 10/09 Internes Entwicklungsprojekt New BW & NewDB Promo Otto-von-Guericke-Universität Magdeburg seit 09/09 Architektonische Anforderungen an ein Data Warehouse unter besonderer Berücksichtigung neuester Techniken der Datenhaltung SAP 2009/ Page 4

5 Inhalt TW Zur Person R/3-Informationssysteme Ein Rückblick Business Information Warehouse BW Accelerator In Column & Memory: OLTP + OLAP Ausblick SAP 20089/ Page 5

6 R/3-Informationssysteme Executive Information System etc. CO-PA Ergebnisrechnung FI: General Ledger et al. Projektsystem- Informationssystem Logistik- Informationssysteme HR- Informationssystem R/3 SAP 2009/ Page 6

7 Data Warehouse Konzepte: Logistik-Informationssysteme (LIS) OLAP Online Analytical Processing DATA WARE- HOUSE Analyse-Werkzeuge Planung Copy Management OLTP Qualitätsmanagement Verdichtete Informationen Produktionsplanung Material- Management Online Transaction Processing Externe Daten Vertrieb Instandhaltung Integrierte Anwendungsmodule Finanzen, SAP 2009/ Page 7

8 Datenfluß im LIS Standard- Analyse Analyseprogramm Analyseprogramm S... S001 S5nn Info-Struktur S001/ Menge Wert S5nn/XYZ Anzahl ø-wert Fortschreibungs- regeln MCVBAK MCVBAP LIS-Schnittstelle Schnittstelle Auftrag Vertrieb VBAK VBAP VBAK VBAP Anwendung SAP 2009 / Page 8

10 Gründe der Trennung von OLTP und OLAP OLAP Steigender Informationsbedarf in Quantität und Qualität Sammlung von Daten verschiedener Art und Quellen Datenharmonisierung (Synonyme Kunde Auftraggeber, ) Unterschiedliche Art der Datennutzung erfordert(e) unterschiedliche Ablage- und Zugriffskonzepte detailliert verdichtet; geringe große Datenmengen; INS/UPD SEL, HW-/Systemressourcen durch gleichzeitige Nutzung erschöpft Unzureichende Berichts- und Analyseperformance OLTP Qualitätsmanagement Vertrieb Produktionsplanung Material- Management Instandhaltung DATA WARE- HOUSE BW ersetzt R/3-Info-Systeme, aber nicht alle Berichte! Finanzen, ERP SAP 2009/ Page 10

11 SAP Business Information Warehouse: Überblick SAP 2009 / Page 11

12 SAP Business Information Warehouse: Einschränkungen Reporting im BW ist fixiert auf InfoCubes, InfoObjects/Stammdaten, größtenteils auf verdichtete Daten bezogen ausgerichtet auf die heutigen, bekannten Bedürfnisse der Anwender Zeitnahe Reaktion auf Unbekanntes ist eingeschränkt: (zu) geringe Detaillierungsgrad der Daten in den InfoProvidern fehlende (historische) Vollständigkeit der Daten anwender-bezogene Datenbeschaffung Veränderung des Originalzustands der Daten fehlende Stammdatenhistorie SAP 2009 / Page 13

13 BW - Layered, Scalable Architecture: Referenzschichten betriebswirtschaftliche Logik BI -Applications- Layer aufbereitet, verwendbar für BI-Applikationen harmonisierte Sicht applikationsneutral EDW-Layer (wiederverwendbar; konzernweit, granular Single Point of Truth ) SAP 2009 / Page 14 A Harmonisierte Sicht Qualitätssicherung User berichts- & analysefertig Reporting Layer (Architected Data Marts) Business Transformation Layer Data Propagation Layer Quality & Harmonisation Layer Data Acquisition Layer Corporate Memory A near real-time reporting granular, operational Operational Data Store unverändert, granular extrahierte Daten unverändert Data Sources langfristig umfassend, komplett temporär das Unbekannte meistern LSA

14 BW - Layered, Scalable Architecture: Kundenbeispiel SAP 2009 / Page 15

16 BW Accelerator Vision Beschleunigung der Berichts-Performance für SAP BW um bis zu Faktor 100 über vorkonfiguriertes plug-in appliance Hohes Datenvolumen Berichte mit einem zugrundeliegende Datenbestand von (zig-) Millionen Sätzen Schnelle Antwortzeiten Beispiel: Service Level Agreements für Call Center u.ä. Ad hoc-berichte Gute Antwortzeiten für verschiedenste Abfagen, Aggregationsstufen, drill-down, slice & dice,

17 BW Accelerator: Architektur (Indexaufbau, -Laden, Berichtsausführung) BusinessObjects Other Explorer Other Daten-/Ergebnisaufbereitung für BI Queries Aggregation on the fly In-Memory Processing Analytic Engine InfoCubes Indexing Any Source SAP 2009 / Page 18 Data Acquisition SAP NetWeaver BW Parallele Indizierung der InfoCube-Daten über BW-Standard prozesse Spaltenbasiertes Speichern & Komprimierung für minimalen Speicherplatz Initiales Laden der Indexe SAP NetWeaver BW Accelerator

18 BW Accelerator Performance (1): Vertical Decomposition Classical DB stores tables by row BW Accelerator stores tables by column Tuple1 Tuple2 Att1 Att2 Att3 Att4 Att5 To find all instances of an attribute value: Go to the first row Check the attribute value Go to the next row Check the attribute value Repeat for each row in the table To find all instances of an attribute value: Go to the attribute column Read its row values SAP 2009 / Page 20

19 BW Accelerator Performance (2): Horizontal Partitioning Index Fact Table Part 01 Part 01 Automatic assignment to nodes TREX Services Metadata Part 02 Part N Part 02 Part N Large Tables Index Metadata Logical Index Server Index Metadata Physical Index Server Index Metadata Physical Index Server.... Index Metadata Physical Index Server Storage If you add a new HW node, the BW Accelerator monitor enables easy redistribution SAP 2009 / Page 21

20 BW Accelerator Performance (3): Smart Compression DocId 1 DocId 2 DocId 3 DocId 4 DocId 5 DocId 6 DocId 7 JAN FEB MAR APR MAY JUN JUL Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, INTEL oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, ABB oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, oder HPdas Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, INTEL oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, IBM oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, IBM oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu SIEMENS öffnen, oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat RED GREEN BLUE RED WHITE BLACK BROWN DocId ValueId DocId 8 AUG Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, INTEL oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, oder das Bild ist beschädigt. Starten Sie den Computer neu, und öffnen Sie dann erneut die Dat BLUE 3 Index Vector 1. Take a column 2. Map its values to integers in a dictionary 3. Write the index vector with integers 4. Invert the index vector for fast lookup Dictionary ValueId Value 0 ABB 1 HP 2 IBM 3 INTEL 4 SIEMENS Inverted Index ValueId DocIdList ,6 3 1,4,8 4 7 SAP 2009 / Page 22

21 BW Accelerator Availability & Scalability Master 1 is active, masters 2 and 3 are backups: each master pings all masters to check availability RFC RFC Server Server Run as many blades as required for current index and query load Name Server Master Name 1 Server Master Name 2 Server Master 3 Index Server Backup BWA Engine Index Index Server Server Master Master BWA Engine Index Index Server Server Cohort Master BWA Engine Index Server Cohort Index Index Server Server Cohort Master BWA Engine For higher availability install one or more extra blades and configure them to serve as backups for the other blades BWA Storage

22 Testergebnisse InfoCube Aggregate BWA SAP 2009 / Page 24

23 Aktuell: SAP BusinessObjects Accelerator & Explorer Integration Excel Universe SAP BusinessObjects Enterprise SAP BusinessObjects Explorer Nonaccelerated accelerated version index designer BW Accelerator SAP BusinessObjects Data Services SAP BusinessObjects Accelerator SAP 2009 / Page 26 External Data Business Warehouse SAP NetWeaver BW

25 Nachteile der Trennung von OLTP und OLAP OLAP hat keine aktuellsten Daten (kein wirkliches real-time reporting ) OLAP hat nur eine vordefinierte Teilmenge der Daten Aufwändiges Synchronisieren beider Systeme notwendig Komplexe ETL-Prozesse in OLTP und OLAP Hohe Datenredundanz Hoher Wartungsaufwand SAP 2009 / Page 28

26 Forschung am HPI Untersuchungen zu In-Memory-Column Database Aussage: Column storage paßt bestens zu modernen CPUs! Vorbemerkung: Multi-core processors: Blades mit 8 CPUs mit jeweils 16 Cores 128 Computing units mit bis zu 500 GB Hauptspeicher Rechnerleistung wird zunehmen! Vorraussetzung: Optimierte Nutzung unter Berücksichtigung von Speichernutzung/-verbrauch Parallelverarbeitung SAP 2009 / Page 29

27 HPI: Column storage paßt bestens zu zeitgemäßen CPUs (1) Grundlage: Betrachtung einer echten (Kunden-)Datenbank : Beispiel: SAP-Tabelle FI-Belegpositionen 160 Attribute, 34 Millionen Datensätze Row-based DBS: ~ 35 GB Column-based DBS: ~ 8 GB (wg. besserer, vertikaler Verdichtung) Typische SQL-Abfrage beinhaltet 10% der Attribute 800MB Daten erforderlich für Summenbildung DB-Zugriffe sind meistens set-basiert und somit spaltenorientiert Eine row-based DB kann (auch mit Indizierung) nicht mit einer column-based konkurrieren (größerer zu durchsuchender Datenbestand) SAP 2009 / Page 30

28 HPI: Column storage paßt bestens zu zeitgemäßen CPUs (2) SAP 2009 / Page 31

29 HPI: Column storage paßt bestens zu zeitgemäßen CPUs (3) Zusätzlich: Berechnungen meistens auf DB-Ebene mit komprimierten Integerformaten möglich Performance-Vorteil von Faktor ggü. nicht-komprimierten Daten auf Applikationsebene Parallelverarbeitung durch einfache Verteilung spaltenorientierter Zugriffe Scan-Geschwindigkeit: 1MB/ms > 10MB/ms bei CPU mit 16 Cores parallel bei einer auf 4 Bytes komprimierten Dimension 2.5 Mio. Tuples/ms Full column scan! SAP 2009 / Page 32

30 HPI: Column storage eignet sich für UPDintensive Applikationen (1) Behauptung: Column-store DB sind teuer bei Updates (durch aufwändiges Neu-Berechnen der komprimierten Spalten(werte)) Grundlage: Betrachtung einer echten (Kunden-)Datenbank : Beispiel: Tabellen der SAP FI-Applikation (~18 Tabellen; 2+16) Ergebnis der Analyse: 3 Hauptarten von Updates Aggregate Statusinformationen Werte SAP 2009 / Page 33

31 HPI: Column storage eignet sich für UPDintensive Applikationen (2) Update von Aggregaten Aggregate werden durch on-the-fly -Berechnungen überflüssig SAP 2009 / Page 34

32 HPI: Column storage eignet sich für UPDintensive Applikationen (3) Update von Statusinformationen UPD problemlos, da Kardinalität sich nicht ändert und sie nicht komprimiert werden (müssen) INS-only-Ansatz (mit Timestamp) Update von Werten Ølich nur 5% Veränderung des Datenbestands INS-only-Ansatz (mit Timestamp) Zusätzliche Last für Delta-Manager kein Problem Zusätzlich: Change History (mit Zeitstempel und Änderer) Weniger UPDs weniger Lock-Situationen SAP 2009 / Page 35 bessere Parallelisierung

33 HPI: Alle Daten eines Systems passen in den Hauptspeicher Daten im Hauptspeicher - Untersuchungen zeigen: Speicher-Komprimierung: Faktor 10 möglich ( Dictionary Compression et al.) Speichereinsparung durch Wegfall von Aggregaten (~ Faktor 2) Nur aktive Datenpartitionen im Hauptspeicher: ~ Faktor 5 (letzten 2 von ca. 10 Jahren Datenbestand) Reduzierung des Speicherbedarfs um Faktor 100 Hardware: 500 GB RAM in Bladeserver der nächsten Generation Bladesysteme mit 100 Blades 50 TB Hauptspeicher verfügbar! SAP 2009 / Page 36

35 OLTP + OLAP in einem System? Nutzung einer In-memory Column-store DB für OLTP + OLAP? OLAP Voraussetzung: Optimierung hinsichtlich Set processing (keine SELECT *) Schnellen inserts Maximalem, gleichzeitigem (Lese-)Zugriff Geringem Reorganisationsaufwand DATA WARE- HOUSE OLTP Konsequenz: Qualitätsmanagement Vertrieb Produktionsplanung Material- Management Instandhaltung OLTP + OLAP in einem column-based System möglich! Finanzen, ERP SAP 2009 / Page 38

36 OLTP + OLAP in einem System: Ausblick Was bedeutet das für Systeme? Auswirkungen auf Applikationsentwicklung: Code-Reduzierung um ~30% (Nutzung der DB-Logik + stored procedures) Geringer Speicherbedarf Anbindung externer Daten(quellen) durch SaaS Vertikale Partitionierung als (gute) Voraussetzung ETL/ELT-Prozesse notwendig? (Datenharmonisierung etc.) Was bedeutet das für Berater? SAP 2009 / Page 39 BW-Berater Prozeßberater?

37 Business Intelligence Infotag SAP Consulting und Leuphana Universität im Dialog Fragen? DANKE!