Enterprise Data Warehouse (EDW)-system syftar till att tillhandahålla verklig Business Intelligence (BI) för det datadrivna företaget. Företagen måste ta itu med kritiska mätvärden som är inbäddade i dessa vitala, levande data. Att tillhandahålla en viktig process för dataintegration som så småningom stöder en mängd olika rapporteringskrav är ett viktigt mål för dessa Enterprise Data Warehouse-system. För att bygga upp dem krävs betydande insatser för utformning, utveckling, administration och drift. När affärssystem, strukturer eller regler i uppströmsledet förändras, misslyckas med att tillhandahålla konsekventa data eller kräver nya lösningar för systemintegration, ger de minimala omarbetningskraven oss problem nr 1: Det enda konstanta är förändring, så hur väl kan en EDW/BI-lösning anpassa sig?
”Det är inte den starkaste av arterna som överlever, inte heller den mest intelligenta som överlever. Det är den som är mest anpassningsbar till förändring.” Charles Darwin
Konsumtion och analys av affärsdata av olika användargrupper har blivit en kritisk verklighet för att bibehålla en konkurrensfördel men tekniska realiteter idag kräver ofta högt utbildade slutanvändare. Att fånga, bearbeta, omvandla, rensa och rapportera dessa data kan vara förståeligt, men i de flesta fall kan datamängden vara överväldigande; ja, problem nr 2: Really Big Data; ofta karakteriserat som: Volym, hastighet, variation, variabilitet, sanning, visualisering, & värde!
Att utforma effektiva och ändamålsenliga EDW/BI-system, förenklade för användbarhet och rapportering av dessa data, blir snabbt en skrämmande och ofta svår teknisk prövning, till och med för erfarna ingenjörsteam. Flera integrerade tekniker krävs, från databassystem, verktyg för databehandling (ETL) som Talend, olika programmeringsspråk, programvara för administration, rapportering och interaktiv grafik till högpresterande nätverk och kraftfulla datorer med mycket stor lagringskapacitet. Utformning, skapande, leverans och support av robusta, lättanvända EDW/BI-system för förenklad, intelligent användning är, ni gissade det, problem nr 3: Komplexitet!
Ofta ser vi omfattande och eleganta lösningar som levereras till affärsanvändare som inte förstår verksamhetens verkliga behov. Vi får höra att det bara är så på grund av tekniska krav (begränsningar, blinkning, blinkning) och/eller designparametrar (brist på funktioner, blinkning, blinkning). Därav problem nr 4: Affärsområdet; anpassa data till verksamhetens behov, inte tvärtom!
För övrigt, när systemen i tidigare led förändras (och det kommer de att göra), när EDW/BI-tekniken går framåt (och det måste den göra), när de dynamiska komplexiteterna som är inblandade råder (obevekligt), måste man då och då lägga till nya datakällor i blandningen. Dessa är vanligtvis oförutsedda och oplanerade. Integrationseffekterna kan vara enorma och kräver ofta en fullständig förnyelse av de aggregerade uppgifterna, därav problem nr 5: Flexibilitet, eller bristen på flexibilitet!
Hur löser vi då dessa problem? Tja …
Bill Inmon, som allmänt betraktas som datalagerets fader, definierar ett datalager som:
”En ämnesorienterad, icke-flyktig, tidsvariabel samling av data till stöd för ledningens beslut”
(http://en.wikipedia.org/wiki/Bill_Inmon)
Ralph Kimball (http://en.wikipedia.org/wiki/Ralph_Kimball), en banbrytande datalagringsarkitekt, utvecklade den metodik för ”dimensionell modellering” som nu betraktas som en de facto-standard inom området för beslutsstöd. Den dimensionella modellen (som kallas ”stjärnschema”) skiljer sig från Inmans metodik för ”normaliserad modellering” (som ibland kallas ”snöflingeschema”). I Kimballs stjärnskema delas transaktionsdata upp i aggregerade ”fakta” med referentiella ”dimensioner” som omger och tillhandahåller deskriptorer som definierar fakta. Den normaliserade modellen (3NF eller ”tredje normalformen”) lagrar data i relaterade ”tabeller” enligt de regler för utformning av relationsdatabaser som fastställdes av E. F. Codd och Raymond F. Boyce i början av 1970-talet och som eliminerar redundans av data. Båda har svagheter när det gäller att hantera oundvikliga förändringar i de system som försörjer datalagret och att rensa data för att uppfylla strikta metodkrav.
Vidare är OLAP-kuben (för ”online analytical processing”) en datastruktur som gör det möjligt att snabbt analysera data från flera olika perspektiv. Kubstrukturen skapas från antingen ett Star- eller Snowflake-schema som lagras som metadata från vilket man kan visa eller ”vrida” data på olika sätt. I allmänhet har kuber en tidsbaserad dimension som stöder en historisk representation av data. Att skapa OLAP-kuber kan vara mycket dyrt och skapar ofta en stor mängd data som är av liten eller ingen nytta. 80/20-regeln tycks i många fall stämma (där endast 20 % av OLAP-kubens data visar sig vara användbara), vilket väcker frågan: Är det verkligen så att en OLAP-kubb, som bygger på en traditionell arkitektur, ger tillräcklig avkastning på investeringen? Ofta är svaret ett rungande NEJ! Hållbara EDW/BI-system måste leverera verkligt värde.
Lär dig hur Talend hjälpte Tipico att omvandla oceaner av data till banbrytande business intelligence.
En ny strategi
Data Vault är en hybridmetod för datamodellering som tillhandahåller historisk datarepresentation från flera källor och som är utformad för att vara motståndskraftig mot miljöförändringar. Dan Linstedt, som ursprungligen utformades 1990 och släpptes 2000 som en modellmetodik för den offentliga sektorn, beskriver en Data Vault-databas som:
”En detaljorienterad, historisk spårning och unikt länkad uppsättning normaliserade tabeller som stöder ett eller flera funktionella affärsområden. Det är en hybridmetod som omfattar det bästa av branschen mellan 3NF och Star Schemas. Designen är flexibel, skalbar, konsekvent och anpassningsbar till företagets behov.”
(http://en.wikipedia.org/wiki/Data_Vault_Modeling)
Fokuserad på affärsprocessen har Data Vault som en arkitektur för dataintegration robusta standarder och definitionsmetoder som förenar information för att göra den begriplig. Data Vault-modellen består av tre grundläggande tabelltyper:
HUB (blå): innehåller en lista över unika affärsnycklar som har en egen surrogatnyckel. Metadata som beskriver affärsnyckelns ursprung, eller postens ”källa”, lagras också för att spåra var och när uppgifterna har sitt ursprung.
LNK (röd): upprättar relationer mellan affärsnycklar (vanligtvis hubbar, men länkar kan länka till andra länkar); beskriver i huvudsak en många-till-många-relation. Länkar används ofta för att hantera förändringar i datagranularitet, vilket minskar effekten av att lägga till en ny affärsnyckel till en länkad hubb.
SAT (gul): innehåller beskrivande attribut som kan förändras med tiden (liknande en dimension av Kimball-typ II som förändras långsamt). När nav och länkar utgör datamodellens struktur innehåller satelliter tidsmässiga och beskrivande attribut, inklusive metadata som länkar dem till deras överordnade nav- eller länktabeller. Metadataattribut i en satellittabell som innehåller ett datum då posten blev giltig och ett datum då den upphörde att gälla ger kraftfulla historiska möjligheter som gör det möjligt att göra sökningar som kan gå ”bakåt i tiden”.
Det finns flera viktiga fördelar med Data Vault-metoden:
– Förenklar datainsamlingsprocessen
– Tar bort rensningskravet för ett stjärnschema
– Ger omedelbar revisionsmöjlighet för HIPPA och andra bestämmelser
– Sätter fokus på det verkliga problemet i stället för att programmera runt det
– Gör det enkelt möjligt att lägga till nya datakällor utan att störa det befintliga schemat
Simpelt uttryckt, Data Vault är både en teknik för datamodellering och en metodik som rymmer historiska data, revision och spårning av data.
”Data Vault är det optimala valet för att modellera EDW inom ramen för DW 2.0”
Bill Inmon
Anpassningsbar
Genom att separera affärsnycklar (eftersom de i allmänhet är statiska) och associationerna mellan dem från deras beskrivande attribut, möter en Data Vault problemet med förändringar i miljön. Genom att använda dessa nycklar som strukturell ryggrad i ett datalager kan alla relaterade data organiseras kring dem. Dessa hubbar (affärsnycklar), länkar (associationer) och SAT (beskrivande attribut) stöder en mycket anpassningsbar datastruktur samtidigt som en hög grad av dataintegritet bibehålls. Dan Linstedt kopplar ofta datavalvet till en förenklad bild av hjärnan där neuronerna är förknippade med hubbar och satelliter och där dendriterna är länkar (informationsvektorer). Vissa länkar är som synapser (vektorer i motsatt riktning). De kan skapas eller tas bort i farten när affärsrelationerna förändras och datamodellen automatiskt ändras efter behov utan att de befintliga datastrukturerna påverkas. Problem #1 löst!
Big Data
Data Vault v2.0 kom in på scenen 2013 och innehåller sömlös integration av Big Data-teknik tillsammans med metodik, arkitektur och implementering av bästa praxis. Genom detta antagande kan mycket stora datamängder enkelt införlivas i ett Data Vault som är utformat för lagring med hjälp av produkter som Hadoop, Infobright, MongoDB och många andra NoSQL-alternativ. Data Vault eliminerar reningskraven i en Star Schema-design och utmärker sig vid hantering av stora datamängder genom att minska inmatningstiderna och möjliggöra parallella inmatningar som utnyttjar kraften i Big Data-system. Problem #2 löst!
Förenkling
Det går snabbt att skapa en effektiv och ändamålsenlig Data Vault-modell när man väl har förstått grunderna för de tre tabelltyperna: Hub, Satellite och Link! Att identifiera affärsnycklarna först och definiera hubbarna är alltid det bästa sättet att börja. Därefter representerar Hub-Satellites kolumner i källtabellen som kan ändras, och slutligen binder länkar ihop allting. Kom ihåg att det också är möjligt att ha tabeller med länkar och satelliter. När du väl har förstått dessa begrepp är det enkelt. När du har färdigställt din Data Vault-modell är nästa vanliga sak att göra att bygga ETL-dataintegrationsprocessen för att fylla den. Data Vault-datamodellen är inte begränsad till EDW/BI-lösningar, men när du behöver hämta data från en datakälla till ett mål krävs i allmänhet en process för dataintegration. Talends uppdrag är att ansluta det datadrivna företaget.
Med sin svit av integrationsprogramvara förenklar Talend utvecklingsprocessen, minskar inlärningskurvan och sänker den totala ägandekostnaden med en enhetlig, öppen och förutsägbar ETL-plattform. Talend är en beprövad ETL-teknik och kan säkert användas för att fylla på och underhålla ett robust EDW/BI-system som bygger på en datamodell från Data Vault. Problem #3 löst!
Din verksamhet
Data Vault definierar i huvudsak ett företags ontologi genom att den beskriver affärsområdet och relationerna inom det. Behandling av affärsregler måste ske innan ett stjärnschema fylls på. Med ett datavalv kan du skjuta dem nedströms, efter EDW-intagningen. En annan filosofi för Data Vault är att alla uppgifter är relevanta, även om de är felaktiga. Dan Linstedt menar att felaktiga uppgifter är ett affärsproblem, inte ett tekniskt problem. Jag håller med! En EDW är verkligen inte rätt plats för att åtgärda (rensa) felaktiga data. Den enkla förutsättningen för Data Vault är att 100 % av källdata tas in 100 % av tiden, oavsett om de är bra, dåliga eller fula. I dagens värld är det därför ett standardkrav att alla data i datalagret ska kunna granskas och spåras. Denna datamodell är särskilt utformad för att uppfylla behoven i dagens EDW/BI-system. Problem nr 4 löst!
”Att förstå Data Vault är att förstå verksamheten”
(http://danlinstedt.com)
Flexibel
Data Vault-metodiken är baserad på SEI/CMMI Level 5 bästa praxis och innehåller många av dess komponenter som kombineras med bästa praxis från Six Sigma, TQM och SDLC (Agile). Data Vault-projekten har korta kontrollerade lanseringscykler och kan bestå av en produktionsversion varannan eller var tredje vecka, vilket automatiskt innebär att de upprepbara, konsekventa och mätbara projekt som förväntas på CMMI-nivå 5 antas. När nya datakällor behöver läggas till, och liknande affärsnycklar är troliga, kan nya hubbar, satelliter och länkar läggas till och sedan länkas vidare till befintliga Data Vault-strukturer utan någon ändring av den befintliga datamodellen. Problem nr 5 löst!
Slutsats
Slutsatsen är att Data Vault-modelleringen och -metodiken behandlar delarna av de problem vi identifierat ovan:
– Den anpassar sig till en föränderlig affärsmiljö
– Den stöder mycket stora datamängder
– Den förenklar EDW/BI-designens komplexitet
– Den ökar användbarheten för affärsanvändare eftersom den är modellerad efter affärsområdet
– Den gör det möjligt att lägga till nya datakällor utan att påverka den befintliga konstruktionen
Detta tekniska framsteg har redan visat sig vara mycket effektivt och ändamålsenligt. Data Vault är lätt att utforma, bygga, fylla på och ändra och är en klar vinnare. Mycket häftigt! Vill du ha en?
Visa http://learndatavault.com eller http://www.keyldv.com/lms för mycket mer om modellering och metodik för Data Vault.
När du ändå håller på, ladda ner en gratis provversion av Talend Cloud Integration Platform för att se vad dina data verkligen kan göra.