Passzív irodaház, megtapasztalva…

Az elmúlt években volt szerencsém nagyon sok ‘green’ filozófiában megihletett irodaházban járni, sőt büszke vagyok arra, hogy én is egy olyan irodaházban dolgozhatom, aminek a kialakítása során arra ügyeltek, hogy az irodaház alapterületével azonos mennyiségű zöld felületet alakítsanak ki az épületen belül, ezzel persze “hasznos irodaterületet” vesztettek el, de mégis egy sokkal élhetőbb környezetet varázsoltak, hiszen még az irodaház belső tereiben is van lehetőség az ablakokon kinézve gondos munkával ápolt kerteket látni. Na ezt az élményt sikerült a múlt heti brüsszeli látogatásom során überelni, amiről gondoltam írnék azért néhány gondolatot, csak hogy ne merüljön fel bárkiben is, hogy a nagy Elasticsearch és big data kalandozásom során megfeledkezem az ökolábnyom témakörről…

Folytatás…

Big Data: Hadoop vs Elasticsearch, mond Te mit választanál?

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.

Folytatás…

Kijött az ES 5.3 és végre a top hits!!!

Kicsit bealudtam a post megírása kapcsán, de a hetem léggé sűrű volt. Volt szerencsém a héten Brüsszelbe utazni ahol többek között megnézhettem az egyik legnagyobb kereskedelmi (nem social!) bigdata kezdeményezést, amiről nyilván semmit nem beszélhetek, de eléggé lenyűgöző dolgokat hoztak össze… (ja és persze elasticsearch és hdfs alapokon). Szóval az utazás és az amúgy is sűrű munkanapok miatt csak lassan volt lehetőségem reagálni arra, hogy kijött az 5.3-as stabil főverzió az Elasticseachből és végre hivatalosan is implementálták mind az ES-ben, mind pedig Kibanában a “top hit” aggregációt. Ráadásul mindjárt elég komoly finomhangolásokkal együtt tették ezt. Közel már fél éve várom, hogy ez a feature megjelenjen az ES főveziójában is, eddig csak nagyon komoly hackeléssel lehetett beleerőszakolni a githubon fellelhető projektet. Amúgy ezúton is külön köszi a top hits értelmi szerzőjének “scampi”-nak. A tisztelére és a munkássága elismeréseként az imént említett Brüsszeli utazásomon életemben először megkóstoltam egy scampi (rákocska) alapú kaját. Jelentem túléltem. Nézzük az alap problémát:
Folytatás…

Zero downtime in ELK (Elasticsearch) environment

Nem visz rá a lélek, hogy ez a címet magyarul akarjam leírni… De miért is érdekes a zero downtime egy NoSQL megoldás kapcsán. A héten került megrendezésre a HOUG nevű szakmai konferencia Siófokon, ami a hazai Oracle felhasználók éves nagy konferenciája, ahol megannyi sales fókuszú előadás mellett bőven akadt szakmai előadás is, melyek egy része bőségesen adott gondolkodnivalót nekem is. Az egyik előadáson lőttem az alábbi ábrát (remélem nem kövez meg senki amiért nyúlom…):

Folytatás…

Hogyan joinoljunk Elasticsearchben?

Oké, ennyire hülye címet is már régen adtam bármilyen postnak. De lássuk csak, hogy miről is akar ez szólni. Ugye a JOIN egy közkedvelt eszköze a relációs (RDBMS) adatbáziskezelőknek, ami pont az a tulajdonságot használja ki, hogy az adatbázis relációs és annak tartalma normalizált ÉS feltételezhetően vannak benne relációk. Ezen relációk adják az RDBMS rendszerek valódi lépéselőnyét a saját pályájukon. A JOIN lényege az, hogy egy vagy több tábla között létrehozunk logikai kapcsolatot és ezen kapcsolatokon keresztül bonyolult lekéréseket tudunk létrehozni. (vagy éppen ki tudjuk nyírni az egész RDBMS-t egy gyönyörű kaszkád szorzással…)
Namost az Elasticsearch az sem nem RDBMS, sem nincsennek benne reálciók (óóó, dehogy nincs… lásd a cikk végén a parent/child relációt…) és úgy egyébként a JOIN-nak sincs semmi értelme benne. Miért is nincs értelme a JOIN-nak? Az Elasticsearch (és igaz ez a legtöbb key=value alapú NoSQL motorra) pont arra az elvre épül fel, hogy minden egyes dokumentum önálló elem melyek önmagukban értemezhetők és esetleg valamilyen statisztikai elemzést vagy aggregációt akarhatunk rajta végrehajta. Mivel erre van optimalizálva az egész motor, ezért semmi értelme az olyan relációs adatmodellnek, ahol egy indexben tárolunk mondjuk dokumentumokat és felhasználói ID-kat, egy másik indexben pedig tárolunk a felhasználói ID-khoz tartozó neveket és egyéb adatokat. Sokkal egyszerűbb minden releváns adatot minden dokumentum esetén tárolni, hiszen a háttérben a NoSQL motor gondoskodik arról, hogy ezek az adatok ne redundánsan tárolódjanak. Ráadásul az ilyen erőltetett kereszthivatkozások csak lassítják is a keresési performanciát.
Folytatás…

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á.
Folytatás…

ELK: Több Elasticsearch [ES] node futtatása egy hoston

Aki ismeri az Elasticsearch [ES] filozófiáját, az pontosan tudja, hogy alap esetben semmi érteme nincs annak, hogy egy hoston több nodeot futtassunk, hiszen mi is az ES esszenciája: Végy egy halom középkategóriás, olcsón fenntartható gépet, majd minden különösebb technológiai tudás nélkül rakd fel rájuk az ES-t, kapcsold öket egy clusterbe és jöhet a fun. Ha pedig mégsem jön, mert ez így nem elég hatékony, akkor optimalizáld a shardok eloszlását, rakj hozzá a clusterhez még néhány gépet és ezen egyszerű eszközökkel lényegében bármikor tudod skálázni a clustert.

Azonban nagyvállalati környezetben előfordul, hogy középkategóriás olcsó gépek helyett komolyabb vasak kerülnek a kijelölésre. Ilyenkor meg kell tudni találni az ésszerű középutat. Egy önálló ES node kapcsán van néhány olyan technikai függőség, ami meghatározza, hogy maximum mennyi erőforrást tud optimálisan használni. Ezen függőségek közül a leginkább fontos talán a heap size:

  • Az elasticsearch technológiailag java virtuális gépben fut, aminek a heap kezelése erősen kihathat az ES működésére. Technológiai adottság, hogy 32Gb heap size alatt a JVM compressed object pointer (compressed oops) technológiát használ a heap kezelésére, ez felett már nem lehet használni ezt az opciót, ami jelentősen rontja a JVM hatékonyságát.

Folytatás…

Szakdolgozathoz segítség…

Sziasztok. Készülő szakdolgozatomhoz kérném segítségeteket. A szakdolgozat témája mi más is lehetne mint: “Befektetési alapok elemzése, vizualizálása egyszerűsített döntéselőkészítés céljából”
Ha van 5-10 perced és segítenél a kérdőív kitöltésével, akkor ezt itt teheted meg:
https://goo.gl/forms/zZvNUvQrBu6UvGMi1

Támogató kérdőív a “Befektetési alapok elemzése, vizualizálása egyszerűsített döntéselőkészítés céljából” szakdolgozathoz. A kérdőív kitöltésével abban tud segíteni, hogy a szakdolgozat minél pontosabb képet mutasson a lehetséges eszközökről és azok használhatóságáról. A Kérdőív teljesen anoním, annak kitöltése semmilyen módon nem kapcsolható a kitöltő személyéhez! A kérdőivnek nem célja, hogy “túrkáljon” a kitöltő zsebében, egyetlen kérdés sem tartalmaz konkrét pénzösszegekkel, fizetéssel, vagyonnal kapcsolatos kérdéseket. A kérdőív kitöltése nagyjából 5-10 percet vesz igénybe.

A segítséget előre is köszönöm,

Ébredező funkcionalitás

Jelezném, hogy A K&H alapkezelő folyamatos adatfrissítése mellett néhány egyéb fukciót is működésre bírtam. Ennek fő oka, hogy beindult a szakdolgozat készítésem aminek témája: “BEFEKTETÉSI ALAPOK ELEMZÉSE, VIZUALIZÁLÁSA EGYSZERŰSÍTETT DÖNTÉSELŐKÉSZÍTÉS CÉLJÁBÓL”. Ennek apropóján újra működnek a következő alapkezelők folyamatos frissítése és bepótlásra került az eddigi adatfrissítés is: OTP, ERSTE, CONCORDE. Terveim szerint megpróbálom feléleszteni még a METLIFE és az UNIQUA alapokat frissítő modulokat is, de ezek lényegesen másabb alapokon nyugszanak. Ezzel párhuzamosan egyéb munkálatok is folyamatban vannak. Remélhetőleg hamarosan újra közel teljes funkcionalitással fog működni az összes korábbi modul.

Nagy rápihenés, karbantartás és új alapkezelő

Rég volt már, hogy életjelet adtam. Volt némi kis kanyar az életemben, ami miatt nem tudtam idekoncentrálni. Ez utóbbi nyilván fenn áll még, úgyhogy a helyzet ezen a téren nem sokat fog változni egyhamar. A BTC bizniszben vegetatív módon még mindig benne vagyok, bár a folyamatosan zuhanó árfolyamok miatt nem őszinte az öröm az arcomon. Előző hét péntekkel sikerült átmigrálni a teljes szervert (amin az oldal is fut) egy lényegesen költséghatékonyabb környezetbe, ennek kapcsán némi fennakadások történtek, de ezeket már orvosoltam. Elvileg semmilyen adat nem veszett el, ha mégis akkor majd pótlom. Ha már hozzányúltam akkor viszont beraktam egy új alapkezelőt is a QUANTIS személyében. Nyilván azért, mert tervezek vele a jövőben alaposabban foglalkozni. A háttere, multja, stb. nem érdekel, csak az eredményei (még mielőtt valaki elkezdené boncolgatni azt.)