Spark, Impala und Hadoop in der Kreditrisikoberechnung: Big Data

Spark, Impala und Hadoop in der
Kreditrisikoberechnung
Big Data In-Memory-Technologien für mittelgroße
Datenmengen
TDWI München, 22. Juni 2015
Joschka Kupilas, Data Scientist, Adastra GmbH
2
Inhalt
 Vorwort
 Projektbeschreibung
 Über Hadoop
 Spark und andere Hadoop Tools
 Ergebnisse des Projekts
 Zusammenfassung und Lessons Learned
3
Kurze Umfrage...
> 1 PB Daten?
Berechnung zu langsam?
4
Big Data überall...
5
...wirklich?
 Wahr:

Mehr Daten

Neue Technologien ermöglichen Nutzung großer Datenmengen
 Aber:

Nur manche Firmen haben so große Datenmengen

90% aller Probleme: „Small/Medium Data“


Mit fortschreitender Technik: „Small“ = Immer mehr GB
Trotzdem zeitaufwändige Berechnung!
 ⇒ Hadoop für Medium Data!
6
Inhalt
 Vorwort
 Projektbeschreibung
 Über Hadoop
 Spark und andere Hadoop Tools
 Ergebnisse des Projekts
 Zusammenfassung und Lessons Learned
7
Beispiel für „Hadoop für Medium Data“
 Proof-of-Concept Projekt für große deutsche Bank
 Berechnung von Kreditwerten
 Hadoop statt Datenbank + Rechenkern
 „Mittelgroße“ Datenmenge
8
Beispielprojekt: „Treiberanalyse“
13 Millionen Kredite


9
Wert eines Kredits ist Funktion von

Ausfallwahrscheinlichkeit

Laufzeit

Betrag

Restbetrag

Währung

…

Anderen Krediten derselben Person/Firma
Berechnung enthält

mathematische/statistische Formeln

Aggregationen, Suchen, Joins
Berechnung der Kreditwerte
Person B
Person A
10
Kredit 1
Kredit 2
Kredit 3
P( Ausfall ) = 0.01
P( Ausfall ) = 0.02
P( Ausfall ) = 0.03
Gesamt: 50.000 €
Gesamt: 10.000 €
Gesamt: 100.000 $
Rest: 20.000 €
Rest: 3.000 €
Rest: 75.000 $
Laufzeit: 60 Monate
Laufzeit: 48 Monate
Laufzeit: 120 Monate
Restlaufzeit: 23 Monate
Restlaufzeit: 6 Monate
Restlaufzeit: 60 Monate
Wert: 18.789€
Wert: 2.265€
Wert: 45.823€
Veränderung der Kreditwerte nach „Treibern“
01.03.2015
01.04.2015
Kredit 3
Kredit 3
P( Ausfall ) = 0.03
+ 0.02
Gesamt: 100.000 $
Rest: 75.000 $
Gesamt: 100.000 $
-1.500$
Laufzeit: 120 Monate
Restlaufzeit: 60 Monate
Rest: 73.500 $
Laufzeit: 120 Monate
- 1 Monat
Wert: 45.823€
Restlaufzeit: 59 Monate
Wert: 36.723€
-9.100€
11
P( Ausfall ) = 0.05
Einfluss der Faktoren (Treiber)
 Fragestellung:

Welcher Faktor hat wieviel zur Veränderung beigetragen?

Einfluss von Teilmengen der Faktoren?
 13.000.000 Kredite × 30 Treiberteilmengen
⟹ hunderte Millionen ähnliche Berechnungen
⟹ Sehr gut parallelisierbares Problem!
 Datenmenge: 5GB pro Zeitscheibe

12
⟹ Kein „Big Data“
Bisherige Situation
 64 Kerne
Rechenkern
DB1
Rechenkern
DB2
DB3
2 Stunden
13
 256 GB RAM
Rechenkern
 $$$$$
DB1
 Sybase IQ
 $$$$$
Idee:
Hadoop
(Spark/Impala)
DB1
 Kostenlose Software
DB1
< 2 Stunden?
14
 Günstige Hardware
Verfügbare Resourcen
Gesamtkosten für
Hardware: ≈ 3000 €
15
Inhalt
 Vorwort
 Projektbeschreibung
 Über Hadoop
 Spark und andere Hadoop Tools
 Ergebnisse des Projekts
 Zusammenfassung und Lessons Learned
16
Ganz Früher
17
CPU Geschwindigkeit stagniert
18
Cluster
19
Vorteile von Hadoop
 Im Vergleich zu Einzelrechnern:

Ausfallsicherheit

Erweiterbarkeit & Zukunftssicherheit

Zeitersparnis/Performance
 Im Vergleich zu „klassischen Clustern“:
20

Kostenersparnis

Einfachere Entwicklung
Hadoop Ökosystem
 Dateisystem

HDFS (oder Amazon S3,…)
 Low-Level Programmier-Framework zur Parallelisierung

MapReduce, Spark, ...
 High-Level Programmiersprachen

22
Impala, Hive, ...
Hadoop HDFS:
Hadoop
Distributed
File
System
 Dateisystem verteilt auf den Nodes des Clusters
 Ausfallsicherheit: Redundante Speicherung
 Ein Name-Node (verwaltet Metainformation)
 Viele Data-Nodes (speichern Daten)
23
24
HDFS
25
HDFS
26
HDFS
27
HDFS
29
Programmier-Paradigma “MapReduce”

Map-Funktion: Die gleiche Berechnung auf vielen Objekten


30
Input -> (Key, Value)
Reduce-Funktion: Aggregation der obigen Resultate

Sortieren nach Keys

Aggregieren der Values
Map:
f(x) = <sign(x),2x>
31
Reduce:
Sum(x)
Wert
Key Value
4
+
8
-2
-
-4
3
+
6
1
+
2
5
+
10
-3
-
-6
Key
Value
+
26
-
-10
Map
32
𝑓
=
𝑓
=
𝑓
=
𝑓
=
𝑓
=
Sort &
Shuffle
Reduce
Σ
Σ
Σ
Publikumsaufgabe
 Map:

Input: Text

Output in (key, value)-Paaren:


Paar („Vokale“, #Vokale) (inkl Ä,Ö,Ü,Y)

Paar(„Konsonanten“, #Konsonanten) (inkl ẞ)

Paar(„Satzzeichen“, #Satzzeichen)
* = Zuständigkeit des „Nodes“ für einen Block
 Sort & Shuffle:

Durchreichen zum „Reducer“ für Vokale, Konsonanten, Satzzeichen
 Reduce:

33
Summieren der Werte je Key
MapReduce: Berechnungszyklus
HDFS
CPU &
Netzwerk
HDD I/O
≈ 1 sec
Lokales
Dateisystem
Map
CPU &
HDD I/O
34
RAM
Gute Probleme für Hadoop
 Viele „Objekte“ vom selben Typ
 Unabhängige gleichartige Berechnungen
 Danach Aggregation der Ergebnisse (wenn gewünscht)
 Beispiele:
35

Welche und wieviele Webseiten (Textdateien) enthalten ein bestimmtes Wort?

Welche Benutzer könnten – laut ihren Interessen – auf eine Werbung klicken?
Ergebnis
Vokale
36
Konsonanten
Satzzeichen
Nachteile von MapReduce
 Starres Programmierkonzept: Alles in Map und Reduce ausdrücken

↦ Entwicklung von Higher-Level-Programmiersprachen (Pig, Hive, Impala...)
 Programmierung nur in Java
 Map ↦ Reduce ↦ HDFS: Langsam für iterative Algorithmen

37
Z.B. In Machine Learning relevant
Inhalt
 Vorwort
 Projektbeschreibung
 Über Hadoop
 Spark und andere Hadoop Tools
 Ergebnisse des Projekts
 Zusammenfassung und Lessons Learned
38
 „Nachfolger“ von MapReduce

39

Früher „Map“, jetzt „Transformation“

Früher „Reduce“ , jetzt „Action“
Unterschiede:

verteiltes Dateisystem ↦„verteiltes RAM“ ⇒ In-Memory

Lazy Evaluation

Mehrere Programmiersprachen
Spark: Grundbegriffe
 RDD: Ähnlich List, Array:… Viele Objekte des selben Typs

RDD<int>, RDD<String>…

Verteilt im RAM der Cluster Nodes
 Transformation: RDD<A> → RDD<B> parallel auf alle Elemente angewendet

f(x) = x*2
RDD<float> → RDD<float>

Filter()
RDD<X> → RDD<X>
 Actions: RDD<C> → einzelner Datentyp

Sum()
RDD<float> → float
 Ergebnisse von Transformations bleiben im RAM, Ergebnisse von Actions
können in HDD gehen
40
Spark: Funktionsweise
 Sourcecode wird von Spark:

analysiert

umstrukturiert

in Java ByteCode umgewandelt, auf JVM ausgeführt

automatisch parallelisiert
 Spark baut Abhängigkeitsgraphen
 „Lazy Evaluation“: Code wird erst/nur ausgeführt, wenn benötigt
41

Nur Daten die benötigt werden, werden berechnet

Filter: Vielleicht müssen gar nicht alle Daten geladen werden

First: nur das erste Element das passt muss geladen werden
Sourcecode: Python
42
Umwandlung in Abhängigkeitsgraphen
moby_dick.txt
RDD
Other Data
textfile()
transf
action
map()
vokale
sum()
int
map()
konsonanten
sum()
int
map()
satzzeichen
sum()
int
filter()
a_zeilen
text
43
Spark: Berechnungszyklus
HDD I/O
Laden
RAM
HDFS
≈ 1 ms
Action
CPU &
HDD I/O
44
CPU
(& Netzwerk)
Warum Spark?
 Datenmenge klein genug für RAM
 Spark schneller als MapReduce
 Popularität
 Auswahl aus mehreren Programmiersprachen
 Bibliotheken

45
SQL, Machine Learning, Graphen, Streaming…
Spark: Nachteile
 Noch nicht viel Wissen öffentlich verfügbar
 Bibliotheken: Bugs und unvollständige Dokumentation
 Debugging aufgrund von Lazy Evaluation schwieriger
 Spark SQL Library (SQL auf RDDs) nicht umfangreich genug
46
Hadoop Tools für SQL
 Hive

Open Source

Basiert auf MapReduce: Stabil

Besser für Batch-Jobs, lange Jobs, sehr große Datenmengen
 Impala

Schneller als Hive

Instabiler

Besser für ad-hoc- und kurze Jobs
 Beides getestet, für Impala entschieden

47
da kurze Rechenzeit und wenige Nodes
Inhalt
 Vorwort
 Projektbeschreibung
 Über Hadoop
 Spark und andere Hadoop Tools
 Ergebnisse des Projekts
 Zusammenfassung und Lessons Learned
48
Zurück zum Projekt Treiberanalyse
01.03.2015
01.04.2015
Kredit 3
Kredit 3
P( Ausfall ) = 0.03
+ 0.02
Gesamt: 100.000 $
Rest: 75.000 $
Gesamt: 100.000 $
-1.500$
Laufzeit: 120 Monate
Restlaufzeit: 60 Monate
Rest: 73.500 $
Laufzeit: 120 Monate
- 1 Monat
Wert: 45.823€
Restlaufzeit: 59 Monate
Wert: 36.723€
-9.100€
49
P( Ausfall ) = 0.05
Zurück zum Projekt Treiberanalyse
 Abwechselnd

komplizierte Joins und andere Queries

Parallel ausführbare mathematische Berechnungen
...
 Beobachtung:
50

Impala: Nutzt Netzwerk

Spark: Nutzt CPU
Messungen
150
Spark
Impala
Summe
Alt
100
50
0
51
1 Node
2 Nodes
3 Nodes
4 Nodes
Spark
00:54:42
00:30:05
00:21:28
00:16:56
Impala
01:12:27
00:41:58
00:33:50
00:30:59
Summe
02:07:09
01:12:03
00:55:18
00:47:55
Geschwindigkeit i.V.z.
alter Implementierung
110 %
194 %
253 %
292 %
Idee: Aufteilung der Daten
Idee:
 Impala braucht mehr Netzwerk
 Spark braucht mehr CPU
⟹ manuelle Aufteilung in 2 zeitversetzte Batchjobs mit jeweils 50% Daten
52
Messungen
53
1 Job (4 Nodes)
2 Jobs (4 Nodes)
Spark
00:16:56
00:15:00
Impala
00:30:59
00:20:10
Summe
00:47:55
00:35:10
Geschwindigkeit i.V.z. alter
Implementierung
292 %
398 %
Inhalt
 Vorwort
 Projektbeschreibung
 Über Hadoop
 Spark und andere Hadoop Tools
 Ergebnisse des Projekts
 Zusammenfassung und Lessons Learned
54
Zusammenfassung
 Ziel: Berechnung der Werte von 13.000.000 Krediten beschleunigen
 Vorher:

Mathematische Berechnung auf Rechenkern

Join, Lookups, Aggregationen auf Sybase IQ Server

> 2 Stunden
 Adastras Ansatz:
55

Alle Daten auf kleinen preiswerten Cluster

Kostenlose Hadoop Software verwenden

Durch leicht zu implementierende Parallelisierung beschleunigen
Resultate:
Schneller und günstiger:
Zeit
Kosten
160
????
140
€€€€
120
€€€
100
€€
80
5000
60
4000
3000
40
2000
20
1000
0
0
Alte
Spark & Impala auf
Implementierung
Hadoop
2:20 Stunden ⇔ 35 Minuten
4 x schneller
56
Alte
Spark & Impala auf
Implementierung
Hadoop
Viele €€€€ ⇔ 3000 €
Deutlich günstiger
Lessons learned
 Spark: Gutes Framework für parallelisierbare Probleme

Deutlich schneller als MapReduce bei vielen Iterationen einer Berechnung

Entwicklung einfach:

57

Mehrere Programmiersprachen

Bibliotheken
Aber:

Noch dynamisch

Bibliotheken sind nicht immer 100% bugfrei
Lessons learned
 Mischen von Hadoop-Tools für beste Ergebnisse
 Problem besser in SQL als in imperative Programmiersprache formulierbar:
58

Sehr simpel? ↦ Spark SQL

Kompliziert, aber kurze Laufzeit? ↦ Impala

Kompliziert, lange Laufzeit (hohe Wahrscheinlichkeit für Hardwarefehler)? ↦ Hive
Lessons learned
 Hadoop nicht nur für „Big Data“
 Auch „Small/Medium Data“ auf “Small/Medium Clusters”, wenn
59

Parallelisierung möglich

Berechnung beschleunigt werden soll
Fragen?
60