EDW #4: Siedem warstw

https://xpil.eu/PTY 📋

Ten wpis należy do serii wpisów poświęconych architekturze hurtowni danych.

Zgodnie z obietnicą, dziś zakaszemy rękawy i w końcu trochę sobie pobrudzimy ręce konkretami.

Hurtownia danych, którą opisuję w niniejszej serii, składa się z siedmiu warstw logicznych. Każda z nich pełni określoną rolę. W gotowym rozwiązaniu dane płyną od warstwy #1 do warstwy #7. Tak naprawdę celem tej serii jest pokazanie Czytelnikowi owych siedmiu warstw, logiki przepływu danych między nimi, sposobu ich implementowania, a także płynących z takiego podejścia zalet (oraz nielicznych wad).

Przypuszczam, że większość ludzi czytających ten wpis po raz pierwszy właśnie drapie się (wirtualnie bądź rzeczywiście) palcem w głowę i myśli sobie: "hy? siedem warstw? a może by tak, urwał, od razu siedemnaście, albo pińcet, hy? pierdzielę, nie czytam dalej, bessęsó..."

Jeżeli takie (lub podobne) myśli właśnie przemknęły Ci, Czytelniku, przez głowę, to dobrze. Człowiek podświadomie dąży do upraszczania sobie życia, a siedem warstw nie brzmi na początek zbyt zachęcająco. Zapewniam jednak, nie taki diabeł straszny, jak go malują. Zanim uciekniesz w popłochu, żeby oglądać śmieszne koty, zechciej pozostać tu jeszcze przez chwilę.

Pamięta ktoś jeszcze skecz "Dziesięć przykazań" Carlina? Facet redukuje tam - na oczach rozbawionej do łez publiczności - dziesięć przykazań do zaledwie dwóch, po czym dodaje jedno od siebie.

Podobnie sprawa ma się tutaj, tylko bez rozwścieczania moherów.

Spośród bowiem wspomnianych siedmiu warstw dwie skrajne są poza naszą kontrolą.

Zostaje pięć.

Z tych pięciu dwie są opcjonalne.

Zostają trzy.

Z tych trzech jedna jest dla użytkowników tępych lub leniwych - jeżeli więc większość naszych użytkowników ma trochę oleju w głowie, możemy tę jedną potraktować opcjonalnie (lub po macoszemu) bez utraty jakości ani funkcjonalności całego rozwiązania.

A więc z groźnych siedmiu warstw zeszliśmy do, pi x oko, dwóch lub trzech. A to już nie brzmi tak źle, prawda?

No dobrze. Obiecałem konkrety, przejdźmy więc do konkretów.

Nasz projekt hurtowni danych będzie oparty na następujących warstwach logicznych:

1. Systemy źródłowe
2. Stage
3. Landing
4. Cross Reference
5. EDW
6. Data Marts
7. Konsumenci

Dziś omówię pokrótce każdą z wyżej wymienionych warstw, natomiast w kolejnych odcinkach serii przyjrzymy się każdej warstwie z bliska. Zobaczymy również, w jaki sposób rozbudować DW o dodatkowe rozwiązania (na przykład moduł DQ - Data Quality - albo MDH - Master Data Hub) bez ryzyka totalnej rozpierduchy.

Systemy źródłowe to nic innego jak, khem, jak by to ująć... no, systemy źródłowe. W każdej odpowiednio skomplikowanej firmie prędzej czy później dochodzi do sytuacji, w której mamy trochę / dużo / mnóstwo (zbędne skreślić) systemów komputerowych realizujących konkretne cele, które to systemy "nie wiedzą" o sobie nawzajem (albo w ogóle, albo prawie w ogóle). Czasem mówimy tu o systemach zewnętrznych dostawców danych (na przykład kursy walut czy jakieś dane statystyczne). Czasem będzie to folder z zylionem plików CSV lub XLS. Czasem jakaś baza danych. Czasem webservice. I tak dalej - czym chata bogata. Ta warstwa pozostaje (na ogół - bo są wyjątki) poza naszą kontrolą, jest jednak kluczowa dla działania DW, ponieważ dostarcza danych do pracy hurtowni.

Stage to pierwsza warstwa DW, nad którą mamy pełną kontrolę. Tutaj przechowujemy dane spływające z systemów źródłowych. Dane w warstwie stage są (z pewnymi wyjątkami) dokładną kopią danych źródłowych. Mamy je jednak "po naszej stronie", a więc jeżeli jakiś system źródłowy ulegnie awarii lub na przykład jest akurat przeciążony i nie można z niego czytać, mamy "swoją" kopię danych z tego systemu i możemy jej używać kiedy tylko nam się spodoba oraz w dowolny sposób.

Landing i Cross Reference - te dwie warstwy służą do dopasowywania danych z różnych systemów. Jeżeli, dajmy na to, dane o klientach spływają do DW z systemu fakturującego oraz z systemu CRM, warstwy Landing i Cross Reference mają za zadanie rozpoznanie, które rekordy z obydwu systemów należą do tego samego klienta, oraz odpowiednie przygotowanie tych rekordów do dalszej obróbki.

EDW to najcenniejsza część DW. Tutaj przechowujemy znormalizowane, dopasowane dane, które w zasadzie już nadają się do wykorzystania przez końcowego użytkownika.

Data Marts to obszar, w którym przechowujemy dane wyciągnięte z EDW oraz (na ogół) zdenormalizowane w taki sposób, żeby maksymalnie ułatwić korzystanie z nich przeciętnemu zjadaczowi bitów. Dane w warstwie Data Marts podzielone są na fakty i wymiary. W najprostszym wariancie może to być zbiór widoków zbudowanych na bazie EDW. Częściej jednak będą to zmaterializowane dane, umożliwiające budowanie na ich bazie wydajnych rozwiązań raportujących.

Konsumenci to warstwa poza naszą kontrolą - reprezentuje ona końcowych użytkowników DW, którzy będą korzystali z danych. Mogą oni żądać różnych kanałów dostępu do danych: ekstrakty csv, xml, xls, mdb, źródła zgodne z odbc, webservice, silniki raportujące typu SSRS, Cognos czy Crystal Reports i tak dalej. Konsumenci świadomi mogą używać danych bezpośrednio z EDW. Konsumenci leniwi skłonią się raczej ku Data Marts.

W zależności od tego, jaki mamy budżet, a także (co ważniejsze) jak bardzo planujemy rozbudować DW i jakich ilości danych się docelowo spodziewamy, warstwy 2-6 można zbudować albo na różnych serwerach, dzięki czemu przetwarzanie danych w każdej warstwie będzie przebiegało bez zakłócania warstw sąsiednich, albo na tym samym serwerze, ale w różnych bazach danych (dzięki temu co prawda będziemy używać tego samego CPU, ale przynajmniej możemy porozkładać bazy na różnych dyskach fizycznych, co powinno przyspieszyć - zrównoleglić - operacje I/O), albo od biedy trzymać wszystko w jednej bazie, w różnych schemas, dzięki czemu możemy wystartować ze względnie niedużym budżetem.

https://xpil.eu/PTY 📋