Diskuze

SAP HANA: Technologie in-memory databázové platformy

Článek pojednává o technologických aspektech in-memory databázových platforem, konkrétně pak na příkladu produktu SAP HANA. Objasňuje hlavní rysy jeho funkčnosti a přináší detailní popis zpracování dat prostřednictvím in-memory technologií.

1. Proč vznikly databázové platformy s technologií in-memory computingu?

Hlavním důvodem, proč vznikly in-memory databázové platformy, byla nutnost reagovat na potřebu zpracování stále se navyšujícího objemu podnikových dat. Tato data slouží nejen k transakcím v provozních systémech typu ERP nebo CRM. Stále častěji se objevují požadavky od podnikových analytiků a vrcholových manažerů na rychlé zpracování analytických dotazů a dolování znalostí v rozsáhlých databázových strukturách, které by byly použitelné k podpoře rozhodování na strategické úrovni organizací nejrůznějších typů a velikostí.

Dále je třeba brát v úvahu, že historické rozdělení databázových systémů na OLAP a OLTP již často neodpovídá jejich současné povaze. Rozdíly mezi oběma koncepty se totiž do značné míry setřely. V OLTP systémech stále více převažují "read-only" dotazy. Druhým problémem je pak stále se prodlužující čas, který je potřebný pro ETL fázi mezi OLTP a OLAP, nehledě na to, že během ETL procesu dochází ke ztrátě části informací v důsledku agregací. V neposlední řadě tu pak máme duplicitní data, plynoucí z tohoto rozdělení.

Vezměme jako příklad společnost, jejíž hlavní činností je výroba, prodej a servis zemědělských strojů, která se rozhodla pro zavedení databázové platformy běžící v operační paměti. Pokud si uvědomíme, že každý traktor, kombajn nebo jiné složitější mechanické zařízení je doslova poseté čipy, zaznamenávající stav nejdůležitějších součástek, jistě si dovedeme představit, že zpracovávat takto získaná data pro stovky zákazníku, majících pronajatých tisíce strojů, by znamenalo, že dříve dojde k samotné poruše, než se zanalyzují výstupy z příslušných senzorů. Díky systému, jako je např. SAP HANA, správnému uložení a sběru dat, lze data procházet a vyvozovat z nich možné problémy s předstihem, vyměnit tak rizikové součásti a vyhnout se placení pokut za traktory, které zůstanou stát s defektem uprostřed pole v období sklizně.

2. Perzistence

První věc, která člověka nejspíše napadne ohledně operační paměti, je bezpečnost uložení dat. Co se stane, když dojde k výpadku proudu (pokud nemáme UPS) nebo poruše jednoho z modulů paměti serveru? Nepřijdu o část svých dat? Jak dlouho bude trvat zotavení?

Samozřejmě ani u in-memory databázových platforem se neobejdeme bez klasických nebo SSD disků. SAP HANA v základním nastavení každých 5 minut vytváří tzv. "savepoint" na pevné disky a k tomu neustále zapisuje transakční změny do logů, jako je tomu u ostatních databází, stejně tak na perzistentní úložiště (některý výrobce SAP HANA kompatibilního hardwaru používají speciální flash karty, jiní například SSD disky).

Vytváření těchto savepointů není jen prosté zapsání kompletního obsahu paměti na disky. V takovém případě bychom zcela ztráceli rychlost a výhody, pokud bychom museli čekat na zapsání. Proto se do těchto obrazů zapisují pouze změny od posledního obrazu a to asynchronně. V případě poruchy a následného restartu (za předpokladu, že jsme nepřišli o disky) se nejprve načte poslední savepoint a pak se zrekonstruují transakce z logů zapsaných od posledního savepointu do času poruchy.

Obr. 1 – SAP HANA perzistence (Zdroj: Bachmaier, Krutov, 2014)
(Klikněte na obrázek pro zvětšení)

3. Column-based tabulky

Protože většina analytických dotazů sleduje data pouze některých atributů tabulky, vznikl koncept sloupcového uložení. K operační paměti totiž přistupujeme sekvenčně, čili data jsou zapsána v řadě za sebou a čteme je po částech o velikosti dané velikostí cache.

Vezměme například tabulku zaměstnanců nadnárodní organizace se sto tisíci zaměstnanci. Pokud by nás zajímal počet mužů, museli bychom v row-store tabulce projít celou tabulku a načíst postupně všechny záznamy a jejich atributy. V případě column-based tabulky stačí přečíst pouze sloupec s pohlavím a sečíst počet výskytu mužů.

Tab. 1 – Rozdíl mezi column a row based tabulkou (Zdroj: vlastní zpracování)
(Klikněte na obrázek pro zvětšení)

4. Komprese dat

Pokud jsme v předchozím případě hovořili o potřebném jednom bytu pro zaznamenání pohlaví pracovníka, ve skutečnosti si zde vystačíme s pouhým bitem. Pro sloupcové tabulky se totiž používá slovníková komprese jako defaultní pro každý sloupec. Jestliže se totiž podíváme na data v podnikových tabulkách téměř jakýchkoli systémů (ERP, CRM, SCM), zjistíme, že mnoho sloupců má velmi nízkou kardinalitu. Některé sloupce dokonce nejsou využity vůbec, nebo obsahují pouze jednu hodnotu. Proto je vhodné data reprezentovat jinak než pomocí znaků abecedy, slov nebo názvů.

Ukažme si na příkladu, jak taková slovníková komprese funguje. Pokud uvažujeme znovu naši tabulku zaměstnanců, sloupec oddělení bude mít pravděpodobně pouze několik odlišných hodnot. Řekněme, že firma má pět divizí. Pro tento atribut se tedy vytvoří slovník, kde bude abecedně seřazený seznam divizí ve slovní podobě a ke každé divizi bude přiřazeno jedno číslo počínaje nulou. V samotném sloupci pak nebude slovní popis oddělení, ale pouze číslo odkazující se na slovník. Pro pět divizí tedy potřebujeme pouhé dva bity pro reprezentaci přiřazení pracovníka místo původních padesáti bytů (pokud bychom uvažovali 50 znaků pro název oddělení). Na sto tisíci záznamech to již může dělat značný rozdíl. Obecně se počítá při migraci zákaznických BW systémů s faktorem komprese 6-8x.

Obr. 2 – Slovníková komprese (Zdroj: vlastní zpracování)
(Klikněte na obrázek pro zvětšení)

Kromě ušetřeného místa v paměti a na disku se zrychlí vyhledávání, protože porovnáváme čísla místo znaků (práce s čísly je pro procesor a s ním spojené části a registry mnohem snazší) a navíc v seřazeném slovníku je možno použít binární vyhledávání místo sekvenčního. Mimoto jak na atribut vektor, tak na slovník se dá uplatnit další z řady sekundárních kompresí, jako jsou například run-length algoritmus, prefix encoding, cluster encoding a jiné (SAP HANA dokáže sama prohlédnutím hodnot vybrat nejlepší algoritmus a uplatnit ho).

Tyto výhody jsou ovšem vykoupeny faktem, že pokud by v našem příkladu firmy přibyla další divize, která by byla alfabeticky před divizí "vedení", museli bychom přeskládat slovník a poté projít všech sto tisíc záznamů a poupravit ID hodnoty

5. Hlavní a delta úložiště

Problém s přidáváním nových hodnot do slovníku atributu řeší SAP HANA pomocí rozdělení každé tabulky na main a delta storage. Jestliže by toto rozdělení neexistovalo, musel by se jak slovník, tak atribut vektor kompletně přeskládávat velmi často. U tabulek se stovkami milionů záznamů, které se v praxi běžně vyskytují, by to znamenalo značné zpomalení práce s databází. Proto veškeré změny (delete, insert, update) jsou zaznamenávány nejprve do delty, která má vlastní vektory atributů a slovníky pro každý sloupec tabulky.

Pokaždé, když tedy měníme nějaký záznam, je tento nejprve označen jako invalidní v hlavní části a poté zapsán jako nový v deltě. Stejně tak operace delete neprobíhá tak, že bychom opravdu záznam fyzicky smazali, pouze se označí jako invalidní a teprve při operaci zvané delta merge dochází k "housekeepingu". Naproti tomu, pokud zadáme selektivní dotaz, procházíme pro získání výsledku jak delta, tak i main storage. Čímž projdeme všechny záznamy a dostaneme korektní odpověď.

Obr. 3 – Rozdělení úložišť tabulky (Zdroj: vlastní zpracování)
(Klikněte na obrázek pro zvětšení)

5.1 Delta merge

Čas od času je potřeba spojení obou úložišť tabulky, protože čím větší by byla delta, která je optimalizovaná hlavně pro zápis, díky užití různých verzí binárního stromu (B+ tree, CSB+), tím vyšší by byl čas pro vyhledávání, čímž bychom přišli o hlavní výhodu in-memory databázových platforem.

Delta merge může být aktivován při různých událostech. Při určitém počtu záznamů v deltě, určité velikosti delty v paměti, poměrové velikosti k hlavnímu úložišti nebo lze merge proces spouštět manuálně. Existuje speciální varianta, kdy je spojení iniciováno aplikací po provedení určité akce, což se hodí například pokud probíhají objemné loady, během nichž by jinak došlo k několikanásobnému sloučení. Během delta merge operace můžeme zároveň spouštět sekundární kompresi, pokud je pro tabulku zapnutá. Vše lze nastavit v hlavních konfiguračních souborech SAP HANA.

6. SAP HANA procesy

Stejně jako ostatní databáze, i SAP HANA se skládá z několika běžících procesů. Každý z nich slouží jednomu hlavnímu účelu a většinou má několik dalších menších úkolů. V případě scale-out řešení, kde je jeden master, několik worker a případně jeden nebo více stand-by nodů, jsou některé procesy pouze na master nodu. Proto si popíšeme ty, které jsou přítomny právě na hlavním serveru.

  • Indexserver - obsahuje row store a column store data, plus systémy pro zpracování dat
  • Preprocessor - použitý index serverem pro analýzu textových údajů
  • Nameserver - obsahuje topologii SAP HANA databáze (důležité hlavně u scale-out)
  • xsengine - webový server pro přístup přes prohlížeč
  • compileserver - provádí kompilace vnořených procedur a SQL skriptů [2]

Kromě těchto hlavních procesů na serveru běží další podpůrné jako saphostcontrol a sapstartsrv, které slouží pro vzdálenou správu a monitoring ostatních procesů, a nebo web dispatcher, jehož hlavní funkcí je distribuce http/https requestů pro xsengine.

7. Závěr

SAP HANA a jiné in-memory databázové platformy jsou budoucností všech podnikových informačních systémů. SAP nedávno uvolnil informaci o novém produktu, který bude již v základu optimalizován pro tuto technologii. Produkt se jmenuje SAP Business Suite 4 SAP HANA nebo zkráceně SAP S/4 HANA. Společnost SAP k tomu uvedla, že se jedná o největší pokrok od dob SAP R/3.

Možnosti personalizace, které budou zákazníkům v rámci tohoto řešení nabízeny, skýtají jak klasickou verzi se zakoupenými servery, tak cloudovou nebo hybridní verzi. Proto kromě systémů BW, ECC a role akcelerátoru, kde může nyní HANA být použita jako databázový systém, budou všechny systémy na bázi SAP optimalizovány pro in-memory technologii.

Použitá literatura

  1. BACHMAIER, Martin a I. Krutov. In-memory computing with SAP HANA on IBM eX5 and X6 systems. 3rd ed. New York: IBM, International Technical Support Organization, 2014. ISBN 0738439908
  2. SAP SE. SAP HANA Administration Guide. Sap.com [online]. ©2014 [cit. 2015-02-15]. Dostupné z: https://help.sap.com/hana/SAP_HANA_Administration_Guide_en.pdf
  3. SAP AG. HA200 SAP HANA installation & operations SPS06. Walldorf: SAP AG, 2013

15.04.2015 - Petr Svitálek - četlo 30313 čtenářů.

[ Zpět ]


Tento článek ješte není ohodnocen.Hodnocení článku:
nejlepší [ 1 | 2 | 3 | 4 | 5 ] nejhorší
Verze pro tisk

Jméno
E-mail
Opište kód :    
Text
*)
   
Odkazy - pravý sloupec


  • Odběr novinek
  • Partneři webu:




  •  
  • Aktuální akce CVIS:


  •  
    Informační systémy
    v podnikové praxi
    (2. aktualizované a rozšířené vydání)
     

  • Nejčtenější články:
    1. SystemOnLine.cz:

    2. Přehledy informačních systémů 

      ERP systémy
       

      Plánování a řízení výroby
       

    3. ČSSI
    4. SSSI
    5. VUT v Brně
    6. Systemonline.cz
    7. Výzkum a vývoj v ČR
    8. ICT unie
    9. Cacio
    10. Živě
    11. Lupa
    12. AKA-MONITOR
    13. Jiko Blog
    14. Databázový svět
    15. destinationCRM.com
    16. MyCustomer.com
    17. ZDNet
    18. Nucleus Research
    19. ComputerWeekly.com
    20. IDC
    21. Gartner
    22. Deloitte
    23. Accenture
    24. Capgemini
    25. CIO
    26. Forrester Research
    27. Aberdeen Group
    28. Archiv: