Idź do:
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 pewnym momencie każde przedsiębiorstwo musi więc zmierzyć się z problemem, którym wcale nie jest brak dostępu do danych czy ich niedobór, ale przesyt, utrudnione przetwarzanie, 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 danych to lek na chaos informacyjny?
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. 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 Murphy 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:
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”.
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.
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 marts 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 nimi. 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.
Rys. 4. Schemat architektury hurtowni danych wg Inmona
Hurtownie danych są zasilane z wykorzystaniem 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.
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.
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 artykule Czy hurtownia to lek na dezintegrację danych?).
Kimball zakłada, że hurtownia danych to tak naprawdę zbiór spójnych data marts opartych na współdzielonych wymiarach. Raporty tworzone są bezpośrednio na podstawie data marts lub poprzez dodatkową warstwę, jaką stanowią kostki OLAP.
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.
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, satelita i link.
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.
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 (niebę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 marts. 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.
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 marts 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
Abramson I.: Data Warehouse: The Choice of Inmon versus Kimball
Adamson C.: Three Data Warehouse Architectures that Use Star Schema, opublikowano: 26 marca 2007.
Anderson D.: What is “The Data Vault” and why do we need it?, opublikowano 27 marca 2015.
Czarko-Wasiutycz R.: Miejsce architektury Data Vault 2.0 w hurtowniach danych, prezentacja na konferencji SQLDay, Wrocław 2018.
Dalby J.: Dimensional modeling – architecture and terminology.
Drozda P.: Bazy danych. Wprowadzenie.
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).
George S.: Inmon or Kimball: Which approach is suitable for your data warehouse?, opublikowano 14 kwietnia 2012.
Graczyk B.: Ciebie też to czeka…ewolucja trwa…, opublikowano 14 marca 2017.
Graczyk B.: Największy mit świata BI – poznaj odpowiedź…, opublikowano 23 sierpnia 2017.
Graziano K.: Data Vault 2.0 Modeling Basics, opublikowano 20 października 2015.
Graziano K.: Building an Information Mart With Your Data Vault, opublikowano 17 listopada 2015.
Hall M.: The 10 IT People Who Mattered in the Past 40 Years (but You May Not Know Why), opublikowano 9 lipca 2007.
Hultgren P.: Data Vault layers & the Raw Vault, opublikowano 20 lutego 2011
Inmon W.H.: Corporate Information Factory, John Wiley & Sons, Indianapolis 2000.
Kempe S.: A Short History of Data Warehousing, opublikowano 23 sierpnia 2012.
Kimball R., Ross M.: The Data Warehouse ToolKit, Third Edition: The Definitive Guide to Dimensional Modeling, John Wiley & Sons, Indianapolis 2013.
Linstedt D., Olschimke M.: Building a Scalable Data Warehouse with Data Vault 2.0, Morgan Kaufmann, Cambridge, MA, USA, 2015.
Mor Y.: Inmon vs. Kimball – The Big Data Warehouse Duel, opublikowano 10 kwietnia 2014.
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.
Orlov V.: Data Warehouse Architecture: Inmon CIF, Kimball Dimensional or Linstedt Data Vault?, opublikowano 9 kwietnia 2014.
Ross M.: Differences of Opinion, opublikowano 3 marca 2004.
The Data Vault Architecture, opublikowano 14 grudnia 2012.
Vos R.: Comparisons between Data Warehouse modelling techniques, opublikowano 12 lutego 2013.
Vos R.: Data Vault comparisons, opublikowano 16 maja 2012.
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.
Warto zobaczyć
Arshad A.: Comparing Data Warehouse Design Methodologies for Microsoft SQL Server, opublikowano: 24 czerwca 2013.
Chodkowski A.: Hurtownie danych a narzędzia self-service Business Intelligence, opublikowano 6 grudnia 2016.
Evers M.: Data Vault, The new Datawarehouse Supermodel
What is Data Vault?, 10 kwietnia 2012.
YouTube: Brief History of the Data Vault
YouTube: Dimensional Modeling to Data Vault Evolution
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.
