Spark, Impala und Hadoop in der Kreditrisikoberechnung: Big Data
Werbung
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
