Amikor napjainkban előkerül az a kifejezés, hogy Big Data, akkor ennek a hátterében (technológiai értelemben) vagy egy Hadoop alapú környezet, vagy egy Elasticsearch áll. Vagy persze ennek valamilyen jellegű kombinációja. (pl hdfs alapú adattárolás mellett nosource indexed elasticsearch kereséshez).
Ez a két technológia lényegében uralja a piacot. Előbbi ugye egy robosztus rendszer, ami modulok és célalkalmazások százait vonultatja fel, az utóbbi pedig leginkább keresésre való, de arra viszont nagyon. A megközelítéssel ugye az a baj, hogy a Big Data mint kifejezés pont annyira egzakt mint mondjuk a “cloud”. Tehát önmagában semmit sem jelent és lényegében bármire lehet használni. A megvalószítás technológiai eszközének kiválasztásához nem árt végig gondolni, hogy mit is akarunk tárolni a big data-ban és mit is akarunk azzal csinálni.
Induljunk ki abból, hogy nagy mennyiségű strukturálatlan adatot akarunk tárolni teljesen független adatforrásokból, ahol gyakran változhat akár a nyers adat formátuma is és az így keletkező adathalmazt szeretnénk hatékonyan, gyorsan és legfőképpen egyszerűen analizálni. Bravó, sikeresen megfogalmaztam a “big data”-t egy mondatban. Szóval lényegében a fenti kiindulási alap általában igaz az összes olyan projektre ami magát big datanak nevezi.
Ebben a postban most nem szeretnék kitérni a kereskedelmi big data megoldásokra, mivel azok egyrészt nem nagyon léteznek, másrészt pedig rendszerint vagy eleve félre értik a big data koncepciót, vagy pedig szándékosan csak egy fajta feladatra használhatók.
Az Elasticsearch és a Hadoop technológiailag közös alapokon nyugszanak. Mindkettőnek a lényege, hogy nagy mennyiségű adatot olyan módon kezel, hogy azokat szétszórja számos commodity szerveren, melyek performanciáját párhuzamosan használva ér el extrém magas feldolgozási sebességet.
Az Elasticsearch ezen alapokon nyújt közel valós idejű indexelést és teljes szövegkeresést, akár analizált adatokon is. Mindehhez szabványos JSON csatlakozást biztosít és nagyon fejlett DSL keresési leíró nyelvet aminek a segítségével nagyon komplex kereséseket, levállogatásokat vagy akár valós idejű aggregálásokat, elemzéseket is lehet végezni. Mindezek miatt az Elasticsearch tökéletes választás bármilyen web alapú környezet adatainak kezelésére. A query DSL ráadásul nagyságrendekkel egyszerűbb mint a Hadoopban elérhető hasonló célú MapReduce, éppen ezért előszeretettel választják a kisebb projektekhez, ahol nem annyira jellemző a komplex elemző szaktudás. Szintén fontos előnye az Elasticsearchnek, hogy lényegesen könnyebb az üzemeltetése, kevésbé igényel komoly, naprakész szakértelmet. Ami ezeken túl talán leginkább az ES felé billenthetné a mérleget, az nem más, mint az elasticsearch saját mottója: “You Know, for Search…”
[commercial_break]Szóval az Elasticsearch a kis “big data” egyik legjobb eszköze 🙂 Ezzel szemben a Hadoop környezetek előnye akkor jelenik meg, amikor az ES-ből már kifut a szufla. Egyrészt a Hadoop (hasonlóan már NoSQL megoldásokhoz) valóban képes nyers formában (schemaless módon) tárolni a forrás adatokat és azokat menet közben elemezni, ezzel ellentétben az Elasticsearch alatt futó Lucene folyamatosan transzformálja az adatokat valamilyen mappingre, ami nagyon sok erőforrást igényel, ha valóban mindent nyers (raw) formában akarunk tárolni. A már indexált dokumentumok későbbi updatelése kifejezetten erőforrás igényes művelet, ezért komoly erőforrást igényel a logstash szabályok és grok filterek folyamatos naprakészen tartása.
Számos egyéb hiányosságokkal küzd az ES, ilyen pl a queryből query futtatása, ami eléggé körülmények a viewk, virtuális datasetek támogatásának hiánya miatt. Persze vannak megkerülő megoldástok (lásd a Joinolós cikket), de ezek is komoly hiányosságokkal küzdenek. Ezzel szemben a Hadoop körül egy nagyon komoly eszköz ökoszisztéma alakult ki (amelyhez hasonló persze folyamatosan készülődik az ES körül is), mely nagyon széles eszköztárat nyújt a hadoopban/hdfsben tárolt adat hatékony elemzésére, többek között van SQL szerű query tool, ami sokban könnyíti meg a hagyományos normalizált, relációs adatbázishoz szokott szakembereket.
Érdemes hálózati szempontból is röviden összehasonlítani a két megoldást:
- Míg az Elasticsearch esetén nagyon komoly gondot jelenthez a splitbrain és az, hogy ennek elkerülése érdekében mindig online kell, hogy le adott számú master nodenak, ami miatt az ES nem kifejezetten használható több adatközpontban. (bár mára erre is van lehetőség pl a tribal node segítségével)
- Addig a Hadoop adattárolási modellje nincs kitéve ilyen veszélynek, ott viszont single point of failure elemként funkcionál a namenode. Ennek kezelésére persze ott van a ZooKeeper komponens.
- Konklúzióként egy adatközponton belüli tárolás esetén az ES legyőzhetetlen, nagyobb (különböző geolokációs) adatközpontok esetén viszont a Hadoop a győztes.
Illene végső konklúziót is levonni, de csak ismételni tudom, amit már korábban is írtam:
- Ha egy projekt igényeit ki tud szolgálni az Elasticsearch, akkor a Hadoop használata ágyúval vébre szituáció. Ha viszont kevésnek tűnik a POC során az Elasticsearch, akkor azonnal droppolni kell és át kell állni Hadoopra, különben csak végeláthataltan finetuneolás, folyamatos adatduplikáció, denormalizálás és olyan bonyolult adatstruktúra vár a projektre, amikre hadoop környezetben semmi szükség nem lenne.
Like