Volgens een recent rapport van IBM Marketing cloud, “is 90 procent van de data in de wereld van vandaag alleen al in de laatste twee jaar gecreëerd, waardoor er 2.5 quintiljoen bytes aan gegevens per dag – en met de opkomst van nieuwe apparaten, sensoren en technologieën zal de datagroei waarschijnlijk nog sneller gaan”.
Technisch betekent dit dat onze wereld van Big Data Processing complexer en uitdagender zal worden. En veel use-cases (bijv. advertenties voor mobiele apps, fraudedetectie, taxiboekingen, patiëntmonitoring, enz.) hebben gegevensverwerking in real-time nodig, op het moment dat de gegevens binnenkomen, om snel uitvoerbare beslissingen te kunnen nemen. Dit is de reden waarom Distributed Stream Processing erg populair is geworden in de Big Data wereld.

Vandaag de dag zijn er een aantal open source streaming frameworks beschikbaar. Interessant is dat ze bijna allemaal vrij nieuw zijn en alleen in de laatste paar jaar zijn ontwikkeld. Dus het is vrij gemakkelijk voor een nieuw persoon om verward te raken in het begrijpen en onderscheiden van streaming frameworks. In deze post zal ik het eerst hebben over typen en aspecten van Stream Processing in het algemeen en dan de meest populaire open source Streaming frameworks vergelijken: Flink, Spark Streaming, Storm, Kafka Streams. Ik zal proberen uit te leggen hoe ze werken (kort), hun use cases, sterke punten, beperkingen, overeenkomsten en verschillen.

Wat is Streaming/Stream Processing :
De meest elegante definitie die ik heb gevonden is : een type data processing engine die is ontworpen met oneindige data sets in gedachten. Niets meer.

In tegenstelling tot Batch processing waar data wordt begrensd met een begin en een eind in een job en de job eindigt na het verwerken van die eindige data, is Streaming bedoeld voor het verwerken van onbegrensde data die in realtime continu binnenkomt voor dagen, maanden, jaren en voor altijd. Als zodanig, altijd bedoeld voor up and running, een streaming applicatie is moeilijk te implementeren en moeilijker te onderhouden.

Belangrijke aspecten van Stream Processing:

Er zijn een aantal belangrijke kenmerken en termen geassocieerd met Stream verwerking die we bewust van moeten zijn om sterke punten en beperkingen van een Streaming kader te begrijpen :

• Aflevergaranties :
  Het betekent wat is de garantie dat wat er ook gebeurt, een bepaalde inkomende record in een streaming-engine zal worden verwerkt. Het kan zijn Atleast-once (zal ten minste een keer worden verwerkt, zelfs in geval van storingen), Atmost-once (mag niet worden verwerkt in geval van storingen) of Exact-once (zal worden verwerkt een en precies een keer, zelfs in geval van storingen) . Uiteraard is Exact-once wenselijk, maar is moeilijk te bereiken in gedistribueerde systemen en gaat ten koste van de prestaties.
• Fouttolerantie:
  In het geval van storingen, zoals knooppunt storingen, netwerk storingen, etc, moet het framework in staat zijn om te herstellen en moet de verwerking weer beginnen vanaf het punt waar het gebleven was. Dit wordt bereikt door checkpointing van de toestand van streaming naar een persistente opslag van tijd tot tijd. bv. checkpointing kafka offsets naar zookeeper na het krijgen van record van Kafka en verwerking it.
• State Management :
  In het geval van stateful verwerking eisen waar we nodig hebben om een aantal toestand (bijv.Bijvoorbeeld het aantal woorden in de records), moet het framework een mechanisme bieden om de statusinformatie te bewaren en bij te werken.
• Prestaties :
  Dit omvat latentie (hoe snel een record kan worden verwerkt), doorvoer (verwerkte records/seconde) en schaalbaarheid. De latentie moet zo klein mogelijk zijn, terwijl de verwerkingscapaciteit zo groot mogelijk moet zijn. Het is moeilijk om beide tegelijk te krijgen.
• Geavanceerde functies : Event Time Processing, Watermarks, Windowing
  Dit zijn functies die nodig zijn als de vereisten voor stream processing complex zijn. Bijvoorbeeld, het verwerken van records gebaseerd op de tijd wanneer het werd gegenereerd bij de bron (event time processing). Om meer in detail te weten, lees deze must-read posts van Google guy Tyler Akidau : deel1 en deel2.
• Volwassenheid :
  Van belang vanuit adoptie oogpunt, is het prettig als het framework al bewezen is en de strijd op schaal getest is door grote bedrijven. Meer kans op goede ondersteuning van de gemeenschap en hulp op stackoverflow.

Twee soorten Stream Processing:

Nu we ons bewust zijn van de termen die we zojuist hebben besproken, is het nu gemakkelijk te begrijpen dat er 2 benaderingen zijn om een Streaming framework te implementeren:

Native Streaming :
Ook bekend als Native Streaming. Het betekent dat elk binnenkomend record wordt verwerkt zodra het arriveert, zonder te wachten op anderen. Er zijn een aantal continu draaiende processen (die we operatoren/taken/bouten noemen, afhankelijk van het framework) die altijd draaien en elk record passeert deze processen om verwerkt te worden. Voorbeelden : Storm, Flink, Kafka Streams, Samza.

Micro-batching :
Ook bekend als Fast Batching. Dit betekent dat binnenkomende records om de paar seconden worden samengevoegd en vervolgens in één enkele minibatch met een vertraging van enkele seconden worden verwerkt. Voorbeelden: Spark Streaming, Storm-Trident.

Beide benaderingen hebben enkele voor- en nadelen.
Native Streaming voelt natuurlijk aan omdat elke record wordt verwerkt zodra deze binnenkomt, waardoor het framework een zo laag mogelijke latency kan bereiken. Maar het betekent ook dat het moeilijk is om fouttolerantie te bereiken zonder afbreuk te doen aan de doorvoer, omdat we voor elk record moeten traceren en checkpoints moeten maken zodra het verwerkt is. Ook is toestandsbeheer eenvoudig omdat er langlopende processen zijn die de vereiste toestand gemakkelijk kunnen handhaven.

Micro-batching, aan de andere kant, is het tegenovergestelde. Fouttolerantie is gratis omdat het in wezen een batch is en de doorvoer is ook hoog omdat verwerking en checkpointing in één keer worden gedaan voor een groep records. Maar het zal ten koste gaan van latency en het zal niet aanvoelen als een natuurlijke streaming. Ook efficiënt state management zal een uitdaging zijn om te onderhouden.

Streaming Frameworks Een voor een:

Storm :
Storm is de hadoop van de streaming wereld. Het is het oudste open source streaming framework en een van de meest volwassen en betrouwbare. Het is echte streaming en is goed voor eenvoudige event based use cases. Ik heb de details over Storm uitvoerig gedeeld in deze posts: deel1 en deel2.

Voordelen:

• Zeer lage latency, true streaming, volwassen en hoge doorvoer
• Uitstekend voor niet-gecompliceerde streaming use cases

Nadelen

• Geen state management
• Geen geavanceerde functies zoals Event time processing, aggregatie, windowing, sessies, watermerken, enz
• Eenmalige garantie

Spark Streaming :

Spark heeft zich ontpopt als echte opvolger van hadoop in Batch processing en het eerste framework dat de Lambda Architectuur volledig ondersteunt (waar zowel Batch als Streaming zijn geïmplementeerd; Batch voor correctheid, Streaming voor snelheid). Het is immens populair, gerijpt en wijdverbreid geadopteerd. Spark Streaming wordt gratis geleverd bij Spark en maakt gebruik van micro batching voor streaming. Voor versie 2.0, had Spark Streaming een aantal serieuze prestatie beperkingen, maar met de nieuwe versie 2.0+, wordt het gestructureerd streamen genoemd en is het uitgerust met vele goede eigenschappen zoals aangepast geheugenbeheer (zoals flink) genaamd wolfraam, watermerken, event time processing ondersteuning, etc. Gestructureerd streamen is ook veel abstracter en er is een optie om te schakelen tussen micro-batching en continue streaming modus in versie 2.3.0. Continuous Streaming mode belooft sub latency te geven zoals Storm en Flink, maar het staat nog in de kinderschoenen met veel beperkingen in operaties.

Voordelen:

• Ondersteunt Lambda architectuur, komt gratis met Spark
• Hoge doorvoer, goed voor veel use-cases waar sub-latency niet vereist is
• Fouttolerantie standaard door micro-batch karakter
• Eenvoudig te gebruiken higher level APIs
• Grote community en agressieve verbeteringen
• Exactly Once

Nadelen

• Niet echt streaming, niet geschikt voor lage latency eisen
• Te veel parameters om af te stellen. Moeilijk om het goed te krijgen. Ik heb een post geschreven over mijn persoonlijke ervaring met het afstellen van Spark Streaming
• Stateless by nature
• Loopt achter op Flink in veel geavanceerde functies

Flink :

Flink heeft ook een vergelijkbare academische achtergrond als Spark. Terwijl Spark van UC Berkley kwam, kwam Flink van de Berlijnse TU Universiteit. Net als Spark ondersteunt het ook Lambda-architectuur. Maar de implementatie is nogal tegengesteld aan die van Spark. Terwijl Spark in wezen een batch is met Spark streaming als micro-batching en speciaal geval van Spark Batch, is Flink in wezen een echte streaming engine die batch behandelt als speciaal geval van streaming met begrensde data. Hoewel API’s in beide frameworks vergelijkbaar zijn, hebben ze geen enkele overeenkomst in implementaties. In Flink, elke functie zoals map, filter, reduce, etc is geïmplementeerd als langlopende operator (vergelijkbaar met Bolt in Storm)

Flink ziet eruit als een echte opvolger van Storm zoals Spark hadoop in batch opvolgde.

Voordelen:

• Leider van innovatie in open source Streaming landschap
• Eerste echte streaming framework met alle geavanceerde functies zoals event time processing, watermerken, etc
• Lage latency met hoge doorvoer, configureerbaar volgens vereisten
• Auto-aanpassing, niet te veel parameters te tunen
• Exacte eenmaal
• Wordt op grote schaal geaccepteerd door grote bedrijven op schaal, zoals Uber, Alibaba.

Nadelen

• Een beetje laat in het spel, er was een gebrek aan adoptie in het begin
• Community is niet zo groot als Spark, maar groeit in snel tempo nu
• Geen bekende adoptie van de Flink Batch als van nu, alleen populair voor streaming.

Kafka Streams :

Kafka Streams, in tegenstelling tot andere streaming frameworks, is een lichtgewicht library. Het is nuttig voor het streamen van gegevens uit Kafka, het doen van transformatie en vervolgens terug te sturen naar Kafka. We kunnen het zien als een bibliotheek vergelijkbaar met Java Executor Service Thread pool, maar met ingebouwde ondersteuning voor Kafka. Het kan goed worden geïntegreerd met elke applicatie en zal werken out of the box.

Door zijn lichtgewicht karakter, kan worden gebruikt in microservices type architectuur. Er is geen match in termen van prestaties met Flink, maar heeft ook geen aparte cluster nodig om te draaien, is erg handig en eenvoudig te implementeren en aan de slag te gaan. Intern maakt gebruik van Kafka Consumer groep en werkt op de Kafka log filosofie.
Dit bericht legt grondig uit de use cases van Kafka Streams vs Flink Streaming.

Een groot voordeel van Kafka Streams is dat de verwerking ervan Exact een keer van eind tot eind is. Het is mogelijk omdat zowel de bron als de bestemming, beide Kafka zijn en vanaf Kafka 0.11 versie die rond juni 2017 is uitgebracht, wordt Exact eenmaal ondersteund. Voor het inschakelen van deze functie, hoeven we alleen maar een vlag in te schakelen en het zal out of the box werken. Voor meer details gedeeld hier en hier.

Voordelen:

• Zeer lichtgewicht bibliotheek, goed voor microservices, IOT-toepassingen
• Heeft geen dedicated cluster
• Erft alle Kafka goede kenmerken
• Ondersteunt Stream joins, intern gebruikt rocksDb voor het behoud van state.
• Exactly Once ( Kafka 0.11 en hoger).

Nadelen

• Nauw verbonden met Kafka, kan niet gebruiken zonder Kafka in beeld
• Nog vrij nieuw in kinderschoenen, nog te testen in grote bedrijven
• Niet voor zwaar werk zoals Spark Streaming, Flink.

Samza :

Wij zullen Samza in het kort behandelen. Samza van 100 voet lijkt op Kafka Streams in aanpak. Er zijn veel overeenkomsten. Beide frameworks zijn ontwikkeld door dezelfde ontwikkelaars die Samza implementeerden bij LinkedIn en daarna Confluent oprichtten waar ze Kafka Streams schreven. Beide technologieën zijn nauw verbonden met Kafka, halen ruwe data uit Kafka en sturen vervolgens verwerkte data terug naar Kafka. Ze gebruiken dezelfde Kafka Log filosofie. Samza is een soort geschaalde versie van Kafka Streams. Terwijl Kafka Streams is een bibliotheek bedoeld voor microservices, Samza is full fledge cluster verwerking die draait op Yarn.
Voordelen :

• Zeer goed in het handhaven van grote staten van informatie (goed voor use case van het samenvoegen van streams) met behulp van rocksDb en kafka log.
• Fouttolerant en hoge prestaties met behulp van Kafka-eigenschappen
• Een van de opties om te overwegen als u al Yarn en Kafka in de verwerkingspijplijn gebruikt.
• Goede Yarn-burger
• Lage latency , Hoge doorvoer , volwassen en getest op schaal

Nadelen :

• Nauw gekoppeld met Kafka en Yarn. Niet gemakkelijk te gebruiken als een van deze niet in uw processing pipeline.
• Atleast-Once verwerking garantie. Ik weet niet zeker of het nu precies eenmaal ondersteunt zoals Kafka Streams na Kafka 0.11
• Misbruik van geavanceerde streaming features zoals Watermarks, Sessions, triggers, etc

Vergelijking van Streaming Frameworks:

We kunnen technologieën alleen vergelijken met vergelijkbare aanbiedingen. Terwijl Storm, Kafka Streams en Samza nu nuttig lijken voor eenvoudigere use-cases, is de echte concurrentie duidelijk tussen de zwaargewichten met de nieuwste features: Spark vs Flink

Als we het over vergelijken hebben, hebben we meestal de neiging om te vragen: Laat me de cijfers zien 🙂

Benchmarking is een goede manier om te vergelijken, maar alleen als het door derden is gedaan.

Een van de oude benchmarking was bijvoorbeeld deze.
Maar dit was in tijden vóór Spark Streaming 2.0, toen het beperkingen had met RDDs en project wolfraam nog niet bestond.
Nu met Structured Streaming post 2.0 release , Spark Streaming probeert veel in te halen en het lijkt erop dat er een harde strijd gaat komen.

Recently benchmarking is een soort van open kat gevecht geworden tussen Spark en Flink.

Spark had onlangs een benchmarking vergelijking gedaan met Flink waarop Flink ontwikkelaars reageerden met een andere benchmarking waarna Spark jongens de post aanpasten.

Het is beter om benchmarking deze dagen niet te geloven omdat zelfs een kleine tweaking de cijfers volledig kan veranderen. Niets is beter dan zelf proberen en testen voordat je beslist.
Vanaf vandaag, is het vrij duidelijk Flink leidt de Streaming Analytics ruimte, met de meeste van de gewenste aspecten, zoals precies een keer, doorvoer, latency, state management, fouttolerantie, geavanceerde functies, enz.

Deze zijn mogelijk vanwege enkele van de echte innovaties van Flink, zoals licht gewogen snapshots en off heap custom memory management.
Eén belangrijk punt van zorg met Flink was de volwassenheid en het adoptieniveau tot enige tijd terug, maar nu gebruiken bedrijven als Uber, Alibaba, CapitalOne Flink streaming op grote schaal, wat het potentieel van Flink Streaming bevestigt.

Onlangs heeft Uber hun nieuwste Streaming analytics framework genaamd AthenaX, dat is gebouwd op de top van Flink engine, open source gemaakt. In deze post hebben ze besproken hoe ze hun streaming analytics verplaatst van STorm naar Apache Samza om nu Flink.

Een belangrijk punt om op te merken, als je al hebt gemerkt, is dat alle native streaming frameworks zoals Flink, Kafka Streams, Samza die staat beheer ondersteunen intern gebruikt RocksDb. RocksDb is uniek in die zin dat het persistente toestand lokaal op elke node bewaart en zeer performant is. Het is een cruciaal onderdeel geworden van nieuwe streaming systemen. Ik heb gedetailleerde informatie over RocksDb gedeeld in een van de vorige posts.

Hoe het beste streaming framework te kiezen :

Dit is het belangrijkste deel. En het eerlijke antwoord is: het hangt ervan af 🙂
Het is belangrijk om in gedachten te houden dat geen enkele verwerking framework kan zilveren kogel voor elke use-case zijn. Elk framework heeft een aantal sterke punten en een aantal beperkingen ook. Toch, met enige ervaring, zal delen een paar tips om te helpen bij het nemen van beslissingen:

1. Hangt af van de use-cases:
   Als de use case eenvoudig is, is er geen noodzaak om te gaan voor de nieuwste en grootste kader als het is ingewikkeld om te leren en te implementeren. Veel hangt af van hoeveel we bereid zijn te investeren voor hoeveel we er voor terug willen. Bijvoorbeeld, als het een eenvoudig IOT soort van event gebaseerd waarschuwingssysteem is, is Storm of Kafka Streams prima om mee te werken.
2. Overwegingen voor de toekomst:
   Op hetzelfde moment, moeten we ook een bewuste overweging over wat zal de mogelijke toekomstige use cases zijn? Is het mogelijk dat er in de toekomst behoefte ontstaat aan geavanceerde functies, zoals event time processing, aggregatie, stream joins, enzovoort? Als het antwoord ja is of kan zijn, dan is het beter om verder te gaan met geavanceerde streaming frameworks zoals Spark Streaming of Flink. Eenmaal geïnvesteerd en geïmplementeerd in een technologie, is het moeilijk en enorme kosten om later te veranderen. Bijvoorbeeld, in ons vorige bedrijf hadden we een Storm pijplijn draaiende vanaf de laatste 2 jaar en het werkte perfect totdat er een eis kwam voor het unicificeren van inkomende events en alleen unieke events te rapporteren. Dit vereiste state management, wat niet inherent wordt ondersteund door Storm. Hoewel ik het implementeerde met behulp van tijd gebaseerde in-memory hashmap, maar het was met de beperking dat de status weggaat bij een herstart. Ook gaf het problemen tijdens dergelijke veranderingen die ik in een van de vorige berichten heb gedeeld. Het punt dat ik probeer te maken is, als we proberen om iets te implementeren op onze eigen die het kader niet expliciet biedt, zijn we gebonden aan onbekende problemen te raken.
3. Existing Tech Stack :
   Een ander belangrijk punt is om de bestaande tech stack te overwegen. Als de bestaande stack van begin tot eind Kafka bevat, dan zijn Kafka Streams of Samza misschien gemakkelijker te gebruiken. Op dezelfde manier, als de verwerkingspijplijn is gebaseerd op Lambda architectuur en Spark Batch of Flink Batch is al aanwezig, dan is het zinvol om Spark Streaming of Flink Streaming te overwegen. Bijvoorbeeld, in mijn een van de vorige projecten had ik Spark Batch al in de pijplijn en dus toen de streaming eis kwam, was het vrij eenvoudig om Spark Streaming te kiezen die bijna dezelfde vaardigheden en code base.

Kortom, als we begrijpen sterke punten en beperkingen van de raamwerken samen met onze use cases goed, dan is het makkelijker om te kiezen of in ieder geval het filteren van de beschikbare opties. Ten slotte is het altijd goed om POC’s te hebben zodra een paar opties zijn geselecteerd. Iedereen heeft tenslotte een andere smaak bud.

Conclusie :

Apache Streaming ruimte ontwikkelt zich in zo’n snel tempo dat deze post zou kunnen zijn verouderd in termen van informatie in een paar jaar. Op dit moment zijn Spark en Flink de zwaargewichten aan de leiding in termen van ontwikkelingen, maar sommige nieuwkomers kunnen nog steeds komen en meedoen in de race. Apache Apex is er daar één van. Er zijn ook proprietary streaming oplossingen die ik niet heb behandeld, zoals Google Dataflow. Mijn doel van deze post was om iemand die nieuw is in streaming te helpen begrijpen, met een minimum aan jargons, enkele kernbegrippen van streaming samen met sterke punten, beperkingen en use cases van populaire open source streaming frameworks. Hoop dat de post nuttig was op een of andere manier.

Happy Streaming!!

Je kunt me volgen op Linkedin en Quora