Skonsolidowane problemy
-
- Tomasz Kopacz,
- 28.11.2005
Jaki cel, taka konsolidacja
Wykonując proces konsolidacji, warto najpierw zadać sobie pytanie o jej cel. To on bowiem określi metodę - budowanie hurtowni danych nie w każdym przypadku jest zasadne. Z biznesowego punktu widzenia, jeśli celem konsolidacji danych jest raportowanie, aktualność danych ma większe znaczenie, zaś ich szczegółowość - mniejsze. Budowane raportów na kopii danych "z wczoraj" nie przyniesie wielkiego pożytku. W innych zastosowaniach, np. do (większości) celów analitycznych, aktualność jest drugorzędna - tym bardziej im dłuższy okres obejmuje. Większość narzędzi czysto raportujących, takich jak Crystal Reports czy Microsoft Reporting Services itp., może bez większych problemów sięgać bezpośrednio do baz operacyjnych. Tu też nie ma jednak jednego scenariusza, bowiem współczesne rozwiązania OLAP nie są już tak bardzo odległe od systemów raportowych (a przy tym wcale nie tak obciążające). Przy odpowiednim zaprojektowaniu transakcji i buforów systemy OLAP mogą spełniać podobną rolę jak systemy raportujące. To, które podejście wybrać, jest kwestią decyzji w konkretnej sytuacji.
W przypadku rozwiązań SAS Institute i BEA Systems, komponent odpowiadający za metadane jest równocześnie pewnego rodzaju serwerem buforowym. Zapewnia to odpowiednią wydajność kolejnej warstwy używającej metadanych, ale równocześnie generuje nową klasę problemów związanych z synchronizacją. Niestety, w niewielu przypadkach można zażądać, by serwer był informowany o tym, że zawartość danych w źródle uległa zmianie, ale zbytnia automatyzacja nie jest tu stosowana. Zwykle sprawdzenie, czy w źródle zaszły zmiany, wykonywane jest co określony czas. Pewnym rozwiązaniem będą mechanizmy oparte na zdarzeniach, jak SqlDependency w SQL Server 2005. Dzięki nim aplikacja może subskrybować otrzymywanie informacji o zdarzeniu określonego typu lub o tym, że odpowiednio duża porcja danych uległa zmianie.
Pomimo wszystkich udoskonaleń, problem opóźnienia pomiędzy zmianą w systemie transakcyjnym a "widocznością" tej zmiany w kolejnej warstwie nadal istnieje. W świecie Javy powstało kilka pomysłów związanych ze "standardową" implementacją metadanych - ale aby to w pełni zadziałało, taki standard musiałby zyskać aprobatę wśród producentów baz danych. Na razie trzeba chyba czekać na rozwiązanie, w którym metadane będą w naturalny sposób dostępne zarówno dla procesów ETL, warstwy biznesowej oraz dla interfejsu użytkownika.
1. Masowy transport danych. Jeśli mowa o konsolidacji, zwykle chodzi o procesy masowe, a więc wymagające wysokiej wydajności. Poszczególni producenci w różny sposób podchodzą do zagadnienia masowego ładowania danych do bazy lub ich eksportu. Pewne jest jedno: zastosowanie standardowych mechanizmów transakcyjnych nie wchodzi w grę, z drugiej jednak strony kopiowanie danych bez jakiegokolwiek rejestrowania operacji nie ma w ogóle sensu.
2. Replikacja. Wszystkie środowiska bazodanowe posiadają mechanizmy do replikowania danych, które jednak istotnie różnią się możliwościami. Większość z nich działa jedynie wtedy, gdy po drugiej stronie funkcjonuje taka sama baza danych (z niewielką tolerancją dla wersji). Poza tym replikacja działa zwykle jedynie w jedną stronę, a więc baza docelowa w normalnych warunkach jedynie przyjmuje dane. Bywają jednak szczytne wyjątki. Problemem związanym z replikacją jest tryb replikacji: synchroniczny bądź nie, online bądź offline. Oddzielna klasa problemów to replikacja między aplikacjami, choć w dobie SOA i Web Services problem ten będzie zanikać.
3. Przetwarzanie ETL. ETL, czyli ekstrakcja, transformacja i ładowanie danych związane z przenoszeniem danych z systemów transakcyjnych do hurtowni i systemów OLAP to samodzielna dziedzina wiedzy i oddzielna klasa problemów z konsolidacją. Wbrew pozorom nie jest to ta sama klasa zagadnień, co przy masowym transporcie danych czy replikacji. Podstawowym wyróżnikiem ETL jest wykonywanie operacji na danych: przekształcenia formatu, zmiana układu, agregacja danych szczegółowych, wyliczanie wartości średnich i innych algorytmów.
4. Czyszczenie danych. We wszystkich scenariuszach konsolidacji zagadnieniem istotnym jest jakość danych, rozumiana jako ich spójność, unikalność, poprawność formatu itp. Biorąc pod uwagę fakt, że wiele danych wciąż jest i jeszcze długo będzie wprowadzane przez ludzi, problem szybko nie zniknie. Sprawa jest na tyle poważna, że producenci oferują dedykowane narzędzia pozwalające zaprowadzić porządek w bazach poprzez ujednolicanie danych określonego typu, np. teleadresowe, nazwiska itp. Stosowane są metody słownikowe, rozmyte grupowanie, metody statystyczne i wiele innych. Mimo to skutek nigdy nie jest w 100% doskonały.
5. Zarządzanie metadanymi. Zarządzanie metadanymi to problem każdego projektu konsolidacji danych. Konsolidacja zakłada ruch danych ze źródła do celu, tyle że i źródeł, i celów jest zwykle wiele i nie są one statyczne. Metadane służą temu, by projekt rozwiązania konsolidacyjnego (czy to ETL, czy też replikacji) mógł pozostać spójny pomimo zmian nazw źródeł danych, ich lokalizacji, zmian definicji danych itp. Wygoda projektanta jest jednak okupiona problemem zarządzania definicjami danych w różnych systemach i ich synchronizacją.
