Dezvoltarea soluțiilor de business SAP reprezintă o continuă provocare extinsă pe doua planuri atât la nivel tehnic cât și la acela de cunoaștere al mediului de afaceri. Nevoia de performanță și adaptabilitate ridicată în crearea unui software de business SAP implică inovație, ale cărei rezultate revoluționare deja aplicabile am dori sa le expunem în rândurile ce urmează.
Volumul de date din cadrul sistemelor de business actuale se află într-o continuă creștere, calitatea datelor este foarte diferită, de la date structurate la cele nestructurate. Odată cu apariția tehnologiilor Mobile s-a schimbat și modul de acces al datelor astfel încât userii au acces real-time, iar timpul de răspuns trebuie sa fie minimal ( < 1s ).
În cazul sistemelor clasice de management al bazelor de date, datorită limitelor tehnologice, încărcarea datelor se face printr-o separare a soluțiilor de data management în procesări transzacționale ( OLTP - Online Transaction Processing ) și analitice ( OLAP - Online application processing ).
Exemplu de In-Memory DB - IMDB
Arhitectura generației actuale de sisteme de business reflectă condițiile tehnologice și evoluția soluțiilor de business :
Figura 2 ilustrează o situație tipică pentru un software de tip enterprise în generația actuală de soluții. Companiile de mari dimensiuni posedă mai multe sisteme de tip enterprise resource planning (ERP) fiecare cu baza de date proprie pentru datele operaționale. Datele analitice sunt consolidate într-un enterprise data warehouse și consumate de către business useri cu ajutorul soluțiilor de Business Intelligence (BI).
În aplicațiile financiare și de business, diferite tipuri de balanțe totale sunt de obicei persistate sub forma de agregate materializate. În cazul SAP HANA si a salvării datelor în memorie , aceste agregate materializate pot fi eliminate astfel încât toate calculele de balanțe și sume necesare rapoartelor sunt determinate real-time cu o performanță ridicată a documentelor, de exemplu cele contabile.
În situaţia utilizării unui system de DBMS classic, necesitatea permanentă de a avea acces la informaţii actualizate conduce la crearea de tabele adiţionale pentru stocarea acestor date. În cazul SAP HANA aceste tabele sunt eliminate, informaţiile necesare putând fi calculate în timp real, astfel simplificându-se modelul de date.
Toate modulele SAP alături de release-urile noi sunt si vor fi adaptate pentru platforma In Memory-Database SAP HANA. Datorită succesului avut până acum SAP HANA este contractată și de aplicațiile noi dezvoltate în SAP-ABAP.
SAP oferă un road-map incremental care permite companiei sau organizației să exploreze tehnologiile de ultimă oră, să rețină oportunitățile în scenarii side-by-side, și să fie pregătită pentru rata în continuă creștere de a face business.
Platforma SAP HANA nu se rezumă la a fi abordarea SAP a conceptului de In-Memory Database, ci vine cu o serie de inovaţii menite să folosească la maximum progresul tehnologic din ultimii ani. În continuare vom discuta structura interna a platformei, evidenţiind aceste inovaţii care diferenţiază SAP HANA de alte soluţii IMDB.
Spre deosebire de un DBMS obişnuit platforma SAP HANA oferă, pe lângă interfaţa SQL standard, şi alte interfeţe precum SQLScript sau MDX(multidimensional expression). Existenţa acestora aduce un plus de flexibilitate platformei şi permite dezvoltarea de aplicaţii optimizate pentru procese în timp real.
Odată cu implementarea pe scară tot mai largă a bazelor de date In-Memory este de aşteptat ca şi fenomenul de "Code Pushdown" să devină tot mai frecvent întâlnit - acesta presupune migrarea logicii de business considerate a fi "data-intensive" de la nivelul aplicaţie la cel al bazelor de date. Interfaţa SQLScript a SAP HANA are rolul de a veni în întâmpinarea acestui fenomen, SQLScript fiind un limbaj dezvoltat de SAP tocmai cu scopul de a sprijini implementarea unei logici complexe la nivelui bazei de date.
Instrucţiunile SQL Script au la bază operaţii SQL standard şi proceduri predefinite. Astfel, din punct de vedere conceptual, SQLScript poate fi asemănat cu procedurile stocate, SQL Script aducând însă îmbunătăţiri semnificative în ceea ce priveşte potenţialul de optimizare al operaţiilor. Astfel, pentru a fi procesate, procedurile SQLScript sunt compilate într-un plan de execuţie bazat pe limbajul "L" iar mai apoi în limbaj C++ în vederea execuţiei efective.
De asemenea la nivelul "layer"-ului C++ au fost dezvoltate şi o serie de librării menite să uşureze implementarea logicilor de business în cadrul bazei de date. Exemple de astfel de librării sunt "Business Function Library"(BFL) şi "Predictive analysis library"(PAL).
Un alt aspect important de care s-a ţinut cont în dezvoltarea platformei SAP HANA este capacitatea masivă de paralelizare a generaţiei actuale de procesoare multicore.
Astfel, un benchmark1 efectuat de Intel împreună cu SAP pe platforma HANA si utilizând procesoare Intel a relevat o relaţie de natură aproape liniară între creşterea paralelismului(numărului de thread-uri) şi scăderea timpului de execuţie la operaţii pe baza de date.
Secretul din spatele acestor performanţe constă în utilizarea unui "model computaţional" optimizat. Practic, instrucţiunile SQLScript sunt compilate şi reprezentate sub forma unui "data flow graph" - un graf aciclic orientat în care fiecare nod al grafului reprezintă o transformare ce trebuie aplicată asupra setului de date.
Tipurile de operaţii ce pot fi înglobate în aceste noduri sunt:
Reprezentarea instrucţiunilor sub această forma permite o mai bună partiţionare a datelor în submulţimi independente, care pot fi procesate în paralel. Utilizarea unei asemenea abordări oferă posibilitatea platformei SAP HANA să profite la maximum de puterea de procesare masivă a generaţiei actuale de "multi-core-uri", astfel explicându-se şi rezultatele uimitoare obţinute în benchmarkul Intel.
Una dintre proprietăţile distinctive ale SAP HANA este faptul că dispune atât de un model de stocare bazat pe rânduri(row store) cât şi pe coloane(column store).
Deşi o tabelă este prin definiţie bidimensională, memoria calculatorului este organizată ca o succesiune secvenţială de locaţii. Astfel, decizia de a stoca o tabelă sub forma unei succesiuni de rânduri, respectiv de coloane, poate avea un impact semnificativ asupra performanţei aplicaţiei.
SAP HANA oferă posibilitatea de a lua această decizie individual pentru fiecare tabelă, luând în calcul natura acesteia. Tabelul următor prezintă situaţiile în care este recomandată utilizare unui "row store", respectiv a unui "column store".
| Row store | Column Store |
| Tabelă cu număr redus de rânduri, de ex. tabele de configurare | Operaţii executate pe o singură (sau puţine) coloane |
| Aplicaţia procesează câte un rând | Număr mare de rânduri, şi sunt necesare operaţii pe coloane(agregare, căutare ş.a.m.d.) |
| Agregările nu sunt necesare | Număr mare de coloane al tabelei |
| Coloanele conţin valori distincte, astfel potenţialul de compresie a datelor fiind redus | Tabela este parcursă doar pe baza valorilor din anumite coloane |
Evident, discuţia despre platforma SAP HANA nu poate fi încheiată altfel decât răspunzând la întreabarea "Care este câştigul concret de performanţă obţinut prin migrarea pe o platformă SAP HANA?" Pentru a cuantifica acest câştig au fost realizate nenumărate benchmark-uri, probabil cele mai relevante fiind cele desfăşurate în contextul de Data Warehousing.
În continuare vor fi prezentate pe scurt rezultatele unui asemenea benchmark realizat pe platforma SAP HANA. În cadrul testului s-a urmărit analiza puterii de procesare analitice a SAP HANA în contextul BI real-time.
Testul a fost executat pe un set de date de 100TB, acestea fiind stocate într-o tabelă de fapte cu 100 de miliarde de înregistrări şi în tabelele de dimensiuni aferente. Setul de date reprezintă înregistrările corespunzătoare pentru un interval de cinci ani ale unui modul de SD (Sales&Distribution).
Operaţiile alese pentru evaluare sunt de natură mixtă, ele acoperiind mare parte din activităţile de BI obişnuite:
Testul a urmărit atât măsurarea timpului de execuţie al unui query cât şi determinarea throughput-ului (exprimat ca număr de query-uri/oră)
Majoritatea query-urilor au rezultat în timpi de răspuns de sub o secundă, până şi cea mai complexă operaţie, efectuată asupră întregului set de date de cinci ani, încheindu-se în mai puţin de 4 secunde2.
Desigur, ceea ce contează într-un final este modul în care această îmbunătăţire de performanţă este resimţită de end-userii sistemului în mediul productiv. Se vehiculează că migrarea de pe un DBMS obişnuit(cu stocare pe suport magnetic) pe SAP HANA aduce cu sine îmbunătăţiri cu un factor de câteva mii.
Acest fapt este susţinut şi de declaraţiile diverşilor clienţi care au trecut deja prin această etapă:
"[R]eplacing our enterprise-wide Oracle data mart and resulting in over 20,000-times speed improvement processing our most complex freight transportation cost calculation . . . our stand-alone mobile applications that were previously running on Oracle are now running on SAP HANA. Our 2,000 local sales representatives can now interact with real-time data instead and have the ability to make on-the-fly promotion decisions to improve sales." - Nongfu Spring
"[O]ur internal technical comparison demonstrated that SAP HANA outperforms traditional disk-based systems by a factor of 408,000."
- Mitsui Knowledge Industry Co. Ltd.
"With SAP HANA, we see a tremendous opportunity to dramatically improve our enterprise data warehouse solutions, drastically reducing data latency and improving speed when we can return query results in 45 seconds from SAP NetWeaver BW on SAP HANA versus waiting up to 20 minutes for empty results from SAP NetWeaver BW on a traditional disk-based database."
- Shanghai Volkswagen