Oracle In-Memory - Das entscheidende Datenbank-Feature für Echtzeit-Analytics Dr.-Ing. Holger Friedrich

Transkript

1 Oracle In-Memory - Das entscheidende Datenbank-Feature für Echtzeit-Analytics Dr.-Ing. Holger Friedrich

2 Agenda Einführung Spaltenorientierte Datenbanken Oracle In-Memory Performance Integration Schlussfolgerungen 2

3 sumit AG Bietet Beratungs- & Implementierungs- dienstleistungen in der Schweiz Experten für Data-Warehousing- und Business-Intelligence-Lösungen Fokussiert auf Oracle-Technologie BI Foundation specialized -Partner Data Warehousing specialized -Partner Unser Motto: Get Value From Data Besuchen sie unsere Web-Site: 3

4 Holger Friedrich Informatikdiplom des Karlsruhe Institute of Technology (KIT) Promotion in Robotik & Machine Learning Mehr als 18 Jahre Erfahrung mit Oracle-Technologie Experte für Data Integration Data Warehousing, Data Mining, Business Intelligence, Big Data Technischer Direktor der sumit AG Seit 2011 Oracle ACE für DWH/BI in der Schweiz 4

5 Analytics - Definitionen Websters Dictionary: The field of data analysis. Analytics often involves studying past historical data to research potential trends, to analyze the effects of certain decisions or events, or to evaluate the performance of a given tool or scenario. The goal of analytics is to improve the business by gaining knowledge which can be used to make improvements or changes. Google: 5

6 International Standards organisation (ISO) - IOC/IEC 2382:2015 real time pertaining to the processing of data by a computer in connection with another process outside the computer according to time requirements imposed by the outside process Note 1 to entry: The term "real time" is also used to describe systems operating in conversational mode and processes that can be influenced by human intervention while they are in progress. Echtzeit - Definition 6

7 Analytics - Echtzeitaspekte Performance Schnelle Berechnung von Analyseergebnissen Flüssige interaktive Analysen, auch auf grossen Datenmengen Integration Schnelle Einbindung multipler Quellen in Analysen Analysen verschiedenster Daten und Formate, ohne langwierige Vorverarbeitung 7

8 Agenda Einführung Spaltenorientierte Datenbanken Oracle In-Memory Performance Integration Schlussfolgerungen 8

9 Vorteile Hervorragend für - scanning grosser Datenmengen - auf begrenzter Spaltenmenge - Berechnung von Aggregaten auf der Ergebnissen des Scans Hohe Kompression auf den meisten Spalten (ausser solchen, mit hohem Anteil unterschiedlicher Werte) Geeignet für OLAP, BI und Analytics allgemein 9

10 Nachteile (bisher) Manche Operationen teuer - DML - Queries über ganze Zeilen Nicht geeignet für OLTP Komplexe, neue DBMS-Infrastruktur muss aufgebaut werden - Speicher (-Management) - Sicherheit - Clustering - Disaster Recovery - 10

11 Wettbewerber Nischenanbieter - Exasol - HP Vertica - Infobright - Paracell Die üblichen Verdächtigen - Microsoft (Columnstore Indexes) - IBM - Teradata - und SAP/HANA 11

12 Agenda Einführung Spaltenorientierte Datenbanken Oracle In-Memory Performance Integration Schlussfolgerungen 12

13 Columnar Stores - Oracles Variante Column-Store transparent neben dem Row-Store gemanagt kein entweder-oder persistente Speicherung wie bislang zeilenbasiert Column-Store in Echtzeit DML-gesyncht die gesamte Oracle DB-Umgebung bleibt unverändert - Sicherheit - Backup - Disaster Recovery - RAC - Keine Anwendungsänderungen erforderlich! 13

14 Technologie-Leckerbissen 1. In-Memory Storage-Indexing 2. Daten filtern auf binär komprimierten Daten 3. Feingranulare Konfiguration des Speicherumfangs 4. Transparente Abfragen über die ganze Speicherhierarchie 5. Echtzeitkonsistenz des Columnar-Store bei DML 6. Parallele Abfrageverarbeitung 7. SIMD Vektorverarbeitung 8. In-Memory-Fehlertoleranz auf RAC 9. In-Memory-Aggregation 14

15 Spaltendaten werden in IM-Compression-Unitys gespeichert (IMCUs) In-Memory Storage-Indexe speichern Min/Max-Werte pro Spalte, pro IMCU IMCUs mit Min/Max-Wert ausserhalb eines Query-Pädikats können bei der Verarbeitung ignoriert werden v$mystat zeigt Informationen über die Anzahl gelesener vs. die Anzahl ignorierter IMCUs In-Memory Storage-Index Example: Find sales from stores with a store_id of 8 or higher Memory Min 1 Max 3 Min 4 Max 7 Min 8 Max 12 SALES Column Format Min 13 Max 15 15

16 SIMD Vector Processing Single-Instruction- Verarbeitung von Multiple- Data-Werten Auswertung einer Menge von Spaltenwerten innerhalb eines Instruktionszyklus der CPU Bringt das Potential die Verarbeitung auf Milliarden, anstatt nur Millionen Sätze pro Sekunde zu steigern Memory CPU Load multiple PROMO_ID values PROMO_ID VECTOR REGISTER Example: Find all sales With PROMO_ID Vector Compare all values in 1 cycle 16

17 In-Memory on RAC inklusive Fehlertoleranz Verteilung der In-memory-compressionunits (IMCUs) grosser Objekte automatisch (default) BY ROWID RANGE BY {SUB}PARTITION Fehlertoleranz (engineered systems only) DISTRIBUTE clause für redundante IMCU-Kopien auf Knoten DISTRIBUTE ALL = jede IMCU auf alle Knoten kopieren 17

18 Neue Optimizer-Transformation: Vector Group By Erinnert an die bekannte Star-Transformation Verarbeitung in 2 Phasen und 6 Schritten Phase 1 - Vorbereitung 1. Dimensionen scannen 2. Schlüsselvektoren bilden 3. Akkumulator vorbereiten 4. Tmp-Tabellen für Dim-Attribute bilden Phase 2 - Berechnung 5. Fakten bzgl. Schlüsselvektoren scannen 6. Gefilterte Fakten mit TMP-Tabellen joinen In-Memory Aggregation 18

19 In-Memory Aggregation - XPLAN 19

20 Die In-Memory-Option hat das Potential Queries extrem zu beschleunigen Insbesondere das scannen von Daten profitiert Joins & Vector-By-Aggregation werden ebenfalls beschleunigt Aber, es ist keine Zauberei, sondern Technologie Sortieren, klassisches aggregieren etc. werden nur begrenzt schneller Beurteilung Row Store Scan Data Aggregate In-Memory Scan Data Aggregate Row Store Scan Data Join / Sort / Group / Aggregate In-Memory Scan Data IM-Join / Sort / Group / Aggregate Scan Data IM-Join / Sort / Group / IMAgg t 20

21 Agenda Einführung Spaltenorientierte Datenbanken Oracle In-Memory Performance Integration Schlussfolgerungen 21

22 Auswirkungen auf Abfragearten Reporting queries - Einfache - SQL*Analytics (Tool-basiertes) OLAP Dimensionale Queries Schlüssel-Transformationen Statistikberechnungen 22

23 Einfache Report-Queries Query-Charakteristik wenige Joins Einfache one-step Aggregationen (falls überhaupt) viele Filterprädikate manchmal viele Zeilen und Spalten darzustellen Verarbeitung scanning im Columnar-Store nutzt IMCU Storage-Indexes join mittels Bloom-Filterung im Columnar-Store Scan- und Joinaufwand sehr viel grösser als anderer Aufwand SIMD-Instruktionen werden stark genutzt Auswirkungen von In-Memory hoher Performance-Gewinn aber Transferzeit zum Client u.u. signifikant bei vielen Ergebnis-Zeilen/-Spalten 23

24 SQL*Analytics Report-Queries Query-Charakteristik einige Joins komplexe analytische Funktionen viele Anwendungen von Filterprädikaten Verarbeitung scanning im Columnar-Store nutzt IMCU Storage-Indexes join mittels Bloom-Filterung im Columnar-Store Anteil von Operationen ausserhalb des Columnar-Store nimmt stark zu SIMD-Instruktionen werden genutzt Auswirkungen von In-Memory Performance-Gewinn, aber geringer, als für einfache Reporting-Queries 24

25 (Tool-basiertes) OLAP Query-Charakteristik sehr komplexe Abfragen Verkettung von With-Clause-Blöcken komplexe analytische Funktionen und Aggregationen Verarbeitung - kurze Scan-Zeit - schwierig für den Optimizer einen effizienten Plan zu finden - Materialisierung temporärer Ergebnisse bricht' die spaltenorientierte Verarbeitung - Nicht-columnar Berechnungsaufwand weit grösser, als der Columnar-Anteil Auswirkungen von In-Memory Performanzgewinn hängt von der Komplexität der Abfrage ab 25

26 Query-Charakteristik - wenige, einfache Joins (Star) - filtern auf den Dimensionen - Aggregation i.d.r. entlang der Dimensionsattribute - sehr grosse Faktenmenge - manchmal auch sehr grosse Dimensionen Technologie & Folgen - sehr kurze Scandauer Dimensionale Queries - Anwendung der neuen Vector-group-by-Transformation durch den Optimizer Auswirkungen von In-Memory sehr hoher Performance-Gewinn 26

27 Beschleunigung Von Report-Queries report type no of rows result set row store (SGA) columnar store times X simple 400K 35 10ms 2ms 5 join, top10 (analytics) dimensional (vector by) 14M & 55K 10 2s 1s 2 14M & 1.8K & s 0.8s 10 Demo vergleicht SGA zeilenbasiert vs. in-memory Columnar-Store Kleine Virtual-Machine Kein SIMD support in Demo-Umgebung Serielle Ausführung Wesentlich höhere Faktoren in Enterprise-Infrastruktur 27

28 Typisches Szenario - Reverse-lookups DWH-eigener Surrogate-Keys zu Business-Keys für Analysen/Data-Marts - Forward Lookups für DWH-Ladeprozesse - multiple (Outer)-Joins gegen DWH-Tabellen - typischer Fall von (Outer)-Joins ohne Aggregation Herausforderung - U.U. nicht alle Tabellen im Columnar-Store Strategie - nur benötigte Spalten in Columnar-Store (falls überhaupt) Schlüssel-Transformationen - geht mit Lookup-Tabellen in Spalten- und Driver-Tabellen in Zeilen-Format 28

29 Beispiel Schlüssel-Transformationen select s.invoicenumber, s.year, s.audit_id, s.cutoffdt, r.id invoice_id, m.id member_id from (select * from st_db_rechnung_in_t where rownum < ) s, db_rechnung_ht r, pv_mitglied_ht m where s.invoicenumber = m.invoicenumber (+) and s.invoicenumber = r.invoicenumber (+) and s.year = r.year (+) and s.invoiceitem = r.invoiceitem (+) and s.srcmodifieddt > SYSDATE return DWH-IDs und andere Attribute 1. scan Stagingtabelle 3. outer join an Lookup-Tabellen 2. nimm letzte 2 Jahre 29

30 Verkettung von Bloom-Filtern Id Operation Name Rows Bytes TempSpc Cost (%CPU) Time SELECT STATEMENT K 2848 (1) 00:00:01 * 1 HASH JOIN OUTER K 8008K 2848 (1) 00:00:01 2 JOIN FILTER CREATE :BF K 1090 (1) 00:00:01 * 3 HASH JOIN OUTER K 6840K 1090 (1) 00:00:01 4 JOIN FILTER CREATE :BF K 278 (1) 00:00:01 * 5 VIEW K 278 (1) 00:00:01 * 6 COUNT STOPKEY 7 TABLE ACCESS FULL ST_DB_RECHNUNG_IN_T K 278 (1) 00:00:01 8 JOIN FILTER USE :BF K 4637K 29 (7) 00:00:01 * 9 TABLE ACCESS INMEMORY FULL PV_MITGLIED_HT 395K 4637K 29 (7) 00:00:01 10 JOIN FILTER USE :BF K 17M 73 (13) 00:00:01 * 11 TABLE ACCESS INMEMORY FULL DB_RECHNUNG_HT 781K 17M 73 (13) 00:00: hash-join Bloom- Filter-Ergebnisse wg. falsch-positiver matches 2. kreiere Bloom-Filter auf Lookup-Tabellen 3. wende Bloom- Filter an 1. scan Stagingtabelle 30

31 Hintergrund - statistische Daten über Spalten, Partitionen, Tabellen, Indexe, etc. - wichtigster Input für den Cost-Based Optimizer - essential, um gute Ausführungsstrategien zu finden = gute Performance Herausforderung - Statistikberechnungen sind teuer - Wartungsfenster sind (immer) zu kurz Query-Characteristik - eine Tabelle, spaltenorientierte Queries - viel Scanning - zumeist einfache Funktionen Statistikberechnung 31

32 Statistikberechnung - Beispiel-Query SELECT /*+ no_parallel(t) no_parallel_index(t) dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring xmlindex_sel_idx_tbl no_substrb_pad */ COUNT(*), SUM(sys_op_opnsize("PROD_ID")), SUM(sys_op_opnsize("CUST_ID")), COUNT(DISTINCT "CHANNEL_ID"), SUM(sys_op_opnsize("CHANNEL_ID")), substrb(dump(min("channel_id"),16,0,64),1,240), substrb(dump(max("channel_id"),16,0,64),1,240), COUNT(DISTINCT "PROMO_ID"), SUM(sys_op_opnsize("PROMO_ID")), substrb(dump(min("promo_id"),16,0,64),1,240), substrb(dump(max("promo_id"),16,0,64),1,240), COUNT(DISTINCT "QUANTITY_SOLD"), SUM(sys_op_opnsize("QUANTITY_SOLD")), substrb(dump(min("quantity_sold"),16,0,64),1,240), substrb(dump(max("quantity_sold"),16,0,64),1,240), SUM(sys_op_opnsize("AMOUNT_SOLD")) FROM "SH"."MY_SALES" t; 4. Aggregationen 1. Spalten scannen 3. post-processing gescannter Spalten 2. scan einer Tabelle 32

33 In-Memory Statistikberechnung in In-Memory 1. In-Memory automatisch gewählt Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (27) 00:00:01 1 SORT GROUP BY TABLE ACCESS INMEMORY FULL MY_SALES 14M 336M 1070 (27) 00:00: With explicit NO_INMEMORY Hint 2. Switched 3. Grosser to row Kostenvorteil storage SGA, Flash, für IM Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (1) 00:00:01 1 SORT GROUP BY TABLE ACCESS FULL MY_SALES 14M 336M (1) 00:00: Wechsel auf Zeilen aus SGA, Flash oder Disk 33

34 Agenda Einführung Spaltenorientierte Datenbanken Oracle In-Memory Performance Integration Schlussfolgerungen 34

35 Information Mgmt Referenzarchitektur In-Memory Big Data 35

36 Warum In-Memory mit Big Data integrieren? Integration von Daten in einen (In-Memory)-Data-Mart braucht Zeit macht Arbeit verursacht Kosten Big Data Analytics bedeutet spezielle Tools (ein Zoo) spezielle Skills benötigt langsamer Datenzugriff Security ist ein Albtraum Lösung: Big Data SQL = direkter SQL-Zugriff auf Big Data durch Run-Time-Integration mit der Oracle Datenbank und damit auch In-Memory 36

37 Big Data SQL Query Execution Hadoop nodes 37

38 Big Data SQL - Smart Scan 1. Liest Daten auf dem HDFS-Knoten - Direct-path reads - C-basierte Reader wenn vorhanden - sonst native HADOOP-Klassen 2. Übersetzt Bytes zu Oracle 3. Smart scan in Oracle-Format - wendet Storage Indexe an - filtert - projiziert Spalten - parst JSON/XML - berechnet Scoring-Modelle 38

39 Optimizer Database optimizer und Execution Engine sind der Schlüssel Transformer: - neue Transformationen Estimator: - neue Kostenschätzmodelle Execution engine: - neue Calls und APIs Nur möglich, weil Oracle alle Implementierungen und APIs kontrolliert 39

40 Agenda Einführung Spaltenorientierte Datenbanken Oracle In-Memory Performance Integration Schlussfolgerungen 40

41 Schlussfolgerungen Oracle In-Memory-Option ist entscheidend für Real-Time Analytics im Gegensatz zu Nischenanbietern ist sie absolut enterprise-ready im Gegensatz zu den grossen Konkurrenten sind keine Modifikationen notwendig Deshalb bietet In-Memory einen grossen Leistungssprung mit - geringen Risiken - geringen Projekt-, Infrastruktur-, Wartungs- & Entwicklungskosten Integration mit Big Data ist einfach und effizient Aber, In-Memory ist keine eierlegende Wollmilchsau Abfragekomplexität bestimmt den Performance-Gewinn Gutes Design der ETL-Prozesse & Analysen bleibt wichtig Kraftvolle Infrastruktur ist notwendig (zum Beispiel Oracle Engineered Systems) 41