Machine Learning (ML) II. fejezet – lineáris regresszió

Ez a cikk egy több fejezetes gépi tanulásról szóló cikksorozat második fejezet. A jelenleg elérhető fejezetek:

  1. Machine Learning (ML) I. fejezet – ismerkedés az alapokkal

Miután az alapokkal megismerkedtünk ideje belecsapni a lecsóba. A Machine Learning (ML) egyik leggyakrabban használt és legszélesebb körben ismert interpretációja a regresszió és annak alternatívái közül is a lineáris regresszió. Sokan ezen szó hallatán gyomorgörcsöt kaphatnak és rémálomként idézhetik fel az egyetemi mat/gazd. stat. élményeiket. Igen, ez ugyanaz a regresszió, amiről ott is tanultatok.

Azon olvasóknak akiknek vagy már megkopott ez a tudása, vagy nem is tűnik számukra ismerősnek ez, azoknak egy kis gyorstalpaló:

Folytatás…

Machine Learning (ML) I. fejezet – ismerkedés az alapokkal –

Ez a cikk egy több fejezetes gépi tanulásról szóló cikksorozat első fejezet. A jelenleg elérhető fejezetek:

  1. Machine Learning (ML) I. fejezet – ismerkedés az alapokkal
  2. Machine Learning (ML) II. fejezet – lineáris regresszió

Sokszor hallottam, olvastam már, hogy a Machine Learning (ML), magyarul: Gépi tanulás, lényegében egy olyan szintje az informatikának és az adatelemzésnek, amely már sokkal inkább tudományos tapasztalatokat igényel, mintsem programozói ismereteket. Sok esetben valamiféle mesterséges intelligenciának tekintik a ML-t (nem alaptalanul), amely abból a szempontból igaz is lehet, hogy a hétköznapi életben ismert és használt gépi tanuláson alapuló megoldások (pl. beszédfelismerés, képeken arcfelismerés, stb.) valóban mesterséges intelligenciára és gépi tanulásra épülne. Ettől függetlenül a gépi tanulás egyébként közel sem annyira nagy ördöngösség ami miatt tudományos fokozat kellene a megértéséhez és használatához.

Folytatás…

Hybrid + Napelem: Tapasztalatok 4 év után

A blog minden bizonnyal egyik leginkább keresett bejegyzése a mai napig a hasonló címmel megjelent írásom ami 10 hónap fényében mutatta be a korábbi saját beruházásból megvalósított fűtés korszerűsítést, mely során a fűtést un. hybrid gázkazán és levegős hőszívattyús rendszerrel oldottam meg, amihez az áramot napelemmel termelem. A konstrukció részleteit az eredeti cikkben fejtettem ki.

A cikkben az első 10 hónapos eredmények alapján azt prognosztizáltam, hogy a korábbi fűtési rendszerhez képest évi 669ezer forintos megtakarítást tudok elérni, amivel alig 4,5 év alatt pozitívba fog tudni fordulni a beruházás. Most, hogy lassan véget és a negyedik fűtési szezon is (bár ennek némileg ellent mond az időjárás) itt az ideje, hogy visszamérésre kerüljön a prognózis.

Folytatás…

Timeseries vizualizáció: Kibana Timelion

Jelenlegi post még a timelion funkcionalitására épül, azonban itt jegyezném meg, hogy az 5.4-es főverzió kapcsán kiadott közlemény alapján ezek a funkciók (vagy legalábbis nagy részük) már elérhető lesz közvetlenül a beépített Kibana vizualizációs eszközökkel is. Addig is amíg nem kerül kiadásra az 5.4, viszont marad a timelion. A timelion eredetileg egy függetlenül fejlesztett Kibana plugin volt, ami az 5.0-ás főverziótól kezdődően beépült az alap Kibana funkciók közül (a Sense pluginnal együtt).

A timelion talán legfontosabb funkciója az összehasonlítható és vizuálisan részletgazdagabb chartok képessége. Mindemellett a timelionban készített vizualizációk minden gond nélkül rárakhatók tetszőleges dashboardra vegyesen akármilyen más Kibanás vizualizációval együtt.

Folytatás…

Elasticsearch Index és a performancia

Az Elasticsearch alapértelmezetten nem spórol az indexekben tárolt dokumentumok kapcsán az erőforrásokkal. Ha az adott index nem rendelkezik egy jól felépített és átgondolt mappinggel, akkor az ES gyakorlatilag “szabadfolyást” tart, minden szöveges típust analizál, minden olyan adatot ami rendezhető vagy aggregálható azt inmemory bufferbe lapoz, ráadásul menedzsel egy csomó olyan virtuális fieldet is mint pl az: _all.

Ezzel az ES egy végtelen rugalmasságot és könnyed felhasználást teszt lehetővé, ami a legtöbb projekt esetén egyébként nagyon pozitívan értékelhető hozzáadott érték. Azonban ennek megvan az ára, ez pedig a performancia. Egy tetszőleges ES installment esetén elmondható, hogy néhány millió dokumentumig nem nagyon kell foglalkozni a mappingekkel, hiszen itt még bőven érvényesül az a fajta distributed processing hozzáállás, hogy ha kezd lassulni az indexelés vagy a keresés, akkor bővíteni kell a clustert egy-két extra node-dal (már persze ha az index shard beállításainál ügyeltünk arra, hogy ennek legyen értelme…) és máris normalizálódik a performancia.

Folytatás…

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…