Ha megnézzük ezt a képet a big data eszközök listájával, úgy tűnhet, hogy az összes lehetséges rés ezen a területen már foglalt. Ennyi verseny mellett nagyon nehéz lehet úttörő technológiával előállni.
Az Apache Flink alkotói erről másképp gondolkodnak. A Stratosphere nevű kutatási projektként indult. A Stratosphere-t forkolták, és ez a fork lett az, amit Apache Flink néven ismerünk. 2014-ben Apache Incubator projektként fogadták el, és alig néhány hónappal később egy felső szintű Apache projekt lett belőle. E sorok írásakor a projektnek közel tizenkétezer commitja és több mint 300 közreműködője van.
Miért van ekkora figyelem? Azért, mert az Apache Flinket új generációs nagy adatfeldolgozó keretrendszernek nevezték el, és elég újítás van a tarsolyában ahhoz, hogy leváltsa az Apache Sparkot, és a kötegelt és folyamfeldolgozás új de-facto eszközévé váljon.
Váltania kellene az Apache Flinkre? Maradjon még egy ideig az Apache Sparknál? Vagy az Apache Flink csak egy új trükk? Ez a cikk megpróbál választ adni ezekre és más kérdésekre.
Hacsak nem élt egy szikla alatt az elmúlt években, hallott már az Apache Sparkról. Úgy tűnik, hogy minden modern rendszer, amely bármilyen adatfeldolgozást végez, valamilyen módon használja az Apache Sparkot.
Hosszú ideig a Spark volt a legújabb és legnagyszerűbb eszköz ezen a területen. Elődeihez képest lenyűgöző tulajdonságokat nyújtott, például:
- Lenyűgöző sebesség: Tízszer gyorsabb, mint a Hadoop, ha az adatokat lemezen dolgozza fel, és akár százszor gyorsabb, ha az adatokat memóriában dolgozza fel.
- Egyszerűbb irányított aciklikus gráf modell: Az adatfeldolgozási feladatok merev MapReduce keretrendszerrel történő definiálása helyett a Spark lehetővé teszi a feladatok gráfjának definiálását, amely komplex adatfeldolgozási algoritmusokat valósíthat meg
- Patakfeldolgozás: Az olyan új technológiák megjelenésével, mint például a dolgok internete, nem elég egyszerűen hatalmas mennyiségű adatot feldolgozni. Most már hatalmas mennyiségű adatot kell feldolgozni, ahogy azok valós időben érkeznek. Ezért az Apache Spark bevezette a folyamfeldolgozást, amely lehetővé teszi a potenciálisan végtelen adatfolyam feldolgozását.
- Gazdag könyvtárkészlet: Az alapfunkcióin kívül az Apache Spark nagy teljesítményű könyvtárakat biztosít gépi tanuláshoz, gráffeldolgozáshoz és SQL-lekérdezések végrehajtásához.
Hogy jobban megértsük, hogyan írhatunk alkalmazásokat az Apache Sparkkal, nézzük meg, hogyan valósíthatunk meg egy egyszerű szószámláló alkalmazást, amely megszámolja, hogy az egyes szavak hányszor szerepelnek egy szöveges dokumentumban:
// Read fileval file = sc.textFile("file/path")val wordCount = file // Extract words from every line .flatMap(line => line.split(" ")) // Convert words to pairs .map(word => (word, 1)) // Count how many times each word was used .reduceByKey(_ + _)Ha ismerjük a Scalát, ez a kód egyszerűnek tűnik, és hasonló a hagyományos gyűjteményekkel való munkához. Először is beolvasunk egy sorlistát a file/path” alatt található fájlból. Ez a fájl lehet akár egy helyi fájl, akár egy HDFS-ben vagy S3-ban lévő fájl.
Ezután minden sort szavak listájára bontunk a flatMap módszerrel, amely egyszerűen felosztja a sztringet a szóköz szimbólummal. Ezután a szavak számlálásának megvalósításához a map módszerrel minden szót párossá alakítunk, ahol a pár első eleme egy szó a bemeneti szövegből, a második elem pedig egyszerűen egy egyes szám.
Az utolsó lépés egyszerűen megszámolja, hogy az egyes szavakat hányszor használtuk, azáltal, hogy az azonos szóra vonatkozó összes pár számadatait összeadjuk.
Az Apache Spark nagyszerű és sokoldalú eszköznek tűnik. De mit hoz az Apache Flink?
Az első pillantásra nem tűnik sok különbségnek. Az architektúra diagramja nagyon hasonlónak tűnik:
Ha megnézzük az Apache Flink szószámláló alkalmazás kódpéldáját, láthatjuk, hogy szinte semmi különbség nincs:
val file = env.readTextFile("file/path")val counts = file .flatMap(line => line.split(" ")) .map(word => (word, 1)) .groupBy(0) .sum(1)A kevés említésre méltó különbség, hogy ebben az esetben a textFile metódus helyett a readTextFile metódust kell használnunk, és hogy egy metóduspárt kell használnunk: groupBy és sum a reduceByKey helyett.
Szóval mi ez a nagy felhajtás? Lehet, hogy az Apache Flink külsőleg nem mutat látható különbségeket, de határozottan elég újdonságot tartalmaz ahhoz, hogy a következő generációs adatfeldolgozó eszközzé váljon. Íme csak néhány ezek közül:
- Valódi streaming feldolgozást valósít meg: Amikor egy adatfolyamot feldolgoz az Apache Sparkban, azt sok kis kötegelt problémaként kezeli, ezért a stream-feldolgozás egy speciális eset. Az Apache Flink ezzel szemben a kötegelt feldolgozást speciálisként kezeli, és nem használ mikrokötegelést.
- Jobb támogatás a ciklikus és iteratív feldolgozáshoz: A Flink néhány további műveletet biztosít, amelyek lehetővé teszik a ciklusok megvalósítását a streaming alkalmazásban és az olyan algoritmusokban, amelyeknek több iterációt kell végrehajtaniuk a kötegelt adatokon.
- Egyedi memóriakezelés: Az Apache Flink egy Java alkalmazás, de nem támaszkodik teljes mértékben a JVM szemétgyűjtőjére. Egyéni memóriakezelőt valósít meg, amely a feldolgozandó adatokat bájtmezőkben tárolja. Ez lehetővé teszi a szemétgyűjtő terhelésének csökkentését és a teljesítmény növelését. Erről ebben a blogbejegyzésben olvashat.
- Alacsonyabb késleltetés és nagyobb áteresztőképesség: Több, harmadik fél által végzett teszt szerint az Apache Flink alacsonyabb késleltetéssel és nagyobb áteresztőképességgel rendelkezik, mint versenytársai.
- Hatékony windows operátorok: Amikor egy adatfolyamot kell feldolgozni, a legtöbb esetben egy függvényt kell alkalmazni a folyam elemeinek egy véges csoportjára. Például meg kell számolnod, hogy az alkalmazásod hány kattintást kapott minden egyes ötperces intervallumban, vagy tudni szeretnéd, hogy mi volt a legnépszerűbb tweet a Twitteren minden egyes tízperces intervallumban. Bár a Spark támogatja az ilyen felhasználási esetek egy részét, az Apache Flink sokkal erősebb operátorkészletet biztosít a folyamfeldolgozáshoz.
- Könnyűsúlyú elosztott pillanatfelvételek megvalósítása: Ez lehetővé teszi, hogy az Apache Flink alacsony rezsiköltséget és csak egyszeri feldolgozási garanciákat nyújtson a folyamfeldolgozásban, anélkül, hogy a Sparkhoz hasonlóan mikrokötegelést használna.
Szóval, egy új projekten dolgozol, és ki kell választanod hozzá egy szoftvert. Milyen ypi-t kellene használnod? Sparkot? Flinket?
Természetesen itt nincs helyes vagy helytelen válasz. Ha komplex folyamfeldolgozást kell végezned, akkor én az Apache Flink használatát javasolnám. Ez jobban támogatja a stream-feldolgozást és néhány jelentős fejlesztéssel rendelkezik.
Ha nincs szükséged vérző stream-feldolgozási funkciókra, és szeretnél a biztos oldalon maradni, akkor talán jobb, ha maradsz az Apache Sparknál. Ez egy érettebb projekt, nagyobb felhasználói bázissal, több képzési anyaggal és több harmadik féltől származó könyvtárral rendelkezik. De ne feledje, hogy az Apache Flink percről percre zárja ezt a szakadékot. Egyre több projekt választja az Apache Flinket, ahogy egyre érettebbé válik.
Ha viszont szeret kísérletezni a legújabb technológiával, akkor mindenképpen adjon egy esélyt az Apache Flinknek.
Mindez azt jelenti, hogy az Apache Spark elavult, és pár éven belül mindannyian az Apache Flinket fogjuk használni? A válasz meglepheti Önt. Bár a Flinknek van néhány lenyűgöző funkciója, a Spark nem marad a régi. Az Apache Spark például 2015-ben a Tungsten projekt kiadásával bevezette az egyéni memóriakezelést, és azóta olyan funkciókkal bővült, amelyeket először az Apache Flink vezetett be. A győztes még nem dőlt el.
A következő blogbejegyzésekben többet fogok írni arról, hogyan használhatod az Apache Flinket kötegelt és stream feldolgozásra, úgyhogy maradj velünk!
Ha többet szeretnél tudni az Apache Flinkről, akkor nézd meg a Pluralsight tanfolyamomat, ahol részletesebben foglalkozom az Apache Flinkkel. Itt van egy rövid előzetese ennek a kurzusnak.