Wykład 2. Architektura hurtowni danych. Model pojęciowy, logiczny i fizyczny. Wielowymiarowy model danych.

Streszczenie

W tym wykładzie omawiamy architekturę hurtowni danych i jej fizyczne implementacje. Przedstawiamy także różnice między rozwiązaniem relacyjnym, wielowymiarowym i hybrydowym. Podkreślamy również, że proces projektowania hurtowni danych przebiega w trzech etapach – najpierw tworzony jest model pojęciowy, następnie logiczny, a na końcu fizyczny. Ten sposób modelowania dotyczy wszystkich elementów hurtowni danych – centralnej hurtowni, procesów ETL, hurtowni tematycznych itd. Na zakończenie tego wykładu wyjaśniamy, czym jest wielowymiarowy model danych.

Ogólna architektura hurtowni danych

Strukturę hurtowni danych tworzą kolejne warstwy danych, przy czym każda następna warstwa jest zasilana z poprzedniej. Najniższą warstwę stanowią, bardzo często heterogeniczne i rozproszone, źródła danych, którymi mogą być relacyjne bazy danych (np. systemy transakcyjne), inne systemy zastane w przedsiębiorstwie, arkusze kalkulacyjne, pliki tekstowe, pliki XML, urządzenia rejestrujące itp. Źródła te mogą być bardzo zróżnicowane pod względem sposobu dostępu, a także struktury logicznej, wielkości i jakości danych.

Środkową warstwę stanowi centralna hurtownia danych (podstawowa, korporacyjna), która jest podstawowym miejscem przechowywania ukierunkowanej tematycznie informacji pochodzącej ze źródeł. W centralnej hurtowni danych przechowywane są zarówno dane szczegółowe (choć w porównaniu ze źródłami są one zwykle zagregowane), jak i częściowe podsumowania (agregacje). Centralna hurtownia jest cyklicznie (np. w cyklu dobowym) zasilana ze źródeł danych, przy czym zakładamy, że nowe dane dołączają do danych już istniejących, a nie je zastępują (problemy związane z przechowywaniem pełnej historii będą omówione w dalszej części wykładu). Dane w hurtowni mogą być gromadzone na przestrzeni wielu lat.

Ponieważ w centralnej hurtowni danych gromadzone są ogromne ilości danych dotyczące działalności całej firmy, często kolejną warstwę stanowią tak zwane hurtownie tematyczne (data marts, hurtownie oddziałowe), tworzone na potrzeby użytkowników z konkretnych działów. Ilość danych w hurtowniach tematycznych jest istotnie mniejsza, gdyż po pierwsze, dane tam gromadzone dotyczą pewnego wycinka działalności firmy, a po drugie, dane, które tam trafiają są na ogół silniej zagregowane niż dane w hurtowni. Ze względu na mniejszy rozmiar i możliwość pracy lokalnej, hurtownie tematyczne pozwalają na sprawniejsze operowanie danymi. Mogą być zaimplementowane jako relacyjne bazy danych lub specjalne struktury wielowymiarowe.

Na poniższym rysunku przedstawiona jest podstawowa architektura hurtowni danych:

Rysunek 2.1. Architektura hurtowni danych

Rysunek 2.1. Architektura hurtowni danych

Czasami między źródłami a centralną hurtownią danych wprowadza się warstwę pośrednią, zwaną magazynem danych operacyjnych (operational data store, ODS). Gdy występuje ta warstwa dane ze źródeł ładowane są najpierw do ODS, a następnie do hurtowni. Magazyn danych operacyjnych, podobnie jak sama hurtownia, zawiera dane zintegrowane i zorganizowane tematycznie, ale w przeciwieństwie do niej jest częściej aktualizowany i zawiera aktualniejsze (ale ulotne) informacje, często bardzo szczegółowe (w niewielkim stopniu zagregowane). Tworzenie tej pośredniej warstwy może odciążyć centralną hurtownię od części zadań związanych z aktualizacją danych, a ponadto bywa uzasadnione ze względów technicznych (np. znacznego geograficznego rozproszenia źródeł danych).

Na poniższym rysunku przedstawiona jest architektura hurtowni danych z magazynami danych operacyjnych:

Rysunek 2.2. Architektura hurtowni danych z magazynami danych operacyjnych

Rysunek 2.2. Architektura hurtowni danych z magazynami danych operacyjnych

Rodzaje implementacji

W praktyce spotyka się trzy podstawowe architektury fizyczne hurtowni danych: architekturę scentralizowaną, federacyjną oraz wielowarstwową.

W architekturze scentralizowanej wszystkie dane wykorzystywane do analiz w przedsiębiorstwie są przechowywane w jednej fizycznej hurtowni danych, przez co najlepiej sprawdza się ona w firmach o scentralizowanej działalności operacyjnej. Zaletami takiego rozwiązania są: łatwiejsze tworzenie i administrowanie w porównaniu z innymi rozwiązaniami, znacznie uproszczony dostęp do danych dzięki ujednoliceniu modelu, wspólne metadane oraz brak konieczności przesyłania danych (poza ładowaniem). Zasadniczą wadą jest mniejsza wydajność z uwagi na konieczność wykonywania wszystkich zapytań i modyfikacji danych w jednej, centralnej bazie.

Rysunek 2.3. Architektura scentralizowana

Rysunek 2.3. Architektura scentralizowana

Alternatywnym rozwiązaniem jest architektura rozproszona sprawdzająca się przy dużych rozwiązaniach. Jej zaletami są: skalowalność, większa odporność na awarie, krótszy czas działania z uwagi na umieszczenie danych bliżej użytkownika końcowego, zmniejszenie przeszukiwanego obszaru danych oraz możliwość autonomii oddziałów. Wady to: trudniejsza budowa i konserwacja, trudniejsze odświeżanie, czasami trudniejsza realizacja zapytań analitycznych oraz trudniejsza modyfikacja procesów analitycznych.

Architektura federacyjna to architektura rozproszona, w której logicznie jednorodne dane fizycznie przechowywane są w różnych bazach danych zlokalizowanych w jednym lub wielu systemach komputerowych. Przechowywane lokalnie tematyczne hurtownie danych zawierają informacje właściwe konkretnemu działowi danej instytucji. Cechą charakterystyczną jest to, że centralna hurtownia danych jest wirtualna (stanowi jedynie wspólny model logiczny i pojęciowy danych), a fizycznym miejscem przechowywania danych są magazyny danych operacyjnych oraz zmaterializowane hurtownie tematyczne.

Rysunek 2.4. Architektura federacyjna

Rysunek 2.4. Architektura federacyjna

Architektura wielowarstwowa to architektura, w której hurtownię centralną będącą rzeczywistą, fizyczną bazą danych uzupełniają kolejne poziomy lokalnych tematycznych hurtowni danych, zawierających kopie danych poprzedniej warstwy lub ich podsumowania. Z uwagi na wydajność, wszystkie warstwy są materializowane.

Rysunek 2.5. Architektura wielowarstwowa

Rysunek 2.5. Architektura wielowarstwowa

Architektura relacyjna i wielowymiarowa

Tworząc hurtownię możemy zdecydować się na przechowywanie danych na serwerze relacyjnej bazy danych (RDB, Relational Database) lub wielowymiarowej bazy danych (MDDB, Multidimensional Database). Jeśli decydujemy się na rozwiązanie relacyjne, mówimy o architekturze ROLAP (Relational OLAP), a jeśli na wielowymiarowe, mówimy o architekturze MOLAP (Multidimensional OLAP).

W architekturze ROLAP dane (oraz agregacje) przechowywane są w tabelach relacyjnych, przy czym schemat bazy danych zaprojektowany jest w taki sposób, aby odzwierciedlić wielowymiarową strukturę danych. Charakterystyczne dla tego podejścia schematy gwiazdy, płatka śniegu oraz konstelacji faktów zostaną omówione w wykładzie 3. Zaletami tego rozwiązania są przede wszystkim duża elastyczność, skalowalność w zakresie liczby wymiarów i złożoności hierarchii oraz szeroki zakres realizacji zapytań predefiniowanych i ad hoc, wadą jest zróżnicowana wydajność, na ogół niższa niż w rozwiązaniach MOLAP. Architektura ROLAP nadaje się do nawet bardzo dużych zastosowań (> 10TB).

W architekturze MOLAP dane (oraz agregacje) przechowywane są w wielowymiarowych tablicach, zwanych też kostkami danych. Podstawową zaletą tego rozwiązania jest bardzo wysoka wydajność wyszukiwania i prezentacji danych, wadą jest między innymi mała elastyczność. Jeśli chcemy cokolwiek do takiej kostki dodać lub zmodyfikować, musimy ją usunąć i stworzyć od nowa. Kolejną wadą jest to, że kostka jest taką „zamkniętą puszką”, to znaczy dane są mocno agregowane już w momencie ekstrakcji, co przekłada się na brak lub ograniczenie dostępu do danych atomowych. Możliwa jest zatem efektywna realizacja zapytań predefiniowanych (czyli określonych a priori), natomiast niemożliwa (lub bardzo utrudniona) realizacja zapytań ad hoc. Architektura MOLAP charakteryzuje się też niską skalowalnością. Przyjmuje się, że tego rodzaju rozwiązanie nadaje się dla stosunkowo małych zastosowań (do 50 GB). [4]

Jak widać, obydwa podejścia mają zarówno wady i zalety, stąd też pomysł na połączenie obu podejść, zwany architekturą HOLAP (Hybrid OLAP). W tym rozwiązaniu dane przechowywane są w tabelach na serwerze relacyjnym, zaś złożone przetwarzanie danych jest realizowane na serwerze wielowymiarowym.

Model pojęciowy, logiczny i fizyczny

Proces projektowania hurtowni danych przebiega w trzech etapach. Najpierw tworzony jest model pojęciowy, następnie logiczny, a na końcu fizyczny. Ten sposób modelowania dotyczy wszystkich elementów hurtowni danych – centralnej hurtowni, procesów ETL, hurtowni tematycznych itd. Podstawową zaletą takiego trójetapowego sposobu projektowania jest to, że decyzje dotyczące projektu logicznego i fizycznego mogą być podejmowane i implementowane bez wpływu na model pojęciowy, który odzwierciedla wymagania firmy. Kolejna, równie istotna w przypadku hurtowni zaleta jest taka, że dzięki modelowi pojęciowemu użytkownikom biznesowym jest o wiele łatwiej zrozumieć dane w hurtowni, co przekłada się na dużo efektywniejsze korzystanie z niej.

Poszczególne modele można scharakteryzować następująco:

Warto pamiętać, że hurtownia danych to przedsięwzięcie nie tylko informatyczne, ale też organizacyjne. W skład projektu i realizacji hurtowni danych wchodzi np. ustalenie procedur i instrukcji postępowania, schematów replikacji danych, organizacja przechowywania i transportu kopii zapasowych itp. Tworzenie hurtowni danych to też okazja do dodefiniowania pojęć, które zdają się być oczywistymi, a przy wnikliwszym zastanowieniu, okazują się być wcale nie oczywiste. Jednym z takich pojęć jest pojęcie „sprzedaży”. Czym jest sprzedaż? W którym momencie możemy mówić o wystąpieniu faktu sprzedaży, zwłaszcza w firmie internetowej? W momencie złożenia zamówienia? W momencie wydania towaru z magazynu? W momencie wystawienia faktury? To trzeba koniecznie ustalić.

Wielowymiarowy model danych

Podstawowym modelem logicznym dla systemów OLAP jest wielowymiarowy model danych (MDD, Multidimensional Data Model). W modelu wielowymiarowym analizujemy fakty wzdłuż wymiarów. Fakt to pojedyncze zdarzenie będące podstawą analiz (np. fakt sprzedaży, fakt dokonania operacji na koncie bankowym, fakt wzięcia kredytu itp.), w tym przypadku będące po prostu zbiorem miar, czyli numerycznych wartości opisujących zdarzenie (miarami są np. liczba sztuk zakupionych produktów, łączna kwota sprzedaży, zysk, łączna kwota operacji bankowych, kwota wziętego kredytu itp.). Wartości miar zależą od wymiarów, po których dane są analizowane. Przykładowo wymiarami analizy mogą być produkty, klienci, obszary sprzedaży, czy też daty sprzedaży. Mówiąc matematycznie, miara jest reprezentowana jako punkt w n-wymiarowej przestrzeni wymiarów. Wymiary są opisane zbiorami atrybutów (np. nazwa produktu, nazwa kategorii produktu), a atrybuty tworzą hierarchie (np. produkt –> kategoria).

Model wielowymiarowy zakłada stworzenie n-wymiarowej tablicy (zwanej kostką OLAP), której krawędzie opisane są wymiarami, a poszczególne komórki zawierają podsumowania miar. Kostka stanowi następnie dogodne źródło danych do podsumowań - często wystarczy jedynie wyselekcjonować jej dwa wymiary, aby uzyskać wymaganą tabelę statystyczną do raportu.

Rysunek 2.6. Trójwymiarowa kostka danych

Rysunek 2.6. Trójwymiarowa kostka danych

Model wielowymiarowy bezpośrednio implementowany jest w architekturze MOLAP. Jeśli decydujemy się na architekturę ROLAP tworzymy schemat relacyjny mający szczególną, odzwierciedlającą inherentną wielowymiarowość danych, strukturę. Tej tematyce poświęcony jest wykład 3. Ale nawet, jeśli dane chcemy trzymać na serwerze relacyjnym możemy przygotować kostki danych i przechowywać w nich agregacje.

Dla kostki danych określony jest zbiór operacji, które można na niej wykonywać. Podstawowymi operacjami na kostce są:

Rysunek 2.7. Operacja rozwijania

Rysunek 2.7. Operacja rozwijania

Rysunek 2.8. Operacja zwijania

Rysunek 2.8. Operacja zwijania

Rysunek 2.9. Operacja drążenia danych

Rysunek 2.9. Operacja drążenia danych

Rysunek 2.10. Operacja selekcji

Rysunek 2.10. Operacja selekcji

Rysunek 2.11. Operacja obracania – obrót wokół osi pionowej o 90º.

Rysunek 2.11. Operacja obracania – obrót wokół osi pionowej o 90º

Obok operacji podstawowych są też inne operacje na kostkach danych, np. wybór n górnych miejsc lub n górnych procent. Z tego rodzaju operacji korzystamy, gdy chcemy np. wybrać dziesięć najlepiej sprzedających się produktów w styczniu 2011 roku albo 5% najlepszych klientów z roku 2010.

Zadania

Zadanie 1. Zastanów się, czy w swoim projekcie zastosujesz architekturę scentralizowaną, czy rozproszoną. Uzasadnij swój wybór.