EDW #5: Źródło

https://xpil.eu/Cor 📋

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:

1. 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?
2. 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ć?
3. Czy potrzebujemy wszystkich danych, czy tylko ich części? Jeżeli tylko części, to której części? Ile to zajmie miejsca?
4. 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ć?
5. 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.)?
6. 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ę.

https://xpil.eu/Cor 📋