Tisztázzuk az alapokat: big data, nosql, ES, APM

Mielőtt nagyon belemélyednél a konkrét témákba (lásd címben), talán érdemes tisztázni, hogy mit is jelentenek ezek a fogalmak, mi közük van egymáshoz és konkrétan én mit értek ezeken. Ebben a postban véletlenül sem szeretném tudományos alapokig részletezni és szakmailag sem mennék bele. Célom csak egy általános kép kifejtése azoknak, akik csak most ismerkednek ezekkel a fogalmakkal.
Big data: kezdeném is mindjárt a legnagyobb lufival. Kezdetben vala a strukturált adattárolás, amikor (az ősidőkben) még luxus volt az adattár, jól végig gondoltuk, hogy mit is akarunk tárolni és törekedtünk arra, hogy ezt a leginkább optimális módon tegyük. Ezzel együtt eljött az internet, eljöttek a felhők (nem… nem a skynet) és eljött mindaz, ami ma jellemzi az adattárolást. Az olcsó adattárolás, a mesterséges(-nek tűnő) intelligencia (gépi tanulás) és strukturálhatatlan adatkörök miatt jöt létre az a valami, amit big datanak nevezünk. Mi jellemzi ezt: gyakorlatilag mindent tárolunk amilyen adatot csak elő tudunk állítani, annak minősége, jellege és értelme nélkül, mindezt tesszük azzal a szándékkal, hogy később feltételezhetően fel fogunk fedezni olyan összefüggéseket, amik értelmet adnak a strukturálatlan adatnak. A régi mondás, mely szerint “a kevesebb több”, mára átalakult a “több az több lehet” mondássá.

NoSQL: ahogy az előző pontot is kezdtem: kezdetben vala a strukturált adattárolás. Ennek az egyik legismertebb manifesztációja az SQL alapú adattárolás és a relációs adatbázisok. Ez az adattárolás azon az igen logikus feltételezésen alapszik, hogy azonos jellegű adatokat tárolunk amelyek közötti összefüggéseket szeretnénk értelmezni és kihasználni. Ez az adattárolás tipikusan nem az, ami a Big data adatmodellekhez kell. A strukturálatlan adattömegek, akár folyamatosan változó adattartalmú dokumentumok hatékony kezelésére találták ki a NoSQL koncepciót. Anélkül, hogy túlságosan belemélyednék a NoSQL filozófiájába a legtöbb implementációt úgy kell elképzelni, hogy lényegi kötöttségek nélkül az adatbázisban tárolt adatok egyszerű kulcs-érték (vagy bármilyen más kapcsolati modell mentén) tárolják az adatokat, amelyeket könnyen lehet beszúrni, frissíteni, keresni és lényegében minden elemi adatbázis műveletet könnyedén lehet velük intézni. A NoSQL implementációkat végtelenül egyszerű szoftver architektúra jellemzi, egyszerű skálázhatóság, alkalmazás szinten megoldott magas rendelkezésreállás és a modernebb implementációkban akár elosztott tranzakció kezelés is. Ami talán leginkább jellemzi a NoSQL-eket (és pont ez adja a jó táptalajt a big data jellegű felhasználásnak: a benne tárolt adatok (legyen az egy dokumentum vagy egy telemetrikus adatsor) ugyanolyan gyorsan érhető el függetlenül attól, hogy 5 perce lett rögzítve vagy 5 éve.
Elasticsearch (ES): Bár az Elasticsearch terméket sokan egyfajta NoSQL implementációként aposztrofálják, de valójában az ES célja koránt sem egy teljes értékű NoSQL implementáció megvalósítása. Az ES egy nagyon fejlett kereső motor, ami ennél fogva tökéletes eszköze lehet a házi barkács big data projekteknek. Közel valós idejű indexelést (adattárolást) és adatkinyerést biztosít. Amihez fejlett statisztikai és aggregációs valamint igen modern szöveg analizáló metódusokat nyújt. Ezek szintén jó eszközei lehetnek egy deviancia elemző vagy éppen azonos karakterisztikájú eseményeket vizsgáló gépi tanuló (machine learning) algoritmusnak. Az ES minden szempontból az önálló működésre van tervezve. Gyakorlatilag konzervdobozokon is elfut és rugalmasan skálázható újabb konzervdobozokkal. Az adatkörök (indexek) karbantartása teljesen automatikus, beleértve a replikációkat, a rebalancet és az összes recovery folyamatot is. Rendszerfelügyelet alatt lényegében csak annyit vár el, hogy lehetőleg csak olyankor piszkáljuk, amikor minden státusz zöld. A háttérben minden kihívást megold.
APM: A bigdata-tól az ES-ig bemutattam magát a koncepciót és az eszközt. Most akkor jöhet az adat, amit pl: elemezhetünk mindezzel. Az APM egy rövidítés szó, ami az “Application Performance Management”-et fedi. Ez egy igen komplex folyamat, aminek a lényege egy vagy több alkalmazás jellemző performancia adatainak hatékony mérése és ez alapján akár automatizált döntések meghozatala. Legyen ez egy bottleneck riasztás vagy akár egy automatizált erőforrás bevonás, sőt ide tartozhat pl: egy rosszul performáló komponens automatikus izolálása is. Mindezt emberi beavatkozás nélkül. Ez jól hangzik, de hol van itt big data és miért kell ehhez ES/NoSQL? Amig egy alkalmazásról beszélünk, addig erre feltétlenül nincs szükség, ha viszont egy nagyvállalat alkalamzás ökoszisztémájáról beszélünk, ahol akár több száz alkalmazás közötti relációkat kellene megismerni, feltérképzelni és ez alapján lépéseket megtervezni, akkor bizony előkerülhet a big data mint koncepció. Miért kellene megérteni több száz alkalamzás akár több tízezer performancia mutatójának az összes összefüggését, ha ezeket a relációkat statisztikai elemzéssel is ki lehet mutatni és az ezen elemzések során jelentkező devianciákból nem csak azt lehet megmondani, hogy hol és milyen performancia problémák vannak, de azt is, hogy ez milyen más alkalmazások, más performancia mutatójára hathat ki negatívan? Mivel realtime performancia adatokról beszélünk, amik alapján akár döntéseket is meg kell hozni pl egy incidens elkerülése érdekében, ezért a reakcióidő kritikus, így adott lehet a NoSQL és akár az Elasticsearch erre a célra. A big data mint koncepció szintén adott, hiszen nincs két ugyanolyan alkalamás, minden alkalmazás esetén más és más lehet az adott alkalamzás egyes funkcióinak jellemző performancia adata. Ráadásul mivel eleve feltételezzük, hogy lehetőleg minden adatot gyüjteni akarunk függetlenül attól, hogy látjuk-e annak értelmét/célját (hiszen ezek az összefüggésekre csak később derülhet majd fény az elemzésnél), ezért a big data mint koncepció elkerülhetetlen. Maga a megközelítés egyébként nem újkeletű. A legtöbb piaci (méregdrága) APM implementáció már évek óta “mesterséges(nek tűnő) intelligenciával” gyűjti az adatokat, valamint integrációs lehetőséget nyújt real-time adatelemzés céljából pl. Elasticsearch feedelésre.

[commercial_break]

Az APM persze csak egy konkrét példa arra, hogy mire jó a big data és miért jó ehhez akár Elasticsearch-öt használni. A nagyvilágban ezek a technológiák mára ott vannak minden olyan technológia mögött ahol a “keresés” kifejezés gyorsasága és pontossága kritikus. Legyen az akár egy webshop, vagy az önvezető autó technológiák, vagy éppen az amikor a rádióban hallott zeneszám szövegéből néhány szóra emlékezve beírod az adott szavakat a google-be, ami megérti ezt, akár úgy is, hogy a szavak felét elgépelted vagy eleve rosszul értetted. De ugyanezek a technológiák vannak az egyre divatosabb chatbotok, sőt a virtuális asszisztensek mögött is, akik már régóta nem úgy működnek, hogy megértik amit mondani akarsz nekik, hanem egyszerűen a saját végtelenségig analizált és folyamatosan bővülő adathalmazuk alapján levonják a leglogikusabb következtetést arra, hogy vajon mit is akartál nekik mondani. Minél több adattal dolgoznak, annál pontosabb napról napra ezen rendszerek találati aránya. Ma még talán csak a naptárad karbantartását bízod rá egy big data alapú neutrális hálózatra (pl. Siri/iOS), de néhány év múlva már ugyanezek a technológiák fogják vezeti az autódat.

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *