caching: in-memory column store oder im bi server

Caching:In-Memory Column Store oder BI Server?

Andreas Buckenhofer / Analytics / Daimler TSS

1Caching: In-Memory Column Store oder BI Server? | Analytics | 18-Nov-2015

Zur Person

Caching: In-Memory Column Store oder BI Server? | Analytics | 18-Nov-2015

Andreas Buckenhofer

Senior DB ProfessionalE-Mail: [email protected]

Seit 2009 bei Daimler TSS

im Fachgebiet Data Warehouse & Data Integration (Cognos/Informatica) –Department Analytics

Schwerpunkt DWH/CRM seit 1998 als

• Entwickler

• Administrator

• Berater

Daimler TSS IT-Exzellenz: Ganzheitlich, innovativ, nah

Wir sind Spezialist und strategischer Business-Partner für innovative IT-Lösungen im Daimler-Konzern. Als

100%ige Daimler-Tochter leben wir die Kultur der Exzellenz mit dem Anspruch der Innovations- und

Technologieführerschaft.

Mit herausragender Technologie- und Methodenkompetenz verstehen wir uns als kompetenter Anbieter von wettbewerbsdifferenzierenden IT-Dienstleistungen. Unsere Geschäftspartner im Konzern begleiten wir lösungsorientiert im Rahmen eines ganzheitlichen Ansatzes.

Wir denken und arbeiten partnerschaftlich und agil, sind technologieneutral und hersteller-unabhängig. Das macht uns frei für maßgeschneiderte End-to-End-Lösungen mit hoher Effektivität. Die Aufnahme wichtiger Trends und Impulse von außen zusammen mit dem tiefen Verständnis der Daimler-Geschäftsprozesse garantieren eine umfassende Sicht und überzeugenden Mehrwert.

Unser Anspruch ist es, die Geschäftsprozesse, die Wettbewerbsfähigkeit und die Innovations-kraft von Daimler mit marktführenden IT-Lösungen voranzutreiben. Als attraktiver Arbeitgeber wollen wir mit Menschen arbeiten, die durch unser Unternehmen und das menschlich geprägte Umfeld inspiriert sind ihr Bestes zu geben und mit uns ihr volles Potential zu entwickeln.


Standorte Daimler TSS



Ganzheitliche Betreuung (Erhebung, Auswertung, Visualisierung und Interpretation), unabhängige Beratung und Optimierung der Geschäftsabläufe.

Von klassischer BI bis hin zu predictive und prescriptiveAnalytics bieten wir Leistungen unter Berücksichtigung der Datensicherheit.

Dabei verknüpfen wir fachliche Erfahrung und IT-Know-how im Daimler-Kontext mit dem Blick fürs große Ganze.

Analytics. Das große Ganze verstehen, um Daten nutzbar machen.

Gliederung

Motivation und Konzepte spaltenorientierter In-Memory DBs (IMDB)

OLAP/Cognos In-Memory Cubes und IMDB

Testszenario und –durchführung mit Oracle

Erkenntnisse/Folgerungen

Zusammenfassung


DWH Reference Architecture


Backend

Frontend

Acquisition Layer (Input Layer)

Core Warehouse Layer (Storage Layer)

Information Mart Layer (Output Layer)

Ad-hoc Reporting

Standard Reporting

Dash-boards

Predictive Analytics

PrescriptiveAnalytics

Star OLAP

3NF Data Vault

Keine FK, PKFlat

DWH Reference Architecture PoC


Backend

Frontend




Cognos BI Cognos SPSS / R

Star Cognos Cubes

Data Vault

Keine FK, PKFlat

Information und Analytics Mart Layer

Ausgangssituation/Fragestellung im Projekt:

• Modellierung: Relationales Starschema mit In-Memory DB oder weiterhin Nutzung von Cubes?

• Analysen / Reporting direkt auf Core Warehouse Layer möglich (= performant)?


In-Memory … nicht neu

Datenbank Buffer Cache

Datenspeicherung auf RAM-Disk

Datenspeicherung auf SSD

OLAP In-Memory Cubes

Datenanalyse mit Qlikview, TM1, u.a.


In-Memory - Cache Latenz


Quelle: Brendan Gregg: “Systems Performance: Enterprise and the Cloud”

Flüchtig

Nicht flüchtig

„In-Memory“

Festplatte

Datenverteilung, z.B. partitionierte Umsatzdaten

In-Memory – Speicherhierarchien Kosten vs Nutzen


Festplatte SSD RAM1/2015

2/2015

…

1/2013

…

12/2014

<= 12/2012

Wenig genutzte Daten

Häufig genutzte Daten

Spaltenorientierung … nicht ganz so neu


1993 1995 > 2004

KDBSybase IQ

(heute SAP)

Relational:MonetC-StoreVertica

Greenplum(Nicht-Relational:

BigTableHBASE

Cassandra)

Spaltenorientierung: Speicherung Zeilen- vs Spalten


Id Name Geburtsdatum

1 Maier 1967

2 Schmitt 1980

3 Maier 1993

4 Berger 1980

5 Müller 1967

6 Maier 1970

7 Müller 1980

Spaltenorientierte Speicherung

1, Maier, 1967, 2 Schmitt, 1980, 3

Maier, 1993, 4, Berger, 1980, 5

Müller, 1967, 6, Maier, 1970, …

1, 2, 3, 4, 5, 6, 7, …

Maier, Schmitt, Maier, Berger,

Müller, Maier, Müller, …

Zeilenorientierte Speicherung

Block / Page / In-Memory Unit

Zeilen- vs Spaltenorientierung: Vor und Nachteile


Zeilenorientierung Spaltenorientierung

Vorteile • Datensatz wird zusammen abgespeichert

• Einfache/PerformanteUpdates und Deletes

• Select auf eine oder mehrere Spalten liest keine unnötigen Spalten

• Spalte kann als Index verstanden werden

Nachteile • Es wird der gesamte

Datensatz gelesen – auch

wenn nur einzelne Spalten

benötigt werden

• Nach der Selektion muss ein Datensatz aus den einzelnen Spalten rekonstruiert werden

• Inperformante Datenänderungen

• Cache-Aufbau

Vorteil: Komprimierungsverfahren je nach Datentyp


Dictionary Encoding

• Zentrale Wörterbücher zur Kodierung.

Run-length Encoding

• Mehrfache Wiederholungen werden durch ein Anzahl-Attribut kodiert.

Null-Suppression

• Unterdrückung von Nullwerten.

Bit-Vector

• Kodierung von 0 bzw1 für eine vorhandene bzw. nicht vorhandene Ausprägung.

Vorteil: Data Skipping (Column Store Storage Index)


• Automatische Registrierung minimaler und maximaler Werte in einer IMU

• „Interner Index“: Ignorieren/Überlesen nicht relevanter Pages

Cache mit InMemory Units (IMU)

1,9,20,34,4,100,…Min: 1 Max: 100

22,1,19,34,4,10,…Min: 1 Max: 34

SQL-Abfrage

SELECT …FROM …WHERE spalte > 50

72,60,60,61,60,69,…Min: 60 Max: 72

32,44,30,50,50,…Min: 30 Max: 50

skip

Vorteil: SIMD-Prozessoren (Single Instruction Multiple Data)


CPU

VectorRegister

z.B. where x=12

112

312

55

1212

12

12

1212

Cache (RAM)

112

312

55

1212

Zusammenfassung Auswahl Konzepte

Spaltenorientierte IM DB

RAM (In-Memory)

Spalten-orientierung

KomprimierungData Skipping

SIMD


Gliederung





Zusammenfassung


OLAP Cubes

Multidimensionales

Format


OLAP Cubes

• Multi-dimensionales Datenarray „Würfel“

• Fakten, Dimensionen, Hierarchien, Aggregate

• Eine Struktur ohne Joins

• Ziel: schnell / interaktiv

• KPIs (Kennzahlen) nötig + Dimensionen

• Typisch für BI Reporting, aber auch inflexibel

• Beladung meist mittels Batch


Kunde

Prod

ukt

KPIUmsatz

Cognos Dynamic Cubes

• In-Memory OLAP-Würfel, die Daten direkt aus relationalen DBs laden

• Voraussetzung: Star-Schema oder Snowfalke-Schema (Views möglich, aber nicht empfohlen)

• In Cognos BI integriert– keine seperate Installation oder Lizenz

• Verschiedene Caches


Cognos Dynamic Cubes – Cache Hierarchie


Cognos Dynamic Cubes – Cache Hierarchie


Start Cube

• Member Cache wird komplett geladen• Aggregate Cache wird komplett

geladen

Reporting/Daten-Analyse

• Weitere Caches werden nach Bedarf geladen

• Sobald Cache voll ist, werden Daten aus DB gelesen

Oracle

Das duale Format in der Datenbank


Oracle – Buffer Cache (row) and IMDB (columnar)


Quelle: Guy Harrison: “Next Generation Databases”

Gliederung





Zusammenfassung


Testszenario mit Oracle DB

Daten: 60GB komprimiert sowie RAM: 60GB

• Testlauf 1: Zeilenorientierte Speicherung „Baseline“ mit Basic compression

• Testlauf 2: Spaltenorientierte Speicherung „Vergleich“ mit Low compression

• Verschiedene parallele Abfragen (simulieren User-Parallität)

• 3 Datenmodelle


Testzenario – 3 Datenmodelle


Data Vault

Strukturierte Modellierung für das Core Warehouse

Star

Fakten und Dimensionen

typisch für Data Mart

Layer

Flat

Flache Tabelle =

MeinExcel

Testzenario – 3 Datenmodelle (Auszug Datenmodell)


Data Vault Star Flat

Testszenario – Abfragen (Beschränkung auf Standard-Abfragen)

Typ 1•Simuliert Report-Einstieg•Keine where-Bedingung, Aggregation auf höchster Ebene

Typ 2•Simuliert Drill Down von Typ 1•1-2 where-Bedingungen

Typ 3•Simuliert Drill Down von Typ 2•3-4 where-Bedingungen


4 parallele Sessions

führen Abfragen aus in der Reihenfolge

Typ1->Typ2->Typ3->Typ3->Typ2->Typ3->Typ3

Verhältnis Häufigkeit Typ1:Typ2:Typ3 = 1:2:4



• Testlauf 1: Zeilenorientierte Speicherung „Baseline“ mit Basic

compression

• Testlauf 2: Spaltenorientierte Speicherung „Vergleich“ mit Low compression


• 3 Datenmodelle33Caching: In-Memory Column Store oder BI Server? | Analytics | 18-Nov-2015

0

10

20

30

40

50

60

70


Buffer CacheLaufzeit (sek)

Buffer CacheGröße (GB)

Testlauf 1: zeilenorientierte Speicherung, Cache


3 1 1 2 32

Testlauf 1: Bewertung

Ergebnis bestätigt die Erwartungen: Star Schema performant für Reporting

Star Schema (= empfohlene Modellierung für Standardreports im Data Mart)

• Klar beste Performanz und sehr gute Komprimierung (kleine Indexe)

Data Vault (eine mögliche Modellierung im Core Warehouse Layer)

• Schlechte Leseperformanz, da für Beladung optimiert

• Hash Keys verwendet, daher relativ großer Speicherverbrauch

Flat

• Hohe Datenmenge aufgrund großer Redundanz




• Testlauf 1: Zeilenorientierte Speicherung „Baseline“ mit Basic compression

• Testlauf 2: Spaltenorientierte Speicherung „Vergleich“ mit Low

compression


• 3 Datenmodelle36Caching: In-Memory Column Store oder BI Server? | Analytics | 18-Nov-2015

0

5

10

15

20

25

30


IMDBLaufzeit (sek)

IMDBGröße (GB)

Testlauf 2: spaltenorientierte Speicherung, Cache


3 2 1 1 23

Vergleich Testlauf 1 und Testlauf 2


0

5

10

15

20

25

30

35

40

45


Buffer CacheLaufzeit (sek)

IMDBLaufzeit (sek)

0

10

20

30

40

50

60

70


Buffer CacheGröße (GB)

IMDBGröße (GB)

Laufzeit Cache Größe

Testlauf 2: Bewertung 1(2)

Ergebnis (Anmerkung: Indexe gelöscht außer PK, UK, FK)

Star Schema

• Gute Performanz und gute Komprimierung

Data Vault

• Performanzverbesserung beim Lesen

Flat

• Beste Performanz in diesem Beispiel! Jedoch nicht unbedingt empfehlenswert zukünftig so zu modellieren!


Testlauf 2: Bewertung 2(2)

• Testläufe sind nicht beliebig zu verallgemeinern, zeigen aber Vor/Nachteile auf. Es gibt auch Ausreißer.

• Ergebnis stark abhängig von Anzahl Typ1 / Typ2 / Typ3 Abfragen

• Viele Typ3-Abfragen = gut für Spaltenorientierung und Flat-Tabellen

• Viele Typ1-Abfragen = geringer/kein Vorteil für Spaltenorientierung

• Testen, Testen, Testen bei Migration in eine spaltenorientierte In-Memory DB.

• Nicht immer Performanzvorteile

• Oft ist das Problem in der Anwendung und nicht in der DB


Gliederung





Zusammenfassung


• Data Vault Hub-Tabelle H_CUSTOMER mit Hash-Keys

• Schmale Tabelle mit eindeutigen Hash-Keys und eindeutigen Business-Keys

• Tabellen mit solchen Daten (nicht nur bezogen auf Data Vault) sind ungeeignet für Dictionary-Compression

Ausreißer Komprimierung am Beispiel Hub-Tabelle

Größe in GB Verfahren

9 GB Buffer Cache, Basic compression

9.7 GB (größer!) IMDB, FOR QUERY LOW compression

8.4 GB IMDB, FOR QUERY HIGH compression


Allgemeine Faustformel

The greater the ratio of

the total data accessed by a query to

the data actually processed by the query,

the greater the potential benefit from IMDB.

Quelle: Oracle White Paper: When to use Oracle IMDB


Anzahl selektierter Spalten


Beschreibung Gut geeignet für

Spalten InMemory

Weniger geeignet für

Spalten InMemory

Je mehr Spalten abgefragt werden, umso geringer ist der Vorteil des spaltenorientierten Zugriffs. Bei der

Modellierung im BI Tool

darauf achten, dass nicht

automatisch select *

verwendet wird

SELECT cust_name FROM customer;

SELECT * FROM customer;

Anzahl zurückgelieferter Zeilen


Spalten InMemory


Spalten InMemory

Je mehr Zeilen zurückgeliefert werden, umso geringer ist der Vorteil des spaltenorientierten Zugriffs, da die Werteübergabe zum BI

Server und der

Berichtaufbau die Performanz dominiert.

SELECT sum(revenue) FROM sales;

SELECT revenue FROM sales;


Komplexe SQL-Funktionen (Expressions)


Spalten InMemory


Spalten InMemory

Rechenintensive SQL-Funktionen sind weniger geeignet, da die Performanz für die Berechnung benötigt wird.

SELECT I.id, sum(S.revenue)FROM Sales S, Items I WHERE S.item_id = I.id AND I.name LIKE “%LED%TV”GROUP BY I.id;

SELECT I.id, sum(S.revenue)FROM Sales S, Items I WHERE S.item_id = I.idAND MyMatch(I.name,”LEDTV”)=1GROUP BY I.id;


DWH Reference Architecture PoC


Backend

Frontend




Cognos BI Cognos SPSS / R

Star Cognos Cubes

Data Vault

Keine FK, PKFlat

Use Case: Standardreporting

IMDB Cognos Dynamic Cubes (OLAP)

Skalierbar Skalierbar

Wenn IMDB-Cache voll, wird der Buffercache verwendet

Nur Membercache und Aggregatecachekritisch (alle Daten müssen reinpassen). Faktendaten müssen nicht in den Cache (Abhängigkeit von der DB-Performanz; IBM empfiehlt Einsatz IMDB)

DML-Operationen verlangsamen Aktualität Kompletter Refresh: dauert täglich länger mit größer werdender Datenmenge (RealTime Differential Refresh möglich)


Use Case: Ad-hoc Reporting


• Cubes sind nicht für ad-hoc geeignet. OLAP Cubes setzen bekannte Abfragen voraus, deren Daten zuvor festgelegt/implementiert werden müssen.

Use Case: Flexibilität und Virtualisierung


• Information / Analytics Mart Layer besteht nur aus Views auf Tabellen im Core Warehouse Layer

• Einschätzung nach Performanztests: Vereinzelt machbar mit guter Performanz

Gliederung





Zusammenfassung


OLAP Cubes / Cognos Dynamic Cubes

Use Cases werden weniger

• Sinnvoll bei rechenintensiven KPIs (Aggregation, Expression Cache)

• Sinnvoll, wenn Abfragen komplett feststehen (reines Standardreporting)

• Keine weitere Lizenz nötig sobald Cognos BI lizensiert

• Cognos Dynamic Cubes: Nicht alle Daten müssen im Cache gehalten werden (nur Member + Aggregate)

• Zugriff auf DB bei Daten, die nicht im Cognos Cache sind

• Performanz schwankt, je nach DB-Performanz52Caching: In-Memory Column Store oder BI Server? | Analytics | 18-Nov-2015

OLAP, OLTP und OLTAP

OLAP

OLTP

OLTAP –

gemischte

Workloads


• großes Potential für spaltenorientierte In-Memory DBs

• auch mit reinen Views als Data Marts denkbar („Datenvirtualisierung“)

• vereinzelt sinnvoll, z.B. große Stammdatentabellen

• große Herausforderung in der Vergangenheit

• Potential für spaltenorientierte In-Memory DBs

• aber: gegenläufiger Trend Microservices = „kleinere“ DBs

One size does not fit all

„In 10 years there will be no row

stores in the data warehouse world.“

Quelle: Stonebreaker, O'Reilly webcast http://radar.oreilly.com/2015/06/the-future-of-data-at-scale.html


Vielen Dank!


Daimler TSS GmbH

Wilhelm-Runge-Straße 1189081 UlmTelefon +49 731 505-06Fax +49 731 505-65 [email protected]

Internet: www.daimler-tss.com

Daimler TSS GmbHSitz und Registergericht: Ulm, HRB-Nr.: 3844 Geschäftsführung: Dr. Stefan Eberhardt (Vorsitzender), Steffen Bäuerle

Jobportalhttps://jobs.daimler-tss.de/PORTAL/jobs.html z.B.:

In-Memory: IBM, Microsoft, Oracle, SAP 1(3)

SQL Server IBM DB2 BLU Oracle IMDB SAP HANA

Ersteinführung 07/2014 06/2013 04/2014 10/2010

Befehl zur

Erzeugung der

spaltenorienti

erten Tabelle

Create index … Create table … Eigenschafteiner Tabelle

Create table …




Datenkomprim

ierung

Ja Ja Ja Ja

Data Skipping Ja Ja Ja Ja

Datenhaltung • Zeilen (In-Memory OrganizedTables)

• Spalten (Columnstore Index)

• Zeilen und Spalten (Column-organizedTables oder Schattentabellen)

• Zeilen und Spalten simultan (BufferCachefür Zeilen)

• Zeilen und Spalten (Spalten präferiert)




In-Memory

Analytics / R

Ja Nein Ja Ja

Persistenz

Columnstore

Ja Ja Nein Ja

Aggregate

Pushdown

Ja (ab 2016) Ja

Limitierung

durch RAM

Nein Nein Nein Nein (nicht mehr)

SIMD Ja Ja Ja Ja


1 Technologie - 4 Hersteller – 4 Implementierungen

Spaltenorientierte IM DB

RAM (In-Memory)

Spalten-orientierung

KomprimierungData Skipping

SIMD


SAP HANA

Aufhebung Trennung operative

(OLTP) und analytische (OLAP)

Workloads


Workload OLTP und OLAP


Quelle: http://www.vldb.org/pvldb/vol5/p061_jenskrueger_vldb2012.pdf

SAP Hana


Eine Tabelle ist entweder

zeilenorientiert oder

spaltenorientiert.Row Store

Column Store Delta L2 Delta L1

Select + DML

DML

Select

Logs Snapshots

IBM DB2 BLU

Seven Big Ideas


IBM DB2 BLU – 7 Big Ideas


Big Idea 1: Simplicity and ease of use

Big Idea 2: Column store

Big Idea 3: Adaptive compression

Big Idea 4: Parallel vector processing (SIMD)

Big Idea 5: Core-friendly parallelism

Big Idea 6: Scan-friendly memory caching

Big Idea 7: Data skipping

IBM DB2 BLU – Variante 1: OLAP


Eine Tabelle ist entweder


spaltenorientiert.

IBM DB2 BLU – Variante 2: OLTAP (Schattentabellen)


Eine Tabelle ist zeilenorientiert

und spaltenorientiert.

MS SQL Server

Dedizierte In-Memory stores für

OLTP und OLAP


MS SQL Server – NonClustered Columnstore Index


Eine Tabelle („Index“) ist

zeilenorientiert und

spaltenorientiert.

MS SQL Server – Clustered Columnstore Index


Eine Tabelle („Index“) ist entweder


spaltenorientiert.

Oracle

Das duale Format in der Datenbank


Oracle – Buffer Cache (row) and IMDB (columnar)


Row Store Column Store

Logs Datendateien

Eine Tabelle ist zeilenorientiert

und spaltenorientiert.

Row Store

DML

Select

Cognos Cube Technologien


RDBMS vs OLAP vs IMDP

Datenmodell Abfrage-

Sprache

Interaktion Vorteile

RDBMS Star-Schema SQL Abfrage und Antwort

SkalierbarFlexibel

OLAP Cube MDX Interaktiv Performant

IMDB Star-SchemaOder andere relationale Form

SQL Interaktiv SkalierbarFlexibelPerformant


RDBMS (In-Memory) nähert sich OLAP Cubes an (interaktiv, schnell)

Selektivität von Join-Bedingungen


Spalten InMemory


Spalten InMemory

Selektive Join-Bedingungen nutzen den Vorteil des schnellen Filterns von Daten.

SELECTS.id, P.name, S.revenueFROM Sales S, Products P WHERE S.prod_id=P.id AND P.type=‘Footwear’;

SELECTSi.d, S.revenue, P.nameFROM Sales S,Products P WHERE S.prod_id=P.id;


Anzahl der Tabellen im Join


Spalten InMemory


Spalten InMemory

Je größer die Anzahl der Tabellen im Join ist, umso geringer ist der Vorteil, da die Performanz für den Joinbenötigt wird.

Aber typisch im Reporting!

SELECT <select list>FROM Sales, Products, CustomersWHERE <join condition>

SELECT <select list>FROM Sales, Products, Customers, Shipments, Stores, Suppliers, WarehousesWHERE <Join Condition>


Selektivität von Spalten-Prädikaten


Spalten InMemory


Spalten InMemory

Selektive Prädikate nutzen den Vorteil des schnellen Filterns von Daten.

SELECT MEDIAN(revenue) FROM Sales WHERE revenue < 2;

Vorteilhaft, da weniger Zeilen und dadurch weniger Daten für die Median-Berechnung nötig sind.

SELECT MEDIAN(revenue)FROM Sales WHERE revenue > 2;


OLTP - Mögliche Anwendungsfälle

Sinnvoll bei

• Größeren Stammdatentabellen

• Weniger Indexe

• Vermeidung ständiges Tuning dieser Tabellen

• Klassiker: Adress-Suche (siehe folgendes Beispiel)


Klassiker: Adress-Suche

Kunden-Tabelle Adress-Tabelle

Kundennummer Ort

Vorname PLZ

Nachname Straße

Geburtsdatum Kundennummer

etc etc


Herausforderung Suchabfrage: Müller AND Berlin

Buckenhofer: ca. 100

Müller: ca. 700.000

Berlin: ca. 3.5 Mio

Dornstadt: ca. 8.500


Buckenhofer

Berlin Müller Dornstadt

Müller Berlin

21 12

? ?

1 2 = Reihenfolge der Abarbeitung / JoinsKleine Tabelle zuerst

Lösungsansätze Adress-Suche

• Materialized Views

• Text Index

• Bitmap Join Index

• Index Backbone Join: Patent US8103658 (Lothar Flatz, Bjorn Kisbye Engsig) http://www.google.com/patents/US8103658

• Spaltenorientierte In-Memory DB


Zusammenfassung Konzepte


Rohdaten Komprimierung Spalten Skipping SIMD

caching: in-memory column store oder im bi server

Data & Analytics