Slide 1

Slide 1 text

FAST DATA SMACK DOWN Data Done Right Created by / Stefan Siprell @stefansiprell

Slide 2

Slide 2 text

SMACK? Spark Mesos Akka Cassandra Kafka

Slide 3

Slide 3 text

Spark Schweizer Taschenmesser für Daten ETL Jobs? Kein Problem. µ-Batching auf Streams? Kein Problem. SQL und Joins auf non-RDBMS? Kein Problem. Graphen Operationen auf non-Graphen? Kein Problem. Map/Reduce aber in schnell? Gerne.

Slide 4

Slide 4 text

Mesos Verteilter Kernel für die Cloud Verknüpft viele Maschinen zu einem logischen Rechner Statisches Deployment von Mesos Dynamisches Deployment der Workload Gute Integration mit Hadoop, Kafka, Spark Wirklich wirklich vielen Maschinen - Rechenzentren

Slide 5

Slide 5 text

Akka Framework für verteilte Anwendungen Hoch performant Einfache Nebenläufigkeiten durch asynchrone Verteilung Elastisch und Dezentral Ausfallsicher Wirklich wirklich performant - 50 Millionen Nachrichten pro Maschine und Sekunde

Slide 6

Slide 6 text

Cassandra Performante und skalierende No-SQL Datenbank Lineare Skalierung - etwa 10'000 Requests pro Maschine und Sekunde Ausfallsicher Comfort eines Spaltenindex mit Append Only Performance Datensicher auch über mehrere Rechenzentren Stark in Denormalisierung

Slide 7

Slide 7 text

Kafka Messaging für Big Data Schnell - Liefert Hunderte von Mega Bytes pro Sekunde an Tausende von Clients Skaliert - Partitionierung der Daten auf handlebare Größen Datensicher - Append Only, um TBs an Daten ohne Performanceverluste zu speichern Verteilt - von Anfang an

Slide 8

Slide 8 text

Am Anfang gab es HADOOP

Slide 9

Slide 9 text

Big-Batch sah, dass es gut war und hat fortan gemapped and gereduced

Slide 10

Slide 10 text

Doch Business wollte nicht immer warten. Business will immer mehr... und das immer schneller

Slide 11

Slide 11 text

Viel zu schnell Realtime Processing für High Frequency Trading Stromnetzüberwachung Rechenzentrumsüberwachung basieren auf Single-Threaded, Cache-Optimized, Memory-Barrier Ringbuffer und sind per Definition "schlampig" und haben sehr statische und kleine Kontexte.

Slide 12

Slide 12 text

Zwischen Batch und Realtime... ...gibt es einen neuen Sweet Spot SMACK Aktualisieren der Nachrichtenseiten Klassifikation von Usern (Business) Realtime Bidding für Advertising IoT bei Automobilherstellern Digitalisierung der Fertigung

Slide 13

Slide 13 text

Was wollen wir? Verlässliche Ingestion Flexible Storage und Query Optionen Anspruchsvolle Analyseoptionen Management Out-Of-the-Box

Slide 14

Slide 14 text

Was ist SMACK - Teil II Architekturbaukasten Best-of-Breed Plattform Bald ein Produkt

Slide 15

Slide 15 text

Mini Batching Wann möchte ich das? Ich muss nicht auf jedes Event im Einzelnen reagieren. Ich möchte nur wissen, was los ist. Abuse Classification User Classification Site Classification

Slide 16

Slide 16 text

Wie geht das? Spark Streaming sammelt Events und generiert RDDs aus den Fenstern. Nutzt Kafka, Datenbanken, Akka oder andere Streams als Input Batches können per ETL in persistente Speicher geflushed werden Batch RDDs können per SQL In-Memory/Disk ausgeführt werden Klassifikation der Daten in neue RDDs oder persistente Speicher

Slide 17

Slide 17 text

Was ist mit λ-Architekturen? Entwickelte Spark Operationen lassen sich sowohl in Batch oder Stream wiederverwenden - sind ja alles RDDs!

Slide 18

Slide 18 text

Ich brauche Realtime! Der Bot darf nicht weiter botten! Welche Anzeige schalte ich? Welches X-Selling Angebot zeige ich? Mit Akka kann ich auf einzelne Events reagieren. Mit Spark Stream und Cassandra habe ich schnelle Speicher um einen Entscheidungskontext zu etablieren.

Slide 19

Slide 19 text

3 Streams der Glückseligkeit Es gibt direct streams zwischen Kafka und Spark. Es gibt raw streams für TCP, UDP Verbindungen, Files, etc. Es gibt reactive streams für Back Pressure Umgang. Kafka kann zwischen raw und reactive Streams konvertieren.

Slide 20

Slide 20 text

Backpressure? Zu Peak Zeiten können mehr Daten ankommen, als in der Zeit verarbeitet werden können. Da Stream Events im Speicher bleiben sollen, muss der Gegendruck gemanaged werden, da sonst ein Speicherüberlauf provoziert wird! mehr später

Slide 21

Slide 21 text

Flow Erfordert ein Event Realtime Handling - eine Reaktion - muss es direkt in Akka eingespielt werden. Sonst über Kafka. Wieso Kafka? Append Only:Consumer können für Tage ausfallen. Broker:Reduktion der Punkt zu Punkt Verbindungen. Router:Routen von Streams inklusive (De-)Multiplexing. Pufferung:Ausgleichen von Lastspitzen. Replay:Fehler im Algorithmus und falsche Daten? Redeploy und Replay!

Slide 22

Slide 22 text

Exactly Once? Wer exactly-once von Infrastruktur fordert, hat keine Ahnung von verteilten Systemen. Kafka unterstützt at-least once. Macht eure Business Logik idempotent! In der Realität ist das ja auch eine Anforderung!

Slide 23

Slide 23 text

Cloud? Bare Metal? Bare Metal ist möglich. Cloud bietet natürlich mehr Schutz vor Ausfällen und Elastizität. Mesos erfordert keine Virtualisierung oder Containerisierung. Kann alle Big Data Tools direkt ausführen. Die Workload bestimmt das Cluster.

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Streams ... sind ein kontinuierlicher Strom von Ereignissen mit einer unbekannten oder unbeschränkter Größe.

Slide 26

Slide 26 text

Conventional Streams Viele Streams laufen über lange Zeiten und haben bedrohliche Lastschwankungen. Buffer können Lastspitzen ausgleichen. Unbound Buffer können bei Speichererschöpfung fatale Probleme auslösen. Bound Buffer haben verschiedene Optionen bei ausgeschöpftem Speicher. FIFO Drop? FILO Drop? Reduced Sampling?

Slide 27

Slide 27 text

Reactive Streams Ist ein Konsument mit der Last überfordert, wechselt er von PUSH zu PULL. Dieser Fallback kann sich durch den Stream Graphen nach vorne durchziehen. Die Stromquelle wird schlussendlich vor die Entscheidung gestellt, wie damit umzugehen ist.

Slide 28

Slide 28 text

SMACK Reactive Streams Akka implementiert Reactive Streams. Spark Streaming 1.5 implementiert Reactive Streams. Spark Streaming 1.6 erlaubt Reactive Stream als Protokoll für die Konsumenten. Kafka ist ein idealer Bound Buffer für Event Ströme. Mesos Frameworks können Konsumenten on-the-fly out-scalen.

Slide 29

Slide 29 text

Functional? Streams wollen parallel abgearbeitet werden! Events sind immutable - das führt zu keinen Überraschungen. Functions haben keine Seiteneffekte - keinen Zustand zwischen den Aufrufen manipulieren. Functions sind First Class - Erhöht die Wiederverwendung.

Slide 30

Slide 30 text

Reuse? s p a r k C o n t e x t . t e x t F i l e ( " / p a t h / t o / i n p u t " ) . m a p { l i n e = > v a l a r r a y = l i n e . s p l i t ( " , " , 2 ) ( a r r a y ( 0 ) , a r r a y ( 1 ) ) } . f l a t M a p { c a s e ( i d , c o n t e n t s ) = > t o W o r d s ( c o n t e n t s ) . m a p ( w = > ( ( w , i d ) , 1 ) ) } . r e d u c e B y K e y { ( c o u n t 1 , c o u n t 2 ) = > c o u n t 1 + c o u n t 2 } . m a p { c a s e ( ( w o r d , p a t h ) , n ) = > ( w o r d , ( p a t h , n ) ) } . g r o u p B y K e y . m a p { c a s e ( w o r d , l i s t ) = > ( w o r d , s o r t B y C o u n t ( l i s t ) ) } . s a v e A s T e x t F i l e ( " / p a t h / t o / o u t p u t " )

Slide 31

Slide 31 text

Danke!