Enligt en färsk rapport från IBM Marketing cloud har 90 procent av datan i världen i dag skapats bara under de senaste två åren, vilket har skapat 2.5 kvintiljoner bytes data varje dag – och med nya enheter, sensorer och tekniker som dyker upp kommer datatillväxten troligen att accelerera ännu mer”.
Tekniskt sett innebär detta att vår värld för bearbetning av stora data kommer att bli mer komplex och mer utmanande. Och många användningsområden (t.ex. annonser i mobilappar, upptäckt av bedrägerier, taxibokning, patientövervakning etc.) behöver databehandling i realtid, i takt med att data anländer, för att kunna fatta snabba beslut som kan användas. Det är därför som Distributed Stream Processing har blivit mycket populärt i Big Data-världen.

I dag finns det ett antal ramverk för streaming med öppen källkod tillgängliga. Intressant nog är nästan alla av dem ganska nya och har utvecklats bara under de senaste åren. Det är därför ganska lätt för en ny person att bli förvirrad när det gäller att förstå och skilja mellan olika streamingramverk. I det här inlägget kommer jag först att tala om typer och aspekter av Stream Processing i allmänhet och sedan jämföra de mest populära ramverken för streaming med öppen källkod: Flink, Spark Streaming, Storm, Kafka Streams. Jag kommer att försöka förklara hur de fungerar (kortfattat), deras användningsområden, styrkor, begränsningar, likheter och skillnader.

Vad är Streaming/Stream Processing :
Den mest eleganta definitionen jag hittade är : en typ av databehandlingsmotor som är utformad med oändliga datamängder i åtanke. Inget mer.

Till skillnad från batchbehandling där data är avgränsade med en start och ett slut i ett jobb och jobbet avslutas efter att ha behandlat dessa begränsade data, är Streaming avsett för behandling av obegränsade data som kommer i realtid kontinuerligt i dagar, månader, år och för evigt. Eftersom en streamingapplikation alltid är avsedd att vara igång är den svår att implementera och svårare att underhålla.

Väsentliga aspekter av strömbearbetning:

Det finns några viktiga egenskaper och termer som är förknippade med strömbearbetning och som vi bör känna till för att förstå styrkor och begränsningar hos ett Streaming-ramverk :

• Leveransgarantier :
  Det innebär att det är garanterat att oavsett vad som händer så kommer en viss inkommande post i en strömningsmotor att bearbetas. Det kan vara antingen Atleast-once (kommer att behandlas minst en gång även vid fel), Atmost-once (får inte behandlas vid fel) eller Exactly-once (kommer att behandlas en och exakt en gång även vid fel). Exactly-once är naturligtvis önskvärt men är svårt att uppnå i distribuerade system och innebär kompromisser med prestandan.
• Feltolerans:
  I händelse av fel, t.ex. nodfel, nätverksfel etc., bör ramverket kunna återhämta sig och börja bearbetningen på nytt från den punkt där det slutade. Detta uppnås genom att man från tid till annan kontrollerar tillståndet för streamingen till ett beständigt lagringsutrymme, t.ex. kontrollerar kafka offsets till zookeeper efter att ha hämtat en post från Kafka och bearbetat den.
• Tillståndsförvaltning :
  Inför tillståndskrävande bearbetningskrav där vi måste upprätthålla ett visst tillstånd (t.ex.t.ex. räkningar av varje distinkt ord som ses i poster), bör ramverket kunna tillhandahålla en mekanism för att bevara och uppdatera tillståndsinformation.
• Prestanda :
  Detta inkluderar latens (hur snabbt en post kan bearbetas), genomströmning (poster som bearbetas/sekund) och skalbarhet. Latency bör vara så liten som möjligt medan throughput bör vara så stor som möjligt. Det är svårt att få båda samtidigt.
• Avancerade funktioner : Dessa är funktioner som behövs om kraven på strömbearbetning är komplexa. Till exempel kan man behandla poster baserat på den tidpunkt då de genererades vid källan (händelsetidsbehandling). Om du vill veta mer i detalj kan du läsa dessa inlägg som Google-killen Tyler Akidau måste läsa: del 1 och del 2.
• Mognad :
  Viktigt ur adoptionssynpunkt, det är trevligt om ramverket redan är beprövat och stridstestat i stor skala av stora företag. Det är troligare att få bra samhällsstöd och hjälp på stackoverflow.

Två typer av strömbearbetning:

När man nu är medveten om termerna vi just diskuterat är det nu lätt att förstå att det finns två tillvägagångssätt för att implementera ett ramverk för streaming:

Native Streaming :
Och även känd som Native Streaming. Det innebär att varje inkommande post behandlas så snart den anländer, utan att vänta på andra. Det finns några processer som körs kontinuerligt (som vi kallar operatörer/uppgifter/bultar beroende på ramverket) som körs i all oändlighet och varje post passerar genom dessa processer för att behandlas. Exempel : Storm, Flink, Kafka Streams, Samza.

Micro-batching :
Också känt som Fast Batching. Det innebär att inkommande poster med några sekunders mellanrum samlas ihop och sedan behandlas i en enda minibatch med några få sekunders fördröjning. Exempel: Spark Streaming, Storm-Trident.

Båda tillvägagångssätten har vissa för- och nackdelar.
Native Streaming känns naturligt eftersom varje post bearbetas så fort den anländer, vilket gör det möjligt för ramverket att uppnå minsta möjliga latenstid. Men det innebär också att det är svårt att uppnå feltolerans utan att kompromissa med genomströmningen eftersom vi för varje post måste spåra och kontrollera när den har behandlats. Det är också lätt att hantera tillståndet eftersom det finns processer som löper länge och som lätt kan upprätthålla det nödvändiga tillståndet.

Micro-batching , å andra sidan, är raka motsatsen. Feltolerans är gratis eftersom det i huvudsak är en batch och genomströmningen är också hög eftersom bearbetning och kontrollpunktsättning sker i ett svep för en grupp av poster. Men det sker på bekostnad av en viss latenstid och det kommer inte att kännas som en naturlig strömning. Dessutom kommer effektiv tillståndshantering att vara en utmaning att underhålla.

Streamingramverk en efter en:

Storm :
Storm är hadoop i streamingvärlden. Det är det äldsta ramverket för streaming med öppen källkod och ett av de mest mogna och tillförlitliga. Det är äkta streaming och är bra för enkla händelsebaserade användningsfall. Jag har delat detaljer om Storm utförligt i dessa inlägg: del1 och del2.

Fördelar:

• Varje låg latenstid, sann streaming, mogen och hög genomströmning
• Utmärkt för okomplicerade användningsfall för streaming

Nackdelar

• Ingen tillståndsstyrning
• Ingen avancerade funktioner som Event time processing, aggregering, fönsterindelning, sessioner, vattenstämplar etc
• Atleast-once-garanti

Spark Streaming :

Spark har visat sig vara en sann efterföljare till Hadoop när det gäller batchbehandling och det första ramverket som fullt ut stöder Lambda-arkitekturen (där både Batch och Streaming implementeras; Batch för korrekthet, Streaming för snabbhet). Det är oerhört populärt, moget och allmänt antaget. Spark Streaming ingår gratis i Spark och använder micro batching för streaming. Före version 2.0 hade Spark Streaming allvarliga prestandabegränsningar, men med den nya versionen 2.0+ kallas den strukturerad streaming och är utrustad med många bra funktioner, t.ex. anpassad minneshantering (som flink) som kallas tungsten, vattenmärken, stöd för händelsetidsbearbetning osv. Structured Streaming är också mycket mer abstrakt och det finns möjlighet att växla mellan micro-batching och kontinuerlig strömning i version 2.3.0. Läget Continuous Streaming lovar att ge en lägre latenstid än Storm och Flink, men det är fortfarande i sin linda med många begränsningar i verksamheten.

Fördelar:

• Stöder Lambda-arkitektur, levereras gratis med Spark
• Hög genomströmning, Bra för många användningsfall där sublatens inte krävs
• Felttolerans som standard på grund av mikrobatchnatur
• Enkla att använda API:er på högre nivå
• Stort samhälle och aggressiva förbättringar
• Exakt en gång

Objektiva nackdelar

• Inte äkta streaming, inte lämplig för krav på låg latenstid
• För många parametrar att ställa in. Svårt att få det rätt. Har skrivit ett inlägg om min personliga erfarenhet när jag justerade Spark Streaming
• Stateless by nature
• Lags behind Flink in many advanced features

Flink :

Flink är också från liknande akademisk bakgrund som Spark. Medan Spark kommer från UC Berkley, kommer Flink från Berlins TU-universitet. Liksom Spark stöder det också Lambda-arkitektur. Men genomförandet är helt motsatt till Spark. Medan Spark i huvudsak är en batch med Spark streaming som micro-batching och ett specialfall av Spark Batch, är Flink i huvudsak en riktig streamingmotor som behandlar batch som ett specialfall av streaming med avgränsade data. Även om API:erna i de båda ramverken är likartade har de inga likheter i implementeringarna. I Flink implementeras varje funktion som map, filter, reduce etc. som en operatör med lång löptid (liknande Bolt i Storm)

Flink ser ut att vara en sann efterföljare till Storm som Spark efterträdde Hadoop inom batch.

Fördelar:

• Ledare av innovation i open source Streaming-landskapet
• Första riktiga streamingramverk med alla avancerade funktioner som händelsetidsbehandling, vattenmärken etc
• Låg latenstid med hög genomströmning, Konfigurerbar enligt krav
• Automatisk justering, inte för många parametrar att ställa in
• Exakt en gång
• Fått allmänt accepterat av stora företag i skala som Uber,Alibaba.

Nackdelar

• Lite sent i spelet, det fanns brist på adoption initialt
• Gemenskapen är inte lika stor som Spark men växer i snabb takt nu
• Ingen känd adoption av Flink Batch i dagsläget, endast populär för streaming.

Kafka Streams :

Kafka Streams är till skillnad från andra streamingramverk ett lättviktsbibliotek. Det är användbart för att strömma data från Kafka , göra transformationer och sedan skicka tillbaka till kafka. Vi kan förstå det som ett bibliotek som liknar Java Executor Service Thread pool, men med inbyggt stöd för Kafka. Det kan integreras väl med alla program och kommer att fungera direkt.

På grund av sin lätta vikt kan det användas i arkitekturer av typen microservices. Det finns ingen motsvarighet när det gäller prestanda med Flink men behöver inte heller separat kluster för att köras, är mycket praktisk och lätt att distribuera och börja arbeta . Internt använder Kafka Consumer group och arbetar med Kafka-loggfilosofin.
Detta inlägg förklarar grundligt användningsområdena för Kafka Streams vs Flink Streaming.

En stor fördel med Kafka Streams är att bearbetningen sker exakt en gång från början till slut. Det är möjligt eftersom både källan och destinationen är Kafka och från Kafka 0.11-versionen som släpptes runt juni 2017 stöds Exactly Once. För att aktivera den här funktionen behöver vi bara aktivera en flagga och det kommer att fungera direkt. För mer information delas här och här.

Fördelar:

• Very light weight library, good for microservices,IOT applications
• Does not need dedicated cluster
• Inherits all Kafka good characteristics
• Supports Stream joins, internally uses rocksDb for maintaining state.
• Exactly Once ( Kafka 0.11 och framåt).

Nackdelar

• Tätt sammankopplat med Kafka, kan inte användas utan Kafka i bilden
• Ganska nytt i ett tidigt skede, har ännu inte testats i stora företag
• Inte för tungt arbete som Spark Streaming,Flink.

Samza :

Samza kommer att behandlas kortfattat. Samza från 100 fot ser ut att likna Kafka Streams när det gäller tillvägagångssättet. Det finns många likheter. Båda dessa ramverk har utvecklats av samma utvecklare som implementerade Samza på LinkedIn och sedan grundade Confluent där de skrev Kafka Streams. Båda dessa tekniker är tätt kopplade till Kafka, tar rådata från Kafka och lägger sedan tillbaka bearbetade data tillbaka till Kafka. Använd samma Kafka Log-filosofi. Samza är en slags skalad version av Kafka Streams. Medan Kafka Streams är ett bibliotek avsett för mikrotjänster är Samza en fullfjädrad klusterbehandling som körs på Yarn.
Fördelar :

• Väldigt bra när det gäller att upprätthålla stora informationsmängder (bra för användningsfallet att sammanföra strömmar) med hjälp av rocksDb och kafka log.
• Felttolerant och högpresterande med hjälp av Kafka-egenskaper
• Ett av alternativen att överväga om man redan använder Yarn och Kafka i behandlingspipelinen.
• God Yarn-medborgare
• Låg latenstid , Hög genomströmning , mogen och testad i skala

Nackdelar :

• Tätt kopplad till Kafka och Yarn. Inte lätt att använda om någon av dessa inte finns i din behandlingspipeline.
• Atleast-Once processing guarantee. Jag är inte säker på om den stöder exakt en gång nu som Kafka Streams efter Kafka 0.11
• Missbruk av avancerade strömmingsfunktioner som vattenmärken, sessioner, triggers etc

Genomgång av ramverk för strömmning:

Vi kan jämföra tekniker endast med liknande erbjudanden. Storm, Kafka Streams och Samza ser nu användbara ut för enklare användningsfall, men den verkliga konkurrensen är tydlig mellan tungviktarna med de senaste funktionerna: Spark vs Flink

När vi pratar om jämförelser brukar vi i allmänhet fråga: Visa mig siffrorna 🙂

Benchmarking är ett bra sätt att jämföra, men bara när det har gjorts av tredje part.

En av de gamla benchmarkingmetoderna var till exempel följande.
Men detta var före Spark Streaming 2.0 när det fanns begränsningar med RDDs och projekt Tungsten inte fanns på plats.
Nu med Structured Streaming efter 2.0 försöker Spark Streaming komma ikapp en hel del och det verkar som om det kommer att bli en tuff kamp framöver.

Nyligen har benchmarking blivit ett slags öppen kattmatch mellan Spark och Flink.

Spark hade nyligen gjort en benchmarkingjämförelse med Flink, varpå Flink-utvecklarna svarade med en annan benchmarking, varefter Spark-killarna redigerade inlägget.

Det är bättre att inte tro på benchmarking nuförtiden, eftersom även en liten justering kan förändra siffrorna helt och hållet. Ingenting är bättre än att prova och testa oss själva innan vi bestämmer oss.
I dag är det ganska uppenbart att Flink leder Streaming Analytics-området, med de flesta av de önskade aspekterna som exakt en gång, genomströmning, latens, tillståndshantering, feltolerans, avancerade funktioner etc.

Dessa har varit möjliga tack vare några av de verkliga innovationerna i Flink, som lättviktade ögonblicksbilder och anpassad minneshantering utanför heap.
Ett viktigt problem med Flink var mognads- och adoptionsnivån fram till för en tid sedan, men nu använder företag som Uber, Alibaba och CapitalOne Flink streaming i stor skala, vilket bekräftar potentialen hos Flink Streaming.

För en kort tid sedan öppnade Uber upp sitt senaste ramverk för streaminganalys, AthenaX, som är byggt ovanpå Flink-motorn. I det här inlägget har de diskuterat hur de flyttade sin streaminganalys från STorm till Apache Samza och nu Flink.

En viktig punkt att notera, om du redan har lagt märke till det, är att alla inhemska streamingramverk som Flink, Kafka Streams, Samza som har stöd för tillståndshantering använder RocksDb internt. RocksDb är unik på så sätt att den upprätthåller ett beständigt tillstånd lokalt på varje nod och har hög prestanda. Det har blivit en viktig del av nya streamingsystem. Jag har delat detaljerad information om RocksDb i ett av de tidigare inläggen.

Hur man väljer det bästa streamingramverket :

Detta är den viktigaste delen. Och det ärliga svaret är: det beror på 🙂
Det är viktigt att komma ihåg att inget enskilt behandlingsramverk kan vara silver bullet för alla användningsfall. Varje ramverk har vissa styrkor och vissa begränsningar också. Med viss erfarenhet kommer jag ändå att dela med mig av några tips som kan hjälpa till att fatta beslut:

1. Avgörs av användningsfallen:
   Om användningsfallet är enkelt finns det ingen anledning att välja det senaste och bästa ramverket om det är komplicerat att lära sig och genomföra. Mycket beror på hur mycket vi är villiga att investera för hur mycket vi vill ha tillbaka. Om det till exempel är ett enkelt IOT-typiskt händelsebaserat varningssystem är Storm eller Kafka Streams helt okej att arbeta med.
2. Framtida överväganden:
   Till samma tid måste vi också ha ett medvetet övervägande om vilka framtida användningsområden som är tänkbara. Är det möjligt att det i framtiden kommer att ställas krav på avancerade funktioner som händelsetidsbearbetning, aggregering, stream joins osv. Om svaret är ja eller kanske ja, är det bättre att gå vidare med avancerade streamingramverk som Spark Streaming eller Flink. När man väl har investerat och implementerat en teknik är det svårt och kostar mycket att ändra den senare. I ett tidigare företag hade vi till exempel en Storm-pipeline i drift sedan två år tillbaka och den fungerade utmärkt tills vi fick ett krav på att unika inkommande händelser och endast rapportera unika händelser. Nu krävde detta tillståndshantering som inte stöds av Storm. Även om jag implementerade med hjälp av tidsbaserad in-memory hashmap men det var med begränsning att tillståndet kommer att försvinna vid omstart . Dessutom gav det problem under sådana ändringar som jag har delat med mig av i ett av de tidigare inläggen. Det jag försöker säga är att om vi försöker implementera något på egen hand som ramverket inte uttryckligen tillhandahåller, kommer vi att stöta på okända problem.
3. Existerande teknisk stapel :
   En annan viktig punkt är att ta hänsyn till den befintliga tekniska stapeln. Om den befintliga stacken har Kafka på plats från början till slut, kan Kafka Streams eller Samza vara lättare att anpassa. På samma sätt, om bearbetningsledningen är baserad på Lambda-arkitektur och Spark Batch eller Flink Batch redan finns på plats, är det vettigt att överväga Spark Streaming eller Flink Streaming. I ett av mina tidigare projekt hade jag till exempel redan Spark Batch i pipeline, så när streamingkravet kom var det ganska enkelt att välja Spark Streaming som krävde nästan samma färdigheter och kodbas.

Kort sagt, om vi förstår styrkorna och begränsningarna hos ramverken tillsammans med våra användningsfall är det lättare att välja eller åtminstone filtrera ner de tillgängliga alternativen. Slutligen är det alltid bra att ha POCs när ett par alternativ har valts. Alla har trots allt olika smaklökar.

Slutsats :

Apache Streaming space utvecklas så snabbt att det här inlägget kan vara inaktuellt när det gäller information om några år. För närvarande är Spark och Flink de tungviktare som leder utvecklingen, men någon ny unge kan fortfarande komma och delta i loppet. Apache Apex är en av dem. Det finns också egna strömningslösningar som jag inte har behandlat, t.ex. Google Dataflow. Mitt mål med det här inlägget var att hjälpa någon som är nybörjare inom streaming att förstå, med ett minimum av jargong, några centrala begrepp inom streaming tillsammans med styrkor, begränsningar och användningsområden för populära ramverk för streaming med öppen källkod. Hoppas inlägget var till hjälp på något sätt.

Happy Streaming!!

Du kan följa mig på Linkedin och Quora