Systemy Enterprise Data Warehouse (EDW) mają na celu zapewnienie prawdziwego Business Intelligence (BI) dla przedsiębiorstwa opartego na danych. Firmy muszą zajmować się krytycznymi metrykami zakorzenionymi w tych istotnych, żywych danych. Zapewnienie istotnego procesu integracji danych, który ostatecznie wspiera różnorodne wymagania w zakresie raportowania, jest kluczowym celem systemów hurtowni danych. Ich budowa wymaga znacznych nakładów projektowych, rozwojowych, administracyjnych i operacyjnych. Kiedy systemy biznesowe, struktury lub reguły zmieniają się, nie dostarczają spójnych danych lub wymagają nowych rozwiązań w zakresie integracji systemów, minimalne wymagania w zakresie reengineeringu stawiają nas przed problemem nr 1: Jedną stałą jest zmiana; więc jak dobrze rozwiązanie EDW/BI może się dostosować?
„Nie przetrwa najsilniejszy z gatunków, ani najbardziej inteligentny. To ten, który jest najbardziej przystosowany do zmian.” Charles Darwin
Konsumpcja i analiza danych biznesowych przez zróżnicowane społeczności użytkowników stała się krytyczną rzeczywistością dla utrzymania przewagi konkurencyjnej, jednak dzisiejsze realia technologiczne często wymagają wysoko wykwalifikowanych użytkowników końcowych. Przechwytywanie, przetwarzanie, przekształcanie, oczyszczanie i raportowanie tych danych może być zrozumiałe, ale w większości przypadków sama ilość danych może być przytłaczająca; Yup, problem #2: Really Big Data; często charakteryzowany jako: Volume, Velocity, Variety, Variability, Veracity, Visualization, & Value!
Crafting effective and efficient EDW/BI systems, simplified for usability and reporting on this data, quickly becomes a daunting and often difficult technical ordeal even for veteran engineering teams. Wymagane jest zastosowanie kilku zintegrowanych technologii, począwszy od systemów baz danych, narzędzi do przetwarzania danych (ETL), takich jak Talend, różnych języków programowania, oprogramowania administracyjnego, raportującego i interaktywnego oprogramowania graficznego, aż po wydajne sieci i potężne komputery o bardzo dużych pojemnościach pamięci masowej. Projektowanie, tworzenie, dostarczanie i wspieranie solidnych, niewymagających wysiłku systemów EDW/BI dla uproszczonego, inteligentnego użytkowania to, zgadliście, problem nr 3: Złożoność!
Często widzimy kompleksowe i eleganckie rozwiązania dostarczane użytkownikowi biznesowemu, który nie rozumie prawdziwych potrzeb biznesu. Mówi się nam, że tak właśnie jest ze względu na wymagania techniczne (ograniczenia; wink, wink) i/lub parametry projektowe (brak funkcji; nudge, nudge). Stąd problem #4: Domena biznesowa; dopasuj dane do potrzeb biznesu, nie odwrotnie!
Co więcej, jako że systemy upstream zmieniają się (a będą się zmieniać), jako że technologia EDW/BI pędzi do przodu (a musi), jako że dynamiczne złożoności przeważają (nieubłaganie), co jakiś czas nowe źródła danych muszą być dodawane do miksu. Są one zazwyczaj nieprzewidywalne i nieplanowane. Wpływ integracji może być ogromny, często wymagający całkowitej regeneracji zagregowanych danych; stąd problem #5: Elastyczność; lub jej brak!
Jak więc rozwiązać te problemy? Cóż…
Bill Inmon powszechnie uważany za ojca hurtowni danych, definiuje hurtownię danych jako:
„Zorientowany tematycznie, nieulotny, zmienny w czasie zbiór danych wspierający decyzje kierownictwa”
(http://en.wikipedia.org/wiki/Bill_Inmon)
Ralph Kimball (http://en.wikipedia.org/wiki/Ralph_Kimball), pionier architektury hurtowni danych, opracował metodologię „modelowania wymiarowego” uznawaną obecnie za de-facto standard w dziedzinie wspomagania decyzji. Model wymiarowy (zwany „schematem gwiaździstym”) różni się od metodologii „modelowania znormalizowanego” Inmana (zwanego czasem „schematem płatka śniegu”). W schemacie gwiaździstym Kimballa, dane transakcyjne są podzielone na zagregowane „fakty” z referencyjnymi „wymiarami” otaczającymi i dostarczającymi deskryptorów, które definiują fakty. Model znormalizowany (3NF lub „trzecia postać normalna”) przechowuje dane w powiązanych ze sobą „tabelach” zgodnie z zasadami projektowania relacyjnych baz danych ustanowionymi przez E. F. Codda i Raymonda F. Boyce’a na początku lat 70-tych, które eliminują redundancję danych. Obydwie metodologie mają słabe punkty, gdy mają do czynienia z nieuniknionymi zmianami w systemach zasilających hurtownię danych oraz w czyszczeniu danych, aby spełniały surowe wymagania metodologiczne.
Ponadto, kostka OLAP (od „online analytical processing”) jest strukturą danych, która pozwala na szybką analizę danych z wielu perspektyw. Struktura kostki jest tworzona na podstawie schematu gwiazdy lub płatka śniegu przechowywanego jako metadane, na podstawie których można przeglądać lub „pivotować” dane na różne sposoby. Generalnie kostki posiadają jeden wymiar oparty na czasie, który wspiera historyczną reprezentację danych. Tworzenie kostek OLAP może być bardzo kosztowne i często tworzy znaczną ilość danych, które są mało lub w ogóle nieużyteczne. W wielu przypadkach sprawdza się zasada 80/20 (gdzie tylko 20% danych z kostki OLAP okazuje się użyteczne), co rodzi pytanie: Czy zbudowana na tradycyjnej architekturze kostka OLAP rzeczywiście zapewnia wystarczający ROI? Często odpowiedzią jest stanowcze NIE! Trwałe systemy EDW/BI muszą dostarczać prawdziwą wartość.
Dowiedz się, jak Talend pomógł Tipico przekształcić oceany danych w najnowocześniejszą inteligencję biznesową.
Świeże podejście
The Data Vault to hybrydowa metodologia modelowania danych zapewniająca reprezentację danych historycznych z wielu źródeł, zaprojektowana tak, aby była odporna na zmiany środowiska. Dan Linstedt, jej twórca, opisuje bazę danych Data Vault jako:
„Zorientowany na szczegóły, śledzący historię i jednoznacznie powiązany zestaw znormalizowanych tabel, które wspierają jeden lub więcej funkcjonalnych obszarów biznesu. Jest to hybrydowe podejście obejmujące to, co najlepsze pomiędzy 3NF i Star Schemas. Projekt jest elastyczny, skalowalny, spójny i adaptowalny do potrzeb przedsiębiorstwa.”
(http://en.wikipedia.org/wiki/Data_Vault_Modeling)
Skupiając się na procesach biznesowych, Data Vault jako architektura integracji danych posiada solidne standardy i metody definiowania, które jednoczą informacje w celu nadania im sensu. Model Data Vault składa się z trzech podstawowych typów tabel:
HUB (niebieski): zawierający listę unikalnych kluczy biznesowych posiadających swój własny klucz zastępczy. Metadane opisujące pochodzenie klucza biznesowego lub „źródło” rekordu są również przechowywane w celu śledzenia, skąd i kiedy pochodzą dane.
LNK (czerwony): ustanawiający relacje między kluczami biznesowymi (zazwyczaj huby, ale linki mogą łączyć się z innymi linkami); zasadniczo opisujący relację wiele do wielu. Powiązania są często wykorzystywane do radzenia sobie ze zmianami w ziarnistości danych, zmniejszając wpływ dodania nowego klucza biznesowego do powiązanego Hubu.
SAT (żółty): przechowywanie atrybutów opisowych, które mogą zmieniać się w czasie (podobne do powoli zmieniającego się wymiaru Kimball Type II). Podczas gdy Huby i Linki tworzą strukturę modelu danych, Satelity zawierają atrybuty czasowe i opisowe, w tym metadane łączące je z ich macierzystymi tabelami Hub lub Link. Atrybuty metadanych w ramach tabeli Satellite zawierające datę, kiedy rekord stał się ważny i datę, kiedy wygasł, zapewniają potężne możliwości historyczne umożliwiające zapytania, które mogą sięgać „wstecz w czasie”.
Podejście Data Vault ma kilka kluczowych zalet:
– Upraszcza proces przyjmowania danych
– Usuwa wymóg czyszczenia danych przez Star Schema
– Natychmiast zapewnia możliwość audytu dla HIPPA i innych regulacji
– Skupia uwagę na prawdziwym problemie zamiast programować wokół niego
– Łatwo pozwala na dodawanie nowych źródeł danych bez zakłócania istniejącego schematu
Sprościej mówiąc, Data Vault jest zarówno techniką modelowania danych, jak i metodologią, która umożliwia przechowywanie danych historycznych, audytowanie i śledzenie danych.
„Data Vault jest optymalnym wyborem do modelowania EDW w ramach DW 2.0”
Bill Inmon
Adaptable
Poprzez oddzielenie kluczy biznesowych (ponieważ są one na ogół statyczne) i związków między nimi od ich atrybutów opisowych, Data Vault stawia czoła problemowi zmian w środowisku. Wykorzystując te klucze jako strukturalny szkielet hurtowni danych, wszystkie powiązane dane mogą być zorganizowane wokół nich. Te Huby (klucze biznesowe), Linki (asocjacje) i SAT (atrybuty opisowe) wspierają wysoce adaptowalną strukturę danych przy jednoczesnym zachowaniu wysokiego stopnia integralności danych. Dan Linstedt często porównuje skarbiec danych do uproszczonego obrazu mózgu, w którym neurony są powiązane z Hubami i Satelitami, a dendryty są Linkami (wektorami informacji). Niektóre Łącza są jak synapsy (wektory w przeciwnym kierunku). Mogą one być tworzone lub upuszczane w locie, gdy zmieniają się relacje biznesowe, automatycznie zmieniając model danych w razie potrzeby, bez wpływu na istniejące struktury danych. Problem #1 rozwiązany!
Big Data
Data Vault v2.0 pojawił się na scenie w 2013 roku i zawiera płynną integrację technologii Big Data wraz z metodologią, architekturą i wdrożeniami najlepszych praktyk. Dzięki tej adopcji, bardzo duże ilości danych mogą być łatwo włączone do Data Vault zaprojektowanego do przechowywania przy użyciu produktów takich jak Hadoop, Infobright, MongoDB i wielu innych opcji NoSQL. Eliminując wymagania związane z oczyszczaniem danych, jakie stawia schemat gwiaździsty, Data Vault doskonale radzi sobie z ogromnymi zbiorami danych, skracając czas wczytywania i umożliwiając równoległe wstawianie danych, co pozwala wykorzystać możliwości systemów Big Data. Problem #2 rozwiązany!
Uproszczenie
Stworzenie efektywnego i wydajnego modelu Data Vault może być wykonane szybko, gdy tylko zrozumiesz podstawy 3 typów tabel: Hub, Satellite i Link! Identyfikacja kluczy biznesowych na pierwszym miejscu i zdefiniowanie hubów jest zawsze najlepszym punktem wyjścia. Następnie Huby-Satelity reprezentują kolumny tabeli źródłowej, które mogą się zmieniać, a na końcu Linki wiążą to wszystko razem. Pamiętaj, że możliwe jest również posiadanie tabel Link-Satelita również. Gdy już poznasz te koncepcje, wszystko jest proste. Po zbudowaniu modelu Data Vault następną rzeczą, którą trzeba zrobić, jest zbudowanie procesu integracji danych ETL, który będzie go wypełniał. Model Data Vault nie jest ograniczony do rozwiązań EDW/BI, ale za każdym razem, gdy potrzebujesz pobrać dane z jakiegoś źródła danych do jakiegoś obiektu docelowego, proces integracji danych jest generalnie wymagany. Misją Talend jest łączenie przedsiębiorstw opartych na danych.
Dzięki swojemu pakietowi oprogramowania integracyjnego Talend upraszcza proces tworzenia oprogramowania, redukuje krzywą uczenia się i obniża całkowity koszt posiadania dzięki ujednoliconej, otwartej i przewidywalnej platformie ETL. Jako sprawdzona technologia ETL, Talend z pewnością może być użyty do wypełnienia i utrzymania solidnego systemu EDW/BI zbudowanego w oparciu o model danych Data Vault. Problem #3 rozwiązany!
Twój biznes
Data Vault zasadniczo definiuje ontologię przedsiębiorstwa, opisując domenę biznesową i relacje w jej obrębie. Przetwarzanie reguł biznesowych musi nastąpić przed wypełnieniem schematu gwiezdnego. Dzięki Data Vault możesz je przekazać dalej, po wprowadzeniu do EDW. Dodatkową filozofią Data Vault jest to, że wszystkie dane są istotne, nawet jeśli są błędne. Dan Linstedt sugeruje, że błędne dane są problemem biznesowym, a nie technicznym. Zgadzam się! EDW naprawdę nie jest właściwym miejscem do naprawiania (oczyszczania) złych danych. Prostym założeniem Data Vault jest pobieranie 100% danych źródłowych przez 100% czasu; dobrych, złych lub brzydkich. W dzisiejszym świecie audytowalność i identyfikowalność wszystkich danych w hurtowni danych stały się standardowym wymogiem. Ten model danych został zaprojektowany specjalnie po to, aby sprostać potrzebom dzisiejszych systemów EDW/BI. Problem #4 rozwiązany!
„Zrozumieć Data Vault to zrozumieć biznes”
(http://danlinstedt.com)
Elastyczność
Metodologia Data Vault jest oparta na najlepszych praktykach SEI/CMMI Level 5 i zawiera wiele jej komponentów łącząc je z najlepszymi praktykami z Six Sigma, TQM i SDLC (Agile). Projekty Data Vault mają krótkie, kontrolowane cykle wydawnicze i mogą składać się z wydania produkcyjnego co 2 lub 3 tygodnie, automatycznie adoptując powtarzalne, spójne i mierzalne projekty oczekiwane na poziomie 5 CMMI. Gdy trzeba dodać nowe źródła danych, podobne klucze biznesowe są prawdopodobne, można dodać nowe Huby-Satelity-Linki, a następnie dalej połączyć je z istniejącymi strukturami Data Vault bez żadnych zmian w istniejącym modelu danych. Problem #5 rozwiązany!
Wniosek
Podsumowując, modelowanie i metodologia Data Vault adresuje elementy problemów, które zidentyfikowaliśmy powyżej:
– Dostosowuje się do zmieniającego się środowiska biznesowego
– Obsługuje bardzo duże zbiory danych
– Upraszcza złożoność projektowania EDW/BI
– Zwiększa użyteczność dla użytkowników biznesowych, ponieważ. jest wzorowany na domenie biznesowej
– Pozwala na dodawanie nowych źródeł danych bez wpływu na istniejący projekt
Ten postęp technologiczny już teraz okazuje się być wysoce efektywny i wydajny. Łatwy do zaprojektowania, zbudowania, zapełnienia i zmiany, Data Vault jest zdecydowanym zwycięzcą. Bardzo fajne! Chcesz go mieć?
Zobacz http://learndatavault.com lub http://www.keyldv.com/lms, aby dowiedzieć się więcej na temat modelowania i metodologii Data Vault.
Przy okazji pobierz bezpłatną wersję próbną Talend Cloud Integration Platform, aby przekonać się, co naprawdę potrafią Twoje dane.