Embed Size (px)
Citation preview
Titel der
Präsentation
eingeben
Titel der
Präsentation
eingeben
IT in der Praxis
- LPA –
Aufgaben-
stellung Ringvorlesung IT in der Praxis und Industrie
Redner: Stefan Utermark (head of software development)
Datum: 24. April 2013
2
Problemstellung
Nächtliche Berechnung von 20.000 – 100.000 Finanzprodukten in
max. 8h inkl. Persistenz der Analyse-Ergebnisse in eine DB
Zur Analyse des aktuellen Gesamtbestandes aller relevanten Finanzgeschäfte
einer Bank, bspw. zur bankinternen Risiko-Steuerung (CVA) oder
Vertriebsunterstützung, müssen sämtliche Produkte mind. 1x täglich
berechnet werden.
Je nach Kunde und Geschäftsgruppe umfasst das Mengengerüst ca. 5.000 bis
mehrere 100.000 Produkte.
Unter Berücksichtigung von Systemauslastung, Verfügbarkeits- und Backup-
Zeiten stehen für die Analyse in der Nacht ca. 4-8h zur Verfügung.
3
Problemstellung
4
System-Übersicht
Produkt-DB
Calculators Market Data
Server
App Server Client
5
Rahmenbedingungen
Input
Inputdaten aus der Datenbank:
• Daten zur Berechnung eines Geschäfts liegen in DB vor und müssen
eingelesen werden
• Notwendig sind u.a. Metadaten wie Geschäftsnummer und Produkttyp
• Die zu berechnenden Finanzprodukte werden in Form von XML-
Beschreibungen in der DB angelegt (Vgl. Demo_ProductFile_CapFloor.xml)
• Die Menge der Produktdaten ist in der Demo-DB hinzuzufügen
Hinweis zur Umsetzung:
Zur Demonstration genügt es, die Daten aus der Datenbank zu laden, die
weitere Verwendung insbes. zur Berechnung kann angedeutet werden
6
Überblick: DB-Struktur f. Produkt-Informationen
7
Rahmenbedingungen
Input
Externe Informationen:
• Zur Berechnung von Cashflow-Szenarien (zukünftige Verläufe werden
angenommen), müssen beispielsweise Indices (Euribor) auf Basis der
aktuellen Marktdaten simuliert werden
• Da alle Berechnungsergebnisse zueinander konsistent sein müssen, wird
jeweils ein Marktdaten-Set des Vortages - c(lose) o(f) b(usiness) – zur
Berechnung verwendet
• D.h. für alle Berechnung werden die gleichen Marktdaten verwendet
• Ein Marktdaten-Set hat ca. eine Größe von 3-4MB (XML)
• Die Daten werden über einen speziellen Marktdaten-Service zur Verfügung
gestellt
Hinweis zur Umsetzung:
• Zur Demonstration genügt es, einen geeigneten Caching-Mechanismus
anzuwenden, der Mock-Daten in der Größenordnung für die einzelnen
Berechnungen vorhält
8
Rahmenbedingungen
Berechnung
Berechnung:
• Durchschnittlich benötigt die Berechnung eines Produktes ca. 10sec
• Je nach Ausgestaltung der Produkte kann die Berechnung 0,5 – 600sec
• Treiber hierbei sind Laufzeit (n-Perioden) und Kündigungsrechte (Monte-Carlo-
Simulation im Modell [LMM])
Hinweis zur Umsetzung:
• Die „Berechnung“, sowie die Erzeugung der Ergebniswerte (Cashflows) sollte
so umgesetzt werden, das der Vorgang zufällig zw. 0,5-600sec und im Mittel
10sec dauert
• D.h. 1000 Produkte * 10sec = 2,7h Gesamtrechendauer + Laden & Speichern
• „Ergebnisse“ sollen simuliert erzeugt werden und im Prozess für eine
„gewisse“ Auslastung wären der Berechnungsdauer sorgen
9
Rahmenbedingungen
Output
Output-Daten in DB speichern:
• Analyseergebnisse müssen pro Geschäft in DB abgelegt werden
• Bei der Berechnung entstehen sowohl skalare Ergebnisse (NPV), als auch Datenreihen
(Cashflows) d.h. es gibt mehrere Ergebnis-Tabellen
Hinweis zur Umsetzung:
• Pro Geschäft sollen Cashflows-Informationen in die Tabellen
• AnalysisCashflowStructures (1 Struktur),
• AnalysisCashflowPeriods (zufällig zw. 10 &240 Perioden)
• AnalysisCashflowScenarios (10 Szenario-Ergebnisse)
10
Überblick: DB-Struktur f. Berechnungsergebnisse
(Ausschnitt)
12
Rahmenbedingungen
Mengengerüst
• Beispielhaft sollen die Produkte aus der DB „berechnet“ werden
• Pro Produkt sollen für 10 Szenarien Cashflow-Verläufe
• AnalysisCashflowStructures:
• 1000 Produkte = 1000 Einträge
• AnalysisCashflowPeriods:
• 1000 Produkte * 10-240 Perioden (zufällig & im Mittel 120 Perioden)
= ca. 120.000 Einträge
• AnalysisCashflowScenarios:
• 1000 Produkte * 10-240Perioden * 10 Szenarios = 1.200.000 Einträge
• Die Lösung muss skalierbar umgesetzt werden, sodass es möglich ist mit
wachsenden Geschäftsmengen umgehen zu können
• täglich werden neue Geschäfte abgeschlossen (mehr) & bestehende Geschäfte laufen
aus (weniger)
Zielsetzung: Minimierung der Gesamtlaufzeit
13
Zielsetzung
Erwartete Ergebnisse:
Vorstellung einer Zielarchitektur, welche in der Lage sein soll, die gestellten
Anforderungen bzgl. Laufzeit und Skalierbarkeit zu erfüllen
Identifikation von Problemfeldern & Skizzierung von entsprechenden
Lösungsansätzen
Prototypische Umsetzung der Berechnungskomponente inkl. DB-Interaktion
Performanceanalyse f. 100, 1.000, 5.000 (& optional 20.000)
Produktergebnisse – die Anzahl der Kalkulatoren sollte dabei von 1-n
gesteigert werden
- Gesamtdauer
- Dauer (Ø) von Laden aus DB, Generieren der Daten & Speichern in DB
gruppiert nach #Kalkulatoren
- Auslastung (Ø) f. CPU & RAM pro Kalkulator
- Auslastung (Ø) f. CPU, RAM & I/O bei DB gruppiert nach #Kalkulatoren
14
Quellen
Entwicklungsumgebung (z.B.):
• Microsoft Visual Studio Express 2012 & C#
http://www.microsoft.com/de-de/download/details.aspx?id=34673
Datenbank:
• Microsoft® SQL Server® 2012 Express bzw. LocalDB
http://www.microsoft.com/de-de/download/details.aspx?id=29062
Performance-Analyse:
• Windows-Leistungsüberwachung (Übersicht)
http://technet.microsoft.com/de-de/library/cc749154.aspx
• MSDN Monitoring SQL Server Performance – MSDN
http://msdn.microsoft.com/en-us/library/ee377023(v=bts.10).aspx
15
