In-Memory DWH Reporting mit Oracle

Transkript

1 GfK Retail and Technology StarTrack Name of presenter 14 April 2008 In-Memory DWH Reporting mit Oracle Jens Albrecht, Marc Fiedler, Oliver Scheibe DOAG Konferenz und Ausstellung November 2009, Nürnberg

2 1 GfK Retail and Technology

3 GfK Retail and Technology GfK Gruppe Geschäftsbereiche: Custom Research, Retail and Technology und Media Umsatz 2008: 1.2 Mrd. Mitarbeiter: > weltweit 3 GfK Retail and Technology Erhebung von Handelsinformationen für langlebige Gebrauchsgüter z.b. Unterhaltungselektronik, Unterhaltungsmedien, elektrische Haushaltsgeräte, IT und Telekommunikation, DIY, Entertainment Dienstleistungen Produktion standardisierter Analysen für Informationen zu Trends, Volumen, Umsatz, Vertriebsweg und Segment Kundennutzen Produkt- und Preispolitik, Distribution, Vertrieb und Logistik

4 Panelorientierte Marktforschung 4 Industrie Großhandel Einzelhandel Konsument Mehrere hundert Kunden weltweit Handelspanel (GfK RT) Durables Erhebung in Geschäften Über 300 Warengruppen in insgesamt 80 Ländern Geschäfte weltweit Verbraucherpanel FMCG Erhebung bei Verbraucher

5 2 StarTrack Die Data Warehouse Plattform bei GfK RT

6 StarTrack Die Data Warehouse Plattform bei GfK RT 6 MDM Master Data Management CDM Client Delivery Management ETL Extraction Transformation Load Reporting GfK StarTrack Explorer

7 StarTrack Portal Client-Zugang zum Online-Reporting Zentraler Zugang zu allen GfK RT Services 7 GfK StarTrack Explorer

8 GfK StarTrack Explorer (GSE) 8 GROUP BY GENERATION TOTAL*, EDGE GROUP BY GENERATION TOTAL*, HSDPA GROUP BY DESIGN GROUP BY WAY OF BUYING GROUP BY KEYBOARD

9 StarTrack Reporting Infrastruktur 9 Clients Application Servers Database Servers Real Application Cluster (RAC) DB 128 Cores 512 GB RAM 6 TB Storage (HDS)

10 GfK StarTrack Explorer Interaktive Performance 10 Heterogene Berichtsstruktur Ausführung mehrerer SQL Anfragen pro Sheetberechnung Einige Berichte nicht interaktiv ausführbar Antwortzeiterwartung unzureichende Performance <= 10s Berechnungszeiten für 1 Sheet schwankend (wenige Sekunden bis mehrere Minuten) instabile Performance

11 Performancesteigerung durch Vorberechnung Rohdaten 11 Geschäft Zeit Fakten Artikel Aggregation anwendungsseitige Materialisierte Sichten Summary Tables Pre-Caching anwendungsseitig vorberechnete Berichte Aggregate Base

12 Ursachen für Performancedegradierung auf dem Zentralsystem 12 Degeneration der physischen Speicherstrukturen (Relationen und Indizes) Fortwährende Schreiboperationen (7x24 transaktionale Ladeprozesse) Gleichzeitiger Lese- und Schreibbetrieb UNDO Management ( snapshot too old ) REDO Management Ausführung heterogener Berichte für unterschiedlichste Kunden lesende Zugriffe auf verschiedene Datenbereiche Fortwährende Verdrängung von Objekten aus dem Systempuffer Hohe Anzahl paralleler Sessions Gleichzeitiger Zugriff von Kunden und GfK Mitarbeitern auf gleiche Datenbank

13 Client Data Marts Garant interaktiver Performance 13 Clients Application Servers Database Servers Zentrale Datenbank (Master) Definierter Datenausschnitt (Kopie) Reporting Base Client Data Mart

14 Client Data Marts Designziele 14 Konsequente Nutzung des Hauptspeichers Große SGA Vorladen des Systempuffers nach Abschluss der Ladeoperationen Identifikation von Hot-Spot Objekten Bestmögliche physische Organisation der Daten Reorganisation: Tabellen und Indizes in möglichst kompakter Form Konsequente Nutzung von Oracle Table Compression Separation von Lese- und Schreiblast Wechselseitiger Ausschluss von Ladeprozessen und interaktivem Reporting

15 3 In-Memory Client Data Mart Reporting

16 Client Data Marts Separation von Lese- und Schreiblast 16 Architektur einer Client Data Mart Einheit Client Data Mart DWH AppServer DWH AppServer Oracle 10g Oracle 10g HP Proliant 460c e Blades 2 Quad Core GB

17 Client Data Marts Separation von Lese- und Schreiblast (2) 17 Updatemechanismus Zentrale Reporting Base Client Data Mart REPORTING REPORTING UPDATING M I D D L E T I E R GSE Clients Lastverteilung Redundante Datenhaltung

18 In-Memory Reporting mit Oracle LRU Algorithmus Database Buffer Cache 18 Default Pool oft angefragt wenig angefragt MRU LRU Neuer Datenblock wird angefragt DB

19 In-Memory Reporting mit Oracle LRU Algorithmus 19 Database Buffer Cache Default Pool Keep Pool wenig angefragt MRU LRU Least Recently Used DB

20 In-Memory Reporting mit Oracle SGA Dimensionierung 20

21 In-Memory Reporting mit Oracle reduziertes Datenvolumen 21 Aggregate Base Reporting Base 2200 GB Einschränkung auf Warengruppen ~ Faktor 7 Aggregate Base Client Data Mart 284 GB Oracle Table Compression ~ Faktor 4 Beschränkung auf aktuelle Jahre mittels Oracle Partitionierung ~ Faktor 4 71 GB 18 GB

22 In Memory Reporting Verwendung Keep Pool 22 Was wird in den Keep Cache geladen? Anwendungsseitiges Priorisieren der Daten. Summary Tables + Aggregate Base Priorisierte Daten Ladeliste KEEP POOL Hot-Spots Ermittlung Hot-Spot Objekte Aktuelle Daten zuerst laden Aktualität

23 In Memory Reporting Verwendung Keep Pool (2) 23 Bestimmung Hot-Spot Objekte SELECT owner, FROM WHERE object_name, object_type, DECODE (OBJECT_TYPE, 'TABLE SUBPARTITION',SUBSTR(SUBOBJECT_NAME, 1, 3), 'INDEX SUBPARTITION',SUBSTR(SUBOBJECT_NAME, 1, 3), SUBOBJECT_NAME) AS SUBOBJECT_NAME, SUM (value) as overall_reads v$segment_statistics statistic_name IN ('logical reads', 'physical reads', 'physical reads direct') AND owner IN ('DWH_META', 'DWH_DATA', 'DWH_RB') GROUP BY owner, object_name,object_type, DECODE(OBJECT_TYPE, 'TABLE SUBPARTITION',SUBSTR(SUBOBJECT_NAME, 1, 3), 'INDEX SUBPARTITION',SUBSTR(SUBOBJECT_NAME, 1, 3), SUBOBJECT_NAME);

24 In Memory Reporting Verwendung Keep Pool (3) 24 Resultierende Ladeliste Keep Pool PRIORITY SEGMENT_NAME SEGMENT_TYPE YEAR MBytes 1 RB_FACT_AGG_SUM_SPACE_PRJ_IDX INDEX SUBPARTITION Y RB_FACT_AGG_SUM_SPACE_PRJ_IDX INDEX SUBPARTITION Y RB_FACT_AGG_SUM_SPACE TABLE SUBPARTITION Y RB_LU_DATAFILTER_MV TABLE NO 2 33 RB_FACT_AGG_SUM TABLE SUBPARTITION Y RB_FACT_AGG_SUM TABLE SUBPARTITION Y08 60

25 In Memory Reporting Verwendung Keep Pool (4) SEG_NAME SEG_TYPE MBytes TABLE_1 TABLE 50 INDEX_2 INDEX 10 INDEX IDX_PART_1 SUBPARTITION 9 Start Default Pool 25 Liste abgearbeitet JA NEIN Keep Pool Objekt Default Pool zuweisen NEIN Objektgröße < freier Keep Pool JA Objekt Keep Pool zuweisen und laden Ende

26 In Memory Reporting Verwendung Keep Pool (5) 26 Zuweisungs- und Ladebeispiele -- Eine Tabellen dem Keep Pool zuweisen ALTER TABLE ADM_COUNTRY_MV STORAGE ( BUFFER_POOL KEEP); -- Daten einer Tabellenpartition in den Keep Pool laden. SELECT /*+ FULL(t) */ count(*) FROM ADM_COUNTRY_MV t; -- Eine Tabellen-Partition dem Keep Pool zuweisen ALTER TABLE RB_FACT_AGG_SUM_SPACE MODIFY PARTITION Y07 STORAGE ( BUFFER_POOL KEEP); -- Daten einer Tabellenpartition in den Keep Pool laden. SELECT /*+ FULL(t) */ count(*) FROM RB_FACT_AGG_SUM PARTITION(Y07) t; -- Eine Index-Partition dem Keep Pool zuweisen ALTER INDEX RB_FACT_SP_PRJ_IDX MODIFY PARTITION Y07 STORAGE ( BUFFER_POOL KEEP); -- Eine Index-Partition in den Keep Pool laden SELECT /*+ INDEX(t RB_FACT_SP_PRJ_IDX)*/ count(*) FROM RB_FACT_AGG_SUM PARTITION(Y07) t;

27 4 Evaluation

28 Workload Definition 28 Interaktives Reporting: Protokollierung der SQL-Abfragen an den Application Servern Application Server SQL 2 Testszenarien: Client Data Mart Servers SQLs in 35 parallelen Sessions SQLs in 25 parallelen Sessions

29 Laufzeit Minuten Ergebnisse Testszenario o SQLs : 85% AGGBASE-SQLs, 15% RAWDATA SQLs o SGA-Test-Einstellungen Test SGA / GB Default Buffer Pool /GB Keep Buffer Pool / GB DEFAULT Pool KEEP Pool Laufzeiten DEFAULT Pool KEEP Pool AGGBASE RAWDATA

30 Laufzeit Minuten Ergebnisse (2) Testszenario o SQLs : 40% AGGBASE-SQLs, 60% RAWDATA SQLs o SGA-Test-Einstellungen Test SGA / GB Default Buffer Pool /GB Keep Buffer Pool / GB DEFAULT Pool KEEP Pool Laufzeiten DEFAULT Pool KEEP Pool AGGBASE RAWDATA

31 Interpretation der Ergebnisse 31 Pro Performance auf Client Data Marts im Schnitt Faktor 10 besser als auf der zentralen Reporting Base Performancesteigerung und Laufzeitstabilität für alle priorisierten Daten im KEEP POOL Performance aufgrund reduzierten Datenvolumens Trennung von Lese- und Schreibprozessen Mehr Daten im Buffer Cache durch Oracle Compression kompakte Daten große SGA Kontra Größen der SGA muss mit der Größe der Aggregate Base und der Summary Tables in Relation stehen Default Pool bei unbekannten Lastverhalten meist besser Fusionsproblematik Zusätzliche Datenbewirtschaftung Zeitaufwendige Reorganisation der Daten

32 5 Zusammenfassung und Ausblick

33 Zusammenfassung und Ausblick 33 Zusammenfassung Mangelnde interaktive Performance auf Zentralsystem Client Data Marts sind Faktor 10 schneller In-Memory Reporting durch Nutzung des Keep Pools Ausblick Rasante Hardwareentwicklung Oracle 11gR2 (Cache Fusion) Suche nach Alternativen PoC Database Machine => Donnerstag 14:00 Raum Istanbul

34 Thank you very much for your attention.???? Fragen?????? 34