pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Nowe Technologie', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2007
Rozdział 10
w
Przyrostowa ekstrakcja danych ETL( δ ): aspekty
implementacyjno-wydajnościowe
w
1 Wstęp
da
.b
w
Streszczenie. W celu poprawy dostępności danych do analiz w hurtowniach
danych zaproponowano rozbudowę funkcjonalności eksploatowanego systemu ETL o proces przyrostowej ekstrakcji danych źródłowych ( δ ). Taki system ETL( δ ) pozwala zachować pełną historię zmian w danych początkowych, a aktualizacja może odbywać się równolegle z dostępem do danych.
W rozdziale przedstawiono wybrane aspekty implementacyjne oraz ocenę
wydajności reprezentatywnych procesów ekstrakcji.
pl
s.
Obecnie dostęp do aktualnych danych, w jak najkrótszym czasie staje się kluczowym zagadnieniem projektowanych systemów hurtowni danych. Przyrostowa ekstrakcja danych
jest jedną z cech hurtowni danych czasu rzeczywistego, dla których określony jest maksymalny, stosunkowo krótki czas propagacji zmian w źródłach danych. Oczywiście trudno
mówić tu o czasach rzędu milisekund, ale rząd minut jest rozsądną granicą do osiągnięcia.
W pracy [1] podjęto próbę analizy tego problemu. Autorzy zaproponowali trójwarstwową architekturę procesu ETL (ang. Extraction, Transformation, Load – ETL), w której
każda warstwa jest funkcjonalnym rozwinięciem odpowiadającej jej części procesu. Dane
w systemie ETL były reprezentowane w języku XML, połączenia pomiędzy warstwami odbywały się bezpośrednio, poprzez szybkie złączki, bez składowania danych pośrednich w
plikach. System ten zaimplementowano w środowisku J2EE ETL w formie zbioru kontenerów, usług i adapterów, bez udokumentowanych praktycznych wyników.
W pracy [2] przedstawiono pewne definicje i problemy realizacji hurtowni danych czasu
rzeczywistego. Omówiono współbieżność aktualizacji (aktualizacja danych wraz z równoległym dostępem do danych) oraz czas aktualizacji samych danych w hurtowni, wydłużony
o aktualizację wszelkich struktur wzmacniających wykonanie analiz danych.
W pracy [3] przestawiono system ETL( δ ) uwzględniający w klasycznym procesie ETL
proces przyrostowej aktualizacji danych δ dzięki detekcji zmian w danych źródłowych.
Takie podejście jest kontynuacją wcześniejszych badaniach własnych [5–11] i kolejnym
krokiem w realizacji ciągłej integracji danych.
W pracy [4] przedstawiono analizy wydajnościowe podstawowych komponentów tj.:
detekcji zmian, grupowania systemu ETL( δ ), które wykazały ich dużą użyteczność.
Marcin Gorawski, Mariusz Ciepluch
Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice, Polska
email:{m.gorawski, m.ciepluch}@polsl.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2007
M. Gorawski, M. Ciepluch
w
Uwzględniając, że typowa liczba zmian w danych źródłowych jest średnio rzędu 5%, zysk
z wykorzystania systemu dla takiego przypadku jest widoczny. Drugą korzyścią z zastosowania systemu ETL( δ ) jest to, że przy cyklicznie wykonywanych aktualizacjach można
zachować aktualność i kompletność danych w hurtowni (zwykle trudno osiągalne w klasycznym procesie ETL). Relacje pomiędzy zbiorem danych przyrostowych a pełnym zbiorem danych są złożone. To wymusza szybki dostęp do pozostałych danych niezmienionych,
które w procesie ETL( δ ) są blokowane. W systemie ETL( δ ) przyjęto rozwiązanie bazujące na przechowywaniu i zarządzaniu lokalnymi repozytoriami, zawierającymi aktualne dane. To powoduje, że dane są powielane wielokrotnie w procesie ekstrakcji do docelowej
hurtowni i mają wyraźny wpływ na całościową wydajność tego systemu. Wykazano, że
zyski z użycia systemu ETL( δ ) z tak zaprojektowanymi komponentami są wyższe niż poniesione koszty.
Celem tego rozdziału jest przybliżenie kolejnych aspektów implementacyjno-wydajnościowych systemu ETL( δ ), którego kluczowym zadaniem jest przyrostowa aktualizacja
hurtowni danych, z zachowaniem pełnej historii zmian i dostępności dla analiz.
w
w
2 Proces ETL(δ)
da
.b
W procesie ETL( δ ) dodajemy detekcję zmienionych danych źródłowych (rys. 1) na samym początku klasycznego procesu ETL i operujemy dalej tylko na samych zmienionych
danych [12]. Pozwala to na przyrostowe aktualizowanie danych w hurtowni, z zachowaniem historii zmian, co przy dobrej współbieżności zapewnia ciągłą dostępność systemu.
Właśnie ta ostatnia cecha, czyli ciągła dostępność danych, jest pożądana dla procesu
ETL( δ ). Więcej szczegółów można znaleźć w pracy [1], [2].
Hurtownia
danych
Ładowanie
Ładowanie
Ekstrakcja
Pliki
Bazy danych
Źródła danych
pl
s.
ETL
Transformacja
ETL( )
Hurtownia
danych
Transformacja
δ
Detekcja zmian
Ekstrakcja
Pliki
Bazy danych
Źródła danych
Rys. 1. Różnice pomiędzy procesami ETL (po lewej) i ETL(δ) (po prawej)
Detekcja zmian w danych początkowych
Proces detekcji zmian w danych początkowych jest złożony, a sprawne wykonanie detekcji
jest podstawą szybkiego procesu ETL( δ ). Optymalny dla systemu hurtowni danych jest
bezpośredni dostęp do samych zmienionych danych (wtedy ciężar detekcji zmian jest przerzucany na ich źródło). Jedną z możliwości, jest wykorzystanie systemu zarządzania dany116
Przyrostowa ekstrakcja danych ETL(δ) – aspekty implementacyjno-wydajnościowe
w
mi (RDBMS) np. poprzez zastosowanie wyzwalaczy. Drugą z możliwości jest przypadek,
gdy w bazie jest przechowywany czas operacji zmiany każdej krotki (np. w bazach czasowych). Możemy zauważyć, że przez wykonanie zapytania czasowego możemy uzyskać
wszystkie dane zmienione. Trzecią możliwością jest takie skonfigurowanie RDBMS’a, aby
wykonywane operacje były zapisywane do pliku dziennika. Potem odtwarzając listę zmian
zapisaną w pliku dziennika, można znaleźć dane, które uległy zmianie. Czwartą możliwością są źródła „odpytywane”, które pozwalają na okresowe odpytywanie w celu wykrycia
zmian [14].
Jednak nie wszystkie bazy danych mają możliwość aktywnego raportowania o zmianach, dlatego musi istnieć sposób detekcji zmian po stronie systemu ETL( δ ). Wykorzystano tutaj metodę porównywania migawek, opartą o znaczniki każdej krotki [1], [2]. Sprowadza to proces detekcji zmian do prostego porównania pojedynczych wartości całkowitych.
Tak, więc przez sekwencyjne przeglądanie dwóch zbiorów można wykryć zmiany w danych początkowych. Oczywiście, do poprawnej identyfikacji krotki, trzeba zachować osobno klucz każdej krotki wraz z jej znacznikiem. Szczegóły algorytmu porównania dwóch migawek (przed i po), opartego o znaczniki można poznać w [1].
w
w
3 System ETL(δ)
da
.b
System ETL( δ ) zaimplementowany w języku Java jest modyfikacją już istniejącego systemu ETL [5]. Dla prawidłowego jego funkcjonowania wprowadzono kilka zmian.
− Zdefiniowano typ krotki, aby odzwierciedlić wynik detekcji. Każda krotka może być
jednego z czterech typów: nowa (N), zmieniona (U), usunięta (D), bez zmian (C).
Każdy typ odzwierciedla rodzaj modyfikacji danej krotki od czasu poprzedniej detekcji.
− Przeprojektowano komponenty ETL tak, aby operowały na typach krotek.
− Dodano komponent detekcji zmian, który wykrywa zmiany w danych źródłowych
i nadaje typ każdej krotce.
System ETL( δ ) implementuje przyrostową aktualizację docelowych tablic. Na podstawie wykrytych zmienionych danych przeprowadza, w oparciu o nie, częściową transformację i tworzy docelowe zmiany w tabelach. Te zmiany po stronie insertorów są określonego
rodzaju (N, D lub U). Zatem wdrażamy je odpowiednio wg dwóch możliwych scenariuszy:
1) krotki typu U i D są wstawiane jako nowe, ale nadpisują odpowiednie odniesienie do
poprzednich ich wartości; 2) krotki typu U nadpisują poprzednie wartości, a krotki D są
usuwane z systemu. Krotki typu N są zawsze wstawiane do systemu. Jak widać, możemy
sterować przechowywaną historią i zarządzać nią po stronie insertorów, w zależności od
wybranego scenariusza aktualizacji docelowych tabel. W obecnej wersji systemu ETL( δ )
przyjęto dla uproszczenia drugi sposób.
Niektóre komponenty transformacji dla prawidłowego swojego działania muszą znać pozostałe dane, dlatego posiadają lokalne repozytoria przetwarzanych danych. Dla przykładu,
komponent grupowania musi znać rozkład wszystkich dotychczasowych grup, aby móc poprawnie dopasować przybyłą krotkę do istniejącej już grupy, albo stworzyć dla niej nową
grupę. Komponenty wymagały pewnych modyfikacji związanych z występowaniem znaczników, bowiem przetwarzanie opiera się tylko o dane zmienione (krotki typu N, U, D).
pl
s.
117
4 Implementacja systemu ETL(δ)
System ETL(δ) jest rozbudowanym o proces δ systemem ETL, w którym główny schemat
klas można przedstawić jak na rys. 2.
A b s tra c tN o d e
w
E x tra c t o r
T ra n s f ro m a t io n
In p u t G ro u p
1
*
w
w
O u tp u t
In s e rt e r
1
A t t rib u t e s
O u tp u tB u ffer
*
In p u t
Rys. 2. Schemat głównych klas systemu
da
.b
pl
s.
Każdy komponent w systemie pochodzi od klasy bazowej AbstractNode i odpowiadającej mu jednej ze specjalizacji: ekstrakcji (klasa Extractor), transformacji (klasa Transformation) lub wstawiania (klasa Inserter). Każda z tych klas posiada wejście (klasa InputGroup) i/lub wyjście (klasa Output) z/do komponentu. Na wejście komponentu składają się
obiekty klasy Input, które reprezentują pojedyncze połączenie pomiędzy sąsiadującymi
komponentami. Na klasę wyjścia komponentu składa się bufor wyjściowy implementowany w klasie OutputBuffer. Wyjście i wejście komponentu posiada określoną relację w postaci obiektu klasy Attributes. Wydzielenie obiektu klasy relacji pozwala na łatwe zarządzanie obiektami krotek przechodzących przez system, bowiem w takim przypadku pojedyncza krotka niesie tylko dane, a ta klasa odpowiada za pozostałe operacje na krotkach (np.
wyznaczanie kluczy) oraz przechowują informacje o typie relacji.
Połączenie pomiędzy sąsiednimi komponentami odbywa się na drodze obiektów: OutputBuffer komponentu poprzedzającego (pole w klasie Output) oraz Input[i] komponentu
następującego (przerywana linia na rys. 2). Na wyjściu jest N kanałów odbiorczych (N jest
liczbą następujących komponentów), do których z osobna wpływa kolejna kopia danych.
Każdy następujący komponent posiada przydzielony mu numer kanału odbiorczego w buforze wyjściowym dla zapewnia niezależnego odbioru danych.
W systemie można wyróżnić kilka typów połączeń: a) dane, będące połączeniem kierunkowym pomiędzy dwoma sąsiednimi komponentami, gdzie przekazywane są dane (pakiety
krotek – linia ciągła), b) komunikaty, przekazywane na drodze: komponent, a zarządca
komponentów. Służą one sterowaniu działaniem systemu (linia wykropkowana), c) zapisy
dziennika i błędy, przekazywane do osobnego obiektu dziennika, który je wszystkie magazynuje i przetwarza (linia przerywana).
Zarządca komponentów odpowiada za prawidłową pracę i konfigurację komponentów.
W przypadku wystąpienia wyjątku, kończy działanie systemu ETL( δ ).
118
4.3 Komponenty
w
4.3.1 Komponent detekcji zmian
Dla zachowania uniwersalności komponent detekcji zmian został opracowany jako osobny
obiekt. Przy takim rozwiązaniu jest niezależny od tego, jaki ekstraktor będzie go poprzedzał. Jego zadaniem jest wykrycie danych zmienionych na podstawie aktualnie otrzymanych danych i swojego repozytorium danych poprzednich, a następnie wysłać je (same dane zmienione) z odpowiednimi znacznikami N, U i D.
Komponent detekcji zmian porównuje migawki metodą opartą o znaczniki. W wyniku
tego porównania zostaje wyznaczony typ każdej krotki (N, U, D). Dodatkowo, dla poprawnego działania systemu krotki typu U i D są uzupełniane poprzednimi wartościami z lokalnego repozytorium wartości poprzednich, które są osobno przechowywane przez komponent w plikach danych. Osobne przechowanie wartości krotek i skrótów służy do przyspieszenia operacji poprzez uniknięcie wyliczania skrótów dla poprzednich wartości danych
oraz w celu odtworzenia samych wartości krotek. W obecnej implementacji przyjęto rozwiązanie oparte o binarne pliki dyskowe, przechowywane lokalnie. Algorytm detekcji
zmian opartej o znaczniki został szczegółowo opisany w pozycji [1].
w
w
da
.b
4.3.2 Komponenty ekstrakcji danych
Wyróżniono dwa komponenty ekstrakcji: z pliku tekstowego i z bazy danych. Oba są ekstraktorami biernymi i dla prawidłowego ich funkcjonowania tuż za nimi powinien się znaleźć komponent detekcji zmian. Funkcjonalność ekstraktorów sprowadza się do sekwencyjnego pobierania danych ze źródła (kolejnych linii z pliku, czy wierszy z tabeli bazie danych), opakowania ich w obiekt krotki i wysłania do bufora wyjściowego. W obecnej implementacji przyjęto jako źródła, pliki tekstowe, w których każda linia to nowy wiersz, kolumny rozdzielone są określonym i definiowanym separatorem oraz ich liczba jest stała we
wszystkich wierszach. Oczywiście dopisanie ekstraktorów czytających dane z innych plików, czy baz danych innego typu niż relacyjnych, jest także możliwe.
pl
s.
4.3.3 Komponenty transformacji danych
Komponenty transformacji danych podzielono na komponenty zależne i niezależne od
wcześniejszych danych. Komponenty zależne wymagają przechowywania wszystkich swoich pośrednich wyników oraz ich aktualizacji wraz z napływem kolejnych krotek. Przechowywanie danych następuje w lokalnych binarnych plikach, z opcjonalnym dodatkowym indeksem na podstawie zmodyfikowanego B-drzewa lub cachem danych wejściowych. Komponenty niezależne nie wymagają znajomości danych, tylko przetwarzają każdą krotkę
w locie.
Do komponentów zależnych możemy zaliczyć komponent agregacji, komponent grupowania oraz komponent złączenia.
Komponent Agregacji pozwala zrealizować funkcje agregacji (jedna z pięciu funkcji:
SUM, AVG, COUNT, MIN, MAX) na wszystkich danych przechodzących przez komponent. Dane funkcje agregacji są rozdzielne, więc dla prawidłowego funkcjonowania, komponent musi przechowywać aktualne wartości poszczególnych agregatów pomiędzy kolejnymi etapami procesu. Dwie pierwsze funkcje (SUM i COUNT) poprawiają sumę lub liczebność krotek. W przypadku funkcji średniej (AVG) musimy znać sumę i liczebność, aby
móc poprawnie określać średnią wraz z przepływem kolejnych danych. W przypadku funkcji minimum i maksimum (MIN i MAX) pojawia się problem z odtworzeniem wartości po
wykasowaniu aktualnej wartości ekstremalnej. Dlatego funkcje te przechowują N ostatnich
119
w
wartości ekstremalnych, dzięki czemu jesteśmy w stanie określić nowe ekstremum. Jest to
pewne ograniczenie systemu, bowiem po wykorzystaniu wszystkich N liczb, następujące
wyniki są już obarczone możliwym błędem wyboru wartości, która może nie być poprawną
wartością ekstremalną. Dlatego dobór właściwej liczby N, podobnie jak wybór właściwej
funkcji wyznaczającej znacznik krotki jest trudny.
Komponent Grupowania pozwala wykonać funkcje agregacji, ale osobno w każdej znalezionej grupie. W przypadku tego komponentu, należy znać wartość każdego agregatu
w każdej grupie z osobna. Dlatego dla każdej wyznaczonej grupy przechowuje się osobną
tablicę wyników wykonywanych agregatów, które są aktualizowane wraz z nadchodzeniem
kolejnych krotek. Drugą różnicą w grupowaniu jest to, że na wyjściu pojawiają się inne dane, niż na wejściu. Wynikowe krotki są złożeniem klucza grupy i aktualnych dla niego wartości agregatów, a znacznik wynikowej krotki jest uzależniony od tego czy dana grupa została zmodyfikowana (znacznik U), czy dodana (znacznik N), lub usunięta (znacznik D).
Komponent Złączenia umożliwia dopasowanie krotki z dwóch wejść na podstawie klucza złączenia. Każdorazowe przybycie krotki na wejście powoduje wykonanie następujących czynności: 1) aktualizację wpisu w pliku danych, 2) dodanie do listy krotek przybyłych w danym etapie (przechowywany jest klucz i skrót krotki oraz jej typ, a na koniec
3) próba złączenia krotki, czyli odszukanie pasującej krotki -(ek) (o tym samym kluczu złączenia) z sąsiedniego wejścia. W trakcie działania komponentu Złączenia wyróżnia się dwa
typy złączenia: 1) warunkowy, gdy dane na drugim wejściu ciągle napływają. W takim
przypadku nie można łączyć danej z wejścia pierwszego z drugim wejściem, dopóki nie ma
pewności, że dana krotka jest aktualna; (2) bezwarunkowy, gdy dane na drugim wejściu już
nie napływają. Wtedy istnieje pewność, że wpisy w listach danych są aktualne i każdą przybyłą krotkę z wejścia pierwszego łączy się z krotką z wejścia drugiego w momencie dopasowania.
Dla potrzeb złączenia zostało zaimplementowane rozwinięcie B+drzewa, obsługujące
złączenie, dalej nazywane drzewem złączeń. Główną ideą drzewa złączeń jest przechowanie
dwóch indeksów (z dwóch wejść komponentu złączenia) w jednym wspólnym B+drzewie.
Gdy wyszukuje się miejsce dla danego klucza, znajdujemy dany wpis (o danym kluczu)
i mamy tam od razu wszystkie klucze (z obu wejść) mające taki sam klucz złączenia. Czyli
przy jednym dostępie można określić wszystkie potencjalne krotki do złączenia.
Poziom liści takiego drzewa składa się z dwóch list (oznaczonych jako List, po jednej
dla każdego z wejść), składających się z JoinElement, gdzie pojedynczy JoinElement
składa się z 3 pól:
− long:filePos – opisujący położenie krotki w pliku danych,
− int:hashCode – opisujący jej skrót, dla identyfikacji właściwej krotki,
− byte:type – opisujący jej typ w danym etapie (lub 0, jeśli C).
List są listami wszystkich elementów z danego wejścia (1 lub 2), które mają dany klucz
złączenia (X lub Y). Taki pojedynczy element jest w stanie zidentyfikować krotkę (na
podstawie skrótu hashCode) jak i wskazać jej położenie w pliku danych (przez położenie
filePos). Przykładowa organizacja komponentu złączenia została przedstawiona na rys. 3.
Upraszczając, algorytm działania można opisać następującymi krokami:
− wyznacz klucz złączenia dla danej krotki,
− wyszukaj właściwy element (JoinTreeElement) dla danego klucza,
− dodaj/zaktualizuj wpis w odpowiednim pliku danych,
− dodaj/zaktualizuj wpis dla elementu,
− dokonaj złączenia, z uwzględnieniem warunków i zależności.
da
.b
w
w
pl
s.
120
B+Drzewo
JoinTreeElement
JoinTreeElement
JoinTreeElement
Klucz: 5
DataFile1
X | 47 | C
DataFile2
Y|5|C
X:
w
2 | 5 | Jan | Nowak | 40
Y:
5 | Dział Techniczny
w
Rys. 3. Przykład drzewa złączeń
Jeśli chodzi o bardziej szczegółowy algorytm samego operowania w elementach drzewa,
można tutaj wyróżnić następujące szczegóły, przedstawione poniżej.
da
.b
w
// jeśli na drugie wejście, czyli te które dołączamy
If(entryNo == 2)
// złączenie bezwarunkowe
// łączymy dany element E ze wszystkimi elementami z wejścia 1)
Foreach(JoinElem e : entries1)
Join(E, e)
pl
s.
// jeśli na pierwsze wejście, czyli te do które dołączamy
Else if (entryNo == 1)
// złączenie warunkowe jeśli drugie wejście zakończyło się
If(secondFinised)
// łączymy dany element E ze wszystkimi wpisami z wejścia 2)
Join(E, e)
// jeśli dana krotka jest wykasowana
If(E.type == D)
Entries1.delete(E)
// kasujemy wpis
else
E.type = 0
// inaczej gasimy typ (ustawiamy na C)
// robimy to, żeby potem dany element już nie był rozpatrywany
// tutaj na drugie wejście mogą nadejść dane, wiec musimy uważać na
// typy i rozpatrywać tylko te, które są ustawione (zaktualizowane)
else
// łączymy ze wszystkimi wpisami z wejścia drugiego,
// których typ jest ustawiony (wartość różna od 0)
If(e.type != 0)
Join(E, e)
Można zauważyć, że każde przybycie nowej krotki inicjuje złączenie: a) bezwarunkowe,
jeśli przyszła na drugie wejście oraz b) warunkowe, jeśli na pierwsze wejście.
Jednak taki proces jest niepełny. Można sobie wyobrazić, że pewne krotki (o danym kluczu złączenia) nie przybyły na drugie wejście i nie zainicjowały złączenia. Dodatkowo musimy zgasić wszystkie flagi, przed uruchomieniem kolejnego etapu, bowiem obowiązują
tylko w obrębie jednego etapu (potem są rozpatrywane jako typ C). Na koniec musimy wywołać proces przeglądający wszystkie dane i dokonujący złączenia i gaszenia typów.
Do komponentów niezależnych od danych możemy zaliczyć komponent Filtracji (weryfikuje krotki pod względem spełniania określonego warunku filtracji), Unii (poziome złączenie krotek z N wejść), Projekcji (wydzielenie podrelacji z relacji wyjściowej), Scalania
(poziome złączenie danych z kilku wejść), Generacji (generacja dane na podstawie przybyłych danych), Sortowania (porządkuje dane wg ustalonego porządku).
121
w
4.3.4 Komponenty wstawiania danych
W przypadku komponentów wstawiania danych do docelowej tabeli w bazie danych, w zależności od typu przybyłej krotki musimy wykonać jedną z 3 operacji: INSERT dla krotek
typu N, UPDATE dla krotek typu U oraz DELETE dla krotek typu D. Dodatkowo musimy
zadbać, aby zachować właściwą kolejność aktualizacji, zgodnie z poniższą kolejnością
przetwarzania: 1) nowych linii w wymiarach (znacznik N), 2) zmienionych linii w wymiarach (znacznik U), 3) nowych linii w faktach (znacznik N), 4) zmienionych linii w faktach
(znacznik U), 5) usuniętych linii w faktach (znacznik D), 6) usuniętych linii w wymiarach
(znacznik D).
w
5 Przykłady procesów ETL( δ )
w
Przedstawiono wyniki testów dla dwóch grafów ekstrakcji danych. Testy zostały wykonane
na komputerze AMD Athlon XP 2600 z 1 GB RAM i składały się z 10 powtórzonych serii
wykonań procesu, przy tych samych danych. Przedstawione wyniki są średnią z tych serii.
Graf ekstrakcji danych dla przykładu 1 został przedstawiony na poniższym rys. 4 (lewa
strona), dla przykładu 2 (prawa strona).
Gen
DBE 1
Union
Group
DBE
Diff
Diff
Group 1
Sort
da
.b
SF
DBE 2
Diff
Proj
Group
SF
Union
Gen
FI
FI
DBE 3
FE
Diff
Join 1
FI
Join 2
FI
Join 3
FI
Group 2
Group 3
Diff
Rys. 4. Graf ekstrakcji danych dla przykładu 1 (po lewej) i dla przykładu 2 (po prawej)
pl
s.
Badania testowe dla przykładu 1 zostały wykonane dla relacji pracownicy w liczebności
100 tys. (DBE). W skład relacji wchodziły następujące atrybuty:
id_pracownik, id_dzial, nazwisko, imie, wiek, pensja.
Pozostałe komponenty można opisać następująco:
− SF, filtracja i podział zbioru danych na dwie połowy (równoliczne);
− Group, w którym grupowanie odbywa właśnie na podstawie atrybutu id_dzial,
a w poszczególnych grupach wykonywany jest pełen zestaw funkcji agregacji na
atrybucie pensja;
− Union, łączenie otrzymanych danych z komponentów;
− Sort, sortowanie danych;
− Proj, wybór podrelacji id_dzial, max(pensja), min(pensja.
Uzyskane wyniki można zobaczyć na wykresie na rys. 5.
Badania dla przykładu 2 zostały wykonane dla relacji:
− sprzedaż o liczebności 500 tys. rekordów (DBE1) i typie zmian N i D. W skład relacji wchodziły następujące atrybuty: id_sprzedaz, id_towar, id_sprzedawca, id_dzial,
ilość, wartość;
− towary o liczebności 1 mln. rekordów (DBE2) i bez zmian. W skład relacji wchodziły następujące atrybuty: id_towar, nazwa, cena, ilość;
− pracownicy w liczebności 100 tys. (DBE3) i typie zmian U. W skład relacji wchodziły następujące atrybuty: id_pracownik, id_dzial, nazwisko, imie, wiek, pensja;
122
− działy w liczebności 10 tys (FE) i typie zmian U. W skład relacji wchodziły następujące atrybuty: id_dzial, nazwa, premia.
80
70
60
w
czas [s]
50
40
30
20
10
w
0
Init
0%
5%
10%
15%
20%
25%
30%
40%
50%
75%
90%
procent zmian w danych źródłowych
DBE
Sort
Proj
FI 1
Union
FI 2
Diff 1
SF 1
SF 2
Gen 2
Group 1
Group 2
Gen 2
Unio 2
w
Rys. 5. Wyniki dla przykładu 1
da
.b
Pozostałe komponenty można opisać następująco.
− Group, w którym grupowanie odbywa się na podstawie odpowiednio atrybutów
id_dzial, id_towar, id_praconik, a w poszczególnych grupach wykonywany jest pełen zestaw funkcji agregacji na atrybucie liczbowym.
− Join, złączenie otrzymanych pogrupowanych danych z odpowiadającymi danymi
źródłowymi.
Uzyskane wyniki zebrano wykresie na rys. 6.
2500
2000
czas [s]
1500
1000
0
init
0%
5%
10%
15%
20%
25%
pl
s.
500
30%
40%
50%
75%
90%
procent zm ian w danych źródłowych
DBE 1
FI 1
FI 2
FI 3
DBE 2
Diff 1
Diff 2
Diff 4
DBE 3
FE
Group 1
Join 1
Group 3
Join 3
Join 2
Group 2
Diff 3
Rys. 6. Wyniki dla przykładu 2
Dla przykładu 1 zbiór danych został podzielony na dwie połowy. Wyniki pokazują, że
uzyskane rezultaty są sparowane w dwuelementowe grupy, dla każdej z połówek. Dodatkową obserwacją jest fakt dużego czasu pracy komponentu filtracji. Dla przykładu 2, uzyskane wyniki tworzą trzy grupy, w tym jedną mocno odbiegająca od pozostałych. Do tej najliczniejszej należą grupowania i złączenia dla towarów i pracowników (oraz sprzedaży), do
drugiej (średnio licznej) należą komponenty detekcji zmian do tych relacji, oraz do relacji
głównej – sprzedaży.
123
6 Podsumowanie i wnioski
w
System ETL( δ ) realizuje proces przyrostowej ekstrakcji danych wykorzystujący ideę ciągłej integracji danych. Jest uzupełnieniem klasycznego systemu ETL o mechanizm procesu
przyrostowej ekstrakcji danych w ramach detekcji zmian w danych źródłowych. System
ETL( δ ) gwarantuje pełną dostępność danych w hurtowni danych oraz zachowanie historii
zmian danych. Wyniki badań potwierdzają fakt większych korzyści uzyskanych z większej
funkcjonalności niż nakłady poniesione na detekcję zmian w danych. Wysoka wydajność
poszczególnych komponentów przekłada się na dobrą wydajność wielokomponentowych
realizacji złożonych procesów ETL( δ ).
w
Literatura
1.
3.
5.
6.
7.
8.
10.
11.
12.
13.
14.
pl
s.
9.
da
.b
4.
w
2.
Bruckner R., List B., Schiefer J.: Striving towards Near Real-Time Data Integration for Data
Warehouses. DaWaK 2002, pp. 317–32.
Raden N.: Real time: get Real. Take the idea of a real-time data warehouse with a grain of salt,
then realize the possibilities. Intelligent Enterprise, vol. 6, no.10, 2003.
Gorawski M., Ciepluch M.: Przyrostowa ekstrakcja danych ETL( δ ). Studia Informatica vol. 27,
1(66), 2006.
Gorawski M., Ciepluch M.: Ocena wydajności komponentów systemu przyrostowej ekstrakcji
danych ETL( δ ) WKŁ, In a joint publication Kozielski S et al.: Databases. Structures,
Algorithms, Methods (Bazy danych. Struktury, algorytmy, metody) Architecture, Formal
Methods and Data Mining (Architektura, metody formalne I eksploracja danych), Conf.
BDAS’06, ISBN 978-83-206-1611-5, pp. 289–298 (2006).
Gorawski M., Piekarek M.: Rozwojowe środowisko ETL/Java Beans. Studia Informatica, vol.
24, 4(56), pp. 288–302, 2003.
Gorawski M., Jabłoński P.: Uniwersalne środowisko graficzne do modelowania procesów
ekstrakcji i odtwarzania. Studia Informatica, vol. 26, 3(64), s. 7–28, 2005.
Gorawski M., Marks P.: Grouping and Joining Transformations in Data Extraction Process. XXI
Autumn Meeting of the Polish Information Processing Society, Conference Proceedings, Wisła,
Poland, ISBN 83-922646-0-6, PIPS pp. 105–113, 2005.
Gorawski M., Piekarek M.: Rozproszony proces ekstrakcji danych z protokołem SimpleRMI.
Bazy Danych - Modele, Technologie, Narzędzia, Eds. St. Kozielski, Wydawnictwo Komunikacji
i Łączności (WKŁ), ISBN 83-206-1572-0, s. 43–50, 2005.
Gorawski M.: Ekstrakcja i integracja danych w czasie rzeczywistym. Praca zbiorowa.
„Współczesne problemy systemów czasu rzeczywistego”, WNT, s. 435–445, 2004.
Gorawski M.: 3 perspektywy procesu ekstrakcji danych. Praca zbiorowa „Strategie
informatyzacji i zarządzanie wiedzą”, Eds. Szyjewski Z., Nowak J., Grabara J.,WNT, ISBN-832004-3014-3, s. 295–341, 2004.
Gorawski M., Siódemak P.: Graficzne projektowanie aplikacji ETL. Studia Informatica, vol. 24,
4(56), s. 345–367, 2003.
Gorawski, M.: Modelowanie procesu ekstrakcji danych. IV Konferencja Metody i systemy
komputerowe w badaniach naukowych i projektowaniu inżynierskim, 26-28 listopad, 2003,
Kraków, Poland, ONT, Ed. Tadeusiewicz R., Ligęza A., Szymkat M., ISBN 83-916420-1-1, s.
165–170, 2003.
Rosana L. de B. A. Rocha, Cardoso L., Souza J.: An Improved Approach in Data Warehousing
ETLM Process for Detection of Changes in Source Data. SBBD 2003, pp. 253–266.
Jennifer Widom: Research Problems in Data Warehousing. Proc of 4th International Conference
on Information and Knowledge Management (CIKM) Nov. 1995.
124

pobierz plik referatu

Transkrypt

Podobne dokumenty

R CD wieża

Ekstrakcja, transformacja i ładowanie danych (ETL