Przejdź do:
Z praktycznego punktu widzenia (i w znacznym skrócie) hurtownia danych jest to baza danych, gromadząca dane historyczne oraz dane bieżące z jednego bądź wielu systemów źródłowych, które mają być wykorzystywane do wszelkiego rodzaju analiz oraz raportowania. Najważniejszą wartością, jaką oferują hurtownie danych, jest tzw. jedna wersja prawdy. Co to znaczy? Bardzo częstym problemem występującym w przedsiębiorstwach jest to, że raporty czy też analizy, opisujące dany aspekt biznesu, są tworzone w oparciu o inne systemy źródłowe. Zdarza się nawet, że są one tworzone przez różnych specjalistów według odmiennych algorytmów. Sprawia to rzecz jasna, że analizy i raporty mogą dawać różne wyniki – i jest to przykład doskonale obrazujący złamanie zasady „jednej wersji prawdy”. Hurtownia danych ma za zadanie tworzenie przepływów danych w taki sposób, żeby takich sytuacji uniknąć i zapewnić rzetelne źródło informacji. Dopiero posiadając takie wiarygodne źródło wiedzy o procesach biznesowych, można podejmować właściwe decyzje.
Proces ETL
Niezwykle istotną kwestią, związaną z analityką biznesową, jest integracja danych źródłowych. W przypadku, kiedy przedsiębiorstwo posiada wiele systemów przetwarzajacych dane, może dojść do sytuacji, że dane pomiędzy nimi będą niespójne. Zadaniem hurtowni danych jest integracja danych, przy użyciu odpowiednich narzędzi, wydajnie wspierających takie działania. Niejednokrotnie jest tak, że dane z jednego systemu muszą być dopasowane do danych z drugiego systemu lub wręcz przetransformowane. Dlatego specjaliści Business Intelligence potrzebują oprogramowania umożliwiającego takie działania, w zgodzie z regułami biznesowymi danego przedsiębiorstwa. Oprócz możliwości dopasowania, narzędzia tego typu służą do tworzenia procesów migracji oraz integracji danych z systemów źródłowych do docelowej hurtowni danych – całokształt takich działań nazywamy procesem ETL, czyli ekstrakcji, transformacji oraz ładowania danych.
Z procesem ładowania danych do hurtowni danych nieodłącznie wiąże się pojęcie jakości danych. Jest to powszechny problem, który musi zostać rozwiązany właśnie w procesie ETL. Żeby zilustrować powszechność występowania problemów z jakością danych, wyobraźmy sobie sytuację, w której dane klienta wprowadzane są ręcznie do systemu źródłowego. W takim przypadku ryzyko popełnienia błędu jest bardzo wysokie. Klasycznym przykładem tego typu problemu jest nazwa miejscowości, podawana na przykład w formularzach zamówienia, gdzie niezbędne jest wprowadzenie adresu dostawy. Dane tego typu mogą być wprowadzone na kilka, a nawet kilkadziesiąt różnych sposobów np. Dąbrowa Górnicza może być zapisana bez polskich znaków jako „Dabrowa Gornicza”, z myślnikiem „Dąbrowa-Górnicza” lub np. poprzez połączenie obu sposobów „Dabrowa-Gornicza”. Jak widać, ilość kombinacji jest bardzo wysoka, a kreatywność użytkowników pod tym kątem nie zna granic. W idealnym świecie chcielibyśmy, żeby aplikacja kliencka skutecznie uniemożliwiała wprowadzanie tego typu błędów, w praktyce jest to jednak bardzo trudne, wdrażając systemy analityczne, musimy więc się liczyć z takimi sytuacjami i w wydajny sposób te wyjątki obsłużyć. Dlatego właśnie nowoczesne oprogramowanie ETL, obsługujące hurtownie danych, posiada odpowiednie mechanizmy, pozwalające wychwytywać i eliminować błędy obniżające jakosć danych.
Dane historyczne
Kolejną ważną funkcją hurtowni danych jest przechowywanie danych historycznych. W przypadku wszelkiego rodzaju analiz i raportów istotny jest przecież kontekst czasowy. Niektóre dane muszą więc być historyzowane. Np. w przypadku, gdy analizie poddawana jest sprzedaż poszczególnych przedstawicieli handlowych, ale jeden z nich przeniósł się z jednego województwa do innego. W takiej sytuacji, przy braku odpowiedniego podejścia do danych historycznych, utracimy informacje o poprzednim miejscu działalności przedstawiciela, a jego wyniki mogą przykładowo zostać uwzględnione w jego nowej lokalizacji. Oczywiście nie wszystkie dane muszą być w pełni historyzowane i, zgodnie z dobrymi praktykami tworzenia hurtowni danych, tworzone się różne poziomy historyzacji, zwane wymiarami wolnozmiennymi.
Przykładową architekturę rozwiązań korporacyjnych, opartych na narzędziach Business Intelligence (w tym konkretnym przypadku o oprogramowanie firmy Microsoft) przedstawiono na poniższym diagramie. Celem tej wizualizacji nie jest omówienie każdego z wymienionych elementów, ale zrozumienie złożoności i modularności systemów tego typu. Oczywiście nie wszystkie elementy poniższej architektury muszą być użyte w implementacji.
Schemat systemu Business Intelligence, wykorzystującego hurtownię danych
BI bez hurtowni danych – self-service
W tym momencie można już zadać fundamentalne dla tego artykułu pytanie: czy możliwa jest implementacja systemu Business Intelligence bez hurtowni danych? Jeśli znamy rynek i dostępne na nim narzędzia, odpowiedź staje się prosta i jednoznaczna – skoro istnieje cały segment usług self-service BI, oznacza to, że takie podejście jest możliwe. Wielu dostawców „nowoczesnych” narzędzi Business Intelligence rezygnuje z niepotrzebnej i przestarzałej ich zdaniem architektury opartej na hurtowni danych i skomplikowanym procesie ETL, opierając swoje rozwiązania bezpośrednio na systemach źródłowych. Jednak w tym miejscu należy postawić kolejne pytanie: czy takie podejście jest w każdym przypadku efektywne pod kątem utrzymaniowym i użytkowym? Tutaj odpowiedź nie jest już taka prosta.
Należy mieć na uwadze kilka zasadniczych wad takiego podejścia. Przede wszystkim raporty oparte na systemie źródłowym muszą te dane z systemu cyklicznie pobierać. Bez względu na to, czy odpytują to źródło w czasie rzeczywistym, czy buforują dane w swoich wewnętrznych mechanizmach (przetwarzanie w pamięci operacyjnej, ang. in-memory), oznacza to konieczność regularnego odpytywania źródła. A czym jest to źródło danych? Jest to najczęściej baza transakcyjna, czyli baza, na której opiera się system ERP, CRM lub inny system – zazwyczaj krytyczny w działaniu firmy. Bazy transakcyjne bardzo często i tak są mocno obciążone, więc jeśli nie poradzą sobie z dodatkowym obciążeniem zapytaniami raportowymi, może to być bardzo niebezpieczne dla funkcjonowania całego przedsiębiorstwa. Rozwiązaniem w takim wypadku jest tzw. ładowanie przyrostowe, dzięki któremu dane nie będą pobierane za każdym razem w 100%, a dodawane będą jedynie te dane, które pojawiły się, bądź zmieniły od ostatniego ładowania. Jednak takie rozwiązanie wymaga przygotowania odpowiedniego modelu ładowania danych, a więc w istocie – procesu ETL.
I tutaj dochodzimy do sedna. Tworząc wewnętrzne struktury danych dla narzędzia self-service BI, często nazywane modelem danych, tworzymy tak naprawdę hurtownię danych. Wszelkie modele, których rolą jest zastąpienie hurtowni danych, w rzeczywistości są hurtowniami danych. Zmieniono jedynie ich nazwę i wprowadzono nowe, chwytliwe hasła. Największym problemem w takim podejściu nie jest jednak samo zmienione nazewnictwo, a warstwa utrzymaniowa raportów zbudowanych w taki sposób. Najczęściej tworzony jest bowiem osobny model dla poszczególnych jednostek raportowych – można więc sobie wyobrazić sytuację, w której istnieją dziesiątki raportów i każdy z nich osobno pobiera dane ze źródła, na podstawie osobno dla niego stworzonego modelu danych. Złamana w ten sposób zostaje kluczowa zasada integralności danych i jednej wersji prawdy.
Konsekwencje self-service
Przedsiębiorstwo, które początkowo chciało ograniczyć koszty poprzez rezygnację z hurtowni danych, wpaść może więc w spiralę błędu, z której niełatwo wyjść. Wyobraźmy sobie, co się stanie, jeżeli coś zostanie zmienione w źródłowej bazie danych, chociażby coś tak prostego jak nazwa kolumny w tabeli. W przypadku dziesiątek autonomicznych modeli trzeba będzie wprowadzić zmiany w każdym z nich z osobna. W przypadku zunifikowanego procesu ETL, stworzonego dla hurtowni danych, zmiany takie wprowadzane są w określonych miejscach przepływu – tylko raz. Ponadto pojedyncze modele w raportach mogą mieć swoją własną logikę działania (i innego autora), więc w momencie, gdy trzeba wprowadzić modyfikację, w skrajnych przypadkach może to powodować konieczność zrozumienia ogromnej ilości linii kodu obsługującego poszczególne raporty.
Bezpieczeństwo
Istotnym aspektem w przypadku wszelkich systemów opartych o dane jest bezpieczeństwo. W tej kwestii narzędzia self-service również mogą być ryzykowne. W przypadku centralnego miejsca przetwarzania danych, a więc hurtowni danych, łatwiej jest zarządzać ich bezpieczeństwem. Nowoczesne systemy bazodanowe, na których możemy postawić hurtownie danych, takie jak np. SQL Server, mają wbudowane mechanizmy zabezpieczeń obiektów i rekordów, dlatego też w spójny sposób można na przykład nadawać i odbierać dostępy użytkownikom. Natomiast w przypadku rozwiązań opartych bezpośrednio na źródle danych, wykorzystywać trzeba zabezpieczenia konkretnych jednostek raportowych, co może skutkować podobnymi problemami, jak wspomniane wcześniej zarządzanie zmianami w źródle i logice.
Zobaczmy typową architekturę rozwiązania samoobsługowego BI bez hurtowni danych. Wydaje się dużo prostsza, prawda? Jest to jednak złudne wrażenie, ponieważ wszystko „dzieje się” wewnątrz każdej z aplikacji (raportu, analizy). Każda aplikacja ma swoje własne połączenia i reguły pobierania danych.
Schemat systemu Business Intelligence typu self-service
Podsumowanie
Zarówno systemy wykorzystujące hurtownie danych, jak i narzędzia self-service, znajdują zastosowanie w biznesie. Implementacje w obu przypadkach mogą być zakończone zarówno sukcesem, jak i porażką – wszystko zależy od rodzaju biznesu, jego potrzeb, wykorzystanych narzędzi i umiejętności architekta systemu. Moim zdaniem warto jednak pamiętać o tym, że sytuacje, w których można „ominąć” hurtownię danych są stosunkowo rzadkie, a narzędzia, które nie korzystają z tradycyjnej hurtowni danych, tak naprawdę budują jej model wewnątrz swoich własnych struktur, pomijając przy tym cały szereg udogodnień i dobrych praktyk związanych z hurtownią. Do każdej implementacji należy więc podejść rozsądnie, bez ulegania marketingowym sloganom przedstawicieli handlowych. Należy również dostrzegać długofalowe zalety oraz wady, koszty i korzyści implementacji każdego narzędzia – to, co na początku może wydawać się tańszym rozwiązaniem, może okazać się głównym generatorem kosztu, zmniejszającym nasz zwrot z inwestycji.
