Skonsolidowane problemy

Pod słowem konsolidacja danych kryje się wiele różnych pojęć i wiele związanych z nimi problemów.

Pod słowem konsolidacja danych kryje się wiele różnych pojęć i wiele związanych z nimi problemów.

Choć dostawcy od dawna dążą do budowy rozwiązań zintegrowanych, codzienna praktyka wdrożeniowa przeczy ich wizji. Bowiem nawet jeśli firma kupuje duży system, zwykle nie instaluje wszystkich jego elementów, lecz jedynie te, które sensownie pasują do pewnej wypadkowej wywodzącej się po trosze z modelu biznesowego, nieco z preferowanej architektury oraz z bieżących priorytetów i planów na przyszłość.

W każdym ważnym dla firmy obszarze, czy to w finansach, czy współpracy z klientami, czy logistyce, wdrażany jest zwykle kawałek systemu innego producenta. Szkopuł w tym, że - w większości przypadków - każdy z dostawców widzi swój system w centrum środowiska klienta. To z kolei pociąga za sobą chęć koncentracji w nim właśnie ostatecznej wersji prawdy o tym, jakie zdarzenia gospodarcze rzeczywiście zaszły.

Ponieważ wszyscy prezentują podobną postawę, owych ostatecznych wersji prawdy (unikalnych identyfikatorów klientów, kodów towarów, kategorii usług itp.) bywa w firmach wiele - oczywiście z opłakanymi skutkami dla spójności, a więc także użyteczności informacji. Firmy, którym udało się takiego scenariusza uniknąć, mimo wszystko i tak stają się jego ofiarami - przy okazji najbliższej fuzji. Drugim poważnym problemem, mieszczącym w sobie kilka pomniejszych, jest integracja danych na potrzeby analizy, czy to w formie dużej hurtowni danych, czy zestawie hurtowni tematycznych (data marts).

Zarządzanie ruchem

Zagadnienie konsolidacji danych można rozdzielić na kilka zagadnień szczegółowych. Pierwszym z nich jest transport informacji pomiędzy systemami - w ujęciu technicznym. W przypadku relacyjnych baz danych jest to "względnie" proste - każdy motor ma swój specyficzny sposób "szybkiego" zrzucenia danych i wczytania dużej porcji informacji (tzw. bulk load) z pominięciem kosztownych wydajnościowo operacj weryfikacyjnych, takich jak sprawdzanie więzów integralności.

Jeżeli dodatkowo następuje transport pośrednich "płaskich" plików, to okazuje się, że trzeba mieć na podorędziu sprawdzony sposób "wycofywania" operacji, gdy np. transport przyrostowy się nie udał. W praktyce okazuje się, że tylko w niektórych scenariuszach można "zacząć od początku". Z drugiej strony, w przypadku dużych hurtowni zasilanie transakcyjne (w odróżnieniu od masowego) jest skrajnie nieefektywne i z tego powodu prawie nie jest stosowane. Aby uniknąć tych skrajności i ich niedogodności, wystarczy dodać znacznik czasu (określający numer "zasilającej sesji" itp.), by można było w miarę prosto usunąć pozostałości po imporcie zakończonym niepowodzeniem.

Większość hurtowni danych ma strukturę przechowywania informacji podobną do baz relacyjnych. Motory są obecnie na tyle wydajne, że nie ma potrzeby stosować specjalistycznych rozwiązań. Większość serwerów baz danych oferuje mechanizmy do określenia parametrów działania logu transakcyjnego. Za ich pomocą można zażądać od serwera, by rejestrował wszystkie czynności związane z masowym ładowaniem danych. Zdarzają się jednak wyjątki, np. Sybase IQ. Dzięki temu, że struktura hurtowni pozwala przechowywać dane w kompresowanych "pionowo" kolumnach (wiersz w razie potrzeby może być złożony z odpowiednich elementów), można oddzielnie wczytywać informacje do poszczególnych kolumn oraz szybko aktualizować dane w hurtowni.

Zasilanie kostki OLAP nie jest tym samym, co zasilanie hurtowni. W przypadku hurtowni informacje są tylko dopisywane (niemal nigdy nie są kasowane). W przypadku baz OLAP dokonywane są przeliczenia, aby narzędzia analityczne mogły tworzyć raporty oparte na gotowych agregatach. W takiej sytuacji głównym zadaniem serwera aktualizującego dane jest ustalenie, jaka część kostki może ulec zmianie, gdy pojawią się nowe informacje. W większości rozwiązań (a w każdym razie w ważniejszych, m.in. w Microstrategy, Hyperion, Oracle, Microsoft) można z góry wskazać wymiary, które nie ulegają zbyt częstym zmianom, co znacznie ułatwia zarządzanie danymi.

Pojawiają się także rozwiązania, w których zawartość kostki OLAP tak naprawdę nie istnieje - poszczególne wartości są dynamicznie wyliczane. Oczywiście, aby było to użyteczne, na początku powstają pewne struktury pomocnicze. W ten sposób powoli zanika różnica pomiędzy kostkami MOLAP (dane przechowywane w kostce wielowymiarowej i aktualizowane) i ROLAP (dane przechowywane w strukturach relacyjnych hurtowni danych).

Transakcje wysłane w świat

Trochę innym zagadnieniem związanym z konsolidacją danych jest ich replikacja, czyli łączenie informacji pochodzących z różnych systemów, ale rozproszonych geograficznie, które z różnych powodów nie mogą być połączone z centralnym serwerem bazodanowym. Opcje replikacji oferuje chyba każdy producent bazy danych, ale niestety większość z nich ograniczona jest tylko do jednej platformy.

Podstawowa replikacja Oracle wykorzystuje zmaterializowane widoki oraz mechanizm snapshot i działa tylko w jedną stronę. Zdalne tabele są uruchamiane z atrybutem tylko do odczytu. Mechanizm zaawansowany oparty jest na triggerach, zapisujących informacje w dodatkowej dystrybucyjnej bazie danych, która w ramach określonej procedury może być udostępniona aplikacjom klienckim, jeśli baza podstawowa zawiedzie.

Replikacja w Microsoft Server 2000 działa podobnie, z tą różnicą, że oprócz bazy SQL Server 2000 obsługuje także bazy Oracle. Firma stawia na maksymalne uproszczenie konfiguracji replikacji, tak by większość operacji można było wykonać myszą w ramach kreatorów. Mechanizm replikacji Microsoftu zakłada, że istnieje kolumna z typem uniqueidentifier (GUID), który jednoznacznie identyfikuje wiersz. W SQL Server 2000 skonfigurowanie bazy z opcją replikacji powodowało, że nie można było używać normalnych operacji DDL. W SQL Server 2005, którego premiera właśnie się odbyła, to ograniczenie zostało usunięte.

Sybase oferuje bardzo ciekawe rozwiązanie o nazwie Sybase Replication Server. Jeśli system ten zostanie zainstalowany w środowisku serwera bazy danych, log operacji z każdego węzła przechodzi do kolejki, a potem do serwera replikacyjnego, który stara się rozwiązać konflikty i zgodnie z założoną topologią "odtworzyć" operacje w docelowym systemie. Dzięki systemowi agentów dostosowanych do różnych platform to rozwiązanie obsługuje dużo różnych systemów - nie tyko Sybase ASE, ale także Oracle, Microsoft SQL Server, IBM DB2 UDB i IBM Informix. Co ciekawe, Sybase Replication Server obsługuje także replikację "dyskietkową", umożliwiającą przenoszenie danych na nośnikach fizycznych i odtwarzanie ich na serwerze docelowym.

W sytuacji gdy musimy niemal na bieżąco synchronizować zdalne bazy, a rozproszona transakcja (zwłaszcza na słabym łączu) bardzo spowolniłaby cały proces, można ustawić tzw. replikację transakcyjną lub "prawie transakcyjną", która dokonuje się na bieżąco, lecz asynchronicznie, nie blokując transakcji w źródłowym. Oczywiście, replikacja jest z gruntu rozwiązaniem, które zostało stworzone na czarną godzinę - na wypadek, gdy klasyczny system klient-serwer działa offline lub też gdy istnieje ryzyko niedostępności podstawowej bazy danych.

Czasami nie da się tego osiągnąć bez modyfikacji w aplikacji, ale replikacja może dużo ułatwić.

Warto jednak pamiętać, że koncepcja Smart Client czy też szerzej - SOA, powoduje, że replikacja na poziomie bazy danych nie jest absolutnie konieczna. W tych architekturach bowiem luźne powiązania między klientami i serwerami są dane, tak jak abstrakcyjność i wirtualność ich interfejsów, umożliwiająca łatwe zapewnienie wysokiej dostępności usługi bez uciekania się do skomplikowanych zabiegów.

Metadane wciąż niedoskonałe

Współczesne rozwiązania do zarządzania metadanymi są znacznie lepsze niż te, które były dostępne na rynku jeszcze kilka lat temu. Niemniej nie są to w większości rozwiązania doskonałe z punktu widzenia klientów. Rysują się tu dwa podstawowe problemy. Pierwszy to brak wersjonowania metadanych, co przy dużej ich zmienności ma fatalny wpływ na koszty utrzymania repozytorium metadanych i sprawność budowy rozwiązania w ogóle. Drugi to dostępność metadanych nie tylko w ramach jednego przepływu, czy też zestawu przepływów, ale dla wszystkich przepływów definiowanych z wykorzystaniem zbioru metadanych. Poleganie na kopiowaniu definicji między podprojektami tylko częściowo ułatwia pracę - podstawowym problemem w zarządzaniu metadanymi jest bowiem utrzymanie ich spójności w każdym czasie.


TOP 200