Utveckling av DATA VAULT och övergång till BUSINESS DATA VAULT

I den tidigare artikeln beskrev jag grunderna i DATA VAULT, de centrala elementen i DATA VAULT och deras syften. Ämnet DATA VAULT kan dock inte anses vara uttömt; vi måste prata om nästa steg i evolutionen av DATA VAULT.

I denna artikel kommer jag att fokusera på utvecklingen av DATA VAULT och övergången till BUSINESS DATA VAULT eller helt enkelt BUSINESS VAULT.

Orsaker till att BUSINESS DATA VAULT uppstod.

Det är värt att notera att, trots sina vissa styrkor, DATA VAULT inte är utan brister. En av dessa brister är svårigheten att skriva analytiska frågor. Frågorna har ett betydande antal JOIN:ar, vilket gör att koden blir lång och otymplig. Dessutom genomgår inte data som kommer in i DATA VAULT några omvandlingar, så ur ett affärsperspektiv har DATA VAULT i sitt rena skick inget ovillkorligt värde.

Just för att åtgärda dessa brister har metodologin DATA VAULT utvidgats med sådana element som:

• PIT (point in time) tabeller;
• BRIDGE tabeller;
• PREDEFINED DERIVATIONS.

Låt oss gå igenom syftet med dessa element mer i detalj.

PIT tabeller

Som regel kan ett affärsobjekt (HUB) bestå av data med olika uppdateringsfrekvenser. Om vi till exempel talar om data som karakteriserar en person, kan vi säga att information om telefonnummer, adress eller e-post har en högre uppdateringsfrekvens än, låt oss säga, namn, passdata, civilstånd eller kön.

Därför, när vi bestämmer satelliter, bör vi ha i åtanke deras uppdateringsfrekvens. Varför är detta viktigt?

Om vi lagrar attribut med olika uppdateringsfrekvenser i samma tabell, måste vi lägga till en rad i tabellen vid varje uppdatering av det oftast förändrade attributet. Följaktligen – ökat behov av diskytelse och längre exekveringstid för frågorna.

Nu när vi har delat satelliterna efter uppdateringsfrekvens, och kan ladda data i dem oberoende, bör vi säkerställa att vi kan få aktuella data. Bättre utan att använda överflödiga JOIN:ar.

Låt mig förklara, till exempel, att det krävs att få aktuell (datum för senaste uppdatering) information från satelliter med olika uppdateringsfrekvenser. För detta kommer det att krävas inte bara att göra en JOIN, utan även att skapa flera inbäddade förfrågningar (till varje satellit som innehåller information) med val av den senaste uppdateringsdatum MAX(Uppdateringsdatum). Med varje ny JOIN växer en sådan kod och blir snabbt svår att förstå.

PIT-tabellen syftar till att förenkla sådana förfrågningar, PIT-tabeller fylls samtidigt som nya data skrivs in i DATA VAULT. PIT-tabell:

Således har vi information om aktuell datakvalitet för alla satelliter vid varje tidpunkt. Genom att använda JOINs till PIT-tabellen kan vi helt eliminera inbäddade förfrågningar, givetvis under förutsättning att PIT fylls dagligen och utan avbrott. Även om det finns luckor i PIT kan aktuella data endast erhållas genom att använda en inbäddad förfrågan till själva PIT. En inbäddad förfrågan kommer att köras snabbare än inbäddade förfrågningar till varje satellit.

BRIDGE

Tabeller av BRIDGE-typ används också för att förenkla analytiska förfrågningar. Men skillnaden från PIT är att de förenklar och påskyndar förfrågningar mellan olika hubbar, länkar och deras satelliter.

Tabellen innehåller alla nödvändiga nycklar för alla satelliter som ofta används i förfrågningar. Dessutom, om så krävs, kan hashade affärsnycklar kompletteras med nycklar i textformat, om namnen på nycklarna behövs för analys.

Det är så att utan användning av BRIDGE, i processen att hämta data från satelliter som tillhör olika hubbar, kommer det att krävas att göra JOIN inte bara mellan satelliterna själva, utan också mellan länkarna som förbinder hubbarna.

Tilstedeværelsen eller fraværet av BRIDGE bestäms av lagringskonfigurationen och behovet av att optimera hastigheten på förfrågningar. Det är svårt att tänka sig ett universellt exempel på BRIDGE.

PREDEFINED DERIVATIONS

En annan typ av objekt som närmar oss BUSINESS DATA VAULT är tabeller som innehåller förberäknade indikatorer. Sådana tabeller är verkligen viktiga för verksamheten, de innehåller information som har aggregerats enligt angivna regler och möjliggör relativt enkel åtkomst till den.

Arkitekturella PREDEFINED DERIVATIONS är inget annat än en ytterligare satellit av en viss hub. Den, precis som en vanlig satellit, innehåller affärnyckeln och datumet för skapandet av posten i satelliten. Men här slutar likheterna. Den ytterligare sammansättningen av attributen för en sådan "specialiserad" satellit bestäms av affärsanvändarna baserat på de mest efterfrågade, förhandsberäknade indikatorerna.

Till exempel kan en hub som innehåller information om en anställd inkludera en satellit med sådana indikatorer som:

• Minimilön;
• Maximallön;
• Genomsnittlig lön;
• Ackumulerat resultat av den utbetalda lönen osv.

Det är logiskt att inkludera PREDEFINED DERIVATIONS i PIT-tabellen för denna hub, så kan man enkelt få datautdrag för anställda på ett specifikt valt datum.

SLUTSATSER

Som erfarenheten visar, är användningen av DATA VAULT av affärsanvändare något besvärlig av flera anledningar:

• Frågekoden är komplex och skrymmande;
• Överflödet av JOINs påverkar frågornas prestanda;
• För att skriva analytiska frågor krävs en utmärkt kunskap om lagrets struktur.

För att förenkla åtkomsten till data, utvidgas DATA VAULT med ytterligare objekt:

• PIT (point in time) tabeller;
• BRIDGE tabeller;
• PREDEFINED DERIVATIONS.

I nästa artikeln Jag planerar att berätta om det mest intressanta, enligt min mening, för dem som arbetar med BI. Jag kommer att presentera sätt att skapa fakta- och dimensions-tabeller baserat på DATA VAULT.

Materialen i artikeln är baserade på:

• På publikation Kenta Graziano, där det förutom detaljerade beskrivningar finns modeller;
• Boken: “Building a Scalable Data Warehouse with DATA VAULT 2.0”;
• Artikel Grunderna i Data Vault.

Källa: habr.com