A magyar gyökerű VirtDB laudációja

.
Bevezetés, motivációk

Azon szerencsések egyike vagyok a magyarországi informatikusok között, akinek volt lehetősége találkozni az adatvirtualizációval, elméleti szinten is és gyakorlatban konkrét eszközhasználat - VirtDB szintjén is.

A világ informatikájának egyik hajtómotorja, hogy user-igényeket próbálnak meg szoftvergyártók implementálni, "pull"-alapon. Ezek aztán előbb-utóbb kitermelik a maguk vadhajtásait, például gyászos véget ért "gemkapcsos" Microsoft Office Assistant. Én kétféle emberrel találkoztam csak eddig pályafutásomban: (1) aki eleve fel sem rakta, illetve (2) aki szerette volna uninstallni. :)

Az adatvirtualizáció az a topik, amit a szoftvergyártók "találtak ki" "push"-útra terelve a témát (ennek minden előnyével és hátrányával), nem egy, nem kettő van a piacon belőlük és jellemzően eladni akarják őket (nem a vásárlók kopogtatnak az ajtajukon, hogy megvehessék). Aminek egyik oka, azt gondolom, hogy komoly informatikai - horribile dictu architect-szintű - szaktudás kell a topik tárgyilagos és pontos mérlegeléséhez, amivel a gazdasági döntéshozók ritkán rendelkeznek.

És máris megkaptuk a 22-es csapdáját. Hiszen, ha már lenne kritikus tömegű eladás az ilyen termékekből, akkor könnyen tudhatna sikersztori lenni maga a szaktopik (vagy éppen ellenkezőleg kudarc esetén más fontosabb fejlődési irányokba lendülni az ügyfélkiszolgálás), de amíg ez a kritikus tömeg nincs, addig exponenciálisan nehéz feladatnak látszik a kritikus tömeg elérése, ha hiányzik az ügyfél-szállító párbeszéd.

A 22-es csapdájának motívumai

Csak a felhasználók tudnák validálni (vagy éppen elvetni) a topikot, de korlátaik (pl.:időhiány) alapvető inicializáló gátja a valamilyen kimenetű kifutásnak. Viszont azt a célraorientált szakmai diskurzust nem lehet lefolytatni, ahol a beszélgető partnerek hallgatnak.
* Túl sok jó(?) termék van a piacon, sokszor (részben és/vagy átfedően/redundánsan) használható is: így aztán sokszor nincs (vagy elhal a) motiváció, új szemléletre váltásra.
* Vállalatoknak éppen elégnek látszik a verzió-upgradeknek is megfelelni, amiben az informatika tudomány/gyakorlata is sokszor bűnös lássuk be.
* Az adatvirtualizáció nem akadémikus/teoretikus tudomány, nincsen, például adatbányászatban megszokott, cikkáradat, nem implikál phd-téziseket. Hanem ellenkezőleg kifejezetten üzleti implikációjú ezért nehezen matematizálható, ugyanakkor jól behatárolható viszonylag szűk szakterület.
* A sales-e meg azért tudhat nehéz lenni adatvirtualizáció témában, mert a viagra-típusú spameléstől a minőségileg ügyfélorientált sales-ig nagyon széles a megtapasztalható skála.
* Az adatvirtualizáció meg nem az a kimondott egybites viagra-értékelést generálja, hanem pont a skála másik végén az alaposabb, időigényesebb ad absurdum konzultációs-alapú végiggondolást igényli.
* Ha analógiát akarnék hozni, ha valaki egy szoftvereszközt akarna megtanulni használni (aka "vállalati folyamatok javítása"), de még a kérdezés is problémába ütközik alapvető információk hiányában.
* A tárgybeli VirtDB-nek, minden eladása mellett is, meg kell küzdenie evvel a démonával.

Mi is az adatvirtualizáció? 

* Ha egy mondatban akarnám megfogalmazni: heterogén környezetben létező adatbázisok virtuális (majd később opcionálisan és teljesen vagy részlegesen materializált) homogenizálási célzatú mountolása egy (vagy több, ámde azonban ellenben viszont legacy adatbázisoknál nagyságrendileg kevesebb) host adatbázisba.
* Egészen konkrétan fogalmazva milyen jópofa tudhat lenni mondjuk egy olyan SQL-fannak mint nekem pl.: Oracle-típusú SQL-t kiadni akár egy NoSql adatbázisra, vagy SAP-ERP, SAP-BW-re (minimális overhead mellett, 100%-ban adatbázisrétegben maradva).

Miért jó az adatvirtualizáció, miért hot topic, ki a célközönség?

1. Vízválasztó: vállalati adatvagyon "big data" mérete és/vagy komplexitása
 
Az egyik jelentős (konkurens) irány, a lambda architektúra. Ez tudomásul veszi, hogy exponenciálisan bővül az adatok tömege (extenzíven és intenzíven egyaránt). Esély nincs a régi módszertanok alapján pénzt nagy tömegben hozó információkat kiaknázni, elsősorban az idő hiányában. A sokféle feldolgozást, sőt még ezek megtervezését is, feladatspecifikusan ennek a ténynek rendeli alá. Az irányzat egyik nagy fájdalma, hogy könnyű káoszba-fulladni, ösvényt téveszteni, nagyon nehéz koherens változás-kezelést implementálni benne. A rugalmassága nagy és adott esetben nem feltétlen jól/könnyen felodható vitákat eredményezhet.

Egy másik, sokkal emberközelibb irányzat (szóbanforgó adatvirtualizáció), teljességgel eliminálni akarja a káoszt, az egyszerűségben, tiszta elvekben, gyakorlatban hisz. Ha már az élet úgy hozta, hogy heterogén legacy rdbms-instance-unk sokasága van, akkor legalább operatív és analitikus/batch üzleti analitikánk szintjén legyen (még ha csak virtuálizáltan is) homogén az adatbázisunk.

2. Vízválasztó: "big data" méretével és/vagy komplexitásával lineárisan vagy progresszíven skálázódik a data science iránti vállalati igény.

Egy szenzoros stream miningos projektben úgy nőhetnek rapid módon a feldolgozást igénylő adatok, hogy a projekt kiált a lambda architektúra után, viszont az adatbányászati aspektust tekintve már nem ekkora horderejű a terület, pontosan a jó behatároltsága miatt.

Egy másik vállalatnál lehet n darab legacy rdbms-instance, ad absurdum n darab különböző technológiai platformon, például részleges vagy teljes lokál specifikummal fűszerezett ERP-funkcionalitással. A feladat méretben lehet elég jól behatárolható, miközben az üzleti intelligencia megfelelő kipréselése felfelé skálázandóan több self-bi-ban erős analitikus egyént igényel. Itt egy adatvirtualizáció jobban tudhat tért követelni magának alternatívaként, hiszen active directory-s jellegű fában lehet hasznos látni a legacy erp-ket, az információkikristályosítási folyamat alapköveként.

Idevágóan egyfajta konklúzió

* Heterogén rdbms-instance-ok integrációjának rengeteg technikája van a világban. Aszinkron message queue (MQ) alapútól kezdve a legkülönfélébb ETL-eszközökön át, most már kijelenthetjük az adatvirtualizációig is. Az előbbi kettőt láthatóan/érzékelhetően szereti a világ, sőt sok pénzt is áldoz rájuk (néha indokolatlanul sokat is).
* Ha megnézzük - nomen est omen - GoldenGate-t, amit az Oracle Corp akvirált, az tényleg aranyárban van. Azaz piacilag is alátámaszthatóan van rés/potenciál a témában. ;)

Az adatvirtualizáció milyen alternatívát tud nyújtani velük szemben? 

* Ár: nyilván nem nehéz a jelzett árszint alá menni, főleg, ha ezen termékek technológiailag nem indokolt extraprofitot tartalmaznak.
* Nem kell újabb minőségileg más - pl. ETL - cucc az architektúrába.
* Akinek tehát fontos az informatikai jellegű erőforrásainak hatékonyabb koncentrálása a információ-kiaknázás útján, kerülve a felesleges overheadeket, erőforrás-diverzifikálásokat.
* Ha szempont, hogy ne exportálódjon semmilyen üzleti logika adatbázison kívülre (ETL,MQ), változás-managementet nehezítően.
* Örökíthetők legyen a legacy-rendszerek beállított-jogosultságai.ETL ide vagy oda, vannak kényes adatok, amik ETL után sem kellenének szabadon "publikálhatók" legyenek.
* Ne legyen heterogenizálódás ETL-ben (is), pláne mint közbülső lépésben, ha már kell ilyen, akkor az üzleti intelligencia lánc végén legyen csak (minimalizálva bármilyen migrálási követelményt / komplexitást is)
* Ha axiómának fogadjuk el, hogy az SQL-nél nem találtak még jobb, explicitebb, egzaktabb, éppen még megtanulhatóbb közvetítő közeget az üzleti és informatikai leképezésekre, naprakész dokumentációk generálásához.
* Ha axiómának fogadjuk el, hogy az SQL bármennyire szimpatikus, van egy nagyon csúnya sajátossága, hogy rengeteg alapjaiban különböző nyelvjárási különbségek vannak köztük.
* Ha axióma, hogy jó csak EGYETLEN (host) metaadattárat kezelni üzleti és informatikai szinten.
* Nem csak "alulról" biztosít legjobb layert, hanem "felülről" is: hiszen a CDC-t és Batch-feldogozást korrekten tudhatja egységes felületen közvetíteni a felhasználó felé.
* Fontos a szinkronitás (minden potenciálisan fontos adat online legyen és minimalizáltan persze) . Ez mindig drágább irány ugyan, gondoljunk arra, hogy (globális) meetinget szervezni mindig fájdalmasabb, mint aszinkron módon levelet váltani. De lássuk be a szinkronitásnak is vannak felbecsülhetetlen hozzáadott értékei. Nemhogy egy MQ, de egy CDC (on demand) batch integrate is aszinkron, miközben egy (adott esetben rosszul megírt) CDC-online (gondolok itt egy HVR-ra) nagyon, értsd nagggggyon fájdalmas is tudhat lenni egy vállalat életében
* Axióma az is, hogy egy vállalat ne egy minden üzleti funkcionalitást valahogy lefedni akaró univerzális kalapáccsal akarja megoldani felmerülő (majd szöggé transzformált) feladatait. Az adatvirtualizáció feladatfelvetése azért tudhat rokonszenves lenni, mert úgy általános célú, hogy kellően jól és szűken behatárolt (ami nagyon ritka az informatikában: nem véletlen, hogy "push" és nem "pull" a termékvonal).
* Létezik optimális feladatdekomponálás, amiben egy adatvirtualizációnak nagyon szépen definiált helye tudhat lenni.Lássuk be a Tableau-t sem R-integrációja miatt szeretjük, ahogy a Tableau ezerszer szebben, gyorsabban jelenít meg komplex vizuális tartalmat, mint egy Alteryx.

Az adatvirtualizció egyik új játékosa a magyar gyökerű/startup-ú VirtDB. Amit volt szerencsém projekt keretében használni.

Mit szerettem a VirtDB-ben?

* Klasszikus fejlesztési elveken alapuló és 100%-ban ügyfél- meg feladat-orientáltan fejlesztett eszköz.Ügyfélhaszon-maximalizálással, látványos overhead-minimalizálással.
* Nincs még egy mégcsak hasonló szoftver sem amiben kevesebbet kell kattintani. Mint egérgyűlölő ennek én nagyon örültem.
*  Végtelenül könnyű és egyszerű elemi és filterezett csoportos legacy-táblák mountolása.
* Hihetetlenül produktív a használata nagy tömegű táblák "importálásánál", az említett projektben egy "nagytudású" agilis projektvezető agresszív hajcsárkodása mellett nehezen túlbecsülhető szempont volt.
* Nem kell dokumentáció az admin-gui-hoz, hiszen egyszerű, tiszta, önmagát adja az intuitiv felülete. Aki nem szereti a böngészős alkalmazásokat (mint én sem), azt is leveszi a lábáról az egyszerűsége, szépsége és hatékonysága.
* Mind felhasználói, mind adminisztrátori szemmel nagyon könnyen kezelhető volt.
* Elképesztő materializálási sebesség: 10GB, 7.2 millió rekordos legacy Oracle-tábla host Greenplum-ba, 100.000 record/sec-kel is tudhat menni (OCI-s data provider hatékonysága miatt).
* Messze legkisebb overheadet jelent a materializált mountolás is, bármilyen ETL-el szemben.
* Egyszerűsége hatalmas előny a supportnál is. Hibajelzés és hibajavítás között elképesztő rövid az átfutási idő a szoftvernél.
* Nagy öröm volt izmosabb SQL-t használni addig sql-lel nem elérhető táblákra is.
* Jogosultság-rendszer nem feltétlen duplikálandó használatával.
* Hihetetlenül elegáns a szoftver. Ami nagy meló nagy érték, azt elrejti a felhasználó elöl teljességgel. Sőt! Inkább a fejlesztésben vállal be többet költség oldalon, csak hogy minél teljesebb legyen a felhasználói élmény.
* Remek ár/teljesítmény aránya van, létezik opex/capex árszabása is a terméknek.
* Úgy általános célú a szoftver, hogy a lokálspecifikumokat szépen tudta mindig is fogadni, mindezt plusz overhead jelentkezése nélkül. Ez csak kiváló szemlélet és architect-tervezés folyamánya lehet csak.