Egyre többen osztják azt a nézetet, miszerint korunk legmenőbb szakmája az adattudós (data scientist). Nem kisebb nevű kiadványban jelent meg hasonló megállapítás, mint a Harvard Business Review. Egész Európában, sőt világszerte forrongó témáról van szó, ugyanis a big data folyamatos emlegetése még nem jelenti azt, hogy a fejekben rend van, és mindenki pontosan tudja, hogy mire és miképpen használhatja fel a rendelkezésére álló, állandóan növekvő hatalmas adatmennyiséget. Egyáltalán mit is takar az adattudós szakma? Mihez kell érteniük az adattudósoknak, mit vár, várhat el tőlük a piac, illetve vannak-e megfelelő számban, és ha igen, honnan kerülnek ki ezek a szakemberek?
Volker Markl, a Berlini Műszaki Egyetem professzora szerint az adattudósnak három, egymást átfedő területen kell otthonosan mozognia. Először is értenie kell a gépi tanulási, statisztikai, adatelemzési módszerekhez. Másodszor komoly adatkezelési tudással kell rendelkeznie. Olyan hatalmas mennyiségű adatokkal kell ugyanis dolgoznia, amelyeknél a hagyományos adatbázis-kezelők már nem alkalmazhatók. Mindezen túlmenően az adattudósnak értenie kell ahhoz az alkalmazási területhez, ahol a tudományát beveti. Megfelelő ismeretekkel kell tehát rendelkeznie a távközlési, a pénzügyi, a marketing, a közlekedési, az egészségügyi stb. szektorról.
Ezen elvárások egyben azt is mutatják, hogy az adattudós iránti igények jócskán eltérnek a diplomásokkal szemben támasztott általános, „T” alakkal leírható igényektől. Egy egyetemet végzett szakembertől jellemzően azt várják el, hogy sok területről legyen átfogó tudása (a T kalapja), és egy bizonyos területre ássa bele magát mélyebben (a T szára). Ezzel szemben az adattudós ismeretei legyenek „Π” alakúak. A mély, speciális informatikai tudás mellett mindig ott kell lennie a másik lábnak, az alkalmazás beható ismeretének.
Képzési gondok
„Ebből a bizonyos Π alakú elvárásból következik, hogy nagyon nehéz adattudósokat képezni. Az egyetem megadhatja a gépi tanulási, adatkezelési, tehát informatikai ágat. De valahol meg kell szerezni az adatelemzéshez szükséges területspecifikus tudást is, ami nem is olyan egyszerű feladat. Ráadásul ez utóbbi olyannyira szektorfüggő, hogy az egyik területen megszerzett ismeretek nem feltétlenül hasznosíthatóak más területen. Az is az igazsághoz tartozik, hogy napjainkban az adattudóssághoz elengedhetetlen informatikai tudás megalapozása az egyetemi képzésben még csak gyerekcipőben jár.
Elindultak már adattudományi képzések, ám ezek egyrészt nem fedik le a teljes területet, másrészt a munkaerőpiaci igényeknél sokkal kevesebben sajátíthatják el ezeket az ismereteket. „Jelenleg a környezetemben 200 olyan álláshirdetésről tudok, amelyben adattudósokat keresnek. Ezek többsége a távközlés és a szoftver-infrastruktúra területén mozgó nagyvállalatok felhívása” – tájékoztat Benczúr András, az MTA SZTAKI Big Data Lendület Kutatócsoportjának vezetője.
Az iparban egyre többen jelzik, hogy szeretnének analitikai megoldásokat alkalmazni „big data” jellegzetességekkel. Van, ahol ez teljesen indokolt, de előfordulhat, hogy csak a divatot követik. Akár így, akár úgy, nem minden cégnél tudják pontosan, hogy mit is akarnak. Jellemző forgatókönyv, hogy egy cég megbíz egy kutatócsapatot adatai elemzésével, de a kapott eredményt nehezen tudja felhasználni üzleti folyamataiban. A cégvezetők teljesen idegenül állnak a kérdéshez, ráadásul hiányoznak a hozzáértő munkatársak is. Nagyon kellenének tehát olyan szakemberek, akik korrektül meg tudják fogalmazni az igényeket, a fejlesztésben is részt tudnak venni, majd értelmezni és prezentálni tudják a kapott eredményeket.
Rekonstruálható mérések
A SZTAKI kutatócsoportja több, részben közvetlen adatelemzési megbízást kapott, részben a megrendelővel közös kutatás-fejlesztési projektben vett részt. Egyértelmű tapasztalatuk, hogy egy ilyen fejlesztésnek be kell épülnie a cég belső struktúrájába. Hiába adják kézbe a működő prototípust, ha a folyamatos üzemeltetéshez hiányzik a megfelelő szakértelem.
Jó irányt jelez, amikor egy cég megérti és reprodukálja a kutatási eredményeket. Például egy francia startup végül nem a SZTAKI kutatói prototípusát termékesítette, de megértette a lényegét, majd a tapasztalatok alapján ki tudta fejleszteni saját adatelemző szoftverét. A kutatók ezzel elérték céljukat: sikerült megtanítaniuk az adattudományra a vállalatot.
Benczúr András szerint a megbízóval akkor jó az együttműködés, ha a fejlesztők azokkal állnak kapcsolatban, akik ténylegesen az adatokkal dolgoznak. Természetesen a felsővezetésnek támogatnia kell a tevékenységet, de a kooperációnak a tényleges munkavégzés szintjén kell létrejönnie.
„Fontos tudnivaló, hogy az adattudós nem döntést hoz, hanem támogatja a döntéshozót. Ezért nagyon fontos, hogy eredményeit helyesen tudják értelmezni. Az adattudományban számomra az a vonzó, hogy általában rekonstruálható méréseket végzünk. Tipikus módszer az AB-teszt, amikor a felhasználók A csoportja a jelenlegi szolgáltatást kapja, B csoportja az újat, és az eredményesség mérése alapján levonjuk a megfelelő következtetéseket. A pénzügyi döntéseknél, például egy tőzsdei befektetésnél ez nem így működik. A döntéshez valamilyen matematikai statisztikai módszert alkalmaznak, de a lépés jellemzően nem ismételhető meg más paraméterek, feltételezések mellett. A pénzügyi rendszer ugyanis nagyon nyitott, rengeteg a külső befolyás” – fogalmaz Benczúr András.
Nem mindenre jó a Hadoop
Mivel az adattudós jellemzően ömlesztve kapja az óriási adatmennyiséget, többféle nehézséggel találja magát szemben. Először is gyakori, hogy az adatok hatalmas sebességgel özönlenek (például a távközlésben, a közlekedésben). Gyakran azonnal reagálni is kell a pillanatnyi helyzetre, miközben hosszabb távú méréseken alapuló modelleket kell építeni. Ezt a feladatot, tehát a valósidejűség és a hosszabb távú működés modellezését nagyon komplex szoftverekkel lehet csak megvalósítani.
A következő nehézség, hogy az adatok jellemzően zajosak, heterogének. Ezeket meg kell tisztítani, hogy az így születő adatokból már jó minőségű analitikát lehessen létrehozni. További probléma az analitika minősége, a megfelelő modellező eszközök kiválasztása. Szintén nehézség rejlik e rendszerek fejlesztésében, amelyek tipikusan nem az analitikai cél tömör megfogalmazását, hanem nagyszámú, a végcél szempontjából lényegtelen, a szerverfarm működését leíró kódok elkészítését igénylik. A legelterjedtebb analitikai rendszer a Hadoop. Kialakulása még a big data fogalom megjelenése előtti időre tehető. Magát az architektúrát eredetileg a Google-nál a keresési index felépítésére találták ki, majd nagyrészt a Yahoo támogatásával jött belőle létre egy nyílt forráskódú analitikai eszköz.
„Sajnos mostanság mindent Hadooppal akarnak megoldani, ami bizonyos esetekben teljesen reménytelen. Szerencsére azonban nagyon sok egyéb, más és más célra kitalált rendszer közül lehet választani, amelyek között sok a nyílt forráskódú. Inkább az a probléma, hogy túl nagy a kínálat, így nehéz a választás” – mutat rá Benczúr András.
A SZTAKI kutatói – a Berlini Műszaki Egyetemmel együttműködésben – az Apache Flink projektje mellett tették le a voksukat. Többek tapasztalata szerint e rendszer a big data téma európai jolly jokere. Mivel a Flink nem az első szoftverek egyike, tervezésekor megpróbálták kiküszöbölni a korábbi rendszerek negatívumait. Így olyan szoftver jött létre, amely képes valós időben is válaszolni a hatalmas adatmennyiségre, jó minőségű analitikát képez, ugyanakkor hozzáférhető a fejlesztők számára. Olyan rendszer, amelyben az egyszerű dolgokat 3-4 sorral le lehet írni, miközben Hadoopban ugyanez a dolog csak 2 képernyőoldalnyi kóddal fejezhető ki.
Adatbázis-tisztítás és előrejelzés
Sidló Csaba, a SZTAKI kutatócsoportjának tagja több olyan jellegű projektben vett részt, ahol a megbízó cég sokéves működése alatt összegyűlt nagyméretű ügyféladatbázist kellett megtisztítani és analizálni. Az ilyen adatbázisokban az elírásokon és egyéb közvetlen hibán kívül is sokféle minőségi problémával szembesülhetünk, sok ügyfél több példányban szerepelhet, vannak, akiknek időközben megváltozott a nevük, lakcímük stb.
A kutatócsoport a megtisztított adatra épülő különféle előrejelzési projektekben is részt vett, például olyan szoftvert készített, amely az egyes tranzakciók idősorai alapján szolgáltatásminőségi problémákat jósol meg. E rendszernek valós időben kell reagálnia például akkor, amikor egy aktív folyamat történései valamilyen minőségi problémát jeleznek.
