Hirdetés
 

SAP HANA és IMDB: elérkezett a valós idejű analitika!

PDF
Nyomtatás

saphana100.jpgMostanára már bizonyára mindenki, akit foglalkoztatnak az SAP-val kapcsolatos hírek, hallott valamit a HANA-ról (High Performance Analytical Appliance).
Az első hivatalos bejelentés még tavaly decemberben volt, most júniusban pedig a GA (General Availability) ideje jött el.
De ki (vagy inkább mi) is ez a titokzatos HANA? Kezdjük egy kicsit messzebbről...

Az analitika jelenlegi helyzete

Anélkül, hogy túl sok részletbe belemennénk, a mai üzleti intelligencia megoldásoknak - sok más egyéb mellett - a következő kihívásokkal kell megküzdeniük:

  • Még az üzletileg kritikus lekérdezések adatai is csak kisebb vagy nagyobb késleltetéssel érhetőek el (a kinyerés, transzformálás, betöltés (ETL) ütemezése, és/vagy az aggregálás sebessége miatt)
  • Nem minden adat áll rendelkezésre: különböző „célcsoportok" (felsővezetői, operatív, stb.) számára különböző riportok készülnek, és még ezek sem mindig elégítik ki az adott célcsoport „adatéhségét"
  • A legtöbb adat aggregálva áll csak rendelkezésre: nem lehet végtelen mértékben lefúrni a sorszintű adatokhoz
  • Az ETL feladatok bonyolultsága, a folyamatosan változó üzleti és felhasználói igények miatt az adott vállalat BI költségei magasak és folytonosak

Az alábbi ábra egy leegyszerűsített BW-s szcenáriót mutat, hogy hogyan jutunk el a sorszintű számla és rendelések adataiból egy aggregált és konszolidált rétegbe, amire az egyes üzleti felhasználók igényei szerint implementált riportok épülnek. A Globális Kiadások MultiProvider egy fizikailag materializált tárolási egység a BW-ben, és korántsem valós idejű, továbbá korántsem biztos, hogy minden esetben konzisztens képet mutat (az esetleg gyorsan változó törzsadatok és attribútumok, hierarchiák miatt).

SAP HANA régi BI szcenárió

Miben nyújt többet / mást a HANA?

Mivel segít a fenti problémákon a HANA? Egyfelől a sebességével. Képzeljük el, hogy vajon továbbra is vesződnénk-e a sok transzformációval, aggregálással, miegyébbel, ha a riportjaink és dashboard-jaink valós időben - on the fly - tudnák a forrásadatainkat kezelni? Nyílván nem. De ehhez az kell, hogy egy olyan motor legyen az analitikai alkalmazásaink alatt, amely ezeket az oriási volumenű és részletességű adatmennyiségeket (akár több százmillió rekordot) kezelni tudja. Ez pedig nem más mint a HANA. Az alábbi ábrán láthatjuk a fenti szcenárió „HANÁ-sított" megoldását:

SAP HANA új BI szcenárió

Láthatjuk, hogy immár semmilyen aggregálásra, de még transzformációra sincs szükség, mivel a Globális kiadások már csak egy virtuális nézet (modell) a sorszintű adataink felett, és minden transzformáció és aggregálás valós időben történik. Sőt még a korábbi esetben látott DSO-k (pl. Rendelések) BW-ben való materializálására sincs szükség (erről később bővebben).

Miben megy még ennél is tovább az SAP HANA megoldása? Abban, hogy az adatok a riportok számára is a lehető legrészletesebb szinten állnak rendelkezésre, és innentől kezdve nem kell (legalábbis modell szinten nem) megkülönböztetni az operatív és a stratégiai riportok adatának körét, mert mindegyik riport / query / dashboard ugyabból a virtuális nézetből fog „táplálkozni".

És persze mondani sem kell, hogy mindezt elképesztő sebességgel. Akik ismerik a BWA-t (BW Accelarator-t) és/vagy a ráépülő BOBJ Explorer-t (Accelerated version), azok már találkoztak ezzel a sebességgel, de a HANA ennél többet nyújt abban, hogy nincs szükség az adatok külön BW-ben és BWA-ban való materializálására.

A következő fejezetben a HANA egyes komponenseit tárgyaljuk.

A HANA felépítése

Mielőtt a HANA architektúráját részletesebben tárgyalnánk, érdemes egy aspektusra kitérni. Mégpedig arra, hogy mi is van a HANA szó mögött, vajon szoftver vagy hardver, vagy pedig a kettő együtt?

Megint csak a BWA-t hoznám példaképpen. A BWA (és a HANA) esetében az SAP nem csupán a szoftvert árusít. Magának a szoftvernek a magját (a memórialapú adatbázis motort) többféle képen hívják / hívták, pl. IMDB (In-Memory Database Engine), NewDB, HDB, ICE (In-Memory Computing Engine), stb. Ennek összetevőiről ebben a fejezetben is szó lesz. De a HANA nem csak ebből áll, hanem egyfelelől további „kapcsolt" szoftverkomponensekből:

  • Sybase Replication Server (és client) - az adatok a backend rendszer (pl. ERP) adatbázisszerveréből való replikációját végzi.
  • BusinessObjects DataServices - ez a replikálás mellett a másik adatbetöltési lehetőség a HANA-ba.

Ezen kívül a HANA termék a hardvert is magában foglalja. Az SAP partnercégei (pl. IBM, HP, stb.) által forgalmazott szerverekkel (rack szerverekkel) együtt árusítják a HANA-t. Különböző vevői igényeknek megfelelő méretű „csomagok" érhetőek el. A legkisebb csomag előre láthatólag egy 2 x 8 magos processzoros, 128GB RAM-ot tartalmazó szervert foglal magába. A HANA erős, ugyanakkor viszonylag olcsón elérhető (commodity server) hardvert igényel.

És akkor most essék szó a HANA egyes komponenseiről kicsit részletesebben!

Az alábbi ábra egy magasabb szintű felépítést mutat:

SAP HANA architektúra IMDB NewDB Replication Server

Ahogyan korábban is említettem, a HANA csomag része (az adatbázis kezelő mellett) az alábbi két szoftverkomponens:

  • Sybase Replication Server. Az adatbázisrendszer (pl. DB2) DB logjait replikálja HANA-ba. Ennek a folyamatnak köszönhető, hogy a kiválasztott adatok (tranzakciós-, törzsadatok, stb.) valós időben rendelkezésre állnak az analitikai alkalmazások / riportok számára
  • BusinessObjects DataServices - A DataServices egy ETL eszköz, ebből kifolyólag az ilyen jellegű adatbetöltés már nem nevezhető valós idejűnek, de konfigurációval közel valós idejűvé tehető. A DataServices segítségével sokkal több forrásrendszert tudunk a HANA-hoz kapcsolni, mert rendelkezésünkre áll egyebek mellett fájl-interface, webservice interface, adatbázis kezelő interface (ODBC, JDBC), stb. Ezen túl az adatok transzformálásához és validálásához is eszközöket nyújt, szemben a replikálás egy- az-egyhez megközelítésével.

Az SAP HANA tehát egyrészt magából az adatbázis kezelőből (az ábrán In-Memory Computing Engine), az adminisztrációs szoftverből (Modeling Studio - egy Eclipse alapú modellező és felügyeleti eszköz) illetve a fent említett kiegészítő alkalmazásokból áll.

Az alábbi kapcsolódási lehetőségek érhetőek el jelen pillanatban:

  • SAP Business Suite (pl. ERP) - komplett adatbázis táblák replikációja a Sybase Replication Server segítségével. A HANA-ban tárolásra kerül a teljes - széltében (mezők) és hosszában (összes adat) - adatbázis tábla, amelyeken létre lehet hozni a „nézeteket" / modelleket. Ezeknek a modelleknek egyik fajtáját Analytic View-nak hívják. Ez egy virtuális modell, amely különböző join és egyéb feltételek alapján jön létre. A BI Query-khez hasonló számított keyfigure-eket (calculated keyfigure) is definiálhatunk ezekben a nézetekben.
  • SAP NetWeaver BW - a BW Accelerator-os use case továbbra is érvényes HANA esetén is. Továbbá az SAP BW egyik következő verziója már közvetlenül a HANA adatbázis kezelőjén fut, mint elsődleges adatbázis. Tehát a jövőben a HANA lehet a BW adatbázis kezelő (DBMS) rendszere.
  • 3rd Party - külső rendszerekből lehet a DataServices segítségével adatokat betölteni

A következő alkalmazások használják a HANA-ban tárolt adatokat:

  • SAP BusinessObjects termékek - az összes BOBJ termék képes / képes lesz a HANA-val való integrációra (Explorer, Dashboard Design (Excelsius), Crystal Reports, stb). A meglévő riportok és dashboard-ok mellett a valós idejűség és sebesség teljesen új riportolási lehetőségeket nyújt.
  • Other applications - külső third party (nem SAP) alkalmazások számára elérhető interface-ek: ODBC, JDBC, MDX (MS Excel), BICS. A HANA-ban található adatok standard SQL utasításokkal kezelhetők.

Végezetül ejtsünk néhány szót az adatbázis kezelő rendszerről (aka. In-Memory Computing Engine, IMDB, NewDB, stb.)! Mint az ábrán is látható, leegyszerűsítve két főbb részből áll: az úgynevezett Calculation and Planning engine-ből, valamint a tárolásért felelős engine-ekből.

  • Calculation and Planning Engine - az IMDB (In-Memory DataBase Engine) nem csupán egy DBMS (adatbázis kezelő rendszer), hanem több annál - magas szinten támogatja az oszlopszintű tárolás és az in-memory adatkezelés paradigmáját kihasználó számítási műveleteket. Tehát pl. ha van egy modellünk, amiben rendelkezésre áll a Sales Quantity és a Sales Amount keyfigure, akkor ebből könnyedén kaphatunk egy átlagos Sales Price értéket, amelyet viszont általában nem a legnagyobb granularitáson szeretnénk megjeleníteni, hanem aggregált, pl. régió vagy ország szinten. Egyebek mellett az ilyen és ehhez hasonló műveleteket támogatja a Calculation Engine. A Calculation Engine ennél persze többre képes, komplex számítási és lekérdezés-végrehajtási feladatokat lát el. A Planning Engine pedig egyebek mellett a tervezést, pl. tervadatok diszaggregálását támogatja.
  • Row and Column Store - mint ennek a komponensnek a neve is mutatja, az adatbázis kezelőben van sorszintű és oszlopszintű adatreprezentációt támogató tárolási motor. Alapvetően az IMDB felhasználási lehetőségeinek nagyobb részéhez az oszlopszintű reprezentáció az előnyösebb, de a rendszer része a sorszintű tárolási engine is, mivel bizonyos esetekben ennek jobb az (elérési és írási) performanciája (pl. konfigurációs táblák, stb.) Az alábbi ábra szemlélteti a sor és oszlopszintű adattárolásbeli különbségeket: az oszlopszintű tárolás az egyes attribútumok (oszlopok) egyedi értékeit tárolja, és ezekből ál össze egy sora az adatbázis táblának.

    SAP HANA oszlopszintű adattárolás (column based)

Ezeken kívül természetesen egyéb IMDB komponensek is léteznek, pl. tranzakció kezelő, SQL feldolgozó és optimalizáló, session és authorizáció kezelő, stb. De ezek olyan technikai részletek, amelyek bemutatása nem tárgya ennek a cikkne

Kinek jó mindez?

Felmerülhet a kérdés, hogy melyek azok az iparágak, ezen belül „use case-ek", amelyek a HANA funkcionalitását hasznosítani tudják. A rövid válasz, hogy szinte bármely iparág. Bárhol, ahol szükség van nagy vagy óriási adatmennyiséget villámsebesen, rövid késleltetéssel feldolgozni. Vagy ahol a riportolási és dashboard igények (mezők, adatok) gyorsan változnak, illetve van igény az egyes üzleti folyamatok mozgatórugóinak (részleteinek) mélyebb megértésére. Néhány use-case példa (a sok száz közül):

  • Közművek: az intelligens mérők (smart meter) valós időben, nagy gyakorisággal (akár percenként) küldenek adatot a központokba. Ezen adatokat korábban csak késleltetéssel és aggregált szinten lehetett felhasználni. A HANA elősegítheti olyan üzleti folyamatok kialakítását, amelyek valós idejű reakción alapulnak (pl. áram vásárlás - eladás - hálózatirányítás)
  • Sales és marketing: az egyes vállalatok vásárlói viselkedésének elemzése új ismereteket nyújthat a gyártó vagy forgalmazó számára, pl. melyek azok az időszakok, vagy napszakok, amikor egyes termékeket vásárolnak - és mik ezek mozgatórugói (időjárás, stb.)
  • Kereskedelem: kis és nagykereskedelmi vállalatok egyaránt nagy adatmennyiségekkel dolgoznak. A kiskereskedelmi vállalatok számára elérhető nagy részletességű és granularitású eladási (POS - Point of Sales) adatok az egész beszállítói lánc számára - még a gyártó számára is - érdekesek és értékesek lehetnek.
  • Telekommunikáció: ez az iparág szintén rendelkezik olyan folyamatosan érkező, nagy volumenű adatokkal, amelyek valós idejű és nagy részletességű feldolgozása segítheti a folyamatok és a vásárlói szokások jobb megértését.
  • BOBJ Explorer: az Explorer önmagában egy olyan termék, amely attraktívvá és intuitívvá teszi az adatbányászást, bármely célcsoport (operatív vagy stratégiai) és bármely iparág számára. A HANA segítségével valós időben és nagyon részletes képet kaphatunk egyes folyamatokról (pl. eladásokról, megrendelésekről)

Az analitikán túl - jövőbe tekintés

Az SAP HANA stratégiája két főbb irányt jelöl meg: az úgynevezett HANA content és a HANA alkalmazások építését. Tehát egyfelől a HANA az adatokat BI szemszögből megközelítő, analitikát gyorsító és valós idejűvé tevő platform, amely első sorban az egyes Business Suite alkalmazások tranzakciós és törzs adataira épül. Az ügyfelek saját modelleket készíthetnek, vagy felhasználhatják az SAP által kiszállított content-et.

Másfelelő az SAP hosszabb távú terve, hogy az in-memory paradigmákat és a HANA által nyújtott elképesztő sebességet felhasználva, teljesen új terméket fejlesszen. Ennek egyik (hivatalos) példája a Strategic Workforce Planning alkalmazás. De ezen kívül még számos egyéb termék van készülőben az SAP palettáján.

Továbbá az SAP aktívan támogatni kívánja, hogy az ügyfelek saját analitikai és alkalmazás ötleteiket meg tudják valósítani a HANA segítségével.

Zárszó

Ezzel a cikkel szerettem volna némiképp részleteiben bemutatni a HANA-t, mert ez jelenleg egy meglehetősen felkapott terület. Nem is alaptalanul. Az első ügyfél-visszajelzések kiemelkedően pozitívak - és ami talán elég ritkaság egy informatikai termék esetén, amely üzleti felhasználóknak készült - az ügyfelek lelkesednek! Az SAP hosszú távú stratégiájának fontos része az in-memory computing megoldások fejlesztése. Ezért nem mehetünk el szó nélkül a HANA mellett, mert a nem is olyan távoli jövőben könnyen lehet, hogy úton útfélén a HANA alapú megoldásokba botlunk.

Amennyiben lesz érdeklődés, várhatók további HANA-val és in-memory computing-gal kapcsolatos cikkek.

A SAP Labs Hungary ABAP fejlesztőjeként tevékenykedik, 2010-ig az SCM / MIP területen hegesztette az SPP nevű alkatrészkezelő alkalmazást. 2011-től a DP (Demand Planning) területbe is belekóstolt egy custom development fejlesztés keretében. Ezek mellett SAP In-Memory (HANA) területekkel is megismerkedett, egy prototípus alkalmazás illetve fejleszés alatt lévő termék kapcsán.
Szabadidejét kedvesével és fotózással tölti, szeret utazni, világot látni, új dolgokat megismerni.

További cikkek a szerzőtől


Téma megvitatása (1 hozzászólás)
SAP HANA és IMDB: elérkezett a valós idejű analitika!
2011. Október 25. kedd, 04:54
** Ebben a témában a következő cikket vitatjuk meg: SAP HANA és IMDB: elérkezett a valós idejű analitika! **

Remek cikk, köszi!

A téma megvitatása a fórumon. (1 hozzászólás)