Dane w trakcie przeprowadzki

Drugi problem związany z konsolidacją informacji to przekształcenie danych: translacja do właściwego formatu, ale także bardziej zaawansowane przekształcenia, np. wykonanie wyliczeń, uzupełnień, walidacji itp. W przypadku zasilania hurtowni chodzi o odpowiednie powielenie danych (z pewnymi warunkami), sięgnięcie do tablic słownikowych, dodanie wyliczeń i/lub podsumowań itp. Liczy się także właściwe partycjonowanie informacji, dokonywanie porównań zbiorów itp. Tak naprawdę jest to zarówno zadanie skomplikowane z punktu widzenia samych operacji na danych, jak i organizacji - czyli w jakiej kolejności poszczególne zadania mają być wykonane. Stąd rozwiązanie ETL to nie tylko prosta "pompa do danych", która przenosi i ewentualnie przekształca informacje, ale też rozwiązanie, w którym modelowane są procesy biznesowe.

Microsoft SQL Server 2005 oferuje w tej dziedzinie usługi Integration Services, będące następcami usług DTS z SQL Server 2000. W SQL Server 2005 proces ETL został rozdzielony na dwie niezależne części. Projektant definiuje w Visual Studio tzw. Control Flow, czyli kolejność wykonywania zadań (pętle, iteracje po elementach słownikowych, rozgałęzienia warunkowe itp.). Jednym z zadań może być tzw. Data Flow, który wykonuje określoną transformację na danych.

Podobnie jest w przypadku bazy danych Oracle. Częścią Warehouse Builder (dodatku do wersji Oracle 9/10g) jest moduł pozwalający "narysować" zależności pomiędzy poszczególnymi transformacjami. Kod generowany jest w języku XML Process Definition Language, który może być uruchomiony potem przez komponent typu workflow realizujący dany przepływ. Rozbudowa XPDL o własne operacje sprowadza się do wystartowania odpowiedniego procesu zewnętrznego. To jest pewien mankament, albowiem odwoływanie się do kodu zewnętrznego w stosunku do serwera - zwłaszcza jeśli będzie się to wiązać z przekazaniem do niego większej porcji danych - będzie w bardzo istotny sposób osłabiać wydajność całego rozwiązania ETL.

W przypadku rozwiązań SAS Institute zaprojektowane przepływy nie są uruchamiane, lecz konwertowane do postaci programu w języku SAS, który potem jest wykonywany w ramach środowiska. Nie ma tu problemu z rozbudową schematów przepływów w ramach całego procesu ETL - oczywiście pod warunkiem, że daną operację da się w języku SAS napisać wydajnie.

Jednym z trudniejszych zadań podczas projektowania rozwiązań ETL jest testowanie scenariuszy przetwarzania i ich optymalizacja. Tak naprawdę nie da się tego zrobić dobrze bez pracy z kopią rzeczywistej bazy. Niestety, niewiele firm dysponuje infrastrukturą, która mogłaby posłużyć za środowisko testowe. Analityk ma więc zazwyczaj do dyspozycji słabsze serwery i musi rozsądnie wybrać porcje danych, aby być w stanie wykryć ewentualne wąskie gardła w przypadku "własnych" komponentów biorących udział w procesie ETL.

Dane ze znakiem Q

Na to wszystko nakłada się problem związany z jakością informacji. Rzadko jest tak, że w różnych systemach dostępne są wspólne identyfikatory, które jednoznacznie identyfikują klientów lub indeksy towarowe. Nawet NIP może nie być unikatowy, jeśli, dajmy na to, został błędnie wprowadzony, o co wcale nie jest trudno. Zwykle trzeba porównywać dane na podstawie opisów czy innych charakterystyk (masa, wymiary).

Sprawą porównywania danych zajął się ostatnio Microsoft. W SQL Server 2005 wprowadzony został operator przybliżonego porównania, będący implementacją logiki rozmytej, np. na potrzeby grupowania informacji podobnych (fuzzy grupping). Można też sięgnąć do modelu Data Mining i na jego podstawie decydować o przynależności do grupy. Konkretnych implementacji dla typowych problemów jeszcze nie ma.

Z kolei Oracle Warehouse Builder ma zdefiniowane specjalne rozwiązanie przeznaczone do poprawiania nazw i adresów, które opiera się głównie na bibliotekach zewnętrznych dostosowywanych przez partnerów. Można także definiować reguły w operatorze Match-Merge, który decyduje o tym, czy dane wiersze są takie same, porównując odpowiednie kolumny.

Bardzo ciekawy produkt do porównywania danych oferuje SAS Institute. Na podstawie słowników (także polskich) potrafi on np. uporządkować adresy. Specjalne narzędzie administracyjne pozwala też przeprowadzić proces standaryzacji, np. sposobu zapisu adresu. Działa to w ten sposób, że wybiera się grupy rekordów zawierające podobne dane i automatycznie dobiera ewentualne transformacje dla wpisów niepasujących do wartości uznanej za właściwą. System potrafi np. rozpoznać, czy przekazany tekst jest nazwą firmy, czy określa osobę prywatną. Rozwiązanie oferuje bardzo dużo opcji konfiguracyjnych, ale oczywiście nie jest nieomylne.

Rozwiązanie do czyszczenia danych zawartych w bazach danych oferuje także IBM, który na początku br. wszedł w ich posiadanie wraz z przejęciem Ascential Software, o czym pisaliśmy w CW 12/2005. Szczególnie interesujące jest narzędzie QualityStage. Można je stosować zarówno jako rozwiązanie do jednorazowej operacji czyszczenia danych, ale także - w połączeniu z innymi narzędziami z portfolio Ascential - do bieżącego utrzymania jakości danych i niedopuszczania do pogorszenia ich jakości z biegiem czasu. Ascential był pod tym względem liderem rynkowym - firma wypracowała wiele dziedzinowych algorytmów (dane teleadresowe, nazwiska itp.) i słowników ułatwiających proces czyszczenia danych.

Mapa z metadanych

W ramach procesu ETL, a także później - przy okazji analizy danych i raportowania - projektant cały czas odwołuje się do konkretnych zbiorów danych - tabel w bazie, plików w katalogach itd. Aby to uprościć, stosowane są metadane, które w formie przyjaznej dla człowieka nazwy reprezentują bardziej skomplikowane obiekty i sposoby dostępu do nich. Dzięki abstrakcji wprowadzanej przez metadane struktura i lokalizacja rzeczywistych zasobów mogą się zmieniać, co jednak nie rodzi konieczności wprowadzania zmian do projektu rozwiązania ETL.

W Oracle Warehouse Builder (od wersji 10g) dostępny jest mechanizm przechowywania obrazu różnych wersji obiektów używanych przy projektowaniu hurtowni. Zapamiętywany jest pełny obraz każdej poprzedniej wersji projektu, który można porównać z aktualną strukturą. Podobnie jak w przypadku kostek OLAP w SQL Server 2005, w Warehouse Builder można zdefiniować translacje pojęć używanych do opisu metadanych. Do tego repozytorium zdefiniowane zostały interfejsy API dla języka Java, pozwalające na uzyskanie dostępu lub zmianę definicji obiektu lub wartości jej atrybutu skojarzonego z konkretną aplikacją.

Jednym z elementów platformy SAS jest serwer metadanych przechowujący określone "źródła informacji" (wyrażenia SQL, procedury napisane w języku SAS itp.) z przypisanymi nazwami. Pierwszym etapem przy projektowaniu przepływu w ETL jest więc w rozwiązaniach SAS określenie źródeł, zdefiniowanie metadanych, np. przez wskazanie określonych tabel czy pola/wyrażenia SQL, które są później wykorzystywane w procesie projektowania. Metadane są wspólne dla wszystkich przepływów w ramach projektu. Niestety, przynajmniej na razie brakuje wersjonowania metadanych - nie można cofnąć się do starszej wersji. W aktualnej wersji metadane są tylko pomocą projektanta. Ostateczny kod SAS wygenerowany na podstawie przepływu odwołuje się bezpośrednio do obiektów, które wskazuje określona metadefinicja.

Tworząc nowy tzw. pakiet (zestaw przepływów) za pomocą usług Integration Services w Microsoft SQL Server 2005 można definiować źródło danych i widoki, które na podstawie źródeł danych wybierają i nazywają określone obiekty. Co ciekawe, mechanizm UDM pozwala w podobny sposób traktować dane relacyjne i pochodzące z kostek OLAP. Niestety, te informacje nie są dostępne globalnie, a jedynie w ramach jednego pakietu zapisanego w postaci pliku XML.

Warto tu także wspomnieć o warstwie metadanych w rozwiązaniu AquaLogic firmy BEA Systems. Nie jest ono przeznaczone dla procesów ETL, ale pozwala elegancko opisywać różne źródła danych i określić zasady ich aktualizacji lub pobierania informacji z nich. Na tej podstawie można zbudować rozwiązanie konsolidacyjne - nie na zasadzie łączenia danych z różnych źródeł, ale poprzez łączenie operacji wydzielonych z systemów przedsiębiorstwa, w szczególności operacji pobrania określonej statystyki. Nawiasem mówiąc, podobnie można postąpić, używając dowolnej platformy do modelowania procesów biznesowych (Tibco, Microsoft BizTalk Server itp.), bo tak naprawdę nie zawsze występuje potrzeba, by pobierać wszystkie dane i agregować je w jakiejś olbrzymiej superstrukturze. Czasem wystarczy jedynie wybrać z określonego systemu pewne podsumowanie i potem zaprezentować je np. na portalu.