Ewolucja technik modelowania hurtowni danych

Artykuły eksperckie | 08.08.2018 | Czas czytania: 16 minut

Poszukiwanie efektywnego sposobu przechowywania danych i ich wydajnego przetwarzania jest znakiem naszych czasów. Niniejszy artykuł porusza więc tematykę sposobu relacyjnego przechowywania dużych ustrukturyzowanych zbiorów danych, pochodzących z różnych źródeł, określanego mianem hurtowni danych. Artykuł powinien zainteresować wszystkich tych, którzy zastanawiają się, czym jest hurtownia danych, czym jest Data Vault i co na przestrzeni ostatnich lat zmieniło się w postrzeganiu „tradycyjnej” wielowymiarowej hurtowni danych.

Przekleństwo eksplozji danych

Właściwie każde większe przedsiębiorstwo zmaga się z problemem nadmiarowości danych. Dane „produkowane” są niemal przez każde urządzenie elektroniczne i różnego rodzaju systemy wspierające działalność operacyjną organizacji. Można do nich zaliczyć systemy służące do:

  • planowania zasobów przedsiębiorstwa,
  • zarządzania relacjami z klientami,
  • zarządzania magazynem,
  • systemy finansowo-księgowe,
  • systemy produkcyjne,
  • i wiele innych, często specyficznych dla obszaru działalności przedsiębiorstwa.

Systemy te przeważnie gromadzą dane w bazach danych w trzeciej postaci normalnej. Co to znaczy? W bazach danych spotkać można relacje trzech postaci:

  1. Pierwsza postać normalna = 1PN (ang. 1NF = First normal form) – każdy atrybut w tabeli ma wartość elementarną (brak powtarzających się grup informacji), tabela posiada klucz
  2. Druga postać normalna = 2PN (ang. 2NF = Second normal form) – tabela powinna przechowywać dane dotyczące tylko konkretnej klasy obiektów
  3. Trzecia postać normalna = 3PN (ang. 3NF = Third normal form) – każdy niekluczowy atrybut jest bezpośrednio zależny tylko od klucza głównego

W systemach operacyjnych, które stanowią źródło dla hurtowni danych, najczęściej spotykana jest postać 3PN, ponieważ gwarantuje to szybkie operacje zapisu danych bez redundancji.

W pewnym momencie każde przedsiębiorstwo musi więc zmierzyć się z problemem, którym wcale nie jest brak czy niedobór danych, ale ich przesyt, brak możliwości przekucia ich w wiedzę i wydajnego zastosowania w procesie podejmowania decyzji. Odpowiedzią na ten problem jest hurtownia danych, której zadaniem jest integracja heterogenicznych, czyli pochodzących z wielu źródeł, danych przedsiębiorstwa. Termin hurtownia jednoznacznie wskazuje także na spory wolumen danych możliwych do przechowywania w takiej strukturze.

Hurtownia danych to relacyjna baza danych, przechowująca zintegrowane dane pochodzące z różnych źródeł, w tym z systemów transakcyjnych przedsiębiorstwa. Najczęściej hurtownia danych poświęcona jest konkretnemu procesowi biznesowemu czy obszarowi działania przedsiębiorstwa. Celem hurtowni jest dostarczenie wiedzy decyzyjnej.

Więcej podstawowych informacji na ten temat można znaleźć w artykule Czy hurtownia to lek na dezintegrację danych? 

Historia hurtowni danych w pigułce

Trudno jednoznacznie wyznaczyć konkretny moment w historii stanowiący początek koncepcji hurtowni danych. Prace teoretyczne w tym obszarze były prowadzone już w latach 70-tych ubiegłego stulecia. Z drugiej strony pierwszy komercyjny system Business Intelligence został stworzony w 1985 roku dla firmy Procter & Gamble. W roku 1988 w artykule zatytułowanym Architektura dla biznesu i systemów informacyjnych Barry Devlin i Paul Murpy zdefiniowali pojęcie „hurtowni danych biznesowych” na łamach czasopisma naukowego IBM Systems Journal.

Hurtownie danych nieodłącznie kojarzone są z urodzonym w 1945 roku amerykańskim informatykiem Billem Inmonem, uważanym przez wielu za ojca hurtowni danych. Bill Inmon został mianowany przez Computerworld w 2007 roku jedną z dziesięciu osób, które miały najbardziej znaczący wpływ na rozwój IT przez ostatnie 40 lat. W 1992 roku Inmon zdefiniował hurtownię danych następująco:

Hurtownia danych to tematyczna baza danych, która trwale przechowuje zintegrowane dane opisane wymiarem czasu, mająca służyć wspomaganiu procesu podejmowania decyzji.

Każde z użytych w definicji słów precyzyjnie określa atrybuty hurtowni danych:

JPro ewolucja technik modelowania hurtowni 01 cechy hurtowni Inmon

Rys. 1. Atrybuty hurtowni danych wg definicji Inmona

Obok Inmona kluczową postacią w obszarze hurtowni danych jest urodzony w 1944 roku Ralph Kimball. W odróżnieniu od definicji hurtowni danych Inmona, gdzie nacisk położony jest na cechach hurtowni, Kimball koncentruje się na jej przeznaczeniu:

Hurtownia danych to system, który pozyskuje dane z systemów źródłowych, przekształca je i ładuje je do wielowymiarowych struktur, a następnie dostarcza zapytania i analizy wspierające podejmowanie decyzji.

JPro ewolucja technik modelowania hurtowni 02 przeznaczenie hurtowni Kim

Rys. 2. Przeznaczenie hurtowni danych wg definicji Kimballa

Autorem trzeciego podejścia do tematyki hurtowni danych, określanym jako Data Vault, jest Dan Linstedt. Data Vault to wynik 10-letnich badań Linstedta w celu zapewnienia spójności, elastyczności i skalowalności hurtowni. Za pierwszy owoc jego badań w tym zakresie można przyjąć wydane w 2000 roku pięć artykułów poświęconych tej tematyce.

Bill Inmon, Ralph Kimball i Dan Linstedt są autorami setek publikacji prezentujących ich podejście do modelowania danych. Najpełniejsze odzwierciedlenie ich punktów widzenia na hurtownie danych można odnaleźć w książkach, których są autorami. Wyjaśnienie podejścia każdego z trzech wizjonerów postaram się jednak w skrócie porównać w kolejnych akapitach.

 JPro ewolucja technik modelowania hurtowni 03 ksiazki hurtownia danych

Rys. 3. Pierwsze wydania książek poświęconych projektowaniu hurtowni danych wg różnych podejść

Jedna wersja prawdy Billa Inmona

Hurtownia danych wg Inmona w fizycznym, implementacyjnym ujęciu to centralna, relacyjna baza danych w trzeciej postaci normalnej, na podstawie której budowane są data marty przeznaczone dla poszczególnych jednostek (departamentów, działów, wydziałów) organizacji. Podejście Inmona oparte jest bezpośrednio na danych źródłowych, budowę hurtowni można więc rozpocząć a priori bez specyfikowania wymagań użytkownika. Architektura Inmona zakłada wykorzystanie wszystkich baz systemów operacyjnych, wyklucza więc możliwość wybiórczego pozyskiwania danych. Hurtownia danych przechowuje zatem atomowe (elementarne) dane pochodzące z baz danych systemów źródłowych. Takie podeście daje gwarancję elastyczności i skalowalności, co jest niezwykle cenne w przypadku szybko zmieniających się struktur baz danych systemów źródłowych. Dodatkowo, wszystkie data marty oparte są zawsze na tej samej hurtowni danych, co implikuje spójność pomiędzy data martami. Inmon jest zatem zwolennikiem teorii jednej wersji prawdy (ang. SVOT = single version of the truth). Warto podkreślić, że hurtownia danych i data marty są fizycznie odseparowane, co można zaobserwować na poniższym rysunku.

JPro ewolucja technik modelowania hurtowni 04 schemat architektury inmon

Rys. 4. Schemat architektury hurtowni danych wg Inmona

Zasilanie hurtowni danych wymaga wykorzystania tzw. procesów ETL (ang. Extract, Transform, Load). Są to procesy, których zadaniem jest:

  • ekstrakcja, czyli pobranie danych z systemów źródłowych;
  • transformacja, czyli przekształcenie i ujednolicenie danych;
  • załadowanie danych do hurtowni.

Na schemacie zaznaczono źródła danych, które mogą być bazami danych systemów transakcyjnych, albo plikami płaskimi pochodzącymi z tych systemów. Dopuszczalne są oczywiście inne formy źródeł danych, natomiast te dwa są najbardziej powszechne. Drugą (opcjonalną) warstwą jest obszar przejściowy (ang. staging area), do którego dane trafiają bezpośrednio z systemów źródłowych, najczęściej bez żadnych transformacji.

Jak już wspomniałem, hurtownia danych w rozumieniu Inmona reprezentuje dane atomowe pochodzące z systemów źródłowych zapisane w trzeciej postaci normalnej. Na podstawie jednej centralnej hurtowni danych, określanej czasem jako Korporacyjna Fabryka Informacji (ang. Corporate Information Factory) budowane są data marty. Data marty lub kostki OLAP zbudowane na podstawie martów stanowią źródła danych dla różnych aplikacji raportowych wyposażonych w takie funkcjonalności jak tabela przestawna, wizualizacja danych w postaci wykresów, prezentacja kluczowych wskaźników KPI (ang. Performance Key Indicator), itd.

Poszukujesz doświadczonego specjalisty lub zespołu Business Intelligence?

 

Wielowymiarowy świat Kimballa

Nazwisko Kimball bardzo mocno kojarzone jest ze schematem logicznym hurtowni danych, określanym mianem schematu gwiazdy (ang. star schema). To skojarzenie jest jak najbardziej trafne, Kimball opracował bowiem koncepcję schematu gwiazdy, czyli relacyjnej struktury bazy danych, której centralną część stanowi tzw. tabela faktów (ang. fact table) wraz z otaczającymi ją tabelami wymiarów (ang. dimension tables). Tabela faktów zawiera miary (ang. measures) oraz klucze obce wymiarów, czyli referencje do wymiarów. Miara charakteryzuje wielkość zaistniałego zjawiska (np. wartość sprzedaży w przypadku zaistnienia faktu sprzedaży jakiegoś produktu).

Wymiary opisują natomiast zaistniały w rzeczywistości fakt, dostarczając dodatkowych informacji na jego temat (np. informacje o sprzedanym produkcie oraz o kliencie, który dokonał zakupu). Każda hurtownia musi zawierać wymiar czasu, który pozwala na jednoznaczne określenie daty i godziny danego zdarzenia.

JPro ewolucja technik modelowania hurtowni 05 schemat gwiazdy

Rys. 5. Schemat gwiazdy opracowany przez Ralpha Kimballa

Oprócz schematu gwiazdy istnieją także schematy określane mianem płatka śniegu i konstelacji gwiazd, będące wariacją na temat schematu gwiazdy (więcej informacji można odnaleźć w tym artykule).

Kimball zakłada, że hurtownia danych to tak naprawdę zbiór spójnych data martów opartych na współdzielonych wymiarach. Raporty tworzone są bezpośrednio na podstawie data martów lub poprzez dodatkową warstwę, jaką stanowią kostki OLAP.

JPro ewolucja technik modelowania hurtowni 06 schemat architektury kimba

Rys. 6. Schemat architektury hurtowni danych wg Kimballa

Wymiary w rozumieniu Kimballa powinny być uzgodnione, czyli zachowywać to samo znaczenie w relacji z wieloma faktami. Etap projektowania tego podejścia zakłada opracowanie macierzy procesów biznesowych i wymiarów (ang. bus matrix). Dzięki takiemu podejściu konkretne tabele faktów wpinane są w „magistralę”, reprezentującą dostępne wymiary organizacji w hurtowni danych.

JPro ewolucja technik modelowania hurtowni 07 macierz procesow

Rys. 7. Macierz procesów biznesowych i wymiarów

Ponadto podejście Kimballa w przeciwieństwie do Inmona, zakłada mocne zaangażowanie użytkowników końcowych już od samego początku tworzenia hurtowni.

Jedna wersja faktów Linstedta – Data Vault

W przeciwieństwie do spojrzenia Inmona na dane, Linstedt zakłada, że wszystkie dostępne dane z całego okresu powinny zostać załadowane do hurtowni. Stanowi to podejście określane jako „jedna wersja faktów”. Tak jak w przypadku schematu gwiazdy Kimballa, tak w przypadku Data Vault Linstedt wprowadza pewne dodatkowe obiekty w celu organizacji struktury hurtowni danych. Obiekty te określane są jako: hub, satelitalink.

JPro ewolucja technik modelowania hurtowni 08 data vault Linstedt

Rys. 8. Schemat architektury Data Vault wg Linstedta

Huby to obiekty zawierające unikalną listę kluczy biznesowych (pochodzących z systemów źródłowych). Dodatkowo w hubie przechowywane są metadane dotyczące daty i godziny pierwszego pojawienia się danego klucza oraz źródła pochodzenia. Hub nie zawiera danych opisowych ani faktów. Linki z kolei pozwalają na określanie relacji pomiędzy hubami. Przypominają one tabele faktów w modelowaniu wielowymiarowym. Satelity zawierają dane opisowe, przypominając tym samym znane z modelowania wielowymiarowego wymiary, i mogą łączyć się tylko z hubami lub linkami. Przykładowym hubem może być zatem unikalny identyfikator klienta w systemie sprzedażowym; łączem będzie pojedyncza linia sprzedażowa, a satelitą dane klienta do wysyłki.

 JPro ewolucja technik modelowania hurtowni 09 schemat architektury linst

Rys. 9. Schemat architektury hurtowni danych wg Linstedta

W celach optymalizacyjnych w Data Vault 2.0 zamiast kluczy głównych bezpośrednio pochodzących z systemów źródłowych (najczęściej liczby całkowite), poddaje się je przekształceniu przy wykorzystaniu tzw. funkcji skrótu (haszującej), np. MD5 lub bezpieczniejsze SHA-2. Dodatkowo, dzięki takiemu podejściu możliwe jest wdrożenie Data Vault na Hadoopie. Inną innowacją Data Vault 2.0 jest wykorzystanie tzw. Hash Diff do wydajnego porównywania danych już załadowanych, z danymi oczekującymi na załadowanie w kolejnym zasileniu. Hash Diff wyznaczany jest na podstawie wszystkich opisowych kolumn w satelicie (nie będących metadanymi) za pomocą funkcji skrótu. W przypadku różnic pomiędzy skrótami, następuje zapisanie nowego rekordu (analogicznie jak w przypadku SCD typu 2), brak zmian to brak akcji.

W hurtowni danych wg Listedta wyróżnia się czasem tzw. Raw Vault oraz Business Vault. Raw Vault to serce Data Vault zorganizowane w satelity, huby i linki umożliwiające historyczne śledzenie zmian w zintegrowanych danych pochodzących z różnych źródeł. Na podstawie tej warstwy tworzone jest tzw. Business Vault, czyli warstwa przechowująca dane o znaczeniu biznesowym. Dane w tej warstwie poddane zostały podstawowym przekształceniom wymaganym przez biznes. Business Vault stanowi przygotowanie danych dla data martów. Określane jest czasem mianem staging out, w odróżnieniu od staging in, czyli warstwy przechowującej dane zebrane bezpośrednio ze źródeł bez przekształceń (obszar przejściowy). Od Data Vault 2.0 zamiast terminu data mart używany jest termin information mart w celu podkreślenia roli jaką powinny spełniać, czyli dostarczanie użytecznej informacji decydentom.

Omawiając Data Vault, warto wspomnieć nazwiska osób, które aktywnie współtworzą i propagują koncepcję Data Vault na świecie: Hans Hultgren, Michael Olschimke, Roelant Vos.

Porównanie technik modelowania

Istnieje wiele aspektów, które odróżniają lub łączą przedstawione w artykule podejścia. Wygodnym narzędziem może być tabela prezentująca różne kryteria analizy porównawczej, dostępna w pliku PDF.

Wybór?

Biorąc pod uwagę ugruntowaną pozycję hurtowni danych w podejściu Kimballa, może pojawić się pytanie: Czy modelowanie wielowymiarowe jest zatem przestarzałą techniką modelowania hurtowni danych? Odpowiedź jest prosta: potrzeby klienta decydują o doborze odpowiedniej techniki modelowania. Dla niektórych rozwiązanie Data Vault nie jest adekwatne, dla innych z kolei bezcelowe jest wykorzystanie podejścia Inmona. W „naturze” odnaleźć można niejednokrotnie hybrydowe rozwiązania, łączące różne podejścia. Zamiast dogmatycznego wyboru pomiędzy akademickimi podejściami, należy postawić na pragmatyzm i elastyczność. Każdy przypadek jest indywidualny i tylko trafna analiza poparta doświadczeniem pozwala na odpowiedni wybór i dostosowanie rozwiązania do potrzeb klienta.

Ogólnie rzecz ujmując, w przypadku braku wyspecyfikowanych wymagań dotyczących analizy lub też w sytuacji kiedy celem martów jest dostarczenie informacji do kilku systemów BI, warto skorzystać z podejścia Inmona. Tym bardziej, jeżeli struktury baz danych systemów źródłowych są stabilne.

Podejście Kimballa jest zalecane, gdy wymagania są dobrze znane i zdefiniowane. Modele wielowymiarowe są zalecane jako struktura martów z uwagi na swoje zalety, do których można zaliczyć wysoką wydajność i czytelność dla użytkowników końcowych. Z drugiej strony, niektóre narzędzia doskonale radzą sobie z data martami o strukturze płaskiej, które dodatkowo doskonale nadają się do analiz Data Science.

Podejście Data Vault Lindstedta to skuteczne rozwiązanie dla hurtowni danych, opartej na wielu źródłach danych, których struktura często się zmienia. Data Vault stanowi zazwyczaj dobry wybór w przypadku dużych i bardzo dużych projektów zwinnych, gdzie elastyczność, produktywność i skalowalność hurtowni są kluczowe.

Big Data

Omawiając sposoby przechowywania dużych zbiorów danych nie można nie wspomnieć także o zyskujących na popularności rozwiązaniach określanych mianem Big Data. W obliczu olbrzymiej ilości danych dostępnych w przedsiębiorstwach obok koncepcji hurtowni danych rozwija się koncepcja tzw. jeziora danych (ang. Data Lake), przeznaczonego właśnie dla przechowywania i analizy Big Data. Pojawianie się nowych rozwiązań tego typu nie wyklucza dotychczasowych hurtownianych rozwiązań, a jedynie uzupełnia dotychczasową lukę. Wzajemna koegzystencja i integracja systemów przechowywania danych (nieustrukturyzowanych i ustrukturyzowanych) w organizacji pozwala na zapanowanie nad chaosem i uzyskanie potrzebnej wiedzy biznesowej.

Źródła:

  1. Abramson I.: Data Warehouse: The Choice of Inmon versus Kimball
  2. Adamson C.: Three Data Warehouse Architectures that Use Star Schema, opublikowano: 26 marca 2007.
  3. Anderson D.: What is “The Data Vault” and why do we need it?, opublikowano 27 marca 2015.
  4. Czarko-Wasiutycz R.: Miejsce architektury Data Vault 2.0 w hurtowniach danych, prezentacja na konferencji SQLDay, Wrocław 2018.
  5. Dalby J.: Dimensional modeling – architecture and terminology.
  6. Drozda P.: Bazy danych. Wprowadzenie.
  7. Comparison Between Inmon and Kimball Methodology for the Purpose of Designing, Constructing and Testing of a Commercial BIDW Project, International Journal of Computer Graphics Vol. 8, No.1 (2017).
  8. George S.: Inmon or Kimball: Which approach is suitable for your data warehouse?, opublikowano 14 kwietnia 2012.
  9. Graczyk B.: Ciebie też to czeka…ewolucja trwa…, opublikowano 14 marca 2017.
  10. Graczyk B.: Największy mit świata BI – poznaj odpowiedź…, opublikowano 23 sierpnia 2017.
  11. Graziano K.: Data Vault 2.0 Modeling Basics, opublikowano 20 października 2015.
  12. Graziano K.: Building an Information Mart With Your Data Vault, opublikowano 17 listopada 2015.
  13. Hall M.: The 10 IT People Who Mattered in the Past 40 Years (but You May Not Know Why), opublikowano 9 lipca 2007.
  14. Hultgren P.: Data Vault layers & the Raw Vault, opublikowano 20 lutego 2011
  15. Inmon W.H.: Corporate Information Factory, John Wiley & Sons, Indianapolis 2000.
  16. Kempe S.: A Short History of Data Warehousing, opublikowano 23 sierpnia 2012.
  17. Kimball R., Ross M.: The Data Warehouse ToolKit, Third Edition: The Definitive Guide to Dimensional Modeling, John Wiley & Sons, Indianapolis 2013.
  18. Libera T., Ziuziański P.: Charakterystyka budowy hurtowni danych i możliwości implementacji wymiarów różnego typu, Zeszyty Naukowe WSZiB, nr 43, Kraków 2017.
  19. Linstedt D., Olschimke M.: Building a Scalable Data Warehouse with Data Vault 2.0, Morgan Kaufmann, Cambridge, MA, USA, 2015.
  20. Mor Y.: Inmon vs. Kimball - The Big Data Warehouse Duel, opublikowano 10 kwietnia 2014.
  21. Naamane Z., Jovanovic V.: Effectiveness of Data Vault compared to Dimensional Data Marts on Overall Performance of a Data Warehouse System, IJCSI International Journal of Computer Science Issues, Volume 13, Issue 4, July 2016.
  22. Orlov V.: Data Warehouse Architecture: Inmon CIF, Kimball Dimensional or Linstedt Data Vault?, opublikowano 9 kwietnia 2014.
  23. Ross M.: Differences of Opinion, opublikowano 3 marca 2004.
  24. Sen A., Sinha A.: A Comparison of Data Warehousing Methodologies, Communications of the ACM, March 2005/Vol. 48, No. 3.
  25. The Data Vault Architecture, opublikowano 14 grudnia 2012.
  26. Vos R.: Comparisons between Data Warehouse modelling techniques, opublikowano 12 lutego 2013.
  27. Vos R.: Data Vault comparisons, opublikowano 16 maja 2012.
  28. Yessad L., Labiod A.: Comparative study of data warehouses modeling approaches: Inmon, Kimball and Data Vault, International Conference on System Reliability and Science (ICSRS), Paris 2016.

Zobacz pełną listę

Warto zobaczyć:

  1. Arshad A.: Comparing Data Warehouse Design Methodologies for Microsoft SQL Server, opublikowano: 24 czerwca 2013.
  2. Chodkowski A.: Hurtownie danych a narzędzia self-service Business Intelligence, opublikowano 6 grudnia 2016.
  3. Evers M.: Data Vault, The new Datawarehouse Supermodel
  4. What is Data Vault?, 10 kwietnia 2012.
  5. YouTube: Brief History of the Data Vault
  6. YouTube: Dimensional Modeling to Data Vault Evolution
  7. Ziuziański P.: Czy hurtownia to lek na dezintegrację danych?, opublikowano 7 marca 2018.

Zobacz pełną listę

 

Pragnę podziękować zespołowi Business Intelligence naszej Firmy za szereg interesujących dyskusji w toku powstawania artykułu. Dziękuję serdecznie Grzegorzowi Goli za wsparcie w obszarze Data Vault. Ponadto swoje podziękowania za konsultacje kieruje w stronę Adriana Chodkowskiego, współautora bloga seequality.net.

 

 

Autorem wpisu jest

Piotr Ziuziański, JCommerce

Senior Business Intelligence Specialist

Certyfikowany specjalista technologii Business Intelligence firmy Microsoft. Tworzy rozwiązania dla klientów, począwszy od etapu modelowania hurtowni danych, projektowania i wdrażania procesów ETL, po implementację modelu danych i wdrożenie wizualnej warstwy raportowej. Autor bloga poświęconego tematyce rozwiązań klasy Business Intelligence.

Komentarze

  • Aktualnie brak komentarzy.

Skontaktuj się z nami