Metody i technologie budowy hurtowni danych ze szczególnym

Metody i technologie budowy hurtowni danych ze szczególnym

Zakład Zaawansowanych Technik Informacyjnych Z-6
Metody i technologie budowy hurtowni danych
ze szczególnym uwzględnieniem zapewnienia
długookresowej jakości produktu
Praca nr 06.30.002.7
Warszawa 2007 – 12 – 7
Metody i technologie budowy hurtowni danych ze szczególnym uwzględnieniem zapewnienia
długookresowej jakości produktu
Praca nr 06.30.002.7
Słowa kluczowe (maksimum 5 słów): Hurtownie Danych, Jakość danych
Kierownik pracy:
mgr inż. Mariusz Pajer
Wykonawcy pracy:
dr inż. Janusz Granat
mgr inż. Michał Majdan
mgr inż. Robert Kuśmierek
mgr inż. Cezary Chudzian
mgr inż. Marcin Salwa
mgr inż. Jarosław Sobieszek
Kierownik Zakładu: dr inż. Janusz Granat
© Copyright by Instytut Łączności, Warszawa 2007
4
Spis Treści
1.
Wstęp ...............................................................................................................................4
2.
Przegląd stosowanych technologii i metod.......................................................................4
2.1.
Podstawy hurtowni danych .......................................................................................4
2.2.
Typowe metody i technologie budowy hurtowni danych...........................................5
2.2.1.
Warstwa konceptualno-funkcjonalna ................................................................6
2.2.2.
Warstwa logiczna..............................................................................................9
2.2.3.
Warstwa fizyczna............................................................................................14
2.2.4.
Narzędzia użyteczne w budowie hurtowni danych .........................................17
2.3.
Zastosowanie ASM do budowy hurtowni danych ...................................................17
3.
Opracowana metodyka...................................................................................................18
4.
Moduł Sterujący..............................................................................................................20
4.1.
4.1.1.
Uruchomienie..................................................................................................23
4.1.2.
Konfiguracja....................................................................................................24
4.1.3.
Zatrzymanie aplikacji ......................................................................................25
4.1.4.
Komunikacja systemu z użytkownikiem..........................................................26
4.1.5.
Realizowana funkcjonalność ..........................................................................26
4.2.
Działanie i budowa systemu ...................................................................................27
4.2.1.
Działanie systemu...........................................................................................27
4.2.2.
Struktura aplikacji ...........................................................................................29
4.3.
5.
Funkcjonalność systemu ........................................................................................22
Dalsze plany rozwoju..............................................................................................31
Wnioski ...........................................................................................................................32
Bibliografia..............................................................................................................................33
3
1. Wstęp
Hurtownie danych (HD) są złożonymi systemami informatycznymi, które przetwarzają
i łączą dane pochodzące z różnych źródeł w zunifikowane struktury, aby nadać im jakość
i formę niezbędną dla celów analitycznych. Taka definicja HD zwraca uwagę na wymiar
jakości a zwłaszcza jakości danych, który współdecyduje o tym, czy zbudowana wysokim
nakładem pracy HD będzie dostarczać danych godnych zaufania, czy też przedstawi ich
fałszywy obraz. Z problem tym stykają się członkowie zespołu realizującego niniejszą pracę
wdrażając i utrzymując HD. Dlatego w ramach niniejszej pracy opracowano nową metodykę.
Uzupełnia ona dotychczas stosowane metodyki budowy HD o nowe metody, które zapewnią
jakość danych od momentu ich ekstrakcji do HD aż do prezentacji użytkownikowi
końcowemu. Metody te dotyczą aspektu przetwarzania i przepływu danych w HD, dla
którego istotne jest wprowadzenie modularyzacji kolejnych kroków przetwarzania danych,
powiązanie ich w łańcuchy oraz wprowadzenie zewnętrznej aplikacji, która uruchamia
kolejne moduły oraz nadzoruje przetwarzanie, przepływy i jakość danych. Modularyzacja
umożliwia optymalizację wydajności przetwarzania danych, stopniową kontrolę jakości
danych w trakcie przetwarzania oraz w prowadzenie mechanizmów zwrotnych
pozwalających na wykrycie i opanowanie anomalii przed uzyskaniem zafałszowanych
wyników końcowych. Modularyzacja sprzyja wreszcie wprowadzaniu zmian w HD
i utrzymaniu HD oraz ogranicza ich koszty. Moduły przetwarzające dane w HD układają się
w łańcuchy, które tworzą wzorce przepływu i przetwarzania danych. Metodyka korzystająca
ze wzorca wymaga użycia lub stworzenia systemu sterującego przetwarzaniem zgodnie ze
zdefiniowanymi dla HD wzorcami. W ramach niniejszej pracy zaimplementowano w języku
Java system nazwany Modułem Sterującym, który służy do wykonywania procesów ETL,
zgodnie ze zdefiniowanym wzorcem. Moduł Sterującym oraz niniejszy raport są głównymi
produktami pracy 06.30.002.7.
2. Przegląd stosowanych technologii i metod
2.1.
Podstawy hurtowni danych
Wdrożenie hurtowni danych następuje najczęściej wtedy, kiedy osoby decydujące
o funkcjonowaniu (lub zarządzające wybranymi obszarami działalności) przedsiębiorstwa
dochodzą do wniosku, że posiadane przez nich narzędzia analityczne nie pozwalają im na
podjęcie decyzji w oparciu o wystarczającą liczbę danych, z użyciem wszystkich koniecznych
źródeł danych lub w dostatecznie szerokim zestawieniu kategorii i kryteriów. Kryteria,
względem których analizuje się obiekty ewidencjonowane w HD nazywa się miarami.
Kategorie obiektów podlegających analizie nazywa się wymiarami. Szczególnym
i naturalnym wymiarem analiz jest czas (agregacja lub porównywanie wartości miar
w czasie). Zgodnie z koncepcją hurtowni danych, dane zapisane w HD nie ulegają
modyfikacjom, dlatego cykliczne zapisywanie danych do HD tworzy w niej historyczny obraz
danych, których czas zapisu można ewidencjonować się przy pomocy stempli czasowych.
Wdrożenie HD bywa często elementem strategii uporządkowania i usystematyzowania
analiz wybranego obszaru działalności przedsiębiorstwa. Typowymi przykładami
zastosowania danych zgromadzonych w HD są analizy zysku wobec kosztów, przychodu
wobec sprzedaży, preferencji i charakterystyki zachowań klientów.
HD są repozytoriami danych (lub po prostu bazami danych), których działanie jest
zoptymalizowane w kierunku raportowania danych i które przechowują dane w strukturach
zdefiniowanych przez analizy (do których mają służyć), aby jak najkrócej i jak najbardziej
płynnie następowało wybieranie danych z HD do prezentacji dla użytkownika końcowego.
4
Struktury danych składowanych w HD są w pełni zgodne ze strukturami będącymi
przedmiotem analiz (na przykład kategorie biznesowe są wymiarami), tak aby nawet
najbardziej złożone analizy można było prowadzić w czasie rzeczywistym, z tego powodu
hurtownie danych określa się mianem systemów przeznaczonych do zadań typu OLAP (Online analytical processing) lub określa się wprost mianem systemów typu OLAP. Struktury
hurtowni danych widoczne z perspektywy narzędzi analitycznych określa się mianem data
marts [4]. Tym samym mianem określa się również tematyczne hurtownie danych.
HD integruje i gromadzi w jednym miejscu dane pochodzące z wielu źródeł, którymi są
najczęściej transakcyjne bazy danych służące do działań operacyjnych, na przykład
bieżącego ewidencjonowania działań, zasobów, produktów, usług czy klientów
przedsiębiorstwa. Transakcyjne bazy danych służące do działań operacyjnych są z reguły
systemami typu OLTP (On-line transactional processing), ponieważ są zoptymalizowane
do wykonywanie bieżących czynności ewidencyjnych przy użyciu tzw. transakcji, tak aby
zawierać zawsze aktualne informacje o stanie ewidencjonowanych obiektów.
Wypełnienie struktur HD następuje na drodze złożonego procesu, który określa się mianem
ETL (Extraction – Transformation – Loading) – ekstrakcja, transformacja i ładowanie.
Ekstrakcją danych nazywa się pobranie danych z pierwotnych Źródeł Danych (ŹD, czyli
z operacyjnych systemów informacyjnych) dla potrzeb HD. Dane z ŹD od HD pobiera się
najczęściej cyklicznie. Z uwagi na zazwyczaj dużą liczbę pobieranych danych czyni się to
przyrostowo, a operacja pobrania wymaga najczęściej dużego obciążenia ŹD.
Dane pobrane z ŹD ulegają najczęściej szeregu przekształceń, transformacji i integracji
przed złożeniem do końcowych struktur danych w HD. Jest to spowodowane koniecznością
ich oczyszczenia i unifikacji, a także ma na celu wykonanie niezbędnych obliczeń
i porównań. Czynności przekształcania i wpasowywania danych w końcowe struktury HD
nazywa się transformacją i ładowaniem.
Jak wspomniano, HD są zoptymalizowane pod kątem raportowania i zawierają dane
w strukturach przeznaczonych do bezpośredniej prezentacji, co powoduje, że struktury
przechowywanych danych są nie znormalizowane a same dane są redundantne.
Redundancja jest wymuszona na przykład koniecznością składowania wartości miar dla
każdego z poziomów agregacji dowolnego z wymiarów. Przykładem może być składowanie
danych dla potrzeb analizy sprzedaży, w której zachodzi konieczność prezentacji liczby lub
wartości sprzedaży (miary) na poziomie każdego roku, półrocza, kwartału, miesiąc i dnia.
Zagregowane wartości liczby lub wartości sprzedaży muszą być zapisane w HD, aby można
je było zaprezentować bez konieczności wykonania obliczeń w trakcie prezentacji, co
prowadzi do redundancji informacji i danych mówiących o wartości lub liczbie sprzedaży.
Należy również zauważyć, że wartości obliczane dla przytoczonych powyżej agregacji są
wyliczane i zapisywane do struktur HD w trakcie procesu ETL.
2.2.
Typowe metody i technologie budowy hurtowni danych
Budowa hurtowni danych jako źródła informacji dla analiz biznesowych, które powstają na
drodze integracji i przekształceń danych pochodzących z wielu źródeł warunkuje złożoność
tego procesu. Metodologie budowy HD muszą obejmować między innymi:
−
jak najszersze i jak najbardziej dokładne modelowanie tych obszarów działalności
przedsiębiorstwa, które będą objęte analizami wykonywanym przy użyciu informacji
składowanych w hurtowni danych;
−
wszystkie pojęcia, obiekty i działania, które będą ujęte w źródłach danych
zasilających hurtownie oraz wszystkie pojęcia, obiekty i działania, które będą
odwzorowywane w hurtowni a także ich wzajemne relacje;
−
zaprojektowanie struktury danych hurtowni odpowiadające potrzebom analiz;
5
−
zrozumienie funkcjonowania systemów źródłowych i identyfikację struktur, które będą
dostarczać danych do zasilania HD, a także ich przełożenia na struktury hurtowni
danych;
−
wybór technologii implementacji HD, wykonania procesów ETL oraz dostarczenia
analiz użytkownikowi końcowemu (interfejs użytkownika).
Wykonanie powyższych prac wymaga współdziałania pomiędzy specjalistami
w dziedzinie budowy hurtowni danych a osobami planującymi analizy, odbiorcami analiz
i osobami posiadającymi wiedzę na potencjalnych i zidentyfikowanych źródeł danych.
Czynności związane z budową HD można rozpatrywać w podziale na trzy podstawowe
warstwy [3] :
1. pojęciową-funkcjonalną;
2. logiczną;
3. fizyczną.
Rys. 1: Schemat budowy hurtowni danych
Warstwa
pojęciowofunkcjonalna
Warstwa
logiczna
Warstwa
fizyczna
Projekt
Funkcjonalny
Projekt
Techniczny
Implementacja
Model
pojęciowofunkcjonalny
Schemat
funkcjonalny
Aplikacja użytkownika
Model logiczny
Specyfikacja
aplikacji użytkownika
Hurtownia
Danych
Specyfikacja struktur
Hurtowni Danych
Schemat
Hurtowni Danych
Schemat
Źródła Danych 1
Moduły
ładowania
danych
Specyfikacja logiki
ładowania danych
Moduły
transformacji
danych
Specyfikacja logiki
transformacji danych
Moduły
ekstrakcji
danych
Specyfikacja logiki
ekstrakcji danych
Schemat
Źródła Danych n
Specyfikacja struktur
Źródeł Danych
mapowanie pojęciowo-logiczne
mapowanie logiczno-fizyczne
Źródło
Danych 1
Źródło
Danych n
logiczny przepływ danych
fizyczny przepływ danych
2.2.1. Warstwa konceptualno-funkcjonalna
Pojęciowo-funkcjonalna warstwa budowy HD ma dostarczyć koncepcyjnej reprezentacji
tej części działalności przedsiębiorstwa, która ma być analizowana przy pomocy danych
zgromadzonych w HD. Identyfikuje się w niej konceptualne reprezentacje:
−
wymiarów i miar analiz, a przez to obiektów opisywanych w HD;
6
−
obiektów opisywanych przez źródła danych;
−
relacji pomiędzy obiektami opisywanymi przez
analizowanymi i opisywanymi poprzez zawartość HD.
źródła
danych
a obiektami
Opis obiektów zidentyfikowanych w warstwie pojęciowo-funkcjonalnej i ich relacji składa się
na Model Pojęciowy-Funkcjonalny (MPF) hurtowni danych, który zostaje najczęściej
udokumentowany w Projekcie Funkcjonalnym (PF) hurtowni danych.
Model pojęciowo-funkcjonalny jest niezależny od sposobu implementacji HD i ma na celu
pokazanie semantyki ŹD i HD wraz z ich wzajemnymi relacjami. Model ten nie powstaje
w sposób jednorazowy, ale jest wynikiem przyrostowej pracy zespołu projektowego, który
zaczyna od uzgodnienia słownika terminów z osobami korzystającymi ze ŹD i odbiorcami
HD. Kolejnym krokiem jest ujednolicenie pojęć i obrazów działania tego obszaru działalności
przedsiębiorstwa, który ma zostać poddany analizom. Dalej stworzona zostaje koncepcyjna
reprezentacja danych występujących w ŹD i określa się ich przełożenie na informacje
gromadzone do analizy w HD. Końcowym krokiem tego etapu prac nad modelem pojęciowofunkcjonalnym jest konsolidacja schematów ŹD i HD.
Stworzenie modelu pojęciowo-funkcjonalnego w oparciu o spojrzenie poprzez pryzmat
jednolitego i globalnego modelu danych korporacyjnych we wszystkich źródłach oraz
hurtowni danych nazwano LAV (local-as-view). Jest to podejście rekomendowane
uczestników europejskiego projektu DWQ 1 . W podejściu LAV, każda tabela w źródle danych
oraz każda tabela w hurtowni danych jest zdefiniowana przy użyciu warunków spojrzenia
poprzez globalny modelu danych korporacyjnych. Dzięki na reprezentację pojęciową
zarówno hurtowni danych jak i źródeł danych nie rzutuje rzeczywista logika struktur źródeł
danych. Mapowanie reprezentacji pojęciowej na rzeczywiste struktury dokonuje się na
poziomie warstwy logicznej.
Alternatywnie można użyć podejścia GAV (global-as-view), które bywa często stosowane
w budowie hurtowni danych. W podejściu GAV modele pojęciowe każdego ze źródeł danych
są zbudowane zgodnie z ich własnymi modelami biznesowymi.
Następnym celem jest wyznaczenie schematu konsolidacji danych zapisanych w ŹD
z informacjami gromadzonymi w HD. Drogą do tego jest identyfikacja obiektów
reprezentowanych w ŹD oraz ich związków z obiektami reprezentowanymi w HD. Dzięki
powyższym działaniom, model pojęciowo-funkcjonalny staje się podstawą konsolidacji
schematów oraz danych ŹD i HD. Model pojęciowo-funkcjonalny jest również niezbędny do
dalszego udoskonalania zbudowanej hurtowni danych, jak również do dopasowywania HD
do zmian w ŹD.
Uzgodnienie danych zgromadzonych w różnych ŹD i reprezentujących te same obiekty jest
jednym z elementów prac w warstwie pojęciowo-funkcjonalnej. Prace te można
zautomatyzować przy użyciu dostępnych narzędzi do automatycznego wnioskowania, które
potrafią wyprowadzić i zweryfikować kilka typów właściwości danych w oparciu
o koncepcyjne opisy poszukiwanych informacji i ich wzajemnych związków.
Formalizacja informacji zawartych w modelu koncepcyjnym wprowadza rozróżnienie
pomiędzy koncepcjami obiektów i wartości, co znajduje odbicie w zapisie modelu pojęciowofunkcjonalnego za pomocą dwóch komponentów:
1. modelu Encji i Relacji (ER, Entity – Relationship model) – formalizowany
w postaci diagramu ERD (Entity – Relationship Diagram), który przedstawia
graficznie właściwości koncepcyjne obiektów i relacji między obiektami;
1
ESPIRIT Basic Research Action Project RP 22469 „Foundations of Data Warehouse Quality
(DWQ)”, http://www.dbnet.ece.ntua.gr/~dwq/.
7
2. zestawu asercji domen wartości, który modeluje właściwości wartości parametrów
obiektów.
Praca [3] pokazuje zalety i przedstawia przykłady ulepszenia formalizacji opisu modelu
koncepcyjnego HD, poprzez dodanie do modelu ER formalizmu opartego na logice, który
nazwano DLR [29]. Formalizm ten należy do rodziny Logiki Deskryptywnej (Description
Logic). Autorzy publikacji argumentują, że DLR wzbogaca formalizm opisu modelu
koncepcyjnego o kilka form wyrażeń, które nie mogą zostać zapisane przy pomocy
standardowego modelu ER. Ponadto DLR dostarcza zaawansowanych możliwości
wnioskowania automatycznego, które mogą zostać wykorzystane do weryfikacji różnych
właściwości modelu pojęciowo-funkcjonalnego. DLR zostało wcześniej wprowadzone do
obszaru Reprezentacji Wiedzy i tam zostało przebadane [32,33,34]. Przestawione zostało
pełnowartościowe zastosowanie metody formalizacji schematu ER przy pomocy DLR
w budowie procesów ETL i hurtowni danych w obszarze telekomunikacji [30,31].
Zarówno w przypadku budowy nowej hurtowni, jak i w przypadku rozbudowy już istniejącej
hurtowni, konieczne jest zastosowanie kroków zmierzających do rozszerzenia schematów
źródeł i schematu hurtowni. Następuję to w przypadkach:
−
dodania nowego źródła danych lub nowej części źródła danych;
−
dodania nowej analizy lub zmiany zawartości istniejącej analizy.
Przypadek dodania nowego źródła jest nazywany źródło-centrycznym (source-centric) [3].
Wymaga on przeprowadzenia analizy nowego źródła lub jego dodawanej części, a następnie
dodania go do modelu pojęciowo-funkcjonalnego. Wśród niezbędnych kroków wymienia się
[3]:
1. konstrukcję nowego modelu źródła,
2. integracje nowego modelu źródła z modelem pojęciowo-funkcjonalnym, podczas
której trzeba przeprowadzić:
♣ rozwiązywanie konfliktów – obejmujące identyfikację i rozwiązanie konfliktów
semantycznych i strukturalnych pomiędzy schematem nowego źródła
a istniejącym modelem pojęciowo-funkcjonalnym, między innymi poprzez
doprowadzenie do ich kompatybilności przed integracją;
♣ zdefiniowanie asercji między-modelowych – dodanie nowego modelu źródła do
istniejącego już modelu pojęciowo-funkcjonalnego, wnosi do rozszerzonego
modelu koncepcyjnego asercje między-modelowe wiążące elementy schematu
nowego źródła z elementami modelu pojęciowo-funkcjonalnego;
3. analizę jakości – polegającą na ewaluacji poprawionego modelu pojęciowofunkcjonalnego względem zdefiniowanych wcześniej wskaźników jakości modelu
pojęciowo-funkcjonalnego, pomocne mogą być przy tym techniki wnioskowania
związane z zastosowanym wcześniej formalizmem opisu modelu, w przypadku
wykrycia niezgodności z zadanymi kryteriami, należy dopasować model do zadanych
kryteriów.
Scenariusz modyfikacji modelu pojęciowo-funkcjonalnego, w wyniku dodania nowej analizy
lub modyfikacji zawartości już istniejącej analizy, jest określany jako zorientowany
na zapytanie (query-centric). Wymaga on przeprowadzenia analizy nowej funkcjonalności
i zmiany modelu pojęciowo-funkcjonalnego hurtowni w celu wprowadzenia semantyki
związanej z nowym zapytaniem (analizą). Wśród kroków charakterystycznych dla tego
scenariusza warto wymienić:
1. kontrolę konfliktów pomiędzy nowymi elementami semantyki modelu pojęciowofunkcjonalnego a dotychczasowymi elementami tego modelu i schematami źródeł
danych;
8
2. zdefiniowanie asercji dla nowych elementów schematu pojęciowo-funkcjonalnego;
3. analizę schematów źródeł w celu określenia, czy w obecnej formie są one
wystarczające do obsługi nowego zapytania;
4. w przypadku stwierdzenia konieczności wprowadzenia nowego źródła lub dodania
nowej części już istniejącego źródła, należy przeprowadzić scenariusz źródłocentryczny dla każdego dodanego źródła lub każdej nowej części źródła danych;
5. kontrolę jakości i dodanie nowych kryteriów jakości uwzględniających zmianę modelu
pojęciowo-funkcjonalnego.
Model pojęciowo-funkcjonalny określa ponadto funkcjonalność analiz możliwych do
przeprowadzenia z użyciem danych zgromadzonych w HD. Dąży się do tego, aby
zidentyfikować wszystkie dostępne wymiary, wszystkie możliwe poziomy ich dekompozycji
oraz schematy agregacji wartości na poszczególnych poziomach dekompozycji wymiarów.
Dla przykładu, w projekcie funkcjonalnym można określić, że wartości wymiaru „czas” będą
przedstawione w podziale na lata, które będą dzielone na półrocza, które będą dzielone na
kwartały roku (pierwsze półrocze – I kwartał i II kwartał, drugie półrocze – III kwartał i IV
kwartał), które będą dzielone na miesiące (1…12), które będą dzielone na tygodnie
w ramach miesięcy (a nie roku !), które będą dzielone na dni. Warto tu zauważyć, że
w przypadku podziału względem wymiaru czasu istotne znaczenia ma obsługa tego typu
wymiaru i agregacji względem tego typu wymiaru przez mechanizmy narzędzi ETL i/lub HD.
Może się bowiem okazać, że z uwagi na procedury przekształcania i prezentacji możliwe
będzie na przykład tylko wprowadzenie następujących odrębnych dwóch typów podziałów:
−
na pierwszym poziomie lata, które będą dzielone na kwartały roku (I…IV kwartał),
które będą dzielone na miesiące (1…12), które będą dzielone na dni;
−
na pierwszym poziomie lata, które będą dzielone na tygodnie roku, które będą
dzielone na dni.
Określenie pełnej funkcjonalności analiz zaplanowanych do przeprowadzenia przy użyciu
informacji zmagazynowanych w hurtowni danych, pozwala na stworzenia jak najbardziej
pełnego modelu pojęciowego hurtowni oraz ułatwia ocenę kompletności schematów źródeł.
Określenie pełnej funkcjonalności analiz jest również niezbędne w celu wyboru technologii
i narzędzi budowy hurtowni danych.
2.2.2. Warstwa logiczna
Budowa hurtowni w warstwie logicznej składa się z trzech podstawowych części:
1. specyfikacji logicznego schematu struktur każdego ze źródeł;
2. wyspecyfikowaniu i zaprojektowaniu logicznego schematu struktur hurtowni danych
na podstawie opracowanego modelu pojęciowo-funkcjonalnego;
3. zaprojektowaniu mechanizmów i modułów wykonujących zadania procesu ETL.
Wynikiem przeprowadzenia wymienionych powyżej działań jest uzyskanie specyfikacji logiki
służącej do integracji danych pochodzących ze struktur źródłowych i przekształcenia ich
w zawartość struktur hurtowni danych. W przypadku potrzeby stworzenia narzędzi do
przeglądania zawartości HD, należy zaprojektować również logikę działania aplikacji będącej
interfejsem użytkownika, poprzez który będzie on prowadził analizy. Produkty wszystkich
z wymienionych tu działań są elementami projektu technicznego hurtowni danych. Projekt
techniczny powinien uwzględniać aspekty wydajnościowe procesu przetwarzania danych
i wprowadzać zrównoleglenie zadań wykonywanych przez algorytmy ekstrakcji, czyszczenia,
transformacji i ładowania danych do hurtowni. Konieczne jest również zagwarantowanie
9
możliwości prowadzenia analiz korzystających z informacji zapisanych w hurtowni danych
w czasie rzeczywistym.
Specyfikacja logicznej struktury źródeł danych jest tożsama opisowi struktur danych
pobieranych ze źródeł. Specyfikacja logicznych struktur hurtowni danych jest
tożsama zmaterializowanemu widokowi struktur wirtualnej hurtowni danych, która została
wyspecyfikowana w modelu pojęciowo-funkcjonalnym. Ponieważ źródła danych mają
najczęściej postać relacyjnych baz danych, dlatego ich struktury definiuje się zazwyczaj przy
pomocy zestawu relacji używając relacyjnego modelu baz danych. Przypisanie do każdej
relacji zapytania ponad modelem pojęciowo-funkcjonalnym, umożliwia formalne
zdefiniowanie mapowania reprezentacji pojęciowo-funkcjonalnej na reprezentację logiczną.
Dzięki temu logiczną zawartość źródła można opisać za pomocą warunków wirtualnej bazy
danych zdefiniowanej za pomocą modelu pojęciowo-funkcjonalnego, co jest konieczne
w przypadku zastosowania podejścia LAV do stworzenia modelu pojęciowo-funkcjonalnego.
Logiczny schemat hurtowni danych również opisuję się przy pomocy zestawu relacji.
Podobnie jak w przypadku schematu logicznego źródeł, tak i w przypadku schematu
logicznego hurtowni danych, mapowanie na model pojęciowo-funkcjonalny jest dokonywane
przy pomocy zapytań.
Ponieważ model pojęciowo-funkcjonalny hurtowni danych definiuje źródła danych
w oderwaniu od ich rzeczywistych modeli biznesowych (pojęciowych) oraz w oderwaniu od
ich rzeczywistych struktur danych, dlatego konieczne jest uwzględnienie w procesie
mapowania:
1. informacji o aktualnych strukturach logicznych źródeł danych;
2. specyfikacji translacji schematu danych systemu źródłowego
zaprojektowany na podstawie modelu pojęciowo-funkcjonalnego.
2.2.2.1.
na
schemat
Zapytania ponad MPF
Określono formalizację zapisu mapowania modelu pojęciowo-funkcjonalnego na model
logiczny, przy użyciu mechanizmu zapytań ponad modelem pojęciowo-koncepcyjnym [3].
Formalizacja ta opiera się na definicji, że zapytania oparte na MPF są uniami
koniunktywnych zapytań. Każde z takich zapytań można zapisać jako:
T (~
x ) ← q(~
x, ~
y ),
(1)
gdzie:
T (~
x ) – nagłówek, definiuje schemat relacji o nazwie T oraz jej arność,
~
x – arność, w tym przypadku zapewne liczba kolumn, szerzej chodzi tu o liczbę
x , użycie symbolu ~
x odnotowuje, że chodzi tu krotność zmiennych
komponentów ~
x1 ,K, xn dla pewnego n , ten symbol oznacza również zbiór zmiennych x1 ,K, xn
q(~
x, ~
y ) – ciało, opisuje zawartość relacji przy użyciu warunków modelu pojęciowo-
funkcjonalnego,
q – zapytanie, którego formę podaje .
Ciało ma formę:
conj1 (~
x, ~
y1 ) ∨ L ∨ conjm (~
x, ~
ym ) ,
gdzie:
conji (~
x, ~
yi ) – koniunkcja atomów,
10
(2)
~
x, ~
yi – wszystkie zmienne występujące w koniunkcji.
Każdy z atomów może reprezentować:
−
encje występujące w modelu pojęciowo-funkcjonalnym, przy użyciu formy:
E (t ) ,
(3)
gdzie:
E – encje występujące w MPF,
t – zmienna w ~
x, ~
y lub stała;
i
−
relacje w modelu pojęciowo-funkcjonalnym, przy użyciu formy:
R(~
t ),
(4)
gdzie:
R – relacje występujące w MPF,
~
t – zmienna w ~
x, ~
yi lub stała;
−
atrybuty w modelu pojęciowo-funkcjonalnym, przy użyciu formy:
A(t , t ′) ,
(5)
gdzie:
A – atrybuty występujące w MPF,
t – zmienna w ~
x, ~
y lub stała;
i
t ′ – zmienna w ~
x, ~
yi lub stała.
Dla każdej bazy danych spełniającej warunki modelu koncepcyjno-funkcjonalnego,
podstawienie specyfikacji ciała zapytania (2) do równania definiującego zapytanie (1) daje
zapytanie sformułowane jako:
T (~
x ) ← conj1 (~
x, ~
y1 ) ∨ L ∨ conjm (~
x, ~
ym ) ,
(6)
dla którego arność n oznacza n -krotny zbiór ( d1 ,K, d n ), w którym każde di jest takim
obiektem tej bazy danych, że przy zastąpieniu każdego di przez xi wyrażenie:
∃~
y1 ⋅ conj1 (~
x, ~
y1 ) ∨ L ∨ ∃~
ym ⋅ conjm (~
x, ~
ym ) ,
(7)
daje w wyniku prawdę.
Zapytania zdefiniowane w powyższy sposób można wykorzystać w procesie wnioskowania
pod warunkiem uwzględnienia poniższych reguł modelu pojęciowo-funkcjonalnego.
−
Reguła spójności zapytania. Zapytanie q zdefiniowane ponad MPF jest spójne,
jeżeli istnieje choć jedna taka baza spełniająca warunki MPF, dla której zbiór krotek
wybrany przy użyciu q nie jest zbiorem pustym.
−
Reguła zawieranie się zapytań. Biorąc dwa zapytania q1 i q2 (o tej samej arności n )
zdefiniowane ponad MPF można powiedzieć, że q1 zawiera się w q2 , jeżeli zbiór
krotek wybranych przy użyciu q1 zawiera się w zbiorze krotek wybranych przy użyciu
q2 , dla każdej bazy spełniającej warunki MPF.
11
−
Reguła rozłączności zapytań. Biorąc dwa zapytania q1 i q2 (o tej samej arności n )
zdefiniowane ponad MPF można powiedzieć, że są one rozłączne, jeżeli przecięcie
zbioru krotek wybranych przy użyciu q1 i zbioru krotek wybranych przy użyciu q2 jest
zbiorem pustym, dla każdej bazy spełniającej warunki MPF.
Siłę zapytań zdefiniowanych ponad modelem projektowo-funkcjonalnym jako narzędzi do
budowy modelu logicznego źródeł i hurtowni danych, pokazują poniższe.
1. Tabele relacyjnych baz danych zawierają krotki wartości, które są jedynym typem
obiektów występującym w logicznym modelu źródeł danych i hurtowni danych,
dlatego każda zmienna w nagłówku zapytania reprezentuje wartość (a nie obiekt
pojęciowy).
2. Każda zmienna występująca w ciele zapytania reprezentuje obiekt pojęciowy lub
wartość, w zależności od atomu, w którym występuje. Ponieważ obiekty pojęciowe
i wartości tworzą zbiory rozłączne (dla każdej bazy danych, która spełnia warunki
MPF), żadne zapytanie nie może zawierać wartości, pod którą można jednocześnie
podstawić obiekt pojęciowy i wartość.
3. Ponieważ każdy obiekt pojęciowy jest reprezentowany za pomocą krotki wartości na
poziomie logicznym, dlatego niezbędny jest mechanizm wyrażający korespondencję
pomiędzy krotką wartości a obiektem pojęciowym, który ta krotka reprezentuje.
Mechanizm ten zapewnia uszczegółowienie zapytania.
2.2.2.2.
Uszczegółowienie zapytań ponad MPF
Precyzyjne pobieranie danych przy użyciu zapytania ponad MPF, wymaga dodania
uszczegółowienia (adornment) do zapytania. Uszczegółowienie służy do zadeklarowania
domen kolumn tabel oraz atrybutów tabeli, które są niezbędne do identyfikacji obiektów
wyspecyfikowanych w modelu pojęciowo-funkcjonalnym.
Zapytanie uszczegółowione (adorned query) zapisuje się przy pomocy następującego
wyrażenia:
T (~
x ) ← q (~
x, ~
y ) | α1 , K , α n ,
(8)
gdzie:
α1 ,K, α n – uszczegółowienie,
α i – oznaczenie przypisów do poszczególnych zmiennych wyspecyfikowanych w ~x .
Uszczegółowienie można opisać przy pomocy dwóch poniższych definicji.
−
x przypis uszczegóławiający ma formę:
Dla każdego X ∈ ~
X :: V ,
(9)
gdzie:
V – domena wyrażenia.
Formuła uszczegółowienia (9) definiuje w jaki sposób wartości przypisane do
zmiennej X są reprezentowane w tabeli na poziomie logicznym.
−
z⊆~
x , który został użyty w celu identyfikacji
Dla każdego zbioru wartości ~
~
x, ~
y ) , przypis uszczegółowiający
w T obiektu pojęciowego Y ∈ y wymienionego w q(~
przyjmuje formę:
12
Identify([~
z ], Y ) ,
(10)
gdzie:
[~z ] – grupuje zmienne
~
z w pojedynczy argument.
Przypis uszczegółowiający (10) definiuje explicite, że zbiór wartości
reprezentacją obiektu pojęciowego Y .
~
z
jest
Uszczegóławianie zapytań stosuje się zarówno wobec zapytań operujących na relacjach
w tabelach źródłowych baz danych, jak i wobec zapytań operujących na relacjach
w zmaterializowanym widoku hurtowni danych. W przypadku uszczegóławiania pytań
związanych ze źródłami danych, uszczegółowienie wymaga zastosowania metod
analitycznych odwrotnej inżynierii programowania (reverse engineering) wobec struktur
źródła danych. W przypadku uszczegóławianiu zapytań wobec zmaterializowanych struktur
hurtowni danych, uszczegóławianie jest dodatkowym produktem wraz ze specyfikacją
i projektowaniem logicznych struktur hurtowni danych, zaś uszczegółowione zapytania
stanowią specyfikację poleceń ładujących dane do hurtowni danych.
2.2.2.3.
Uzgodnienia korespondencji
Uzgodnieniami korespondencji (reconciliation correspondences) nazywa się asercje,
które specyfikują korespondencje pomiędzy danymi występującymi w różnych logicznych
schematach danych, zarówno w schematach źródeł danych, jak i w schemacie hurtowni
danych [3,35]. Uzgodnienia korespondencji definiuje się przy użyciu terminologii relacji,
podobnie jak ma to miejsce w przypadku relacji opisujących źródła danych i hurtownie
danych na poziomie logicznym. Każde z potrzebnych uzgodnień korespondencji definiuje się
w formie uszczegółowionego zapytania, które zostaje następnie zaimplementowane
w postaci programu wykonywanego każdorazowo w trakcie procesów ETL. W fazie
modelowania logicznego definiuje się przede wszystkim parametry wejściowe i wyjściowe
programów odpowiadających parametrom uzgodnień korespondencji. W literaturze rozróżnia
się trzy typy korespondencji:
1. konwersję;
2. dopasowanie;
3. mieszanie.
Szczegółowy opis wymienionych typów korespondencji zawiera praca [35].
2.2.2.4.
Typowa realizacja prac w warstwie logicznej
Specyfikację schematów logicznych źródeł danych i hurtowni danych można wykonać przy
użyciu uszczegółowionych zapytań. Zaprojektowanie schematu logicznego hurtowni danych
wymaga restrukturyzacji i denormalizacji struktur HD zgodnie z wymaganiami optymalizacji
struktur HD w celu umożliwienia prowadzenia analiz czasie rzeczywistym. W trakcie tych
operacji należy wybrać dane, które będą zmaterializowane w HD oraz sposób ich
organizacji. Oszacowanie kosztów ekstrakcji, transformacji, ładowania i odświeżania danych,
czy przestrzeni potrzebnej do składowania danych jest między innymi konieczne, aby można
było podjąć poprawne decyzje projektowe.
Istotne miejsce w modelowaniu logicznym zajmuje zaprojektowanie logiki ekstrakcji danych
ze źródeł, ich transformacji i ładowania do materialnych struktur hurtowni danych. Korzysta
się przy tym ze specyfikacji użytecznych struktur źródeł danych oraz zaprojektowanej
materializacji struktury danych hurtowni. Na strukturach źródeł danych operują programy
służące do ekstrakcji danych, które pobierają dane ze źródeł i opakowują je w struktury
13
użyteczne do dalszego przetwarzania, dlatego programy te określa się również mianem
wrapers [3]. Do ich specyfikacji można wykorzystać formalizację uszczegółowionych
zapytań wobec źródeł danych ponad modelem pojęciowo-funkcjonalnym.
Formalizacja uszczegółowionych zapytań wobec hurtowni danych ponad modelem
pojęciowo-funkcjonalnym jest natomiast użyteczna do specyfikacji procedur ładowania
danych do struktur hurtowni.
Integracja danych pochodzących ze źródeł w hurtowni wymaga zawarcia w procesach
transformacji operacji oczyszczania i łączenia danych, które bywają nazywane mediatorami
(mediators). Nazwą mediatorów określa się również łącznie całość procedur transformacji
i ładowania danych [3].
W celu przeprowadzenia oczyszczenia i łączenia danych, budowniczowie hurtowni muszą
wyspecyfikować – jak należy mapować i dopasowywać dane pochodzących ze źródeł do
wymogów jakościowych informacji, która ma być składowana w hurtowni danych. W tym celu
można użyć opisanej wcześniej metodyki uzgodnienia korespondencji, aby poprzez
uszczegółowione zapytania wyspecyfikować logikę procedur oczyszczania i łączenia danych.
Metodyka uzgodnienia korespondencji jest również użyteczna do automatycznej generacji
procedur spełniających funkcje mediatorów lub do automatycznego wyszukiwania
właściwości korespondencji pomiędzy danymi źródeł i informacjami gromadzonymi
w hurtowni danych [35].
2.2.3. Warstwa fizyczna
Warstwa fizyczna obejmuje implementację struktur hurtowni danych i procesów ETL.
W przypadku potrzeby implementacji interfejsu użytkownika, implementowane są również
narzędzia do prowadzenia analiz zgodnie z technologią OLAP.
Struktury hurtowni danych implementuje się przy użyciu rozwiązań opartych na relacyjnej
baz danych [8, 10, 11,12,13,14,16,20,23] lub rozwiązań dedykowanych nie opartych na
relacyjnej bazie danych [24,25], które pozwalają na stworzenie wielowymiarowych struktur
danych. Podczas implementacji wielowymiarowe struktury danych przyjmują zazwyczaj
formę przypominającą gwiazdę lub płatek śniegu.
Wielowymiarowe struktury informacyjne hurtowni danych implementuje się w postaci
wielowymiarowych struktur zwanych kostkami danych (data cube) lub przy użyciu tabel,
które ponadto są używane do przechowywania agregacji lub danych uszczegóławiających
informacje wielowymiarowe.
Procesy ETL implementuje się przy użyciu:
−
języka SQL i jego rozszerzeń, które zostały stworzone przez producentów bazy
danych bazy danych lub producentów hurtowni danych zbudowanych w oparciu
o relacyjne bazy danych;
−
języków stworzonych przez producentów rozwiązań hurtowni danych [25];
−
rozwiązań dedykowanych
[7,9,15,18,19,21,22,24,25].
do
projektowania
i wykonywania
procesów
ETL
Interfejs użytkownika jest realizowany za pomocą:
−
narzędzi wchodzących w skład rozwiązań określanych jako Inteligencja Biznesowa
(BI – Business Intelligence) [14,15,17,19,20,23,24,25];
−
narzędzi do analizy danych, które pozwalają na definiowanie własnych analiz
[7,14,17,23,24,25,27];
14
−
samodzielnie zaimplementowanych aplikacji z użyciem technologii WWW, XML, CGI,
ASP, .NET, języków Java, C, C++, C#.
W sprzedaży jest obecnie dostępnych szereg narzędzi i rozwiązań, które mogą zostać użyte
do implementacji hurtowni danych, procesów ETL lub realizacji interfejsu użytkownika
według technologii OLAP. Poniżej wymieniono reprezentatywną część z dostępnych
rozwiązań.
−
IBM WebSphere DataStage [7] – narzędzie do integracji danych, wchodzi w skład
rozwiązania IBM Information Server, które w połączeniu z hurtownią danych pozwala
na prowadzenie analiz według technologii OLAP.
−
IBM DB2 Warehouse [8] – hurtownia danych.
−
Informatica PowerCenter [9] – zunifikowana platforma służąca do dostępu, analizy
i integracji danych, współpracująca w różnorodnymi biznesowymi systemami
informacyjnymi, w tym z hurtowniami danych i bazami danych, umożliwia
prowadzenie analiz według technologii OLAP.
−
Teradata Enterprise Data Warehouse [10] – dedykowana hurtownia danych,
zapewniająca równoległe przetwarzanie i dostęp do olbrzymich ilości danych.
Teradata działa zgodnie z architekturą obliczeń rozproszonych SN (shared nothing),
która tworzy strukturę typu GRID, gdzie każdy z węzłów jest niezależny
i samowystarczalny. Rozwiązanie to zawiera dedykowane elementy w zakresie
sprzętu i oprogramowania. Podobnymi rozwiązaniami są Netezza, Greenplum
i PANTA.
−
Netezza Performance Server [11] – dedykowana hurtownia danych, zapewniająca
równoległe przetwarzanie i dostęp do olbrzymich ilości danych. Rozwiązanie to
zawiera dedykowane elementy w zakresie sprzętu i oprogramowania, w tym:
wbudowany systemem operacyjny Linux, adaptowaną wersję bazy danych
PostgreSQL i dużą przestrzeń dyskową. Podobnymi rozwiązaniami są Teradata,
Greenplum i PANTA.
−
Greenplum Database [12] – dedykowana hurtownia danych, zapewniająca
równoległe przetwarzanie i dostęp do olbrzymich ilości danych. Greenplum działa
zgodnie z architekturą obliczeń rozproszonych SN. Rozwiązanie to zawiera
dedykowane elementy w zakresie sprzętu i oprogramowania, w tym: wbudowany
systemem operacyjny Linux/ Solaria/ OSX, adaptowaną wersję bazy danych
PostgreSQL i dużą przestrzeń dyskową. Podobnymi rozwiązaniami są Teradata,
Netezza i PANTA.
−
PANTA Data Warehouse Appliance with Oracle [13] – dedykowana hurtownia
danych, zapewniająca równoległe przetwarzanie i dostęp do olbrzymich ilości
danych. Rozwiązanie to zawiera dedykowane elementy w zakresie sprzętu
i oprogramowania, w tym: bazę danych Oracle i dużą przestrzeń dyskową.
Podobnymi rozwiązaniami są Teradata, Netezza i Greenplum.
−
Sybase IQ Analytics Server [14] – rozwiązanie określane jako Server analityczny.
Zawiera hurtownię danych, narzędzia do stworzenia własnych analiz oraz elementy
BI. Sybase IQ jest oparte na specyficznej relacyjnej bazie danych, która przechowuje
w tabelach dane zorganizowane w sekcje kolumn danych, a nie wiersze danych.
Dzięki temu jest lepiej dopasowana do przeszukiwania danych zgodnie z ideą
wymiarów i miar w hurtowni danych.
−
SAP NetWeaver Business[15] – rozwiązanie zawierające narzędzia BI, narzędzia
umożliwiające prowadzenie analiz według technologii OLAP, hurtownię danych,
narzędzia wykonujące procesy ETL.
15
−
Oracle Data Warehousing [16] – rozwiązanie zawierające hurtownię danych
i narzędzia ETL jako komponenty bazy danych Oracle.
−
Oracle Business Intelligence Foundation and Tools [17] – rozwiązanie zawierające
zestaw narzędzi BI oraz zestaw narzędzi umożliwiających prowadzenie analiz według
technologii OLAP. Po przejęciu przez Oracle platformy Hyperion, zawiera zestaw
narzędzi BI platformy Hyperion.
−
Oracle Data Integrator [18] – narzędzie do projektowania i wykonywania procesów
ETL w celu integracji danych pochodzących z wielu źródeł w jednej bazie lub
hurtowni danych.
−
Cognos 8 Business Intelligence [19] – rozwiązanie zawierające zestaw narzędzi BI,
zestaw narzędzi umożliwiających prowadzenie analiz według technologii OLAP,
zestaw narzędzi do integracji danych poprzez zaprojektowanie i realizację procesów
ETL.
−
BusinessObjects Warehouse [20] – rozwiązanie składające się z hurtowni danych
i narzędzi analitycznych. BusinessObjects Warehouse stanowi część platformy
BusinessObjects BI, która dostarcza narzędzi BI.
−
BusinessObjects Data Integrator [21] – narzędzie do zaprojektowania i realizacji
procesów ETL.
−
Microsoft SQL Server Integration Services [22] – narzędzie do implementacji
i wykonywania procesów ETL. Microsoft SQL Server Integration Services wraz
z Microsoft SQL Server: Data Warehousing są elementami platformy BI Microsoft
SQL Server, która dostarcza narzędzi analitycznych zgodnie z technologią OLAP.
−
Microsoft SQL Server Data Warehousing [23] – hurtownia danych oparta o relacyjną
bazę danych. Microsoft SQL Server Data Warehousing wraz z Microsoft SQL Server
Integration Services są elementami platformy BI Microsoft SQL Server, która
dostarcza narzędzi analitycznych zgodnie z technologią OLAP.
−
Kalido [24] – rozwiązanie zawierające zestaw narzędzi BI, zestaw narzędzi
umożliwiających prowadzenie analiz według technologii OLAP, zestaw narzędzi do
integracji danych poprzez zaprojektowanie i realizację procesów ETL oraz hurtownię
danych.
−
SAS System [25] – rozwiązanie zawierające zestaw narzędzi BI, zestaw narzędzi
umożliwiających prowadzenie analiz według technologii OLAP, zestaw narzędzi do
integracji danych poprzez zaprojektowanie i realizację procesów ETL oraz hurtownię
danych. SAS System dysponuje własnym językiem programowania o nazwie SAS,
który zalicza się do języków 4GL (fourth-generation programming language), choć
z uwagi na pewne ograniczenia bywa też określany jako 3,5 GL. Język SAS służy
miedzy innymi do zaprogramowania procesów ETL. Konkurentem języka SAS jest
język R [26]. Język R jest językiem, którego interpretery i specyfikacja są dostępne
bezpłatnie (w porównaniu z drogim środowiskiem uruchomieniowym SAS System).
Język R jest implementacją typu kod otwarty (open source) języka S [28].
−
Insightful [27] – rozwiązanie do prowadzenia analizy statystycznej i data mining.
Insightful jest przeznaczone prowadzenia analiz w technologii OLAP z użyciem
hurtowni danych. Insightful dysponuje własnym językiem S-PLUS, który jest
komercyjną implementacją języka S [28].
16
2.2.4. Narzędzia użyteczne w budowie hurtowni danych
Wśród narządzi przydatnych do stworzenia modelu pojęciowo-funkcjonalnego, a następnie
do prac nad logicznym modelem hurtowni danych warto wymienić wymienione poniżej typy
narzędzi.
−
Narzędzia do budowania ontologii – ułatwią budowę i upowszechnienie ontologii,
która stanie się słownikiem definiującym terminy opisujące wspólny obraz
działalności korporacyjnej. Słownik ten powinien zawierać wszystkie pojęcia
opisujące obiekty występujące w modelu pojęciowo-funkcjonalnym. Przykładem
takiego narzędzia jest FaCT lub FaCT++ [37,38]. Ponadto FaCT i FaCT++ jest
narzędziem zawierającym automatyczne wnioskowanie z użyciem DLR, co czyni go
szczególnie przydatnym dla formalizacji modelu pojęciowo-funkcjonalnego
i weryfikacji właściwości modelu pojęciowo-funkcjonalnego [3].
−
Narzędzia do projektowania baz danych, aplikacji, systemów informacyjnych,
narzędzia CASE – ułatwią budowę modeli pojęciowo-funkcjonalnych i umożliwią jego
zapis. Przykładami takich narzędzi są: DBDesigner 4 [39], CA ERwin® Modeling
Suite [40], PowerDesigner [41], ArgoUML [42], Oracle Developer [43].
−
Narzędzia do prototypowania zapytań – ułatwią i umożliwią specyfikacje logiki
zapytań i aplikacji procesu ETL. Przykładem takiego narzędzia posiadającego
wsparcie dla uszczegółowionych zapytań jest DaRe [3].
2.3.
Zastosowanie ASM do budowy hurtowni danych
Abstract State Machines (ASMs) zostało stworzone jako narzędzie do wysokopoziomowego projektowania systemów i ich analizy. Ideą ASM polega na dostarczeniu
projektantom i analitykom zunifikowanego formalizmu z czysto matematyczną semantyką
bez popadania w pułapkę ograniczenia metod formalnych. Zgodnie z podaną ideą, formalizm
ASM ma być używany na wszystkich poziomach rozwoju systemu oraz być na tyle
elastycznym, aby uchwycić wymagania na dosyć ogólnym poziomie i jednocześnie pozwolić
na uzyskanie wykonalnej specyfikacji systemu. Dlatego formalizm ASM jest precyzyjny,
zwięzły, abstrakcyjny i kompletny, dosyć prosty i łatwy do obsługi, a także używa wyłącznie
podstawowej matematyki. Budowanie systemu z użyciem ASM rozpoczyna się od definicji
podstawowego modelu (ground model) ASM (lub kilku powiązanych modeli), którego
głównym zadaniem jest uchwycenie wymagań. Dalszy rozwój następuje na drodze rafinacji
modelu (modeli) ASM przy użyciu dosyć generalnych pojęć oczyszczania poprzez cykle
oczyszczania i walidacji.
Podstawowy ASM można zdefiniować w następujący sposób:
(
ASM M
)
(
)
IMPORT M 1 r11 ,K r1n1 ,K, M k rk1 ,K, rknk
,
EXPORT q1 ,K, ql
(11)
SIGNATURE
gdzie:
M – etykieta opisywanej aktualnie ASM;
M i – etykieta ASM zdefiniowanej gdzie indziej;
rij – nazwy funkcji i reguł importowanych z ASM M i , które zostały zdefiniowane w ciele M i
i są jedynie używane w M i ;
17
q1 ,K, ql – nazwy funkcji i reguł, które mogą zostać zaimportowane i używane przez inne
ASM (inne niż M );
SIGNATURE – sygnatura ASM, która składa się ze skończonej listy funkcji f1 ,K, f m ,
dla każdej z funkcji f i podaje się arność tej funkcji, która jest oznaczana jako ari i jest liczbą
całkowitą nie ujemną.
W pracy [4] autorzy podali dalszą specyfikację ASM i zaproponowali użycie ASM jako
metody budowy hurtowni danych z uwagi na jej wysoki poziom formalizacji. Zaproponowali
oni użycie trzy warstwowego modelu hurtowni danych:
1. warstwa źródeł danych;
2. warstwa wewnętrznych struktur zdefiniowanych przy użyciu schematu
gwiazdy lub płatka śniegu;
3. warstwa prezentacji danych do analizy (data marts).
Dla każdej z wymienionych warstw skonstruowali oni podstawowy model danych, który
poddali następnie rafinacji. Autorzy podali formalne reguły rafinacji oraz przedstawili
praktyczne wskazówki użycia podanych reguł.
Metoda zastosowania ASM do budowy hurtowni danych jest warta przytoczenia w tej pracy,
ponieważ prawdopodobnie umożliwia weryfikację części kryteriów jakości na już na samym
początku budowy hurtowni danych [4], a przez to warta jest uwzględnienia w rozważenia nad
metodami i technologiami budowy danych ze szczególnym zapewnieniem długookresowej
jakości produktu i dalszej obserwacji.
3. Opracowana metodyka
Przedstawione powyżej metodyki budowy hurtowni danych prezentują szereg metod
stosowanych do budowy hurtowni, które stosowane są w procesach projektowania,
wdrażania i bywają użyteczne w procesie utrzymania hurtowni danych.
Metodyka łącząca typowe metody budowy hurtowni danych, kładzie silny nacisk ma
pojęciowe i logiczne struktury źródeł danych i hurtowni danych oraz ich wzajemne
mapowanie. Użycie uszczegółowionych zapytań, zapewnienia dobrą jakość przekształcenia
modelu pojęciowego w model logiczny, dobrą jakość identyfikacji obiektów znajdujących się
w logicznych strukturach źródeł oraz dobrą jakość wypełniania struktur logicznych hurtowni.
Użycie formalizacji dla uzgodnień korespondencji w trakcie projektowania logicznego,
zapewnia dobrą jakość przekształceń danych pochodzących z logicznych struktur źródeł
w informacje składowane w logicznych strukturach hurtowni danych. W powyższy sposób,
metodyka łącząca typowe metody budowania prawdopodobnie może, dzięki odpowiedniej
formalizacji zapytań, zapewnić dobrą jakość struktur danych hurtowni i dobrą jakość danych
składowanych w hurtowni poprzez procesy ETL w trakcie budowy hurtowni.
Podobne efekty pozwoli zapewne osiągnąć (zgodnie z przewidywaniami), metodologia
oparta na użyciu ASM i metody zaproponowane jako rama dla projektowania scenariuszy
ETL [5].
Ponieważ cykl funkcjonowania hurtowni danych zawiera regularne wykonywanie procesów
ETL, w celu wypełniania jej informacjami utworzonymi na podstawie danych pochodzących
ze źródeł, to:
1. hurtownia danych jest niezwykle czuła na zaburzenia jakości danych występujących
w źródłach lub brak ich dostępności,
2. długookresowa jakość hurtowni danych jest tożsama z jakością informacji
składowanych w HD w wyniku kolejnych wykonań procesów ETL.
18
Opisanej powyżej długookresowej jakości nie mogą zapewnić przedstawione wcześniej
metodyki, ponieważ zapewniają one jakość produktu (jakim jest hurtownia danych), jedynie
poprzez zapewnienie jakości procesu budowy tego produktu, a nie zapewniają jakości
informacji uzyskanych w trakcie kolejnych uruchomień procesów ETL.
W oparciu o powyższe obserwacje i dotychczasowe doświadczenia zespołu realizującego
niniejszą pracę w zakresie projektowania, wdrażania i utrzymania hurtowni danych
zdefiniowano metodykę budowy hurtowni danych, która zapewnia długookresową jakość
hurtowni oraz procedury kontroli jakości danych. Metodyka ta obejmuje procesy
projektowania, wdrażania i utrzymania hurtowni danych i składa się z poniższych elementów.
1. Dla procesów projektowania.
a. Zdefiniowanie kryteriów kontroli poprawności jakościowej danych, które będą
podstawiane w miejsce atrybutów obiektów w modelu pojęciowofunkcjonalnym.
b. Zaprojektowanie mechanizmów obsługi anomalii w danych zgromadzonych
w hurtowni na poziomie interfejsu użytkownika.
c. Włącznie kryteriów kontroli poprawności jakościowej wartości zmiennych
występujących w reprezentacji logicznej struktur źródeł i hurtowni danych, do
uszczegółowienia zapytań mapujących model pojęciowo-funkcjonalny
na model logiczny lub odpowiadających im formalizmów.
d. Włączenie kryteriów kontroli poprawności jakościowej wartości danych do
uzgodnień korespondencji lub odpowiadających im formalizmów, w celu
wprowadzenia kontroli jakościowej na poziomie przekształceń danych
pochodzących z logicznych struktur źródeł w informacje składowane
w logicznych strukturach hurtowni danych.
e. Włączenie kryteriów kontroli poprawności jakościowej do metody
dekompozycji procesów ETL na mniejsze moduły, w celu zrównoleglenia
wykonywania procesów ETL i zwiększenia wydajności procesów ETL oraz
zapewnienia większej kontroli nad jakością produktów poszczególnych działań
w procesach ETL.
f.
Zaprojektowanie systemu czuwającego nad jakością produktów w całości
procesów ETL, tak aby było możliwe skontrolowanie produktów realizacji
poszczególnych modułów uzyskanych ze dekomponowanych procesów ETL
i podjęcie akcji zaradczych lub powiadomienie o utracie jakości w hurtowni
danych. Postuluje się wbudowanie tej funkcjonalności w system
administrujący wykonywaniem procesów ETL.
g. Zapisanie informacji o kryteriach kontroli jakości produktów procesów ETL
w postaci meta danych, które mogłyby zostać użyte przez osoby utrzymujące
hurtownie danych, przez osoby korzystające z hurtowni danych, przez
aplikacje służące do prowadzenia analiz (w celu oznaczenia jakości danych
lub szerzej obsługi przypadków wystąpienia anomalii w informacjach
zgromadzonych w hurtowni danych), przez systemem automatycznej kontroli
i zapewnienia jakości hurtowni danych.
2. Dla procesów wdrożenia.
a. Wdrożenie procesów ETL zgodnie ze zdefiniowanymi w projekcie kryteriami
jakości produktów wykonania tych procesów.
b. Wdrożenie systemu czuwającego nad jakością produktów w całości procesów
ETL zgodnie ze specyfikacją określoną w projekcie.
c. Wdrożenie aplikacji służących do prowadzenia analiz z uwzględnieniem
jakości produktów procesów ETL.
19
3. Dla procesów utrzymania
a. Użytkowanie systemu czuwającego nad jakością produktów w całości
procesów ETL.
b. Korzystanie z aplikacji analitycznych dostarczających informacji o jakości
informacji składowanej w hurtowni lub obsługujących przypadki wystąpienia
anomalii w hurtowni danych.
c. Zapewnienie mechanizmu sprzężenia zwrotnego od osób korzystających
z hurtowni danych do osób utrzymujących hurtownię danych, w celu
zapewnienia przepływu informacji o anomaliach w danych.
d. Zapewnienie mechanizmu przepływu informacji o anomaliach w danych,
informacji o zmianach w strukturach danych lub informacji o jakościowych
zmianach danych zawartych w źródłach danych od osób utrzymujących źródła
danych do osób utrzymujących hurtownię danych.
e. Modyfikacje lub uzupełnienia zdefiniowanych wcześniej kryteriów kontroli
jakości zmiennych, danych i produktów procesów ETL (w zależności od
kontekstu), w przypadku stwierdzenia nie prawidłowości w jakości informacji
składowanych w hurtowni danych, w przypadku zmian w strukturach źródeł
danych lub strukturach hurtowni danych, w przypadku jakościowych zmian
danych źródeł lub jakościowych zmian informacji w hurtowni danych.
Obsługa anomalii w informacjach zgromadzonych w hurtowni danych lub prezentacja
informacji o takich anomaliach w narzędziach, którymi posługuje się użytkownik hurtowni
danych, może być potrzebna na przykład w celu:
−
ostrzeżenia użytkownika przed wadliwymi agregacjami (gdy na przykład brakuje
części lub uszkodzona jest część danych);
−
prezentacji danych, które co prawda nie są całkiem wadliwe, ale na przykład nie
mogły być użyte do dalszych porównań lub agregacji.
4. Moduł Sterujący
Moduł Sterujący (MS) jest systemem przetwarzania danych w HD, którego implementacja
jest niezbędna do przeprowadzenia budowy i utrzymania hurtowni danych zgodnie
z zaproponowaną metodologią zapewnienia długookresowej jakości produktu. Z uwagi na
podział aplikacji Moduł Sterujący na części zwane dalej modułami, cała aplikację będzie się
w dalszej części nazywać aplikacją, systemem, lub managerem.
Procesy przetwarzania danych typu ETL (extract, transform, load) są nierozerwalnie
związane z zasilaniem hurtowni danych. Procesy tego typu to zazwyczaj skomplikowane
procedury informatyczne, wykonywane z reguły automatycznie wówczas, gdy konieczne jest
uaktualnienie danych w hurtowni.
Procesy ETL składają się z atomowych podprocesów, przetwarzających dane cząstkowe.
Wyniki pracy poszczególnych podprocesów stanowią dla innych podprocesów dane do
przetwarzania i w tym sensie można mówić o złożoności procesu ETL. Proces ETL
w opisywanej postaci można przedstawić jako graf, składający się z poszczególnych
etapów/podprocesów, przy czym łuki grafu reprezentują zależności między podprocesami,
natomiast same podprocesy są węzłami grafu. Strukturę taką nazywamy w niniejszej pracy
wzorcem przetwarzania, lub też łańcuchem przetwarzania. Podprocesy, będące
składowymi wzorca przetwarzania nazywamy po prostu zadaniami przetwarzania.
Przykładową strukturę przedstawiono na Rys. 2.
Wykonanie procesu przetwarzania o strukturze tak złożonej jak opisana powyżej niesie za
sobą szereg problemów do rozwiązania:
20
−
Problemy związane z jakością przetwarzanych danych takie jak niekompletność
danych, niepoprawność danych, czy niezrozumiałość danych.
−
Problemy wydajnościowe związane z obciążeniem środowiska, w którym dokonuje
się przetwarzania i oczekiwaniem przez użytkownika, że proces zakończy się w
skończonym czasie
−
Problemy związane z zapewnieniem odporności procesu ETL na awarie środowiska
przetwarzania (braki zasobów, awarie sprzętowe, zatrzymywanie i wznawianie
procesu).
Rys. 2 Przykładowy wzorzec przetwarzania
Dlatego też niezbędny jest system zarządzający realizacją procesu ETL przez nadzór nad
wykonaniem wzorca przetwarzania.
System taki winien zapewnić stały nadzór nad całościowym procesem ETL poprzez:
−
Możliwość
wyboru
strategii
uruchamiania
poszczególnych
podprocesów
zapewniającej na przykład jak najszybsze wykonanie poszczególnych podprocesów
przetwarzania ( w miarę możliwości zrównoleglenie ich działania) lub na przykład
optymalne wykorzystanie dostępnych zasobów
−
Udostępnienie informacji o stanie poszczególnych podprocesów przetwarzania
i postępie całościowym przetwarzania
−
Uwzględnienie zmiany w dostępności
poszczególnych procesów przetwarzania.
zasobów
i
wadliwe
wykonanie
się
Biorąc pod uwagę powyższe wymagania w budowie systemu dają się wyodrębnić 3 moduły:
−
Moduł odpowiedzialny za budowę według określonej strategii harmonogramu
wykonywania procesów. System musi uwzględnić zarówno zależności między
21
procesami, jak i zapotrzebowanie procesów na pamięć, procesory czy miejsce na
dyskach fizycznych maszyny, na której wykonane zostanie przetwarzanie.
Harmonogram musi być dynamicznie korygowany w trakcie pracy systemu, aby
uwzględnić niepoprawne zakończenie przetwarzania się poszczególnych procesów,
brak zasobów do wykonania procesów itp.
−
Moduł odpowiedzialny za uruchamianie procesów przetwarzania według
harmonogramu i związana z tym gospodarka dostępnymi zasobami
(rezerwacja i zwalnianie pamięci/procesorów/miejsca na dysku)
−
Moduł odpowiedzialny za monitorowanie pracy poszczególnych procesów
(w szczególności wykrywanie błędów w ich działaniu) i powiadamianie o tym modułu
odpowiedzialnego za opiekę nad harmonogramem wykonywania procesów
Ideę współpracy między modułami przedstawiono na Rys. 3.
Rys. 3 Organizacja pracy w systemie
Niniejszy rozdział omawia zaimplementowane w ramach pracy narzędzie, spełniające
opisane powyżej warunki. Podrozdział pierwszy omawia funkcjonalność systemu z punktu
widzenia użytkownika. Podrozdział drugi zawiera szczegółowy opis działania i budowy
systemu. W ostatnim podrozdziale przedstawiono propozycję rozbudowy narzędzia.
4.1.
Funkcjonalność systemu
System, w obecnej postaci przy wykonywaniu wzorca przetwarzania współpracuje ściśle
z bazą danych. W strukturze bazy przechowywane są wszystkie informacje na temat
wzorców przetwarzania i zadań będących ich składowymi. Również informacje związane
z pracą systemu takie jak status wykonywanego wzorca, czy wykonywanego zadania
zapisywane są do bazy.
System przetwarza dane zgodnie ze wskazanym wzorcem dla danych z zadanego okresu,
przy czym kwantem w tym okresie przetwarzania jest dzień. Aby rozróżnić proces
przetwarzania danych dla poszczególnych zadań w danym okresie w systemie wprowadzono
22
pojęcie instancji zadania. Termin ten oznacza zadanie przetwarzania dla danych z danego
dnia. Analogicznie można mówić o instancji wzorca agregującej instancje zadań należące
do tego wzorca, dla danego dnia w okresie przetwarzania. Informacje związane z pracą
systemu, takie jak status wykonywanej instancji wzorca, czy status wykonywanej instancji
zadania również zapisywane są do bazy.
W Przykł. 1 omówiono zagadnienia związane z uruchamianiem systemu, jego konfiguracją
i sposobami zatrzymywania i komunikacją systemu z użytkownikiem.
4.1.1. Uruchomienie
System startuje jako aplikacja konsolowa. Użytkownik przy uruchomieniu podaje szereg
parametrów, m.in. określających uruchamiany wzorzec i okres przetwarzania. Poniżej
przedstawiono szczegółowy opis składni wywołania programu.
Przykł. 1: Opis składni wywołania programu
NAME
MsRun - runs Mangment Service for Data Warehouse Processing
VERSION
2.0 RC3 build 2007112801
SYNOPSIS
[SYSTEM STYLE]
ms_run_java.sh -h
ms_run_java.sh [options] &
[JAVA STYLE]
java –jar MsRun.jar -h
java –jar MsRun.jar [options] &
SUMMARY
MsRun is Mangment Service for Data Warehouse Processing. It is designed to be run
in Java Runetime Environment as a standalone deamon process (still experimental). The
deamon can be stopped in soft or hard shutdown mode. User should send USR1 signal
(kill -s USR1 MsRun_PID) to the deamon to start the soft shutdown or USR2 signal (kill s USR2 MsRun_PID) to start the hard shutdown. The MsRun PID can be found in file
"/tmp/MsRun_ms.pid". The MsRun PID can be found in file "/tmp/MsRun_ms.pid".
OPTIONS
-f or --from - begin date of processing period
-t or --to - end date of processing period
-o or --horizon - begin date of processing period, end date is today
23
-d or --days - number of days
-p or --pattern - id (name) of processing pattern
-e or --exit - exit application when all scheduled task instances has been finished
DATE FORMAT
YYYYMMDD, i.e. 20071231
4.1.2. Konfiguracja
Szczegółowa konfiguracja aplikacji przechowywana jest w pliku „usrCfg/msrun.properties”.
Zmieniając wartości parametrów zawartych w pliku użytkownik ma możliwość dopasowania
aplikacji do swoich potrzeb środowiska, w którym będzie ona uruchamiana. Wśród
parametrów znajdują się zarówno te określające miejsce przechowywania istotnych dla
aplikacji danych czy parametry dostępu do bazy danych jak i związane bezpośrednio z pracą
systemu (np. po ilu próbach system ma zrezygnować z uruchamiania instancji zadania –
zakładając, że wszystkie uruchomienia zakończyły się fiaskiem). Parametry poprzedzane są
komentarzami wyjaśniającymi ich znaczenie. Istnieje możliwość zmiany formatu pliku
konfiguracyjnego z formatu Properties na XML. W Przykł. 2 przedstawiono fragment
zawartości przykładowego pliku konfiguracyjnego:
Przykł. 2: Fragment pliku konfiguracyjnego aplikacji
# application Name
appName = MsRun
appVersion = 2.0 RC3
appYear = 2007
appMonth = 11
appDay = 28
appBuildMinor = 01
appScriptName = ms_run_java.sh
appRunningName = ${appScriptName}
# path to file keeping MsRun PID.
msRunPidFile = /tmp/${appName}_ms.pid
# the fist part of message to put into file keeping MsRun PID when no PID found
msRunNoPidMessageFirstPart = # No PID found. Look at process list to find
# the second part of message to put into file keeping MsRun PID when no PID found
msRunNoPidMessageSecondPart = PID.
# path to file keeping Log4J properties.
24
log4JPropertiesFile = log4J.properties
# path to file keeping sql patterns.
sqlPropertiesFile =sql/SQLqueries.properties
TIMESTAMP_FORMAT= yyyy/MM/dd HH:mm:ss
# URL used for connection to MetaData Database.
sqlDBUrl = jdbc:oracle:thin:@palenica:1521:kruk
#user name used for connection to MetaData Database.
sqlDBUser= segmm
#password used for connection to MetaData Database.
sqlDBPasswd= segmmz6
#enable caching for connection to MetaData Database.
sqlCachingEnabled = true
#cashe name used for connection to MetaData Database.
sqlCacheName = SegmmCache
#MinLimit property used for connerction to MetaData Database.
sqlMinLimit = 1
#MaxLimit property used for connerction to MetaData Database.
sqlMaxLimit = 4
#InitialLimit property used for connerction to MetaData Database.
sqlInitialLimit = 1
#ConnectionWaitTimeout property used for connection to MetaData Database.
sqlConnectionWaitTimeout = 5
Użytkownik ma możliwość dokonywania dynamicznych zmian w konfiguracji systemu, bez
wyłączania aplikacji. Po naniesieniu zmian w pliku konfiguracyjnym wystarczy do procesu
systemowego, reprezentującego aplikacje wysłać sygnał HUP.
4.1.3. Zatrzymanie aplikacji
Aplikacja może zostać zatrzymana „miękko” lub „twardo”. W trybie miękkim system czeka
z zakończeniem pracy na zakończenie wykonywania aktualnie uruchomionych instancji
zadań i nie uruchamia już w tym czasie kolejnych instancji, które zgodnie z harmonogramem
powinny być uruchomione w następnej kolejności. W trybie twardym system zakańcza
wszystkie działające w danej chwili instancje i sam zakańcza pracę. Zatrzymanie w trybie
miękkim wywoływane jest przez wysłanie do procesu systemowego, reprezentującego
aplikację sygnału USR1. Zatrzymanie w trybie twardym wywołuje sygnał USR2.
25
4.1.4. Komunikacja systemu z użytkownikiem
Wszystkie informacje o pracy systemu są na bieżąco zapisywane w logach w podkatalogu
„logs”. Informacje zapisywane są do 3 plików. W pliku ms_run2_INFO_log4j.log system
przechowuje informacje związane ze swoją normalną pracą oraz komunikaty o ewentualnych
błędach powstałych w jej czasie. W pliku ms_run2_ERRORS_log4j.log zapisywane są
wyłącznie informacje o wynikłych błędach. Plik ms_run2_ALL_log4j.log przeznaczony jest
raczej dla administratorów i programistów zajmujących się utrzymaniem aplikacji.
Duplikowane są tam wszystkie informacje zapisywane w plikach ms_run2_INFO_log4j.log
i ms_run2_ERRORS_log4j.log uzupełnione o komunikaty pozwalające na bardziej
szczegółowe śledzenie działania aplikacji.
Przedstawiony interfejs aplikacji pozwala na komunikację z nią w skrajnie ubogim
środowisku. Sytuacja taka zdarza się na serwerach produkcyjnych, gdzie np. ze względu
na bezpieczeństwo jedynym sposobem dostępu jest szyfrowany terminal znakowy ssh.
Kolejną zaletą jest możliwość demonizacji aplikacji, to jest jej pracy w tle.
4.1.5. Realizowana funkcjonalność
Dalsza część podrozdziału omawia ogólnie funkcjonalność programu.
Najistotniejszą z realizowanych przez system funkcjonalności jest harmonogramowanie
instancji zadań do wykonania. Dzięki modułowej konstrukcji aplikacji strategie budowy
harmonogramu są łatwe do implementacji i wymiennego użycia. W obecnie
zaimplementowanej strategii instancje zdań porządkowane są w harmonogramie ze względu
na datę w okresie przetwarzania. Instancje zadań mające przetworzyć dane z pierwszego
dnia w okresie przetwarzania zostaną wykonane jako pierwsze. Dodatkowo w budowie
harmonogramu uwzględnia się dostępność i poprawność danych wejściowych dla
poszczególnych instancji zadań. Harmonogram jest cyklicznie przebudowywany w trakcie
trwania aplikacji. Pozwala to uwzględnić w nim pojawienie się oczekiwanych danych
i zasobów. Ponadto w zależności od konfiguracji instancje zakończone błędem mogą zostać
ponownie uwzględnione w harmonogramie. W opisywanej strategii wprowadzony jest
mechanizm kary, na mocy którego instancja wykonana z błędem przed ponownym
uwzględnieniem w harmonogramie zostaje pominięta w x cyklach jego przebudowy.
Kolejną, kluczową dla działania systemu funkcjonalnością jest uruchamianie wg
harmonogramu instancji zadań. System przy uruchamianiu instancji zadań alokuje dla nich
niezbędne zasoby (np. pamięć, czas procesora, miejsce na dysku). Alokacja ma miejsce
tylko wewnątrz aplikacji, na podstawie zapisanych w bazie informacji o dostępnych zasobach
i zapotrzebowaniu na zasoby, generowanym przez poszczególne zadania. Mechanizm ten
pozwala na optymalne obciążenie środowiska, w którym dokonywane jest przetwarzanie.
Następną z realizowanych funkcjonalności jest monitorowanie przetwarzanych instancji
zadań. W trakcie pracy instancji monitorowane są generowane przez nią logi, zużycie przez
nią procesora i zajętość pamięci w środowisku przetwarzania, jak również czas działania. Po
jej zakończeniu sprawdzana jest również dostępność i jakość danych mających być
rezultatem pracy instancji. W ramach monitorowania system nadaje instancji status
określający jej stan w danej chwili. Informacja ta jest zapisywana zarówno w logach jak
i w bazie danych.
Wśród statusów instancji zadań rozróżniamy:
−
UNDEFINED – instancja jeszcze nie została uruchomiona;
−
NOEXC – próba uruchomienia instancji się nie powiodła;
−
RUNNING – instancja pracuje;
26
−
WARNING – pojawił się błąd w trakcie pracy instancji, ale nie jest on krytyczny;
−
DONE – instancja została zakończona;
−
ERROR – pojawił się błąd krytyczny w pracy instancji/ instancja zakończyła się
błędami;
−
RETRY – instancja przeznaczona jest do ponownego uruchomienia;
−
EXCLUDED – instancja została wykluczona z harmonogramu po x uruchomieniach
zakończonych porażką.
Wraz ze zmianami statusów instancji zadań zmienia się status instancji wzorca
przetwarzania.
Ostatnią z opisanych funkcjonalności jest zapis do logów informacji związanych z pracą
systemu. Funkcjonalność ta została już opisana w tym podrozdziale, w części „Komunikacja
systemu z użytkownikiem”.
4.2.
Działanie i budowa systemu
4.2.1. Działanie systemu
System otrzymuje przy uruchomieniu identyfikator wzorca przetwarzania i informacje
o okresie przetwarzania. Na podstawie tych informacji i danych z bazy danych tworzone są
obiektowe reprezentacje wzorca przetwarzania, wchodzących w jego skład zadań i instancji
tych zadań dla podanego okresu przetwarzania.
Instancje
zadań
harmonogramowane
są
do
uruchomienia
według
jednej
z zaimplementowanych
strategii.
Rozpoczyna
pracę
manager
harmonogramu,
uruchamiający zgodnie z powstałym harmonogramem kolejne instancje zadań.
Przed uruchomieniem instancji zadania następuje sprawdzenie dostępności wymaganych
przez instancje zasobów. Po potwierdzeniu dostępności zasobów następuje ich alokacja
i uruchomienie instancji zadania. Po uruchomieniu wszystkich wskazanych przez
harmonogram w danej chwili zadań, lub braku wystarczających zasobów manager zapada
w drzemkę. Budzi się z niej bądź po upływie określonego w konfiguracji czasu bądź po
zakończeniu którejś z uruchomionych instancji zadań. Po wybudzeniu manager odpytuje
harmonogram o instancje do uruchomienia. Harmonogram jest w tym momencie
przebudowywany, aby uwzględnić nowe warunki (np. pojawienie się wymaganych przez
poszczególne instancje danych wejściowych). Manager po otrzymaniu od harmonogramu
instancji podejmuje próbę ich uruchomienia i cykl się powtarza.
27
Rys. 4 Diagram działania systemu
Instancje zadań uruchamiane są równolegle. Uruchomienie każdej instancji odpowiada
uruchomieniu w systemie kolejnej instancji właściwej aplikacji przetwarzającej dane. Dla
przykładu testowego, wykorzystywanego przy tworzeniu opisywanego systemu był to SAS.
Dla każdej instancji zadania tworzone są monitory śledzące zawartość logów generowanych
przez instancje. Śledzone jest również zużycie przez nią zasobów systemowych. Po
zakończeniu instancji następuje powiadomienie o tym fakcie managera harmonogramu
i zwolnienie zajętych zasobów systemowych. Weryfikowana jest również jakość i dostępność
28
stworzonych przez instancje danych. System może w każdej chwili zakończyć działanie po
otrzymaniu sygnału „miękkiego” lub „twardego zatrzymania” bezpośrednio od użytkownika
lub sytemu będącego środowiskiem uruchomieniowym. Użytkownik może również chwilowo
zatrzymać pracę aplikacji żądaniem przeładowania konfiguracji. System obsłuży wtedy to
polecenie i wznowi pracę z nowymi ustawieniami. Dane o stanie instancji a po zakończeniu
jej działania o rezultatach są zapisywane na bieżąco do logów i do bazy danych. Rys. 4
zawiera diagram obrazujący działanie systemu.
4.2.2. Struktura aplikacji
Na poziomie funkcjonalności system składa się z trzech modułów.
1. Moduł harmonogramujący przede wszystkim odpowiedzialny jest za budowę
i dynamiczną aktualizację harmonogramu uruchamiania instancji zdań. Wiąże się
z tym odpowiedzialność za konstrukcję obiektów reprezentujących wzorzec, zadania
i instancje zdań.
2. Moduł uruchamiający uruchamia wg harmonogramu instancje zdań.
3. Moduł monitorujący śledzi stan uruchomionej instancji i efekt jej pracy.
Należy przy tym zaznaczyć, że moduł monitorujący a częściowo i moduł uruchamiający jest
zwielokrotniony na poziomie każdej instancji, to jest dla każdej instancji zadania istnieje
osobny byt monitorujący jej pracę.
Na poziomie struktury fizycznej aplikacji funkcjonalność opisanych powyżej modułów
realizowana jest przez klasy zgromadzone w dwóch kluczowych pakietach (task i schedule)
obsługiwanych przez klasy zgromadzone w szeregu mniejszych pakietów(db, tools, config
i exceptions). Strukturę fizyczną aplikacji przedstawiono na Rys. 5.
Pakiet schedule realizuje funkcjonalność modułu harmonogramującego i modułu
uruchomieniowego. Pakiet task odpowiedzialny jest za realizacje modułu monitoringu.
Znajdują się w nim również klasy związane z obiektową reprezentacją zadań i ich instancji.
Pakiet db odpowiedzialny jest za komunikację systemu z bazą danych. Dostęp do plików
konfiguracyjnych z dowolnego miejsca aplikacji realizowany jest poprzez pakiet config.
Pakiet tools zawiera klasy użytkowe, wykorzystywane przez wszystkie 3 moduły. Między
innymi w pakiecie tym znajdują się klasy pozwalające na zapis do logów.
Aplikacja korzysta z kilku plików, przechowujących dane niezbędne do jej poprawnego
działania. W pliku „SQLqueries.properties”, przechowywanym w podkatalogu SQL znajdują
się sparametryzowane kwerendy SQL. Wykorzystuje je pakiet db, zapewniając komunikacje
z bazą danych.
W pliku „log4j.xml” zdefiniowany jest mechanizm zapisu do logów aplikacji. Przy zapisie
komunikatu do logów definiowany jest jego priorytet.
Dostępne są 4 priorytety:
−
DEBUG
−
INFO
−
WARNING
−
ERROR
29
Rys. 5: Struktura fizyczna aplikacji
W zależności od priorytetu komunikaty trafiają do różnych logów w podkatalogu logs,
wszystkie zaś duplikowane są w pliku ms_run2_ALL_log4j.log. W pliku log4j.xml można
zdefiniować na poziomie zarówno pakietów, jak i konkretnych klas priorytet, poniżej którego
komunikaty nie będą zapisywane do logów. Opisywane plik daje wiele innych możliwości,
30
których opis można znaleźć w dostępnej pod adresem http://logging.apache.org/log4j/
dokumentacji. W pliku config.xml zdefiniowany jest miejsce przechowywania i format
właściwego pliku konfiguracyjnego aplikacji. Aplikacja współpracuje z plikami
konfiguracyjnymi w formacie xml i properties. W chwili obecnej właściwym plikiem
konfiguracyjnym aplikacji jest plik „msrun.properties”.
4.3.
Dalsze plany rozwoju
Prezentowana aplikacja w obecnej postaci spełnia opisane we wstępie rozdziału wymagania,
stawiane managerowi procesów ETL(Extract,Transform,Load). Jest to prototyp a nie w pełni
konkurencyjna, komercyjna aplikacja. Dalszy rozwój aplikacji może nastąpić wg dwóch
ścieżek: akademickiej i komercyjnej.
Niezależnie od wybranej ścieżki rozwoju w dalszych pracach nad aplikacją powinno
uwzględnić się implementacje opisanej poniżej funkcjonalności:
−
System powinien opcjonalnie
poprzednio działający system.
−
System powinien obsługiwać osierocone instancje zadań. Łączy się to z poprzednio
wymienioną funkcjonalnością. Osierocone instancje pojawiają się w przypadku
nagłego przerwania procesu przetwarzania. Może to być wywołane np. zabiciem
procesu systemowego reprezentującego aplikację lub awarią środowiska, w którym
aplikacja została uruchomiona. System powinien rozpoznać stan porzuconej instancji
i wprowadzić/uzupełnić informacje o niej do systemu i bazy danych, usunąć
tymczasowo tworzone przez instancje pliki, ewentualnie podjąć próbę ponownego
uruchomienia instancji zadania.
−
Użytkownik powinien mieć możliwość wymuszenia ponownego uwzględnienia
w harmonogramie usuniętej z niego instancji zadania.
−
System powinien umieć przetwarzać naraz kilka wzorców przetwarzania, przy czym
użytkownik powinien mieć możliwość dodania nowych wzorców przetwarzania
w nowych okresach. Podobnie przydatna byłaby możliwość dodania do
harmonogramu pojedynczego zadania dla podanego przez użytkownika okresu
przetwarzania.
kontynuować
przetwarzanie
rozpoczęte
przez
Rozwój akademickiej postaci aplikacji sprowadza się do rozwijania biblioteki zawierającej
strategie budowy harmonogramu przetwarzania instancji zadań. W ostatniej wersji aplikacji
moduł strategii harmonogramowania został wydzielony z całości aplikacji. Dzięki temu
zabiegowi implementacja nowej strategii staje się znacznie prostsza. Możliwe jest również
testowanie działania aplikacji z różnymi algorytmami harmonogramowania bez konieczności
rekompilacji kodu przy zmianie strategii. Wszystko to znacznie ułatwia pracę nad nowymi,
innowacyjnymi, bardziej wydajnymi czasowo, wykorzystującymi optymalnie zasoby
algorytmami harmonogramowania. Sama implementacja algorytmu jest tu już czynnością
wtórną.
Rozwój skomercjalizowanej wersji aplikacji a więc dążącej do jej jak największej
konkurencyjności powinien uwzględnić poniższe propozycje rozwoju:
−
Przejście w części dostępu do bazy danych na technologie DAO, z wykorzystaniem
Hibernate. Pozwoli to przy dalszym rozwoju aplikacji na znaczne ograniczenie czasu
poświęconego na obsłużenie zdarzeń związanych z dostępem do bazy danych
−
Uniezależnienie pracy aplikacji od rodzaju repozytorium, w którym przechowywane
dane o wzorcach przetwarzania i jego składowych (zamiast bazy danych na przykład
schematy XML). Umożliwi to wykorzystanie aplikacji bez konieczności instalacji
31
dodatkowego oprogramowania (baza danych/ zakładanie nowej, złożonej struktury
w bazie danych).
−
Stworzenie interfejsu zapewniającego komunikacje z aplikacją na bieżąco (przede
wszystkim na potrzeby raportowania aktualnego stanu aplikacji, aktualnego stanu
przetwarzania), na przykład w oparciu o mechanizm gniazdek dla części dotyczącej
komunikacji i schematy XML dla części dotyczącej budowy raportów.
−
Budowa interfejsu webowego we frameworku RubyOnRails, z funkcjonalnością
obejmującą zdalną administrację i wizualną kontrolę nad stanem bieżącym aplikacji.
Proponowany framework zapewnia bardzo szybką konstrukcję interfejsu.
−
Powiadamianie użytkownika przebywającego w innej lokacji o bieżących zdarzeniach
w systemie z wykorzystaniem aplikacji typu jabber lub serwera sms.
5. Wnioski
Przeprowadzony przegląd obecnie stosowanych metod i technologii budowania hurtowni
danych pozwoliła na identyfikację ich zalet i wad. Modelowanie pojęciowo-funkcjonalne
z użyciem formalizmu DLR, metody formalizacji przy użyciu uszczegółowionych zapytań,
mechanizm korespondencji, metodyka użycia ASM oraz zastosowanie ramy projektowania
scenariuszy ETL do budowy hurtowni danych wydają się zapewniać odpowiednią jakość
budowy hurtowni danych, ale są nie wystarczające do zapewnienia długookresowej jakości
produktu. W przeciwieństwie do wymienionych wcześniej metodyk, nowa metodyka budowy
hurtowni danych (przedstawiona w niniejszej pracy) powinna pozwolić zapewnić
długookresową jakość hurtowni danych. W celu udowodnienia tej tezy przystąpiono do
implementacji narzędzia nazwanego Moduł Sterujący, które zostało zaprojektowane zgodnie
z nową metodyką i które pozwoli na praktyczne wdrożenie i sprawdzenie poprawności nowej
metodyki. Konieczna jest dalsza praca, aby dookreślić formalizm dla nowej metodyki
i dokończyć implementację Modułu Sterującego. Przydatnym byłoby również zbudowanie
hurtowni, która byłaby zaprojektowana, wdrożona i użytkowana zgodne z nową metodyką,
aby w pełni zweryfikować poprawność przedstawionej metodyki.
32
Bibliografia
[1] Kimball R., Reeves L., Ross M., Thornthwaite W.: The Data warehouse Lifecycle Toolkit.
Expert Methods for Designing, Developing, and Deploying Data Warehouses. Wiley. 1998
[2] Todman Chris: Projektowanie hurtowni danych. Zarządzanie kontaktami z klientami
(CRM). WNT, 2003
[3] Calvanese D., Dragone L., Nardi D., Rosati R., Trisolini S.: Enterprise modeling and Data
Warehousing in Telecom Italia, Information Systems, 2006, Volume 31, No. 1
[4] Zhao J., Ma H.: M ASM-based design of data warehouses and on-line
analytical processing systems. The Journal of Systems and Software, 2006, Volume 79
[5] Simitsis V., Georgantas A., Terrovitis P., Skiadopoulos M.: A generic and customizable
framework for the design of ETL scenarios. Information Systems, November, 2005, Volume
30, Issue 7
[6] Vassiliadis P., Bouzeghoub M., Quix C.: Towards Quality-Oriented Data Warehouse
Usage and Evolution. Information Systems, 2000, Volume 25, No. 2
[7] IBM: IBM WebSphere DataStage,
http://www-306.ibm.com/software/data/integration/datastage/
[8] IBM: DB2 Warehouse,
http://www-306.ibm.com/software/data/db2/warehouse/
[9] Informatica: Informatica PowerCenter,
http://www.informatica.com/products/powercenter/default.htm
[10] Teradata: Enterprise Data Warehouse,
http://www.teradata.com/enterprise-data-warehouse
[11] Natezza: Data warehouse appliance product information from Netezza,
http://www.netezza.com/products/data-warehouse-appliance-products.cfm
[12] Greenplum: Greenplum - World's Best Database for BI - Products Overview,
http://www.greenplum.com/index.php?page=products
[13] PANTA: PANTA Systems - Oracle based Data Warehouse Appliances,
http://www.pantasys.com/products/overview.html
[14] Sybase: Sybase IQ Analytics Server - Data Warehousing & Mining Tool - Sybase Inc,
http://www.sybase.com/products/datawarehousing/sybaseiq
[15] SAP: SAP - Components & Tools of SAP NetWeaver: SAP NetWeaver Business
Intelligence, http://www.sap.com/platform/netweaver/components/bi/index.epx
[16] Oracle: Oracle Data Warehousing | Oracle Business Intelligence Solutions,
http://www.oracle.com/solutions/business_intelligence/dw_home.html
[17] Oracle: Oracle Business Intelligence Foundation and Tools | Oracle Business
Intelligence, http://www.oracle.com/appserver/business-intelligence/index.html
[18] Oracle: Oracle Data Integrator | Oracle Fusion Middleware,
http://www.oracle.com/products/middleware/oracle-data-integrator.html
[19] Cognos: Data Integration with Cognos 8 Business Intelligence,
http://www.cognos.com/products/cognos8businessintelligence/data-integration.html
[20] Bussiness Objects: Performance Management Applications: BusinessObjects
Warehouse, http://www.businessobjects.com/products/analyticapps/warehouse/default.asp
[21] Bussiness Objects: Data Integration Tools: BusinessObjects Data Integrator,
http://www.businessobjects.com/products/dataintegration/dataintegrator/default.asp
33
[22] Microsoft: Microsoft SQL Server: Integration Services,
http://www.microsoft.com/sql/technologies/integration/default.mspx
[23] Microsoft: Microsoft SQL Server: Data Warehousing,
http://www.microsoft.com/sql/solutions/dw/default.mspx
[24] Kalido: Kalido - Enterprise Data Management Solutions,
http://www.kalido.com/solutions/enterpriseData.asp
[25] Sas: SAS | Enterprise Data Integration Server,
http://www.sas.com/technologies/dw/entetlserver/index.html
[26] The R-Project: The R Project for Statistical Computing,
http://www.r-project.org/
[27] Insightful: Statistical analysis software and data mining software | Insightful,
http://www.insightful.com/products/splus/default.asp
[28] Wikipedia: S (programming language),
http://en.wikipedia.org/wiki/S_programming_language
[29] Calvanese D., De Giacomo G., Lanzerini M., Nardi D., Rosati R.: Description logic
framework for information integration. W: Proceedings of the Sixth International Conference
on Principles of Knowledge Representation and Reasoning (KR’98), 1998, str. 2-13
[30] Trisolini S.M., Lanzerini M., Nardi D.: Data integration and warehousing in Telecom
Italia. W: Proceedings of the ACM SIGMOD International Conference on Management of
Data, 1999, str. 538-539
[31] Calvanese D., De Giacomo G., Lanzerini M., Nardi D., Rosati R.: Use of reconciliation
tool at Telecom Italia. Technical Report DWQ-UNIROMA-007, DWQ Consortium, October
1999
[32] Baader F., Calvanese D., McGuinness D., Nardi D., Patel-Schneider P.F. (Eds.): The
Description Logic Handbook: Theory, Implementation and Applications. Cambrige University
Press, Cambrige, 2003
[33] Donini F.M., Lanzerini M., Nardi D., Schaerf A.: Reasoning in Description logics. W:
Principles of Knowledge Representation, Studies in Logic, Language and Information. Red:
Brewka G., CSLI Publications, 1996, s. 193-238
[34] Borgida A.: Description logics in data management. IEEE Trans. Knowledge Data Eng.,
Vol. 7, No. 5, 1995, s. 671-682
[35] Calvanese D., De Giacomo G., Lanzerini M., Nardi D., Rosati R.: Data integration in data
warehousing. International Journal of Cooperative Information Systems, Volume 10, Number
3, 2001, str. 237-271
[36] Inmon W.: Building the Data Warehouse. Wiley & Sons, New York, 1996
[37] Horrocks I.: Using an expressive description logic: FaCT or fiction ?. W: Proceedings of
the Sixth International Conference on Principles of Knowledge Representation and
Reasoning (KR’98), 1998, str. 636-647
[38] University of Manchester, OWL : FaCT++, http://owl.man.ac.uk/factplusplus/
[39] fabFORCE.net: DBDesigner 4, http://www.fabforce.net/dbdesigner4/
[40] CA: CA ERwin® Modeling Suite, http://www.ca.com/us/products/product.aspx?id=297
[41] Sybase: PowerDesigner,
http://www.sybase.com/products/modelingmetadata/powerdesigner
[42] Tigris.org: ArgoUML, http://argouml.tigris.org/
[43] Oracle: Oracle Developer, http://www.oracle.com/technology/products/jdev/index.html
34