MSCW jako proces normalizacji

Procesem normalizacji nazywa się proces, który przekształca dane źródłowe w ustandaryzowany format, nazwy oraz wartości bazując na pewnych regułach. Dane wyjściowe uzyskujemy z danych wejściowych oraz wykonanych regułach na tych danych. W tym przypadku będzie to normalizacja MSCW:

Reguły MSCW są regułami, które zapewniają istotne informacje (lub ich brak) w danych wyjściowych. Zapewne, nie świadomie korzystasz z tych reguł, gdyż są bardzo popularne, ale bardzo rzadko nazywa się je. Są bardzo ważne w bezpieczeństwie przesyłanych danych.

Znaczenie skrótu MSCW wyjaśnia wszystko:
Must - pole musi być w danych wejściowych oraz musi być sprawdzone i zwalidowane
Should - pole musi być w danych wejściowych, a jak nie ma wartości to zostanie zastąpione przez inną (być może domyślną) wartością
Could - jeżeli pole będzie w danych wejściowych, to te pole będzie procesowanie dalej
Won't - jeżeli pole będzie w danych wejściowych, to te pole będzie zablokowane

Przykładem normalizacji MSCW jest proces rejestracji użytkownika na stronie internetowej. Po rejestracji, dostępne informację dla innych użytkowników strony są ograniczone do podstawowych pól:

Normalizacja MSCW występuje również w dużych projektach ETL. Zawsze powinniśmy wiedzieć jakie dane powinny być procesowane, a jakie powinny być ukryte.

Monitorowanie procesu ETL

Jak przy każdym projekcie, wcześniej czy później zespół dochodzi do wniosku, że potrzebne jest narzędzie/metody/procesy do monitorowania działania projektu. Chciałbym Ci przedstawić przykład monitorowania procesu ETL.


Proces ETL może być bardzo skomplikowany i niektóre zadania mogą nie działać poprawie. W tym celu dokonuje się logowania błędów. Logowanie pozwala na szybszą diagnozę, aby wywnioskować, co mogło wywołać błąd. Im więcej loguje się zdarzeń występujących w procesie ETL tym diagnoza jest dokładniejsza, ale każde logowanie wymaga dodatkowej przestrzeni pamięci. Same logowanie błędów nie wystarcza.

Oprócz logowania zdarzeń wymaga się narzędzia, które mogłoby sprawdzać różne części całego procesu ETL. Sprawdzenie połączenia do różnych zasobów jest dokonywana za pomocą mechanizmu pulsacji (heartbeat), które co dany interwał czasowy sprawdza zasób. Jeżeli dany zasób nie jest dostępny to wywoływany jest alarm (alert). Niektóre zasoby procesu ETL nie muszą być sprawdzane za każdym razem, a wystarcza, że zostaną sprawdzone raz przy uruchomieniu monitora (single alert). Monitor może sprawdzać czy istnieje połączenie do danych źródłowych. Na przykład, monitor sprawdza czy jest połączenie z bazą danych. Czasami samo sprawdzenie schematu bazy danych nie wystarcza i należy sprawdzić format zapisanych danych. W projektach rozproszonej odpowiedzialności, dane w bazie danych są zmieniane i zmiana formatu może spowodować nie wyekstraktowanie wszystkich danych lub co jest gorsze – ekstraktownie błędnych danych. Takie sprawdzenie ostrzeże nas przed uruchomieniem proces ETL. Dodatkowo możemy sprawdzić czy mamy dostęp do wymaganych plików oraz czy jest możliwość dostępu do sieci wewnętrznej. Sprawdzenie dostępu do sieci wewnętrznej nie tylko pozwoli nam na dostęp do danych referencyjnych, ale mamy możliwość sprawdzenia czy nie mamy problemów z połączeniem sieciowym. Czasami baza danych lub pliki są dostępne z jednego komputera (z danej podsieci), ale ten zasób może być niedostępny dla servera (z innej podsieci). Oprócz monitorowania danych wejściowych to dane wyjściowe (targets) również są monitorowane. Sprawdza się czy jest możliwość połączenia się do hurtowni danych (lub innego docelowego miejsca przechowywania danych).

Można monitorować komunikację w procesie ETL. Poszczególne komponenty ETL mogą komunikować się ze sobą za pomocą kolejki komunikatów (message queues) (lub przez Interprocess Communications). Każda kolejka jest wypełniana (produkcja) informacjami z jednego komponenty, a następny komponent wykorzystuje (konsumpcja) te informacje do dalszego działania. Jeżeli kolejka nie jest konsumowana to wiadomo, że następny komponent nie został wystartowany. Oprócz konsumpcji komunikatów sprawdzana jest ilość tych komunikatów. Jeżeli ilość jest za mała lub za duża to jeden z komponentów musiał wygenerować błąd lub istnieją duplikaty informacji.


Poniżej jest zawarty rysunek z przykładowym schematem monitorowania procesu ETL:

Data Marty - uszczuplona hurtownia danych

Wcześniej pisałem o procesie ETL i w nim wspominałem o Data Martach jako zbiorze załadowanych danych. Data Marty są nazywane tematycznymi hurtownie danych. Są tworzone w celu zapewnienia wsparcia procesu podejmowania decyzji osobom odpowiedzialnym za konkretny obszar biznesowy. W przypadkach, gdy tylko część danych jest poddawana analizie, warto rozważyć użycie data martów. Data Mart jest generowany na bazie hurtowni danych i zawiera zagregowane dane zorientowane na jeden wybrany temat, które są często wyświetlane oraz łatwo i szybko dostępne dla użytkowników.

Hurtownia danych operuje na poziomie wszystkich dostępnych danych, przy czym tematyczna hurtownia danych jest używana z reguły przez jeden obszar danych w niej zawartych dotyczących jednego konkretnego tematu biznesowego. Dla banków może to być obszar produktów kredytowych lub obszar transakcji kontraktów krótkoterminowych

Typową i najczęściej spotykaną architektura w korporacjach jest jedna globalna hurtowna danych i bezpośrednio zależne i czerpiących z niej dane Data Marty.

Powyżej przedstawiony jest sposób działania Data Martów. Dostęp do nich mają tylko wyznaczone osoby (lub grupy ludzi). Dział raportujący ma dostęp tylko do danych potrzebnych do tworzenia i przeglądania raportów. Dział analiz ma dostęp do Data Martów do analizy oraz raportów. Natomiast grupa administracyjna ma dostęp do wszystkich obszarów danych, gdyż zarządzają tymi danymi.

Kluczowym problemem jest utrzymanie spójności z hurtownią danych. Najważniejsze te kwestie to definicja danych, sposób aktualizacji oraz zarządzanie danymi. Sposobem na ominięcie części problemów jest tworzenie data martu niezależnego od hurtowni danych. Zdarza się to najczęściej, gdy do utworzenia data martu wymagane jest dodatkowe źródło danych spoza hurtowni. Wtedy tematyczne hurtownie danych są zasilane i zarządzane przez procesy ETL (Extract-Translate-Load). Należy jednak pamiętać o tym, że tego typu architektura jest narażone na ryzyko niespójności w rozumowaniu danych.

Najczęstsze powody tworzenia data martów to:
- większa denormalizacja
- dane z zagregowanymi danymi
- dane ze specyficznego okresu czasowego istnienia tych danych ( np. wartość akcji z poprzedniego roku)
- dane dostępne tylko dla specyficznej grupy (dane tylko dla analityków, testerów lub administratorów)

Co to jest ETL ?

Jak zaczynałem swoją pracę przy bardzo dużym projekcie ETL, to na początku nie wiedziałem co to jest i do tej pory nie ma zbyt dużo materiałów na ten temat. Przedstawię Ci krótki wstęp do ETL.

Skrót ETL oznacza ekstrakcję (extract), transformację (transform) i ładowanie (load). Jest to metoda procesowania danych. ETL składa się z 3 etapów:
1) ekstrakcja danych ze źródła danych - proces ten determinuje bazowe źródła dla hurtowni danych.
2) transformacja danych - etap ten ma za zadanie standaryzować dane, filtrację oraz sprawdzanie reguł biznesowych.
3) ładowanie danych do docelowego zbioru danych - etap zapisu wygenerowanych danych.

Na rysunku przedstawiony jest ogólny schemat działania procesu ETL. Do danych wejściowych (source) należą aplikacje (m.in. bazy danych), dodatkowe pliki oraz inne pomocne dane (m.in. metadane). Proces ETL przetwarza te dane i zapisuje je do wyznaczonego zbioru danych (target). Docelowy zbiór danych jest określony przez projektanta i może to być hurtowania danych, data mart lub zbiór plików zapisanych na serwerze. W praktyce 80% czasu spędzonego na rozwijaniu systemu BI jest poświęcone na rozwijanie procesu ETL. Jest to najbardziej czasochłonne zadanie przy budowaniu hurtowni danych i jednocześnie wymaga najwięcej wiedzy i doświadczenia. Bardzo często proces ETL nazywany jest procesem integracji danych, natomiast narzędzia ETL nazywane są platformą integracyjną.

Pierwsza częścią - ekstrakcja danych ze źródła danych - jest to najbardziej wymagający etap całego ETL. Większość hurtowni danych integruje dane z różnych źródeł danych. Każde źródło danych może się różnić organizacją danych czy sposobem dostępu. Najczęściej spotykanym źródłem danych są relacyjne bazy danych oraz pliki w formacie CSV. Celem ekstrakcji danych jest przekonwertowanie danych do ujednoliconego formatu, który jest przystosowany dla procesu transformacji.

Etap transformacji jest częścią opisującą przepływ danych, który zawiera zaaplikowane reguły biznesowe oraz szczegółowy opis kalkulacji i mapowania między danymi. Niektóre dane wymagają bardzo mało, a nawet brak modyfikacji danych. W większości przypadkach etap ten składa się pezynajmniej z jednego z poniższych zadań:
- wyselekcjonowanie tylko niektórych kolumn danych z tabeli
- transformacja sposobu zapisu danych. Jeżeli dana jest zapisana w postaci binarnej (1-0) to można zapisać słownie (Tak – Nie)
- transformacja formatu zapisu danych. Część dat jest zapisana w formacie skoordynowanego czasu uniwersalnego (UTC) lub czasu lokalnego
- wyliczenie nowej wartości, która jest zależna od wartości innych zmiennych
- sortowanie według danego kryterium
- łączenie danych z innymi danymi z innych źródeł - wzbogacanie danych
- rozdzielenie kolumny na kilka kolumn
- usuwanie zduplikowanych danych
- agregacja danych. Można wprowadzić data rollup ( wiersz podsumowujący dane)
- tworzenie unikatowego klucza (surrogate key) dla wszystkich elementów
- dokonywanie transpozycji oraz tworzenie tabeli przestawnej. Jest to proces, w którym kolumny zamieniane są na wiersze.

Faza ładowania danych odnosi się do zapisu do specjalnego obiektu docelowego (najczęściej jest to hurtowna danych). Obiekt docelowy jest zależny od wymagań danego projektu. Najczęściej istniejące dane w hurtowni danych są nadpisywane przez nowo wygenerowane. Inne hurtownie danych są czyszczone i na nowo załadowane, ale takie rozwiązanie niesie ze sobą problem „pustych danych”, gdyby wystąpił problem w etapie ładowania danych.

Architekt jest jak ogrodnik

Bardzo mi się podoba metafora "architekt jest jak ogrodnik". Ogrodnik powinien pielęgnować ogród. Architekt powinien pielęgnować architekturę.

Problem może pojawić się, kiedy mamy architekta, który mówi, że wszystko jest ok, nie trzeba modernizować starego systemu, manualne czynności nie muszą być zautomatyzowane, projekt działa wystarczająco szybko, nie jest potrzebna reużywalność i tak dalej... To tak samo by było, gdyby ogrodnik nie chciałby wyciąć drzewa, które zagraża życiu ludzkiemu, przesadzić suche i brzydkie kwiatki czy podciąć zarośnięty żywopłot i nie dba o dróżki prowadzące przez ogród.

Z drugiej strony mamy architekta, który od nowa chce stworzyć system, zastosuje technologie jakie są teraz modne, a stary system z przyjemnością by usunął. Tak samo jest z ogrodnikiem, który chce wyciąć wszystko i od nowa posadzić nowe roślinki (oczywiście ogrodnik ten nie zna do końca wymagań wszystkich rośliny). Można zrobić fantastyczne ogrody tak jak labirynt znajdujący się w Kurozwękach czy ogród Herrenhäuser w Hannoverze, ale koszt utrzymania takiego ogrodu jest bardzo duży.


Pamiętaj, "architekt jest jak ogrodnik, pielęgnuje architekturę systemu".

Astronauci Architektury

Każda osoba pracowała albo słyszała o architekcie, który stracił kontakt z ziemią.
Taki architekt jest nazywany "astronautem".


Jest im bardzo ciężko zacząć pisać produktywny kod, ponieważ nie mogą przestać rozmyślać o architekturze. Są jak astronauci w przestrzeni kosmicznej. Wcześniej bujali w obłokach, ale teraz to są na takiej wysokości, że nie ma tlenu i "ważne" sprawy są oddalone od nich o setki kilometrów. Muszą założyć kask. Nie widzą już szczegółów znajdujących się na ziemi. Jeżeli zdjęli by kask to prawdopodobnie mogli by się udusić. Na ogół pracują dla wielkich korporacji, które mogą sobie pozwolić na nieproduktywne rozmyślanie nad architekturą.


Joel Spolski już wcześniej pisał o takich architektach. Omówił ten problem na przykładzie mody na architekturę "Peer-to-Peer". Ludzie byli zafascynowani Napsterem, torrentami i eMule. Wszystko te projekty działają na p2p. Architekci zaczęli rozmyślać jak wbudować p2p w swoich projektach. Były tworzone konferencje o p2p. I nagle ... p2p umarło.


Astronauta Architektury powie ci: "czy możesz sobie wyobrazić aplikację, która tak samo jak torrenty będzie przesyłała ważne dane". Potem powie coś takiego jak: "wyobraź to sobie, już nigdy nie będziesz musiał pisać połączenia klient-server" Ten przykład nie jest tylko dla p2p. Równie dobrze może odnosić się do XMLa, PL/SQL'a, NoSQL czy do innego dowolnego frameworka lub technologię, na którą jest teraz moda.