pobierz plik referatu - BDAS

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 29
w
Ocena wydajności komponentów systemu
przyrostowej ekstrakcji danych ETL(δ)
w
1 Wstęp
da
.b
w
Streszczenie. W celu poprawy dostępności danych do analiz w hurtowniach
danych zaproponowano rozszerzenie 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 wyniki badań wydajnościowych podstawowych
komponentów systemu ETL(δ).
pl
s.
Ciągła integracja danych silnie charakteryzuje hurtownie danych czasu rzeczywistego, czyli
takich, w których m.in. maksymalny czas propagacji zmian danych źródłowych jest rzędu
minut [1]. Przyrostowa ekstrakcja danych jest jednym z podprocesów ciągłej integracji
danych, którego podstawą jest detekcja zmian wartości danych w źródłach danych.
Już od samego początku istnienia hurtowni danych, kluczowym elementem stała się jej
aktualizacja. Gdy hurtownia danych efektywnie implementowała zmaterializowane perspektywy, pojawiał się wtedy problem jak propagować do niej zmiany powstałe w jednym
ze źródeł, na którym powstała dana perspektywa. Wtedy pojawiał się problem, że gdy założymy, że dane źródło poinformuje o wystąpieniu pewnej zmiany (np. dodano nowy towar),
to nie jesteśmy w stanie jednoznacznie określić co się stanie, gdy taka prosta i pojedyncza
zmiana przybędzie do hurtowni. Może się w takim przypadku zdarzyć, że będziemy wymagać jakiś dodatkowych danych z innych źródeł, wymuszając od hurtowni danych odpytywania źródeł o te dane, co następuje po wystąpieniu zmiany i może spowodować niespójność danych [18]. Same zmaterializowane perspektywy są tylko pewnym obrazem istniejących źródeł, pod względem interesujących nas kryteriów. Tak więc taka materializacja
perspektyw, zawiera w sobie proces ETL, czyli ekstrakcję (określenie z których źródeł pobieramy dane), transformację (określenie w jaki sposób łączymy źródła, dodając do nich
transformację danych), wstawienie (określając wynikową perspektywę). Tak więc nie ma
jednoznacznego podziały na etapy.
Jednak obecny proces definiowania hurtowni, jest procesem określającym źródła danych, ciąg operacji (transformacji) wykonanych na danych i określeniem miejsc doceloMarcin 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 2006
M. Gorawski, M. Ciepluch
w
wych, gdzie tak przygotowane dane wylądują. Tutaj już odchodzimy od określenia stricte
perspektyw, chociaż na wyższym procesie abstrakcji taka wynikowa hurtownia danych nadal pewnym obrazem źródeł. Analizując problem aktualizacji hurtowni danych, nie traktowany już jako zarządzaniem zmaterializowanym perspektywami może natknąć się na różne
podejścia.
W pracy [1] autorzy zaproponowali trójwarstwową architekturę procesu ETL opisanego
językiem XML, gdzie każda warstwa jest funkcjonalnym rozwinięciem fragmentów procesu. Komunikacja pomiędzy warstwami odbywają się bezpośrednio poprzez szybkie złączki,
bez składowania danych pośrednich w plikach. System ten zaimplementowano w środowisku J2EE ETL bez podania jego osiągów m.in. wydajności, skalowalności.
W pracy [2] przedstawiono pewne definicje i zagadnienia implementacyjne hurtowni
danych czasu rzeczywistego. Zarysowano dwa ważne aspekty zagadnienia: (a) współbieżność aktualizacji (aktualizacja danych wraz z równoległym dostępem do danych) oraz (b)
czas aktualizacji danych w bazie hurtowni, wydłużony o czas aktualizacji wszelkich struktur wzmacniających wykonanie analiz, tj. kostki i markety danych.
W pracy [3] autorzy przedstawiają obiektowe podejście oraz zarysowują problem
utrzymywania historii zmian w docelowej hurtowni danych. Zestawiono wszystkie dane na
tym samym poziomie szczegółowości i opisano wszystkie schematy poszczególnych źródeł, jednym wspólnym schematem. Wprowadzono dodatkowe monitory reagujące na zmiany oraz opakowywacze w powiązaniu z systemem odświeżania hurtowni. Menadżer odświeżania zarządza całym procesem poprzez odebranie danych ze źródeł operacyjnych jako
obiektów i skoordynowanie aktualizacji danych w docelowej hurtowni, bazując na repozytorium metadanych opisujących poszczególne relacje.
W rozdziale zaprezentowano wyniki testów wydajnościowych dla trzech głównych komponentów systemu ETL(δ): detekcji zmian, grupowania, złączenia.
da
.b
w
w
2 System ETL(δ)
pl
s.
Prezentowany system ETL(δ)uwzględnia w klasycznym systemie ETL (ang. Extraction,
Transformation, Load) proces przyrostowej aktualizacji danych δ dzięki detekcji zmian
w danych źródłowych. Takie podejście jest kontynuacją wcześniejszych badaniach własnych [4] – [14] i kolejnym krokiem w realizacji ciągłej integracji danych.
W klasycznym procesie ETL ekstrakcja danych następuje zwykle do pustej struktury
hurtowni danych. W takim przypadku, jeśli chcemy zaktualizować zawartość hurtowni
należy cały proces ETL wykonać od nowa. Takie rozwiązanie obarczone jest stratą czasu
na ponowną ekstrakcję oraz utratę historii zmian w danych. Podczas każdej reekstrakcji
dodatkowo dane w hurtowni są niedostępne dla analiz. Uwzględniając masowość danych
w hurtowniach ciągły proces reekstrakcji i utrata historii zmian obniża znacznie wartość
danych oraz zwiększa koszt ich uzyskania.
W procesie ETL(δ) dodajemy proces detekcji zmienionych danych źródłowych (rys.1)
i operujemy tylko na samych danych przyrostowych [15]. Proces detekcji zmian zachodzi
na samym początku procesu ETL(δ). Pozwala to na przyrostowe aktualizowanie danych
w hurtowni z zachowaniem historii zmian, co przy dobrej współbieżności zapewnia ciągłą
dostępność danych. Właśnie ta ostatnia cecha, czyli ciągła dostępność danych jest pożądaną
dla procesu ETL(δ).
Zaproponowanym rozwiązaniem w tym systemie jest operowanie na wycinku całości
danych, czyli na samych danych zmienionych.
290
Ocena wydajności systemu przyrostowej ekstrakcji danych ETL( δ )
Hurtownia
danych
Ładowanie
Ładowanie
ETL
Transformacja
δ
)
w
Transformacja
ETL(
Hurtownia
danych
Detekcja zmian
Ekstrakcja
w
Pliki
Bazy danych
Źródła danych
Ekstrakcja
Pliki
Bazy danych
Źródła danych
w
Rys. 1. Różnice pomiędzy klasycznym procesem ETL (po lewej) a procesem ETL(δ)
z aktualizacją przyrostową (po prawej)
da
.b
Takie rozwiązanie pociąga za sobą problem zależności pomiędzy danymi i dostępem do
pozostałych danych (nie występujących w przetwarzanej paczce aktualizacyjnej). Ogólnie
wymagania komponentów w takim systemie można podzielić na 3 grupy:
1) niezależne od poprzednich danych (np. filtrowanie);
2) wymagające przechowania poprzedniej wartości podsumowania (np. agregacja);
3) wymagające dostępu do wszystkich poprzednich danych (np. złączenie, grupowanie).
Pierwsza grupa nie wymaga wyjaśnienia. Aby rozwiązać problem dwóch pozostałych,
w systemie przyjęto założenie o przechowaniu lokalnych kopii danych na wejściu, aktualizowanej wraz z pojawianiem się kolejnych zmian w danych. Takie rozwiązanie (tak jak
zapytania zwrotne podczas aktualizacji zmaterializowanych perspektyw) powala na dostęp
do danych, które nie są obecne w danej aktualizacji, a są wymagane do aktualnie transformowanej krotki (np. do złączenia).
pl
s.
3 Badania wydajnościowe komponentów systemu ETL(δ)
Szczegółowe opisy funkcjonale komponentów tworzących system ETL(δ) można znaleźć
w pracy [16]. Poniższe rezultaty testów i analiz dotyczą trzech głównych komponentów
systemu ETL(δ): detekcji zmian, grupowania, złączenia Badania wydajnościowe pozwalają
oszacować opłacalność użycia systemu ETL(δ). Dla wszystkich prezentowanych wariantów badań w/w komponentów procedura badawcza była podobna: wykonanie kilku powtarzalnych badań z pomiarem czasu wykonania dla każdego przypadku, a następnie obliczenie średniej arytmetycznej uzyskanych wyników. Dla czytelniejszej prezentacji, wyniki
zostały przedstawione na wykresie, gdzie oś X stanowi procent zmian w danych źródłowych (procentowy udział liczebności zbioru krotek wysyłany na danym etapie). Innymi
słowy, jaka jest liczebność krotek zmienionych (U – zmodyfikowanych, D – usuniętych, N
– dodanych) na każdym etapie, z odpowiednimi wartościami procentowymi, z dodatkowym
polem Init, mówiącym o początkowym ładowaniu do pustego systemu ETL(δ). Oś Y to oś
czasu pracy komponentu liczonego w sekundach.
291
Badania podzielono na dwie grupy, w pierwszej pokazano jaki wpływ na wydajność ma
organizacja lokalnych repozytoriów danych; w drugim pokazane ma jaki wpływ na wydajność ma typ krotki wejściowej. Wybrano 3 komponenty, bowiem są najbardziej reprezentatywne oraz kluczowe dla całego procesu.
w
3.1 Analiza czasu pracy komponentów systemu ETL(δ) w zależności od metody prze
chowania danych
da
.b
w
w
Poniższe badania dotyczą komponentów: detekcji zmian, grupowania, złączenia w kontekście organizacji danych, zgodnie z ich możliwościami konfiguracyjnymi. Komponenty te są
reprezentatywne dla systemu ETL(δ) pod względem wymagań obliczeniowych prowadzenia testów wydajnościowych. Uzyskane wyniki pokazują wady i zalety poszczególnych
metod przechowania danych tych komponentach. Do tych metod zaliczono:
− skorowidz, czyli przechowywanie kluczy w pamięci, a danych na dysku.
− B+drzewo, które w węzłach przechowuje same klucze, a w liściach odwołania do
danych w pliku.
− skorowidz stronnicowy, czyli podzielenie zbioru na N części i przechowywanie tylko
jednej części w pamięci, a resztę na dysku. Przy każdym odwołaniu do elementu
poza istniejący zakres następuje przeładowanie strony: zapisanie bieżącej i wczytanie
nowej, wg przechowywane indeksu elementów.
− strukturę przechowującą pewien zbiór M ostatnich elementów, które są najczęściej
używane z użyciem buforu LRU [17].
− strukturę bezpośredniego wyznaczania na podstawie klucza położenia w pliku
danych, z użyciem bufora LRU (zwane dalej jako iPersist).
3.1.1 Detekcja zmian
W przypadku testowania komponentu detekcji zmian użyto 5 typów przechowania danych,
w tym 3 opierają się o skorowidz (D0 – D 2), a dwie pozostałe to skorowidz stronnicowy
(D 3.0 oraz D 3.1) i B+drzewo (D 4) (rys. 2).
Czas detekcji zmian w zależności od typu
s.
140
120
80
pl
czas detekcji [s]
100
60
40
20
0
init
0%
5%
10%
15%
20%
25%
30%
40%
50%
75%
90%
procent zmian
D0
D1
D2
D 3.0
D 3.1
D4
Rys. 2. Czas detekcji w zależności od typu przechowania danych w komponencie detekcji
zmian
292
Wydajność tego komponentu dla poszczególnych metod jest podobna poza czasem ładowania początkowego. Najgorzej wypada skorowidz stronicowy, dla którego wydajność komponentu spada w wyniku ciągłego przeładowywania stron i to dla danych posortowanych
(nieakceptowanie niska dla danych nieposortowanych). Dla B+drzewa komponent cechuje
długi czas ładowania początkowego, ale jest to typowa właściwość tego typu struktur. Metoda B+drzewa zapewnia najlepszą wydajność dla co najmniej 50% udziału krotek zmienionych.
w
w
3.1.2 Grupowanie
Badanie komponentu grupowania zostało przeprowadzone dla dwóch wariantów danych
wejściowych: posortowanych i nieposortowanych, względem klucza grupowania. Wyróżniono następujące warianty grupowania: agregaty przechowywane (w całości) w pamięci
(GT 0 - GT 2), skorowidz stronnicowy (GT3.0, GT3.1, a GT5.0 i GT5.1 wersja
z dodatkowym buforem LRU), skorowidz (GT 4, GT 6 wersja z dodatkowym buforem
LRU), wykorzystującego interfejs iPersist (GT 7) oraz B+drzewo (GT 8).
w
czas grupowania w zależności od typu dla danych posortowanych
140
120
czas pracy [s]
80
60
40
20
0
init
da
.b
100
0%
5%
10%
15%
20%
25%
30%
40%
50%
75%
90%
procent zmian
GT 5.0
GT 6
GT 7
GT 8
GT 0
GT 1
GT 2
GT 3.0
GT 3.1
Gt 4
GT 5.1
s.
Rys. 3. Czas grupowania dla posortowanych danych wejściowych, w zależności od sposobu przechowania danych w komponencie grupowania
pl
W przypadku danych posortowanych (rys. 3) wydajność komponentu dla poszczególnych
typów grupowania jest podobna, poza typem GT 3 (3.0, 3.1) oraz GT 4. Jednak po dodaniu
bufora LRU wydajność komponentu osiąga standardowy poziom. Także wzrost czasu
przetwarzania komponentu wraz ze wzrostem procentu zmian w danych źródłowych
w pewnym momencie osiąga, lub nawet przekracza czas ładowania początkowego. W tym
przypadku można określić opłacalność użycia tego komponentu na ok. 50 % zmian
w danych źródłowych.
Dla przypadku danych nieposortowanych (rys. 4) na wejściu względem klucza
grupowania, można zauważyć inny rozkład wyników dla komponentu grupowania. Po
pierwsze, jego wydajność dla metody skorowidza stronnicowego (z i bez bufora LRU) jest
nie klasyfikowana dla tego przypadku, z powodu wydajności gorszej o rzędy wielkości.
Drugą uwagą jest to, że jego wydajność dla skorowidza indeksowego (GT 4 i GT 6
z buforem) odbiega od pozostałych, których wydajność jest porównywalna z sobą.
293
Czas grupowania w zależności od typu dla danych
nieposortowanych
120
w
czas pracy [s]
100
80
60
40
20
w
0
init
0%
5%
10%
15%
20%
25%
30%
40%
50%
75%
90%
procent zmian w danych
GT 7
GT 6
GT 0
GT 8
GT 2
GT 1
GT 4
w
Rys. 4. Czas grupowania dla nieposortowanych danych wejściowych, w zależności od
sposobu przechowania danych w komponencie grupowania
da
.b
3.1.3 Złączenie
Komponent złączenia wymaga dopasowania danych z dwóch różnych i niezależnych wejść.
Dla każdej krotki nadchodzącej na wejście N, musimy dopasować krotkę z wejścia M lub
zadecydować o odrzuceniu krotki. Z tego powodu na każdym wejściu komponentu złączenia są przechowywane wszystkie krotki, które weszły na to wejście (aktualna wersja do
danego etapu), oraz zmiany nadchodzące w danym etapie. Dzięki czemu, dla każdej krotce
na wejściu N, możemy dopasować krotkę z wejścia M. Wadą takiego rozwiązania jest złożoność takiego sposobu, zarówno czasowa, jak i pamięciowa.
Czas złączenia w zależności od typu
1200
1000
czas [s]
600
400
200
0
init
0%
5%
10%
15%
20%
25%
30%
procent zmian w danych
JT 0
JT 1
40%
pl
s.
800
50%
75%
90%
JT 2
Rys. 5. Czas złączenia w zależności od sposobu przechowania danych w komponencie
złączenia
Dla operacji złączenia wyróżnia się 3 typy złączeń: blokujące (JT 0) – blokujemy przyjmowanie krotek na jednym z wejść, dopóki nie zaktualizujemy drugiego wejścia (pobierzemy wszystkie krotki i uaktualnimy wersję bazy lokalnej); nie blokujące (JT 1) – sekwen294
w
cyjne pobieranie krotek z dwóch wejść i warunkowe dopasowywanie, tylko tych, które zostały zaktualizowane; oraz drzewo złączeń (JT2) – specjalną strukturę, która wykorzystuje
fakt, że krotki z dwóch wejść dopasowywane są na podstawie zgodnego klucza, czyli mogą
być przechowywane razem w jednym węźle zmodyfikowanego B+drzewa.
Jak można zauważyć na rys. 5, wraz ze wzrostem procentu zmian w danych źródłowych,
rosną różnice w wydajności poszczególnych typów. Najlepszym typem jest drzewo złączeń, a najgorszym wersja blokująca. Jednak analizując przypadek, że stroną do której dołączamy jest mało liczna (w porównaniu ze stroną dołączaną), należy się spodziewać, że
wersja blokująca będzie wydajniejsza. Drugą uwagą jest to, że w przypadku tego komponentu różnica w wydajności, między ładowaniem początkowym a procentami zmian jest
wyraźna. Widać tutaj duży wpływ zależności pomiędzy dwoma wejściami (dopasowanie na
podstawie równości klucza) na wydajność. Jednak wykorzystanie drzewa złączeń pozwala
osiągnąć wydajność, na poziomie porównywalnym z ładowaniem początkowym.
w
w
3.2 Analiza czasu pracy komponentów systemu ETL( δ ) w zależności od typu krotek
wejściowych
da
.b
Prezentowane wyniki uzyskano dla 3 głównych komponentów: detekcja zmian, grupowania, złączenie dla różnych typów krotek w systemie: zmienionych (U), dodanych (N) i usuniętych (D). Należy przez to rozumieć, że procent zmian był jednolity, czyli były tylko
krotki jednego typu. Jako metodę przechowywania danych, przyjęto w każdym przypadku
strukturę B+drzewa.
3.2.1 Detekcja zmian
Dla komponentu detekcji zmian najbardziej kosztowną operacją jest dodawanie nowych
krotek (rys. 6). Wzrost czasu działania komponentu wraz z procentem zmian danych jest
znaczący, z lekkim odskokiem dla procentowo większych zmian, dążący do czasu ładowania początkowego.
Porównanie czas detekcji w zależności od typu krotki
60
czas [s]
40
30
20
10
0
Init
0%
5%
10%
15%
20%
25%
30%
40%
50%
75%
l
p
s.
50
90%
procent zmian
Diff 1 U
Diff 1 N
Diff 1 D
Rys. 6. Czas detekcji zmian w zależności od typu krotek w komponencie detekcji zmian
Czas pracy komponentu dla krotek typu U jest liniowy, dążący do ok. 40% czasu ładowania
początkowego. Jeśli chodzi o kasowanie krotek (D), to początkowa wydajność komponentu
295
jest najlepsza, ale dla większych zmian w danych można zauważyć skok wydajności, od
wartości ok. 60% ładowania początkowego.
Uzyskane wyniki są skutkiem przyjętej metody przechowywania danych (B+drzewo),
bowiem jest to jej cechą charakterystyczną: duży koszt dodawania nowych węzłów i mniejszy koszt usuwania (chyba, że występuje procentowo dużo krotek zmienianych, powodujący potrzebę kompensacji węzłów)
w
w
3.2.2 Grupowanie
W przypadku komponentu grupowania, wpływ typu krotki na czas pracy dla procentu
zmian nie przekraczającego 50% jest nikły (rys.7). Dopiero powyżej tej granicznej wartości
następuje rozdział na nowe krotki, zaraz potem zmienione i na samym końcu usuwane.
Porównanie czas grupowania w zależności od typu krotki
40
35
w
30
czas [s]
25
20
10
5
0
Init
.b
15
0%
5%
10%
15%
20%
25%
30%
40%
50%
75%
90%
da
procent zmian
Group U
Group N
Group D
Rys. 7. Czas grupowania w zależności od typu krotek w komponencie grupowania
s.
Dobra wydajność tego komponentu dla krotek usuwanych spowodowana jest tym, że usunięcie danego agregatu prowadzi tylko do jego wyzerowania, więc odpada kosztowne usunięcia go ze struktury.
4 Podsumowanie i wnioski
pl
3.2.3 Złączenie
W przypadku testowania komponentu złączenia, widać od razu charakterystykę zachowania
się B+drzewa, czyli duży koszt wstawiania nowych węzłów i kasowania, a mały aktualizacji (rys. 8).
System ETL(δ) realizuje proces ekstrakcji danych opartego o ideę ciągłej integracji danych.
Jest uzupełnieniem klasycznego systemu ETL o mechanizm detekcji zmian w danych źródłowych. System ETL(δ) gwarantuje pełną dostępność danych w hurtowni danych oraz zachowanie historii zmian danych. Analizy wydajnościowe podstawowych komponentów tj.
detekcji zmian, grupowania systemu ETL(δ) wykazały ich dużą użyteczność.
296
Porównanie czasu złączenia w zależności od typu krotki
70
60
40
w
w
czas [s]
50
30
20
10
0
Init
0%
5%
10%
15%
20%
25%
30%
40%
50%
75%
90%
procent zmian
Join U
Join N
Join D
w
Rys. 8. Czas złączenia w zależności od typu krotek w komponencie złączenia
da
.b
Uwzględniając, że typowy liczba zmian w danych źródłowych będzie średnio rzędu 5%
(i mniej), zysk z wykorzystania systemu dla takiego przypadku jest widoczny. Drugą korzyścią z zastosowania systemu ETL(δ) jest to, że przy cyklicznych wykonywanych aktualizacjach jesteśmy w stanie utrzymywać aktualność i kompletność danych w hurtowni, nie
osiągalne w klasycznym procesie ETL.
Niestety jest pewien koszt detekcji zmian w danych i operowania tylko na podzbiorze
danych, co wymaga tworzenia, przechowywania i zarządzania lokalnymi kopiami danych.
Tym większy im więcej czasu tracimy sami na wykrycie zmiany w danych źródłowych.
Jednak można przyjąć rozwiązanie optymistyczne, w którym detekcję zmian przerzucamy
na same źródła danych, czy zewnętrzne systemy, lub monitory zmian, działające w trybie
ciągłym. W każdym z tych przypadków, mamy na początku kolejnego etapu aktualizacji,
już gotowe dane przyrostowe. Wtedy zadaniem systemu ETL(δ) jest przetworzenie tych
danych przyrostowych i załadowanie ich do docelowej hurtowni danych.
Relacje pomiędzy danymi przyrostowymi a pełnym zbiorem danych są złożone. To
wymusza szybki dostęp do pozostałych danych nie zmienionych, które w procesie ETL(δ)
są blokowane. W systemie ETL(δ) przyjęto rozwiązanie, bazujące na przechowywaniu
i zarządzaniu lokalnymi bazami, zawierającymi aktualne dane. Powoduje to, że dane są powielane wielokrotnie w procesie ekstrakcji do docelowej hurtowni i ma wyraźny wpływ na
całościową wydajność tego systemu.
Kolejną ważną kwestią jest to, że przeprowadzone badania (przy przyjętej implementacji w języku JAVA oraz architekturze x86) wykazały duże zapotrzebowanie komponentów
systemu ETL(δ) na pamięć, miejscami nieosiągalne dla architektury x86. Oczywiście, jest
to zależne od przyjętych rozwiązań, dlatego i w tej kwestii jest możliwość optymalizacji,
czy nawet wykorzystaniu architektur klasy wyższej od x86.
Podsumowując, zyski z użycia systemu ETL(δ) z tak zaprojektowanymi komponentami są wyższe niż koszty poniesione. Kluczowym zadaniem tego systemu jest przyrostowa
aktualizacja hurtowni danych, z zachowaniem pełnej historii zmian i dostępności dla analiz.
I stąd system ETL(δ) jest silnie rozwijany.
pl
s.
297
Literatura
1.
2.
3.
w
Bruckner R., List B., Schiefer J.: Striving towards Near Real-Time Data Integration for Data
Warehouses. DaWaK 2002, s.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.
Athanasios Vavouras, Stella Gatziu, Klaus R. Dittrich „Modeling and Executing the Data
Warehouse Refreshment Process”. International Symposium on Database Applications in NonTraditional Environments (DANTE '99), Kyoto, Japan. IEEE CS 1999, ISBN 0-7695-0496-5.
Gorawski M., Jabłoński P.: Uniwersalne środowisko graficzne do modelowania procesów
ekstrakcji i odtwarzania. Studia Informatica, vol. 26, 3(64), pp.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, Wydawnictwa Komunikacji
i Łączności (WKŁ), ISBN 83-206-1572-0, pp. 43-50, 2005.
Gorawski M., Marks P.: Data Loading based on UB-Tree Index Implemented in DesignResume/JavaBeans Environment. Studia Informatica, vol. 25, 1(57), pp.141-154, 2004.
Gorawski M., Piekarek M.: Rozwojowe środowisko ETL/JavaBeans wzbogacone o roz-proszone
sortowanie danych. Praca zbiorowa „Współczesne problemy sieci komputerowych” WNT,
pp.173-180, 2004.
Gorawski M.: Ekstrakcja i integracja danych w czasie rzeczywistym. Praca zbiorowa.
„Współczesne problemy systemów czasu rzeczywistego”, WNT, pp. 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, pp. 295-295-341, 2004.
Gorawski M.: Charakterystyka procesu ekstrakcji danych. Studia Informatica, vol. 24, 4(56),
pp.212-232, 2003.
Gorawski M., Piekarek M.: Rozwojowe środowisko ETL/Java Beans. Studia Informatica, vol.
24, 4(56), pp.288-302, 2003.
Gorawski M., Siódemak P.: Graficzne projektowanie aplikacji ETL. Studia Informatica, vol. 24,
4(56), pp.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, pp.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, s. 253-266.
Gorawski M., Ciepluch M.: Przyrostowa ekstrakcja danych ETL( δ ). Studia Informatica 2006.
Gorawski M., Faruga.: Indeksowanie przestrzenno – agregacyjne: R, XBR i aP- drzewa.
CMS'05: Computer Methods and Systems, Kraków, Poland. Oprogramowanie NaukowoTechniczne, ISBN 83-916420-3-8, Vol. 2, pp.517-522, 2005.
Hue Y., Garcia-Molina H., Hammer J., Widom J.: View Maintence In a Warehousing
Enviroment.
4.
5.
7.
8.
10.
11.
12.
13.
14.
16.
17.
18.
pl
s.
15.
da
.b
9.
w
w
6.
298

pobierz plik referatu - BDAS

Transkrypt

Podobne dokumenty

Pobierz PDF

35. Omów zadania wykonywane podczas procesu ETL

Konsultant ds. Business Intelligence / ETL

Polityka Jakości ETL Finance Sp z o.o.

densitron det043wvnmcmis-4a

projektant_hurtowni_danych_3.11.2010 03/11/2010, 12:35

Konsultant BI

Ework Reshaping Consulting - Big Data Analytics Engineer

TERMOSTAT ELEKTRONICZNY ETL 011

TERMOSTAT ELEKTRONICZNY