Oracle Data Integrator

Jadwiga Gnybek

 

Gromadzone w systemach komputerowych dane zaliczane są dziś do najważniejszych zasobów każdej firmy. Ich gromadzenie, zabezpieczanie i eksploracja bardzo często decyduje o zdolności firmy w pokonywaniu rynkowej konkurencji. Dane te są najczęściej zbierane lub tworzone w różnych systemach, nie posiadających wspólnego modelu danych. Coraz częściej również stajemy przed koniecznością integracji danych pochodzących z różnych firm. Dlatego właśnie narzędzia służące integracji danych nabierają w ostatnich latach dużego znaczenia.

 

Od trafnego wyboru narzędzi integracyjnych zależy finalny efekt pracy wielu systemów informatycznych, wielu komórek organizacyjnych firmy a w końcu również całego przedsiębiorstwa. Wszyscy wiemy, że systemy przetwarzające dane nie potrafią poprawić ich jakości. Natomiast z pewnością mogą ich jakość pogorszyć. Niewłaściwa integracja danych nie tylko – co oczywiste, może zniszczyć ich spójność, ale również (co nie mniej ważne) znacząco zmniejszyć wydajność pozyskiwania informacji.

Różne integracje

Różnorodność technologii budowy systemów informatycznych sprawiła, że pojęcie integracji znacznie rozszerzyło swoje znaczenie. Z pierwotnie rozumianej integracji na poziomie danych, przeniosło się również do poziomu integracji aplikacji. Mamy zatem do czynienia z dwoma nowymi obszarami: obszarem integracji architektury aplikacji sterowanej zdarzeniami (EDA) oraz obszarem integracji aplikacji zorientowanych serwisowo (SOA). Integracja na poziomie danych siłą rzeczy koncentrowała się na przepływach dużych ich wolumenów. Nowe obszary integracji wymagają natomiast zupełnie innych rozwiązań.

Spore trudności napotykają z tego powodu projekty zawierające co najmniej dwa z wymienionych powyżej obszarów integracji. Skazane są one bowiem na korzystanie z kilku niekoniecznie wzajemnie kompatybilnych narzędzi. System zbudowany w rezultacie takich działań charakteryzuje się zwykle słabą podatnością na wprowadzanie kolejnych modyfikacji, niską wydajnością i skomplikowanymi procedurami utrzymaniowymi.

Nie dziwi zatem fakt, że integracja danych stała się jednym z elementów Oracle Fusion Middleware. Poznajmy więc Oracle Data Integrator – narzędzie, które dostarcza kompleksowego wsparcia zarówno dla hurtowni danych i business intelligence, jak i dla zarządzania w czasie rzeczywistym danymi źródłowymi oraz budowy dostarczających dane biznesowe serwisów SOA.

Ogólnie rzecz biorąc sprawa wygląd prosto – dane powinny być poprawne, dostępne i aktualne. Niestety, aby ten prosty cel osiągnąć, nie wystarczą proste i oczywiste metody. Dane poprawne, to nie znaczy poprawnie przepisane. Dane zbierane z różnych źródeł muszą być oczywiście poprawnie integrowane, zunifikowane i co najważniejsze muszą być rzetelne i aktualne.

Pobrać, przekształcić, załadować

Rozpocząć musimy oczywiście od pozyskania danych, a właściwie zidentyfikowania wszystkich potencjalnych źródeł danych. Oracle Data Integrator wyposażony został w szeroki wachlarz narzędzi umożliwiających pobieranie danych z najróżniejszych źródeł – takich jak pliki płaskie i pliki bazodanowe. Kolejnym elementem tego łańcucha są oczywiście wydajne mechanizmy ETL. Mechanizmy te nie ograniczają się jedynie do przepisania danych. Podczas operacji ETL można bowiem zaprogramować najefektywniejsze wydajnościowo procedury transformacji danych. Ważne jest przy tym, aby o procesach ETL nie myśleć jedynie jak o zbiorze procedur transferujących dane. ETL jest dziś narzędziem realizującym również integrację serwisów SOA, a w szerszym spojrzeniu działającym w czasie rzeczywistym jako data flow naszej organizacji.

Dlatego też dla powodzenia projektów wdrożeniowych szczególnie ważny jest etap projektowania. To wtedy podejmowane są bowiem decyzje, które umożliwią lub skutecznie utrudnią dalszy sterowany zmianami organizacji rozwój mechanizmów wymiany informacji. W procesie tym znaczący udział brać powinni przedstawiciele użytkowników systemów, choć do tej pory było to dość trudne. Uwaga projektantów mechanizmów ETL skupiona była bowiem przede wszystkim na pytaniach „jak przetransferować określone dane”, nie zaś „co i po co transferować”. Dzięki zastosowaniu nowego podejścia do budowania mechanizmów transformacji, udział przedstawicieli biznesu jest znacznie efektywniejszy. ETL Oracle Data Integrator opiera się bowiem na mapowaniu danych w strukturach baz źródłowych na struktury bazy docelowej oraz budowie odpowiadających tym mapowaniom data flow, opartych na wbudowanych szablonach i regułach transformacji.

O resztę technicznych szczegółów troszczy się Oracle Data Integrator Knowledge Module. Moduł ten dzięki wbudowanym rozwiązaniom jest zoptymalizowany pod kątem współpracy z różnymi technologiami przechowywania danych. Dzięki temu dołączanie nowych różnorodnych technologicznie źródeł danych nie powoduje każdorazowo konieczności strojenia wydajności całego ETLa.

Architektura E-LT

Wszystko wskazuje na to, że zaimplementowane przez Oracle rozwiązania otworzą nową epokę w transformacji danych. Dalej historię dzielić będziemy na tę przed E-LT i po nim. Aby dokładnie zrozumieć jakościowa zmianę zaproponowanego rozwiązania, przyjrzyjmy się najpierw tradycyjnemu mechanizmowi ETL czyli ekstrakcji, transformacji i ładowaniu (extract, transform, load). Zgodnie zatem z logiką nazwy, w pierwszym kroku wykonywana jest ekstrakcja danych z baz źródłowych, potem ich obróbka do postaci oczekiwanej, a następnie załadowanie danych do bazy docelowej. Cechą charakterystyczną tego procesu było zawsze duże zapotrzebowanie na moc obliczeniową maszyn, a co za tym idzie konieczność budowy dedykowanych procesom ETL serwerów. Wynikało to oczywiście z konieczności wykonywania transformacji danych metodą wiersz po wierszu na dużych wolumenach przesyłanych informacji. Czasem na etapie tym wykonywane były również działania mające na celu sprawdzenie jakości danych. Kolejnym czynnikiem wpływającym na wydajność tradycyjnego ETL była konieczność dwukrotnego przesyłu danych: ze źródła do serwera transformującego i dalej do bazy docelowej.

Oba te czynniki odpowiadały za duże opóźnienia w prezentacji pozyskiwanych w ten sposób danych. Dodatkowe obciążenia i opóźnienia można było wygenerować poprzez wymaganie sprawdzenia integralności danych w bazie docelowej, w porównaniu z bazą lub bazami źródłowymi. Architektura E-LT podchodzi do problemu transformacji zupełnie inaczej. Poprzez zmianę kolejności operacji przenosi bowiem ciężar transformacji na stronę bazy docelowej wykorzystując do tego celu natywne mechanizmy SQLa.

Projektowanie transformacji

Konwencjonalne podejście do procesu projektowania transformacji danych zakładało konieczność tworzenia wszystkich kolejnych kroków, przeprowadzających model danych baz źródłowych do postaci oczekiwanej w bazie docelowej. Siłą rzeczy był to proces długotrwały i zagrożony możliwością popełnienia błędów – zarówno na poziomie projektu jak i kodowania. Budowa takiego procesu wymagała dużych umiejętności programistycznych i gruntownej biznesowej znajomości obu modeli danych. W rezultacie otrzymywaliśmy zwykle produkt mało przejrzysty i trudny – zarówno w eksploatacji, jak i modyfikacji czy rozwoju. Wiedza dotycząca takich zagadnień, jak np. gdzie i po co zaprojektowaliśmy określone operacje, zacierała się bowiem szybko w pamięci programistów. Jedynym ratunkiem była więc ponowna analiza lub zaufanie do sporządzonej uprzednio dokumentacji.

Nowe podejście do projektowania procesów transformacji skupia się na pytaniu co, nie zajmując się w szczegółach pytaniem w jaki sposób. Techniczne aspekty realizacji transformacji determinowane są przez dołączone do tego narzędzia mechanizmy i reguły. Nasza uwaga w całości może zatem skoncentrować się na biznesowym meritum całej operacji, bez konieczności rozwiązywania problemów technologicznych. Technologią zajmą się moduły wiedzy czyli Knowledge Modules. Każdy z takich modułów przeznaczony jest do wykonywania ściśle określonych zadań. Do dyspozycji mamy więc moduły odpowiedzialne za reverse-engineering metadanych systemów heterogenicznych, obsługę Changed Data Capture (CDC), ładowanie danych, kontrolę integralności oraz prezentację danych.

Czym w praktyce są zatem Knowledge Modules? To szablony kodu przygotowane dla poszczególnych zadań procesu integracji. Co ważne, kod ten nie jest zależny od interfejsów jakie zostaną użyte w celu pozyskania danych z baz źródłowych i umieszczenia ich w bazie docelowej. Podczas projektowania transformacji określić należy jedynie metadane określające proces integracji. Stanowią one bowiem podstawę do działania generatorów kodu Knowledge Modules. Podczas pierwszego uruchomienia procesów integracji, Oracle Data Integrator umieszcza ten kod zarówno po stronie baz źródłowych jak i bazy docelowej. Mimo niebezpiecznie wyglądającej automatyzacji procesu tworzenia kodu, daje on projektantowi spory wybór wykorzystywanych metod i technologii. Na przykład, chcąc przenieść dane pomiędzy dwoma instancjami DBMS, do wyboru mamy loadery – takie jak Oracle’s SQL*Loader, Microsoft SQL Server’s BCP, Teradata Pump lub mechanizmy łączenia baz Oracle Database Links, czy Microsoft SQL Server’s Linked Server. Generowany przez automat kod może być oczywiście edytowany i uzupełniany o ręcznie nanoszone poprawki. Z pewnością ta funkcjonalność okaże się bardzo przydatna w procesie optymalizacji wydajności lub implementacji korporacyjnych standardów. Jeśli jednak nie posiadamy takich potrzeb, bez konieczności „ręcznego programowania” skorzystać możemy z ponad stu modułów realizujących integrację z szerokim wyborem dostępnych na rynku baz danych i aplikacji.

Sterowanie zdarzeniami i wiadomościami

Jeśli procesy integracji pracują w czasie rzeczywistym w środowisku aplikacji sterowanych zdarzeniami, to muszą odpowiednio reagować na komunikaty przesyłane wewnątrz systemu. Dlatego też Oracle Data Integrator wyposażony został w moduł obsługi standardu Java Message Services (JMS). Dzięki temu mechanizmy transformacji subskrybować mogą wiadomości mogące mieć wpływ na procesy integracyjne. Mechanizmy te mogą również służyć do zbierania informacji dotyczących zmian dokonywanych na poziomie bazy danych – na przykład dodania nowego rekordu. Informacje takie przechwytywane przez moduł Changed Data Capture, mogą również stanowić impuls do realizacji zdefiniowanych uprzednio zadań, jeszcze zanim operacja ta pociągnie za sobą wynikające z logiki biznesowej działania aplikacji. Mechanizmy takie mogą okazać się szczególnie wydajne na przykład w stosunku do systemów CRM. Dodanie nowego klienta może wywołać natychmiastowe zadziałanie mechanizmów integracyjnych, co w konsekwencji rozkłada w czasie obciążenie wynikające z konieczności realizacji tych właśnie zadań integracyjnych. Porównując to z klasycznym scenariuszem ETL, baza CRM każdorazowo przed ekstrakcją musi zostać przeszukana na okoliczność istnienia danych przyrostowych. Dane te następnie w jednej dużej paczce poddawane są zwykle transformacji, bardzo obciążającej maszyny.

Moduł Changed Data Capture identyfikuje i rejestruje zdarzenia polegające na dodaniu, modyfikacji lub usunięciu informacji z bazy. Informacje o takich zdarzeniach przekazywane są następnie do innych modułów Oracle Data Integratora, gdzie służyć mogą jako sygnały sterujące dla zdefiniowanych uprzednio zadań integracyjnych. Oczywiście sygnałami takimi mogą być również komunikaty pochodzące z aplikacji sterowanych zdarzeniami. Dla potrzeb procesów integracyjnych może być stosowana dowolna kombinacja obu metod zbierania informacji o życiu systemu. W monitorowaniu zmian danych na poziomie bazodanowym Changed Data Capture wykorzystuje dwa sposoby zdobywania informacji. Pierwszy z nich polega na wprowadzeniu do bazy triggerów informujących o monitorowanych zdarzeniach lub przeglądaniu logów bazy. W przypadku rejestracji wiadomości publikowanych przez systemy sterowane zdarzeniami, Changed Data Capture występuje w systemie w charakterze standardowego subskrybenta informacji.

Pojedyncze zmiany danych w bazach źródłowych rzadko kiedy stanowią samodzielne zdarzenie biznesowe. Niemalże każdej operacji towarzyszy zmiana informacji, zapisywana w różnych miejscach modelu danych. Dlatego też zachowanie spójności danych integrowanych w czasie rzeczywistym wymaga wprowadzenia dodatkowego mechanizmu kompletowania informacji o transakcjach. W pakiecie zadanie takie spełnia moduł Consistent Set CDC.

Kolejny element middleware

Oracle Data Integrator niewątpliwie stanowi kolejny element systematycznie rozbudowywanego środowiska middleware. W praktyce oznacza to jego naturalne połączenie z istniejącymi już na rynku rozwiązaniami systemowymi i technologicznymi. Czołowym przykładem takiej integracji jest Oracle SOA Suite połączony z Oracle Data Integratorem poprzez serwisy transformacji i dostępu do danych oraz serwisy dostępu via Web. Serwisy te generowane automatycznie przez Oracle Data Integrator i umieszczane w systemie jako kolejny web serwis, uruchamiamy z serwera aplikacji Java. Jeśli teraz utworzone w ten sposób serwisy dostępu do danych zapisanych w bazie połączymy z zadaniami realizowanymi przez Changed Data Capture, otrzymamy doskonale wtopiony w architekturę systemu kanał przenoszenia danych. Mechanizmy integracyjne stają się bowiem jednym z wielu subskrybentów krążących po systemie danych. Oczywiście integracja taka możliwa jest również w odniesieniu do serwisów dostarczanych przez firmy trzecie.

W trosce o integralność danych

Integralność danych to pięta achillesowa wielu systemów transformacji danych. Stąd też zadania związane z utrzymaniem wysokiej jakości integrowanych danych, stanowią znaczącą część funkcjonalności zaimplementowanej w pakiecie Oracle Data Integrator.

Podstawą dokonywania sprawdzenia jakości danych są zdefiniowane w systemie, a przechowywane w repozytorium metadanych reguły integralności danych (data integrity rules). Reguły te obejmować muszą całokształt modelu danych wykorzystywanego przez systemy informatyczne danej firmy. To bowiem od ich dokładności zależy finalny efekt integracji czyli jakość, a więc także przydatność zbieranych z różnych źródeł danych. Nikomu do niczego nie są bowiem potrzebne informacje nie dające spójnego obrazu realizowanych procesów biznesowych. Dlatego też o jakość danych trzeba dbać w sposób ciągły; na nic zdadzą się tu prowadzone od czasu do czasu kontrole, wprowadzenie niespójnych danych jest bowiem procesem trudnym do naprawienia.

Tak właśnie w większości przypadków działa Oracle Data Integrator. Zapisane w jego repozytorium reguły sprawdzane są na bieżąco w odniesieniu do każdej wykonywanej operacji. Co więcej, reguły te mogą być generowane automatycznie na podstawie zależności zdefiniowanych w modelu danych. Proces reverse-engineering zainicjowany na strukturach baz źródłowych może w istotny sposób odciążyć projektantów od definiowania kryteriów sprawdzeń. Oczywiście istnieje możliwość ręcznego dodawania reguł, których istnienie nie wynika z informacji zapisanych w słownikach bazy. Najbardziej oczywistymi typami takich reguł są oczywiście reguły unikalności danych, reguły sprawdzające formalną poprawność merytorycznej zawartości rekordu oraz reguły zapewniające spójność danych zapisanych w różnych tabelach bazy.

W uzasadnionych biznesowo przypadkach integralność danych może być też sprawdzana w trybie audytu, czyli przeglądu wszystkich danych zgromadzonych w bazie docelowej. Celem przeprowadzenia audytu może być na przykład zgromadzenie statystyk integralności lub usunięcie danych niespójnych do wydzielonego obszaru bazy. Działania takie z jednej strony pozwalają na dokonywanie analiz dla identyfikacji interfejsów aplikacji, umożliwiających wprowadzanie do systemu niespójnych danych; z drugiej strony mogą stanowić przygotowanie do „ręcznego” okresowego czyszczenia danych. Możliwe jest również podłączenie do zadań realizowanych przez Oracle Data Integrator specjalizowanych w czyszczeniu danych narzędzi – takich jak Trillium TS Quality.

Słowo o architekturze

Oracle Data Integrator jest pakietem złożonym z modułów składujących dane konfiguracyjne we wspólnym repozytorium metadanych. Elementy uruchomieniowe zrealizowane są w postaci komponentów Java, które mogą być instalowane i uruchamiane na dowolnej platformie.

Interfejs użytkownika składa się z czterech podstawowych elementów, a są to: Designer, Operator, Topology Manager i Security Manager. Designer – jak łatwo zgadnąć, jest modułem pozwalającym na definiowanie reguł transformacji i zapewnianie integralności danych. Informacje wprowadzane za pomocą tego interfejsu zapisywane są w repozytorium Integratora. Dane te mogą być również do repozytorium importowane. Zgromadzone w ten sposób informacje służą modułowi Designera do generacji scenariuszy i zadań integracyjnych. Do kontroli ich realizacji w środowisku produkcyjnym służy natomiast moduł Operator. W przejrzystej graficznej formie monitorować tu można na bieżąco liczbę poddanych transformacji wierszy, statystyki realizacji zadań integracyjnych, logi i komunikaty o błędach. Moduł ten może również służyć do debugowania uruchomionych już fragmentów kodu. Aby spojrzeć na całość realizowanych zadań bardziej kompleksowo, Oracle Data Integrator wyposażony został w konsolę Topology Manager. Jest to narzędzie służące do definiowania fizycznej i logicznej architektury całego rozwiązania. To tu właśnie rozpoczyna się praca nad ogólnym kształtem przyszłego rozwiązania. Ostatni z elementów tego interfejsu, czyli Security Manager, to oczywiście moduł służący do administrowania dostępem do pozostałych konsol Integratora. Jest to podstawowe narzędzie pracy administratora bezpieczeństwa systemu.

Wszystkie elementy wchodzące w skład infrastruktury informatycznej, w której implementowana jest integracja danych za pośrednictwem Oracle Data Integrator, wyposażone są oczywiście w koordynujące ich współpracę agenty, które sterują wdrażaniem i egzekwowaniem zadań integracyjnych. Do ich podstawowych zadań należy bowiem pobranie odpowiednich fragmentów kodu z repozytorium i uruchomienie tego kodu na odpowiednim elemencie infrastruktury informatycznej (bazie danych, systemie operacyjnym serwera itp.). Po zakończeniu wykonania zadania agent dokonuje również odpowiedniego wpisu w plikach logów, metadanych, raportach błędów i statystykach wykonanych prac. Zapisy te wykorzystywane są później przez konsolę Operatora lub interfejs Metadata Navigator. Technologicznie rzecz ujmując, agenty są małymi, wielowątkowymi komponentami, na których realizowane mogą być operacje load-balancingu.

Kolejnym istotnym elementem pakietu Oracle Data Integrator jest repozytorium. Na jego strukturę składa się repozytorium główne i kilka repozytoriów roboczych. Repozytoria te mogą być zaimplementowane na dowolnej relacyjnej bazie danych. W repozytorium głównym znajdziemy oczywiście informacje dotyczące zdefiniowanych użytkowników systemu i ich przywilejów oraz na temat topologii systemu. Repozytoria robocze powstają na skutek implementacji i instalacji projektu. Znajdziemy tam zatem informacje dotyczące baz danych, wraz ze szczegółowym opisem modeli danych i reguł zachowania integralności. Repozytorium to składuje również pełną informację o projekcie – w tym interfejsy, pakiety, foldery, moduły wiedzy i niezbędne zmienne. Po uruchomieniu projektu, do repozytorium zapisywane są też informacje operacyjne – takie jak scenariusze działań i logi z ich realizacji.

Innym sposobem obserwacji tego, co dzieje się w zadaniach integracyjnych jest dostępny za pośrednictwem przeglądarki webowej Metadata Nawigator i Lightweight Designer. Konsole te przeznaczone są zarówno dla deweloperów i administratorów, jak i biznesowych użytkowników systemu. Począwszy od ogólnej mapy przepływu danych, obejrzeć tu możemy strukturę i zawartość danych źródłowych, a także mapowanie danych i scenariusze działań integracyjnych. Poszczególne zadania mogą być również na bieżąco monitorowane lub nawet „ręcznie” uruchomione z konsoli.

Oracle Data Integrator w zastosowaniach

Tytułem podsumowania, na kolejnych kilku rysunkach prześledzimy sposób w jaki Oracle Data Integrator może być umieszczany i wykorzystywany w różnych środowiskach biznesowych. Pierwszym, najbardziej klasycznym przykładem jest batchowe ładowanie danych do hurtowni. Dla większego skomplikowania sytuacji założyć możemy, że środowisko zawiera wiele równoważnych źródeł danych, które po transformacji integrowane są do wspólnej bazy hurtownianej za pomocą transferów inkrementalnych. Integralność i spójność danych sprawdzana jest mechanizmami zaimplementowanymi w bazie hurtownianej, gdzie przygotowywane są również agregaty i eksporty danych przekazywanych następnie do on line’owych procesów analitycznych (kostek OLAP) oraz aplikacji analitycznych i raportujących.

Inną konfiguracją infrastruktury informatycznej wykorzystującą Oracle Data Integrator, jest umieszczenie go w środowisku zorientowanym obiektowo. W takim przypadku Oracle Data Integrator jest dostawcą serwisów zapewniających dostęp do danych oraz ich transformację i zachowanie integralności. Oczywiście do realizacji zadań związanych z transformacją danych wykorzystywane mogą być również serwisy dostarczane przez inne elementy systemu.

Zupełnie innym pomysłem na wykorzystanie tego pakietu jest wkomponowanie go w heterogeniczne środowisko w charakterze głównego zarządcy danych. Dzięki łatwej w użyciu, wyposażonej w graficzne udogodnienia konsoli Common Format Designer, możliwe jest bowiem zdefiniowanie w repozytoriach Oracle Data Integratora głównego kanonicznego formatu danych. Z jego pomocą Integrator może przejąć rolę huba lub zarządcy data flow, umożliwiającego i kontrolującego wymianę danych pomiędzy różnorodnymi aplikacjami. W takiej konfiguracji swoje miejsce znajdą również Oracle Customer Data Hub oraz Oracle Product Information Management, które zadbają o synchronizację wszystkich działań w systemie.

Jak widać, pomysłów na zastosowanie tego pakietu jest wiele. Życzę więc udanych wdrożeń…