Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Streaming Plattformen und die Qual der Wahl

633 views

Published on

Grundlegende Streaming Konzepte, Vorstellungen ausgewählter Frameworks sowie Vergleich der Frameworks inkl. einer unverbindlichen Empfehlung

Published in: Software
  • Be the first to comment

  • Be the first to like this

Streaming Plattformen und die Qual der Wahl

  1. 1. Stream Processing Plattformen & die Qual der Wahl_ @matthiasniehoff WebTechNight Karlsruhe
  2. 2. •Grundlegende Konzepte vermitteln •Kriterien zur Auswahl vorstellen •Ausgewählte Frameworks erläutern •Unverbindliche Empfehlungen Ziel des Vortrags_ 2
  3. 3. Die Basics 3
  4. 4. Request/Response_ 4 Client Server
  5. 5. Batch_ 5 Client Server
  6. 6. Streaming_ 6 Client Server
  7. 7. Warum Stream Processing?_ 7
  8. 8. •Infinite and continuous data Unendliche, kontinuierliche Daten_ 8
  9. 9. •And some mind breaking Bulletpoints 1 •And some mind breaking Bulletpoints 2 •And some mind breaking Bulletpoints 3 • Or some great Sub-Bulletpoints 1 • Or some great Sub-Bulletpoints 2 • Or some great Sub-Bulletpoints 3 •And some mind breaking Bulletpoints 4 •And some mind breaking Bulletpoints 5 Geschwindigkeit & (Near) Real Time_ 9
  10. 10. Erst Verarbeiten, dann speichern_ 10 Persistenz Query Persistenzstream processing stream processing stream processing
  11. 11. Stream Processing Plattform? 11
  12. 12. –Tyler Akidau “ ... an execution engine designed for unbounded data sets, and nothing more” 12
  13. 13. •Unbegrenzter Datenstrom •Verteilt über verschiedene Knoten •Kontinuierliche Verarbeitung, Aggregation und Analyse •MapReduce ähnliches Verarbeitungsmodell •In-Memory Verarbeitung •Latenz im Bereich von Millisekunden oder Sekunden •Skalieren durch Verteilen •Häufig modelliert als DAG Distributed Stream Processing_ 13
  14. 14. •Eventzeit: • Zeitpunkt, an dem das Event aufgetreten ist •Verarbeitungszeit: • Zeitpunkt, an dem das Event vom System beobachtet und verarbeitet wurde Eventzeit vs. Verarbeitungszeit_ 14 Event Verarbeitung 1 2 3 4 5 6 7 8 9t in Minuten
  15. 15. •Differenz ist nicht konstant • Ressourcen bedingt (CPU, Netzwerk,..) • Software bedingt (verteilte Systeme..) • Daten bedingt (Schlüsselverteilung, Varianzen in Daten selbst) •Analyse nach Verarbeitungszeit • einfacher aber ggfs. zu ungenau •Analyse nach Eventzeit • komplexer, dafür genauer Eventzeit vs. Verarbeitungszeit_ 15
  16. 16. •Nicht triviale Anwendungen benötigen meist einen State • z.b. Aggregationen über einen längeren / unendlichen Zeitraum • in-memory • interessant im Fehlerfall State & Window Verarbeitung_ 16
  17. 17. •Window als (zeitlich) begrenzter State • Tumbling Window • Sliding Window • Session Window •Unterschiedliche Trigger • Zeit • Anzahl Windowing & Sliding_ 17
  18. 18. Tumbling Window_ 18
  19. 19. Sliding Window_ 19
  20. 20. Session Window_ 20 Zeit User 1 User 2 Inaktivität Inaktivität
  21. 21. •Mit Verarbeitungszeit einfach •Mit Eventzeit schwerer • Vollständigkeit (out of order Events) • Buffering •Strategien bei Eventzeit Windows • Watermarks • Trigger • Akkumulation •Mehr Informationen • https://www.oreilly.com/ideas/the-world-beyond-batch- streaming-101 • http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf Window Verarbeitung und Zeiten_ 21
  22. 22. •Wann werden States materialisiert? •Watermark: Wann habe ich alle Daten zusammen? •Trigger: Zusätzliche Auslöser, sowohl früher als auch später •Akkumulation: Wie werden die einzelne Teile zusammengefügt? Exkurs: Watermarks, Trigger, Akkumulation_ 22 input .apply(Window.into(FixedWindows.of(Duration.standardMinutes(2))) .triggering( AtWatermark() .withEarlyFirings(AtPeriod(Duration.standardMinutes(1))) .withLateFirings(AtCount(1)))) .withAllowedLateness(Duration.standardMinutes(1))) .discardingFiredPanes()) .apply(Sum.integersPerKey()); vgl. https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102
  23. 23. Die Kandidaten 23
  24. 24. •Gestartet 2010 durch BackType/Twitter, Apache seit 2013 •Pionier im Big Data / Stream Bereich •Technologie der Lambda Architektur •Low Level API •Spouts und Bolts beschreiben eine Topologie •Trident: High Level Erweiterung • Aggregationen • State & Window Operationen • Join, Merge, Group, ... Apache Storm_ 24
  25. 25. •Entwickelt bei LinkedIn, Open Source 2013 •Verfolgt den Log Ansatz von Kafka •Ausgeführt auf YARN •Geeignet für große States •Erweiterbar über APIs Apache Samza_ 25
  26. 26. •Open Source (2010) & Apache Projekt (2013) •Einheitliche Batch & Stream Verarbeitung •Hohe Verbreitung •RDD als Basis, DataFrames/DataSets als Optimierung Apache Spark_ 26
  27. 27. •2010 als Forschungsprojekt gestartet, seit 2014 Apache •Low Latency Streaming und High Throughput Batch Processing •Streaming First Ansatz •Flexible States und Windows Apache Flink_ 27
  28. 28. •Einfache Bibliothek, ohne Laufzeitumgebung •Benötigt Kafka (0.10) •Nutzt Kafka Consumer Techniken • Reihenfolge, Partitionierung, Skalierung •Quelle, Senke: Nur Kafka Topics •Kafka Connect für andere Datenquellen/senken •Grundidee: Streams ≈ Tabellen Kafka Streams_ 28 (key1, value1) key1 value1 key1 value3 key2 value2 key1 value1 key2 value2 (key2, value2) (key1, value3)
  29. 29. Die Analyse 29
  30. 30. •Engine •Programming Model •Skalierbarkeit •Latenz •Durchsatz •Resilienz / Delivery Guarantees •Community Aspekte von Streaming Anwendungen_ 30
  31. 31. Engine - Native Streaming_ 31 Empfänger Verarbeitung Senke geringe Latenz geringer Durchsatz flexibel Fehlertoleranz komplexer Lastenverteilung komplexer
  32. 32. Engine - Microbatching_ 32 Empfänger Verarbeitung Senke Microbatches hoher Durchsatz höhere Latenz einfacher Fehlertolerant weniger Flexibel (z.B. Windows) State Verarbeitung komplexer
  33. 33. •Operatoren und Quellen als Komponenten •Eigene Komponenten •manuelle Topologie Definition Programmiermodell_ 33 Komponentenbasiert •High Level API •Higher Order Functions •Abstrakte Datentypen •Fortgeschrittene Operationen inkludiert •Eingebaute Optimierungen Deklarativ
  34. 34. Word Count - Flink_ 34 val env = StreamExecutionEnvironment.getExecutionEnvironment val text = env.socketTextStream("localhost", 9999) val counts = text
 .flatMap(_.toLowerCase.split("W+"))
 .filter( _.nonEmpty) .map(_, 1) .groupBy(0) .sum(1) counts.print env.execute("Scala Socket Stream WordCount") Stateful Operation
  35. 35. Word Count - Spark_ 35 val sparkConf = 
 new SparkConf().setAppName("Streaming Word Count") val ssc = new StreamingContext(sparkConf, Seconds(1)) ssc.checkpoint(".") val mappingFunc = (key: String, value: Option[Int], state: State[Int]) => { val sum = value.getOrElse(0) + state.getOption.getOrElse(0) val output = (key, sum) state.update(sum) output } val wordCountState = StateSpec.function(mappingFunc)
  36. 36. Word Count - Spark_ 36 val lines = ssc.socketTextStream(args(0), args(1).toInt) val words = lines.flatMap(_.split(" ")) val wordsWithCount = words.map(x => (x, 1)) val stateDstream = wordsWithCount.mapWithState(wordCountState) stateDstream.print() ssc.start() ssc.awaitTermination()
  37. 37. •Spark 2.0 wurde releast • Dataframes für Streaming • Schneller, flexibler, ... • Preview Status Spark 2.0_ 37
  38. 38. Word Count - Storm_ 38 TopologyBuilder builder = new TopologyBuilder(); builder.setSpout("spout", new RandomSentenceSpout(), 5); builder.setBolt("split", new SplitSentence(), 8) .shuffleGrouping(„spout"); builder.setBolt("count", new WordCount(), 12) .fieldsGrouping("split", new Fields("word"));
  39. 39. Word Count - Storm_ 39 Config conf = new Config(); conf.setMaxTaskParallelism(3); LocalCluster cluster = new LocalCluster(); cluster.submitTopology("word-count", conf, builder.createTopology()); Thread.sleep(10000); cluster.shutdown();
  40. 40. Word Count - Storm_ 40 public static class WordCount extends BaseBasicBolt { Map<String, Integer> counts = new HashMap<String, Integer>(); public void execute(Tuple tuple, BasicOutputCollector collector) { String word = tuple.getString(0); Integer count = counts.get(word); if (count == null) count = 0; count++; counts.put(word, count); collector.emit(new Values(word, count)); } public void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declare(new Fields("word", "count")); } }
  41. 41. Word Count - Storm Trident_ 41 TridentTopology topology = new TridentTopology(); TridentState wordCounts = topology.newStream("spout1", spout) .each(new Fields("sentence"), new Split(), new Fields("word")) .groupBy(new Fields("word")) .persistentAggregate(new MemoryMapState.Factory(), new Count(), new Fields("count")) .parallelismHint(6); Trident
  42. 42. Word Count - Storm Trident_ 42 public class Split extends BaseFunction { public void execute(TridentTuple tuple, TridentCollector collector) { String sentence = tuple.getString(0); for(String word: sentence.split(" ")) { collector.emit(new Values(word)); } } } Trident
  43. 43. Word Count - Samza_ 43 class WordCountTask extends StreamTask with InitableTask { private var store: CountStore = _ def init(config: Config, context: TaskContext) { this.store = context.getStore("wordcount-store") .asInstanceOf[KeyValueStore[String, Integer]] }
  44. 44. Word Count - Samza_ 44 override def process(envelope: IncomingMessageEnvelope, collector: MessageCollector, coordinator: TaskCoordinator) { val words = envelope.getMessage.asInstanceOf[String].split(" ") words.foreach { key => val count: Integer = Option(store.get(key)).getOrElse(0) store.put(key, count + 1) collector.send(new OutgoingMessageEnvelope(new SystemStream("kafka", "wordcount"), (key, count))) } }
  45. 45. Word Count - Kafka Streams_ 45 KStreamBuilder builder = new KStreamBuilder(); KStream<String, String> source = builder .stream("streams-file-input"); KTable<String, Long> counts = source .flatMapValues(value -> Arrays.asList(value.toLowerCase().split("W+"))) .map((key, value) -> new KeyValue<>(value, value)) .countByKey("Counts") counts.to(Serdes.String(), Serdes.Long(), "streams-wordcount- output"); KafkaStreams streams = new KafkaStreams(builder, props); streams.start(); Stateful Operation
  46. 46. •Skalieren durch Partitionierung • Partitionieren der Daten • Partitionieren des Flows Skalierbarkeit_ 46
  47. 47. Spark - Cluster_ 47
  48. 48. Flink - Cluster_ 48
  49. 49. •Erneute Verarbeitung nicht einfach möglich •Anfang und Ende schwer zu bestimmen •State muss auch gesichert werden •Verschiedene Ansätze • Record Ack • Micro Batching • Transactional Updates • Snapshots • Change Logs Fault Tolerance_ 49
  50. 50. Fault Tolerance - Storm_ 50 Ack Ack Ack Ack Ack Ack
  51. 51. •Fehlgeschlagene Microbatches werden wiederholt •Batch Acknowledge statt Record Acknowledge •Checkpoints für States Fault Tolerance - Spark & Storm Trident_ 51
  52. 52. •Transaktionale Updates auf Transaction Log •Kafka als Transaction Log Fault Tolerance - Samza_ 52 partition 0
 partition 1 partition 2 Checkpoint partition 0: offset .. partition 1: offset .. partition 2: offset .. SamzaKafka Kafka
  53. 53. •Distributed Checkpoints Fault Tolerance - Flink_ 53
  54. 54. •Basiert auf der neuen Consumer API •State Changelog als Kafka Topic (mit Log Compaction) Fault Tolerance - Kafka Streams_ 54
  55. 55. •Maximal mögliche Garantien •Beeinflussen Performance •Nicht in jeder Kombination möglich (abhängig von Quelle) •At-Least-Once + Idempotente Operationen häufig ausreichend Zustellungsgarantien_ 55 Trident At-least-once Exactly-once* Exactly-once* At-least-once Exactly-once* At-least-once
  56. 56. •Abhängig von der Runtime •Höhere Latenz --> höherer Durchsatz gilt nur noch teilweise Latenz & Durchsatz_ 56 ~50ms 500ms 30.000ms Samza Storm Flink Spark Streaming Storm Trident Custom Kafka Streams
  57. 57. Latenz & Durchsatz_ 57 https://yahooeng.tumblr.com/post/135321837876/benchmarking-streaming-computation-engines-at Throughput Latenz
  58. 58. •Viele Variablen, Unparteiische Tests schwierig •Latenz vs. Durchsatz •Delivery Guarantees •Fehlertoleranz •Tuning •Netzwerk, Daten Lokalität, Serialisierung Performance_ 58
  59. 59. •Native Eventzeitverarbeitung in Flink und Storm • Out-of-order Events • Watermarks • Trigger •Eventzeit als Key in anderen Framework möglich • Keine out-of-order Events • Begrenzte Window Lebenszeit (Kafka) Event- & Verarbeitungszeit_ 59 final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
  60. 60. •Idee der „continuous application“ Queryable State_ 60 state Query stream processing
  61. 61. •In Notebooks (Zeppelin, Spark Notebook,...) Queryable State_ 61 dstream.foreachRDD(rdd=> rdd.toDF().registerAsTable("tweets") ) select createdAt, count(1) from tweets group by createdAt order by createdAt •Direkt in der Streaming Anwendung: Geplant/Umgesetzt • Spark (SPARK-16738) • Kafka Streams (KAFKA-3909, v0.10.1.0) • Flink (FLINK-3779, v1.2.0)
  62. 62. Laufzeitumgebung - Cluster vs. Bibliothek_ 62 YARN
  63. 63. Das Ergebnis 63
  64. 64. Überblick_ 64 Trident Engine Nativ Microbatching Microbatching Nativ Nativ Nativ Programmier- modell Komponentenbasiert Deklarativ Komp. basiert Deklarativ Beides Durchsatz Mittel Gering Sehr Hoch Hoch Hoch Hoch Latenz Sehr Gering Mittel Mittel Gering Gering Gering Garantien At-least-once Exactly-once* Exactly-once* At-least-once Exactly-once* At-least-once Eventzeit Handling Nein Nein Nein/Ja* Nein Ja Ja* Reife Hoch Hoch Hoch Hoch Hoch Mittel Community & Ökosystem Hoch Hoch Hoch Mittel Mittel Mittel Laufzeit- umgebung Cluster Cluster Cluster Cluster Cluster Bibliothek
  65. 65. •bereits Spark Batch Anwendungen vorhanden sind •komplexe Analysen ausgeführt werden sollen •eine Hadoop Distribution vorhanden ist •viele Umsysteme integriert werden •eine große Community wichtig ist •Scala kein Problem ist •Latenz kein Kriterium ist Spark Streaming wenn..._ 65
  66. 66. •Sehr niedrige Latenz, niedriges Volumen •At-Least Once Verarbeitung •Zustandslose Verarbeitung •Ggfs. Heron als Alternative Storm für ..._ 66
  67. 67. •Für Eventzeit Verarbeitung •Für pures Streaming •Sehr gute Konzepte •Nutzen und Mitarbeit an einem jungen Projekt Und Flink ..._ 67
  68. 68. •Kafka omnipräsent ist •Die Verarbeitung simpel ist •Keine Streams korreliert werden •Wenn das Deployment einfach sein soll •Ein Scheduler vorhanden ist Kafka Streams, wenn _ 68
  69. 69. •Es bereits verwendet wird ;-) Samza wenn ..._ 69
  70. 70. •And some mind breaking Bulletpoints 1 •And some mind breaking Bulletpoints 2 •And some mind breaking Bulletpoints 3 • Or some great Sub-Bulletpoints 1 • Or some great Sub-Bulletpoints 2 • Or some great Sub-Bulletpoints 3 •And some mind breaking Bulletpoints 4 •And some mind breaking Bulletpoints 5 Weitere Aspekte & Tools_ 70
  71. 71. •Apache Beam • High Level API für Streaming Runner •Google Cloud Data Flow • Googles Cloud Streaming Framework; Beam Implementierung •Apex • YARN basiert, statische Topologie, Änderungen zur Laufzeit •Flume • Logfile Streaming insb. in HDFS •Heron • Storm Nachfolger, API kompatibel, verbesserter Throughput & Latency Ein Satz zu_ 71
  72. 72. 72
  73. 73. •https://www.oreilly.com/ideas/the-world-beyond-batch- streaming-101 •https://www.oreilly.com/ideas/the-world-beyond-batch- streaming-102 •http://data-artisans.com/apache-flink-apache-kafka-streams/ •https://cloud.google.com/blog/big-data/2016/05/why-apache- beam-a-google-perspective Leseempfehlungen_ 73
  74. 74. Flink Workshop_ 74 München: 13.12.2016 Hamburg: tba (Januar/Februar 2017) https://www.codecentric.de/2016/10/19/apache-flink-workshops-on-tour/
  75. 75. 75 Fragen?_
  76. 76. Vielen Dank! Matthias Niehoff IT-Consultant 90 codecentric AG Gartenstraße 69b 76135 Karlsruhe, Germany mobil: +49 (0) 172.1702676 matthias.niehoff@codecentric.de www.codecentric.de blog.codecentric.de matthiasniehoff
  77. 77. •Logfile: Linux Screenshots, Flickr •Sensors, IT Network: Wikipedia •Devices: Brad Forst, Flickr •Speed: Rool Paap, Flickr •Graph: Wikipedia •Stateful Processing: data-artisans.com •Window & Sliding Windows, Flink Übersicht, Flink Fault Tolerance: Apache Flink •Storm Topologien: Apache Storm •Spark Übersicht: Apache Spark •Samza Übersicht: Apache Samza •Unendliche Daten: https://i.ytimg.com/vi/9rE3kbGmP4w/maxresdefault.jpg •Kafka Streams FT: http://image.slidesharecdn.com/kafkastreams- kafkasummitneha-160511194334/95/introducing-kafka-streams-largescale- stream-processing-with-kafka-neha-narkhede-37-638.jpg?cb=1462995961 Reference_ 77
  78. 78. •http://de.slideshare.net/PetrZapletal1/distributed-realtime- stream-processing-why-and-how-20 •http://data-artisans.com/high-throughput-low-latency-and- exactly-once-stream-processing-with-apache-flink/ •https://www.oreilly.com/ideas/the-world-beyond-batch- streaming-101 •https://databaseline.files.wordpress.com/2016/03/apache- streaming-technologies3.png •O Rly from @ThePracticalDev •Pictures partly from Apache Flink and Apache Spark Reference_ 78

×