Imbunatatirea performantei cuburilor OLAP in Analysis Services 2000
Cind vorbim despre performanta cuburilor OLAP, ne referim in principal la urmatoarele 2 aspecte:
1. Performanta la procesarea cuburilor
2. Performanta la interogarea cuburilor de catre utilizatori.
Pentru inceput, precizez ca exemplele din acest document au fost construite pe baza demonstrativa FoodMart livrata impreuna cu Analysis Services 2000.
1. Performanta la procesarea cuburilor
Procesarea reprezinta procesul de alimentare a cuburilor OLAP pe baza de selecturi rulate pe baza de date relationala specificata in datasource-ul bazei de date. Trebuie precizat ca procesarea unui database / cube cu optiunile Full Process / Incremental Update are ca efect generarea unui folder Shadow in care practic este generata o nou baza de date cu toate fisierele aferente, iar doar in momentul terminarii procesarii (commit transaction), aceasta baza de date temporara inlocuieste baza de date originala. De-a lungul procesarii unui cub utilizatorii ramin conectati, fiind deconectati temporar doar in momentul in care se face commit transaction.
In cadrul operatiunii de procesare sint rulati urmatorii pasi:
a. Procesarea dimensiunilor.
In momentul crearii fiecarei dimensiuni , in diagrama dimensiunii au fost adaugate una sau mai multe tabele, pe baza carora au fost create level-urile dimensiunii. Dimensiunile sint construite pe baza tabelelor de referentiale.
Spre exemplu, pentru popularea dimensiunii Store este rulat urmatorul select asupra bazei de date relationale.
SELECT DISTINCT "store"."store_country", "store"."store_state", "store"."store_city", "store"."store_id", "store"."store_name" FROM "store"
Operatiuni similare sint rulate asupra tuturor dimensiunilor bazei de date multidimensionale, scopul acestei operatiuni fiind acela de a repopula dimensiunile pe baza celor mai recente informatii provenind din baza de date relationala.
b. Procesarea Partitiilor
Datele fiecarui cub sint stocate in una sau mai multe partitii, care contin de fapt inregistrarile, stocate in format multidimensional, provenite din tabela de fapte a cubului. Dintre toti pasii executati la procesare, acest pas este, alaturi de procesarea modelelor de Data Mining ) , printre cele mai consumatoare din punctul de vedere al consumului de timp, intrucit tabelele de fapte pot contine milioane de inregistrari, numarindu-se printre tabelele cele mai mari existente la nivel de datawarehouse.
Urmatorul select a fost utilizat pentru popularea partitiei Budget_1997 a cubului Budget:
SELECT "expense_fact"."account_id", "expense_fact"."store_id", "expense_fact"."category_id", "time_by_day"."quarter", "time_by_day"."month_of_year", "expense_fact"."amount" FROM "expense_fact", "time_by_day" WHERE ("time_by_day"."the_year"=?) AND ("expense_fact"."time_id"="time_by_day"."time_id")
c. Procesarea Modelelor de Data Mining
Pe baza inregistrarilor stocate in partitii, modelele de data mining sunt“antrenate” astfel incit sa corespunda modificarilor aparute la nivel de datawarehouse.
Supravegherea permanenta a performantei la procesare a cuburilor este una din atributiile deosebit de importante ale unui administrator OLAP, intrucit exista constringeri de timp foarte clar definite. Spre exemplu, daca importul la nivel de datawarehouse incepe la ora 01:00 AM si se termina la ora 04:00 AM, in intervalul 04:00 AM - 07:30 AM toate cuburile trebuiesc procesate astfel incit, la ora 08:00 AM , atunci cind utilizatorii ajung la serviciu, toate cuburile sa fie updatate pe baza informatiilor din ziua precedenta.
Performanta la procesarea cuburilor depinde de urmatorii factori:
I. Setari existente la nivel de datawarehouse
a. Una din optiunile extrem de importante care determina performanta la procesare este constituita de alegerea unui view sau a unei tabele ca si tabela de fapte a cubului.
De regula se prefera alegerea unui view atunci cind informatiile necesare tabelei de fapte a unui cub provin din mai multe tabele de fapte, fiecare continind informatii diferite precum:
i. Vinzari de produse pe magazin
ii. Stoc de produse pe magazin
iii. Costuri de productie pentru fiecare produs
In conditiile in care acest view este constituit din mai multe selecturi simple rulate pe fiecare dintre tabelele componente, utilizand clauza union, atunci selectul prezinta avantajul al economisirii spatiului pe disk, necesar stocarii tuturor acestor informatii.
Marele dezavantaj al folosirii view-ului pe post de tabela de fapte apare in momentul in care acesta este format din selecturi complexe, iar cubul al care foloseste aceasta tabela de fapte contine numeroase partitii. In aceste conditii, pentru procesarea fiecareia dintre partitii este necesara reconstruirea view-ului, operatiune care poate fi extrem de costisitoare ca si timp.
b. In conditiile cuburilor partitionate si a utilizarii view-urilor ca si tabele de fapte ale cuburilor, se recomanda utilizarea de constrangeri pentru fiecare dintre tabelele implicate in view. Spre exemplu, daca partitiile dintr-un cub sint create utilizind criteriile Business Unit & Time Civil, este recomandabil ca pentru fiecare pereche Business Unit & Time Civil sa existe cite o tabela. In conditiile in care pentru fiecare tabela au fost definite constringeri pe aceste 2 cimpuri (ex. BUSINESS_UNIT & ACCOUNTING_DATE), la procesarea fiecareia dintre partitii, desi este folosit un view ca tabela de fapte, selectul propriu-zis va fi rulat doar pe tabela care indeplineste conditiile precizate mai sus, imbunatatind dramatic timpul de procesare, mai ales in cazul view-urilor care contin milioane de inregistrari.
c. Definirea de indecsi clustered la nivel de tabela de fapte, pentru cimpurile pentru care sint definite partitiile, intrucit aceste filtre vor fi folosite simultan la procesarea partitiilor.
d. Utilizarea de indecsi simpli pentru toate cimpurile de tip foreign key din tabela de fapte, intrucit aceste cimpuri sint utilizate pentru realizarea legaturii cu tabelele de referentiale.
II. Setari existente la nivel de Analysis Services
a. Modul de procesare al cuburilor
Problema unui administrator OLAP este aceea de a decide, in functie de modalitatea de desfasurare a activitatii companiei si de modficarile tehnice asupra cuburilor, pentru una din cele 3 modalitati de procesare:
i. Incremental update – sint aduse in cub doar noile inregistrari aparute la nivel de datawarehouse, fara reprocesarea agregarilor. Aceasta modalitate de procesare este cea mai rapida insa nu poate fi folosita decit in conditiile in care modificarile la nivel de datawarehouse constau doar in adaugarea de noi inregistrari, fara modificarea celor existente.
ii. Refresh data – repopuleaza tot cubul iar agregarile sint recalculate. In toata aceasta perioada utilizatorii pot interoga insa, ca si viteza de procesare, aceasta modalitate de procesare este mai lenta decit incremental update si nu poate fi folosita in cazul modificarilor de structura la nivelul cubului.
iii. Full Process – necesara in conditiile modificari structurii cubului sau a dimensiunilor. Utilizatorii pot accesa noile date doar dupa reconectarea la cub.
b. Modul de procesare al dimensiunilor
i. Incremental Update – deosebit de utila in cazul in care in dimensiuni apar doar noi elemente, fara a fi efectuate modificari asupra elementelor existente. Spre exemplu, daca dimensiunea Products contine 10.000 de membrii si in urma importului din datawarehouse au aparut 100 de noi produse, atunci dimensiunii existente I se vor adauga doar aceste noi produse, fara a se efectua modificari asupra datelor existente. Procesarea unei dimensiuni cu Incremental Update nu atrage in mod obligatoriu si reprocesarea cubului.
- Acest tip de procesare nu poate fi totusi aplicat, spre exemplu ,in cazul in care in dimensiunea Products, pe linga noile produse adaugate s-au modificat descrieri ale produselor existente, in acest caz fiind obtinuta o eroare la procesarea dimensiunii.
- In cadrul procesarii Incrementale, agregarile existente la nivel de cub nu sint recalculate. Agregarile reprezinta totaluri precalculate, care contin valoarea intersectiei mai multor membrii ai unei dimensiuni. In momentul in care un utilizator lanseaza o interogare asupra cubului, mai intai se incearca indentificarea unei agregari existente pentru acea solicitare, iar daca acea agregare nu exista, atunci sistemul va trebui sa calculeze in momentul executiei valoarea corespunzatoare intersectiei de dimensiuni specificata de utilizator.
ii. Rebuild dimension structure - aceasta optiune permite repopularea completa a unei dimensiuni, oferind si avantajul recalcularii agregarilor. Se recomanda ca aceasta optiune sa fie utilizata in cazul unor modificari dese la nivel de datawarehouse, constind atit in adaugarea de noi date cit si in modificarea celor existente, sau la modificarea structurii dimensiunii.
Aceasta metoda de procesare este cea mai sigura, insa prezinta dezavantajul major al faptului ca dupa o astfel de procesare, toate cuburile care contin acea dimensiune sint invalidate, trebuind reprocesate cu Full Process. In toate aceasta perioada utilizatorii NU se mai pot conecta la cuburile afectate.
2. Performanta la interogarea cuburilor de catre utilizatori.
a. Definirea de partitii adecvate criteriilor de selectie ale utilizatorilor
Rolul partitiilor in performanta la interogare a cuburilor devine evident daca ne gindim la modul in care utilizatorii acceseaza datele din cuburile OLAP. Spre exemplu, pentru o companie multinationala, cu mai multe business locations distribuite in intreaga lume, cei care acceseaza datele sint controlori de gestiune. Accesele acestora sint date de regula doar pentru o anumita locatie geografica (ex. Romania), doar pentru utilizatorii din HeadQuarters fiind definite accese pe toate locatiile geografice (sau locatii de business – Business Units).
In cazul unul cub care are doar o singura partitie, orice select dat de un utilizator va avea ca rezultat parcurgerea de milioane de inregistrari, intrucit ,chiar daca cunosc de la inceput pentru ce business unit si ce perioada fiscala caut datele, sistemul nu are nici o modalitate de a individualiza inregistrarile respective fara a efectua o cautare prin toate inregistrarile cuprinse in partitia respectiva.
In conditiile in care avem partitii definite la nivel de an fiscal si de business unit, sistemul va identifica cu exactitate, in functie de selectul lansat de utilizator si de drepturile acestuia, care este partitia care trebuie interogata, restrangand astfel nr. de inregistrari care trebuie parcurse pentru a raspunde solicitarii utilizatorului.
b. Aggregation design-ul definit la nivel de partitii
Agregarile reprezinta unul din factorii esentiali care determina performanta la interogare a unui cub, intrucit contin stocate totaluri precalculate pentru intersectiile de dimensiuni. Totusi, calcularea agregarilor are ca efect atit cresterea timpului de procesare al cubului cit si a nevoilor de spatiu de stocare. Rolul administratorului OLAP este acela de a gasi un echilibru intre nevoile de sporire a performantei la interogare a cubului si necesitatea ca timpul de procesare al unui cub sa se incadreze in constringerile de timp definite.
In conditii normale de exploatare a cuburilor, pe masura ce volumul de date existent la nivel de datawarehouse creste, creste si timpul necesar pentru atingerea aceluiasi nr. de agregari pentru fiecare partitie in parte. Pentru prevenirea degradarii performantei la procesare, se recomanda dezvoltarea unei strategii axata pe urmatorul scenariu standard:
Utilizatorii acceseaza cel mai frecvent date pentru anul fiscal curent & anul fiscal precedent, de regula avind drepturi de access doar pe anumite companii. In aceste conditii, este nevoie de un timp de raspuns foarte bun pentru cele doua perioade fiscale, intrucit acestea sint cel mai frecvent accesate, ceea ce inseamna un nr. Sporit de agregari. Pentru celelalte perioade fiscale, care sint mai rar accesate, se poate recurge la reducerea nr. de agregari.
Toata aceasta strategie are ca scop mentinerea sub control a timpului de procesare, in conditiile inbunatatirii timpului de raspuns pentru cele mai frecvente interogari ale utilizatorilor. Trebuie precizat faptul ca o astfel de strategie nu poate fi aplicata decit cuburilor partitionate, cel putin la nivel de perioada fiscala, intrucit acesta este de regula cel mai frecvent criteriu de selectie al utilizatorilor.
c. Servere OLAP Regionale
In conditiile existentei unei companii multinationale, exista mai multe locatii de unde utilizatorii se conecteaza la cuburile OLAP. Spre exemplu, daca server-ul de DataWarehouse si serverul OLAP se afla in SUA, iar numerosi utilizatori utilizatori din Europa se conecteaza la aceste cuburi OLAP, este evident ca utilizatorii din America de Nord vor fi favorizati datorita unei viteze de comunicare superioare fata de cea de care beneficiaza utilizatorii din Europa.
In astfel de situatii este recomandata utilizarea de servere OLAP regionale, care sa aduca sursa de date mai aproape de utilizatori.Astfel, un server OLAP regional in Europa rezolva, pentru utilizatorii de pe continent, problema constituita de o slaba conexiune de retea intre Europa si SUA. Cuburile vor fi procesate in fiecare noapte pe serverul OLAP de productie din SUA si replicate dupa aceea pe serverul regional din Europa, urmind ca utilizatorii din fiecare locatie geografica sa se conecteze la serverul cel mai apropiat, imbunatatind astfel radical timpul de raspuns la interogare.
In speranta ca aceste informatii va vor fi de folos , inchei aici prezentarea legata de Imbunatatirea performantei cuburilor OLAP in Analysis Services 2000.
Spor la treaba.
Guse Nicolae
Business Intelligence Engineer
Ubisoft