Ifølge en nylig rapport fra IBM Marketing cloud er “90 procent af dataene i verden i dag blevet skabt i de sidste to år alene, hvilket har skabt 2.5 quintillion bytes data hver dag – og med nye enheder, sensorer og teknologier, der dukker op, vil datavækstraten sandsynligvis accelerere endnu mere”.
Teknisk set betyder det, at vores verden med Big Data Processing bliver mere kompleks og mere udfordrende. Og mange anvendelsestilfælde (f.eks. mobilapp-annoncer, svindeldetektion, taxabestilling, patientovervågning osv.) har brug for databehandling i realtid, efterhånden som dataene ankommer, for at kunne træffe hurtige beslutninger, der kan bruges til handling. Det er derfor, at Distributed Stream Processing er blevet meget populært i Big Data-verdenen.

I dag er der en række open source-streamingframeworks til rådighed. Interessant nok er næsten alle af dem ret nye og er kun blevet udviklet i de sidste par år. Så det er ret nemt for en ny person at blive forvirret i forståelsen af og differentiere mellem streamingrammer. I dette indlæg vil jeg først tale om typer og aspekter af Stream Processing generelt og derefter sammenligne de mest populære open source Streaming frameworks : Flink, Spark Streaming, Storm, Kafka Streams. Jeg vil forsøge at forklare, hvordan de fungerer (kort), deres brugssituationer, styrker, begrænsninger, ligheder og forskelle.

Hvad er Streaming/Stream Processing :
Den mest elegante definition, jeg fandt, er : en type databehandlingsmotor, der er designet med uendelige datasæt i tankerne. Intet andet.

I modsætning til Batch processing, hvor data er afgrænset med en start og en slutning i et job, og jobbet afsluttes efter behandling af disse begrænsede data, er Streaming beregnet til behandling af ubegrænsede data, der kommer i realtid kontinuerligt i dage, måneder, år og for evigt. Da en streaming-applikation altid er beregnet til at være oppe og køre, er den vanskelig at implementere og sværere at vedligeholde.

Vigtige aspekter af Stream Processing:

Der er nogle vigtige karakteristika og termer forbundet med Stream processing, som vi bør være opmærksomme på for at forstå styrker og begrænsninger ved enhver Streaming-ramme :

• Leveringsgarantier :
  Det betyder, hvad der er garantien for, at uanset hvad, vil en bestemt indgående post i en streaming-motor blive behandlet. Det kan være enten Atleast-once (vil blive behandlet mindst én gang, selv i tilfælde af fejl) , Atmost-once (må ikke blive behandlet i tilfælde af fejl) eller Exactly-once (vil blive behandlet én og præcis én gang, selv i tilfælde af fejl) . Det er klart, at Exactly-once er ønskeligt, men det er svært at opnå i distribuerede systemer, og der skal indgås kompromiser med ydeevnen.
• Fejltolerance:
  I tilfælde af fejl som f.eks. knudefejl, netværksfejl osv. skal rammen kunne genoprette sig selv og starte behandlingen igen fra det punkt, hvor den forlod den. Dette opnås gennem checkpointing af tilstanden af streaming til nogle vedvarende lagerplads fra tid til anden. f.eks. checkpointing kafka offsets til zookeeper efter at have fået record fra Kafka og behandle det.
• State Management :
  I tilfælde af stateful behandlingskrav, hvor vi har brug for at opretholde nogle tilstand (e.f.eks. tæller af hvert særskilt ord, der ses i poster), bør rammen være i stand til at levere en mekanisme til at bevare og opdatere tilstandsoplysninger.
• Ydeevne :
  Dette omfatter latenstid (hvor hurtigt en post kan behandles), gennemløb (poster behandlet/sekund) og skalerbarhed. Latency bør være så lille som muligt, mens throughput bør være så stor som muligt. Det er svært at få begge dele på samme tid.
• Avancerede funktioner : Event Time Processing, Watermarks, Windowing
  Dette er funktioner, der er nødvendige, hvis kravene til stream processing er komplekse. For eksempel behandling af poster baseret på det tidspunkt, hvor de blev genereret ved kilden (event time processing). Hvis du vil vide mere i detaljer, kan du læse disse must-read indlæg af Google-fyren Tyler Akidau : part1 og part2.
• Maturitet :
  Vigtigt fra adoptionssynspunktet, det er rart, hvis rammen allerede er afprøvet og kampafprøvet i skala af store virksomheder. Større sandsynlighed for at få god community support og hjælp på stackoverflow.

To typer af Stream Processing:

Nu er man klar over de termer vi lige har diskuteret, er det nu let at forstå at der er 2 tilgange til at implementere et Streaming framework:

Native Streaming :
Også kendt som Native Streaming. Det betyder, at hver indgående post behandles, så snart den ankommer, uden at vente på andre. Der er nogle kontinuerligt kørende processer (som vi kalder operatører/opgaver/bolte afhængigt af rammen), som kører for evigt, og hver post passerer gennem disse processer for at blive behandlet. Eksempler : Storm, Flink, Kafka Streams, Samza.

Micro-batching :
Også kendt som Fast Batching. Det betyder, at indgående poster med få sekunders mellemrum samles i en batch og derefter behandles i en enkelt minibatch med en forsinkelse på få sekunder. Eksempler: Spark Streaming, Storm-Trident.

Både tilgange har nogle fordele og ulemper.
Native Streaming føles naturligt, da hver record behandles, så snart den ankommer, hvilket giver rammen mulighed for at opnå den mindst mulige latenstid. Men det betyder også, at det er svært at opnå fejltolerance uden at gå på kompromis med gennemstrømningen, da vi for hver record skal spore og checkpointe, når den er behandlet. Det er også let at administrere tilstanden, da der er processer, der kører længe, og som nemt kan opretholde den nødvendige tilstand.

Micro-batching , på den anden side, er det stik modsatte. Fejltolerance er gratis, da det i bund og grund er en batch, og gennemstrømningen er også høj, da behandling og checkpointing sker i ét skud for en gruppe af poster. Men det vil være på bekostning af latenstid, og det vil ikke føles som en naturlig streaming. Også effektiv tilstandshåndtering vil være en udfordring at vedligeholde.

Streaming Frameworks en efter en:

Storm :
Storm er hadoop i Streaming-verdenen. Det er det ældste open source streaming framework og et af de mest modne og pålidelige. Det er ægte streaming og er godt til enkle begivenhedsbaserede brugssager. Jeg har delt detaljer om Storm udførligt i disse indlæg: part1 og part2.

Vanskeligheder:

• Meget lav latenstid, ægte streaming, moden og høj gennemstrømning
• Udmærket til ukomplicerede streaming-brugstilfælde

Ulemper

• Ingen tilstandsstyring
• Ingen avancerede funktioner som Event time processing, aggregering, vinduesinddeling, sessioner, vandmærker osv
• Atleast-once-garanti

Spark Streaming :

Spark har vist sig at være den sande efterfølger til hadoop inden for batchbehandling og den første ramme, der fuldt ud understøtter Lambda-arkitekturen (hvor både Batch og Streaming er implementeret; Batch for korrekthed, Streaming for hastighed). Det er uhyre populært, modnet og bredt vedtaget. Spark Streaming følger gratis med Spark og anvender micro batching til streaming. Før udgivelsen af version 2.0 havde Spark Streaming nogle alvorlige begrænsninger i ydeevnen, men med den nye version 2.0+ kaldes det struktureret streaming og er udstyret med mange gode funktioner som f.eks. brugerdefineret hukommelsesstyring (som flink) kaldet tungsten, vandmærker, understøttelse af event time processing osv. Structured Streaming er også meget mere abstrakt, og der er mulighed for at skifte mellem mikro-batching og kontinuerlig streamingtilstand i 2.3.0-versionen. Continuous Streaming-tilstand lover at give sub latency ligesom Storm og Flink, men den er stadig i sin vorden med mange begrænsninger i operationer.

Advantages:

• Understøtter Lambda-arkitektur, leveres gratis med Spark
• Højt gennemløb, god til mange anvendelsestilfælde, hvor sub-latency ikke er påkrævet
• Fejletolerance som standard på grund af micro-batch natur
• Enkel at bruge API’er på højere niveau
• Stort fællesskab og aggressive forbedringer
• Exactly Once

Ulemper

• Ikke ægte streaming, ikke egnet til krav om lav latenstid
• For mange parametre, der skal indstilles. Svært at få det rigtigt. Har skrevet et indlæg om min personlige erfaring under tuning af Spark Streaming
• Stateless by nature
• Lags bagud i forhold til Flink i mange avancerede funktioner

Flink :

Flink er også fra lignende akademisk baggrund som Spark. Mens Spark kom fra UC Berkley, kom Flink fra Berlins TU-universitet. Ligesom Spark understøtter den også Lambda-arkitektur. Men implementeringen er helt modsat Spark’s. Mens Spark hovedsagelig er en batch med Spark streaming som mikro-batching og et specialtilfælde af Spark Batch, er Flink hovedsagelig en ægte streamingmotor, der behandler batch som et specialtilfælde af streaming med afgrænsede data. Selv om API’erne i begge rammeværker ligner hinanden, har de ikke nogen lighed i implementeringerne. I Flink er hver funktion som map,filter,reduce,osv. implementeret som en lang kørende operatør (svarende til Bolt i Storm)

Flink ligner en ægte efterfølger til Storm ligesom Spark efterfulgte Hadoop i batch.

Advantages:

• Leder af innovation i open source Streaming-landskabet
• Første ægte streaming-ramme med alle avancerede funktioner som event time processing, vandmærker osv
• Lav latency med høj gennemstrømning, konfigurerbar i henhold til kravene
• Auto-justering, ikke for mange parametre at indstille
• Exactly Once
• Fået bred accept af store virksomheder i skala som Uber,Alibaba.

Ulemper

• Lidt sent i spillet, der var mangel på adoption i starten
• Fællesskabet er ikke så stort som Spark, men vokser i hurtigt tempo nu
• Ingen kendt adoption af Flink Batch indtil videre, kun populær til streaming.

Kafka Streams :

Kafka Streams , i modsætning til andre streamingframeworks, er et letvægtsbibliotek. Det er nyttigt til at streame data fra Kafka , foretage transformation og derefter sende tilbage til Kafka. Vi kan forstå det som et bibliotek svarende til Java Executor Service Thread pool, men med indbygget understøttelse for Kafka. Det kan integreres godt med enhver applikation og vil fungere ud af boksen.

På grund af sin letvægtsnatur kan det bruges i en arkitektur af microservices-typen. Der er ingen match med hensyn til ydeevne med Flink, men har heller ikke brug for separat klynge til at køre, er meget praktisk og let at implementere og begynde at arbejde . Intern bruger Kafka Consumer group og arbejder på Kafka-logfilosofien.
Dette indlæg forklarer grundigt anvendelsestilfælde af Kafka Streams vs Flink Streaming.

En stor fordel ved Kafka Streams er, at dens behandling er Exactly Once end to end. Det er muligt, fordi kilden såvel som destinationen, begge er Kafka og fra Kafka 0.11 version udgivet omkring juni 2017, Exactly once er understøttet. For at aktivere denne funktion skal vi blot aktivere et flag, og det vil fungere ud af boksen. For flere detaljer delt her og her.

Fordele:

• 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 og frem).

Ulemper

• Tæt koblet med Kafka, kan ikke bruges uden Kafka i billedet
• Helt nyt i spædbarnsstadiet, endnu ikke testet i store virksomheder
• Ikke til tungt løftearbejde som Spark Streaming,Flink.

Samza :

Vil dække Samza i korte træk. Samza fra 100 fod ligner Kafka Streams i tilgang. Der er mange ligheder. Begge disse frameworks er udviklet af de samme udviklere, som implementerede Samza hos LinkedIn og derefter grundlagde Confluent, hvor de skrev Kafka Streams. Begge disse teknologier er tæt koblet til Kafka, tager rå data fra Kafka og lægger derefter forarbejdede data tilbage til Kafka. Brug den samme Kafka Log-filosofi. Samza er en slags skaleret version af Kafka Streams. Mens Kafka Streams er et bibliotek beregnet til microservices , er Samza fuldgyldig klyngebehandling, der kører på Yarn.
Fordele :

• Meget god til at vedligeholde store tilstande af information (god til use case af joining streams) ved hjælp af rocksDb og kafka log.
• Fejletolerant og højtydende ved hjælp af Kafka-egenskaber
• En af de muligheder, der skal overvejes, hvis du allerede bruger Yarn og Kafka i behandlingspipelinen.
• God Yarn-borger
• Lav latenstid , Høj gennemstrømning , moden og testet på skala

Ulemper :

• Tæt koblet med Kafka og Yarn. Ikke let at bruge, hvis nogen af disse ikke er i din behandlingspipeline.
• Atleast-Once behandlingsgaranti. Jeg er ikke sikker på, om den understøtter præcis én gang nu ligesom Kafka Streams efter Kafka 0.11
• Mangel på avancerede streaming-funktioner som vandmærker, sessioner, triggers osv

Sammenligning af Streaming Frameworks:

Vi kan kun sammenligne teknologier med lignende tilbud. Mens Storm, Kafka Streams og Samza nu ser nyttige ud til enklere anvendelsestilfælde, er den virkelige konkurrence klar mellem sværvægterne med de nyeste funktioner: Spark vs Flink

Når vi taler om sammenligning, har vi generelt en tendens til at spørge: Vis mig tallene 🙂

Benchmarking er kun en god måde at sammenligne på, når det er blevet udført af tredjeparter.

For eksempel var en af de gamle benchmarkingmetoder denne.
Men det var på tidspunkter før Spark Streaming 2.0, da det havde begrænsninger med RDDs og project tungsten ikke var på plads.
Nu med Structured Streaming efter 2.0 release , forsøger Spark Streaming at indhente meget, og det ser ud til at der kommer til at være hård kamp forude.

Nu er benchmarking ligesom blevet en åben kattekamp mellem Spark og Flink.

Spark havde for nylig lavet benchmarking sammenligning med Flink, hvortil Flink-udviklerne svarede med en anden benchmarking, hvorefter Spark-fyrene redigerede indlægget.

Det er bedre ikke at tro på benchmarking i disse dage, fordi selv en lille tweaking kan ændre tallene fuldstændigt. Intet er bedre end at prøve og teste os selv, før vi beslutter os.
I dag er det helt tydeligt, at Flink er førende inden for Streaming Analytics med de fleste af de ønskede aspekter som f.eks. præcis én gang, gennemløb, latenstid, tilstandshåndtering, fejltolerance, avancerede funktioner osv.

Dette har været muligt på grund af nogle af de sande innovationer i Flink som f.eks. letvægtede snapshots og brugerdefineret hukommelseshåndtering uden for heap.
En vigtig bekymring med Flink var modenhed og adoptionsniveau indtil for nogen tid siden, men nu bruger virksomheder som Uber, Alibaba, CapitalOne Flink streaming i stor skala, hvilket bekræfter potentialet i Flink Streaming.

For nylig åbnede Uber deres seneste Streaming analytics framework kaldet AthenaX, som er bygget på toppen af Flink-motoren. I dette indlæg har de diskuteret, hvordan de flyttede deres streaminganalyser fra STorm til Apache Samza til nu Flink.

Et vigtigt punkt at bemærke, hvis du allerede har bemærket det, er, at alle native streamingframeworks som Flink, Kafka Streams, Samza, der understøtter tilstandsstyring, bruger RocksDb internt. RocksDb er unik i den forstand, at den opretholder vedvarende tilstand lokalt på hver knude og er meget performant. Det er blevet en afgørende del af nye streamingsystemer. Jeg har delt detaljeret info om RocksDb i et af de tidligere indlæg.

Hvordan man vælger den bedste streaming-ramme :

Dette er den vigtigste del. Og det ærlige svar er: det afhænger 🙂
Det er vigtigt at huske på, at ingen enkelt behandlingsramme kan være silver bullet for alle brugssager. Hver ramme har nogle styrker og også nogle begrænsninger. Alligevel , med nogle erfaringer, vil dele nogle få pointer til at hjælpe med at tage beslutninger:

1. 1. Afhænger af de brugssager:
      Hvis brugssagen er enkel, er der ingen grund til at gå efter den nyeste og bedste ramme, hvis det er kompliceret at lære og implementere. Meget afhænger af, hvor meget vi er villige til at investere for hvor meget vi vil have til gengæld. Hvis det f.eks. er et simpelt IOT-agtigt, begivenhedsbaseret varslingssystem, er Storm eller Kafka Streams helt fint at arbejde med.
   2. Fremtidige overvejelser:
      Samtidig er vi også nødt til at have en bevidst overvejelse over, hvad der vil være de mulige fremtidige anvendelsestilfælde? Er det muligt, at der kan komme krav om avancerede funktioner som event time processing,aggregation, stream joins osv. i fremtiden ? Hvis svaret er ja eller kan være, så er det bedre at gå videre med avancerede streamingframeworks som Spark Streaming eller Flink. Når først investeret og implementeret i en teknologi, er det svært og meget dyrt at ændre senere. For eksempel, I tidligere virksomhed havde vi en Storm pipeline oppe og køre fra sidste 2 år, og det fungerede helt fint indtil et krav kom til at uniquifying indgående begivenheder og kun rapportere unikke begivenheder. Nu krævede dette state management, som ikke i sagens natur er understøttet af Storm. Selv om jeg implementeret ved hjælp af tid baseret in-memory hashmap, men det var med begrænsning, at staten vil gå væk på genstart . Også, det gav problemer under sådanne ændringer, som jeg har delt i et af de tidligere indlæg. Den pointe, jeg forsøger at gøre, er, at hvis vi forsøger at implementere noget på egen hånd, som rammen ikke udtrykkeligt giver, er vi bundet til at ramme ukendte problemer.
   3. Existing Tech Stack :
      Et andet vigtigt punkt er at overveje den eksisterende tech stack. Hvis den eksisterende stak har Kafka på plads fra ende til anden, vil Kafka Streams eller Samza måske være lettere at tilpasse. På samme måde, hvis behandlingspipelinen er baseret på Lambda-arkitektur, og Spark Batch eller Flink Batch allerede er på plads, giver det mening at overveje Spark Streaming eller Flink Streaming. For eksempel havde jeg i et af mine tidligere projekter allerede Spark Batch i pipeline, så da streamingkravet kom, var det ret nemt at vælge Spark Streaming, som krævede næsten samme færdighedssæt og kodebase.

   Kort sagt, hvis vi forstår styrkerne og begrænsningerne ved rammerne sammen med vores brugssager godt, så er det lettere at vælge eller i det mindste filtrere ned de tilgængelige muligheder. Endelig er det altid godt at have POC’er, når et par muligheder er blevet valgt. Alle har trods alt forskellige smagsløg.

   Konklusion :

   Apache Streaming-området udvikler sig så hurtigt, at dette indlæg kan være forældet med hensyn til oplysninger om et par år. I øjeblikket er Spark og Flink de tunge vægtere, der fører fra fronten med hensyn til udvikling, men nogle nye børn kan stadig komme og deltage i løbet. Apache Apex er en af dem. Der er også proprietære streamingløsninger, som jeg ikke har dækket som Google Dataflow. Mit mål med dette indlæg var at hjælpe nogen, der er ny inden for streaming, med at forstå, med et minimum af jargon, nogle centrale begreber inden for streaming sammen med styrker, begrænsninger og anvendelsestilfælde af populære open source streamingframeworks. Håber at indlægget var nyttigt på en eller anden måde.

   Happy Streaming!!

   Du kan følge mig på Linkedin og Quora