Ocena efektywności architektur OLAP

Zasadniczą ideą systemów analitycznych jest zapewnienie zarządzającym efektywnego dostępu do właściwej, wiarygodnej, dostarczanej na czas informacji w celu wspomagania podejmowania decyzji, wspierających realizację strategii organizacji.Takie systemy bazując na hurtowniach danych (ang. Data Warehouse – DW) są zdolne do analitycznego przetwarzania danych na bieżąco (ang. On-Line Analytical Processing – OLAP).

OLAP cechuje możliwość:

• wykonywania analiz wielowymiarowych wg złożonych kryteriów wyszukiwania,

• interaktywnego raportowania bez znajomości języków programowania,

• uzyskiwania odpowiedzi na skomplikowane i często niestandardowe (ang. ad hoc) zapytania w trybie bieżącym.

OLAP zdeterminowany jest zakresem czasowym i liczebnością przechowywanych danych. Analizy wielowymiarowe powinny być przeprowadzane na jak największej liczbie danych gromadzonych w organizacjach. Do analiz przekrojowych, wg złożonych kryteriów wyszukiwania, potrzebne są dane z całego okresu działalności organizacji i takie dane muszą być dostępne. Celem OLAP jest generowanie przekrojowych raportów ze wszystkich dziedzin działalności organizacji wg różnych kierunków analizy np. wymiarów, hierarchii. Dla pełniejszej analizy stosuje się różne techniki przetwarzania analitycznego np. rachunek prawdopodobieństwa, wnioskowanie statystyczne, analizy: regresji, korelacji, trendów, wrażliwości, czy analizy typu „co, jeśli”.

Architektura OLAP transformuje różnorodne zbiory danych w zintegrowaną informację decyzyjną przy pomocy komponentów tj.: motor bazy danych, motor ekstrakcji danych, motor OLAP, motor eksploracji danych, repozytorium metadanych – muszą stanowić dobrze zintegrowany system. Jak na ironię, ta architektura sama w sobie stała się tak złożona, że stanowi źródło coraz poważniejszych problemów integracyjnych.

Architektura OLAP pozwala na prezentację danych w postaci wielowymiarowej, odmiennej od tradycyjnie stosowanej w bazach danych znormalizowanej struktury relacyjnej. O ile przedmiotem relacyjnego modelu danych są pojedyncze rekordy danych i pojedyncze transakcje wykonywane w danym momencie czasu, to w modelu wielowymiarowym są analizowane skutki wielu transakcji dokonywanych w pewnym przedziale czasu lub pewnym obszarze analizy [DIN1999, KIRE1998, GOR2000a].

Wszystkie architektury OLAP wymagają tworzenia wielowymiarowej struktury danych, w której wymiary reprezentują „obiekty” istotne z punktu widzenia prowadzonej analizy. W takiej strukturze danych, określanej potocznie jako „sześcian” lub „kostka” danych użytkownicy prowadzą analizy korzystając ze specjalizowanego motoru OLAP.

Motory OLAP pozwalają użytkownikom na prezentowanie dowolnych widoków danych sumarycznych, a także rozwijanie tych danych do poziomu danych szczegółowych.

Struktury wielowymiarowe mogą być posadowione w dedykowanych, trwałych bazach wielowymiarowych, w tymczasowych „mikro-kostkach” rezydujących w pamięci lub w bazach relacyjnych (w postaci schematów gwiazdy lub płatka śniegu) [GOR2003a, GORF1999, KIM1995].

W architekturze OLAP wyróżniamy motory [DIN1997, GOKO1999b, BLA1998]:

• MOLAP (OLAP wielowymiarowy; ang. Multidimensional On-Line Analytic Processing Multidimensional,) – do prowadzania analiz wykorzystuje serwer wielowymiarowej bazy danych MDDB (ang. Multidimensional Database). W tej architekturze dane muszą być przechowywane wielowymiarowo, jeżeli mają być wielowymiarowo analizowane i prezentowane. Cechą charakterystyczną tych baz danych jest pełna agregacja danych.

• DOLAP (OLAP Desktop)– to motor MOLAP operujący na plikach lub bazach danych zainstalowanych lokalnie, na stacjach klienta (brak serwera).

• ROLAP (OLAP relacyjny; ang. Relational On-Line Analytic Processing) – do prowadzania analiz i wielowymiarowej prezentacji korzysta z danych przechowywanych w relacyjnej bazie danych (RDB) o specjalizowanej strukturze, najczęściej gwiazdy (ang. Star) lub płatka śniegu (ang. Snowflake). Dostęp do danych jest realizowany na poziomie zwykle złożonych zapytań SQL. Dane mogą być wstępnie agregowane lub potrzebne agregaty są wyliczane w trakcie wyszukiwania danych.

• HOLAP (OLAP hybrydowy; ang. Hybrid OLAP) – to architektura mieszana pozwalająca użytkownikom na korzystanie (nie zawsze jednocześnie) z dwóch baz danych: wielowymiarowej lub relacyjnej. HOLAP wzbogaca architekturę OLAP o mechanizm semafora serwerów ROLAP i MOLAP.

Ze względu na sposób przechowywania i przetwarzania danych najważniejsze są dwie architektury MOLAP i ROLAP, dwie pozostałe są ich pochodnymi.

Architektura MOLAP opiera się na predefiniowanych wielowymiarowych tablicach zawierających zagregowane dane załadowane z różnych zasobów danych (rysunek 1). Dane są agregowane wg różnych hierarchii i wymiarów, tak by użytkownik mógł otrzymać wymagany widok danych [KIRE1998, GOR2003a, BLA1998]. Dane są przechowywane na dedykowanym serwerze wielowymiarowej bazy danych. Działające w oparciu o serwery MDDB systemy MOLAP mogą wizualizować tablice danych o wielu wymiarach.Architektura MOLAP zapewnia:

• przechowywanie danych zagregowanych i przeliczonych w postaci predefiniowanej „kostki”, gotowych do zaawansowanych analiz,

• wykorzystanie możliwości MDDB na stacjach użytkowników,

• zarówno zaawansowane rozwijanie danych zagregowanych (ang. drill data) jak i korzystanie z gotowych raportów dzięki serwerowi MDDB,

• uzyskiwanie odpowiedzi wciąż na te same dobrze zdefiniowane i powtarzane pytania analityczne oraz brak odpowiedzi na zapytania niestandardowe.

• rozwijanie i raportowanie danych atomowych w stopniu niedostatecznym.

Zwolennicy architektury MOLAP uważają, że większość systemów wspomagania podejmowania decyzji (ang. Decision Support Systems – DSS) operuje właśnie na takim skończonym, zamkniętym zbiorze danych zagregowanych i że brak lub ograniczenie dostępu do danych atomowych (źródłowych) z zasobów pierwotnych nie jest istotną wadą [RUS2000].

Ponadto pilotażowe wdrożenia zaawansowanych a zarazem bardzo kosztownych technologicznie rozwiązań tj. projekt T3 [MIC2001] pozwalają na składowanie na serwerach MDDB milionów rekordów (co jeszcze niedawna było nie możliwe) i koegzystencję danych zagregowanych i danych atomowych.

Architektura ROLAP została oparta o relacyjne bazy danych, które służą do przechowywania „wirtualnych kostek danych” (rysunek 2). Typowym sposobem przechowywania takich kostek danych jest schemat gwiazdy, schemat płatka śniegu lub inna wielowymiarowa struktura zorientowana (ang. summary – oriented structure) w bazie relacyjnej [DIN1997, BLA1998, RUS2000, FRGK2000].

Motor ROLAP jest warstwą logiczną, która tłumaczy żądania użytkownika na zapytania SQL. Możliwe są dwa skrajne sposoby działania:

• Motor ROLAP kieruje zapytania do danych źródłowych w relacyjnych bazach danych i dokonuje niezbędnych agregacji danych oraz wykonuje obliczenia na bieżąco, by utworzyć podsumowania i przedstawić wyniki użytkownikom w wielowymiarowym formacie;

• W procesie ETL (ang. Extraction, Transformation & Load process- ETL) dane z zasobów pierwotnych są ładowane do relacyjnej hurtowni danych oraz wykonywane są niezbędne agregacje – natomiast motor ROLAP kieruje zapytania SQL do danych źródłowych i częściowo zagregowanych w relacyjnej hurtowni danych.

Częściej stosowany jest drugi z tych sposobów. Po zdefiniowaniu modelu hurtowni danych, dane z zasobów pierwotnych (systemów OLTP (ang. On-Line Transactional Processing) lub obszaru pośredniego) są ładowane do bazy relacyjnej. Jeżeli model danych wymaga tego, wykonywane są procedury agregacji danych. Następnie w celu zoptymalizowania czasu wykonywania zapytań tworzone są indeksy. Użytkownik zleca wykonanie analiz wielowymiarowych motorowi ROLAP, który dynamicznie transformuje żądanie na zapytania SQL. Zapytania są przesyłane do motoru RDBMS, przetwarzane, a rezultat wielowymiarowy zostaje zwrócony użytkownikowi.Obliczenia agregujące wykonywane są przez motor ROLAP i motor RDBMS (dodatkowe tablice) oraz na stacji użytkownika.

Przy wyborze obliczeń agregujących projektant kieruje się następującymi przesłankami [GOFR1999, FRGK2000, GOR2003a]:

• analizą raportów, które będą realizowane w systemie (tworzenie agregatów wspomagających wykonanie tych raportów),

• analizą zapytań zadawanych przez użytkowników (tworzenie agregatów przyśpieszające udzielanie odpowiedzi na te pytania).

Utworzone struktury agregujące są wypełniane (aktualizowane) danymi w procesie ETL. W chwili obecnej realizacja struktur agregujących w oparciu o perspektywy zmaterializowane (Oracle, Informix Red Brick) pozwala na automatyczną aktualizację struktur bezpośrednio po wypełnieniu struktur bazowych. W przypadku wykorzystywania tablic jako struktur agregujących, za aktualizację struktur odpowiedzialny jest proces ekstrakcji [GORK1999, INF2001, ORA2001, GOR2003b].

Pierwotnie SQL był projektowany dla jednowymiarowych zapytań zorientowanych transakcyjnie, a nie dla złożonych zapytań wielowymiarowych. Architektura ROLAP musi przekroczyć te ograniczenia standardowego SQL generując wielokrotne zapytania SQL (ang. multipass SQL). Wymaga to, dla zachowania rezultatów każdego przejścia, stosowania w relacyjnej bazie danych wielu tablic pośrednich [RUS2000].

Tymczasem motory RDBMS przechodzą naturalną ewolucję w kierunku wsparcia analiz wielowymiarowych (wbudowanie motoru OLAP w bazę danych – ORACLE 9i). Już obecnie wiele z nich posiada bogaty zestaw funkcji wykorzystywanych w raportowaniu, np.:

• agregacji wyników na różnych poziomach (ang. rollup, cube)

• klasyfikacji wyników (ang. rank).

Generalnie architektura ROLAP cechuje się:

• organizacją danych w strukturze „gwiazdy”, „płatka śniegu”, „konstelacji faktów”, „gwiazdy skaskadowanej” umieszczonej w relacyjnej bazie danych,

• agregacją danych w hurtowni danych lub na bieżąco,

• wykonaniem operacji transformowanych na zapytanie SQL,

• dostępem do danych sumarycznych jak i do danych szczegółowych

• szerokim zakresem realizacji zapytań wyspecyfikowanych jak i ad hoc.

Najistotniejszym zastrzeżeniem do architektury ROLAP jest niska wydajność zapytań i długi czas oczekiwania na odpowiedź. Jednak wydajność nie jest jedynym kryterium oceny efektywności architektury OLAP. System DSS ma bowiem zapewnić podejmowanie racjonalnych decyzji, natomiast szybkość podejmowania decyzji jest zagadnieniem drugoplanowym. Użytkownicy wykorzystujący zapytania ad hoc zgadzają się na niską wydajność w zamian za możliwość zadawania jednostkowych, nieoczekiwanych zapytań do danych szczegółowych w ogromnym zbiorze danych [RUS2000]. Poza tym wielu dostawców ROLAP wprowadza specjalizowane serwery DSS i rozbudowane podsystemy pamięci podręcznej umożliwiające wykorzystanie wyników wcześniej wykonywanych raportów co pozwala na szybsze wyświetlenie gotowego raportu (wcześniej wykonanego w tle) [GOKO1999b].

Powyższy ogląd zagadnień związanych z architekturą OLAP wyraźnie wskazuje na potrzebę określenia praktycznych obszarów stosowania architektury ROLAP oraz architektury MOLAP. Pomocną w tym może stać się analiza ich efektywności.

Analizę efektywności architektur OLAP należy prowadzić w perspektywie wydajności zapytań i raportowania danych, skalowalności, kosztów procesu ładowania i agregowania danych oraz jej wielowarstwowości.

Budowanie struktury wielowymiarowej w architekturze OLAP odbywa się zasadniczo w dwojaki sposób:

• wielowymiarowa struktura danych jest tworzona w zorientowanym wsadowo procesie ekstrakcji danych, procesie ETL czasu rzeczywistego lub kombinacji tych procesów.

• jednorazowe załadowanie danych do struktury wielowymiarowej tworząc kostkę w bazie (pliku) lub w pamięci.

Sposób, w jaki architektura OLAP rozwiązuje te aspekty określa zależność między wydajnością i wymaganiami analitycznymi – ilustruje to poglądowo rysunek 3., w układzie wydajność, poziom analizy, rozmiar danych.

Wydajność jest odwrotnie proporcjonalna do czasu reakcji systemu na zapytanie użytkownika. Czas ten zależy od złożoności zapytania (poziomu wymaganej analizy) i stopnia agregacji danych. Im bardziej zagregowane dane, tym krótszy czas reakcji i wyższa wydajność.Architektura MOLAP oferuje najlepszy czas odpowiedzi na typowe pytania użytkowników. Wymaga to jednak tworzenia dedykowanych wielowymiarowych baz danych w trakcie procesu ekstrakcji, kosztownych motorów ETL, wykwalifikowanego personelu informatycznego, zastosowania procedur przesyłu danych z baz transakcyjnych do hurtowni oraz narzędzia zarządzania i monitorowania procesu ETL.

Budowanie struktur wielowymiarowych „w locie” (jak to czasami ma miejsce w architekturze ROLAP) lub agregowanie danych w czasie realizacji zapytania SQL nie wymaga tak złożonego procesu ETL, ale wydajność jest dużo niższa (w skrajnych przypadkach zapytanie analityczne wykonuje się w czasie rzędu kilkudziesięciu minut).

Architektura ROLAP umożliwia, jeśli jest to niezbędne, wykonanie pełnego zakresu agregacji i uzyskanie przy generowaniu standardowych raportów wydajności porównywalnej z wydajnością MOLAP. O tym, które dane są agregowane, a które nie – decyduje projektant architektury ROLAP i systemu DSS [FRGK2000]. Agregacje pozwalają na wstępne przeliczenie danych (funkcje agregujące: SUM, COUNT, MAX, MIN i dowolne inne) oraz zapamiętanie wyników w dodatkowych strukturach. Proces przeliczania jest podobny do procesu wykonywanego w architekturze MOLAP z tym, że projektant/administrator jawnie dokonuje wyboru przeliczeń, które mają zostać wykonane. W ten sposób, w systemie istnieją struktury tylko rzeczywiście potrzebne do jego pracy i unika się, występującego w architekturze MOLAP, tworzenia struktur zbędnych. W krańcowym przypadku, agregacja w architekturze ROLAP, może osiągnąć całkowitą przestrzeń obejmującą wszystkie poziomy agregacji danych (najwyższy stopień agregacji danych), co oznacza, że w systemie jest przechowywany wynik każdego możliwego przeliczenia, analogicznie jak w MOLAP (z reguły przeliczenia dotyczą ograniczonego zestawu funkcji, np. funkcji agregujących).

Tendencja (zależna jednak od indywidualnych implementacji) jest taka, by architekturę MOLAP stosować dla modeli danych zaprojektowanych dla potrzeb dobrze zdefiniowanych zapytań analitycznych zadawanych okresowo [RUS2000], natomiast ROLAP powinien być stosowany tam, gdzie:

• istnieje potrzeba budowania „kostek” danych w czasie analizy,

• użytkownik zadaje pytania nietypowe, trudne do przewidzenia,

Z punktu widzenia wymagań analitycznych systemy DOLAP i HOLAP znajdują się pomiędzy tymi skrajnymi możliwościami i oferują pewien podzbiór zastosowań i wydajności architektur MOLAP lub ROLAP [GOKO1999b, GOR2003a].

Hurtownie danych stają się giga – terabajtowymi repozytoriami informacji obsługiwanymi przez motory OLAP. Co więcej, lawinowo rośnie liczba ich użytkowników; niektóre organizacje udostępniają swoje hurtownie tysiącom użytkownikom zewnętrznym. Dodatkowo, analitycy generują coraz bardziej wymagające zadania analizy danych. Stąd rośnie obciążenie obliczeniowe i potrzeba skalowalności architektur OLAP.Skalowalność architektury OLAP oznacza zdolność do rozwoju i zwiększania liczby wymiarów, liczby atrybutów, kategorii danych oraz liczby danych atomowych, bez konieczności tworzenia od nowa wszystkich raportów. Cecha ta silnie zależy od motoru OLAP, modelu danych, funkcjonalności serwera i stosowania architektury klient – serwer. Często decyduje o tym, czy środowisko zastosowane do stworzenia systemu DSS będzie nadal przydatne wraz z rozwojem organizacji i wymagań użytkowników.

Skalowalność danych gromadzonych w DW dla celów podejmowania decyzji może być mierzona w trzech skalach [HUR1998]:

• Głębokości odnosi się do liczby poziomów danych zagregowanych.

• Szerokości danych odnosi się do dostępności danych w odniesieniu do liczby wymiarów i atrybutów, które mogą być analizowane przez użytkownika.

• Atomowości danych odnosi się do ziarnistości danych szczegółowych (liczba wystąpień danych źródłowych).

Architektura MOLAP pozwala – generalnie – na obsługę ograniczonej liczby wymiarów oraz ograniczonej liczby danych źródłowych. Dla większości implementacji MOLAP ograniczona jest także liczba poziomów danych zagregowanych [GOKO2000a, GOKO1999b]. Poglądowo ilustruje to rysunek 4.

Im więcej danych szczegółowych jest przechowywanych w hurtowni danych i uwzględnianych w wyższych stopniach agregacji tym większa jest baza danych. Zachodzi wtedy zjawisko nazywane rozszerzaniem bazy danych dla celów analizy wielowymiarowej.

Współczynnik rozszerzania dla w pełni skonsolidowanych modeli jest bardzo wysoki i determinuje poniższy wzór na pojemność wszystkich danych zagregowanych w bazie wielowymiarowej:

gdzie: n – liczba wymiarów, 2n – współczynnik rozszerzenia, p – pojemność danych szczegółowych.

Przykład 1. Dla całkowicie zagregowanego, pięciowymiarowego modelu MOLAP współczynnik rozszerzenia wynosi 32. Oznacza to, że z 200 MB danych szczegółowych (transakcyjnych) otrzymujemy V[200Mb, 5] = 6,4 GB danych wielowymiarowych, a baza o pojemności 10 GB danych szczegółowych rozszerza się do 320 GB danych wielowymiarowych. Zjawisko to staje się jeszcze bardziej uciążliwe przy większej liczbie wymiarów. Zatem stosowanie modelu MOLAP o wysokim stopniu konsolidacji danych, przy dużych rozmiarach danych szczegółowych (ponad 1GB) i jednocześnie dużej liczbie wymiarów (ponad 10) staje się bardzo trudne – V[1GB, 10] = 1TB.

W dużych organizacjach przemysłowych, handlowych, bankowych czy ubezpieczeniowych, bazy danych szczegółowych znacznie przekraczają dziesiątki lub setki GB, a liczba wymiarów 20 czy 30 jest powszechna. Systemy DSS powinny pozwalać na analizę OLAP od najniższego poziomu ziarnistości danych, który jest istotny (poziom danych źródłowych) do maksymalnego uogólnienia i podsumowania danych.

Ograniczeń tych nie posiada architektura ROLAP. W efekcie DW klasy MOLAP pozwalają na efektywne gromadzenie i analizę danych do 50 GB, natomiast hurtownie klasy ROLAP dla wielu TB danych [GOR2003b]. Dlatego architektura ROLAP powinna być stosowana tam, gdzie konieczne jest przetwarzanie danych o różnej ziarnistości składowanych w ogromnych wolumenach danych [HUR1998, GOKO2000a].

W przypadku zastosowania najnowszych, pod względem technologicznych rozwiązań programowych i narzędziowych [MIC2000] możliwe jest osiągnięcie przez architekturę MOLAP skalowalności porównywalnej z architekturą ROLAP, jednak jest to okupione bardzo wysokimi kosztami.

Istotne dla czasu przetwarzania i reakcji na zapytania jest to, ile danych zagregowanych zostało przeliczonych wcześniej i zapisanych w bazie, a ile jest obliczanych w trakcie tworzenia raportu. Ponieważ przechowywanie danych zagregowanych zwiększa z kolei objętość bazy danych, to konieczne jest poszukiwanie rozsądnego kompromisu. Przechowywanie zbyt dużej liczby danych wstępnie przeliczonych powoduje także problemy z zarządzaniem tymi danymi i konieczność tworzenia dodatkowych indeksów.

Jeśli dane w bazie są wstępnie przetworzone, przeliczone i przygotowane do prezentacji (architektura MOLAP), to wydajność wyszukiwania i szybkość reakcji na zapytania użytkownika jest maksymalna, natomiast przetwarzanie wsadowe przy okresowym ładowaniu danych jest czasochłonne i wymaga pełnego zaangażowania zasobów komputera. Natomiast w systemach o niewielkiej agregacji danych (ROLAP) obciążenie systemu w czasie ładowania danych jest niewielkie, natomiast czasochłonne i bardziej angażujące zasoby systemu jest wyszukiwanie danych do prezentacji w trakcie realizacji zapytań [GOKO1999b]. Architektury MOLAP posiadają 80-100% danych zagregowanych – określa się je mianem systemów o wysokim stopniu agregacji danych. Typowe systemy w architekturze ROLAP posiadają 0-20% danych zagregowanych – mówimy o systemach o niskim stopniu agregacji danych.Ze wzrostem liczby danych zagregowanych następuje:

• zwiększenie czasu przetwarzania wsadowego, obciążenia procesora i kosztów przetwarzania przy ładowaniu bazy,

• zmniejszenie czasu reakcji na zapytanie, obciążenia procesora i kosztów przetwarzania przy prezentacji danych.

Ilustruje to rysunek 5 [MSTR1995].

Załóżmy, że przedstawiony wykres (rysunek 5) otrzymano dla kilkunastu wymiarów. Gdy liczba wymiarów zmniejszy się 2-5 razy, to linie wykresów nie przetną poziomu 100%. Gdy liczba wymiarów zwiększy się 3-4 razy, to już przy stopniu agregacji rzędu 30-50% krzywe przetwarzania wsadowego i krzywa całkowita mogą osiągnąć maksimum. Oznacza to, że DW o wysokim poziomie agregacji danych, dla obsłużenia dużej liczby wymiarów, wymagają większej mocy obliczeniowej systemu komputerowego.

Jeśli głównym celem aplikacji jest wysoka wydajność zapytań, to korzysta się z pełnej agregacji i indeksacji danych. Włączenie do modelu danych wszystkich możliwych agregacji i indeksów pozwala uzyskać zawsze krótki czas odpowiedzi. Oczywiście, odbywa się to kosztem wysokiego stopnia przetwarzania danych na etapie ładowania. Przykładami takich systemów są w pełni zagregowane struktury używane przez wielowymiarowe serwery baz danych (MOLAP) i w pełni indeksowane schematy płatka śniegu (ROLAP). Stopień konsolidacji danych dla takich baz przekracza poziom 80%. W umiarkowanie zagregowanych schematach, poprzez agregację najczęściej używanych tabel uzyskuje się krótki czas odpowiedzi dla większości zapytań. Dodatkowo, indeksy tworzy się na najczęściej używanych kluczach. Przykładem modelu danych w tej kategorii jest umiarkowanie zagregowany schemat gwiazdy i płatka śniegu (ROLAP). Stopień agregacji danych dla takich baz wynosi zwykle 20% – 80%.

Jeśli chcemy minimalizować czas ładowania danych, natomiast czas przetwarzania analitycznego nie jest krytyczny lub wykonywane raporty nie wymagają złożonego przetwarzania, to stosujemy schematy z niskim poziomem agregacji danych (0-20%). Przykładem modelu danych w tej kategorii jest podstawowy schemat gwiazdy z jedną centralną tabelą faktów i tabelami typu lookup dla każdego wymiaru.

Proces ładowania danych do DW jest realizowany w ściśle określonym czasie i zwykle wtedy, gdy systemy z danymi źródłowymi są mało aktywne. W przypadku organizacji o zasięgu lokalnym najczęściej ładowanie hurtowni odbywa się nocą. W organizacji o zasięgu globalnym dobowy przyrost nowych danych jest zwykle bardzo znaczący, a charakter wykonywanych analiz wymaga maksymalnej aktualności danych w hurtowni. W takich sytuacjach stosuje się specjalne mechanizmy przyrostowego ładowania danych.

Zakłócenia procesu ekstrakcji przerywają operację ładowania hurtowni danych. Zakłócenia mogą być spowodowane wystąpieniem błędów (np. nieprawidłowe dane, upadek RDBMS) lub uszkodzeń platform sprzętowych (np. awaria zasilania, uszkodzenie procesora) średnio, co trzydziesty proces ładowania danych zostaje przerwany [GOWO2003a]. W takim przypadku, zwykle dane już przetworzone są usuwane, a cały proces powinien być natychmiast wznowiony – w przeciwnym razie baza hurtowni będzie nieaktualna i niekompletna. Wtedy wykonanie przerwanego procesu przekłada się na kolejny cykl ładowania.

Akcja wznowienia procesu ekstrakcji polegająca na dokończeniu przerwanego procesu ładowania danych nazywa jest odtwarzaniem. W wyniku odtwarzania zbiór danych wynikowych ekstrakcji powinien się pokrywać ze zbiorem danych, który powstałby, gdyby nie doszło do jej przerwania. Algorytmy poszczególnych podprocesów ekstrakcji wspomagających odtwarzanie są modyfikowane, co nie tylko komplikuje projekty, ale przede wszystkim obniża wydajność przetwarzania [GOWO2003b].

Zanim skonstruuje się DW i metadane, należy określić ich wzajemną lokalizację. W fazie wstępnej projektu należy zadecydować, czy stosować bazy wielowymiarowe czy relacyjne, i jaką przyjąć konfigurację architektury OLAP i z jakich motorów/serwerów korzystać. Następnie należy oszacować początkowy rozmiar danych, szybkość ich przyrostu, czas trwania ekstrakcji danych i zaangażowanie zasobów w procesie ładowania przyrostowego i przetwarzania analitycznego.Wyróżnia się trzy podstawowe konfiguracje architektury OLAP [GOKO2000a]:

• Konfiguracja jednowarstwowa (ang. One-tier architecture)

• HD, metadane oraz oprogramowanie DSS na stacji klienta.

• Konfiguracja dwuwarstwowa (ang. Two-tier architecture):

• Oprogramowanie końcowego użytkownika na stacji klienta,

• HD i metadane na zdalnym serwerze.

• Konfiguracja trójwarstwowa (ang. Three-tier architecture)

• Oprogramowanie końcowego użytkownika na stacji klienta,

• Oprogramowanie DSS oraz metadane na serwerze OLAP

• HD na serwerze baz danych.

Obecnie jednak do architektur OLAP dołączono warstwę serwerów WWW.

Ogólnie można wykazać wyższą wydajność serwera ROLAP w architekturze wielowarstwowej aniżeli w architekturze dwu- lub jednowarstwowej ROLAP i MOLAP.

Wynika to z większej:

• efektywności wykonania operacji SQL w architekturze wielowarstwowej,

• wydajności architektury ROLAP przy wzroście liczby wymiarów lub liczby atrybutów.

Również zakres możliwości reorganizacji danych jest większy w przypadku serwerów ROLAP niż MOLAP. Co więcej, na sposób zarządzania serwerem OLAP w istotny sposób wpływa konfiguracja architektury – wielowarstwowa architektura ROLAP pozwala na najlepszą optymalizację przetwarzania zapytań.

Zatem analizując charakterystykę serwera OLAP należy zwrócić uwagę na:

• wielowarstwowość architektury klient / serwer – liczba warstw w istotny sposób wpływa min. na sposób zarządzania serwerem i na wydajność niektórych operacji,

• architekturę wielowymiarową lub relacyjną,

• sposób obliczania sum (wstępnie czy dynamicznie),

• strukturę hiperprzestrzeni (ang. hypercube) lub wieloprzestrzeni (ang. multicubes) stosowaną w serwerach MOLAP,

• wymagania pamięci – architektura MOLAP potrzebuje więcej pamięci na tworzenie i przechowywanie danych w postaci hiperprzestrzeni, natomiast ROLAP na przetwarzanie zapytań SQL i przechowywanie odpowiedzi.

W praktyce architektura OLAP jednak zwykle jest wielowarstwowa, uruchamiana na maszynach o dużej mocy obliczeniowej [GOR2003a].Na rysunku 6. pokazano heterogeniczne środowisko OLAP i DW, w którym zastosowano komercyjne narzędzia i serwery OLAP.

Korzyści dla użytkownika końcowego ze stosowania infrastruktury trójwarstwowej i wielowarstwowej są następujące:

• wykonywanie analiz danych w tle i zmniejszenie obciążenia maszyny klienta,

• zarządzanie zadaniami w dowolnych przedziałach czasu,

• dzielenie dostępu do wyników w ramach hurtowni tematycznych.

Korzyści dla administratora takiego rozwiązania są następujące:

• efektywne dzielenie zasobów między użytkowników,

• monitorowanie pracy użytkowników i stopnia wykorzystania zasobów,

• realizacja wybranych zadań w godzinach mniejszego obciążenia zasobów,

• skalowanie architektury systemu DSS w miarę potrzeb,

• wprowadzanie zmian w środowisku DSS bez oddziaływania na aplikacje końcowe.

Ważnym problemem w projektowaniu wielowarstwowej architektury OLAP jest wydajność samych serwerów OLAP. Na razie brak zatwierdzonych i powszechnie uznawanych testów wydajności serwerów OLAP. Organizacja OLAP Council opracowała zestaw testów APB-1 OLAP Benchmark, jednak nie wszyscy producenci poddają swoje oprogramowanie tym testom i dlatego trudno jest porównać wydajność różnych rozwiązań.

Dla oceny wydajności środowiska DSS istotne są:

• czas reakcji systemu na zapytania (ang. Query response times),

• liczba zapytań obsługiwanych w ciągu minuty (ang. Queries per Minute),

• czas wykonania zapytania (ang. Query Execution),

• sposób operowania tablicami o niewielkim stopniu wypełnienia (ang. Sparse matrix),

• czas ładowania danych (ang. Bulk Load),

• wydajność odświeżania przyrostowego (ang. Incremental Load),

• sposoby obliczeń (rekalkulacji),

• sposoby reorganizacji.

W przypadku producentów platform mamy szeroko stosowane testy baz danych TPC-D, które oceniają sprzęt i relacyjną bazę danych symulując zapytania typowe dla środowiska DSS, jednak testy te nie uwzględniają i nie porównują wydajności środowisk oprogramowania DSS, a jedynie pozwalają na przybliżoną ocenę serwerów i wybranej relacyjnej bazy danych do pracy ze środowiskiem DSS.

W tabeli 1. zawarto charakterystykę architektur ROLAP i MOLAP.

W eksploatowanym środowisku ERP w jednej z polskich elektrowni wdrażano system wspomagania decyzji i analizy zasobów ludzkich (ozn. DSS/HR). System DSS/HR jest oparty o architekturę ROLAP/ MicroStrategy [GOR2003a]. Wdrożony system DSS/HR udostępnia ponad 150 różnych perspektyw zmaterializowanych. System DSS/HR posadowiony był na komputerze HP K410 o konfiguracji: 2 procesory, 512MB RAM, macierz dyskowa, system HP-UX B.10.01 U 9000/829 i serwer Informix 7.x. Przy analizie raportów DSS/HR skoncentrowano się na: obciążeniu jednostki centralnej CPU, obciążeniu dysków, pracy systemu operacyjnego. Na rysunku 7. przedstawiono wyniki pokazujące stopień wykorzystania CPU przez różne procesy występujące w systemie. Monitorowano grupy procesów: usr – procesy użytkownika, sys – procesy systemowe, wio – procesor bezczynny (we/wy), idle – procesor bezczynny.Rysunek 8. przedstawia wpływ systemu DSS/HR na wykorzystanie dysków. Parametr %busy pokazuje % czasu, podczas którego następowała obsługa zleceń przez urządzenie. Przedstawione wyniki pokazują, że posadowienie na jednej maszynie systemów transakcyjnych i systemów DSS/EIS kończy się zazwyczaj niepowodzeniem, ponieważ cechuje je bardzo różny sposób obciążania zasobów systemowych.

Na podstawie własnych doświadczeń i powyższej analizy sformułowano zbiór zaleceń praktycznych na stosowanie architektury ROLAP oraz architektury MOLAP.Architekturę ROLAP zaleca się stosować, jeśli:

• aplikacje analizują dużą liczbę danych,
• przewiduje się potrzebę dostępu do dużej liczby danych szczegółowych,
• czas reakcji systemu na zapytania nie jest krytyczny,
• przewiduje się szybki rozwój naszego systemu DSS i konieczność zmian struktur danych lub gwałtowny wzrost danych szczegółowych (ponad 100 GB),
• poszukuje się globalnej wydajności, skalowalności, dużych możliwości rozbudowy, centralnej i tematycznych HD,
• istnieje potrzeba zadawania pytań „ad hoc” ( nietypowe raporty),
• zarządzanie tablicami podsumowań wymaga bardzo silnego procesu ETL,
• posiada się już relacyjną hurtownię danych w architekturze ROLAP,
• projektuje się hurtownie centralne i dziedzinowe.

Architekturę MOLAP preferuje się w przypadku, jeśli:

• tworzony system DSS nie operuje na zbyt wielu danych (do 50GB);
• konieczny jest bardzo krótki czas odpowiedzi na zapytania użytkowników przy ograniczonej liczbie danych i wymiarów;
• nie jest potrzebna zmiana liczby wymiarów struktury wielowymiarowej;
• system DSS ma generować gotowe, predefiniowane raporty (bez analiz ad hoc);
• ma umożliwiać symulowanie danych i ich zapis do hurtowni danych;
• tworzy się niewielki system DSS w oparciu o hurtownie tematyczne, o wysokiej wydajności lokalnej i szybkiej implementacji;
• brak wykwalifikowanego personelu administratorów baz danych.

Zależnie od charakteru zastosowań architektury OLAP i systemu DSS zróżnicowane są wymagania dotyczące metod modelowania, skalowalności, potrzeb funkcjonalno-analitycznych oraz niezbędnej wydajności. Dalsze poszukiwania idealnej architektury OLAP powinny koncentrować się na perspektywie odtwarzania procesu ładowania danych do DW, odświeżania DW w czasie rzeczywistym, wielowymiarowym modelowaniu danych oraz rozproszonych i równoległych architekturach i ich bezpieczeństwie [GOWO2003b, GOMA2003, GOFR2003].