SlideShare ist ein Scribd-Unternehmen logo
1 von 24
Downloaden Sie, um offline zu lesen
Musterbild
Tipp «PostFinance-Bild einfügen»:
Post-Menü > Bild > PostFinance
Fraud detection mit
Stream Analytics
BATbern43 – 28.6.2019
Matej Ilicic hat 2011 den Master of Science
in Software Engineering an der Universität
Zagreb abgeschlossen, war 5 Jahre als
Software-Engineer tätig, und ist in den
letzten 2,5 Jahren bei der PostFinance als
Solution Architekt hauptsächlich in
Compliance & Risk Bereich tätig. (Linkedin)
Zacharias Kull hat Software Entwicklung
studiert und ist Datenexperte bei ELCA. Er
ist fasziniert von den Möglichkeiten neuer
Technologien wie Kafka und Spark und wie
dadurch verschiedene Disziplinen wie
Batch, Streaming und DevOps
zusammenkommen. (Linkedin)
• Hintergrund Betrugserkennung
• Betrugserkennung bei der PostFinance
• Technologiewahl
• Lösungsdesign
• Projekt und Lessons Learned
Seite 2Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Vorstellung & Agenda
Über uns Agenda
Gemäss Wikipedia, Betrug ist ein strafrechtliches Vermögensdelikt, bei dem der Täter in der Absicht
rechtswidriger Bereicherung das Opfer durch Vorspiegelung oder Unterdrückung von Tatsachen gezielt
so täuscht, dass es sich selbst oder einen Dritten am Vermögen schädigt und damit materiellen Schaden
zufügt.
Betrugskategorien:
Seite 3Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Definition vom Betrug/Fraud
Extern
• Kreditkartebetrug
• Onlinebetrug
• Transaktionsbetrug
• Claims Fraud → Versicherungen
• Andere
Intern
• Betrug mit Finanzberichten
• Korruption
• Veruntreuung vom Vermögen
• Automatisiert und stärkt die Monitoring-Aktivitäten eines Unternehmens
• Monitoring ist basiert auf den Daten von verschiedenen Datenquellen/Sensoren (z.B. Behavior Analytics,
Geolocation, Transaktionen, Kartengeldtransaktionen, Anti Money Laundering (AML) Applikation…)
• Erkennungs- und Präventionsprozess sind basiert auf den Regeln, prädiktiven Modellen oder gemischt
• Ermöglicht ein Fokus der Ressourcen auf die Analyse der Betrugsfälle anstatt auf die manuelle Erkennung
Seite 4Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Betrugserkennungssystem
1. 3’325 Mitarbeiter in 2018 davon ca. 500 in Informatik
2. 2’857 Mio Kunden in 2018
3. 4’503 Mio Konten
4. Zwischen 1,5 und 2,5 Mio Transaktionen täglich und 0,1% davon landen in Case Management
5. 497’594 Transaktionen pro Stunde am 29.5.2019 12:00
6. Überwachung von ca. 5000 gleichzeitige Sessions in EFinance
7. Daraus ca. 24’000’000 Mio Ereignisse pro Tag
Seite 5Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
PostFinance in Facts
965.00 996.00 1 020.00 1 044.00 1 072.00
1 145.00
2013 2014 2015 2016 2017 2018
ANZAHL TRANSAKTIONEN IN LETZTEN 6 JAHREN
Anzahl Transaktionen (Mio)
Seite 6Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Betrugserkennung bei der PostFinance
In-Memory DB
Operational Intelligence
Anomalieerkennung
Transaktionsüberwachung
HTTP-Requests
Order
Payment
Freigabe
Case
Management
BlockierenDatawarehouse
?
• Korrelation von Events
• Real-time Monitoring
• Real-time Situationserkennung
• Auslösen von Aktionen (Session Terminieren, Read-Only Modus, Alarmieren vom Online-
Sicherheit)
Seite 7Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Operational Intelligence - Aufgaben
Heutiger Betrugserkennungsprozess basiert auf Regeln bzw.
• Experten Wissen
• Trial and Error
• Domänen Know How
• Intuition
Seite 8Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Operational Intelligence - Betrugserkennungsprozess
Optimierungen des heutigen Betrugserkennungsprozesses
1. Simulationen mit den Regeln/Modellen und Live-Daten→ Apache Kafka als Grundlage
2. Einbau der zusätzlichen Sensoren (DeviceTracking, Behavior Tracking…)
3. Verbindung und Benutzung der Daten aus anderen Systemen (Kartengeld, AML, Embargo-Listen…)
4. Optimierung der Betrugserkennung mit Machine Learning (Selflearning Feedback Loop)
Seite 9Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Operational Intelligence – Optimierungen & Weiterentwicklung
Stream-Analytics
Off-Line-Analytics
Data Layer
Real-Time
Analyse
Case
Management
Testen &
Optimieren
Advanced
Analytics
Regeln & Modelle
Process
Review
Approve
Seite 13Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Technologien
Kafka Streams Apache Spark Streaming Apache Flink
Latenz Tief (ms) Hoch (sec) Tief (ms)
State Management Statefull Statefull Statefull
Know-How auf dem
Arbeitsmarkt
Deployment Container (wie die
Applikation)
Container Container
Life cycle Wie die Applikation Spark Job auf dem Spark-
Cluster
Flink Job auf dem Spark-
Cluster
Streaming-Typ Native Streaming Micro-Batching Native-Streaming
Durchsatz Mittelmässig Hoch Hoch
Verwendet in OI - Anomalieerkennung OI -
Transaktionsüberwachung
X
Seite 14Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Kafka Streams vs Spark Streaming vs Flink
Seite 15Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Lösungsdesign «Anomalieerkennung»
HttpRequestEvent
- Enrich
- Analyze
JMS to
Kafka
Adapter
Action
Oracle Coherence
EntryServer
NFR-s:
NFR-s: Target 99th percentile latency of 500 ms
Resilience / SLA: Highly available (99.5%)
Kafka Streams Job
Kafka Topic
HttpRequestEvent
(JMS)
Mail & SMS
Business Logging
- Action Handling
- Serving
Seite 16Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Lösungsdesign «Transaktionsüberwachung»
Orders
[Acquisition|Approval|Cancellation] Correlation
JMS to Kafka
Adapter
Payments
[Acquisition|Cancellation]
Correlated-
Payments
PaymentFraud-
Status
Analysis
Coherence
Suspicious-
Payment
JMS to Kafka
Adapter
Spark Streaming Job
Kafka Topic
TO
CaseManager
FROM
CaseManager
Corr.
Result Publisher
Enrichment
Agg.
Enriched-
Payment
Delegate to
CaseManagement
Cases
NFR-s
• Max. processing time: 2.5min for Express payments, 15min for Normal Payments
• Volume: 1 Mio Payments/h
• Komplete und korrekte Prozessierung (at-least-once)
• Resilience / SLA: Highly available (99.5%)
Die zwei Streams Order und Payment sollen korreliert
(gejoined) werden. Jedes Payment soll mit dem zugehörigen
Order zusammengesetzt dem nächsten Aufbereitungsschritt
übergeben werden.
Anforderungen:
▪ Die Order oder die zugehörigen Payments können zuerst
sein
▪ Eine Order kann bis zu 100’000 Payments haben
(normalerweise aber 1:1)
▪ Order und Payment können separat abgebrochen werden.
Wird die Order abgebrochen müssen alle bisher
weitergeleiteten Payments nochmals als abgebrochen
weitergeleitet werden
▪ Nicht genehmigte Orders müssen bis 2 Jahre vorgehalten
werden
▪ Änderungen an einem Payment sollen bis zu 24h nach
kompletter Verarbeitung der Order möglich sein
Komplexe Stream Korrelation
PhotobyWoodyWadeonFlickr
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Bisherige Implementation der Korrelation
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
18
Stream Processing Nodes Distributed Cache Nodes
StoredProcedures
Stream Processing Code
Payment
Order
Correlated
Payment
Stream Processing
(Komplex Aggregation)
Neue Implementation der Korrelation als «Komplexe Aggregation»
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
19
Stream Processing Nodes
Payment
Order
Correlated
Payment
Group By Orderid
Local
Cache
Die einfachere Implementation
erlaubte weitere innovative
Anforderungen in der
Correlation umzusetzen, welche
bisher zu komplex waren.
Spark Structured Streaming Job
Spark Microbatches: at-least-once Garantie und State
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
20
Streaming
input A
Streaming
input B
Streaming
Output
Microbatch x
Operator
Partition
Partition
Partition
Partition
Operator
Partition
Partition
Partition
Partition
Operator
Partition
Partition
Partition
Partition
Offset
Log
Commit
LogState
Persistent Storage
Microbatch x+1
Operator
Partition
Partition
Partition
Partition
Operator
Partition
Partition
Partition
Partition
Operator
Partition
Partition
Partition
Partition
Offset
Log
Commit
LogState
Alles für 24h behalten gibt bis
zu 100GB State im Memory.
Die Spark default
Implementation ist eine in-
memory HashMap. Wir haben
einen Custom
StateStoreProvider entwickelt
auf Basis von RocskDB.
Pro Microbatch & Operator &
Partition wird eine lokale State
Version erstellt.
Mit 3 Operatoren, 10 Partition
und einem 10sec Interval gibt
das ~10'000 State Versionen
pro Stunde.
Resilience: Mehrere Stufen der Fehlerbehandlung
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
23
Level Error Mögliche Ursache Resilience Implementation
User Code Exception in
Src/Tgt/Custom code
von Spark Task
• S3 Up/Download failed
• Kafka Connection errors
• Logic error
• Tune resilience settings (S3, Kafka)
• Implement custom error handling
Spark
Framework
Spark Task failes • Uncatched Exceptions
• OutOfMemory
• Executor Killed (e.g. Chaos
Monkey)
• Spark Task Retry
Kubernetes Spark Job (Driver)
failes
• Task Retries failed
• OutOfMemory
• Driver Killed (e.g. Chaos
Monkey)
• Kubernetes Statefulset restarts Spark
Job
Anspruchsvolles Spark Performance Tuning
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
24
Ziel Parameters
Throughput + Microbatch size
+ Number of Spark Partitions
+ Number of processing Cores
- Microbatch interval
Latency - Microbatch size
- Number of Spark Partitions
+ Number of processing Cores
- Microbatch interval
Memory - Microbatch size
+ Number of Spark Partitions
- Number of processing Cores
Parameter Einfluss
Microbatch size + Throughput
+ Latency
+ Memory
Number of Spark Partitions + Throughput
- Latency
+ Memory
Number of processing Cores + Throughput
- Latency
+ Memory
Microbatch interval - Throughput
- Latency
Aktuelles Sizing / Performance
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
25
Kafka:
- 3 Broker mit je 4GB Ram, 2 Cores, 1TB iSCSI Disk
- 15 Partitionen je Topic
Spark (für die 3 Haupt-Streaming-Queries):
- Driver mit 10GB Ram, 1 Core
- 3 Executors mit je 16GB Ram, 6 Cores, 10GB Disk
- 10 Partitionen
- 30’000 Messages pro Microbatch
→ Erreichtes Microbatch Interval >10s (je nach Last)
→ Performance erfüllt die NFR’s (1Mio/h)
Optimierungspotential ist noch nicht ausgeschöpft
Projektplanung «Transaktionsüberwachung»
26
2019
Optimierung & Hardening
Konzept Ablösung
CEP
Implementierung
«Transaktionsüberwachung»
1.07.
Start Konzept
1.09.
Start Umsetzung
15.2.
«One Delivery»
25.5.
Einführung
RE19A
2018
Testing
Erweiterung
Implementierung
«Anomalieerkennung»
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
Was wir erreicht haben…
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
27
▪ Infrastruktur für Spark auf Kubernetes aufgebaut und Pilot-Projekt darauf umgesetzt (inkl. Apache
Hadoop OpenSource Bugfix)
▪ Stage-of-the-art Messagingarchitektur mit Kafka und Schemaregistry sowie typensicheren Streaming
Pipelines mit Spark implementiert (inkl. avro4s OpenSource Library Improvement).
▪ Komplexe Stream Correlation horizontal skalierbar implementiert
▪ Komplexe Stream Correlation mit «Test Driven Development» umgesetzt
▪ Automatisiertes Deployment mit Atlassian Bamboo umgesetzt
▪ Hohe nicht funktionale Anforderungen an Performance, Stabilität, Vollständigkeit und Betreibbarkeit
umgesetzt.
▪ Go-Live mit RE19A Ende Mai 2019
Lessons Learned…
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
28
▪ Aufbau der Infrastruktur brauchte viel Zeit
→ tiefes Technologieverständnis hilft viel
▪ Rückstand beim Testing hat fast den Release verhindert
▪ Aufgrund der vielen neuen Technologien hatten wir eine lange Optimierung-, Stabilisierung- und
Bugfixingphase bis kurz vor dem Release
→ weniger neue Technologie wäre vielleicht mehr
▪ Optimierung und Bugfixing in solchen verteilten Systemen ist anspruchsvoll
→ ausführliches Logging auf Splunk hilft viel
▪ AWS S3 ist nur “eventual consistent”, Cloudian S3 bietet mehr, aber…
→ Konsistenzfehler verursachen immer noch Abbrüche
▪ Wären Order und Payment nicht getrennt, wäre es einiges einfacher
Fragen…
Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
29

Weitere ähnliche Inhalte

Was ist angesagt?

Clickstream Analysis with Spark
Clickstream Analysis with Spark Clickstream Analysis with Spark
Clickstream Analysis with Spark Josef Adersberger
 
Azure Days 2019: Master the Move to Azure (Konrad Brunner)
Azure Days 2019: Master the Move to Azure (Konrad Brunner)Azure Days 2019: Master the Move to Azure (Konrad Brunner)
Azure Days 2019: Master the Move to Azure (Konrad Brunner)Trivadis
 
Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...
Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...
Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...Spark Summit
 
SplunkLive! München - Flughafen München
SplunkLive! München - Flughafen MünchenSplunkLive! München - Flughafen München
SplunkLive! München - Flughafen MünchenSplunk
 
Continuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn AgileContinuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn AgileLeanIX GmbH
 
SplunkLive! München 2016 - Splunk @ Datev
SplunkLive! München 2016 - Splunk @ DatevSplunkLive! München 2016 - Splunk @ Datev
SplunkLive! München 2016 - Splunk @ DatevSplunk
 

Was ist angesagt? (6)

Clickstream Analysis with Spark
Clickstream Analysis with Spark Clickstream Analysis with Spark
Clickstream Analysis with Spark
 
Azure Days 2019: Master the Move to Azure (Konrad Brunner)
Azure Days 2019: Master the Move to Azure (Konrad Brunner)Azure Days 2019: Master the Move to Azure (Konrad Brunner)
Azure Days 2019: Master the Move to Azure (Konrad Brunner)
 
Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...
Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...
Clickstream Analysis with Spark—Understanding Visitors in Realtime by Josef A...
 
SplunkLive! München - Flughafen München
SplunkLive! München - Flughafen MünchenSplunkLive! München - Flughafen München
SplunkLive! München - Flughafen München
 
Continuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn AgileContinuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn Agile
 
SplunkLive! München 2016 - Splunk @ Datev
SplunkLive! München 2016 - Splunk @ DatevSplunkLive! München 2016 - Splunk @ Datev
SplunkLive! München 2016 - Splunk @ Datev
 

Ähnlich wie batbern43 Fraud Detection mit Stream Analytics

Complex Event Processing (CEP) gets in touch with JSF
Complex Event Processing (CEP) gets in touch with JSFComplex Event Processing (CEP) gets in touch with JSF
Complex Event Processing (CEP) gets in touch with JSFadesso AG
 
Splunk Webinar Searching & Reporting
Splunk Webinar Searching & ReportingSplunk Webinar Searching & Reporting
Splunk Webinar Searching & ReportingGeorg Knon
 
Der Weg in den vollautomatisierten SOC Betrieb
Der Weg in den vollautomatisierten SOC BetriebDer Weg in den vollautomatisierten SOC Betrieb
Der Weg in den vollautomatisierten SOC BetriebSplunk
 
SplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaGeorg Knon
 
SplunkLive! Frankfurt 2016 - Helvetia Use Case
SplunkLive! Frankfurt 2016 - Helvetia Use CaseSplunkLive! Frankfurt 2016 - Helvetia Use Case
SplunkLive! Frankfurt 2016 - Helvetia Use CaseSplunk
 
SplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunk
 
Architecture challenges of search
Architecture challenges of searchArchitecture challenges of search
Architecture challenges of searchTorsten Köster
 
Elastic Compute Cloud: Darf es noch ein Server mehr sein?
Elastic Compute Cloud: Darf es noch ein Server mehr sein?Elastic Compute Cloud: Darf es noch ein Server mehr sein?
Elastic Compute Cloud: Darf es noch ein Server mehr sein?Lothar Wieske
 
Sich selbst verstehen – der ELK-Stack in der Praxis
Sich selbst verstehen – der ELK-Stack in der PraxisSich selbst verstehen – der ELK-Stack in der Praxis
Sich selbst verstehen – der ELK-Stack in der PraxisAlexander Papaspyrou
 
Splunk corporate overview German 2012
Splunk corporate overview German 2012Splunk corporate overview German 2012
Splunk corporate overview German 2012jenny_splunk
 
Log4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfLog4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfStephan Kaps
 
Kaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes seinKaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes seinStephan Kaps
 
Wüstenrot Webinar
Wüstenrot Webinar Wüstenrot Webinar
Wüstenrot Webinar Dynatrace
 
Dataservices - Data Processing mit Microservices
Dataservices - Data Processing mit MicroservicesDataservices - Data Processing mit Microservices
Dataservices - Data Processing mit MicroservicesQAware GmbH
 
Apache Kafka
Apache KafkaApache Kafka
Apache Kafkagedoplan
 
Webcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMon
Webcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMonWebcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMon
Webcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMonQUIBIQ Hamburg
 
Splunk Webinar: Machine Learning mit Splunk
Splunk Webinar: Machine Learning mit SplunkSplunk Webinar: Machine Learning mit Splunk
Splunk Webinar: Machine Learning mit SplunkSplunk
 
Tobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-Projekten
Tobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-ProjektenTobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-Projekten
Tobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-ProjektenDevDay Dresden
 
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergEvent Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergOPITZ CONSULTING Deutschland
 

Ähnlich wie batbern43 Fraud Detection mit Stream Analytics (20)

Complex Event Processing (CEP) gets in touch with JSF
Complex Event Processing (CEP) gets in touch with JSFComplex Event Processing (CEP) gets in touch with JSF
Complex Event Processing (CEP) gets in touch with JSF
 
Splunk Webinar Searching & Reporting
Splunk Webinar Searching & ReportingSplunk Webinar Searching & Reporting
Splunk Webinar Searching & Reporting
 
Der Weg in den vollautomatisierten SOC Betrieb
Der Weg in den vollautomatisierten SOC BetriebDer Weg in den vollautomatisierten SOC Betrieb
Der Weg in den vollautomatisierten SOC Betrieb
 
Bank-Kram made by Railslove
Bank-Kram made by RailsloveBank-Kram made by Railslove
Bank-Kram made by Railslove
 
SplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case Helvetia
 
SplunkLive! Frankfurt 2016 - Helvetia Use Case
SplunkLive! Frankfurt 2016 - Helvetia Use CaseSplunkLive! Frankfurt 2016 - Helvetia Use Case
SplunkLive! Frankfurt 2016 - Helvetia Use Case
 
SplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case HelvetiaSplunkLive! Zürich 2016 - Use Case Helvetia
SplunkLive! Zürich 2016 - Use Case Helvetia
 
Architecture challenges of search
Architecture challenges of searchArchitecture challenges of search
Architecture challenges of search
 
Elastic Compute Cloud: Darf es noch ein Server mehr sein?
Elastic Compute Cloud: Darf es noch ein Server mehr sein?Elastic Compute Cloud: Darf es noch ein Server mehr sein?
Elastic Compute Cloud: Darf es noch ein Server mehr sein?
 
Sich selbst verstehen – der ELK-Stack in der Praxis
Sich selbst verstehen – der ELK-Stack in der PraxisSich selbst verstehen – der ELK-Stack in der Praxis
Sich selbst verstehen – der ELK-Stack in der Praxis
 
Splunk corporate overview German 2012
Splunk corporate overview German 2012Splunk corporate overview German 2012
Splunk corporate overview German 2012
 
Log4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdfLog4j war erst der Anfang.pdf
Log4j war erst der Anfang.pdf
 
Kaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes seinKaps - Es muss nicht immer Kubernetes sein
Kaps - Es muss nicht immer Kubernetes sein
 
Wüstenrot Webinar
Wüstenrot Webinar Wüstenrot Webinar
Wüstenrot Webinar
 
Dataservices - Data Processing mit Microservices
Dataservices - Data Processing mit MicroservicesDataservices - Data Processing mit Microservices
Dataservices - Data Processing mit Microservices
 
Apache Kafka
Apache KafkaApache Kafka
Apache Kafka
 
Webcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMon
Webcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMonWebcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMon
Webcast: Prozess Monitoring in Azure (und on premise) mit dem IntelliMon
 
Splunk Webinar: Machine Learning mit Splunk
Splunk Webinar: Machine Learning mit SplunkSplunk Webinar: Machine Learning mit Splunk
Splunk Webinar: Machine Learning mit Splunk
 
Tobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-Projekten
Tobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-ProjektenTobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-Projekten
Tobias Nebel - Herausforderungen und Changen in Full-Stack-IoT-Projekten
 
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergEvent Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
 

Mehr von BATbern

BATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data MeshBATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data MeshBATbern
 
BATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern
 
BATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und KnacknüsseBATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und KnacknüsseBATbern
 
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data MeshBATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data MeshBATbern
 
BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++BATbern
 
Embracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplaceEmbracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplaceBATbern
 
Serverless und Event-Driven Architecture
Serverless und Event-Driven ArchitectureServerless und Event-Driven Architecture
Serverless und Event-Driven ArchitectureBATbern
 
Serverless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisServerless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisBATbern
 
Serverless at Lifestage
Serverless at LifestageServerless at Lifestage
Serverless at LifestageBATbern
 
Keynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless ArchitecturesKeynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless ArchitecturesBATbern
 
BATbern51 Serverless?!
BATbern51 Serverless?!BATbern51 Serverless?!
BATbern51 Serverless?!BATbern
 
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen PartnersEin Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen PartnersBATbern
 
MLOps journey at Swisscom: AI Use Cases, Architecture and Future Vision
MLOps journey at Swisscom: AI Use Cases, Architecture and Future VisionMLOps journey at Swisscom: AI Use Cases, Architecture and Future Vision
MLOps journey at Swisscom: AI Use Cases, Architecture and Future VisionBATbern
 
From Ideation to Production in 7 days: The Scoring Factory at Raiffeisen
From Ideation to Production in 7 days: The Scoring Factory at RaiffeisenFrom Ideation to Production in 7 days: The Scoring Factory at Raiffeisen
From Ideation to Production in 7 days: The Scoring Factory at RaiffeisenBATbern
 
The Future of Coaching in Sport with AI/ML
The Future of Coaching in Sport with AI/MLThe Future of Coaching in Sport with AI/ML
The Future of Coaching in Sport with AI/MLBATbern
 
Klassifizierung von Versicherungsschäden – AI und MLOps bei der Mobiliar
Klassifizierung von Versicherungsschäden – AI und MLOps bei der MobiliarKlassifizierung von Versicherungsschäden – AI und MLOps bei der Mobiliar
Klassifizierung von Versicherungsschäden – AI und MLOps bei der MobiliarBATbern
 
BATbern48_ZeroTrust-Konzept und Realität.pdf
BATbern48_ZeroTrust-Konzept und Realität.pdfBATbern48_ZeroTrust-Konzept und Realität.pdf
BATbern48_ZeroTrust-Konzept und Realität.pdfBATbern
 
BATbern48_How Zero Trust can help your organisation keep safe.pdf
BATbern48_How Zero Trust can help your organisation keep safe.pdfBATbern48_How Zero Trust can help your organisation keep safe.pdf
BATbern48_How Zero Trust can help your organisation keep safe.pdfBATbern
 
BATbern48_Zero Trust Architektur des ISC-EJPD.pdf
BATbern48_Zero Trust Architektur des ISC-EJPD.pdfBATbern48_Zero Trust Architektur des ISC-EJPD.pdf
BATbern48_Zero Trust Architektur des ISC-EJPD.pdfBATbern
 
Why did the shift-left end up in the cloud for Bank Julius Baer?
Why did the shift-left end up in the cloud for Bank Julius Baer?Why did the shift-left end up in the cloud for Bank Julius Baer?
Why did the shift-left end up in the cloud for Bank Julius Baer?BATbern
 

Mehr von BATbern (20)

BATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data MeshBATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data Mesh
 
BATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data Mesh
 
BATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und KnacknüsseBATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und Knacknüsse
 
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data MeshBATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
 
BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++
 
Embracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplaceEmbracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplace
 
Serverless und Event-Driven Architecture
Serverless und Event-Driven ArchitectureServerless und Event-Driven Architecture
Serverless und Event-Driven Architecture
 
Serverless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisServerless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der Praxis
 
Serverless at Lifestage
Serverless at LifestageServerless at Lifestage
Serverless at Lifestage
 
Keynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless ArchitecturesKeynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless Architectures
 
BATbern51 Serverless?!
BATbern51 Serverless?!BATbern51 Serverless?!
BATbern51 Serverless?!
 
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen PartnersEin Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
 
MLOps journey at Swisscom: AI Use Cases, Architecture and Future Vision
MLOps journey at Swisscom: AI Use Cases, Architecture and Future VisionMLOps journey at Swisscom: AI Use Cases, Architecture and Future Vision
MLOps journey at Swisscom: AI Use Cases, Architecture and Future Vision
 
From Ideation to Production in 7 days: The Scoring Factory at Raiffeisen
From Ideation to Production in 7 days: The Scoring Factory at RaiffeisenFrom Ideation to Production in 7 days: The Scoring Factory at Raiffeisen
From Ideation to Production in 7 days: The Scoring Factory at Raiffeisen
 
The Future of Coaching in Sport with AI/ML
The Future of Coaching in Sport with AI/MLThe Future of Coaching in Sport with AI/ML
The Future of Coaching in Sport with AI/ML
 
Klassifizierung von Versicherungsschäden – AI und MLOps bei der Mobiliar
Klassifizierung von Versicherungsschäden – AI und MLOps bei der MobiliarKlassifizierung von Versicherungsschäden – AI und MLOps bei der Mobiliar
Klassifizierung von Versicherungsschäden – AI und MLOps bei der Mobiliar
 
BATbern48_ZeroTrust-Konzept und Realität.pdf
BATbern48_ZeroTrust-Konzept und Realität.pdfBATbern48_ZeroTrust-Konzept und Realität.pdf
BATbern48_ZeroTrust-Konzept und Realität.pdf
 
BATbern48_How Zero Trust can help your organisation keep safe.pdf
BATbern48_How Zero Trust can help your organisation keep safe.pdfBATbern48_How Zero Trust can help your organisation keep safe.pdf
BATbern48_How Zero Trust can help your organisation keep safe.pdf
 
BATbern48_Zero Trust Architektur des ISC-EJPD.pdf
BATbern48_Zero Trust Architektur des ISC-EJPD.pdfBATbern48_Zero Trust Architektur des ISC-EJPD.pdf
BATbern48_Zero Trust Architektur des ISC-EJPD.pdf
 
Why did the shift-left end up in the cloud for Bank Julius Baer?
Why did the shift-left end up in the cloud for Bank Julius Baer?Why did the shift-left end up in the cloud for Bank Julius Baer?
Why did the shift-left end up in the cloud for Bank Julius Baer?
 

batbern43 Fraud Detection mit Stream Analytics

  • 1. Musterbild Tipp «PostFinance-Bild einfügen»: Post-Menü > Bild > PostFinance Fraud detection mit Stream Analytics BATbern43 – 28.6.2019
  • 2. Matej Ilicic hat 2011 den Master of Science in Software Engineering an der Universität Zagreb abgeschlossen, war 5 Jahre als Software-Engineer tätig, und ist in den letzten 2,5 Jahren bei der PostFinance als Solution Architekt hauptsächlich in Compliance & Risk Bereich tätig. (Linkedin) Zacharias Kull hat Software Entwicklung studiert und ist Datenexperte bei ELCA. Er ist fasziniert von den Möglichkeiten neuer Technologien wie Kafka und Spark und wie dadurch verschiedene Disziplinen wie Batch, Streaming und DevOps zusammenkommen. (Linkedin) • Hintergrund Betrugserkennung • Betrugserkennung bei der PostFinance • Technologiewahl • Lösungsdesign • Projekt und Lessons Learned Seite 2Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Vorstellung & Agenda Über uns Agenda
  • 3. Gemäss Wikipedia, Betrug ist ein strafrechtliches Vermögensdelikt, bei dem der Täter in der Absicht rechtswidriger Bereicherung das Opfer durch Vorspiegelung oder Unterdrückung von Tatsachen gezielt so täuscht, dass es sich selbst oder einen Dritten am Vermögen schädigt und damit materiellen Schaden zufügt. Betrugskategorien: Seite 3Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Definition vom Betrug/Fraud Extern • Kreditkartebetrug • Onlinebetrug • Transaktionsbetrug • Claims Fraud → Versicherungen • Andere Intern • Betrug mit Finanzberichten • Korruption • Veruntreuung vom Vermögen
  • 4. • Automatisiert und stärkt die Monitoring-Aktivitäten eines Unternehmens • Monitoring ist basiert auf den Daten von verschiedenen Datenquellen/Sensoren (z.B. Behavior Analytics, Geolocation, Transaktionen, Kartengeldtransaktionen, Anti Money Laundering (AML) Applikation…) • Erkennungs- und Präventionsprozess sind basiert auf den Regeln, prädiktiven Modellen oder gemischt • Ermöglicht ein Fokus der Ressourcen auf die Analyse der Betrugsfälle anstatt auf die manuelle Erkennung Seite 4Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Betrugserkennungssystem
  • 5. 1. 3’325 Mitarbeiter in 2018 davon ca. 500 in Informatik 2. 2’857 Mio Kunden in 2018 3. 4’503 Mio Konten 4. Zwischen 1,5 und 2,5 Mio Transaktionen täglich und 0,1% davon landen in Case Management 5. 497’594 Transaktionen pro Stunde am 29.5.2019 12:00 6. Überwachung von ca. 5000 gleichzeitige Sessions in EFinance 7. Daraus ca. 24’000’000 Mio Ereignisse pro Tag Seite 5Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA PostFinance in Facts 965.00 996.00 1 020.00 1 044.00 1 072.00 1 145.00 2013 2014 2015 2016 2017 2018 ANZAHL TRANSAKTIONEN IN LETZTEN 6 JAHREN Anzahl Transaktionen (Mio)
  • 6. Seite 6Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Betrugserkennung bei der PostFinance In-Memory DB Operational Intelligence Anomalieerkennung Transaktionsüberwachung HTTP-Requests Order Payment Freigabe Case Management BlockierenDatawarehouse ?
  • 7. • Korrelation von Events • Real-time Monitoring • Real-time Situationserkennung • Auslösen von Aktionen (Session Terminieren, Read-Only Modus, Alarmieren vom Online- Sicherheit) Seite 7Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Operational Intelligence - Aufgaben
  • 8. Heutiger Betrugserkennungsprozess basiert auf Regeln bzw. • Experten Wissen • Trial and Error • Domänen Know How • Intuition Seite 8Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Operational Intelligence - Betrugserkennungsprozess
  • 9. Optimierungen des heutigen Betrugserkennungsprozesses 1. Simulationen mit den Regeln/Modellen und Live-Daten→ Apache Kafka als Grundlage 2. Einbau der zusätzlichen Sensoren (DeviceTracking, Behavior Tracking…) 3. Verbindung und Benutzung der Daten aus anderen Systemen (Kartengeld, AML, Embargo-Listen…) 4. Optimierung der Betrugserkennung mit Machine Learning (Selflearning Feedback Loop) Seite 9Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Operational Intelligence – Optimierungen & Weiterentwicklung Stream-Analytics Off-Line-Analytics Data Layer Real-Time Analyse Case Management Testen & Optimieren Advanced Analytics Regeln & Modelle Process Review Approve
  • 10. Seite 13Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Technologien
  • 11. Kafka Streams Apache Spark Streaming Apache Flink Latenz Tief (ms) Hoch (sec) Tief (ms) State Management Statefull Statefull Statefull Know-How auf dem Arbeitsmarkt Deployment Container (wie die Applikation) Container Container Life cycle Wie die Applikation Spark Job auf dem Spark- Cluster Flink Job auf dem Spark- Cluster Streaming-Typ Native Streaming Micro-Batching Native-Streaming Durchsatz Mittelmässig Hoch Hoch Verwendet in OI - Anomalieerkennung OI - Transaktionsüberwachung X Seite 14Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Kafka Streams vs Spark Streaming vs Flink
  • 12. Seite 15Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Lösungsdesign «Anomalieerkennung» HttpRequestEvent - Enrich - Analyze JMS to Kafka Adapter Action Oracle Coherence EntryServer NFR-s: NFR-s: Target 99th percentile latency of 500 ms Resilience / SLA: Highly available (99.5%) Kafka Streams Job Kafka Topic HttpRequestEvent (JMS) Mail & SMS Business Logging - Action Handling - Serving
  • 13. Seite 16Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA Lösungsdesign «Transaktionsüberwachung» Orders [Acquisition|Approval|Cancellation] Correlation JMS to Kafka Adapter Payments [Acquisition|Cancellation] Correlated- Payments PaymentFraud- Status Analysis Coherence Suspicious- Payment JMS to Kafka Adapter Spark Streaming Job Kafka Topic TO CaseManager FROM CaseManager Corr. Result Publisher Enrichment Agg. Enriched- Payment Delegate to CaseManagement Cases NFR-s • Max. processing time: 2.5min for Express payments, 15min for Normal Payments • Volume: 1 Mio Payments/h • Komplete und korrekte Prozessierung (at-least-once) • Resilience / SLA: Highly available (99.5%)
  • 14. Die zwei Streams Order und Payment sollen korreliert (gejoined) werden. Jedes Payment soll mit dem zugehörigen Order zusammengesetzt dem nächsten Aufbereitungsschritt übergeben werden. Anforderungen: ▪ Die Order oder die zugehörigen Payments können zuerst sein ▪ Eine Order kann bis zu 100’000 Payments haben (normalerweise aber 1:1) ▪ Order und Payment können separat abgebrochen werden. Wird die Order abgebrochen müssen alle bisher weitergeleiteten Payments nochmals als abgebrochen weitergeleitet werden ▪ Nicht genehmigte Orders müssen bis 2 Jahre vorgehalten werden ▪ Änderungen an einem Payment sollen bis zu 24h nach kompletter Verarbeitung der Order möglich sein Komplexe Stream Korrelation PhotobyWoodyWadeonFlickr Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
  • 15. Bisherige Implementation der Korrelation Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 18 Stream Processing Nodes Distributed Cache Nodes StoredProcedures Stream Processing Code Payment Order Correlated Payment
  • 16. Stream Processing (Komplex Aggregation) Neue Implementation der Korrelation als «Komplexe Aggregation» Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 19 Stream Processing Nodes Payment Order Correlated Payment Group By Orderid Local Cache Die einfachere Implementation erlaubte weitere innovative Anforderungen in der Correlation umzusetzen, welche bisher zu komplex waren.
  • 17. Spark Structured Streaming Job Spark Microbatches: at-least-once Garantie und State Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 20 Streaming input A Streaming input B Streaming Output Microbatch x Operator Partition Partition Partition Partition Operator Partition Partition Partition Partition Operator Partition Partition Partition Partition Offset Log Commit LogState Persistent Storage Microbatch x+1 Operator Partition Partition Partition Partition Operator Partition Partition Partition Partition Operator Partition Partition Partition Partition Offset Log Commit LogState Alles für 24h behalten gibt bis zu 100GB State im Memory. Die Spark default Implementation ist eine in- memory HashMap. Wir haben einen Custom StateStoreProvider entwickelt auf Basis von RocskDB. Pro Microbatch & Operator & Partition wird eine lokale State Version erstellt. Mit 3 Operatoren, 10 Partition und einem 10sec Interval gibt das ~10'000 State Versionen pro Stunde.
  • 18. Resilience: Mehrere Stufen der Fehlerbehandlung Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 23 Level Error Mögliche Ursache Resilience Implementation User Code Exception in Src/Tgt/Custom code von Spark Task • S3 Up/Download failed • Kafka Connection errors • Logic error • Tune resilience settings (S3, Kafka) • Implement custom error handling Spark Framework Spark Task failes • Uncatched Exceptions • OutOfMemory • Executor Killed (e.g. Chaos Monkey) • Spark Task Retry Kubernetes Spark Job (Driver) failes • Task Retries failed • OutOfMemory • Driver Killed (e.g. Chaos Monkey) • Kubernetes Statefulset restarts Spark Job
  • 19. Anspruchsvolles Spark Performance Tuning Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 24 Ziel Parameters Throughput + Microbatch size + Number of Spark Partitions + Number of processing Cores - Microbatch interval Latency - Microbatch size - Number of Spark Partitions + Number of processing Cores - Microbatch interval Memory - Microbatch size + Number of Spark Partitions - Number of processing Cores Parameter Einfluss Microbatch size + Throughput + Latency + Memory Number of Spark Partitions + Throughput - Latency + Memory Number of processing Cores + Throughput - Latency + Memory Microbatch interval - Throughput - Latency
  • 20. Aktuelles Sizing / Performance Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 25 Kafka: - 3 Broker mit je 4GB Ram, 2 Cores, 1TB iSCSI Disk - 15 Partitionen je Topic Spark (für die 3 Haupt-Streaming-Queries): - Driver mit 10GB Ram, 1 Core - 3 Executors mit je 16GB Ram, 6 Cores, 10GB Disk - 10 Partitionen - 30’000 Messages pro Microbatch → Erreichtes Microbatch Interval >10s (je nach Last) → Performance erfüllt die NFR’s (1Mio/h) Optimierungspotential ist noch nicht ausgeschöpft
  • 21. Projektplanung «Transaktionsüberwachung» 26 2019 Optimierung & Hardening Konzept Ablösung CEP Implementierung «Transaktionsüberwachung» 1.07. Start Konzept 1.09. Start Umsetzung 15.2. «One Delivery» 25.5. Einführung RE19A 2018 Testing Erweiterung Implementierung «Anomalieerkennung» Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA
  • 22. Was wir erreicht haben… Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 27 ▪ Infrastruktur für Spark auf Kubernetes aufgebaut und Pilot-Projekt darauf umgesetzt (inkl. Apache Hadoop OpenSource Bugfix) ▪ Stage-of-the-art Messagingarchitektur mit Kafka und Schemaregistry sowie typensicheren Streaming Pipelines mit Spark implementiert (inkl. avro4s OpenSource Library Improvement). ▪ Komplexe Stream Correlation horizontal skalierbar implementiert ▪ Komplexe Stream Correlation mit «Test Driven Development» umgesetzt ▪ Automatisiertes Deployment mit Atlassian Bamboo umgesetzt ▪ Hohe nicht funktionale Anforderungen an Performance, Stabilität, Vollständigkeit und Betreibbarkeit umgesetzt. ▪ Go-Live mit RE19A Ende Mai 2019
  • 23. Lessons Learned… Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 28 ▪ Aufbau der Infrastruktur brauchte viel Zeit → tiefes Technologieverständnis hilft viel ▪ Rückstand beim Testing hat fast den Release verhindert ▪ Aufgrund der vielen neuen Technologien hatten wir eine lange Optimierung-, Stabilisierung- und Bugfixingphase bis kurz vor dem Release → weniger neue Technologie wäre vielleicht mehr ▪ Optimierung und Bugfixing in solchen verteilten Systemen ist anspruchsvoll → ausführliches Logging auf Splunk hilft viel ▪ AWS S3 ist nur “eventual consistent”, Cloudian S3 bietet mehr, aber… → Konsistenzfehler verursachen immer noch Abbrüche ▪ Wären Order und Payment nicht getrennt, wäre es einiges einfacher
  • 24. Fragen… Fraud Detection mit Stream Analytics; Matej Ilicic - PostFinance, Zacharias Kull - ELCA 29