Systemer til Enterprise Data Warehouse (EDW) har til formål at levere ægte Business Intelligence (BI) til den datadrevne virksomhed. Virksomhederne skal tage fat på kritiske målinger, der er indlejret i disse vitale, levende data. Et centralt mål for disse Enterprise Data Warehouse-systemer er at levere en vigtig dataintegrationsproces, som i sidste ende understøtter en række forskellige rapporteringskrav. Opbygningen af disse systemer kræver en betydelig indsats inden for design, udvikling, administration og drift. Når forretningssystemer, strukturer eller regler i opstrømsleddet ændres, ikke leverer konsistente data eller kræver nye løsninger til systemintegration, giver de minimale reengineeringskrav os problem nr. 1: Det eneste konstante er forandring; så hvor godt kan en EDW/BI-løsning tilpasse sig?
“Det er ikke den stærkeste af arterne, der overlever, ej heller den mest intelligente, der overlever. Det er den, der er mest tilpasningsdygtig over for forandringer.” Charles Darwin
Forbrug og analyse af forretningsdata af forskellige brugergrupper er blevet en kritisk realitet for at bevare en konkurrencefordel, men de teknologiske realiteter i dag kræver ofte højtuddannede slutbrugere. Det kan være forståeligt at indfange, behandle, transformere, rense og rapportere om disse data, men i de fleste tilfælde kan den rene datamængde være overvældende; Yup, problem nr. 2: Really Big Data; ofte karakteriseret som: Volume, Velocity, Variety, Variability, Veracity, Visualization, & Value!
Det bliver hurtigt en skræmmende og ofte vanskelig teknisk prøvelse, selv for erfarne ingeniørteams, at udarbejde effektive og effektive EDW/BI-systemer, der er forenklet med henblik på brugervenlighed og rapportering om disse data. Der kræves flere integrerede teknologier fra databasesystemer, databehandlingsværktøjer (ETL) som Talend, forskellige programmeringssprog, administration, rapportering og interaktiv grafiksoftware til højtydende netværk og kraftfulde computere med meget stor lagerkapacitet. Design, oprettelse, levering og support af robuste, ubesværlige EDW/BI-systemer til forenklet, intelligent brug er, du gættede det, problem nr. 3: Kompleksitet!
Ofte ser vi omfattende og elegante løsninger, der leveres til forretningsbrugeren, som ikke forstår forretningens sande behov. Vi får at vide, at sådan er det bare på grund af tekniske krav (begrænsninger; blink, blink, blink) og/eller designparametre (mangel på funktioner; puf, puf). Derfor problem nr. 4: Forretningsdomænet; tilpas dataene til forretningens behov, ikke omvendt!
Dertil kommer, at efterhånden som opstrøms-systemerne ændrer sig (og det vil de gøre), efterhånden som EDW/BI-teknologien skrider fremad (og det skal den), efterhånden som de dynamiske kompleksiteter, der er involveret, vinder frem (ubarmhjertigt), skal der med jævne mellemrum tilføjes nye datakilder til blandingen. Disse er som regel uforudsete og uplanlagte. Integrationsvirkningen kan være enorm og kræver ofte en fuldstændig fornyelse af de aggregerede data; deraf problem nr. 5: Fleksibilitet – eller mangel på samme!
Så hvordan løser vi disse problemer? Tja …
Bill Inmon, der i vid udstrækning betragtes som datawarehousingens fader, definerer et datawarehouse som:
“En emneorienteret, ikke-flygtig, tidsvariabel samling af data til støtte for ledelsens beslutninger”
(http://en.wikipedia.org/wiki/Bill_Inmon)
Ralph Kimball (http://en.wikipedia.org/wiki/Ralph_Kimball), en pioner inden for datawarehousing, udviklede den “dimensionelle modelleringsmetode”, der nu betragtes som de-facto standard inden for beslutningsstøtte. Den dimensionelle model (kaldet et “stjerneskema”) er forskellig fra Inmans “normaliseret modellering” (undertiden kaldet et “snefnugskema”) metodologi. I Kimballs stjerneskema er transaktionsdata opdelt i aggregerede “fakta” med referentielle “dimensioner”, der omgiver og giver deskriptorer, som definerer fakta. Den normaliserede model (3NF eller “tredje normalform”) lagrer data i relaterede “tabeller” i overensstemmelse med de regler for design af relationelle databaser, der blev fastlagt af E. F. Codd og Raymond F. Boyce i begyndelsen af 1970’erne, og som eliminerer redundans af data. Begge metoder har svagheder, når det drejer sig om at håndtere uundgåelige ændringer i de systemer, der forsyner datawarehouset, og om at rense data for at overholde strenge metodologiske krav.
Den såkaldte OLAP-kube (for “online analytical processing”) er en datastruktur, der giver mulighed for hurtig analyse af data fra flere perspektiver. Kubestrukturen oprettes ud fra enten et Star- eller Snowflake-skema, der er gemt som metadata, hvorfra man kan se eller “dreje” dataene på forskellige måder. Generelt har cubes én tidsbaseret dimension, som understøtter en historisk repræsentation af data. Oprettelse af OLAP-kuber kan være meget dyrt og skaber ofte en betydelig mængde data, som er ubrugelige eller ubrugelige. 80/20-reglen synes i mange tilfælde at være sand (hvor kun 20 % af OLAP-cubedataene viser sig at være nyttige), hvilket giver anledning til at stille spørgsmålet: Bygger man på en traditionel arkitektur, giver en OLAP-kube så virkelig tilstrækkelig ROI? Ofte er svaret et rungende NEJ! Holdbare EDW/BI-systemer skal levere reel værdi.
Læs mere om, hvordan Talend hjalp Tipico med at omdanne oceaner af data til banebrydende business intelligence.
En frisk tilgang
Data Vault er en hybrid datamodelleringsmetode, der giver historisk datarepræsentation fra flere kilder, der er designet til at være modstandsdygtig over for miljømæssige ændringer. Oprindeligt udtænkt i 1990 og frigivet i 2000 som en public domain-modelleringsmetode, beskriver Dan Linstedt, dens ophavsmand, en resulterende Data Vault-database som:
“Et detaljeorienteret, historisk sporing og unikt forbundet sæt af normaliserede tabeller, der understøtter et eller flere funktionelle områder af forretningen. Det er en hybrid tilgang, der omfatter det bedste af det bedste mellem 3NF og stjerneskemaer. Designet er fleksibelt, skalerbart, konsistent og kan tilpasses virksomhedens behov.”
(http://en.wikipedia.org/wiki/Data_Vault_Modeling)
Data Vault er fokuseret på forretningsprocessen og har som en dataintegrationsarkitektur robuste standarder og definitionsmetoder, der forener information for at give mening. Data Vault-modellen består af tre grundlæggende tabeltyper:
HUB (blå): indeholder en liste over unikke forretningsnøgler, der har sin egen surrogatnøgle. Metadata, der beskriver forretningsnøglens oprindelse eller postens “kilde”, lagres også for at spore, hvor og hvornår dataene stammer fra.
LNK (rød): etablerer relationer mellem forretningsnøgler (typisk hubs, men links kan linke til andre links); beskriver i det væsentlige et mange-til-mange-forhold. Links bruges ofte til at håndtere ændringer i datagranulariteten, hvilket reducerer virkningen af at tilføje en ny forretningsnøgle til en linket hub.
SAT (gul): indeholder beskrivende attributter, der kan ændre sig over tid (svarende til en Kimball Type II-dimension, der ændrer sig langsomt). Hvor hubber og links udgør datamodellens struktur, indeholder satellitter tidsmæssige og beskrivende attributter, herunder metadata, der knytter dem til deres overordnede hub- eller linktabeller. Metadata-attributter i en satellittabel, der indeholder en dato, hvor posten blev gyldig, og en dato, hvor den udløb, giver stærke historiske muligheder, som gør det muligt at foretage forespørgsler, der kan gå “tilbage i tiden”.
Der er flere vigtige fordele ved Data Vault-metoden:
– Forenkler dataindsamlingsprocessen
– Fjerner kravet om rensning af et stjerneskema
– Giver øjeblikkelig revisionsmulighed for HIPPA og andre regler
– Sætter fokus på det virkelige problem i stedet for at programmere uden om det
– Giver let mulighed for tilføjelse af nye datakilder uden forstyrrelse af det eksisterende skema
Simpelt sagt: Data Vault giver mulighed for at tilføje nye datakilder uden at forstyrre det eksisterende skema, Data Vault er både en datamodelleringsteknik og -metodologi, som giver plads til historiske data, auditering og sporing af data.
“Data Vault er det optimale valg til modellering af EDW i DW 2.0-rammen”
Bill Inmon
Adaptable
Gennem adskillelsen af forretningsnøgler (da de generelt er statiske) og associationerne mellem dem fra deres beskrivende attributter, imødegår en Data Vault problemet med ændringer i miljøet. Ved at bruge disse nøgler som den strukturelle rygrad i et datavarehus kan alle relaterede data organiseres omkring dem. Disse Hubs (forretningsnøgler), Links (forbindelser) og SAT (beskrivende attributter) understøtter en meget tilpasningsdygtig datastruktur, samtidig med at der opretholdes en høj grad af dataintegritet. Dan Linstedt sammenligner ofte Data Vault med et forenklet billede af hjernen, hvor neuroner er forbundet med Hubs og Satellites, og hvor dendritter er Links (informationsvektorer). Nogle Links er som synapser (vektorer i den modsatte retning). De kan oprettes eller fjernes undervejs, efterhånden som forretningsforholdene ændres, hvilket automatisk ændrer datamodellen efter behov uden at påvirke de eksisterende datastrukturer. Problem #1 løst!
Big Data
Data Vault v2.0 kom på banen i 2013 og inkorporerer problemfri integration af Big Data-teknologier sammen med metodologi, arkitektur og implementeringer af bedste praksis. Gennem denne vedtagelse kan meget store datamængder nemt inkorporeres i en Data Vault, der er designet til at lagre ved hjælp af produkter som Hadoop, Infobright, MongoDB og mange andre NoSQL-muligheder. Data Vault eliminerer de rensningskrav, der er forbundet med et Star Schema-design, og udmærker sig ved håndtering af store datasæt ved at reducere indlæsningstiderne og muliggøre parallelle indsættelser, der udnytter kraften i Big Data-systemer. Problem nr. 2 løst!
Simplificering
Det kan hurtigt lade sig gøre at udarbejde en effektiv Data Vault-model, når man først har forstået det grundlæggende i de 3 tabeltyper: Hub, Satellite og Link! Identificering af forretningsnøgler 1. og definition af Hubs er altid det bedste sted at starte. Derefter repræsenterer Hub-Satellitterne kildetabelkolonner, der kan ændres, og til sidst binder Links det hele sammen. Husk, at det også er muligt at have Link-Satellit-tabeller. Når du først har forstået disse begreber, er det nemt. Når du har færdiggjort din Data Vault-model, er den næste almindelige ting at gøre, at opbygge ETL-dataintegrationsprocessen til at fylde den. En Data Vault-datamodel er ikke begrænset til EDW/BI-løsninger, men når du skal hente data fra en datakilde og ind i et mål, er der generelt behov for en dataintegrationsproces. Talends mission er at forbinde den datadrevne virksomhed.
Med sin suite af integrationssoftware forenkler Talend udviklingsprocessen, reducerer indlæringskurven og mindsker de samlede ejeromkostninger med en forenet, åben og forudsigelig ETL-platform. Talend er en gennemprøvet ETL-teknologi og kan helt sikkert bruges til at udfylde og vedligeholde et robust EDW/BI-system, der er bygget på en Data Vault-datamodel. Problem #3 løst!
Din virksomhed
Data Vault definerer i det væsentlige Ontologien for en virksomhed, idet den beskriver forretningsdomænet og relationerne inden for det. Behandling af forretningsregler skal finde sted, før et stjerneskema udfyldes. Med en Data Vault kan du skubbe dem nedstrøms, efter EDW-indeksering. En yderligere Data Vault-filosofi er, at alle data er relevante, også selv om de er forkerte. Dan Linstedt antyder, at data, der er forkerte, er et forretningsproblem, ikke et teknisk problem. Jeg er enig! En EDW er virkelig ikke det rette sted til at rette (rense) dårlige data. Den enkle præmis for Data Vault er at indlæse 100 % af kildedataene 100 % af tiden; gode, dårlige eller grimme data. Relevant i dagens verden er det således blevet et standardkrav, at alle data i datavarehuset skal kunne revideres og spores. Denne datamodel er udviklet specifikt til at opfylde behovene i nutidens EDW/BI-systemer. Problem nr. 4 løst!
“At forstå Data Vault er at forstå forretningen”
(http://danlinstedt.com)
Fleksibel
Data Vault-metodologien er baseret på SEI/CMMI Level 5 best practices og omfatter mange af dens komponenter, der kombinerer dem med best practices fra Six Sigma, TQM og SDLC (Agile). Data Vault-projekter har korte kontrollerede udgivelsescyklusser og kan bestå af en produktionsudgivelse hver 2. eller 3. uge, hvilket automatisk indfører de gentagelige, konsekvente og målbare projekter, der forventes på CMMI-niveau 5. Når der skal tilføjes nye datakilder, kan der sandsynligvis tilføjes lignende forretningsnøgler, nye Hubs-Satellites-Links kan tilføjes og derefter knyttes yderligere til eksisterende Data Vault-strukturer uden nogen ændring af den eksisterende datamodel. Problem nr. 5 løst!
Konklusion
Sammenfattende kan det konkluderes, at Data Vault-modelleringen og -metodologien tager fat på elementerne i de problemer, vi identificerede ovenfor:
– Den tilpasser sig et skiftende forretningsmiljø
– Den understøtter meget store datasæt
– Den forenkler EDW/BI-designkompleksiteten
– Den øger brugervenligheden for forretningsbrugere, fordi den er modelleret efter forretningsdomænet
– Den gør det muligt at tilføje nye datakilder uden at påvirke det eksisterende design
Dette teknologiske fremskridt har allerede vist sig at være meget effektivt og virkningsfuldt. Data Vault er let at designe, opbygge, udfylde og ændre, og det er en klar vinder. Meget cool! Vil du have en?
Besøg http://learndatavault.com eller http://www.keyldv.com/lms for at få meget mere at vide om modellering og metodologi til Data Vault.
Mens du er i gang, kan du downloade en gratis prøveversion af Talend Cloud Integration Platform for at se, hvad dine data virkelig kan gøre.