Az IBM Marketing cloud friss jelentése szerint “a mai világ adatainak 90 százaléka csak az elmúlt két évben jött létre, ami 2.5 kvintillió bájtnyi adatot naponta – és az új eszközök, érzékelők és technológiák megjelenésével az adatnövekedés üteme valószínűleg még tovább gyorsul”.
Technikai szempontból ez azt jelenti, hogy a nagy adatfeldolgozási világunk egyre összetettebb és nagyobb kihívást jelent. És sok felhasználási esetnek (pl. mobilalkalmazások hirdetései, csalásfelismerés, taxifoglalás, betegmegfigyelés stb.) valós idejű adatfeldolgozásra van szüksége, ahogy és amikor az adatok beérkeznek, hogy gyors cselekvőképes döntéseket hozhassunk. Ezért vált az elosztott adatfolyam-feldolgozás nagyon népszerűvé a Big Data világában.

Ma már számos nyílt forráskódú streaming keretrendszer áll rendelkezésre. Érdekes módon szinte mindegyikük meglehetősen új, és csak az elmúlt néhány évben fejlesztették ki őket. Így egy új ember számára elég könnyű összezavarodni a streaming keretrendszerek megértésében és megkülönböztetésében. Ebben a bejegyzésben először a stream feldolgozás típusairól és aspektusairól beszélek általánosságban, majd összehasonlítom a legnépszerűbb nyílt forráskódú streaming keretrendszereket : Flink, Spark Streaming, Storm, Kafka Streams. Megpróbálom elmagyarázni a működésüket (röviden), a felhasználási eseteiket, erősségeiket, korlátaikat, hasonlóságaikat és különbségeiket.

Mi a Streaming/Stream Processing :
A legelegánsabb definíció, amit találtam : egy olyan típusú adatfeldolgozó motor, amelyet végtelen adathalmazokra terveztek. Semmi több.

A kötegelt feldolgozástól eltérően, ahol az adatok egy munkával kezdődnek és végződnek, és a munka a véges adatok feldolgozása után befejeződik, a Streaming a valós időben folyamatosan érkező korlátlan adatok feldolgozására szolgál napok, hónapok, évek és örökkévalóságig. Mint ilyen, mivel mindig fel és futásra szánták, egy streaming alkalmazást nehéz megvalósítani és még nehezebb karbantartani.

A streaming feldolgozás fontos szempontjai:

A streaming feldolgozással kapcsolatban van néhány fontos jellemző és kifejezés, amelyekkel tisztában kell lennünk ahhoz, hogy megértsük bármely streaming keretrendszer erősségeit és korlátait :

• Szállítási garanciák :
  Ez azt jelenti, hogy mi a garancia arra, hogy egy adott beérkező rekord egy streaming motorban bármi áron feldolgozásra kerül. Ez lehet vagy Atleast-once (hiba esetén is legalább egyszer kerül feldolgozásra) , Atmost-once (hiba esetén nem kerülhet feldolgozásra) vagy Exactly-once (hiba esetén is pontosan egyszer kerül feldolgozásra) . Nyilvánvalóan az Exactly-once kívánatos, de nehéz elérni az elosztott rendszerekben, és kompromisszumot köt a teljesítményhez.
• Hibatűrés :
  Hiba esetén, például csomóponthiba, hálózati hiba stb. esetén a keretrendszernek képesnek kell lennie a helyreállításra, és újra kell kezdenie a feldolgozást onnan, ahol abbahagyta. Ez úgy érhető el, hogy a streaming állapotát időről időre ellenőrizni kell valamilyen tartós tárolóba. pl. a kafka offsets ellenőrzőpontozása a zookeeperbe, miután megkaptuk a rekordot a Kafkából és feldolgoztuk.
• Állapotkezelés :
  Az állapotfüggő feldolgozási követelmények esetében, ahol bizonyos állapotot kell fenntartani (pl.
• Teljesítmény :
  Ez magában foglalja a késleltetést (milyen gyorsan lehet egy rekordot feldolgozni), az áteresztőképességet (feldolgozott rekordok/másodperc) és a skálázhatóságot. A késleltetési időnek a lehető legkisebbnek, míg az áteresztőképességnek a lehető legnagyobbnak kell lennie. Nehéz mindkettőt egyszerre elérni.
• Speciális funkciók : Eseményidő-feldolgozás, vízjelek, ablakozás
  Ezekre a funkciókra akkor van szükség, ha a folyamfeldolgozási követelmények összetettek. Például a rekordok feldolgozása az alapján, hogy mikor keletkezett a forrásban (eseményidő-feldolgozás). Ha részletesebben szeretne többet tudni, kérjük, olvassa el ezeket a kötelezően olvasandó bejegyzéseket a Google emberétől, Tyler Akidau-tól : 1. rész és 2. rész.
• Érettség :
  Az elfogadás szempontjából fontos, hogy jó, ha a keretrendszer már bizonyított és nagyvállalatok által méretarányosan tesztelt. Nagyobb valószínűséggel kap jó közösségi támogatást és segítséget a stackoverflow-n.

A stream feldolgozás két típusa:

Az imént tárgyalt kifejezések ismeretében most már könnyű megérteni, hogy 2 megközelítés létezik egy Streaming keretrendszer megvalósítására:

Native Streaming :
Az úgynevezett Native Streaming. Ez azt jelenti, hogy minden bejövő rekordot azonnal feldolgozunk, amint megérkezik, anélkül, hogy megvárnánk a többit. Van néhány folyamatosan futó folyamat (amelyeket a keretrendszertől függően operátoroknak/feladatoknak/csavaroknak nevezünk), amelyek örökké futnak, és minden rekord ezeken a folyamatokon halad keresztül a feldolgozáshoz. Példák : Storm, Flink, Kafka Streams, Samza.

Micro-batching :
Más néven gyors kötegelés. Ez azt jelenti, hogy a néhány másodpercenként beérkező rekordokat egybegyűjtik, majd néhány másodperces késleltetéssel egyetlen mini tételben dolgozzák fel. Példák: Példák: Spark Streaming, Storm-Trident.

Mindkét megközelítésnek vannak előnyei és hátrányai.
A natív streaming természetesnek tűnik, mivel minden rekordot azonnal feldolgoz, amint megérkezik, így a keretrendszer a lehető legkisebb késleltetést tudja elérni. Ez azonban azt is jelenti, hogy nehéz hibatűrést elérni az áteresztőképesség veszélyeztetése nélkül, mivel minden egyes rekord esetében nyomon kell követni és ellenőrizni kell az egyszer feldolgozott rekordokat. Emellett az állapotkezelés is egyszerű, mivel vannak olyan hosszan futó folyamatok, amelyek könnyen fenntartják a szükséges állapotot.

A mikrodobozolás , másrészt, éppen ellenkezőleg. A hibatűrés ingyen van, mivel lényegében egy kötegelésről van szó, és az áteresztőképesség is magas, mivel a feldolgozás és az ellenőrzőpontozás egy menetben történik a rekordok csoportjára. De ez némi késleltetés árán történik, és nem lesz olyan érzés, mint egy természetes streaming. A hatékony állapotkezelés fenntartása is kihívást jelent majd.

Streaming Frameworks One By One:

Storm :
A Storm a streaming világ hadoopja. Ez a legrégebbi nyílt forráskódú streaming keretrendszer és az egyik legérettebb és legmegbízhatóbb. Igazi streaming és jó egyszerű esemény alapú felhasználási esetekre. A Stormról részletesen beszámoltam ezekben a bejegyzésekben: 1. rész és 2. rész.

Előnyei:

• Nagyon alacsony késleltetés, valódi streaming, kiforrott és nagy áteresztőképesség
• Kiválóan alkalmas nem bonyolult streaming felhasználási esetekre

Hátrányok

• Nincs állapotkezelés
• Nincsenek olyan fejlett funkciók, mint az eseményidő feldolgozás, Összesítés, ablakozás, munkamenetek, vízjelek, stb
• Előrehaladási garancia

Spark Streaming :

A Spark a hadoop valódi utódjaként jelent meg a kötegelt feldolgozásban, és az első olyan keretrendszer, amely teljes mértékben támogatja a Lambda architektúrát (ahol mind a kötegelt, mind a streaming implementálva van; kötegelt a korrektség, streaming a sebesség érdekében). Mérhetetlenül népszerű, kiforrott és széles körben elfogadott. A Spark Streaming ingyenesen jár a Sparkkal együtt, és a streaminghez micro batchinget használ. A 2.0 kiadás előtt a Spark Streamingnek komoly teljesítménykorlátozásai voltak, de az új 2.0+ kiadással strukturált streamingnek nevezik, és számos jó tulajdonsággal rendelkezik, mint például a tungsten nevű egyéni memóriakezelés (mint a flink), a vízjelek, az eseményidő-feldolgozás támogatása stb. Emellett a strukturált streaming sokkal absztraktabb, és a 2.3.0 kiadásban lehetőség van a micro-batching és a folyamatos streaming mód közötti váltásra. A Continuous Streaming mód azt ígéri, hogy a Stormhoz és a Flinkhez hasonlóan szubkésleltetést biztosít, de még gyerekcipőben jár, sok korlátozással a műveletekben.

Előnyök:

• Támogatja a Lambda architektúrát, ingyenesen jár a Sparkkal
• Nagy áteresztőképesség, jó sok olyan felhasználási esethez, ahol nem szükséges a szub-latencia
• Hibatűrés alapértelmezetten a micro-batch jelleg miatt
• Egyszerűen használható magasabb szintű API-k
• Nagy közösség és agresszív fejlesztések
• Pontos egyszer

Hátrányok

• Nem igazi streaming, Nem alkalmas alacsony késleltetési követelményekre
• Túl sok paramétert kell beállítani. Nehéz jól beállítani. Írtam egy bejegyzést a személyes tapasztalataimról a Spark Streaming hangolása közben
• Jellegénél fogva statikus
• Megmarad a Flink mögött sok fejlett funkcióban

Flink :

A Flink is hasonló tudományos háttérrel rendelkezik, mint a Spark. Míg a Spark a UC Berkley egyetemről származik, addig a Flink a berlini TU egyetemről. A Sparkhoz hasonlóan ez is támogatja a Lambda architektúrát. De a megvalósítás teljesen ellentétes a Sparkkal. Míg a Spark alapvetően egy batch, a Spark streaming mikro-batching és a Spark Batch speciális esete, addig a Flink alapvetően egy valódi streaming motor, amely a batchet a streaming speciális eseteként kezeli, korlátozott adatokkal. Bár a két keretrendszer API-jai hasonlóak, de az implementációkban nincs hasonlóság. A Flinkben minden egyes funkció, mint a map,filter,reduce,stb. hosszú futású operátorként van implementálva (hasonlóan a Stormban lévő Bolthoz)

A Flink a Storm valódi utódjának tűnik, mint ahogy a Spark követte a hadoopot a batchben.

Előnyei:

• A nyílt forráskódú Streaming tájkép innovációjának éllovasa
• Az első igazi streaming keretrendszer minden fejlett funkcióval, mint például eseményidő feldolgozás, vízjelek, stb
• alacsony késleltetés nagy áteresztőképességgel, az igényeknek megfelelően konfigurálható
• Automatikus beállítás, nem túl sok paramétert kell beállítani
• Pontos egyszer
• Széles körben elfogadott nagyvállalatoknál, mint az Uber,Alibaba.

Hátrányok

• Kicsit megkésett, kezdetben hiányzott az elfogadás
• A közösség nem olyan nagy, mint a Spark, de most gyors ütemben növekszik
• Nem ismert a Flink Batch elfogadása egyelőre, csak a streaminghez népszerű.

Kafka Streams :

A Kafka Streams , ellentétben más streaming keretrendszerekkel, egy könnyű könyvtár. Hasznos az adatok Kafkából történő streamelésére , transzformáció elvégzésére, majd visszaküldésére a kafkába. A Java Executor Service Thread pool-hoz hasonló könyvtárként értelmezhetjük, de beépített Kafka támogatással. Jól integrálható bármilyen alkalmazásba, és azonnal működik.

Könnyűsége miatt mikroszolgáltatások típusú architektúrában is használható. Nincs párja a teljesítmény szempontjából a Flinknek, de nem is kell külön fürt a futtatáshoz, nagyon praktikus és könnyen telepíthető és elkezd működni . Belsőleg a Kafka Consumer csoportot használja, és a Kafka log filozófiáján dolgozik.
Ez a bejegyzés alaposan elmagyarázza a Kafka Streams vs Flink Streaming felhasználási eseteit.

A Kafka Streams egyik fő előnye, hogy a feldolgozása Pontosan egyszer végponttól végpontig. Ez azért lehetséges, mert a forrás, valamint a cél, mindkettő Kafka, és a Kafka 0.11-es verziójától, amelyet 2017 júniusa körül adtak ki, Exactly once támogatott. Ennek a funkciónak az engedélyezéséhez csak egy flaget kell engedélyeznünk, és máris működni fog. További részleteket itt és itt osztottunk meg.

Előnyei:

• Nagyon könnyű könyvtár, jó mikroszolgáltatásokhoz,IOT alkalmazásokhoz
• Nem igényel dedikált fürtöt
• Örököl minden Kafka jó tulajdonságot
• Támogatja a Stream joins-t, belsőleg rocksDb-t használ az állapot fenntartására.
• Exactly Once ( Kafka 0.11-től kezdve).

Hátrányok

• Feszesen kapcsolódik a Kafkához, nem használható Kafka nélkül a képen
• Még eléggé új, gyerekcipőben jár, még nem tesztelték nagyvállalatoknál
• Nem alkalmas nehéz munkára, mint a Spark Streaming,Flink.

Samza :

Röviden fogok foglalkozni a Samzával. Samza 100 lábról nézve a Kafka Streamshez hasonlít megközelítésben. Sok hasonlóság van. Mindkét keretrendszer ugyanazoktól a fejlesztőktől származik, akik a LinkedIn-nél implementálták a Samzát, majd megalapították a Confluent-et, ahol a Kafka Streams-t írták. Mindkét technológia szorosan kapcsolódik a Kafkához, nyers adatokat vesznek át a Kafkából, majd feldolgozott adatokat tesznek vissza a Kafkába. Ugyanazt a Kafka Log filozófiát használják. A Samza a Kafka Streams egyfajta skálázott változata. Míg a Kafka Streams egy mikroszolgáltatásokhoz szánt könyvtár , a Samza egy teljes értékű fürtfeldolgozás, amely a Yarnon fut.
Előnyei :

• Nagyon jó a nagy információállomások fenntartásában (jó a streamek egyesítésének felhasználási esetére) a rocksDb és a kafka log használatával.
• Hibatűrő és nagy teljesítményű a Kafka tulajdonságainak használatával
• Egyike a megfontolandó lehetőségeknek, ha már használjuk a Yarnt és a Kafkát a feldolgozási csővezetékben.
• Jó Yarn állampolgár
• alacsony késleltetés , nagy áteresztőképesség , kiforrott és tesztelt méretarányos

Hátrányok :

• Keményen összekapcsolódik a Kafkával és a Yarnnal. Nem könnyű használni, ha ezek egyike sincs a feldolgozási csővezetékben.
• Atleast-Once feldolgozási garancia. Nem vagyok benne biztos, hogy most már pontosan egyszer támogatja, mint a Kafka Streams a Kafka 0.11 után
• A fejlett streaming funkciók hiánya, mint a Watermarks, Sessions, triggers, stb

Streaming keretrendszerek összehasonlítása:

A technológiákat csak hasonló ajánlatokkal tudjuk összehasonlítani. Míg a Storm, a Kafka Streams és a Samza most hasznosnak tűnik egyszerűbb felhasználási esetekben, az igazi verseny egyértelműen a legújabb funkciókkal rendelkező nehézsúlyúak között zajlik: Spark vs Flink

Mikor összehasonlításról beszélünk, általában azt szoktuk kérdezni: Mutasd a számokat 🙂

A benchmarking csak akkor jó módszer az összehasonlításra, ha azt harmadik fél végezte el.

Az egyik régi benchmarking például ez volt.
De ez még a Spark Streaming 2.0 előtti időkben volt, amikor még voltak korlátai az RDD-kkel és a project tungsten még nem volt a helyén.
Most a Structured Streaming 2.0 utáni kiadással , a Spark Streaming nagyon próbál felzárkózni és úgy tűnik, hogy kemény küzdelem lesz.

A benchmarking mostanában egyfajta nyílt macskaviadal lett a Spark és a Flink között.

A Spark nemrég végzett benchmarking összehasonlítást a Flinkkel, amire a Flink fejlesztői egy másik benchmarkinggal válaszoltak, ami után a Spark srácok szerkesztették a posztot.

Jobb, ha manapság nem hiszünk a benchmarkingnak, mert még egy kis finomítás is teljesen megváltoztathatja a számokat. Semmi sem jobb, mint kipróbálni és tesztelni magunkat, mielőtt döntenénk.
Mára teljesen nyilvánvaló, hogy a Flink vezet a Streaming Analytics térben, a legtöbb kívánt szempontot, mint például a pontosan egyszer, az átviteli teljesítmény, a késleltetés, az állapotkezelés, a hibatűrés, az előzetes funkciók stb.

A Flink néhány valódi újítása, mint például a könnyű súlyozott pillanatfelvételek és az off heap egyéni memóriakezelés, lehetővé tette mindezt.
A Flinkkel kapcsolatos egyik fontos aggodalom az érettség és az elfogadottsági szint volt egy ideig, de most olyan vállalatok, mint az Uber, az Alibaba, a CapitalOne tömegesen használják a Flink streaminget, ami igazolja a Flink Streamingben rejlő lehetőségeket.

A közelmúltban az Uber nyíltan közzétette legújabb Streaming analitikai keretrendszerét, az AthenaX-et, amely a Flink motorra épül. Ebben a bejegyzésben arról beszéltek, hogyan költöztették át a streaming analitikájukat a STormról az Apache Samzára és most a Flinkre.

Egy fontos dolog, amit meg kell jegyeznünk, ha már észrevetted, hogy minden natív streaming keretrendszer, mint a Flink, Kafka Streams, Samza, amely támogatja az állapotkezelést, a RocksDb-t használja belsőleg. A RocksDb egyedülálló abban az értelemben, hogy minden egyes csomóponton helyben tartja a perzisztens állapotot, és nagy teljesítményű. Az új streaming rendszerek kulcsfontosságú részévé vált. A RocksDb-ről részletes információkat osztottam meg az egyik korábbi bejegyzésben.

Hogyan válasszuk ki a legjobb streaming keretrendszert :

Ez a legfontosabb rész. És az őszinte válasz: attól függ 🙂
Nem szabad elfelejteni, hogy egyetlen feldolgozási keretrendszer sem lehet silver bullet minden felhasználási esetre. Minden keretrendszernek vannak erősségei és vannak korlátai is. Mégis , némi tapasztalattal, megosztok néhány támpontot, hogy segítsen a döntések meghozatalában:

1. A felhasználási esetektől függ:
   Ha a felhasználási eset egyszerű, nem kell a legújabb és legnagyszerűbb keretrendszert választani, ha bonyolult megtanulni és megvalósítani. Sok múlik azon, hogy mennyit vagyunk hajlandóak befektetni azért, amit cserébe szeretnénk. Ha például egyszerű IOT típusú eseményalapú riasztási rendszerről van szó, a Storm vagy a Kafka Streams tökéletesen megfelel a munkához.
2. Jövőbeni megfontolások:
   Ugyanakkor azt is tudatosan át kell gondolnunk, hogy mik lesznek a lehetséges jövőbeli felhasználási esetek? Lehetséges, hogy a fejlett funkciók, mint az eseményidő-feldolgozás, aggregálás, stream joins stb. igényei jöhetnek a jövőben ? Ha a válasz igen vagy lehet, akkor jobb, ha olyan fejlett streaming keretrendszerekkel haladunk előre, mint a Spark Streaming vagy a Flink. Ha egyszer befektetett és végrehajtott egy technológiába, nehéz és hatalmas költségekkel jár a későbbi változtatás. Például az előző vállalatnál volt egy Storm csővezetékünk, amely az elmúlt 2 évtől kezdve működött, és tökéletesen működött, amíg nem jött egy követelmény a bejövő események egyedivé tételére és csak az egyedi események jelentésére. Ez olyan állapotkezelést igényelt, amelyet a Storm nem támogat. Bár megvalósítottam az idő alapú in-memory hashmap, de ez volt a korlátozás, hogy az állapot megy el az újraindításkor . Továbbá, ez problémákat okozott az ilyen változások során, amelyeket megosztottam az egyik korábbi hozzászólásban. A lényeg, amit próbálok tenni, ha megpróbálunk megvalósítani valamit saját magunk, amit a keretrendszer nem kifejezetten biztosítja, akkor kénytelenek vagyunk ismeretlen problémákba ütközni.
3. Meglévő Tech Stack :
   Egy további fontos pont a meglévő tech stack figyelembe vétele. Ha a meglévő stackben a Kafka végponttól végpontig megtalálható, akkor a Kafka Streams vagy a Samza könnyebben illeszkedhet. Hasonlóképpen, ha a feldolgozási csővezeték a Lambda architektúrán alapul, és a Spark Batch vagy a Flink Batch már létezik, akkor érdemes megfontolni a Spark Streaming vagy a Flink Streaming lehetőségét. Például az egyik korábbi projektemben már volt Spark Batch a csővezetékben, és így amikor a streaming követelmény jött, elég könnyű volt kiválasztani a Spark Streaminget, amely szinte ugyanazt a készségkészletet és kódbázist igényelte.

Röviden, ha jól értjük a keretrendszerek erősségeit és korlátait a felhasználási esetekkel együtt, akkor könnyebb kiválasztani vagy legalábbis leszűrni a rendelkezésre álló lehetőségeket. Végül pedig mindig jó, ha POC-kat készítünk, ha már kiválasztottunk néhány lehetőséget. Végül is mindenkinek más az ízlése.

Következtetés :

Apache Streaming tér olyan gyors ütemben fejlődik, hogy ez a bejegyzés néhány év múlva elavult lehet az információk tekintetében. Jelenleg a Spark és a Flink a nehézsúlyúak, akik elöl járnak a fejlesztések tekintetében, de még mindig jöhet néhány új gyerek, aki csatlakozhat a versenyhez. Az Apache Apex az egyik ilyen. Vannak saját fejlesztésű streaming megoldások is, amelyekkel nem foglalkoztam, mint például a Google Dataflow. Ennek a bejegyzésnek az volt a célja, hogy segítsek valakinek, aki új a streamingben, hogy minimális szakzsargonnal megértse a streaming néhány alapvető fogalmát, valamint a népszerű nyílt forráskódú streaming keretrendszerek erősségeit, korlátait és felhasználási eseteit. Remélem, a bejegyzés valamilyen módon hasznos volt.

Happy Streaming!!

Követhet engem a Linkedin-en és a Quora-n

.