EDW #5: Źródło
Ten wpis należy do serii wpisów poświęconych architekturze hurtowni danych.
Tydzień temu wymieniłem siedem logicznych warstw DW. Dziś omówimy sobie warstwę numer 1, czyli systemy źródłowe.
Jest to jedna z dwóch warstw, nad którą nie mamy żadnej kontroli (z nielicznymi wyjątkami, kiedy system źródłowy jest w naszym posiadaniu - w takim sensie, że we własnym zakresie możemy wprowadzać zmiany w jego konstrukcji).
W przypadku każdego systemu źródłowego X na ogół musimy odpowiedzieć sobie na kilka pytań, na przykład:
-
Czy istnieje technologia umożliwiająca nam zautomatyzowany odczyt danych z systemu źródłowego X? Jeżeli tak, czy umiemy się nią posługiwać? Czy wymaga ona zakupienia jakichś licencji? A może istnieje wiele różnych technologii? Która jest najszybsza? Najtańsza? Najprostsza? Najbardziej bezawaryjna?
-
Czy dane, które będziemy czytać, dadzą się "stabelaryzować"? Innymi słowy, czy system źródłowy oferuje dane w postaci wierszy i kolumn? Jeżeli nie, czy możemy / potrafimy je do takiej postaci doprowadzić?
-
Czy potrzebujemy wszystkich danych, czy tylko ich części? Jeżeli tylko części, to której części? Ile to zajmie miejsca?
-
Jak często dane w systemie X ulegają zmianie? Jak często będziemy potrzebowali je czytać? Jak często możemy czytać dane z systemu X bez zakłócania jego normalnej pracy? W jak dużych porcjach możemy je czytać?
-
A co z bezpieczeństwem danych? Czy potrzebujemy osobnego, dedykowanego loginu i hasła? Czy dane są newralgiczne (typu dane osobowe albo płatności / pensje itd.)?
-
Czy istnieje wersja testowa systemu X? Jak aktualne dane są w niej przechowywane? Czy możemy jej używać do naszych testów?
Kluczowym elementem są tutaj na ogół: rozmiar danych oraz ich bezpieczeństwo. Czasem zdarza się, że zanim dostaniemy dedykowany login do systemu X, spędzamy tydzień albo miesiąc na e-mailowym ping-pongu, albo że musimy przejść dodatkowe szkolenie z bezpieczeństwa danych. Co do rozmiaru danych zaś - no cóż, będziemy je przechowywać po naszej stronie, co wymaga miejsca, które kosztuje. Trzeba więc sensownie (ale też pesymistycznie, na wszelki wypadek) oszacować wymaganą po naszej stronie ilość miejsca potrzebnego na dane z jednego tygodnia, miesiąca, roku i tak dalej.
Wszystkie szczegóły procesu ładowania danych, które mogą mieć wpływ na pracę systemu źródłowego, muszą być omówione z właścicielem tego systemu. Wszystkie procesy muszą być bezdyskusyjnie przetestowane w warunkach różnego obciążenia transakcjami. Hurtownia hurtownią, ale nie chcemy przecież położyć na łopatki jakiegoś głównego systemu transakcyjnego naszego płacodawcy.
W DW będziemy potrzebować osobnej tabeli pomocniczej zwanej SOURCE_SYSTEM, która będzie przechowywać listę wszystkich systemów źródłowych, z których ładujemy dane do DW. Każdy z systemów będzie tu reprezentowany przez jeden rekord z następującymi kolumnami:
-
Identyfikator systemu (unikalna liczba, całkowita potęga dwójki)
-
Pełna nazwa systemu
-
Skrót nazwy (3-5 liter oznaczających dany system)
-
Priorytet systemu (unikalna liczba całkowita)
Dlaczego identyfikator systemu ma być całkowitą potęgą dwójki okaże się w okolicach 4-5 warstwy, na razie więc temat pominę.
Ogólnie rzecz biorąc, lista systemów źródłowych będzie bardzo przydatna w sytuacji, kiedy będziemy musieli wyśledzić konkretne źródło, z którego pochodzi dana wartość w DW.
Dla wszystkich danych, które będziemy musieli ładować z systemu X do DW musimy przygotować gotowe narzędzie do ich odczytywania. Najczęściej będzie to albo sterownik ODBC / JDBC, albo plik TXT / CSV / XLS. W bardziej egzotycznych przypadkach bywa tak, że "coś" czyta dane z systemu X do pliku CSV, a my to dopiero potem zaciągamy do DW - i tak dalej.
Podsumowując: systemy źródłowe to na ogół "łatwy" kawałek hurtowni, o ile tylko nie musimy zmagać się z jakimiś egzotycznymi technologiami odczytywania danych ani kwestiami bezpieczeństwa. Musimy też utrzymywać dobre stosunki z właścicielami systemów źródłowych, bo to dzięki nim mamy dane, z których zbudujemy naszą hurtownię.
Komentarze