Üzleti Intelligencia Hírek, újdonságok és tesztek az üzleti intelligencia és az adattárházak világából

Az SAP új üdvöskéje: HANA

Az SAP Májusban jelentette be a SAPPHIRE rendezvény keretein belül a HANA (High-Performance Analytic Appliance) kódnévre hallgató új termékét, ami a saját fejlesztésű BAE (Business Analytic Engine ) szoftver és bizonyos hardver gyártók szervereinek boldog frigyéből született appliance típusú gépállat. A Hana, ami egy titkos ICE (mert In-memory Computing Engine állnéven is hivatkoznak rá), egyébként egy arab eredetű női név, jelentései: boldogság, virág, munka. Vajon melyikre asszociálhattak az SAP marketing osztályán a névadáskor?

Ha valakinek nem egyértelmű, melyik SAP termék mit reprezentál, illetve milyen pozíciót foglal el az adatbázis / adattárház motorok hall-of-fame –jében, akkor az most erősen koncentráljon, mert történelmi pontatlanságokkal átszőtt áttekintő ámokfutásom következik:
Az SAP-ról (értsünk SAP alatt céget és termékeket is) köztudott, hogy nem foglalkozik az alacsony szintű technológiákkal, nincs neki hw üzletága, nem érdeklik az operációs rendszerek és még megvető pillantásra sem méltat semmit, ami nem legalább német szavak 4 betűs rövidítéseivel megjelölt logikai entitás egy nagyvállalat üzleti folyamatainak informatikai reprezentációjában.
A fenti kijelentés, mint a legtöbb általánosítás (kivételek ezalól Micimackó és Krisztofóró lovag aranyköpései) kis részben igaz, nagy részben meg ordas marhaság.
Koncentráljunk most csak a SAP adattárház rétegére, a BW-re. A BW ugye egy olyan ROLAP megoldás, ami idáig jellemzően nem SAP logós relációs adatbázisokat használt az OLAP kockák fizikai tárolására.
Ennek megfelelően vannak, voltak(?) neki performancia gondjai: nem túl optimalizált (értsd: általános célú) adatbázist használ adattárház célokra, ráadásul a lekérdező felületet (akár BusinessObjects, akár a hagyományos SAP BI) sok logikai réteggel el van szeparálva az adatbázis rétegtől – már hallomás után gyanakodhatunk, hogy az adatmennyiségek növekedésével a BW komoly kihívások előtt állhat.
Például ezekre a kihívásokra válaszul ugorhatott fejest az SAP a saját adatbázis motor fejlesztésébe.

Első lépésként csináltak egy un. Turbó gombot a BW-hez, ez lett a BW Accelerated verzió. Röviden, ez nem más, mint egy az adatkockákat egy a BW szempontjából külső hardveren, annak is főleg a memóriájában lekérdezésre optimalizált (oszlop alapú, tömörített, partícionált) formában eltároló appliance, ami képes a BW-nek címzett lekérdezéseket jó osztálytárs módjára puskából lesúgni, a tanár (lekérdező felhasználó) meg beírja az ötöst.
Ez még önmagában ugye nem adatbázis, BW nélkül eldől, mint rosszul letámasztott féldisznó a hűtőházban.
Második lépésként a SAP fajta nemesítő szakemberek összeházasították az Acceleratort a BO ETL megoldásával (data integrator), illetve az Explorer riportoló eszközzel. Itt már képesek lettünk az Accelerator-ba nem SAP adatot is belegyömöszölni a BO DI-val, illetve azt megjeleníteni is Explorerrel, de azért vegyük észre, ez a megoldás is csak egy szűk szegmens igényeit elégíti ki.
A harmadik lépés pedig már el-teleportált minket a jelenbe: az Accelerator technológiáját felhasználva az SAP kifejlesztett (legalábbis a marketing anyagok szerint) egy igazi, nagybetűs ADATBÁZIST, ezt nevezik hol BAE-nek, máshol ICE-nek. Van benne minden, ami piszkálja Földi kolléga noSQL rendszereken kérgesedett csőrét: ANSI SQL támogatás, ACID működés. Sajnos nem sikerült információt szereznem arról, milyen technológiát fölhasználva ugrotta meg ezt a SAP, állítólag teljesen saját erőből sikerült megvalósítania. Ami már csak azért is furcsa, mert napjaink minden viszonylag új adatbázis kezelője, amelyik ANSI és ACID párttagkönyvvel rendelkezik, valamilyen opensource adatbázis-kezelőt (MySQL, PostgreSQL) használ alapnak (a noSQL adatbázisok meg tojnak ezekre a szabványokra, inkább gyorsak és hibatűrők akarnak lenni, mint szabványosak). Feltételezem, hogy őrült nagy munka és pénz lehet nulláról kifejleszteni egy ilyet, nem is tűnik túl racionális döntésnek. A relációs képességek mellett az adatbázis képes MDX lekérdezések kiszolgálására (azaz OLAP kockák is készíthetőek benne).
Ha ez mind igaz, és működik is, isten bizony soha többé nem mondok rosszat a német mérnökökre és indiai fejlesztőkre. Csak ne csináljanak több bort a németek meg musical-t az indiaiak, és minden rendben lesz. Ha működik…

Az SAP még gyorsan leboltolta a nagyobb, nem Oracle-nek hívott hardvergyártókkal, hogy árusítsák a BAE-t a gépeiken, na ezeket hívhatjuk HANA-nak. Comprende?

A Hana felhasználási céljairól is sokmindent lehet olvasni azon a bizonyos interneten:
• Állítólag az SAP ERP rendszert is lehet majd ezen futtatni.
• Nem váltja ki a BW logikai rétegeit (a BW továbbra is az SAP ERP hivatalos adattárház rétege lesz).
• De a BW-t is lehet majd rajta futtatni (BW állandóan benyomott turbó gombbal).
• Átemelték bele a Sybase Replication Server technológiát, amivel pl a SAP ERP és CRM rendszerek (és gondolom más tranzakciós rendszerek) adatai az alap rendszerek különösebb terhelése nélkül - real time-hoz közeli módon lekérdezhetőek, elemezhetővé vállnak.
• Ez kombinálható a BO DI batch adattöltéseivel, transzformációs képességeivel.
• Rá lehet ültetni a BO riportoló és analítikus eszközöket, hogy csak úgy ugráljanak a flash-es riportok, meg a fúrogatós OLAP elemzések.
• Az SAP már arról beszél, hogy Hana-t az Oracle Exadata ellenfelének szánja. A szándék nemes, ugyanakkor nem láttam leírva, hogy milyen nem BO ETL és BI eszközökkel fog Hana együttműködni. Ha valóban standard ANSI SQL felületet nyújt, akkor gondolom hamarosan sok gyártó certifikáltatja a termékeit az SAP-nál erre a platformra.
• Állítólag lesz Hana-ból kis, közepes, meg ordenáré nagy verzió, hogy mindenkinek költséghatékony megoldás legyen. Olvastam célzásokat csökkenő TCO-ra, de az alacsony ár – SAP termék kontextusban szerintem csak a KKV-knak szánt csomagok nem képeznek 0 elemű halmazt. Bár az Exadata / Teradata / Sybase stb appliance-k sem az olcsóságukról híresek, szóval mihez képest költséghatékony?

Azért van pár megválaszolatlan kérdés:
• Mi a répának vette meg a SAP a Sybase-t, ha már vadul dolgozott közben a saját adatbázis platformján? A járulékos termékek (Mobile platform, Replication Server, stb) azért nem érnek sokcsilliárd dollárt…
• Milyen árazási politikát választ a SAP, hogy elterjedjen a Hana? A gyilkos árversenyt egyszerűen nehezen feltételezem a SAP-ról, és ha már valaki ráveszi magát, hogy platformot váltson (vezessen be), miért ne tegye azt egy olcsó technológiával (Infobright, Greenplum, stb)?
• Ha meg kockázat kerülő valaki, akkor miért ne választaná a már bizonyított Teradata, Sybase, Oracle technológiákat?

További infók: itt, itt, meg itt, és persze az SAP oldalakon.

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.