Potrivit unui raport recent al IBM Marketing cloud, „90% din datele din lumea de astăzi au fost create numai în ultimii doi ani, creând 2.5 quintilioane de octeți de date în fiecare zi – iar odată cu apariția de noi dispozitive, senzori și tehnologii, rata de creștere a datelor va accelera probabil și mai mult”.
Din punct de vedere tehnic, acest lucru înseamnă că lumea noastră de procesare Big Data va fi mai complexă și mai provocatoare. Și o mulțime de cazuri de utilizare (de exemplu, reclamele din aplicațiile mobile, detectarea fraudelor, rezervarea de taxiuri, monitorizarea pacienților,etc.) au nevoie de procesarea datelor în timp real, pe măsură ce sosesc datele, pentru a lua decizii rapide și acționabile. Acesta este motivul pentru care procesarea distribuită a fluxurilor a devenit foarte populară în lumea Big Data.

Astăzi există o serie de cadre de streaming open source disponibile. Interesant este faptul că aproape toate sunt destul de noi și au fost dezvoltate doar în ultimii câțiva ani. Prin urmare, este destul de ușor pentru o persoană nouă să se încurce în înțelegerea și diferențierea între cadrele de streaming. În această postare voi vorbi mai întâi despre tipurile și aspectele procesării fluxurilor în general și apoi voi compara cele mai populare cadre de streaming open source: Flink, Spark Streaming, Storm, Kafka Streams. Voi încerca să explic cum funcționează (pe scurt), cazurile lor de utilizare, punctele forte, limitările, asemănările și diferențele.

Ce este Streaming/Stream Processing :
Cea mai elegantă definiție pe care am găsit-o este : un tip de motor de procesare a datelor care este proiectat având în vedere seturi infinite de date. Nimic mai mult.

Dincolo de procesarea pe loturi, unde datele sunt delimitate cu un început și un sfârșit într-un job și jobul se termină după procesarea acelor date finite, Streaming-ul este menit să proceseze date nelimitate care vin în timp real în mod continuu timp de zile, luni, ani și pentru totdeauna. Ca atare, fiind menită să fie mereu în funcțiune, o aplicație de streaming este greu de implementat și mai greu de întreținut.

Aspecte importante ale procesării în flux:

Există câteva caracteristici și termeni importanți asociați cu procesarea în flux pe care ar trebui să îi cunoaștem pentru a înțelege punctele forte și limitările oricărui cadru de streaming :

• Garanții de livrare :
  Înseamnă care este garanția că, indiferent de situație, o anumită înregistrare care intră într-un motor de streaming va fi procesată. Aceasta poate fi fie Atleast-once (va fi procesată cel puțin o dată chiar și în cazul unor eșecuri) , Atmost-once (poate să nu fie procesată în cazul unor eșecuri) sau Exactly-once (va fi procesată o dată și exact o dată chiar și în cazul unor eșecuri) . Evident, Exactly-once este de dorit, dar este greu de realizat în sistemele distribuite și vine cu compromisuri în ceea ce privește performanța.
• Toleranță la defecțiuni :
  În cazul unor defecțiuni, cum ar fi defecțiuni ale nodurilor, defecțiuni ale rețelei etc., cadrul ar trebui să fie capabil să se recupereze și să înceapă din nou procesarea din punctul în care a rămas. Acest lucru se realizează prin verificarea din când în când a stării de streaming către o stocare persistentă. de exemplu, prin verificarea offseturilor kafka către zookeeper după obținerea înregistrărilor de la Kafka și procesarea lor.
• Managementul stării :
  În cazul cerințelor de procesare cu stare în care trebuie să menținem o anumită stare (de ex.g. numărătoarea fiecărui cuvânt distinct văzut în înregistrări), cadrul ar trebui să fie capabil să furnizeze un mecanism de păstrare și actualizare a informațiilor de stare.
• Performanță :
  Aceasta include latența (cât de repede poate fi procesată o înregistrare), debitul (înregistrări procesate/secundă) și scalabilitatea. Latența ar trebui să fie cât mai mică posibil, în timp ce debitul ar trebui să fie cât mai mare posibil. Este dificil să le obțineți pe amândouă în același timp.
• Caracteristici avansate : Event Time Processing, Watermarks, Windowing
  Acestea sunt caracteristici necesare dacă cerințele de procesare a fluxurilor sunt complexe. De exemplu, procesarea înregistrărilor în funcție de momentul în care au fost generate la sursă (procesare timp eveniment). Pentru a afla mai multe în detaliu, vă rugăm să citiți aceste postări pe care trebuie să le citiți neapărat de către Tyler Akidau, un tip de la Google : partea 1 și partea 2.
• Maturitate :
  Important din punct de vedere al adoptării, este bine dacă cadrul este deja dovedit și testat în luptă la scară largă de către companii mari. Este mai probabil să primească un sprijin bun din partea comunității și ajutor pe stackoverflow.

Două tipuri de procesare a fluxurilor:

Acum fiind conștienți de termenii pe care tocmai i-am discutat, este acum ușor de înțeles că există 2 abordări pentru a implementa un cadru de streaming:

Native Streaming :
Cunoscut și sub numele de Native Streaming. Aceasta înseamnă că fiecare înregistrare primită este procesată imediat ce sosește, fără a aștepta altele. Există câteva procese care rulează continuu (pe care le numim operatori/task-uri/bolțuri, în funcție de cadru) care rulează pentru totdeauna și fiecare înregistrare trece prin aceste procese pentru a fi procesată. Exemple : Storm, Flink, Kafka Streams, Samza.

Micro-batching :
Cunoscut și sub numele de Fast Batching. Înseamnă că înregistrările primite la fiecare câteva secunde sunt grupate împreună și apoi procesate într-un singur mini-lot cu o întârziere de câteva secunde. Exemple: Spark Streaming, Storm-Trident.

Ambele abordări au unele avantaje și dezavantaje.
Stringerea nativă pare naturală, deoarece fiecare înregistrare este procesată imediat ce sosește, permițând cadrului să obțină o latență minimă posibilă. Dar aceasta înseamnă, de asemenea, că este greu de realizat toleranța la erori fără a compromite randamentul, deoarece pentru fiecare înregistrare trebuie să urmărim și să verificăm punctul de control odată ce a fost procesată. De asemenea, gestionarea stării este ușoară, deoarece există procese care rulează de mult timp și care pot menține cu ușurință starea necesară.

Micro-batching , pe de altă parte, este cu totul opus. Toleranța la erori este gratuită, deoarece este în esență un lot, iar randamentul este, de asemenea, ridicat, deoarece procesarea și verificarea punctelor de control se vor face dintr-o singură lovitură pentru un grup de înregistrări. Dar acest lucru se va face cu un anumit cost de latență și nu se va simți ca un streaming natural. De asemenea, gestionarea eficientă a stării va fi o provocare pentru a fi menținută.

Streaming Frameworks One By One:

Storm :
Storm este Hadoop al lumii Streaming. Este cel mai vechi cadru de streaming open source și unul dintre cele mai mature și mai fiabile. Este un adevărat streaming și este bun pentru cazuri de utilizare bazate pe evenimente simple. Am împărtășit detalii despre Storm pe larg în aceste postări: partea1 și partea2.

Avantaje:

• Latență foarte scăzută, streaming adevărat, matur și debit ridicat
• Excelent pentru cazuri de utilizare a streamingului necomplicat

Dezavantaje

• Nu există gestionare a stării
• Nu există caracteristici avansate precum procesarea timpului de eveniment, agregare, windowing, sesiuni, filigrane, etc
• Garanție „o singură dată”

Spark Streaming :

Spark a apărut ca fiind adevăratul succesor al lui hadoop în ceea ce privește procesarea pe loturi și primul cadru care susține pe deplin arhitectura Lambda (în care sunt implementate atât Batch cât și Streaming; Batch pentru corectitudine, Streaming pentru viteză). Este extrem de popular, maturizat și adoptat pe scară largă. Spark Streaming este oferit gratuit împreună cu Spark și utilizează micro batching pentru streaming. Înainte de lansarea versiunii 2.0, Spark Streaming avea unele limitări serioase de performanță, dar cu noua versiune 2.0+ , se numește streaming structurat și este echipat cu multe caracteristici bune, cum ar fi gestionarea personalizată a memoriei (ca Flink) numită tungsten, filigrane, suport pentru procesarea timpului de eveniment etc. De asemenea, Structured Streaming este mult mai abstract și există opțiunea de a comuta între modul micro-batching și streaming continuu în versiunea 2.3.0. Modul Continuous Streaming promite să ofere sub latență ca Storm și Flink, dar este încă în stadiu incipient, cu multe limitări în operațiuni.

Avantaje:

• Suportă arhitectura Lambda, vine gratuit cu Spark
• Traseu ridicat, bun pentru multe cazuri de utilizare în care nu este necesară o sub-latență
• Toleranță la erori în mod implicit datorită naturii micro-batch
• Simplu de utilizat API-uri de nivel superior
• Comunitate mare și îmbunătățiri agresive
• Exactly Once

Dezavantaje

• Nu este un adevărat streaming, nu este potrivit pentru cerințele de latență scăzută
• Prea mulți parametri de reglat. Greu de făcut bine. Am scris o postare despre experiența mea personală în timpul reglării Spark Streaming
• Stateless by nature
• Lags behind Flink in many advanced features

Flink :

Flink provine, de asemenea, din medii academice similare cu Spark. În timp ce Spark provine de la UC Berkley, Flink provine de la Universitatea TU din Berlin. Ca și Spark, suportă, de asemenea, arhitectura Lambda. Dar implementarea este cu totul opusă celei din Spark. În timp ce Spark este, în esență, un batch cu Spark streaming ca micro-batching și un caz special de Spark Batch, Flink este, în esență, un adevărat motor de streaming care tratează batch-ul ca pe un caz special de streaming cu date delimitate. Deși API-urile din ambele cadre sunt similare, dar nu au nicio asemănare în ceea ce privește implementările. În Flink, fiecare funcție precum map,filter,reduce,etc. este implementată ca un operator de lungă durată (similar cu Bolt din Storm)

Flink pare a fi un adevărat succesor al lui Storm, așa cum Spark a succedat lui Hadoop în batch.

Avantaje:

• Liderul inovației în peisajul de streaming open source
• Primul cadru de streaming adevărat cu toate caracteristicile avansate, cum ar fi procesarea timpului de eveniment, filigranele, etc
• Letență redusă cu debit ridicat, configurabil în funcție de cerințe
• Auto-ajustare, nu sunt prea mulți parametri de reglat
• Exact o dată
• Căpătând o largă acceptare de către marile companii la scară precum Uber,Alibaba.

Dezavantaje

• Un pic mai târziu în joc, a existat o lipsă de adopție inițial
• Comunitatea nu este la fel de mare ca Spark, dar crește în ritm rapid acum
• Nici o adopție cunoscută a Flink Batch deocamdată, populară doar pentru streaming.

Kafka Streams :

Kafka Streams , spre deosebire de alte cadre de streaming, este o bibliotecă cu greutate redusă. Este utilă pentru streamingul de date de la Kafka , efectuând transformări și apoi trimițând înapoi la Kafka. O putem înțelege ca pe o bibliotecă similară cu Java Executor Service Thread pool, dar cu suport încorporat pentru Kafka. Poate fi integrată bine în orice aplicație și va funcționa din start.

Datorită naturii sale ușoare, poate fi utilizată în arhitectura de tip microservicii. Nu există nici un meci în ceea ce privește performanța cu Flink, dar, de asemenea, nu are nevoie de un cluster separat pentru a rula, este foarte la îndemână și ușor de implementat și de început să lucreze . La nivel intern, utilizează grupul Kafka Consumer și funcționează pe baza filozofiei de jurnal Kafka.
Acest post explică în detaliu cazurile de utilizare a Kafka Streams vs Flink Streaming.

Un avantaj major al Kafka Streams este că procesarea sa este Exact o dată de la un capăt la altul. Acest lucru este posibil deoarece atât sursa, cât și destinația, ambele sunt Kafka și de la versiunea Kafka 0.11 lansată în jurul lunii iunie 2017, Exactly once este suportat. Pentru a activa această caracteristică, trebuie doar să activăm un indicator și va funcționa din start. Pentru mai multe detalii împărtășite aici și aici.

Avantaje:

• Bibliotecă foarte ușoară, bună pentru microservicii, aplicații IOT
• Nu are nevoie de un cluster dedicat
• Impreună cu toate caracteristicile bune ale Kafka
• Suportă îmbinări Stream, utilizează intern rocksDb pentru menținerea stării.
• Exactly Once ( Kafka 0.11 onwards).

Dezavantaje

• Sunt strâns cuplate cu Kafka, nu se pot folosi fără Kafka în imagine
• Destul de nou, în stadiu incipient, încă nu a fost testat în marile companii
• Nu pentru lucrări grele precum Spark Streaming,Flink.

Samza :

Va acoperi Samza pe scurt. Samza de la 30 de metri pare similar cu Kafka Streams în abordare. Există multe asemănări. Ambele cadre au fost dezvoltate de aceiași dezvoltatori care au implementat Samza la LinkedIn și apoi au fondat Confluent, unde au scris Kafka Streams. Ambele tehnologii sunt strâns legate de Kafka, preiau date brute din Kafka și apoi redau datele procesate înapoi în Kafka. Utilizați aceeași filozofie Kafka Log. Samza este un fel de versiune la scară a Kafka Streams. În timp ce Kafka Streams este o bibliotecă destinată microserviciilor , Samza este un proces de cluster complet care rulează pe Yarn.
Vantaje :

• Mulțumesc foarte bine în menținerea unor stări mari de informații (bun pentru cazul de utilizare al unirii fluxurilor) folosind rocksDb și kafka log.
• Tolerant la erori și foarte performant folosind proprietățile Kafka
• Una dintre opțiunile de luat în considerare dacă se utilizează deja Yarn și Kafka în conducta de procesare.
• Bun cetățean Yarn
• Low latency , High throughput , matur și testat la scară

Dezavantaje :

• Totalmente cuplat cu Kafka și Yarn. Nu este ușor de utilizat dacă niciunul dintre acestea nu se află în pipeline-ul dvs. de procesare.
• Atleast-Once processing guarantee. Nu sunt sigur dacă suportă acum exact o dată ca și Kafka Streams după Kafka 0.11
• Lipsă de caracteristici avansate de streaming, cum ar fi Watermarks, Sessions, triggers, etc

Compararea cadrelor de streaming:

Potem compara tehnologiile doar cu oferte similare. În timp ce Storm, Kafka Streams și Samza par acum utile pentru cazuri de utilizare mai simple, adevărata competiție este clară între greii cu cele mai recente caracteristici: Spark vs Flink

Când vorbim despre comparație, avem în general tendința de a cere: Arată-mi cifrele 🙂

Benchmarking-ul este o modalitate bună de a compara doar atunci când a fost realizat de către terți.

De exemplu, unul dintre vechile benchmarking-uri a fost acesta.
Dar acest lucru se întâmpla înainte de Spark Streaming 2.0, când avea limitări cu RDD-urile și proiectul tungsten nu era în vigoare.
Acum, cu lansarea Structured Streaming post 2.0 , Spark Streaming încearcă să recupereze mult din urmă și se pare că va fi o luptă dură înainte.

Recent, benchmarking-ul a devenit un fel de luptă deschisă de pisici între Spark și Flink.

Spark a făcut recent o comparație de benchmarking cu Flink, la care dezvoltatorii Flink au răspuns cu un alt benchmarking, după care băieții de la Spark au editat postarea.

Este mai bine să nu credem în benchmarking în aceste zile, deoarece chiar și o mică modificare poate schimba complet cifrele. Nimic nu este mai bun decât să încercăm și să ne testăm singuri înainte de a decide.
În prezent, este destul de evident că Flink este lider în spațiul de analiză a fluxurilor, cu majoritatea aspectelor dorite, cum ar fi exact o dată, randament, latență, gestionare a stării, toleranță la erori, caracteristici avansate etc.

Acestea au fost posibile datorită unora dintre adevăratele inovații ale Flink, cum ar fi instantaneele cu greutate redusă și gestionarea memoriei personalizate off heap.
O preocupare importantă legată de Flink a fost maturitatea și nivelul de adoptare până acum ceva timp, dar acum companii precum Uber, Alibaba, CapitalOne folosesc Flink streaming la scară masivă, ceea ce certifică potențialul Flink Streaming.

Recent, Uber a deschis cel mai recent cadru de analiză Streaming numit AthenaX, care este construit pe motorul Flink. În această postare, ei au discutat despre modul în care și-au mutat analizele de streaming de la STorm la Apache Samza și acum la Flink.

Un punct important de reținut, dacă ați observat deja, este că toate cadrele native de streaming, cum ar fi Flink, Kafka Streams, Samza, care acceptă gestionarea stării, utilizează RocksDb în mod intern. RocksDb este unic în sensul că menține starea persistentă la nivel local pe fiecare nod și este foarte performant. Acesta a devenit o parte esențială a noilor sisteme de streaming. Am împărtășit informații detaliate despre RocksDb într-una dintre postările anterioare.

Cum să alegeți cel mai bun cadru de streaming :

Aceasta este cea mai importantă parte. Iar răspunsul sincer este: depinde 🙂
Este important să rețineți că niciun cadru de procesare nu poate fi un glonț de argint pentru fiecare caz de utilizare. Fiecare cadru are unele puncte forte și, de asemenea, unele limitări. Totuși , cu ceva experiență, va împărtăși câteva indicii pentru a ajuta la luarea deciziilor:

1. Depinde de cazurile de utilizare:
   Dacă cazul de utilizare este simplu, nu este nevoie să optați pentru cel mai nou și cel mai bun cadru dacă este complicat de învățat și implementat. Depinde foarte mult de cât de mult suntem dispuși să investim pentru cât de mult ne dorim în schimb. De exemplu, dacă este vorba de un simplu sistem de alertă bazat pe evenimente de tip IOT, Storm sau Kafka Streams este perfect pentru a lucra cu el.
2. Considerații viitoare:
   În același timp, trebuie, de asemenea, să avem o considerație conștientă cu privire la care vor fi posibilele cazuri de utilizare viitoare? Este posibil ca în viitor să apară cereri de caracteristici avansate, cum ar fi procesarea în timp a evenimentelor, agregare, îmbinări de fluxuri, etc.? Dacă răspunsul este „da” sau „s-ar putea”, atunci este mai bine să mergem mai departe cu cadre de streaming avansate, cum ar fi Spark Streaming sau Flink. Odată ce ați investit și implementat o tehnologie, este dificil și foarte costisitor să o schimbați ulterior. De exemplu, în compania anterioară aveam o conductă Storm în funcțiune din ultimii 2 ani și funcționa perfect până când a apărut o cerință de unificare a evenimentelor primite și de raportare numai a evenimentelor unice. Acest lucru a necesitat o gestionare a stării care nu este susținută în mod inerent de Storm. Deși am implementat utilizarea unui hashmap în memorie bazat pe timp, dar cu limitarea că starea va dispărea la repornire. De asemenea, au apărut probleme în timpul unor astfel de modificări pe care le-am împărtășit într-unul dintre postările anterioare. Ceea ce încerc să subliniez este că, dacă încercăm să implementăm ceva pe cont propriu pe care cadrul nu îl oferă în mod explicit, ne vom lovi de probleme necunoscute.
3. Stacheta tehnică existentă :
   Un alt punct important este să luăm în considerare stiva tehnică existentă. Dacă stiva existentă are Kafka în loc de la un capăt la altul, atunci Kafka Streams sau Samza s-ar putea potrivi mai ușor. În mod similar, dacă pipeline-ul de procesare se bazează pe arhitectura Lambda și Spark Batch sau Flink Batch este deja în vigoare, atunci are sens să se ia în considerare Spark Streaming sau Flink Streaming. De exemplu, în unul dintre proiectele mele anterioare, aveam deja Spark Batch în pipeline și, astfel, când a apărut cerința de streaming, a fost destul de ușor să aleg Spark Streaming, care necesita aproape același set de competențe și bază de cod.

În concluzie, dacă înțelegem bine punctele forte și limitările cadrelor, împreună cu cazurile noastre de utilizare, atunci este mai ușor să alegem sau cel puțin să filtrăm opțiunile disponibile. În cele din urmă, este întotdeauna bine să avem POC-uri odată ce au fost selectate câteva opțiuni. La urma urmei, toată lumea are papile gustative diferite.

Concluzie :

Spațiul de streaming Apache evoluează într-un ritm atât de rapid încât acest post ar putea fi depășit în ceea ce privește informațiile în câțiva ani. În prezent Spark și Flink sunt greii care conduc din față în ceea ce privește dezvoltările, dar un puști nou poate încă să vină și să se alăture cursei. Apache Apex este unul dintre aceștia. De asemenea, există și soluții de streaming proprietare pe care nu le-am abordat, cum ar fi Google Dataflow. Obiectivul meu în această postare a fost de a ajuta pe cineva care este nou în domeniul streaming-ului să înțeleagă, cu un minim de jargoane, câteva concepte de bază ale streaming-ului, împreună cu punctele forte, limitările și cazurile de utilizare ale cadrelor populare de streaming open source. Sper că postarea a fost de ajutor într-un fel.

Happy Streaming!!!

Puteți să mă urmăriți pe Linkedin și Quora

.