FAST DATA SMACK DOWN

Talk about Spark, Mesos, Akka, Cassandra and Kafka

Transcript

1. FAST DATA SMACK DOWN Data Done Right Created by / Stefan Siprell @stefansiprell
2. SMACK? Spark Mesos Akka Cassandra Kafka
3. 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.
4. 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
5. 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
6. 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
7. 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
8. Am Anfang gab es HADOOP
9. Big-Batch sah, dass es gut war und hat fortan gemapped and gereduced
10. Doch Business wollte nicht immer warten. Business will immer mehr... und das immer schneller
11. 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.
12. 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
13. Was wollen wir? Verlässliche Ingestion Flexible Storage und Query Optionen Anspruchsvolle Analyseoptionen Management Out-Of-the-Box
14. Was ist SMACK - Teil II Architekturbaukasten Best-of-Breed Plattform Bald ein Produkt
15. 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
16. 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
17. Was ist mit λ-Architekturen? Entwickelte Spark Operationen lassen sich sowohl in Batch oder Stream wiederverwenden - sind ja alles RDDs!
18. 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.
19. 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.
20. 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
21. 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!
22. 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!
23. 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.
25. Streams ... sind ein kontinuierlicher Strom von Ereignissen mit einer unbekannten oder unbeschränkter Größe.
26. 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?
27. 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.
28. 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.
29. 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.
30. 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 " )
31. Danke!